本文概略說明在 GKE 執行推論工作負載的最佳做法。
本文適用對象為資料管理員、營運人員和開發人員，旨在協助他們採用最佳做法，在 Kubernetes 和 GKE 中使用 GPU 和 TPU 等加速器，處理推論工作負載。如要進一步瞭解常見角色，請參閱「常見的 GKE 使用者角色和工作」。
如要查看所有 GKE 最佳做法的整合總覽，請參閱「GKE 最佳做法」。準備在 GKE 上提供推論服務
本節說明準備部署推論工作負載時，應遵循的基本最佳做法。這些做法包括分析應用實例、選擇模型和選取加速器。
分析推論用途的特徵
部署推論工作負載前，請先分析其特定需求。這項分析有助於您做出架構決策，兼顧效能、成本和可靠性。瞭解用途有助於選取合適的模型、加速器和設定，以達成服務水準目標 (SLO)。
為引導分析，請評估工作負載的下列重要面向：
- 定義效能和延遲時間需求：決定應用程式的延遲時間和處理量服務等級目標。需要定義的主要指標包括每秒要求數 (RPS)、回應延遲時間、輸入和輸出詞元長度，以及前置字元快取命中率。詳情請參閱「推論成效指標」。
- 評估模型需求和規模：所選模型的特性會直接影響基礎架構需求。請考量模型支援的最大脈絡長度，並與工作負載的需求進行比較。如果您的用途不需要最大脈絡，降低最大脈絡長度可釋出加速器記憶體，用於更大的 KV 快取，進而提高處理量。
- 確立成本和業務限制：預算和業務目標是設計永續且符合成本效益推論服務的關鍵因素。定義輸入和輸出的目標每百萬個詞元費用，以及這項工作負載的每月總預算。找出最佳化目標，例如成本效益、最低延遲時間或最高處理量，以及應用程式是否能容許延遲時間變動。
為推論用途選擇合適的模型
選擇合適的模型會直接影響推論應用程式的效能、成本和可行性。如要選出最佳模型，請根據下列條件評估候選模型：
- 任務和模態對齊：根據模型指定的任務和支援的模態進行評估。針對特定工作最佳化的模型，效能幾乎總是優於一般用途模型。
- 技術特性：模型的架構和資料類型精確度 (例如 FP16、FP8 和 FP4) 是決定資源需求和效能的關鍵因素。這項評估可協助您判斷是否需要套用量化技術。檢查模型權重支援的精確度、確認框架支援，並驗證模型支援的最大脈絡長度。
- 效能和成本效益：如要根據資料做出決策，請使用公開基準和內部測試，比較入圍的模型。使用 Chatbot Arena 等排行榜比較模型，並評估各模型在目標硬體上的每百萬個詞元費用。
對模型套用量化
量化技術可減少模型的記憶體用量，進而最佳化推論工作負載。這項技術會將模型的權重、啟用值和鍵/值 (KV) 快取，從高精度浮點格式 (例如 FP16、FP32 和 FP64) 轉換為低精度格式 (例如 FP8 和 FP4)。減少記憶體用量可大幅提升效能和成本效益。
量化可減少模型的記憶體用量，進而降低資料移轉負擔，並釋出記憶體，用於更大的 KV 快取。
如要有效對模型套用量化，請遵循下列建議：
- 評估準確度取捨：量化有時會導致模型準確度降低。評估量化對準確度的影響時，請考量 8 位元量化通常只會造成極小的準確度損失。相較之下，4 位元量化最多可將加速器記憶體需求降低四倍，但與 8 位元量化相比，準確度損失可能更大。評估量化模型在特定用途的效能，確保準確度仍在可接受的範圍內。如要評估準確度損失，可以使用 OpenCompass 和語言模型評估工具等工具。
- 評估硬體加速支援：如要充分發揮量化功能，請使用可為量化模型所用資料格式提供硬體加速的加速器。例如：
- 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} \]
方程式中的各項如下：
- 模型權重：模型參數的大小。
- Overhead：推論伺服器和其他系統負擔的緩衝區，通常為 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 Inference Quickstart 說明文件。 為協助您選擇適合工作負載的加速器，下表列出常見推論用途最適合的選項。這些用途的定義如下：
- 小型模型推論：適用於參數數量達數十億的模型，運算負載僅限於單一主機。
- 單一主機大型模型推論：適用於參數量達數百億到數千億的模型，運算負載會分配給單一主機上的多個加速器。
- 多主機大型模型推論：適用於參數量達數千億到數兆的模型，運算負載會分配給多部主機上的多個加速器。
用途 建議的加速器 機器系列 主要特色 小型模型推論 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 / GB300 / Vera Rubin NVL72 A4 / A4X / A4X Max / A5X 適合要求最嚴苛、運算密集且受網路限制的工作負載。A4X、A4X Max 和 A5X 機器使用 Arm 架構 CPU，如果工作負載使用 x86 專屬功能或最佳化設定，可能需要重構工作負載 (除了重建容器，還需要變更程式碼)。 TPU v5e - 經過最佳化調整，可為中大型 LLM 提供具成本效益的高效能服務。 TPU v5p - 高效能選項，適用於需要大規模平行處理的多主機推論。 TPU v6e - 已針對 Transformer、文字轉圖像和 CNN 服務進行最佳化。 範例：為 260 GB 模型選擇加速器
假設您需要部署的模型需要 260 GB 的加速器記憶體總量 (200 GB 用於模型、50 GB 用於 KV 快取，10 GB 用於負載)。
單就記憶體需求而言，您可以排除 NVIDIA L4 GPU，因為最大的 G2 機器最多提供 192 GB 的加速器記憶體。此外，L4 GPU 不支援加速晶片之間的高速、低延遲連線能力，因此將工作負載分散到多個節點，並非達到所需效能的可行選項。
如果不想重構 x86-64 工作負載 (也就是必須修改程式碼，才能在不同類型的處理器上執行)，也應排除使用 Arm 架構 CPU 的 NVIDIA GB200、GB300 和 Vera Rubin NVL72 加速器。
您可以採取下列做法：
- 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 等高速互連技術，這種方法非常有效，但加速器之間需要大量通訊。
範例：張量平行處理
舉例來說，假設您需要部署一個有 1, 090 億個參數的模型。在預設的 BF16 (16 位元) 精度下，將模型權重載入加速器記憶體需要約 113 GB。單一 NVIDIA H100 GPU 提供 80 GB 記憶體。因此，即使不考慮 KV 快取等其他記憶體需求，您也至少需要兩個 NVIDIA H100 GPU，並使用兩個張量平行處理大小，才能載入模型。
管道平行處理：這項技術會將模型的層依序分區給多個節點。這項技術適合在多主機部署作業中，將模型分散至多個節點，且模型等級之間的通訊需求低於張量平行處理。
範例：混合平行處理 (張量和管道)
如果模型非常龐大，參數超過 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 Inference Quickstart，取得適合您用途的最佳基準 Kubernetes 設定。
- 執行基準測試，擷取基準處理量和延遲時間指標。
- 調整推論伺服器的設定。
- 再次執行基準測試並比較結果，驗證變更。
下列建議是根據 vLLM 推論伺服器提供，但原則也適用於其他伺服器。如需所有可用設定的詳細指南，請參閱 vLLM 最佳化和調整說明文件：
- 設定平行處理：
- 張量平行處理 (
tensor_parallel_size)：將這個值設為單一節點上的加速器數量，即可將工作負載進行 shard。例如，設定tensor_parallel_size=4會將工作負載分配到四個加速器。請注意，提高這個值可能會導致同步處理負擔過重。 - Pipeline Parallelism (
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 效能調整：xPU 推論設定終極指南」。
- 如要進一步瞭解如何最佳化模型記憶體，請參閱「在 GKE 使用 GPU 最佳化大型語言模型推論的最佳做法」。
- 如需可部署的完整範例，請參閱 GKE 推論參考實作。
針對延遲時間和可用性進行最佳化
為確保推論服務反應迅速且可靠，您必須盡可能縮短啟動延遲時間，並提高資源可用性。
最佳化推論工作負載冷啟動延遲時間
為了兼顧成本效益和使用者體驗，請務必盡可能縮短推論工作負載的啟動時間。冷啟動延遲時間短，叢集就能快速擴充，滿足需求，確保服務回應迅速，同時盡可能減少昂貴的過度佈建需求。
縮短 Pod 啟動時間
Pod 準備就緒所需的時間，主要取決於提取容器映像檔和下載模型權重的時間。如要同時最佳化這兩項指標，請考慮採用下列策略：
使用最佳化的資料載入器，加快模型載入速度：儲存及載入模型權重的方法，會大幅影響啟動時間。如果是 vLLM 0.10.2 以上版本，建議使用 Run:ai Model Streamer，直接從 Cloud Storage bucket 串流載入 AI 模型。
如果串流器不適用於您的用途，可以使用 Cloud Storage FUSE 掛接 Cloud Storage bucket，並啟用階層命名空間，以及使用平行下載和預先擷取等技術，調整其效能。如要進一步瞭解這些技術，請參閱「針對 GKE 效能最佳化 Cloud Storage FUSE CSI 驅動程式」。無論是哪種情況，建議您使用 Rapid Cache 為 bucket 建立高效能可用區讀取快取，並啟用統一 bucket 層級存取權，統一控管 bucket 存取權。
如果您已使用 Managed Lustre 做為訓練工作負載的高效能檔案儲存空間，也可以使用該服務載入模型權重進行推論。如果資料位置和 POSIX 相容性至關重要，這個方法可提供低延遲存取。
啟用映像檔串流：在 GKE 叢集上啟用映像檔串流，縮短提取容器映像檔所需的時間。映像檔串流功能可讓容器在整個映像檔下載完成前啟動，大幅縮短 Pod 啟動時間。
啟用快速啟動節點
如果工作負載需要快速擴充，您可以使用 GKE 的快速啟動節點。快速啟動節點是預先初始化的硬體資源，啟動時間比標準節點短得多。如果叢集符合需求條件，GKE 會自動啟用快速啟動節點。
規劃加速器容量的彈性、效率和可用性
GPU 和 TPU 等高需求加速器的供應量可能有限，因此必須主動規劃容量。
規劃及預留容量
高需求加速器的供應量可能有限，因此必須主動規劃容量。為確保能存取所需資源，請遵循下列建議：
判斷基準容量和尖峰處理能力：規劃需要預留的基準加速器容量。預留量取決於您的用途。舉例來說，您可以為無法容忍延遲的重要工作負載預留 100% 的所需容量，也可以預留特定百分位數 (例如第 90 或 95 個百分位數)，並隨選取得其餘容量，以處理尖峰。
預留基準容量：如要確保能取得資源，請建立預留項目。您可以根據需求選擇預留類型。舉例來說，如要預留加速器等高需求資源，供未來特定時間範圍使用，可以在日曆模式中建立未來預留項目。
調度資源以因應尖峰用量：如果需求超出基準預留項目，您可以採用備用策略，使用其他資源類型，例如隨選、Spot VM 或 Dynamic Workload Scheduler (DWS)。您可以使用自訂 ComputeClass，定義佈建不同容量類型的優先順序，自動執行這項備用策略。
享有折扣價：購買承諾使用折扣 (CUD)，承諾使用一或三年，即可享有基準容量的超低折扣價。
如果工作負載可容許延遲取得容量，請使用 Dynamic Workload Scheduler 搭配彈性啟動佈建模式
如果工作負載可容許延遲取得運算資源，則可選擇採用彈性啟動佈建模式的 Dynamic Workload Scheduler (DWS)，以折扣價取得加速器。DWS 可讓您將容量要求排入佇列，最長可保留七天。
使用 DWS 搭配彈性啟動佈建模式時，建議採取下列做法：
- 將其納入 ComputeClass：使用 ComputeClass 將 DWS 定義為優先備用策略的一部分，用於取得運算資源。
- 設定執行時間長度上限：
maxRunDurationSeconds參數會設定透過 DWS 要求的節點執行時間上限。如果將這個值設為低於預設值 (七天)，就更有可能取得要求的節點。 - 啟用節點回收功能：為避免工作負載停機，請啟用節點回收功能。這項功能會在舊節點到期前，開始佈建新節點，確保轉換過程更順暢。
- 盡可能減少中斷情形：如要盡可能減少節點淘汰和升級造成的中斷情形，請設定維護期間和排除時段、停用節點自動修復功能，並採用短期升級策略。
使用 ComputeClasses
ComputeClasses 是 GKE 功能，可讓您定義工作負載的基礎架構設定優先順序清單。ComputeClasses 提供多項重要功能，可提升加速器容量的彈性、效率和可用性：
- 備用運算優先順序：您可以定義優先設定清單。如果擴充時無法使用首選選項，自動配置器會自動改用清單中的下一個選項，大幅提高成功取得容量的可能性。
- 主動遷移至優先順序較高的節點：設定這項功能後，GKE 會自動將執行較低優先順序設定的節點，替換為較高優先順序設定的節點 (如有)。這有助於確保 Pod 最終會在您最偏好 (且通常最具成本效益) 的節點上執行。
您可以使用 ComputeClasses 建立取得節點的備用策略。這項策略會使用依優先順序排列的不同容量類型清單，例如隨選 VM、Spot VM 或預留項目。每種容量類型的可用性等級都不同：
- 預留項目：提供最高等級的容量保證。使用 ComputeClass 消耗預留項目時，請考量相關限制。舉例來說，某些預留類型會限制可預留的機器類型，或可要求的機器數量上限。
- 隨選：標準佈建模式，提供彈性，但高需求資源可能受限於區域容量。
- Spot VM：以較低價格使用閒置容量，但可能遭到先占。發生先占事件時，GKE 會盡可能為受影響的 Pod 提供最多 30 秒的安全終止期。如要善用這項功能，請實作檢查點和重試機制，讓工作負載能容許先占事件。
- Dynamic Workload Scheduler (DWS)：可讓您以折扣價格排隊要求稀缺資源。這項功能適合可容許延遲取得容量的工作負載。
優先順序清單的順序應根據您的主要目標是盡可能縮短延遲時間，還是盡量降低成本而有所不同。舉例來說，您可以針對不同的工作負載需求，設定下列優先順序清單：
| 優先順序 | 低延遲工作負載 | 成本最佳化 (可容忍延遲) 工作負載 |
|---|---|---|
| 1 | 預留項目 (特定，若無則任何) | 預留項目 (特定，若無則任何) |
| 2 | 隨選 | Spot VM |
| 3 | Spot VM | Dynamic Workload Scheduler |
| 4 | Dynamic Workload Scheduler | 隨選 |
對於低延遲用途，系統會優先使用預留項目，再使用隨選容量，因為隨選容量會快速回報容量不足，讓 ComputeClass 迅速切換至下一個選項。
如果是成本最佳化的用途，系統會優先使用預留項目，其次是 Spot VM 和具備彈性啟動功能的 DWS，以降低成本。最後會使用隨選容量。
設定 GKE 叢集和節點集區的位置政策
叢集自動配置器的位置政策可控管 GKE 在擴充事件期間，如何跨可用區分配節點。使用 ComputeClass 時，這項設定特別重要，因為這會決定叢集自動配置器在套用 ComputeClass 的優先順序清單前，會考量哪些可用區。
如要提高取得加速器的機率，請根據工作負載需求設定位置政策：
location-policy=ANY：優先取得容量，而非在各可用區平均分配節點。如果 ComputeClass 包含 Spot VM 或可用性不固定的機器類型，這項設定就特別重要，因為ANY可讓叢集自動配置器選擇最有可能滿足 ComputeClass 優先節點類型的可用區。您也可以使用這項設定，優先使用未使用的預留項目。使用這項政策時，建議您從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 設定檔：在 GKE 1.33 以上版本中，符合資格的叢集預設會啟用效能 HPA 設定檔，以縮短 HPA 的反應時間。
詳情請參閱「為 GPU 上的 LLM 工作負載設定 HPA」和「自動調度 TPU 上的 LLM 推論工作負載資源」。
將資料移至更靠近工作負載的位置
工作負載載入資料 (例如模型權重) 所需的時間，可能是延遲的主要來源。將資料移至更靠近運算資源的位置，可縮短資料移轉時間，並提升整體效能。
- 使用 Rapid Cache 建立可用區讀取快取：如果您使用 Cloud Storage 儲存 AI/機器學習工作負載的資料，請啟用 Rapid Cache。Rapid Cache 會為 Cloud Storage bucket 建立高效能可用區讀取快取。
- 在本機 SSD 上快取經常存取的資料：如果工作負載需要以極低延遲時間存取臨時資料，請使用本機 SSD 做為高效能快取。使用本機 SSD 做為低延遲的臨時儲存空間，存放常用資料，可大幅縮短加速器等待 I/O 作業完成的時間，進而減少加速器等昂貴資源的閒置時間。請注意，並非所有機器系列都支援本機 SSD，這可能會影響您選擇的加速器。
- 使用 GKE Data Cache 管理快取：如果工作負載經常從永久磁碟讀取資料，請啟用 GKE Data Cache。GKE Data Cache 會使用本機 SSD，為 Persistent Disk 建立代管的高效能快取。對於大多數正式環境工作負載，建議使用
Writethrough模式，將資料同步寫入快取和基礎永久磁碟，避免資料遺失。
針對進階資源調度架構進行最佳化
為滿足大規模或全球分散式應用程式的需求，您可以採用進階擴充架構，提升效能、可靠性和流量管理。
使用 GKE Inference Gateway 進行流量負載平衡
如果是單一叢集中的推論工作負載，建議使用 GKE Inference Gateway。Inference Gateway 是 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。如要盡可能降低成本，請在各區域建立區域 bucket，並複製模型權重。
- 使用 Rapid Cache 為 Cloud Storage bucket 建立可用區讀取快取，減少網路延遲時間和資料輸出費用。
最佳做法摘要
下表彙整了本文件建議的最佳做法：
| 主題 | 工作 |
|---|---|
| 部署和設定 |
|
| 冷啟動延遲時間 |
|
| 處理能力規劃、彈性、效率和可用性 |
|
| 資源和加速器效率 |
|
| 負載平衡 |
|
| 多節點部署 |
|
| 多區域部署 |
|
後續步驟
- 請參閱 GKE 推論參考架構。