最佳做法：使用 GPU 的 Cloud Run worker 集區

本頁提供最佳做法，說明如何搭配使用 Cloud Run 工作人員集區與 AI 工作負載，例如使用偏好的架構訓練大型語言模型 (LLM)、微調，以及對 LLM 執行批次或離線推論，進而提升效能。如要建立 Cloud Run 工作站集區，即時執行運算密集型工作或批次處理作業，請按照下列步驟操作：

使用載入速度快、易於轉換為 GPU 適用結構的模型，並採用最佳的載入方式。
使用可有效率地並行執行作業的設定，盡可能減少每秒處理目標要求所需的 GPU 數量，同時降低成本。

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

Google 建議從 Cloud Storage 下載 ML 模型，並透過 Google Cloud CLI 存取。您也可以將模型儲存在容器映像檔中，但這種方法最適合小於 10 GB 的模型。

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

以下是各選項的比較：

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

將模型儲存在 Cloud Storage

如要從 Cloud Storage 載入 ML 模型時進行最佳化，請使用Cloud Storage 磁碟區掛接，或直接使用 Cloud Storage API 或指令列，並搭配 Direct VPC，將輸出設定值設為 all-traffic，以及私人 Google 存取權。

使用 Anywhere Cache (會產生額外費用) 可在 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 程序的資源用量計入容器記憶體限制。請按照設定記憶體限制的操作說明，考慮提高容器記憶體限制。

將模型儲存在容器映像檔

將 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 費用。

從網際網路載入模型

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

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

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

在建構期間

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

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

部署期間

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

GPU worker 集區無法自動調度資源。即使 GPU 未執行任何程序，您仍須支付 GPU 費用。
工作站集區的 CPU 和記憶體計費方式與服務和作業不同。不過，GPU SKU 的價格與服務和作業相同。

在執行階段

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

系統設計層級

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