- 使用載入速度快，且只需經過最少轉換就能成為 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 中的副本。 |
| 網際網路 | 快速、在容器啟動期間下載模型。 | 通常較簡單 (許多架構會從中央存放區下載模型)。 | 通常品質不佳且難以預測：
|
取決於模型代管服務供應商。 |
將模型儲存在容器映像檔中
將 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。啟用提示快取，並提供常見或範例提示，協助快取預熱，以供實際使用。儲存產生的輸出內容，以便在執行階段載入。
- 儲存您在建構期間產生的推論模型。相較於載入儲存效率較低的模型，並在容器啟動時套用量化等轉換，這樣做可大幅節省時間。
部署時
規劃部署作業時，請考量下列事項：
啟動探測會判斷容器是否已啟動，並準備好接受流量。設定啟動探針時，請考量下列要點：
- 啟動時間充足：讓容器 (包括模型) 有足夠的時間完成初始化及載入。
- 模型就緒狀態驗證：設定探測器，確保只有在應用程式準備好處理要求時，探測器才會通過驗證。將模型載入 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 服務都必須設定以執行個體為準的計費方式。