GPU 利用率不是终点，Token 成本才是 AI 基础设施真正的北极星指标。
过去几年，AI 基础设施领域最热门的话题之一是 GPU 调度。无论是 Kubernetes、Volcano、Kueue，还是 HAMi，本质上都在解决同一个问题——如何让昂贵且稀缺的 GPU 被更高效地利用。
但随着越来越多企业开始运行生产级大语言模型（LLM）服务，一个新的现象开始出现：GPU 利用率很高，但用户仍然抱怨系统响应慢；GPU 集群已经接近满载，但业务吞吐量却没有同步增长；显存和算力都还有余量，TTFT（Time To First Token，首 Token 延迟）却持续恶化。这说明一个问题——GPU 利用率已经不足以描述现代 AI 系统的真实运行状态。
对于传统云原生应用来说，我们关注的是 CPU、内存、网络和磁盘。而对于 AI 系统而言，我们还需要关注：GPU 是否真正完成了有效计算、NCCL（NVIDIA Collective Communications Library）通信是否成为瓶颈、Kubernetes 是否正确分配了资源、KV Cache 是否已经耗尽、Token 延迟是否满足用户体验要求、每个 Token 的成本是否合理。换句话说，AI 基础设施的观测对象已经从 GPU 扩展到了整个推理链路。
最近我在参与中国信息通信研究院（CAICT）组织的《算力效能提升技术能力要求：异构算力服务》行业标准制定工作时，与多位专家讨论中反复提到一个核心问题：GPU 和 Token 到底怎样联系起来？如何通过 Token 来衡量 GPU 的产出？ 标准中提出了“词元即服务（Token as a Service）”的概念，将算力服务的度量单位从传统的 GPU 小时推向了 Token，但如何建立从底层硬件到上层 Token 的完整可观测链路，仍然缺乏成熟的实践框架。
恰好在研究这个问题时，看到一篇关于 GPU 与 LLM 可观测性的技术文章（GPU & LLM Inference Observability — Layer-by-Layer Coverage），提出了一个很有建设性的思路：将 AI 系统拆分为从 GPU 硬件到业务成本的八个观测层次，恰好填补了从 GPU 到 Token 之间的观测空白。本文在原文基础上进行了重新整理和解读，去除了具体产品实现细节和厂商推广内容，并结合 Kubernetes、HAMi 与现代 LLM 推理架构，对这套模型进行了扩展。
希望通过这篇文章回答一个问题：
当我们解决了 GPU 调度问题之后，下一步应该观测什么？
八层可观测性架构概览
下面展示了从 GPU 硬件到业务成本的八层观测栈，每一层对应不同的观测对象和责任域：
原图来源 GitHub，基于原图翻译并修改。
各层通过 OTel Collector 统一采集数据，分别输出到指标后端、链路追踪后端和日志后端，形成完整的观测闭环。以下逐层展开。
L1 GPU 硬件层
这一层关注 GPU 本身，核心问题是：GPU 是否健康运行？
下表列出了 GPU 硬件层的核心观测指标：
| 分类 | 核心指标 |
|---|---|
| Compute | GPU Utilization、SM Occupancy、Tensor Core Activity |
| Memory | VRAM Usage、HBM Bandwidth |
| Interconnect | NVLink Throughput、PCIe Throughput |
| Reliability | ECC Error、XID Error |
| Thermal | Temperature、Power Draw、Throttle Reason |
很多团队只关注 GPU Utilization，但需要注意一个关键区分——GPU Utilization ≠ GPU Efficiency。两个 GPU 都可能显示 90% Utilization：一个正在执行 Tensor Core 运算，一个正在等待内存访问，最终性能可能完全不同。因此 SM（Streaming Multiprocessor）Occupancy 与 Tensor Core Activity 往往比 Utilization 更有价值。
L2 CUDA 运行时与通信层
对于分布式训练而言，GPU 计算通常不是瓶颈，通信才是。这一层的核心问题是：GPU 在计算，还是在等待其他 GPU？
下表列出了 CUDA 运行时与通信层的关键指标：
| 分类 | 指标 |
|---|---|
| NCCL | AllReduce、AllGather、ReduceScatter |
| Communication | Duration、Bandwidth |
| Kernel | Execution Time、P99 Duration |
| Straggler | Rank Skew |
在大规模训练场景中，一个慢节点就可能拖慢整个训练任务。通过监控 NCCL 通信的 Duration 和 Bandwidth，以及各 Rank 之间的 Skew，可以快速定位通信瓶颈。
L3 宿主机与操作系统层
很多 GPU 问题最终都不是 GPU 问题。当 GPU 利用率异常时，原因可能在宿主机的 CPU、内存、磁盘或网络层面。
下表列出了宿主机层面的关键指标：
| 分类 | 指标 |
|---|---|
| CPU | Utilization、IO Wait |
| Memory | Usage、Swap |
| Disk | Throughput、Latency |
| Network | Retransmit、Bandwidth |
| Process | RSS、Thread Count |
一个常见的误区是：GPU 利用率低，第一反应是 GPU 不够快。实际上经常是 GPU 正在等待数据——DataLoader 太慢、CPU 不足、网络拥塞或存储性能不足，都可能导致 GPU 处于等待状态。
L4 Kubernetes 与调度层
这一层是云原生 AI 基础设施的核心，要回答的问题是：GPU 属于谁？ 需要明确哪个 Pod 正在使用 GPU、哪个 Namespace 消耗最多资源、哪个团队成本最高、哪个模型占用了最多显存。
下表列出了调度层的关键观测维度：
| 分类 | 关键属性 |
|---|---|
| Ownership | Pod、Container |
| Workload | Deployment、Job |
| Organization | Namespace、Team |
| Scheduling | GPU Sharing、GPU Partition |
| Topology | Node、AZ、Region |
HAMi、Volcano、Kueue 等项目主要工作在这一层。HAMi 解决 GPU Sharing、GPU Partitioning 和异构 GPU 调度等核心问题，而可观测性则负责回答：调度之后是否真正提升了资源利用率？ 这一层的观测数据是资源审计和成本分摊的基础。
L5 训练运行时层
训练阶段需要关注模型本身的运行状态。下表列出了训练运行时的关键指标：
| 分类 | 指标 |
|---|---|
| Efficiency | MFU、TFLOPS、Step Time |
| Gradient | Norm、NaN、Inf |
| Loss | Training Loss |
| Data | DataLoader Wait |
| Checkpoint | Save Time、Restore Time |
其中最重要的是 MFU（Model FLOPs Utilization，模型算力利用率）。很多训练任务 GPU 利用率很高，但 MFU 只有 30%，这意味着大量 GPU 时间并没有转化成实际训练进度。MFU 是衡量训练效率的黄金指标，它直接反映了硬件算力转化为有效训练计算的比例。
L6 推理引擎层
这是生产环境最关键的一层，也是目前行业关注度增长最快的一层。下表列出了推理引擎的核心指标：
| 指标 | 含义 |
|---|---|
| TTFT | Time To First Token |
| ITL | Inter Token Latency |
| Queue Wait | 请求排队时间 |
| Throughput | Token 吞吐量 |
| Batch Size | 批处理效率 |
| KV Cache Usage | KV Cache 利用率 |
很多团队仍然只关注 GPU Utilization，而推理系统真正的容量指标往往是 KV Cache（Key-Value Cache）Utilization。
为什么 KV Cache 比 GPU Utilization 更重要
在现代 LLM 推理系统中，GPU 算力通常还有余量，但 KV Cache 往往先耗尽。典型现象是：GPU 利用率只有 60%，KV Cache 已经达到 95%，新请求开始排队，TTFT 快速上升。
对于推理系统而言，KV Cache 更接近于数据库中的 Buffer Pool——它往往决定整个系统的容量上限。当 KV Cache 接近饱和时，系统不得不进行 Eviction（驱逐），这会导致上下文丢失、请求重试，最终表现为延迟飙升和吞吐下降。
L7 生成式 AI API 层
随着 OpenTelemetry GenAI Semantic Conventions 的发展，行业正在形成统一的 AI 可观测性标准。下表列出了 API 层的关键指标：
| 指标 | 含义 |
|---|---|
| Input Tokens | 输入 Token |
| Output Tokens | 输出 Token |
| Request Duration | 请求耗时 |
| TTFT | 首 Token 延迟 |
| Token Throughput | Token 吞吐量 |
这一层开始从基础设施视角转向应用视角。API 层的指标直接面向终端用户和业务系统，是服务质量评估（SLA/SLO）的核心数据来源。
L8 业务与成本层
最终企业关心的不是 GPU 利用率，而是：GPU 是否创造了价值？ 下表列出了业务与成本层的核心指标：
| 指标 | 含义 |
|---|---|
| Cost per GPU Hour | GPU 小时成本 |
| Cost per Token | Token 成本 |
| Cost per Request | 请求成本 |
| Idle GPU Cost | 空闲成本 |
| Tokens per Watt | 推理效率 |
未来 AI 基础设施竞争的核心指标，很可能不是 GPU Utilization，而是 Cost per Useful Token——每产生一个有效 Token 的综合成本。这个指标将硬件成本、能源消耗、推理效率和业务价值统一在一个度量体系内。
跨层故障排查
真正的生产问题往往跨越多个层次。下表列出了常见的跨层故障现象及其可能原因：
| 现象 | 可能原因 |
|---|---|
| TTFT 升高 | CPU IO Wait、Queue Depth、KV Cache Pressure |
| Throughput 降低 | NCCL、Batch Size、Network |
| Latency Spike | KV Cache Eviction |
| OOM | VRAM 不足、Batch 过大 |
| Training Stall | NCCL Straggler |
现代 AI 运维正在从单点监控演变为跨层观测。单层指标异常的根因往往在其他层，只有建立跨层关联能力，才能实现快速定位和精准排障。
从 GPU 控制面到 AI 可观测面
过去几年行业主要关注 Kubernetes Scheduler、Volcano、Kueue、HAMi 等项目，解决的是 GPU 如何分配 的问题。未来几年行业会开始关注 GPU 是否真正产生价值，因此 AI 基础设施正在形成新的技术栈：
GPU Hardware
↓
Kubernetes Control Plane
↓
Inference Runtime
↓
Observability Plane
↓
Optimization PlaneGPU 调度决定资源如何分配，Observability 决定资源是否被正确使用，而这两者共同构成下一代 AI Infrastructure Stack。从 GPU Control Plane 到 AI Observability Plane 的演进，标志着 AI 基础设施从“资源管理”走向“价值管理”的新阶段。
总结
AI 基础设施的可观测性正在经历一次根本性的范式转变。过去我们只看 GPU 利用率，现在需要从 GPU 硬件、CUDA 运行时、宿主机操作系统、Kubernetes 调度、训练运行时、推理引擎、GenAI API 到业务成本八个层次建立完整的观测体系。
关键要点回顾：
- L1-L3 关注硬件与系统：GPU 健康状态、CUDA 通信效率、宿主机资源是否充足
- L4 关注资源分配：Kubernetes 调度和 GPU 共享是否合理，HAMi 等工具解决分配问题
- L5-L6 关注模型运行：训练效率（MFU）和推理容量（KV Cache）是核心指标
- L7-L8 关注业务价值：从 Token 吞吐到每 Token 成本，最终衡量 GPU 是否创造了价值
GPU 调度是 AI 基础设施的起点，但不是终点。从 GPU 到 Token 的八层可观测性体系，才是确保 AI 基础设施真正创造业务价值的关键闭环。
