最佳做法：使用 GPU 的 Cloud Run 工作

本頁提供最佳做法，說明如何使用 Cloud Run 工作搭配 GPU，處理 AI 工作負載 (例如使用偏好的架構訓練大型語言模型 (LLM)、微調，以及對 LLM 執行批次或離線推論) 時，盡可能提升效能。如要建立 Cloud Run 工作，即時執行耗用大量運算資源的作業或批次處理作業，請按照下列步驟操作：
  • 使用載入速度快，且只需經過最少轉換就能成為 GPU 可用結構的模型，並最佳化載入方式。
  • 使用可有效率地並行執行作業的設定，在每秒處理目標要求數量的同時，減少所需的 GPU 數量，進而降低成本。

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

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 值區中託管。
 取決於模型代管服務供應商。

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

將 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 存取權。

從網際網路載入模型

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

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

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

在建構期間

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

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

部署時

規劃部署作業時，請考量下列事項：

  • 為工作執行設定一小時或更短的任務逾時時間。
  • 如果您在工作執行期間執行平行工作，請判斷並將 parallelism 設為低於您為專案分配的適用配額限制最低值。根據預設，平行執行的工作會使用 5 個 GPU 工作執行個體配額。如要申請提高配額，請參閱「如何提高配額」。GPU 工作會盡快啟動，但上限取決於您為專案和所選區域分配的 GPU 配額。如果將平行處理設定為超過 GPU 配額限制，部署作業就會失敗。

在執行階段

  • 主動管理支援的內容長度。支援的背景區間越小，可並行執行的查詢就越多。具體做法取決於架構。
  • 使用在建構時間產生的 LLM 快取。產生提示和前置字元快取時，請提供建構期間使用的相同旗標。
  • 從您剛才寫入的已儲存模型載入。如要比較載入模型的方式，請參閱儲存及載入模型的取捨。
  • 如果架構支援，請考慮使用量化鍵/值快取。這可減少每個查詢的記憶體需求，並允許設定更多平行處理。但這也可能影響品質。
  • 調整要為模型權重、啟動和鍵值快取保留的 GPU 記憶體量。盡量將值設高，但不要造成記憶體不足錯誤。
  • 檢查架構是否有任何選項可提升容器啟動效能 (例如使用模型載入平行化)。

系統設計層級

  • 視需要新增語意快取。在某些情況下，快取整個查詢和回應是限制常見查詢費用的絕佳方式。
  • 控制前言的差異。提示快取只在包含依序排列的提示時才有用。快取實際上是以前置字元為快取鍵。 如果序列中出現插入或編輯內容，表示這些內容未快取，或只有部分內容快取。