Google 會運用 AI 技術將內容翻譯成你偏好的語言，但可能會出錯。

使用機器學習診斷功能監控工作負載

工作負載監控是 ML Diagnostics 平台內建的功能，可偵測及診斷影響Google Cloud上 TPU 執行的 AI/機器學習工作負載問題。針對每個 GKE 工作，機器學習診斷工作負載監控功能會自動建立機器學習執行作業，並監控工作負載的 TPU 負載週期，以偵測影響工作負載的事件。

ML Diagnostics 工作負載監控功能的主要特色如下：

工作負載到節點的對應：自動識別工作負載使用的 Google Cloud 節點。GKE 上的所有 TPU 工作負載預設都會啟用這項功能。
狀態追蹤：監控多種狀態的工作負載，包括 performance degradation、hang、orchestrator interruption 和 termination。
以指標為準偵測問題：監控匯總 TPU 工作週期，偵測工作負載問題 (效能下降、停止回應、協調器中斷和終止)。根據預設，如果工作週期下降 15%，即表示效能降低，系統會觸發分析。如果是其他事件，系統會使用其他指標偵測當機、協調器中斷和終止情形。
自動診斷：如果系統偵測到問題，會執行自動分析器，找出基礎架構、自動調度管理工具或框架的潛在原因。分析器包括：
- 基礎架構：ICI 連結、熱能、TPU 節流、HBM 容量、HBM 頻寬、主機記憶體使用率、CPU 使用率、ToR 上行連結壅塞、ToR NIC 連結。
- 自動調度管理工具：GKE 節點集區中斷、GKE 切片中斷。
- 架構：Megascale XLA 停止回應。
問題本地化：找出受偵測到問題影響的特定節點和執行個體。
建議採取的行動：建議採取的復原或進一步調查步驟，例如重新啟動工作、移除可能發生故障的節點，或收集 XProf 設定檔。
事件時間軸：顯示工作負載事件的時間軸，以及 TPU 負載週期指標，協助您將事件與指標時間序列建立關聯。
分析詳細資料：針對每個事件執行的分析器詳細報表。
系統指標：系統會自動記錄每個工作負載監控機器學習執行的系統指標，間隔為 1 分鐘。這些系統指標提供額外資訊，可與工作負載事件相互參照，進行更深入的分析。系統指標包括：
- TPU 裝置：工作週期、Tensorcore 使用率。
- 主機：主機 CPU 使用率、主機記憶體使用率。
- HBM：記憶體頻寬使用率、HBM 記憶體總量、HBM 記憶體用量。
- 巨型 XLA：MXLA DCN 傳輸延遲時間、MXLA 傳入延遲時間、MXLA 計算延遲時間、MXLA 端對端集體延遲時間、MXLA d2h 延遲時間、MXLA h2d 延遲時間。

必要條件

如要使用 ML Diagnostics 工作負載監控功能，請啟用 Cluster Director API，並新增必要的 IAM 權限。詳情請參閱「ML Diagnostics 先決條件」。

開始使用

在 GKE 上提交 TPU 工作時，機器學習診斷系統會自動開始追蹤工作負載，不需要任何手動程式碼檢測。診斷資訊會顯示在 ML DiagnosticsGoogle Cloud 控制台中，並可使用 ML Diagnostics CLI 或 API 擷取。每個機器學習執行作業 (ML 執行作業) 都會列出診斷資訊

GKE 1.36.0-gke.4447000 以上版本會自動啟用工作負載監控功能。LibTPU 0.40.0 以上版本提供 Megascale XLA 停止回應和 Megascale XLA 指標。

工作負載監控和分析器

機器學習診斷功能會監控 TPU 工作週期，以及這與基礎架構的關係，持續監控工作負載效能。根據預設，如果工作週期下降 15%，即表示效能降低，並會觸發分析。對於其他事件，系統會使用其他指標偵測停止回應、協調器中斷和終止情形。

系統會自動追蹤工作負載狀態，並指派下列其中一個值：

running：工作負載正在執行。這個狀態不會直接顯示在 Google Cloud 控制台中。
termination：工作負載已終止，不再執行。這可能是因為預期的協調器中斷 (導致重新啟動)、成功完成或工作失敗。
hang：長時間偵測到 TPU 活動極少或沒有活動，但工作負載尚未完成。
performance degradation：當匯總 TPU 任務週期等成效指標大幅下降時，就會觸發這項警示。
Orchestrator interruption：系統偵測到 GKE 中斷協調器。這包括 TPU7x (ironwood) 的切片中斷，以及舊版節點集區的中斷。

