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

本頁提供最佳做法，說明如何使用 GPU 搭配 Cloud Run 服務執行 AI 推論時，盡可能提升效能，並著重於大型語言模型 (LLM)。如要建構及部署 Cloud Run 服務，以便即時回應調整規模事件，請完成下列步驟：
  • 使用載入速度快，且轉換為 GPU 可用結構的次數最少的模型，並最佳化載入方式。
  • 使用可有效率地並行執行作業的設定，盡可能減少每秒處理目標要求所需的 GPU 數量，同時降低成本。

建議在 Cloud Run 上載入大型 ML 模型的方法

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

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

以下是各選項的比較：

模型位置 部署時間 開發體驗 容器啟動時間 儲存空間費用
容器映像檔 慢。如果映像檔包含大型模型，匯入 Cloud Run 的時間會比較長。 變更容器映像檔後，必須重新部署，但大型映像檔的部署速度可能會較慢。 視模型大小而定。如果是非常大型的模型，請使用 Cloud Storage，效能較可預測，但速度較慢。 Artifact Registry 中可能有多個副本。
Cloud Storage，透過 Cloud Storage FUSE 磁碟區掛接載入 快速。模型是在容器啟動期間下載。 設定不難，也不需要變更 Docker 映像檔。 使用網路最佳化功能時，速度會更快。不會平行處理下載作業。 一份副本存放在 Cloud Storage。
Cloud Storage，並使用 Google Cloud CLI 指令 gcloud storage cp 或 Cloud Storage API 同時下載，如轉移管理員並行下載程式碼範例所示。 快速。模型是在容器啟動期間下載。 設定難度稍高，因為您需要在映像檔上安裝 Google Cloud CLI，或是更新程式碼以使用 Cloud Storage API。 使用網路最佳化功能時，速度會更快。Google Cloud CLI 會平行下載模型檔案，因此速度比 FUSE 掛接更快。 一份副本存放在 Cloud Storage。
網際網路 快速。模型是在容器啟動期間下載。 通常較簡單 (許多架構會從中央存放區下載模型)。 通常品質不佳且難以預測：
  • 架構可能會在初始化期間套用模型轉換。(您應在建構時執行這項操作)。
  • 下載模型的模型主機和程式庫可能效率不彰。
  • 從網際網路下載檔案有可靠性風險。如果下載目標停止運作，服務可能無法啟動，且下載的基礎模型可能會變更，導致品質下降。建議您在自己的 Cloud Storage bucket 中代管。
 視模型代管供應商而定。

將模型儲存在容器映像檔中

將 ML 模型儲存在容器映像檔中，模型載入作業就能享有 Cloud Run 最佳化的容器串流基礎架構。 不過，建構包含機器學習模型的容器映像檔非常耗用資源，尤其是在處理大型模型時。具體來說，建構程序可能會因網路處理量而受到限制。使用 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 模型時進行最佳化，請使用Cloud Storage 磁碟區掛接，或直接使用 Cloud Storage API 或指令列，並搭配 Direct VPC，將輸出設定值設為 all-traffic，以及私人 Google 存取權。

使用任何位置快取功能會產生額外費用，但可將資料有效快取至 SSD，加快讀取速度，進而縮短模型載入延遲時間。

如要縮短模型讀取時間，請嘗試下列掛接選項，啟用 Cloud Storage FUSE 功能：

  • cache-dir：啟用檔案快取功能，並使用記憶體內磁碟區掛接做為基礎目錄，用於保存檔案。將 cache-dir 掛接選項值設為記憶體內磁碟區名稱，格式為 cr-volume:{volume name}。舉例來說，如果您有名為 in-memory-1 的記憶體內磁碟區，想做為快取目錄使用，請指定 cr-volume:in-memory-1。設定這個值後，您也可以設定其他 file-cache 旗標來設定快取。
  • enable-buffered-read：將 enable-buffered-read 欄位設為 true，即可將 Cloud Storage 物件的部分內容非同步預先擷取到記憶體內緩衝區。這樣一來，後續讀取作業就能從緩衝區提供服務，不必發出網路呼叫。設定這個欄位時，您也可以設定 read-global-max-blocks 欄位，為所有檔案控制代碼設定緩衝讀取作業可用的最大區塊數。

如果同時使用 cache-dir 和 enable-buffered-read，cache-dir 的效力優先。請注意，啟用上述任一功能後，系統會將 Cloud Storage FUSE 程序的資源用量計入容器記憶體限制。請按照設定記憶體限制的操作說明，考慮提高容器記憶體限制。

從網際網路載入模型

如要從網際網路載入機器學習模型，請透過虛擬私有雲網路轉送所有流量，並將輸出設定值設為 all-traffic，然後設定 Cloud NAT，以高頻寬連上公開網際網路。

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

下列各節說明建構、部署、執行階段和系統設計的注意事項。

在建構期間

以下列出規劃建構作業時需要考量的因素：

  • 選擇合適的基本圖片。建議從深度學習容器或 NVIDIA Container Registry，取得所用機器學習框架適合的映像檔。這些映像檔都安裝了最新的效能相關套件。我們不建議建立自訂映像檔。
  • 除非您能證明 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 服務都必須設定以執行個體為準的計費方式。