本文將概略說明在 GKE 上執行推論工作負載的最佳做法。
這份文件適用於資料管理員、營運人員和開發人員，可協助他們採用最佳做法，透過 Kubernetes 和 GKE 搭配 GPU 和 TPU 等加速器，執行推論工作負載。如要進一步瞭解常見角色，請參閱「常見的 GKE 使用者角色和工作」。
準備在 GKE 上提供推論服務
本節說明準備部署推論工作負載時，應遵循的基本最佳做法。這些做法包括分析應用實例、選擇模型，以及選取加速器。
分析推論用途的特徵
部署推論工作負載前，請先分析其具體需求。這項分析有助您做出架構決策，在效能、成本和可靠性之間取得平衡。瞭解用途有助於選取適當的模型、加速器和設定，以達到服務等級目標 (SLO)。
為引導分析，請評估工作負載的下列主要維度：
- 定義效能和延遲需求：決定應用程式的延遲和輸送量服務等級目標。要定義的主要指標包括每秒要求數 (RPS)、回應延遲時間、輸入和輸出權杖長度，以及前置字元快取命中率。詳情請參閱「推論效能指標」。
- 評估模型需求和規模：所選模型的特性會直接影響基礎架構需求。請考量模型支援的最大內容長度，並與工作負載需求進行比較。如果您的用例不需要最大內容，降低最大內容長度可釋出加速器記憶體，以供更大的 KV 快取使用，進而提高輸送量。
- 設定成本和業務限制：預算和業務目標是設計永續且經濟實惠的推論服務時，最重要的考量因素。定義輸入和輸出內容的目標每百萬權杖費用，以及這項工作負載的每月總預算。找出最佳化目標，例如成本效益、最低延遲時間或最高輸送量，以及應用程式是否可容許延遲時間變化。
為推論應用情境選擇合適的模型
選取合適的模型會直接影響推論應用程式的效能、成本和可行性。如要選取最佳模型，請根據下列條件評估候選模型：
- 工作和模式一致性：根據模型指定的任務和支援的模式進行評估。針對特定工作最佳化的模型，幾乎總是比一般用途模型更出色。
- 技術特性：模型的架構和資料型別精確度 (例如 FP16、FP8 和 FP4) 是決定資源需求和效能的關鍵因素。這項評估可協助您判斷是否需要套用量化技術。檢查模型權重支援的精確度、確認架構支援，並驗證模型支援的最大脈絡長度。
- 效能和成本效益：如要根據資料做出決策，請使用公開的基準和您自己的內部測試，比較入圍模型。使用 Chatbot Arena 等排行榜比較模型，並評估目標硬體上每個模型的每百萬權杖費用。
對模型套用量化
量化技術可減少模型記憶體用量，進而最佳化推論工作負載。這項技術會將模型權重、啟動和鍵值 (KV) 快取從高精確度浮點格式 (例如 FP16、FP32 和 FP64) 轉換為低精確度格式 (例如 FP8 和 FP4)。減少記憶體用量可大幅提升效能和成本效益。
量化作業可減少模型占用的記憶體空間，進而降低資料傳輸的負擔，並釋出記憶體空間，供更大的 KV 快取使用。
如要有效將量化套用至模型，請遵循下列建議：
- 評估準確度取捨：量化有時會導致模型準確度降低。評估量化準確度取捨時，請考量 8 位元量化通常只會造成極小的準確度損失。相較之下，4 位元量化最多可減少四倍的加速器記憶體需求，但與 8 位元量化相比，準確度損失可能也較大。 評估量化模型在特定用途上的效能，確保準確度仍可接受。如要評估準確率損失，可以使用 OpenCompass 和 Language Model Evaluation Harness 等工具。
- 評估硬體加速支援：如要充分發揮量化效果，請使用可為量化模型使用的資料格式提供硬體加速的加速器。例如：
- NVIDIA H100 GPU 可為 FP8 和 FP16 作業提供硬體加速功能。
- NVIDIA B200 GPU 可為 FP4、FP8 和 FP16 作業提供硬體加速功能。
- Cloud TPU v5p 可為 FP8 運算提供硬體加速功能。
- 檢查是否有預先量化的模型：自行量化模型前，請先檢查 Hugging Face 等公開模型存放區。理想情況下，請尋找以較低精確度原生訓練的模型，因為這樣做可提升效能，且不會因訓練後量化而可能降低準確率。
- 使用量化程式庫：如果沒有預先量化的模型，請使用程式庫自行執行量化。vLLM 等推論伺服器支援執行以各種技術量化的模型。您可以使用 llm-compressor 等工具，將量化技術套用至非量化模型。
- 考慮 KV 快取量化：除了量化模型權重，您也可以量化 KV 快取。這項技術可進一步減少執行階段 KV 快取所需的記憶體，進而提升效能。
詳情請參閱「在 GPU 上最佳化 LLM 推論工作負載」。
選擇合適的加速器
選取合適的加速器會直接影響推論服務的效能、成本和使用者體驗。最佳選擇取決於模型記憶體需求、效能目標和預算的分析結果。
如要根據特定用途選擇合適的加速器，請按照下列步驟操作：
計算記憶體需求：首先，請計算載入及執行模型所需的最低加速器記憶體。總記憶體是模型權重、推論引擎負荷、中繼啟用和 KV 快取所需的記憶體總和。
如要估算所需記憶體，請使用下列方程式：
\[ \begin{aligned} \text{Required accelerator memory} = {} & (\text{Model weights} + \text{Overhead} + \text{Activations}) \\ & + (\text{KV cache per batch} \times \text{Batch size}) \end{aligned} \]
方程式中的各項如下：
- 模型權重：模型參數的大小。
- 額外負荷：推論伺服器和其他系統額外負荷的緩衝區，通常為 1 到 2 GB。
- 啟用：模型執行期間，中間啟用所需的記憶體。
- 每個批次的 KV 快取：單一序列的 KV 快取所需記憶體，會隨著脈絡長度和模型設定而擴充。
- 批次大小：推論引擎將同時處理的序列數 (
max_num_sequences)。
範例：計算 Gemma 3 的加速器記憶體需求
如要計算部署 Gemma 3 270 億參數模型所需的加速器記憶體，以 BF16 精確度用於文字生成用途，可以使用下列值。
如需這項計算的互動式逐步說明，請參閱「我的模型需要多少 VRAM？」Colab 筆記本。
- 輸入：
- 模型權重：54 GB
- 批次大小 (
max_num_sequences)：1 - 平均輸入長度：1,500 個權杖
- 平均輸出長度：200 個權杖
- 推論引擎額外負荷：1 GB (估計值)
- KV 快取資料類型大小：2 (適用於 BF16)
- KV 向量：2 個 (一個用於鍵，一個用於值)
- Gemma 3 27B 指令微調模型的模型設定：
hidden_size: 5376intermediate_size：21504num_attention_heads: 32num_hidden_layers: 62num_key_value_heads: 16
- 記憶體計算：
sequence_length=avg_input_length+avg_output_length= 1500 + 200 = 1700 個權杖pytorch_activation_peak_memory= (max_num_sequences*sequence_length* (18 *hidden_size+ 4 *intermediate_size)) / (1000^3) = ~0.31 GB (估計值)。head_dims=hidden_size/num_attention_heads= 5376 / 32 = 168kv_cache_memory_per_batch= (kv_vectors*max_num_sequences*sequence_length*num_key_value_heads*head_dims*num_hidden_layers*kv_data_type_size) / (1000^3) = (2 * 1 * 1700 * 16 * 168 * 62 * 2) / (1000^3) = ~1.13 GB- 所需加速器記憶體 =
Model weights+Overhead+Activations+KV cache per batch= 54 + 1 + 0.31 + 1.13 = ~56.44 GB
部署模型所需的預估加速器記憶體總量約為 57 GB。
評估加速器選項：預估記憶體需求後，請評估 GKE 上可用的 GPU 和 TPU 選項。
除了加速器記憶體容量外，也請考慮下列模型評估需求：
- 如果模型需要多個加速器，請檢查是否支援 NVLINK 和 GPUDirect 等高速連線，以減少通訊延遲。
- 對於量化模型，請使用具有原生硬體加速功能的加速器，處理 FP8 和 FP4 等低精確度資料型別，盡可能提升效能。
選擇時，請權衡這些功能、效能、成本和可用性。
不同用途的建議加速器
提示：如要根據服務效能基準和成本分析取得最新的加速器建議，也可以使用 GKE Inference Quickstart 工具。詳情請參閱 GKE 推論快速入門導覽課程說明文件。 為協助您為工作負載選擇合適的加速器，下表列出常見推論用途最適合的選項。這些用途的定義如下：
- 小型模型推論：適用於參數數十億的模型，運算負載僅限於單一主機。
- 單一主機大型模型推論：適用於參數數十億到數千億的模型，這類模型的運算負載會由單一主機上的多個加速器分攤。
- 多主機大型模型推論：適用於參數量達數千億到數兆的模型，這類模型會將運算負載分散到多部主機的多個加速器。
用途 建議使用的加速器 機器系列 主要特徵 小型模型推論 NVIDIA L4 G2 適合小型模型，經濟實惠 (每個 GPU 24 GB 記憶體)。 NVIDIA RTX Pro 6000 G4 對於參數少於 300 億的模型和圖片生成作業而言，這項服務經濟實惠 (每個 GPU 96 GB 記憶體)。支援直接 GPU 對等互連通訊，因此適合單一主機的多 GPU 推論。 TPU v5e - 成本效益最高。 TPU v6e - 為 Transformer 和文字轉圖像模型提供最高價值。 單一主機大型模型推論 NVIDIA A100 A2 適用於大多數可裝載在單一節點上的模型 (總記憶體容量上限為 640 GB)。 NVIDIA H100 A3 適合用於可容納單一節點的推論工作負載 (總記憶體最多 640 GB)。 NVIDIA B200 A4 適合單一節點上需要大量資源的模型 (總記憶體最高可達 1,440 GB)，可因應未來需求。 TPU v4 - 在費用和效能之間取得良好平衡。 TPU v5p - 適合嚴苛工作負載的高效能選項。 多主機大型模型推論 NVIDIA H200 A3 Ultra 適用於大型、耗用大量記憶體的模型 (總記憶體最高可達 1,128 GB)。 NVIDIA B200 / GB200 A4 / A4X 適合要求最嚴苛、需要大量運算資源，以及受網路限制的工作負載。A4X 機器使用 Arm 架構 CPU，如果工作負載使用 x86 專屬功能或最佳化項目，可能需要重構工作負載 (程式碼變更超出簡單的容器重建)。 TPU v5e - 針對中型到大型 LLM 服務的成本效益和效能進行最佳化。 TPU v5p - 適用於需要大規模平行化的多主機推論作業，效能優異。 TPU v6e - 針對 Transformer、文字轉圖片和 CNN 服務進行最佳化。 示例：為 260 GB 的模型選擇加速器
假設您需要部署的模型總共需要 260 GB 的加速器記憶體 (模型需要 200 GB、KV 快取需要 50 GB，以及額外負荷需要 10 GB)。
光是根據記憶體需求，您就可以排除 NVIDIA L4 GPU，因為最大的 G2 機器最多提供 192 GB 的加速器記憶體。此外，由於 L4 GPU 不支援加速器之間的高速低延遲連線，因此無法將工作負載分配到多個節點，以達到所需效能。
如要避免重構 x86-64 工作負載 (也就是修改程式碼，讓程式碼能在不同類型的處理器上執行)，您也需要排除使用 Arm 架構 CPU 的 NVIDIA GB200 和 GB300 加速器。
因此，您有下列選項：
- NVIDIA A100
- NVIDIA RTX Pro 6000
- NVIDIA H100
- NVIDIA H200
- NVIDIA B200
所有這些加速器都有足夠的記憶體。下一步是評估這些功能在目標區域的適用情形。假設您發現特定區域僅提供 NVIDIA A100 和 NVIDIA H100 GPU。比較這兩個選項的成本效益比後，您可能會選擇 NVIDIA H100 來處理工作負載。
多執行個體 GPU
如要提高 GPU 使用率並節省 GPU 費用，可以使用多執行個體 GPU 設定。透過這項設定，您可以分割支援的 GPU，讓 GKE 上的多個容器共用一部 GPU。佈建多執行個體 GPU 時，只能將完整 GPU 附加至 GKE 節點，且須遵守相應的 GPU 定價。建議您只對可信任的工作負載使用多例項 GPU。
舉例來說，您可以附加 NVIDIA RTX PRO 6000，然後執行下列操作：
- 將其分割為四個執行個體 (每個執行個體提供 24 GB 的加速器記憶體)，並執行擴散模型或小型模型推論工作負載，例如約有 80 億個參數的模型，並使用 FP16 資料格式精確度來計算模型權重。與 NVIDIA L4 相比，這個分割區的成本效益比可能較高。
- 將其分割為兩個執行個體 (每個執行個體提供 48 GB 的加速器記憶體)，並執行小型模型推論工作負載，例如約有 150 億個參數的模型，並使用 FP16 資料格式精確度來計算模型權重。這個分割區可做為在 NVIDIA A100 40 GB GPU 上執行推論工作負載的替代方案。
詳情請參閱「執行多執行個體 GPU」。
詳情請參閱 Compute Engine 說明文件中的「GPU 機器類型」和「加速器最佳化機器家族」。
選取推論分配策略：如果模型過大，無法使用單一加速器，請根據工作負載需求選取分配策略。
首先，請根據硬體拓撲選擇分配策略：
- 單一加速器：如果模型適用於單一加速器，這是最簡單且建議的方法。
- 單一節點、多個加速器：如果模型適合使用單一節點搭配多個加速器，您可以運用張量平行化，將模型分配到該節點的加速器。
- 多節點、多加速器：如果模型過大，無法在單一節點上執行，您可以結合張量和平行管線，將模型分配到多個節點。
如要實作這些策略，可以使用下列平行處理技巧：
張量平行化：這項技術會將模型的層級分散到多個加速器。在具有 NVLINK 或直接對等互連 PCIe 等高速互連網路的單一節點中，這項技術非常有效，但需要加速器之間進行大量通訊。
範例：張量平行化
舉例來說，假設您需要部署含有 1090 億個參數的模型。以預設的 BF16 (16 位元) 精度來說，將模型權重載入加速器記憶體約需 113 GB。單一 NVIDIA H100 GPU 可提供 80 GB 的記憶體。因此，即使不考慮 KV 快取等其他記憶體需求，您也需要至少兩個 NVIDIA H100 GPU，才能載入模型 (使用張量平行處理大小為 2)。
管道平行化：這項技術會將模型的分層依序劃分到多個節點。這項技術非常適合在多主機部署作業中，將模型分配到多個節點，而且模型等級之間的通訊量比張量平行處理少。
範例：混合式平行處理 (張量和平行管道)
如果模型非常龐大，參數超過 6, 000 億個，記憶體需求可能會超過 1.1 TB。在有兩個
a3-megagpu-8g節點 (各搭載八個 NVIDIA H100 GPU) 的情況下，叢集總共會有 1.28 TB 的加速器記憶體。如要執行模型，您可以實作混合策略：每個節點內採用 8 向張量平行處理，兩個節點之間採用 2 向管道平行處理。模型會分成兩個階段，第一半的層位於第一個節點，第二半則位於第二個節點。要求抵達時，第一個節點會處理要求，並透過網路將中繼資料傳送至第二個節點，完成運算。
如需為單一模型副本選擇分散式推論策略的更多指南，請參閱 vLLM 說明文件中的「平行處理和縮放」。
選取加速器最佳化機型：根據您選擇的加速器和所需數量，選取提供這些資源的機型。每個機器類型都提供特定組合的 vCPU、系統記憶體和網路頻寬，這些組合也會影響工作負載的效能。舉例來說，如果您需要 16 個 NVIDIA H100 GPU，請選取
a3-megagpu-16g機器類型。執行自己的基準測試：推論工作負載的效能高度取決於特定用途。執行自己的基準測試，驗證所選項目並微調設定。
最佳化推論伺服器的設定
如要部署推論工作負載並發揮最佳效能，建議您進行基準化和調整週期：
- 請先參閱 GKE 推論快速入門指南，取得適用於您用途的最佳化基準 Kubernetes 設定。
- 執行基準測試，擷取基準處理量和延遲時間指標。
- 調整推論伺服器的設定。
- 再次執行基準測試，並比較結果來驗證變更。
以下建議是以 vLLM 推論伺服器為基礎，但這些原則也適用於其他伺服器。如需所有可用設定的詳細指南，請參閱「vLLM 最佳化和微調」說明文件：
- 設定平行處理：
- 張量平行化 (
tensor_parallel_size)：將此值設為單一節點上的加速器數量，即可將工作負載分片。舉例來說，設定tensor_parallel_size=4會將工作負載分配到四個加速器。請注意，增加這個值可能會導致過多的同步處理負擔。 - 管線平行處理 (
pipeline_parallel_size)：將此值設為要分配模型的節點數量。舉例來說，如果您要部署到兩個節點，每個節點有八個加速器，則應設定tensor_parallel_size=8和pipeline_parallel_size=2。增加這個值可能會導致延遲懲罰。
- 張量平行化 (
- 調整 KV 快取 (
gpu_memory_utilization)：這個參數可控制為模型權重、啟用和 KV 快取保留的 GPU 記憶體百分比。值越大，KV 快取大小就越大，可提升輸送量。建議將此值設為介於0.9和0.95之間。如果遇到記憶體不足 (OOM) 錯誤，請調低這個值。 - 設定背景資訊長度上限 (
max_model_len)：如要減少 KV 快取大小和記憶體需求，您可以將背景資訊長度上限設為低於模型的預設值。這樣您就能使用較小且更具成本效益的 GPU。 舉例來說，如果您的用途只需要 40,000 個權杖的內容，但模型預設為 256,000 個，將max_model_len設為 40,000 即可釋出記憶體，用於更大的 KV 快取，進而提高處理量。 - 設定並行要求數量 (
max_num_batched_tokens、max_num_seqs)：調整 vLLM 同時處理的要求數量上限，避免 KV 快取空間不足時發生搶占。max_num_batched_tokens和max_num_seqs的值越低，記憶體需求就越少，但值越高，就越有可能發生 OOM 錯誤，不過輸送量也會隨之提升。如要找出最佳值，建議您執行效能實驗，並觀察 vLLM 匯出的 Prometheus 指標中，搶占要求數量。
詳情請參閱下列資源：
- 如要深入瞭解如何調整這些參數，請參閱「vLLM Performance Tuning: The Ultimate Guide to xPU Inference Configuration」。
- 如需模型記憶體最佳化的更多指引，請參閱「Best practices for optimizing large language model inference with GPUs on GKE」(最佳做法：在 GKE 上使用 GPU 最佳化大型語言模型推論)。
- 如需可部署的完整範例，請參閱 GKE 推論參考實作。
針對延遲和可用性進行最佳化
為確保推論服務的回應速度和可靠性，您必須盡量縮短啟動延遲時間，並提高資源可用性。
縮短推論工作負載的冷啟動延遲時間
盡量縮短推論工作負載的啟動時間，對於提升成本效益和使用者體驗至關重要。冷啟動延遲時間短，叢集就能快速擴充，滿足需求，確保服務回應迅速，同時盡量減少昂貴的過度佈建。
縮短 Pod 啟動時間
Pod 準備就緒所需的時間，主要取決於提取容器映像檔和下載模型權重的時間。如要同時提升這兩項指標，請考慮採用下列策略：
使用最佳化資料載入器加快模型載入速度：您用來儲存及載入模型權重的方法，會對啟動時間造成重大影響。如果是 vLLM 0.10.2 以上版本，建議使用 Run:ai Model Streamer，直接從 Cloud Storage bucket 串流載入模型。
如果串流器不適用於您的用途，可以使用 Cloud Storage FUSE 掛接 Cloud Storage 值區，並啟用階層式命名空間，以及使用平行下載和預先擷取等技術，調整串流器效能。如要進一步瞭解這些技術，請參閱「針對 GKE 效能最佳化 Cloud Storage FUSE CSI 驅動程式」。無論是哪種情況，我們都建議使用「任何位置」快取，為值區建立高效能的區域讀取快取，並啟用統一值區層級存取權，統一控管值區存取權。
如果您已使用 Managed Lustre 為訓練工作負載提供高效能檔案儲存空間，也可以使用這項服務載入模型權重以進行推論。如果資料位置和 POSIX 相容性至關重要，這種做法可提供低延遲存取。
啟用映像檔串流：如要縮短提取容器映像檔的時間，請在 GKE 叢集上啟用映像檔串流。有了映像檔串流，容器不必等待整個映像檔下載完畢即可啟動，進而大幅縮短 Pod 啟動時間。
啟用快速啟動節點
對於需要快速擴充的工作負載，您可以善用 GKE 中的快速啟動節點。快速啟動節點是預先初始化的硬體資源，啟動時間比標準節點短得多。如果叢集符合需求，GKE 會自動啟用快速啟動節點。
規劃容量並盡量取得加速器
GPU 和 TPU 等熱門加速器可能供不應求，因此主動制定容量規劃策略至關重要。
規劃及預留容量
高需求量的加速器供應量可能有限，因此主動規劃容量策略至關重要。為確保能存取所需資源，請遵循下列建議：
判斷處理基準和尖峰流量的容量：規劃需要預留的基準加速器容量。預留金額取決於您的用途。舉例來說，您可以為不容許延遲的重要工作負載預留 100% 的必要容量，也可以預留特定百分位數 (例如第 90 或 95 個百分位數)，並視需要取得其餘容量來處理尖峰流量。
預留基準容量：如要確保取得資源，請建立預留項目。 您可以根據需求選擇預訂類型。舉例來說，如要在特定未來時間範圍內預留加速器等需求量高的資源，可以在日曆模式中建立未來預留項目。
協調尖峰時段的容量：如果需求量超出基準預訂量，您可以實作備援策略，使用其他容量類型，例如隨選、Spot VM 或 Dynamic Workload Scheduler (DWS)。您可以使用自訂運算類別，為佈建不同容量類型定義優先順序，自動執行這項備援策略。
享有折扣價：購買承諾使用折扣 (CUD)，即可享有基準容量的折扣價。只要承諾使用一年或三年，就能享有大幅折扣。
如果工作負載可容許延遲取得運算資源，請搭配使用 Dynamic Workload Scheduler 和彈性啟動佈建模式
如果工作負載可容許取得運算資源時出現延遲，則可使用動態工作負載排程器 (DWS) 搭配彈性啟動佈建模式，以折扣價取得加速器。DWS 可讓您排隊等候最多七天的運算資源要求。
使用彈性啟動佈建模式的 DWS 時，建議採取下列做法：
- 納入自訂運算類別：使用自訂運算類別定義 DWS，做為取得容量的優先備援策略。
- 設定最長執行時間：
maxRunDurationSeconds參數會設定透過 DWS 要求的節點最長執行時間。將此值設為低於預設的七天，可提高取得所要求節點的機率。 - 啟用節點回收：為避免工作負載發生停機情形，請啟用節點回收功能。這項功能會在舊節點過期前開始佈建新節點，確保轉換過程更加順暢。
- 減少中斷：如要盡量減少節點逐出和升級作業造成的中斷，請設定維護期間和排除時段、停用節點自動修復功能，並採用短期升級策略。
使用自訂運算類別
自訂運算類別 (CCC) 是 GKE 的一項功能，可讓您為工作負載定義基礎架構設定的優先順序清單。CCC 提供的主要功能旨在提升加速器取得能力：
- 備援運算優先順序：您可以定義優先順序清單。如果在擴充事件期間無法使用偏好的選項，自動調度器會自動改用清單中的下一個選項，大幅提高成功取得容量的可能性。
- 主動遷移至優先順序較高的節點：設定這項功能後，GKE 會在優先順序較高的設定可供使用時，自動將在優先順序較低的設定上執行的節點，替換為優先順序較高的設定。這有助於確保 Pod 最終會在您最偏好 (通常也是最具成本效益) 的節點上執行。
透過自訂運算類別 (CCC)，您可以建立節點取得作業的回退策略。這項策略會使用不同容量類型的優先順序清單，例如隨選 VM、Spot VM 或預留項目。這些容量類型各有不同的可用性等級：
- 預留項目：可確保您取得容量。使用 CCC 消耗預留項目時，請考量相關限制。舉例來說，部分預訂類型會限制可預訂的機器類型，或可要求的機器數量上限。
- 隨需：標準佈建模式，提供彈性，但高需求資源可能受限於區域容量。
- Spot VM：以較低的價格使用備用容量，但可能會遭到先占。發生先占事件時，GKE 會盡量為受影響的 Pod 提供最長 30 秒的終止寬限期。如要善用這項功能，請實作檢查點和重試機制，確保工作負載能容許搶占事件。
- Dynamic Workload Scheduler (DWS)：可讓您以折扣價將稀少資源的要求加入佇列。這項功能非常適合可容許容量取得延遲的工作負載。
優先順序清單的順序應會變更，視主要目標是盡量減少延遲時間，還是盡量降低成本而定。舉例來說，您可以針對不同的工作負載需求設定下列優先順序清單：
| 優先順序 | 低延遲工作負載 | 成本最佳化 (可容許延遲) 工作負載 |
|---|---|---|
| 1 | 預訂 (特定，然後任何) | 預訂 (特定，然後任何) |
| 2 | 隨選 | Spot VM |
| 3 | Spot VM | 動態工作負載排程器 |
| 4 | 動態工作負載排程器 | 隨選 |
對於低延遲用途，系統會優先處理預留容量，其次才是隨選容量，因為隨選容量會快速回報容量不足，讓 CCC 迅速回溯至下一個選項。
對於成本最佳化用途，系統會優先使用預留項目，然後是 Spot VM 和彈性啟動 DWS，以降低成本。隨選容量會做為最終備用選項。
設定 GKE 叢集和節點集區的位置政策
叢集自動配置器的位置政策可控管 GKE 在擴充事件期間，如何跨區域分配節點。使用自訂運算級別時，這項設定特別重要，因為叢集自動調度器會先考量這項設定，再套用 CCC 的優先順序清單。
如要提高取得加速器的機率，請根據工作負載需求設定位置政策：
location-policy=ANY：優先取得容量，而非在各區域平均分配節點。如果 CCC 包含 Spot VM 或可用性不穩定的機型，這項設定就特別重要，因為ANY可讓叢集自動調度器選擇最有可能滿足 CCC 優先節點類型的可用區。您也可以使用這項設定，優先使用未使用的預留項目。使用這項政策時，建議您先從num-nodes=0開始，讓叢集自動配置器在尋找容量時，能有最大的彈性。location-policy=BALANCED：嘗試在所有可用區域平均分配節點。如果工作負載使用的資源容易取得，且您想維持區域備援以確保高可用性，請使用這項政策。
您可以在建立或更新節點集區時設定這項設定。
提高效率並節省成本
只要仔細監控加速器並智慧調度工作負載，就能大幅減少浪費並降低營運成本。
觀察加速器和推論伺服器
如要瞭解推論工作負載的效能和使用率，就必須制定完善的可觀測性策略。GKE 提供一系列工具，協助您監控加速器和推論伺服器：
- 監控 NVIDIA GPU 的 DCGM 指標：如要監控 NVIDIA GPU 的健康狀態和效能，請將 GKE 設定為將 NVIDIA Data Center GPU Manager (DCGM) 指標傳送至 Cloud Monitoring。
- 啟用自動監控應用程式功能：如要簡化推論伺服器的監控程序，請在 GKE 中啟用自動監控應用程式功能。
- 使用 OpenTelemetry 檢測工作負載：對於自動應用程式監控功能不支援的工作負載，請使用 OpenTelemetry 收集自訂指標和追蹤記錄。
自動調度 Pod 資源
為確保推論工作負載能配合需求變化動態調整，請使用水平 Pod 自動調度資源 (HPA) 自動調度 Pod 數量。對於推論工作負載，請務必根據直接反映推論伺服器負載的指標，而非標準 CPU 或記憶體指標，做出資源調度決策。
如要為推論工作負載設定自動調度資源功能，建議您採取下列做法：
根據推論感知指標設定 HPA：為獲得最佳效能，請根據推論伺服器的指標設定 HPA，以調整資源配置。最佳指標取決於您是想盡量縮短延遲時間，還是提高總處理量。
對於延遲時間敏感的工作負載，您有兩種主要做法：
- KV 快取利用率 (例如
vllm:gpu_cache_usage_perc)： 這項指標通常是即將出現延遲尖峰的最佳指標。 KV 快取使用率高表示推論引擎即將達到容量上限。HPA 可使用這項信號預先新增副本，維持穩定的使用者體驗。 - 執行中的要求數量 (批次大小) (例如
vllm:num_requests_running)：這項指標與延遲時間直接相關，因為批次大小越小，延遲時間通常就越短。不過，使用這項指標自動調度資源可能會有困難，因為要盡量提高處理量，取決於傳入要求的大小。您可能需要選擇低於最大可能批次大小的值，確保 HPA 適當擴充。
- KV 快取利用率 (例如
對於處理量敏感的工作負載，請根據佇列大小 (例如
vllm:num_requests_waiting) 進行調整。這項指標可直接測量待處理工作數量，並以簡單明瞭的方式，根據傳入需求調整處理容量。由於這項指標只會考量等待中的要求，不會考量目前正在處理的要求，因此與根據批次大小進行擴充相比，這項指標可能無法達到最低延遲。
設定最少備用資源數：為確保服務持續可用，並提供基本的使用者體驗，請務必為推論部署作業設定最少備用資源數。
啟用效能 HPA 設定檔：在 1.33 以上版本的 GKE 中，符合資格的叢集預設會啟用效能 HPA 設定檔，以縮短 HPA 的反應時間。
詳情請參閱「在 GPU 上為 LLM 工作負載設定 HPA」和「在 TPU 上自動調整 LLM 推論工作負載」。
讓資料更接近工作負載
工作負載載入資料 (例如模型權重) 所需的時間，可能會造成延遲。將資料移至靠近運算資源的位置，即可縮短資料傳輸時間，並提升整體效能。
- 使用 Anywhere Cache 建立區域性讀取快取：如果您使用 Cloud Storage 儲存 AI/機器學習工作負載的資料，請啟用 Anywhere Cache。Anywhere Cache 會為 Cloud Storage bucket 建立高效能的區域讀取快取。
- 在本機 SSD 上快取經常存取的資料：對於需要極低延遲時間存取臨時資料的工作負載，請使用本機 SSD 做為高效能快取。使用本機 SSD 做為低延遲的暫時儲存空間，存放常用資料，有助於大幅縮短加速器等待 I/O 作業完成的時間，進而減少加速器等昂貴資源的閒置時間。請注意，並非所有機器系列都支援本機 SSD，這可能會影響您選擇的加速器。
- 使用 GKE Data Cache 管理快取：如果工作負載經常從永久磁碟讀取資料，請啟用 GKE Data Cache。GKE 資料快取會使用本機 SSD，為永久磁碟建立代管的高效能快取。對於大多數實際工作負載，我們建議使用
Writethrough模式，將資料同步寫入快取和基礎持續性磁碟，避免資料遺失。
針對進階資源調度架構進行最佳化
為滿足大規模或全球分散式應用程式的需求，您可以採用進階的擴充架構，提升效能、可靠性和流量管理。
使用 GKE 推論閘道進行負載平衡
如要處理單一叢集中的推論工作負載，建議使用 GKE 推論閘道。推論閘道是 AI 感知負載平衡器，可監控推論指標，並將要求轉送至最合適的端點。這項功能可提升效能和加速器使用率。
使用 GKE Inference Gateway 時，建議您遵循下列最佳做法：
- 將提供服務的 Pod 分組到
InferencePool：為每個提供推論工作負載服務的 Pod 群組定義InferencePool。詳情請參閱「自訂 GKE Inference Gateway 設定」。 - 多工處理延遲時間關鍵工作負載：定義
InferenceObjectives來指定模型的服務屬性，例如名稱和優先順序。GKE Inference Gateway 會優先處理優先順序較高的工作負載，讓您多工處理延遲時間關鍵和延遲時間容許的工作負載，並在流量過大時實作負載卸除政策。 - 使用模型感知轉送：如要根據要求主體中的模型名稱轉送要求，請使用以主體為準的轉送。使用主體式轉送時，請確保後端具有高可用性。 如果擴充功能無法使用，閘道會傳回錯誤，避免要求錯誤地轉送。
- 允許閘道自動分配流量：
GKE Inference Gateway 會監控
InferencePool中推論伺服器的重要指標，例如 KV 快取使用率、佇列長度和前置字串快取索引，然後據此智慧地將流量導向推論伺服器。相較於傳統方法，這種即時負載平衡機制可最佳化加速器使用率、縮短尾端延遲，並提高整體輸送量。 - 與 Apigee 和 Model Armor 整合：如要提升安全性和管理效率，請與 Apigee 整合來管理 API，並與 Model Armor 整合來進行安全檢查。
在多個節點上部署推論工作負載
如果模型非常大，無法放在單一節點上，您需要將推論工作負載分配到多個節點。這需要盡量減少節點間通訊延遲的架構，並確保分散式工作負載的所有元件都以單一單元的形式管理。
請考慮以下最佳做法：
盡量提高加速器網路頻寬和輸送量：工作負載分散到多個節點時，網路會成為影響效能的重要因素。如要盡量縮短節點間的通訊延遲時間，請使用 NVIDIA GPUDirect 等高效能網路技術。您可以根據叢集規模和工作負載所需的通訊強度，選擇下列選項：
- GPUDirect-TCPX：適用於在 A3 High 上執行的各種多節點推論工作負載。
- GPUDirect-TCPXO：可提供更強大的卸載和更高的頻寬，因此效能更佳，與標準 TCPX 相比，這項功能對較大的叢集更有利，且可在 A3 Mega 機器上執行。
- GPUDirect RDMA：可讓不同節點的 GPU 之間直接存取記憶體，略過 CPU，提供最高節點間頻寬和最低延遲，最適合在 A3 Ultra 和 A4 機器上執行大規模推論作業。
如需詳細資訊，請參閱：
如要驗證多節點網路設定是否正常運作，建議您使用 NVIDIA Collective Communications Library (NCCL) 等工具執行測試。
使用 LeaderWorkerSet 管理分散式工作負載：部署有狀態的分散式工作負載 (例如多節點推論服務) 時，請務必將所有元件視為單一單元進行管理。如要執行這項操作，請使用 LeaderWorkerSet，這是 Kubernetes 原生 API，可讓您將一組相關 Pod 管理為單一實體。LeaderWorkerSet 可確保集合中的所有 Pod 會一起建立及刪除，這對維護分散式工作負載的完整性至關重要。
使用密集配置模式，將節點放在實體上相近的位置：分散式工作負載中節點之間的實體距離，可能會對節點間的網路延遲造成重大影響。如要盡量減少延遲，請為 GKE 節點集區使用密集配置政策。密集配置方式政策會指示 GKE，盡可能將節點集區中的節點配置在同一個可用區內，且彼此在實體位置上相近。
在多個區域部署推論工作負載
對於需要高可用性和低延遲的全球分散式應用程式，跨多個區域部署推論工作負載是重要的最佳做法。多區域架構可協助您提高可靠性、改善加速器取得能力、減少使用者感受到的延遲，以及符合特定地點的法規要求。
如要有效部署及管理多區域推論服務，請按照下列建議操作：
- 在您預留容量或預期需要容量來處理尖峰負載的多個區域中，佈建 GKE 叢集。
- 為模型權重選擇合適的儲存策略。如要提升作業效率，請建立多區域 Cloud Storage 值區。如要盡量降低成本，請在每個地區建立區域 bucket，並複製模型權重。
- 使用 Anywhere Cache 為 Cloud Storage 值區建立區域讀取快取，藉此減少網路延遲和資料輸出費用。
最佳做法摘要
下表摘要說明本文建議的最佳做法：
| 主題 | 工作 |
|---|---|
| 部署和設定 |
|
| 冷啟動延遲 |
|
| 容量規劃和加速器取得能力 |
|
| 資源和加速器效率 |
|
| 負載平衡 |
|
| 多節點部署 |
|
| 多區域部署 |
|
後續步驟
- 請參閱 GKE 推論參考架構。