如果工作負載偵測到問題，ML 診斷工具會觸發一組分析器，協助診斷基礎架構、自動調度管理工具和框架層級的工作負載潛在問題。這些分析器會找出基礎架構、協調器或架構問題，精確指出受影響的節點，並建議疑難排解步驟。

ICI 連結分析工具

ICI Link Analyzer 會偵測晶片間互連 (ICI) 連結的問題，這些連結會連接配量內的 TPU。這項分析器會偵測 TPU 處理器之間連結的潛在 ICI 網路問題。分析器會找出執行有問題工作負載的特定節點。

熱分析儀

熱分析器會監控並偵測過熱的 TPU 節點。溫度過高可能會對工作負載效能造成負面影響。分析器會找出發生熱問題的特定節點，這可能是因為張量核心或高頻寬記憶體 (HBM) 過熱所致。

TPU 節流分析工具

TPU 節流分析器會偵測 TPU 晶片節流的情況。這可能是因為電力、熱能或其他硬體限制。分析器會找出發生節流的特定節點。

HBM 容量分析工具

HBM 容量分析器會監控 TPU 節點的高頻寬記憶體 (HBM) 使用率。這項分析工具會偵測 HBM 使用率即將達到上限 (約 90%)，或導致記憶體不足 (OOM) 錯誤的 TPU 節點。可能的疑難排解動作包括收集 XProf 剖析追蹤記錄，以進行詳細的 HBM 記憶體用量分析。您也應考慮修改工作負載設定，以最佳化 HBM 使用量，例如縮減批量大小或調整模型參數。

HBM 頻寬分析器

HBM 頻寬分析器會監控 TPU 節點和執行個體的高頻寬記憶體 (HBM) 讀取和寫入頻寬。這項分析工具會偵測 HBM 頻寬受到節流的 TPU 執行個體，這表示高頻寬記憶體 (HBM) 作業受到限制。這可能是因為頻寬限制或硬體問題 (例如 TPU 晶片溫度過高) 所致。分析器會找出發生節流的特定執行個體。

主機記憶體使用率分析工具

主機記憶體使用率分析器會監控 TPU 節點和執行個體不可逐出的主機記憶體使用率。這項分析工具會偵測不可逐出的主機記憶體用量即將達到上限的 TPU 執行個體，這可能會導致效能降低，並增加記憶體不足 (OOM) 事件的風險。這可能是因為資料管道中預先擷取或緩衝處理的資料過多、檢查點作業期間的暫時性 RAM 尖峰，或是自訂載入器中的記憶體洩漏所致。如要瞭解如何識別 GKE 工作負載，並設定適當的記憶體要求和限制，請參閱 GKE 最佳做法。

CPU 使用率分析器

CPU 使用率分析器會監控 TPU 節點和執行個體的主機 CPU 使用率。這項分析工具會偵測主機 CPU 使用率接近分配上限的 TPU 執行個體。這可能會對應用程式效能造成負面影響，導致速度變慢或沒有回應。可能的疑難排解動作包括使用 Cloud Profiling 進行詳細的 CPU 使用率分析。如要瞭解如何識別 GKE 工作負載，並設定適當的記憶體要求和限制，請參閱 GKE 最佳做法。

ToR NIC 連結分析工具

這項分析工具會偵測架頂 (ToR) 交換器與網路介面卡 (NIC) 連結之間的網路問題。分析器會找出執行有問題工作負載的特定例項。

ToR 上行鏈路壅塞分析器

這項分析工具會偵測機架頂端 (ToR) 交換器發生網路路徑壅塞的問題。這個分析器指出特定上行鏈路埠的使用率偏高。分析器會找出發生壅塞的特定執行個體。

GKE Orchestrator Slice Interruption Analyzer

這項分析器會在 GKE 編排層偵測切片層級的中斷事件。偵測到切片中斷時，分析器會找出受影響的切片，並將底層子區塊標示為可能導致中斷的根本原因。這個分析器會在工作負載的每個切片層級運作，因此您會個別取得每個切片的切片中斷事件。

GKE Orchestrator Nodepool Interruption Analyzer

