{"id":"4816b5b1-ebf3-4dcd-a384-7e6770dd6de8","slug":"gke-ai-troubleshooting-tpu-performance-degradation","kind":"skill","name":"gke-ai-troubleshooting-tpu-performance-degradation","summary":"Diagnose GKE Cloud TPU training throughput drops and step-time regressions (15%+ TPU duty-cycle drop) using ML Diagnostics Workload Monitoring (`gcloud alpha mldiagnostics monitored-events` / `hyperco","owner":"google","repoUrl":"https://github.com/google/skills/tree/HEAD/skills/cloud/gke-ai-troubleshooting-tpu-performance-degradation","license":"Apache-2.0","licenseTier":"permissive","trust":"official","stars":21260,"match":null,"fewStars":false,"format":"skill","createdAt":null,"addedAt":"2026-10-14T05:34:35.741Z","logoUrl":"https://avatars.githubusercontent.com/u/1342004?v=4","linkOnly":false,"collection":{"name":"skills","repo":"google/skills"},"skillPath":"skills/cloud/gke-ai-troubleshooting-tpu-performance-degradation","categories":["cloud-infra","data-analytics","memory-knowledge"],"tags":["google","googlecloud"],"runtime":"binary","local":true,"cloudCapable":false,"cloudCapability":"unknown","cloudReadyOnPlatform":false,"needsApiKey":false,"reviewed":false,"syncedAt":"2026-10-14T05:34:35.739Z","sample":false,"url":"https://conduits.dev/tools/gke-ai-troubleshooting-tpu-performance-degradation","language":"Python","transports":[],"install":{},"requirements":{"env":[],"upstreamMayCharge":false},"tools":null,"readme":"> Diagnose GKE Cloud TPU training throughput drops and step-time regressions (15%+ TPU duty-cycle drop) using ML Diagnostics Workload Monitoring (`gcloud alpha mldiagnostics monitored-events` / `hypercomputecluster.googleapis.com/v1alpha`) and 1-minute Cloud Monitoring system metrics (`kubernetes.io/node/accelerator/*`). Distinguishes hardware and network fabric throttling from workload resource bottlenecks (HBM capacity, host memory, or host CPU saturation). Use when TPU training throughput or duty cycle drops without crashing pods, when `PERFORMANCE_DEGRADATION` monitored events fire, or when triaging slow multi-slice training steps. Don't use for complete multi-slice XLA execution stalls with `HANG_DETECTED` logs (use gke-ai-troubleshooting-tpu-mxla-hang) or pod eviction/interruption restarts (use gke-ai-troubleshooting-jobset-interruption).\n\n# Troubleshoot GKE TPU performance degradation with ML Diagnostics Workload Monitoring\n\nDiagnose and mitigate Cloud TPU training throughput drops and step-time\nregressions (`15%+` drop in TPU duty cycle) on Google Kubernetes Engine (GKE) by\ncorrelating **ML Diagnostics Workload Monitoring** `MonitoredEvent` analyzer\nreports with **1-minute Cloud Monitoring system metrics** and GKE node topology\nlabels.\n\n---\n\n## Prerequisites\n\n- **Tools**: Install the\n  [Google Cloud SDK](https://cloud.google.com/sdk/docs/install) (`gcloud` with\n  `alpha` component for `gcloud alpha mldiagnostics`) and `kubectl`.\n- **Cloud Billing & Project Configuration**: Verify an active billing account is\n  linked (`gcloud billing projects describe {project_id}`), authenticate\n  (`gcloud auth login`), set the target project (`gcloud config set project\n  {project_id}`), and ensure `container.googleapis.com`,\n  `monitoring.googleapis.com`, and `hypercomputecluster.googleapis.com` are\n  enabled.\n- **Supported workloads and GKE versions**: Google Cloud ML Diagnostics only\n  supports JAX on TPUs (see\n  [ML Diagnostics platform](https://docs.cloud.google.com/tpu/docs/ml-diagnostics/overview.md.txt)).\n  Workload Monitoring is enabled by default, supports the `jobset` and `job` GKE\n  job types, and is compatible with GKE versions `1.36.0-gke.4681000` and later,\n  as stated in\n  [Configure GKE for ML Diagnostics](https://docs.cloud.google.com/tpu/docs/ml-diagnostics/gke.md.txt).\n  If a workload uses another framework (such as PyTorch) or another custom\n  resource type, `gcloud alpha mldiagnostics` won't list ML runs or monitored\n  events for it. On-demand profiling (Step 4 Path A) additionally requires the\n  cluster setup described in that document.\n- **Required IAM Roles**:\n  - Cluster Director Editor (`roles/hypercomputecluster.editor`), the role\n    listed in the \"IAM permissions\" section of\n    [ML Diagnostics platform](https://docs.cloud.google.com/tpu/docs/ml-diagnostics/overview.md.txt),\n    for the ML Diagnostics CLI and API calls in this skill (ML runs, monitored\n    events, and on-demand profiler sessions)\n  - Monitoring Viewer (`roles/monitoring.viewer`) for the PromQL queries in Step\n    2\n  - Kubernetes Engine Viewer (`roles/container.viewer`) for the `kubectl get\n    nodes` query in Step 3\n  - For remediation (`[High Risk]` steps): Kubernetes Engine Cluster Admin\n    (`roles/container.clusterAdmin`)\n- **Reference Documentation**:\n  - [ML Diagnostics platform](https://docs.cloud.google.com/tpu/docs/ml-diagnostics/overview.md.txt)\n    (Sections: \"IAM permissions\")\n  - [Configure GKE for ML Diagnostics](https://docs.cloud.google.com/tpu/docs/ml-diagnostics/gke.md.txt)\n    (Sections: \"Set up with gcloud CLI, Google Cloud console, or Terraform\",\n    \"Manual installation\", \"Connection-operator\")\n  - [Workload monitoring with ML Diagnostics](https://docs.cloud.google.com/tpu/docs/ml-diagnostics/workload-monitoring.md.txt)\n    (Sections: \"Workload Monitoring and analyzers\", \"HBM Capacity Analyzer\",\n    \"Host Memory Utilization Analyzer\", \"CPU Utilization Analyzer\", \"Access\n    Workload Monitoring information through the API\", \"List all monitored\n    events\", \"System Metrics\")\n  - [Get started with the ML Diagnostics CLI](https://docs.cloud.google.com/tpu/docs/ml-diagnostics/cli.md.txt)\n    (Sections: \"List machine learning runs\", \"Monitored-events commands\", \"List\n    profiler targets\", \"Capture on-demand profiler sessions\")\n  - [Scale container resource requests and limits](https://docs.cloud.google.com/kubernetes-engine/docs/how-to/vertical-pod-autoscaling.md.txt)\n    (Sections: \"Identify workloads without resource requests or limits\")\n  - [Auto-repair nodes](https://docs.cloud.google.com/kubernetes-engine/docs/how-to/node-auto-repair.md.txt)\n    (Sections: \"Repair criteria\", \"Verify node auto-repair is enabled for a\n    Standard node pool\", \"Enable auto-repair for an existing Standard node\n    pool\", \"Node auto repair in TPU slice nodes\")\n  - [Deploy TPU workloads in GKE Standard](https://docs.cloud.google.com/kubernetes-engine/docs/how-to/tpus.md.txt)\n    (Sections: \"Configure auto repair for TPU slice nodes\")\n  - [Get support](https://docs.cloud.google.com/kubernetes-engine/docs/getting-support.md.txt)\n    (Sections: \"Before you contact support\")\n\n> **Read-only rule**: Run read-only diagnostic commands only. Never drain,\n> delete, or re-create nodes, or run any other command that changes the cluster.\n> Give the user any fix to apply themselves.\n\nWhen you recommend a fix, link the doc section that describes it.\n\n---\n\n## Analyzer routing overview\n\nBy default, Workload Monitoring treats a 15% drop in TPU duty cycle as a\nperformance degradation, raises a `MonitoredEvent` (`type:\nPERFORMANCE_DEGRADATION`), and runs its analyzers. Consult the\n[Workload Monitoring and analyzers](https://docs.cloud.google.com/tpu/docs/ml-diagnostics/workload-monitoring.md.txt)\nsection in the official Cloud TPU documentation for the complete analyzer\ndefinitions, detection criteria, and subsections, and route remediation by\ncategory:\n\n- **Category A: workload resource bottlenecks (never cordon or replace nodes)**:\n  - When the firing analyzer (`detectionState: \"DETECTED\"`) indicates a workload\n    memory or host CPU capacity bottleneck (see the \"HBM Capacity Analyzer\",\n    \"Host Memory Utilization Analyzer\", and \"CPU Utilization Analyzer\" sections\n    of\n    [Workload monitoring with ML Diagnostics](https://docs.cloud.google.com/tpu/docs/ml-diagnostics/workload-monitoring.md.txt)),\n    route to\n    [Path A: Workload resource bottlenecks](references/path-a-workload-bottlenecks.md)\n    (workload optimization and profiling).\n- **Category B: infrastructure and network fabric throttling (culprit nodes)**:\n  - When the firing analyzer (`detectionState: \"DETECTED\"`) indicates an\n    interconnect, thermal/power throttling, memory bandwidth, or Top-of-Rack\n    (ToR) network fault on specific instances (see\n    [Workload Monitoring and analyzers](https://docs.cloud.google.com/tpu/docs/ml-diagnostics/workload-monitoring.md.txt)),\n    route to\n    [Path B: Infrastructure or network fabric throttling](references/path-b-infrastructure-throttling.md)\n    (map the culprit Compute Engine instance IDs to GKE nodes, handle node\n    repair through GKE, and escalate to Google Cloud Support).\n- **Category C: `PERFORMANCE_DEGRADATION` event fired, but no analyzer reports\n  `detectionState: \"DETECTED\"`**:\n  - When a `PERFORMANCE_DEGRADATION` event exists (as in the sample output in\n    [List all monitored events](https://docs.cloud.google.com/tpu/docs/ml-diagnostics/workload-monitoring.md.txt),\n    where `analyzerReports` entries have `detectionState: \"NOT_DETECTED\"`),\n    route to\n    [Path C: Event fired with no DETECTED analyzer](references/path-c-no-detected-analyzer.md).\n\n---\n\n## Diagnostic workflow\n\n### Step 0: Collect context and set the investigation window `[Low Risk]`\n\nCollect the target parameters. By default, query a 60-minute window `[T - 30m, T\n+ 30m]` around `{issue_time}`:\n\n- `{project_id}`: Google Cloud project ID\n- `{location}`: Google Cloud region where the ML run and GKE cluster reside (for\n  example, `us-central1`)\n- `{cluster_name}`: GKE cluster name\n- `{workload_name}` / `{ml_run_id}`: JobSet / workload name or ML Diagnostics\n  run ID\n- `{issue_time}`: Timestamp when throughput degradation was observed (`T`,\n  ISO-8601 UTC)\n- `{start_time}`: `T - 30m`\n- `{end_time}`: `T + 30m`\n\n---\n\n### Step 1: Query ML runs and `monitoredEvents` `[Low Risk]`\n\n1. **List active or recent ML runs**: Give the user `gcloud alpha mldiagnostics\n   machine-learning-run list` with a link to\n   [List machine learning runs](https://docs.cloud.google.com/tpu/docs/ml-diagnostics/cli.md.txt)\n   in the ML Diagnostics CLI reference, and locate `{ml_run_id}` matching\n   `{workload_name}`.\n2. **List performance degradation events**: Give the user `gcloud alpha\n   mldiagnostics monitored-events list` with a link to\n   [Monitored-events commands](https://docs.cloud.google.com/tpu/docs/ml-diagnostics/cli.md.txt),\n   or the `hypercomputecluster.googleapis.com/v1alpha` API with a link to\n   [Access Workload Monitoring information through the API](https://docs.cloud.google.com/tpu/docs/ml-diagnostics/workload-monitoring.md.txt),\n   to check for `PERFORMANCE_DEGRADATION` events during `[{start_time},\n   {end_time}]`.\n3. **Describe the `MonitoredEvent`**: Give the user `gcloud alpha mldiagnostics\n   monitored-events describe` with a link to the same\n   [Monitored-events commands](https://docs.cloud.google.com/tpu/docs/ml-diagnostics/cli.md.txt)\n   section, and inspect the `analyzerReports` array (`analyzer`,\n   `detectionState`, `details`, and `recommendedActions`).\n   - If a `PERFORMANCE_DEGRADATION` event fired, run Step 2 to corroborate with\n     the 1-minute system metrics; if none of its `analyzerReports` entries has\n     `detectionState: \"DETECTED\"`, follow\n     [Path C: Event fired with no DETECTED analyzer](references/path-c-no-detected-analyzer.md).\n   - If no `PERFORMANCE_DEGRADATION` event exists and duty cycle is steady in\n     Step 2, **rule out** TPU performance degradation by following\n     [Path D: Healthy telemetry](references/path-d-healthy-telemetry.md).\n\n---\n\n### Step 2: Correlate with 1-minute Cloud Monitoring system metrics `[Low Risk]`\n\nConsult the\n[System Metrics](https://docs.cloud.google.com/tpu/docs/ml-diagnostics/workload-monitoring.md.txt)\nsection in the Workload Monitoring documentation for the 1-minute Cloud\nMonitoring metrics exported for TPU and host devices, and run read-only PromQL\nqueries over `[{start_time}, {end_time}]` to corroborate the analyzer report:\n\n```promql\n# 1. Node TPU duty cycle (look for the drop on the affected nodes)\nkubernetes_io:node_accelerator_duty_cycle{\n  monitored_resource=\"k8s_node\",\n  project_id=\"{project_id}\",\n  cluster_name=\"{cluster_name}\"\n}\n\n# 2. HBM utilization ratio by node (around 0.90 is approaching the limit)\nsum by (node_name) (\n  kubernetes_io:node_accelerator_memory_used{\n    monitored_resource=\"k8s_node\",\n    project_id=\"{project_id}\",\n    cluster_name=\"{cluster_name}\"\n  }\n)\n/\nsum by (node_name) (\n  kubernetes_io:node_accelerator_memory_total{\n    monitored_resource=\"k8s_node\",\n    project_id=\"{project_id}\",\n    cluster_name=\"{cluster_name}\"\n  }\n)\n\n# 3. Host memory and CPU allocatable utilization\nkubernetes_io:node_memory_allocatable_utilization{\n  monitored_resource=\"k8s_node\",\n  project_id=\"{project_id}\",\n  cluster_name=\"{cluster_name}\"\n}\n\nkubernetes_io:node_cpu_allocatable_utilization{\n  monitored_resource=\"k8s_node\",\n  project_id=\"{project_id}\",\n  cluster_name=\"{cluster_name}\"\n}\n```\n\n---\n\n### Step 3: Map culprit instance IDs to GKE nodes and topology `[Low Risk]`\n\nWhen an infrastructure analyzer reports culprit numeric Compute Engine instance\nIDs in `details` or `recommendedActions`, map those numeric instance IDs to GKE\n`Node` names and physical topology blocks using this read-only `kubectl` query\ninspecting `container.googleapis.com/instance_id`:\n\n```bash\nkubectl get nodes -l cloud.google.com/gke-tpu-accelerator \\\n  -o jsonpath='{range .items[*]}{.metadata.name}{\"\\tinstance_id=\"}{.metadata.annotations.container\\.googleapis\\.com/instance_id}{\"\\tblock=\"}{.metadata.labels.cloud\\.google\\.com/gce-topology-block}{\"\\tsubblock=\"}{.metadata.labels.cloud\\.google\\.com/gce-topology-subblock}{\"\\thost=\"}{.metadata.labels.cloud\\.google\\.com/gce-topology-host}{\"\\n\"}{end}'\n```\n\n---\n\n### Step 4: Remediation by analyzer category\n\nLoad and follow only the reference file that matches the analyzer category from\nStep 1:\n\n- **Path A (workload resource bottlenecks — HBM, host memory, or host CPU\n  utilization)**: Read\n  [Path A: Workload resource bottlenecks](references/path-a-workload-bottlenecks.md).\n- **Path B (infrastructure, thermal, ICI, memory bandwidth, or network fabric\n  throttling)**: Read\n  [Path B: Infrastructure or network fabric throttling](references/path-b-infrastructure-throttling.md).\n- **Path C (`PERFORMANCE_DEGRADATION` event fired with all analyzers\n  `NOT_DETECTED`)**: Read\n  [Path C: Event fired with no DETECTED analyzer](references/path-c-no-detected-analyzer.md).\n- **Path D (no `PERFORMANCE_DEGRADATION` events and steady telemetry)**: Read\n  [Path D: Healthy telemetry](references/path-d-healthy-telemetry.md).\n\n---\n\n## Guardrails\n\n1. **Never change GKE-managed instance groups or VMs through Compute Engine**:\n   Don't run `gcloud compute instance-groups managed` commands, such as\n   `delete`, on a node pool's managed instance group. Handle nodes through GKE,\n   as described in\n   [Path B: Infrastructure or network fabric throttling](references/path-b-infrastructure-throttling.md).\n2. **Never cordon nodes for workload resource saturation**: If only the HBM\n   capacity, host memory, or host CPU utilization analyzers detected an issue,\n   don't cordon or replace nodes."}