在不斷演進的大型語言模型 (LLM) 領域中，「每部機器一個模型」的部署模式，正成為企業LLM 服務成本效益的重大瓶頸。LLM 通常需要大量硬體預留空間 (例如完整的 8x H100 GPU 節點)，才能管理尖峰負載。然而，在標準作業期間，這些昂貴的資源往往未充分利用，導致總擁有成本 (TCO) 偏高。
模型共同託管可讓多個模型執行個體共用相同的虛擬機器和 GPU 資源，解決效率落差問題。包括 Llama 3 和 Gemma 3 等完全不同的模型。Vertex AI Model Garden 運用 GPU 子記憶體切片和智慧資源分割功能，將靜態硬體預留項目轉換為彈性高密度的運算集區。
這篇技術部落格詳細說明 Vertex AI 工程團隊的程序，如何將模型共同託管功能導入可供正式環境使用的雲端服務。我們將分享容器層級的實作策略方法、找出最佳服務設定，以及從大規模多模型基準研究中獲得的重要發現，協助您盡可能提高 LLM 服務的成本效益。
瞭解模型共同託管：概念和架構
模型共同託管是一種高密度服務策略，可讓多個大型語言模型 (LLM) 執行個體或不同模型架構，在單一虛擬機器 (VM) 中共用相同的實體硬體資源。與傳統部署模型不同，共同代管會使用精細的資源分割，盡可能提高硬體投資報酬率，並改善記憶體和運算資源的使用率，而傳統部署模型會將完整的 VM 或 GPU 專用於單一模型。
我們的實作重點是容器層級的解決方案，可同時提供多個模型，並採用獨立設定。這項架構透過多種整合式技術機制運作，首先是在單一容器中部署多個獨立模型伺服器執行個體。每個執行個體都是模型伺服器的完整獨立副本，因此虛擬機器可以同時處理多個要求。為管理這類流量，我們在容器中導入執行個體路由層，有效將傳入要求分配給作用中的執行個體。
這項設計可讓每個共存模型使用專屬的服務設定，並為張量平行處理 (TP)、管線平行處理 (PP) 和特定模型執行個體數量提供專屬設定，進而實現精細的平行處理。此外，系統還會進行資源切片，將特定 GPU 記憶體分割區指派給每個模型 (例如每個模型 0.4 個 GPU 記憶體分割區)，確保多種工作負載共用同一部加速器時，不會互相耗盡重要的記憶體資源。這種架構方法可將靜態硬體預留項目 (例如完整的 8 倍 H100 GPU 節點)，轉換為彈性運算集區，能夠提供各種產品組合，包括大型推理模型和小型低延遲聊天模型。
原型設計與基準研究
在開發適用於正式環境的協調器之前，我們進行了全面的基準研究，以驗證模型共同主機的理論效率。這個階段的目標是徹底測試 vLLM 的原生平行處理能力，並精確量化模型共用相同晶片時的「干擾」程度。
平行性調查：找出「交叉點」
我們初步分析的重點是 vLLM 的原生張量平行化 (TP)，以及模型執行個體的 Vertex 實作 (以多個 vLLM 伺服器執行個體的形式)，藉此判斷這些策略在不同使用者負載下的互動方式。我們發現最佳設定取決於並行程度；在並行程度較低時，高張量平行化 (例如 TP=8) 會將各層分配到所有可用的加速器，為個別要求提供最低延遲時間。不過，隨著並行流量增加，瓶頸也會轉移。如要在高負載情況下盡量提高輸送量，最佳設定會從 TP=8 轉移至 TP=4、TP=2，最終轉移至 TP=1，同時增加獨立模型執行個體的數量。這種轉移定義了「交叉點」，也就是在低 TP 設定中，減少 GPU 間通訊延遲時間的優勢，會超過高 TP 執行速度的原始速度。以下是 Gemma 2 9B IT 模型的交叉點圖表。
最佳化擴充：單一模型、多個副本
為建立嚴格的擴充性基準，我們在單一節點上對相同模型的數個執行個體進行基準測試。在流量飽和的條件下 (每個 GPU 2048 個並行要求)，在 8xH100 節點上啟動八個獨立的 vLLM 伺服器執行個體，與單一 GPU 基準相比，輸送量提升約 7.8 倍，延遲幾乎沒有回歸。
基礎架構比較：容器與 Pod 共同排程
我們進一步評估了容器層級的自動化調度管理，與原生基礎架構層級解決方案 (特別是 Pod 共排程) 的差異。雖然這兩種解決方案在多副本服務方面都能提供相近的效能，但我們最終選擇了容器層級方法，做為最簡可行產品 (MVP)。這項決策的依據是容器層級解決方案在異質共存方面提供的卓越彈性，可讓開發人員並排提供不同的模型架構，並使用不受基礎 Kubernetes 排程限制的精細軟體定義記憶體分區。此外，容器層級的自動化調度管理可大幅加快疊代速度，且更容易自訂及創新。
干擾測試：共同託管不同模型
最後一個原型里程碑是「干擾測試」，我們在同一個 VM 上共同主辦 Gemma-3n-E2B-it 和 Llama-3.1-8B-Instruct。為每個模型指派 0.4 個 GPU 記憶體分割區後，服務效能幾乎與單一模型基準保持一致。舉例來說，在共用主機環境中，Gemma-3n 的要求數為 30.21，在獨立環境中則為 30.96。這些結果證實，即使在流量大的情況下，只要適當分割記憶體資源，防止 KV 快取資源不足，共同代管的模型之間幾乎不會發生運算干擾。
MVP 容器實作
從經過驗證的基準轉移至可部署於正式環境的系統，需要設計強大的容器化協調器。這個開發階段的重點是建構高階軟體層，以管理多個模型生命週期的複雜性，同時確保資源隔離的確定性。
模型共同託管伺服器設計
實作的核心是 model_cohost_server，這是自訂進入點，旨在做為容器內的主自動調度器。這個伺服器與標準單一程序模型不同，會實作子程序管理，方便以獨立子程序的形式，並行執行多個獨立模型伺服器執行個體 (例如 vLLM)。為管理傳入的流量，自動調度器會採用高階要求路徑，透過 --served-model-name 等引數依據不重複的模型 ID 識別要求，並將要求導向對應的內部伺服器執行個體。除了路徑之外，伺服器還提供完整的生命週期自動調度，管理所有共同託管執行個體的初始化、健康狀態監控和終止作業。這種集中式管理方式可為外部流量提供單一統一的端點，同時維持每個子程序的不同運作界線。
GPU 資源分割：確定性切片
為避免單一模型的負載在共用環境中觸發記憶體不足 (OOM) 錯誤，我們導入了嚴格的資源切片機制。這是透過 gpu-memory-partition
引數運作，開發人員可定義明確的記憶體比例 (例如 0.4、0.4)，為每個個別模型執行個體保留節點總 GPU 記憶體的固定百分比。
為引導這項分配作業，我們採用「預先分配與暫時性」記憶體模型，可區分靜態和動態資源需求。「預先分配」記憶體包含模型權重和 KV 快取所用的記憶體。模型權重所用的記憶體量取決於模型的參數數量和精確度。舉例來說，BF16 中的 8B 參數模型約需 16 GB 的靜態儲存空間。KV 快取所用的記憶體量取決於模型維度、精確度、內容長度和序列數量。「暫時性」記憶體包含中間運算和推論工作記憶體。gpu-memory-partition 引數會計入「預先分配」記憶體。建議將 gpu-memory-partition 的總和設為小於 1.0，為「暫時性」記憶體保留緩衝空間。
產品化
在模型共同代管的產品化階段，我們致力於建立無縫的實際工作環境，以支援單一模型多個副本和多模型服務設定。這項轉換作業有效地將實證基準測試結果，轉化為簡化的部署工作流程，以及深度整合的基礎架構支援結構。
簡化部署工作流程
為降低高密度服務的進入門檻，我們使用自訂容器引數，將共用主機設定標準化，並與現有的 Vertex AI API 原生整合。對於全形虛擬機器 (例如 8 倍 H100 節點)，我們開發了基準公用程式，可為特定用途自訂最佳做法。這些基準公用程式可讓您根據模型的特定參數計數和精確度，找出自動平衡張量平行處理 (TP)、管線平行處理 (PP) 和模型執行個體數量的設定。此外，我們也提供強大的 Deployment API 支援，讓開發人員直接在標準 deployModel 要求中指定這些精細參數 (包括確切的 GPU 記憶體分區)，並部署模型。
動態提供多個模型
我們在技術發展歷程中取得重大進展，就是從靜態設定轉移至動態服務架構。這項功能對於流量模式快速變化的生產環境至關重要，因為必須能夠載入或卸載模型，而不必重新啟動整個容器，才能維持基礎架構的靈活度和高可用性。
動態更新 API (update_models)
為解決不可變動部署作業的固有限制，我們在 Vertex Model Garden vLLM 模型共同託管容器中，實作了專用的模型更新 API。這項 API 可促進「熱重新載入」，讓伺服器根據儲存在 Google Cloud Storage (GCS) 值區中的集中式設定檔，即時調整託管模型組合。
更新程序會透過對 update_models 端點的 POST 要求啟動，其中包含指向 GCS YAML 檔案的 model_config_path。伺服器收到這項要求後，會執行經過最佳化的多級式協調程序，盡量縮短停機時間：
- 正常卸載：系統會找出新設定中缺少的模型，並先終止其子程序，立即回收 GPU 記憶體和運算資源。
- 智慧載入和重複使用：伺服器接著會初始化新的模型執行個體。最重要的是，如果模型的平行處理設定 (例如張量平行處理 (TP) 或管道平行處理 (PP)) 和分配的記憶體分割區維持不變，協調器就會重複使用現有的執行個體。這項最佳化措施可略過成本高昂的重新初始化階段，確保在設定變更期間，現有服務不會中斷。
延遲時間和效能分析
對這些更新策略進行實證分析後，我們發現動態熱重載可大幅減輕大規模 LLM 服務常見的「冷啟動」懲罰。
結論
與 Vertex AI 共同託管模型代表基本範式轉移，從硬體密集型單體部署作業轉移至流暢且有效率的服務架構。組織擺脫「每個 VM 一個模型」的標準，改用高密度運算集區模型，就能大幅降低總持有成本 (TCO)，同時維持 (甚至提升) 效能基準。
我們的工程歷程和廣泛的多模型基準研究，已為這項架構建立明確的生產指南：
- 沒有適用於所有情況的設定。我們建議為特定用途 (模型、硬體、流量) 找出最佳服務配方，並建構相關工具。
- 使用副本擴充輸送量。
- 打破硬體界線，以更精細的層級分割記憶體，提高資源利用率。
如要成功實作共同代管架構，建議採用下列技術工作流程：
- 明確分割：使用
--gpu-memory-partitions引數，為個別模型分配記憶體資源。 - 疊代基準化：使用提供的基準公用程式，找出工作負載的特定「並行交叉」點，也就是執行個體、TP 和 PP 數量的「最佳」設定。
在 Google Cloud Model Garden 實作共同託管功能，可為建構高密度 AI 應用程式提供可擴充的藍圖。我們鼓勵開發人員探索這些功能，並使用提供的教學課程筆記本重現我們的基準，根據特定企業需求最佳化放送設定。
感謝閱讀
歡迎提供有關 Vertex AI 的意見回饋或提出問題。
特別銘謝
我們衷心感謝 Google Cloud Vertex AI 團隊。特別感謝 Bo Wu 和 Ting Yu 的領導和指導，以及 Deborah He、Shawn Ma、Desmond Liu、Yang Pan、Surya K G Tangatur 和 Luis Rizo 在這個專案中做出的寶貴貢獻。