這個分析器會偵測 GKE 自動化調度管理工具層發生的節點集區中斷事件。對於 TPU v6e (Trillium) 和先前的 TPU 世代，GKE 不會註冊統一的「Slice」資源。這項服務只會註冊綁定為節點集區的標準個別 Compute Engine VM (節點)。

如果節點因計畫性中斷 (維護、搶占或主機錯誤) 或非計畫性故障而停止運作，GKE 會自動套用 Taint (例如 node.kubernetes.io/unreachable)，並將節點的狀態變更為 NotReady。節點集區中斷分析工具會使用這些指標偵測自動調度管理工具中斷。

Megascale XLA (MXLA) 停止回應分析工具

這個分析器會偵測影響 MXLA 框架層多切片 TPU 工作負載的停止回應問題。Cloud TPU 多配量環境是由多個 TPU 配量組成，這些配量會透過資料中心網路 (DCN) 通訊。多切片工作負載會使用 Megascale 集體作業，透過 DCN 進行通訊。如果工作站等待 Megascale 通訊作業的時間超過設定的逾時期限，就會發生 Megascale 停止回應的情況。在這些情況下，您會在 Cloud TPU 記錄中收到 Megascale HANG_DETECTED 訊息。

Megascale 通常會偵測並回報停止回應的情況，因為它負責透過 DCN 進行通訊。不過，這不一定代表錯誤是由 Megascale 造成。通常，偵測到當機是系統其他部分發生問題的徵兆。因此，Megascale HANG_DETECTED 訊息是全面性的指標，表示工作負載無法正常進展。這可能是第三方軟體、Google 擁有的軟體，或是硬體本身的問題所致。

這個分析器會在發生停止回應時自動觸發，並在 ML 診斷系統中提供分析器報告，說明停止回應的可能原因，不必手動檢查使用者記錄。分析工具會找出下列可能原因：

BAD_TPU_CHIP：MXLA 停止運作可能是因為 TPU Tensorcore 發生問題。分析器也會回報顯示問題的特定例項。
BAD_SC_CHIP：MXLA 停止運作可能是因為 TPU sparsecore 發生問題。分析器也會回報顯示問題的特定例項。
NETWORKING_ISSUE：MXLA 停止回應可能是 DCN 網路發生網路問題所致。分析器也會回報顯示問題的特定例項。
DIFFERENT_MODULE：MXLA 停止回應可能是因為在不同 VM 上執行不同的 HLO 模組。如要找出原因，請檢查記錄中分析工具列印的摘要。
FINGERPRINT_MISMATCH：MXLA 停止回應可能是因為 VM 間的 HLO 模組編譯不一致。這可能是 JAX 追蹤或 XLA 編譯器中的錯誤。如要找出原因，請檢查記錄中分析器列印的摘要。傾印 HLO，並與 Google XLA 編譯器團隊分享輸出內容，以便進一步偵錯。詳情請參閱「傾印 HLO 計算」。
DATA_INPUT_STALL：MXLA 停止回應可能是資料輸入停滯所致。分析器也會回報顯示問題的特定例項。
ICI_ERROR：MXLA 停止回應可能是 ICI 錯誤所致。分析器也會回報顯示問題的特定例項。
PROGRAM_NOT_QUEUED：MXLA 停止回應可能是因為某些 VM 未將程式排入 TPU 佇列。檢查應用程式是否遭到封鎖或當機，導致 JAX 無法將下一個 TPU 程式 (即時編譯函式) 加入佇列。
LAUNCHES_ORDER_INCONSISTENT：MXLA 停止回應可能是因為 VM 的啟動順序不一致。如要找出原因，請檢查記錄中分析器列印的摘要。
UNRECOVERABLE_ERROR：MXLA 停止運作的原因是發生無法復原的錯誤。分析器也會回報顯示問題的特定例項。檢查發生無法復原錯誤的執行個體錯誤記錄。如果錯誤似乎與特定機器有關 (例如無法將資料從 TPU 複製到主機)，則您需要設定工作，避開這些主機。如果錯誤記錄未指出問題與特定電腦有關，則問題可能出在應用程式層級。
UNKNOWN：系統偵測到 MXLA 停止回應，但無法判斷可能原因。

系統指標

