關於彈性啟動佈建模式的 GPU、TPU 和 H4D 消耗量

Autopilot Standard

本頁面說明 Google Kubernetes Engine (GKE) 的彈性啟動功能。彈性啟動採用 Dynamic Workload Scheduler 技術，可讓您在需要執行 AI/機器學習工作負載時，以彈性且符合成本效益的方式使用 GPU 或 TPU 等特殊運算資源。

彈性啟動模式可讓您視需要動態佈建 GPU、TPU 和 H4D 機器系列的彈性啟動型 VM，最多可使用七天，不限於特定開始時間，且無需管理長期預留項目。因此，彈性啟動 VM 非常適合用於需求量波動或時間較短的中小型工作負載。例如小型模型預先訓練、模型微調或可擴充的服務模型。

本頁面的資訊可協助您執行下列操作：

• 瞭解 GKE 中彈性啟動的運作方式。
• 判斷彈性啟動是否適用於您的工作負載。
• 決定最適合工作負載的彈性啟動設定。
• 使用彈性啟動型 VM 時，管理中斷情況。
• 瞭解 GKE 中彈性啟動型 VM 的限制。

本頁內容適用於希望為工作負載最佳化加速器基礎架構的平台管理員和營運人員，以及機器學習 (ML) 工程師。

使用彈性啟動的時機

如果工作負載符合下列所有條件，建議您使用彈性啟動：

• 工作負載需要 GPU 資源。
• 工作負載需要 TPU 資源，且這些資源在單主機 TPU 配量節點集區中執行。
• 工作負載需要其他特殊硬體，例如針對 HPC 最佳化的 H4D 機器系列。
• 您沒有或只有少量預留 GPU 或 TPU 運算資源，但需要更可靠地存取這些加速器。
• 工作負載的時間彈性較高，且您的用途可以等待取得所有要求的容量，例如 GKE 在非尖峰時段分配 GPU 資源。

彈性啟動定價

如果工作負載需要視需要動態佈建資源，且最多可透過短期預留項目使用七天，不需複雜的配額管理，並能以經濟實惠的價格存取，建議使用彈性啟動。彈性啟動 採用 Dynamic Workload Scheduler，並依 Dynamic Workload Scheduler 定價計費：

• vCPU、GPU、TPU 和任何附加的本機 SSD 磁碟可享折扣 (最高 53%)。
• 您會採用即付即用 (PAYG) 模式。

需求條件

如要在 GKE 中使用彈性啟動功能，叢集必須符合下列需求：

• 如要執行 GPU，請使用 GKE 1.32.2-gke.1652000 以上版本。

• 如要執行 TPU，請參閱「在 GKE 中規劃 TPU」一文中的 GKE 版本需求。彈性啟動支援下列版本和區域：

  • us-central1-c中的 Ironwood (TPU7x)。
  • asia-northeast1-b、us-east5-a 和 us-east5-b 的 TPU Trillium (v6e)。
  • us-west4-a 中的 TPU v5e。
  • us-east5-a 中的 TPU v5p。

  不支援 TPU v3 和 v4。

彈性啟動佈建模式的運作方式

使用彈性啟動模式時，您可以在工作負載中指定所需的運算容量 (例如 GPU 或 TPU)。此外，您還可以在標準叢集的特定節點集區中設定彈性啟動。當容量可用時，GKE 會完成下列程序，自動佈建彈性啟動型 VM：

1. 工作負載要求的容量無法立即使用。這項要求可直接透過工作負載規格提出，或透過自訂運算類別或 Kueue 等自動化調度管理工具提出。
2. GKE 會識別節點是否已啟用彈性啟動。如未指定 --request-valid-for-duration 標記，GPU 工作負載最多可等待 14 天，相較之下，TPU 工作負載可以等待不確定的時間長度。
3. 叢集自動配置器會接受您的要求，並計算必要的節點數量，將這些節點視為單一單位。
4. 叢集自動配置器會在必要節點可用時佈建這些節點。這些節點最多可執行七天，或在您於 maxRunDurationSeconds 參數中指定值時，執行時間會更短。如未指定 maxRunDurationSeconds 參數的值，預設為七天。
5. 在 maxRunDurationSeconds 參數中定義的執行時間結束後，節點和 Pod 會遭到搶占。
6. 如果 Pod 提早完成，且節點不再使用，叢集自動配置器會根據自動調度資源設定檔移除節點。

