0. 核心观点
GPU 推理平台的可观测性不能停留在“GPU 利用率曲线”。对业务来说，真正重要的是请求排队、首 token 延迟、吞吐、错误率、成本和容量余量。GPU 指标只解释了一部分现象；如果不能与 Kubernetes 调度、模型服务指标和业务 SLO 关联，SRE 只能看到资源忙，却不知道用户为什么慢。
本文的判断是：Kubernetes GPU 平台需要从节点指标走向推理链路观测，把 DCGM、Prometheus/OpenTelemetry、模型服务和业务 SLO 放在同一个闭环里。
1. 背景与问题定义
AI 推理工作负载与传统 Web 服务不同。它的延迟受模型大小、batching、KV cache、上下文长度、GPU 显存、队列策略和调度拓扑共同影响。仅看 CPU、内存和 Pod 重启次数远远不够；仅看 GPU utilization 也可能误导，因为高利用率可能是健康吞吐，也可能是队列拥塞和显存碎片。
2. 指标分层
| 层级 | 关键指标 | 解释的问题 |
|---|---|---|
| GPU 设备 | utilization、memory used、SM occupancy、temperature、ECC | 节点是否健康、显存是否逼近上限 |
| Kubernetes | pending pod、node allocatable、GPU plugin 状态 | 调度是否受限、资源是否碎片化 |
| 模型服务 | queue time、time to first token、tokens/sec、batch size | 慢在排队、预填充还是解码 |
| 业务 SLO | p95 latency、error budget、cost per request | 用户体验与成本是否可接受 |
真正有效的 dashboard 应允许从业务延迟下钻到模型实例，再下钻到 Pod、节点和 GPU 设备，而不是把这些指标分散在不同页面。
3. 工程化设计
推荐以 DCGM Exporter 或等价组件采集 GPU 设备指标，以模型服务暴露推理指标，以 OpenTelemetry 贯穿请求 trace。Prometheus 适合指标聚合，日志系统保存错误上下文，trace 关联单次请求在网关、队列、模型服务中的路径。
observability_contract:
labels:
required: [cluster, namespace, model, model_version, gpu_type, node, tenant_hash]
metrics:
gpu: [utilization, memory_used, ecc_errors]
inference: [queue_ms, ttft_ms, output_tokens_per_second, batch_size]
business: [p95_latency_ms, error_rate, cost_per_1k_tokens]
traces:
propagate: [trace_id, tenant_id, model_version]| 观测缺口 | 表面现象 | 真正要补的指标 | 处置动作 |
|---|---|---|---|
| 只看 GPU utilization | GPU 很忙但用户仍慢 | queue_ms、ttft_ms、decode_tokens/s | 扩副本、调整 batch、拆模型池 |
| 只看 Pod 状态 | Pod Running 但推理失败 | model_load_error、kv_cache_used、oom_count | 回滚模型或降低上下文 |
| 缺少统一标签 | 无法定位哪个租户/模型烧钱 | tenant_hash、model_version、gpu_type、node | 成本归因和配额治理 |
| trace 记录过度 | 排障时泄露 prompt | redacted span attributes | 只保留 metadata 与 hash |
4. 最小可复现实验：先把指标标签契约固定下来
即使暂时没有 GPU 集群，也可以先验证观测契约是否完整。下面是一条推理请求应携带的最小指标标签；如果缺少 model_version、tenant_hash 或 gpu_type，后续就无法把延迟、成本和容量问题关联起来。
inference_request_latency_ms{
cluster="prod-a",
namespace="llm-serving",
model="qwen3",
model_version="2026-06-08-01",
gpu_type="l40s",
tenant_hash="t_8f3a",
route="chat"
} 842可以在 CI 中对 Prometheus exposition 做静态检查：
required = {"cluster", "namespace", "model", "model_version", "gpu_type", "tenant_hash"}
labels = {"cluster", "namespace", "model", "model_version", "gpu_type", "tenant_hash", "route"}
assert required <= labels这个实验没有替代 DCGM 或真实 GPU 压测，但它先锁住了可观测性的地基：指标维度一旦缺失，后面再漂亮的 dashboard 都只能看热闹，不能定位到模型版本、租户、节点池和成本归因。
5. SLO 闭环
可观测性闭环的终点不是告警，而是动作：扩容、降级、回滚、限流或容量采购。每一种动作都应有触发条件和副作用说明。例如，增大 batch 可能提升吞吐但拉高首 token 延迟；量化可能降低显存压力但影响某些任务质量。
6. 风险与安全边界
推理可观测性也会带来数据风险。日志和 trace 不能包含完整 prompt、用户上传文件或模型输出明文。对于多租户平台，tenant_hash 这类脱敏租户标签必须能支持隔离分析，但不能泄露客户名称或敏感业务字段。采样策略也要分级：错误样本可以记录更详细的结构化元数据，但敏感字段仍需脱敏。
另一个边界是成本可见性。GPU 利用率高不代表成本健康，如果模型版本、上下文长度和 token 输出不可见，平台团队无法解释账单增长。建议把 cost per request、cost per tenant_hash 和 cost per model 作为一等指标。
结论
Kubernetes GPU 推理平台的可观测性闭环不是指标越多越好，而是要让延迟、利用率、成本和错误之间形成可下钻的关联。当 p95 延迟飙升时，能定位到是 queue 堆积、decode 瓶颈还是显存碎片；当成本超支时，能拆分到租户、模型版本和 GPU 类型。这才是平台团队该建的工程能力。