每次執行工作負載監控機器學習時，Cloud Monitoring 都會自動以 1 分鐘為間隔收集系統指標。這些系統指標提供額外資訊，可與工作負載事件建立關聯，並與分析器結果一起進行深入分析。系統指標包括：

TPU 裝置指標：任務週期 (node/accelerator/duty_cycle)、Tensor Core 使用率 (node/accelerator/tensorcore_utilization)。
主機裝置指標：主機 CPU 使用率 (node/cpu/allocatable_utilization)、主機記憶體使用率 (node/memory/allocatable_utilization)。
HBM 指標：記憶體頻寬使用率 (node/accelerator/memory_bandwidth_utilization)、HBM 記憶體總計 (node/accelerator/memory_total)、HBM 記憶體用量 (node/accelerator/memory_used)。
多切片工作負載的 MXLA 指標：MXLA DCN 傳輸延遲時間 (container/multislice/network/dcn_transfer_latencies)、MXLA 傳入傳輸延遲時間 (container/multislice/network/dcn_inbound_transfer_latencies)、MXLA 計算延遲時間 (container/multislice/accelerator/compute_latencies)、MXLA 端對端集體延遲時間 (container/multislice/network/collective_end_to_end_latencies)、MXLA d2h 延遲時間 (container/multislice/accelerator/device_to_host_transfer_latencies)、MXLA h2d 延遲時間 (container/multislice/accelerator/host_to_device_transfer_latencies)。

如需系統指標的相關資訊，請參閱 GKE 系統指標。

如要以更細的間隔記錄系統指標，請使用 ML Diagnostics SDK 並設定 log_system_metrics=true。如要查看 SDK 每 10 秒記錄一次的系統指標清單，請參閱 ML Diagnostics (google-cloud-mldiagnostics) SDK 說明文件。根據預設，系統會自動將每 1 分鐘收集的系統指標，匯入 ML Diagnostics 系統。

在 Google Cloud 控制台中查看工作負載監控

您可以在Google Cloud 控制台的「Cluster Director」和 GKE 下方，查看 ML Diagnostics 工作負載監控功能監控的執行作業。

如要查看 Cluster Director 中的所有機器學習執行作業，請按照下列步驟操作：

前往 Google Cloud 控制台的「Cluster Director」頁面。
按一下「執行診斷」分頁標籤。

前往「Cluster Director Run Diagnostics」

如要查看 Google Kubernetes Engine 中的所有機器學習執行作業，請按照下列步驟操作：

前往 Google Cloud 控制台的「Kubernetes」頁面。
按一下導覽選單中的「AI/ML」。
按一下「執行診斷」分頁標籤。

前往 GKE AI/機器學習執行診斷

Cluster Director 和 GKE 控制台會顯示下列資訊：

執行摘要：這個表格包含 Workload Monitoring 為 GKE 工作建立的每個執行作業名稱。系統會自動使用 job-name-timestamp 格式為執行作業命名。
執行詳細資料 (監控總覽)：選取 ML 執行作業，即可在「監控總覽」分頁中查看詳細資訊。這個分頁包含：
- 匯總 TPU 任務週期：顯示 ML 執行作業匯總 TPU 任務週期的圖表。
- 事件時間軸：所有影響 ML 執行的事件時間軸，包括效能降低、停止、協調器中斷和終止。
- 事件表格：這個表格會彙整影響 ML 執行的事件。每個活動都包含：
  - 事件名稱和活動類型。
  - 活動的開始和結束時間。
  - 分析器詳細資料的連結。
- 活動詳細資料：選取活動的「查看詳細資料」，即可查看該活動的所有分析結果。
- 系統指標：系統會從 Cloud Monitoring 自動提取系統指標，間隔為 1 分鐘，或是由 ML Diagnostics SDK 以更精細的層級記錄

透過 Google Cloud CLI 存取工作負載監控資訊

針對每項 GKE 工作，工作負載監控會自動在 ML 診斷中建立機器學習執行作業，並使用 job-name-timestamp 格式的 ML 執行作業名稱。您可以使用 ML Diagnostics gcloud CLI 指令 (例如 Describe、List、Delete 和 Update)，查看專案中建立的所有 ML 執行作業、取得這些執行作業的詳細資料，以及刪除或更新 ML 執行作業的屬性。

此外，您可以使用 monitored-events Google Cloud CLI 指令列出工作負載監控服務偵測到的所有事件，並擷取每個事件的分析器詳細資料。詳情請參閱「使用 ML Diagnostics CLI」。