GKE 會在節點層級計算每個彈性啟動要求的持續時間。啟動期間發生延遲，因此可執行 Pod 的時間可能稍短。Pod 重試會共用這段時間，也就是說，Pod 在重試後可用的時間較少。GKE 會分別計算每項彈性啟動要求的時間長度。

彈性啟動設定

GKE 支援下列彈性啟動設定：

• 彈性啟動：GKE 會逐一分配節點資源。這項設定只需要在建立節點時設定 --flex-start 旗標。

• 彈性啟動搭配佇列式佈建：GKE 會同時分配所有要求的資源。如要使用這項設定，您必須在建立節點集區時新增 --flex-start 和 enable-queued-provisioning 旗標。GKE 會遵循本文「彈性啟動佈建模式的運作方式」一節中的程序，但也會套用下列條件：

  • 排程器會等待所有要求的資源在單一可用區中可用。
  • 工作負載的所有 Pod 都能在新佈建的節點上一起執行。
  • 工作負載執行作業之間不會重複使用佈建的節點。
  注意： 搭載 GKE 1.29.1-gke.1708000 以上版本的叢集會最佳化可用區選取程序，以縮短等待時間。舊版可能需要較長的排隊時間。

下表比較了彈性啟動設定：

	彈性啟動	彈性啟動搭配佇列式佈建
可用性	預覽	正式發布版 (GA) 注意：彈性啟動功能支援預先發布版中的 flex-start 和 enable-queued-provisioning 標記。
支援的加速器	GPU 單一主機 TPU 配量節點集區和多主機 TPU 配量節點集區中的 TPU	GPU 多主機 TPU 配量節點集區中的 TPU
建議的工作負載大小	小型到中型，也就是說工作負載可在單一節點上執行。舉例來說，如果您執行小型訓練工作、離線推論或批次工作，這個設定就非常適合。	中型至大型，也就是說，工作負載可在多個節點上執行。工作負載需要多項資源，必須等到所有節點都佈建完成並準備就緒，才能開始執行。舉例來說，如果您執行分散式機器學習訓練工作負載，這個設定就非常適合。
佈建類型	GKE 會在資源可用時，一次佈建一個節點。如果是 TPU，GKE 會在單主機 TPU 配量節點集區中一次建立一個節點，並在多主機 TPU 配量節點集區中一次建立整個配量。	GKE 會同時分配所有要求的資源。
設定複雜度	較簡單。這項設定與隨選和 Spot VM 類似。	更複雜。強烈建議您使用配額管理工具，例如 Kueue。
支援自訂運算類別	是	否
節點回收	是	否
價格	彈性啟動 SKU	彈性啟動 SKU
配額	GPU 先占配額 TPU 先占配額	GPU 先占配額 TPU 先占配額
節點升級策略	短期升級	短期升級授權
gcloud container node pool create 旗標	--flex-start	--flex-start --enable-queued-provisioning
開始使用	GPU： 在 GKE 上提供 LLM，並採用成本效益最高且高可用性的 GPU 佈建策略 使用 GPU 和彈性啟動佈建模式執行小型批次工作負載 TPU： 使用 TPU 和彈性啟動佈建模式執行小型批次工作負載	透過彈性啟動搭配佇列式佈建，執行大規模工作負載

最佳化彈性啟動設定

如要建立穩健且成本最佳化的 AI/機器學習基礎架構，可以結合彈性啟動設定和可用的 GKE 功能。建議您使用運算類別，根據工作負載需求定義優先節點設定清單。GKE 會根據可用性和您定義的優先順序，選取最合適的設定。

