Google 会使用 AI 技术将内容翻译成您偏好的语言。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 分钟记录一次，适用于每个工作负载监控 ML 运行。这些系统指标可提供额外信息，以便与工作负载事件相关联，从而进行更深入的分析。系统指标包括：
- TPU 设备：占空比、TensorCore 利用率。
- 宿主设备：宿主 CPU 利用率、宿主内存利用率。
- HBM：内存带宽利用率、HBM 内存总量、HBM 已用内存。
- 超大规模 XLA：MXLA DCN 传输延迟时间、MXLA 入站传输延迟时间、MXLA 计算延迟时间、MXLA 端到端总体延迟时间、MXLA 设备到主机延迟时间、MXLA 主机到设备延迟时间。

前提条件

如需使用 ML Diagnostics Workload Monitoring，请启用 Cluster Director API 并添加所需的 IAM 权限。如需了解详情，请参阅 ML 诊断前提条件。

开始使用

在 GKE 上提交 TPU 作业时，机器学习诊断系统会自动开始跟踪您的工作负载，而无需任何手动代码插桩。诊断信息会显示在 ML DiagnosticsGoogle Cloud 控制台中，并且可以使用 ML Diagnostics CLI 或 API 进行检索。系统会列出每个机器学习运行作业（ML 运行作业）的诊断信息

对于 GKE 1.36.0-gke.4447000 及更高版本，系统会自动启用工作负载监控功能。LibTPU 版本 0.40.0 及更高版本支持 Megascale XLA 挂起和 Megascale XLA 指标。

工作负载监控和分析器

ML 诊断会监控 TPU 工作周期及其与底层基础架构的关系，从而持续监控工作负载性能。默认情况下，占空比下降 15% 表明性能下降，并会触发分析。对于其他事件，系统会使用其他指示器来检测挂起、编排器中断和终止。

系统会自动跟踪工作负载状态，并为其分配以下值之一：

running：工作负载正在积极执行。此状态不会直接显示在 Google Cloud 控制台中。
termination：工作负载已终止，不再运行。这可能是由于编排器预期中断（导致重新启动）、成功完成或作业失败所致。
hang：长时间检测到 TPU 活动极少或没有活动，但工作负载未完成。
performance degradation：由性能指标（例如 TPU 汇总占空比）的大幅下降触发。
Orchestrator interruption：检测到 GKE 中断了编排器。这包括 TPU7x (ironwood) 的切片中断，以及更早版本的节点池中断。

对于在工作负载中检测到的问题，机器学习诊断会触发一组分析器，以帮助诊断工作负载在基础架构、编排器和框架层面的潜在问题。这些分析器可识别基础架构、编排器或框架问题，精确定位受影响的节点，并建议问题排查步骤。

ICI Link Analyzer

ICI Link Analyzer 可检测连接切片内 TPU 的芯片间互连 (ICI) 链接存在的问题。此分析器可检测 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 Link Analyzer

此分析器可检测架顶 (ToR) 交换机与网络接口卡 (NIC) 链路之间的网络问题。分析器会找到运行问题工作负载的具体实例。

ToR 上行链路拥塞分析器

此分析器可检测到出现网络路径拥塞的架顶 (ToR) 交换机存在的问题。此分析器表明特定上行链路端口的利用率较高。分析器会找到发生拥塞的具体实例。

GKE Orchestrator Slice Interruption Analyzer

此分析器可在 GKE Orchestrator 层检测切片级中断事件。检测到切片中断时，分析器会识别受影响的切片，并将底层子块确定为中断的潜在根本原因。此分析器在工作负载的每个切片级别运行，因此您会单独获得每个切片的切片中断事件。

GKE Orchestrator 节点池中断分析器

此分析器会检测 GKE 编排器层发生的节点池中断事件。对于 TPU v6e (Trillium) 及更早的 TPU 世代，GKE 不会注册统一的“Slice”资源。它仅注册绑定在一起的标准单个 Compute Engine 虚拟机（节点）作为节点池。

当节点因计划中断（维护、抢占或主机错误）或意外故障而停机时，GKE 会自动应用污点（例如 node.kubernetes.io/unreachable）并将节点的状态更改为 NotReady。节点池中断分析器会使用这些指标来检测编排器中断。

Megascale XLA (MXLA) 挂起分析器

此分析器可在 MXLA 框架层检测影响多切片 TPU 工作负载的挂起。Cloud TPU 多切片环境由多个通过数据中心网络 (DCN) 进行通信的 TPU 切片组成。多切片工作负载使用 Megascale 集体通过 DCN 进行通信。当工作器等待 Megascale 通信操作的时间达到设定的超时时间段时，就会发生 Megascale 挂起。在这些情况下，您会在 Cloud TPU 日志中收到 Megascale HANG_DETECTED 消息。

Megascale 通常会检测并报告挂起，因为它负责通过 DCN 进行通信。不过，这并不一定意味着该错误是由 Megascale 引起的。通常，挂起检测是系统其他部分出现问题的症状。因此，Megascale HANG_DETECTED 消息是一种全方位的指示，表明工作负载未正常运行。这可能是由第三方软件、Google 自有软件或硬件本身的问题引起的。

该分析器不会手动检查用户日志，而是在发生挂起时自动触发，并在 ML 诊断系统中提供有关挂起潜在原因的分析器报告。分析器会确定以下潜在原因：