透過 API 存取工作負載監控資訊

您可以透過 MonitoredEvent API 的「GET」方法，存取 Workload Monitoring 偵測到的事件。

列出所有受監控的事件

如要列出特定 ML 執行作業的所有受監控事件 (MonitoredEvent)，請使用「GET」方法和 /v1alpha/{parent=projects/*/locations/*/machineLearningRuns/*}/monitoredEvents 端點。

以下是要求範例：

curl -X GET \
  -H "Authorization: Bearer $(gcloud auth print-access-token)" \
  -H "Content-Type: application/json" \

 "https://hypercomputecluster.googleapis.com/v1alpha/projects/PROJECT_ID/locations/LOCATION/machineLearningRuns/ML_RUN_ID/monitoredEvents"

輸出內容為 ListMonitoredEventsResponse 物件，也就是包含 MonitoredEvent 摘要清單的 JSON 物件。摘要會提供事件時間戳記和詳細資料的總覽。

以下是 ListMonitoredEventsResponse 物件的範例：

{
 "monitoredEvents": [
   {
     "name": "projects/user-project-id/locations/us-central1/machineLearningRuns/my-tpu-job-20260327T073000/monitoredEvents/event-id-456",
     "type": "PERFORMANCE_DEGRADATION",
     "displayName": "Performance degradation - 2026-03-27T07:45:10Z ",
     "startTime": "2026-03-27T07:45:10Z",
     "endTime": "2026-03-27T08:00:00Z",
     "analyzerReports": [
       {
         "analyzer": "TPU Throttling Analyzer",
         "detectionState": "NOT_DETECTED"
       }
       // ... additional analyzer reports
     ]
   },
   {
     "name": "projects/user-project-id/locations/us-central1/machineLearningRuns/my-tpu-job-20260327T073000/monitoredEvents/event-id-123",
     "type": "PERFORMANCE_DEGRADATION",
     "displayName": "Performance degradation - 2026-03-27T07:35:00Z ",
     "startTime": "2026-03-27T07:35:00Z",
     "endTime": "2026-03-27T08:15:00Z",
     "analyzerReports": [
       // ... analyzer reports
     ]
   }
   // ... other events
 ]
}

取得受監控的事件

如要擷取特定監控事件 (MonitoredEvent) 的詳細資料，請將「GET」要求傳送至 /v1alpha/{parent=projects/*/locations/*/machineLearningRuns/*}/monitoredEvents/* 端點。

以下是要求範例：

curl -X GET \
     -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     -H "Content-Type: application/json" \
     "https://hypercomputecluster.googleapis.com/v1alpha/projects/PROJECT_ID/locations/LOCATION/machineLearningRuns/ML_RUN_ID/monitoredEvents/EVENT_ID"

輸出內容為 MonitoredEvent 物件，也就是包含指定事件相關資訊的 JSON 物件。這個物件中的 analyzer_reports 陣列包含詳細的結果、狀態，以及每個分析器 (ICI 連結、熱能、TPU 節流、HBM 容量) 針對偵測到的事件所提供的建議。

以下是 MonitoredEvent 物件的範例：

{
 "name": "projects/user-project-id/locations/us-central1/machineLearningRuns/my-tpu-job-20260327T073000/monitoredEvents/event-id-456",
 "type": "PERFORMANCE_DEGRADATION",
 "displayName": "Performance degradation - 2026-03-27T07:45:10Z ",
 "startTime": "2026-03-27T07:45:10Z",
 "endTime": "2026-03-27T08:15:00Z",
 "analyzerReports": [
   {
     "analyzer": "ICI Link Analyzer",
     "detectionState": "DETECTED",
     "details": "ICI Link issues detected in <instance_ids>: This indicates networking issues on ICI links connected between TPU processors.",
     "recommendedActions": [
       {
         "description": "Contact Google team for further diagnosis. Potential action could be to Outkast affected nodes, but there could be other causes that need further investigation.",
         "documentationUrl": "https://docs.cloud.google.com/tpu/docs/ml-diagnostics/workload-monitoring"
       }
     ]
   },
   {
     "analyzer": "TPU Throttling analyzer",
     // ... results from TPU Throttling analyzer
   }
   // ... other analyzer reports
 ]
}