管理使用 Dynamic Workload Scheduler 的工作負載中斷情形

如果工作負載需要節點集區中的所有或大部分節點可用，則容易受到淘汰作業影響。此外，使用 Dynamic Workload Scheduler 要求佈建的節點不支援自動修復。自動修復功能會從節點移除所有工作負載，因此工作負載無法執行。

如果叢集控制層執行彈性啟動的最低版本 (1.32.2-gke.1652000 以上版本)，則所有使用彈性啟動型 VM、佇列式佈建或兩者的節點，都會使用短期升級。

短期升級會更新 Autopilot 叢集中的標準節點集區或節點群組，且不會中斷執行中的節點。系統會使用新設定建立新節點，並逐漸取代舊設定的現有節點。如果使用不支援彈性啟動或短期升級的舊版 GKE，則需要採用不同的最佳做法。

使用短期升級的節點，盡可能減少工作負載中斷的最佳做法

如果叢集執行 1.32.2-gke.1652000 以上版本，系統會自動將使用彈性啟動型 VM 的節點，以及使用佇列式佈建的節點，設定為使用短期升級。

如要盡量減少使用短期升級的節點對工作負載造成的干擾，請執行下列工作：

• 設定維護期間和排除時段，指定 GKE 應在哪些時間執行更新作業 (例如節點升級)，並確保 GKE 仍有時間執行自動維護作業。
• 停用節點自動修復功能。

如果叢集節點執行的版本早於 1.32.2-gke.1652000，因此未使用短期升級，請參閱這些節點的具體指引。

最佳做法：盡可能減少佇列式佈建節點的工作負載中斷情形，不進行短期升級

如果叢集執行的 GKE 版本早於 1.32.2-gke.1652000，使用佇列式佈建的節點不會使用短期升級。如果叢集升級至 1.32.2-gke.1652000 以上版本，且有現有的佇列式佈建節點，系統會自動更新叢集，改用短期升級。

如要瞭解如何處理執行這些舊版節點的問題，請參閱下列指引：

• 視叢集的發布管道註冊狀態而定，請採用下列最佳做法，防止節點自動升級中斷工作負載：
  • 如果叢集已註冊發布管道，請使用維護時間範圍和排除項目，防止 GKE 在工作負載執行期間自動升級節點。
  • 如果叢集未註冊至發布管道，請停用節點自動升級。不過，建議您使用發布管道，並搭配更精細的維護排除範圍。
• 停用節點自動修復功能。
• 使用維護期間和排除時段，盡量減少執行中工作負載的中斷情形，同時確保 GKE 仍有時間自動維護。請務必安排在沒有工作負載執行的時間。
• 為確保節點集區保持最新狀態，請在沒有任何 Dynamic Workload Scheduler 要求，且節點集區為空白時，手動升級節點集區。

叢集遷移至短期升級時的注意事項

叢集升級至 1.32.2-gke.1652000 以上版本時，GKE 會使用佇列式佈建更新現有節點，採用短期升級。GKE 不會更新其他設定，例如在您停用特定節點集區的節點自動升級功能時，啟用該功能。

節點集區使用短期升級後，建議您考慮導入下列最佳做法：

• 如果您使用 --no-enable-autoupgrade 旗標停用節點自動升級功能，這項遷移作業不會為節點集區重新啟用節點自動升級功能。 建議您啟用節點自動升級功能，因為短期升級不會干擾現有節點和在節點上執行的工作負載。詳情請參閱「短期升級」。
• 此外，如果叢集尚未加入發布管道，建議您加入叢集，以便使用更精細的維護排除範圍。

彈性啟動模式中的節點回收

為確保節點順利轉換，並避免執行中的作業發生停機情形，彈性啟動支援節點回收。節點達到期限時，GKE 會自動以新節點取代，保留執行中的工作負載。

如要使用節點回收功能，您必須建立自訂運算類別設定檔，並在 flexStart 規格中加入 nodeRecycling 欄位和 leadTimeSeconds 參數。

