最佳做法：在 Cloud Run 服務中使用 GPU 進行 AI 推論

• 使用可快速載入且只需進行少量轉換作業就能轉換為 GPU 就緒結構的模型，並最佳化載入方式。
• 使用可讓並行執行作業達到最高效率的設定，藉此減少每秒處理目標要求所需的 GPU 數量，同時降低成本。

在 Cloud Run 上載入大型機器學習模型的建議方式

Google 建議您將 ML 模型儲存在容器映像檔內，或是最佳化從 Cloud Storage 載入模型。

儲存及載入機器學習模型的取捨之道

以下是這些選項的比較：

在容器映像檔中儲存模型

在部署至 Cloud Run 的容器映像檔中儲存 ML 模型，可享有 Cloud Run 內建容器映像檔串流最佳化功能的優勢，可在不進行額外網路最佳化情況下，盡可能縮短檔案載入時間。

建構包含機器學習模型的容器可能需要一段時間。如果您使用 Cloud Build，可以設定 Cloud Build 使用更大的機器，以便加快建構作業。如要這麼做，請使用建構設定檔建立映像檔，其中包含下列步驟：

steps:
- name: 'gcr.io/cloud-builders/docker'
  args: ['build', '-t', 'IMAGE', '.']
- name: 'gcr.io/cloud-builders/docker'
  args: ['push', 'IMAGE']
images:
- IMAGE
options:
 machineType: 'E2_HIGHCPU_32'
 diskSizeGb: '500'
 

如果包含模型的圖層在圖片之間不同 (不同的雜湊值)，則可為每個圖片建立一個模型副本。如果模型層在每個圖像中都是獨特的，每個圖像可能會有一個模型副本，因此可能會產生額外的 Artifact Registry 費用。

將模型儲存在 Cloud Storage 中

如要從 Cloud Storage 載入 ML 模型時，為了最佳化 ML 模型載入作業，您可以使用 Cloud Storage 磁碟區掛載，或直接使用 Cloud Storage API 或指令列，但必須使用 直接 VPC，並將出口設定值設為 all-traffic，以及私人 Google 存取權。

從網際網路載入模型

如要最佳化從網際網路載入機器學習模型的作業，請將所有流量轉送至 vpc 網路，並將傳出設定值設為 all-traffic，然後設定 Cloud NAT，以高頻寬連線至公開網際網路。

建構、部署、執行階段和系統設計注意事項

以下各節將說明建構、部署、執行階段和系統設計的考量事項。

在建構期間

以下清單列出規劃建構作業時需要考量的事項：

• 選擇合適的基本映像檔。您應從所用 ML 架構的深度學習容器或 NVIDIA 容器登錄機制中，取得相關映像檔。這些映像檔已安裝最新的效能相關套件。我們不建議建立自訂映像檔。
• 請選擇 4 位元量化模型，以便盡可能提高並行處理能力，除非您能證明這些模型會影響結果品質。量化可產生較小且速度更快的模型，減少提供模型所需的 GPU 記憶體量，並可在執行期間增加平行處理作業。理想情況下，模型應以目標位元深度訓練，而非將其量化至該深度。
• 請選擇載入速度快的模型格式，盡可能縮短容器啟動時間，例如 GGUF。這些格式可更準確地反映目標量化類型，並在載入 GPU 時減少轉換次數。基於安全考量，請勿使用 pickle 格式的查核點。
• 在建構期間建立並預熱 LLM 快取。在建構 Docker 映像檔時，請在建構機器上啟動 LLM。啟用提示快取功能，並提供常見或範例提示，以便為實際使用情境預熱快取內容。儲存產生的輸出內容，以便在執行階段載入。
• 儲存您在建構期間產生的推論模型。與載入儲存效率較低的模型，以及在容器啟動時套用量化等轉換相比，這可節省大量時間。

部署時

下列清單列出規劃部署作業時，需要考量的事項：

1. 請務必在 Cloud Run 中正確設定服務並行數。
2. 根據設定調整啟動探測程序。

啟動探測可判斷容器是否已啟動，且是否已準備好接受流量。設定啟動探測時，請考量下列重點：