BAD_TPU_CHIP：MXLA 挂起很可能是由 TPU 张量核心问题引起的。分析器还会报告出现问题的具体实例。
BAD_SC_CHIP：MXLA 挂起很可能是由 TPU sparsecore 问题引起的。分析器还会报告出现问题的具体实例。
NETWORKING_ISSUE：MXLA 挂起很可能是由 DCN 网络中的网络问题引起的。分析器还会报告出现问题的具体实例。
DIFFERENT_MODULE：MXLA 挂起很可能是由在不同虚拟机上运行不同的 HLO 模块引起的。如需确定原因，请检查分析器在日志中打印的摘要。
FINGERPRINT_MISMATCH：MXLA 挂起很可能是由虚拟机之间 HLO 模块编译不一致造成的。这可能是 JAX 跟踪或 XLA 编译器中的 bug。如需确定原因，请检查分析器在日志中打印的摘要。转储您的 HLO 并与 Google XLA 编译器团队分享输出，以便进一步调试。如需了解详情，请参阅转储 HLO 计算。
DATA_INPUT_STALL：MXLA 挂起很可能是由数据输入停滞引起的。分析器还会报告出现问题的具体实例。
ICI_ERROR：MXLA 挂起很可能是由 ICI 错误引起的。分析器还会报告出现问题的具体实例。
PROGRAM_NOT_QUEUED：MXLA 挂起很可能是由某些虚拟机未将程序排队到 TPU 引起的。检查您的应用是否被阻塞或崩溃，这会阻止 JAX 将下一个 TPU 程序（经过 JIT 编译的函数）加入队列。
LAUNCHES_ORDER_INCONSISTENT：MXLA 挂起很可能是由虚拟机之间启动顺序不一致造成的。如需确定原因，请检查分析器在日志中打印的摘要。
UNRECOVERABLE_ERROR：MXLA 挂起是由无法恢复的错误引起的。分析器还会报告显示问题的具体实例。检查出现不可恢复错误的实例的错误日志。如果错误似乎是特定于给定机器的（例如，无法将数据从 TPU 复制到主机），则需要配置作业以避开这些主机。如果错误日志未表明此问题与特定机器相关，则问题可能出在应用层面。
UNKNOWN：检测到 MXLA 挂起，但尚未确定潜在原因。

系统指标

对于每次工作负载监控机器学习运行，Cloud Monitoring 都会自动以 1 分钟的间隔收集系统指标。这些系统指标可提供额外信息，以便与工作负载事件相关联，并与分析器结果一起进行更深入的分析。系统指标包括：

TPU 设备指标：工作周期 (node/accelerator/duty_cycle)、TensorCore 利用率 (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 控制台中查看由 ML 诊断工作负载监控功能监控的运行，这些运行既位于Cluster Director 下，也位于 GKE 下

如需在 Cluster Director 中查看所有机器学习运行作业，请执行以下操作：

在 Google Cloud 控制台中，前往 Cluster Director 页面。
点击运行诊断标签页。

前往 Cluster Director 运行诊断

如需查看 Google Kubernetes Engine 中的所有机器学习运行，请执行以下操作：

在 Google Cloud 控制台中，前往 Kubernetes 页面。
在导航菜单中，点击 AI/ML。
点击运行诊断标签页。

前往 GKE AI/ML 运行诊断

Cluster Director 和 GKE 控制台会显示以下信息：

运行摘要：此表格包含由工作负载监控为 GKE 作业创建的每次运行的名称。系统会自动使用 job-name-timestamp 格式为运行命名。
运行详情（监控概览）：选择一个机器学习运行作业，即可在“监控概览”标签页中查看详细信息。此标签页包含：
- TPU 汇总占空比：机器学习运行的 TPU 汇总占空比图。
- 事件时间轴：影响 ML 运行的所有事件的时间轴，包括性能下降、挂起、编排器中断和终止。
- “事件”表格：此表格总结了影响机器学习运行的事件。对于每个活动，它包含：
  - 事件名称和活动类型。
  - 活动的开始时间和结束时间。
  - 指向分析器提供的详细信息的链接。
- 活动详情：选择活动的查看详情，即可查看该活动的所有分析器结果。
- 系统指标：从 Cloud Monitoring 自动提取的系统指标列表（提取间隔为 1 分钟），或由 ML Diagnostics SDK 以更精细的粒度记录的系统指标列表

通过 Google Cloud CLI 访问工作负载监控信息

对于每个 GKE 作业，工作负载监控都会在 ML 诊断中自动创建一个机器学习运行，其 ML 运行名称采用 job-name-timestamp 格式。您可以使用 ML Diagnostics gcloud CLI 命令（例如 Describe、List、Delete 和 Update）查看项目中创建的所有 ML 运行、获取这些运行的详细信息，以及删除或更新 ML 运行的属性。

此外，您还可以使用 monitored-events Google Cloud CLI 命令列出工作负载监控功能检测到的所有事件，并检索每个事件的分析器详细信息。如需了解详情，请参阅使用 ML Diagnostics CLI。

通过 API 访问工作负载监控信息

您可以通过 MonitoredEvent API 的“GET”方法访问工作负载监控检测到的事件。

列出所有受监控的事件

如需列出给定 ML 运行的所有受监控事件 (MonitoredEvent)，请使用 /v1alpha/{parent=projects/*/locations/*/machineLearningRuns/*}/monitoredEvents 端点的“GET”方法。

以下是一个示例请求：

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) 的详细信息，请向 /v1alpha/{parent=projects/*/locations/*/machineLearningRuns/*}/monitoredEvents/* 端点发送“GET”请求。

以下是一个示例请求：

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
 ]
}