leadTimeSeconds 參數可讓您兼顧資源可用性和成本效益。這個參數會指定節點在七天期限結束前多久 (以秒為單位)，應開始新的節點佈建程序來取代節點。延長前置時間可提高新節點在舊節點移除前準備就緒的機率，但可能會產生額外費用。

節點回收程序包含下列步驟：

1. 回收階段：GKE 會驗證彈性啟動佈建的節點是否具有 nodeRecycling 欄位，且已設定 leadTimeSeconds 參數。如果是，當目前日期大於或等於下列欄位值之間的差異時，GKE 會啟動節點回收階段：

   • creationTimestamp 加 maxRunDurationSeconds
   • leadTimeSeconds

   creationTimeStamp 旗標包含節點的建立時間。您可以在自訂運算類別中指定 maxRunDurationSeconds 欄位，預設值為七天。

2. 建立節點：開始建立新節點，並依序進行排入佇列和佈建階段。排入佇列階段的時間長度會因可用區和特定加速器容量而異。

3. 限制節點，該節點的七天期限即將到期：新節點執行後，舊節點會受到限制。這項操作可防止在節點上排定任何新的 Pod。該節點中的現有 Pod 會繼續執行。

4. 節點取消佈建：節點達到七天期限後，會在適當時間取消佈建，確保執行中的工作負載已遷移至新節點。

以下是運算類別設定範例，包含 leadTimeSeconds 和 maxRunDuration 欄位：

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: dws-model-inference-class
spec:
  priorities:
    - machineType: g2-standard-24
      spot: true
    - machineType: g2-standard-24
      maxRunDurationSeconds: 72000
      flexStart:
        enabled: true
        nodeRecycling:
          leadTimeSeconds: 3600
  nodePoolAutoCreation:
    enabled: true

如要進一步瞭解如何使用節點回收功能，請參閱「在 GKE 上提供 LLM 服務，並採用成本效益最高的高可用性 GPU 佈建策略」教學課程。

限制

• 不支援 Pod 之間的抗親和性。叢集自動配置器在佈建節點時不會考量 Pod 間的反親和性規則，這可能會導致工作負載無法排程。如果兩個以上 Dynamic Workload Scheduler 物件的節點是在同一個節點集區中佈建，就可能發生這種情況。
• Dynamic Workload Scheduler 不支援預留項目。 動態工作負載排程器僅支援叢集自動調度資源的ANY 位置政策，且必須使用這項政策。
• 單一 Dynamic Workload Scheduler 要求最多可建立 1,000 個虛擬機器 (VM)，這是單一節點集區每個區域的節點數量上限。
• GKE 會使用 Compute Engine ACTIVE_RESIZE_REQUESTS 配額，控管佇列中待處理的 Dynamic Workload Scheduler 要求數量。這項配額的預設上限為每個專案 100 項要求。 Google Cloud如果嘗試建立大於配額的 Dynamic Workload Scheduler 要求，新要求就會失敗。
• 使用 Dynamic Workload Scheduler 的節點集區容易受到中斷影響，因為節點是同時佈建。詳情請參閱「管理使用 Dynamic Workload Scheduler 的工作負載中斷情形」。
• 您可能會在 Google Cloud 控制台看到其他短期 VM。這是預期行為，因為 Compute Engine 可能會建立 VM，然後立即移除，直到有足夠容量可佈建所有必要機器為止。
• 不支援 Spot VM。
• Dynamic Workload Scheduler 不支援臨時磁碟區。 您必須使用永久磁碟區做為儲存空間。如要選取使用永久磁碟區的最佳儲存空間類型，請參閱「GKE 叢集儲存空間總覽」。
• 如果工作負載使用節點回收功能，且是由 Job 部署，請將 Job 的完成模式設為 Indexed。
• 單一 ProvisioningRequest 物件在 podSets 清單中僅支援一個項目。如果要求包含多個 podSet 項目，就會失敗。

後續步驟

• 選取 GPU 類型
• 使用 Dynamic Workload Scheduler 部署 GPU。