• 充足的啟動時間：容許容器 (包括模型) 有充足的時間完成初始化和載入作業。
• 模型就緒性驗證：請只在應用程式準備好處理要求時，才讓探測器通過。大多數的服務引擎會在模型載入 GPU 記憶體時自動達成這項目標，避免提早提出要求。

請注意，Ollama 可以在模型載入前開啟 TCP 通訊埠。解決方式如下：

• 預先載入模型：請參閱 Ollama 說明文件，瞭解如何在啟動期間預先載入模型。

在執行階段

• 主動管理支援的內容長度。您支援的背景區間越小，可同時執行的查詢就越多。具體操作方式取決於架構。
• 使用您在建構期間產生的 LLM 快取。提供您在產生提示和前置字元快取時，在建構期間使用的相同標記。
• 從您剛剛寫入的儲存模型載入。如要比較載入模型的不同方式，請參閱「儲存和載入模型的取捨之處」。
• 如果架構支援，請考慮使用量化鍵/值快取。這可減少每個查詢的記憶體需求，並允許設定更多平行作業。但也可能會影響品質。
• 調整 GPU 記憶體的用量，以便為模型權重、啟用和鍵/值快取保留記憶體。盡可能將其設為最高值，但不要導致記憶體不足錯誤。
• 請檢查您的架構是否有任何選項可改善容器啟動效能 (例如使用模型載入並行化)。
• 請在服務程式碼中正確設定並行性。請確認服務程式碼已設定為搭配 Cloud Run 服務並行設定運作。

在系統設計層級

• 視需要新增語意快取。在某些情況下，快取整個查詢和回應，是限制常見查詢成本的好方法。
• 控制前置文字中的變化。提示快取功能只有在包含按順序排列的提示時才有用。快取實際上是前置字串快取。序列中的插入或編輯內容，表示這些內容未快取或僅部分顯示。

自動調度和 GPU

如果您使用預設的 Cloud Run 自動調度資源功能，Cloud Run 會根據 CPU 使用率和要求並行處理等因素，自動調度資源每個修訂版本的執行個體數量。不過，Cloud Run 不會根據 GPU 使用率自動調整執行個體數量。

對於含 GPU 的修訂版本，如果修訂版本的 CPU 使用率不高，Cloud Run 就會針對要求並行處理進行擴充。如要針對要求並行處理最佳化調整，您必須設定最佳的每個執行個體的並行要求數量上限，詳情請參閱下一節。

每個執行個體的並行要求數量上限

「每個執行個體的並行要求數量上限」設定會控制 Cloud Run 一次向單一執行個體傳送的要求數量上限。您必須調整並行性，以便符合每個執行個體內部可處理的並行性上限，並確保良好效能。

最高並行作業和 AI 工作負載

在每個執行個體的 GPU 上執行 AI 推論工作負載時，程式碼可處理的最大並行作業數 (並且維持良好效能) 取決於特定架構和實作細節。以下因素會影響您設定最佳並行要求數量上限的方式：

• 載入至 GPU 的模型例項數量
• 每個模型的並行查詢數
• 使用批次處理
• 特定批次設定參數
• 非 GPU 工作量

如果並行要求數量上限設定過高，要求可能會在執行個體中等待 GPU 存取權，導致延遲時間增加。如果並行要求數量上限設定過低，GPU 可能會未充分利用，導致 Cloud Run 擴充出比必要更多的執行個體。

設定 AI 工作負載並行要求數量上限的一般規則如下：

(Number of model instances * parallel queries per model) + (number of model instances * ideal batch size)

舉例來說，假設某個執行個體將 3 模型例項載入 GPU，且每個模型例項都能處理 4 個並行查詢。理想的批次大小也是 4，因為這是每個模型例項可處理的並行查詢數量。根據經驗法則，您可以設定並行要求數量上限 24：(3 * 4) + (3 * 4)。

請注意，這個公式只是大致的規則。理想的並行要求數量上限設定取決於實作方式的具體細節。為達到實際最佳效能，建議您使用不同的最大並行要求設定負載測試服務，評估哪個選項的效能最佳。

總處理量與延遲時間與成本之間的取捨

如要瞭解最大並發要求對處理量、延遲時間和成本的影響，請參閱「處理量與延遲時間與成本的權衡」。請注意，所有使用 GPU 的 Cloud Run 服務都必須設定以執行個體為準的帳單計費方式。