可观测与计量：你必须回答的十个问题
只有能被解释、能被治理、能被结算的资源体系，才是真正可运营的 GPU 平台。
为什么要把“观测与计量”单独成章
在 GPU 平台化过程中，常见的误区是认为“调度器装上了、Pod 能跑了”就代表系统已经可用。然而，随着多租户、资源共享和在线推理的引入，平台的核心矛盾会从“有没有 GPU”转变为“能不能解释、能不能治理、能不能结算”。
观测与计量的目标并非简单堆砌指标，而是建立一种可运营的可解释性。当资源冲突发生、吞吐下降、P99 抖动或成本失控时，平台需要能够快速回答“发生了什么、影响了谁、要不要干预、怎么恢复、怎么追责/结算”。
本章将梳理你必须回答的十个关键问题，并针对每个问题明确指标口径、数据源、实现路径和验收标准。
十个必须回答的问题
以下十个问题按照“资产视角 → 组织视角 → 工作负载视角 → 体验视角 → 财务视角”分层。对于任何即将上线的 GPU 平台，建议至少能够回答其中 6–7 个问题。
当前 GPU 平台运营中最核心的十个问题如下：
- 现在是谁在占用 GPU？占用的是哪张卡/哪个 MIG slice/哪个 vGPU？
- 占用了多少？是显存占用、算力占用，还是两者都占？
- 利用率为什么低？是碎片化、排队，还是工作负载本身不吃 GPU？
- 抖动从哪里来？是共享干扰、邻居噪声，还是模型服务负载波动？
- SLA/SLO 是否满足？谁受影响、影响多大？
- 调度与准入是否在按规则运行？配额是否兑现？
- 资源是否被超用或穿透？谁在“偷 GPU”？
- 失败率与恢复成本是多少？OOM、驱动问题、MIG 重配、容器启动失败各占多少？
- 成本如何归因？按租户/团队/项目的 GPU 成本是多少？
- 产能如何规划？未来一周/一月的供需缺口在哪里？
下面将逐条展开说明。
下图展示十个必须回答的问题按五个视角分类。资产视角（蓝色区域）：Q1 谁在占用 GPU（哪张卡/MIG/vGPU）、Q2 占用多少（显存/算力）。组织视角（黄色区域）：Q6 调度与准入是否按规则运行、Q9 成本如何归因（按租户/团队/项目）。工作负载视角（绿色区域）：Q3 利用率为什么低（碎片化/排队/工作负载本身）、Q8 失败率与恢复成本（OOM/驱动/MIG 重配/容器启动失败）。体验视角（紫色区域）：Q4 抖动从哪里来（共享干扰/邻居噪声/负载波动）、Q5 SLA/SLO 是否满足（谁受影响影响多大）。财务视角（橙色区域）：Q7 资源是否被超用或穿透（谁在偷 GPU）、Q10 产能如何规划（未来一周/一月供需缺口）。平台最小可验收版本建议满足 10 条中的 7 条。核心理念：只有能被解释能被治理能被结算的资源体系，才是真正可运营的 GPU 平台。
现在是谁在占用 GPU？占用的是哪张卡/哪个 MIG slice/哪个 vGPU？
明确 GPU 资源的归属，是将 GPU 从“机器上的硬件”转变为“可追踪的资源资产”的基础。最小可行方案是通过 GPU UUID 关联节点、Pod、Namespace 及 Owner。建议以“物理 GPU UUID”为根主键，向上挂载 MIG Instance / vGPU 逻辑单元，再映射到 Pod。
占用了多少？是显存占用、算力占用，还是两者都占？
区分显存与算力的实际占用，有助于避免“看起来用了 GPU，实际只吃显存/只吃算力/反之”的误判。建议分别统计每个 Pod 的显存占用（MB/GB）与算力利用率（SM%），并将“申请配额”与“实际使用”分开，二者差值即为治理对象（浪费/超用）。
利用率为什么低？是碎片化、排队、还是工作负载本身不吃 GPU？
低利用率问题需要从“抱怨”转为“可定位的归因”。建议至少区分三类 idle：无任务、排队等资源、任务在跑但 GPU 不忙。通过对 GPU 空闲时间、队列等待时间、工作负载 CPU/I/O/网络瓶颈时间的分析，实现精准归因。
抖动从哪里来？是共享干扰、邻居噪声、还是模型服务负载波动？
在线推理的 P99 延迟是平台的“信用评分”，抖动不可解释就不可治理。建议关联抖动事件与“同卡共址拓扑”，并构建“干扰系数”（interference factor），结合同卡邻居 Pod 列表、同时段 GPU 指标变化及服务侧延迟曲线（P50/P95/P99）进行分析。
SLA/SLO 是否满足？谁受影响、影响多大？
治理策略（如抢占、限流、隔离）需要有明确的触发条件。建议按租户/服务聚合 SLO 达标率（如 P99 < X ms），并将 SLO 分解到资源层面（GPU、节点、队列），以便于定位和治理。
调度与准入是否在按规则运行？配额是否兑现？
调度过程需要从“黑盒”变为“可审计过程”。建议记录每个 Pod 的调度决策事件（为何成功/为何 Pending）与配额扣减记录，并将“队列等待时间”作为一级运营指标，直接反映平台拥塞或资源不足。
资源是否被超用或穿透？谁在“偷 GPU”？
在共享场景下，需关注“声明一套、实际一套”的现象。建议对配额（requested/allocated）与实际使用（used）进行对账，并设置异常阈值告警。可定义软违规（短时尖峰）与硬违规（持续超额/绕过限制）两类违规。
失败率与恢复成本是多少？OOM、驱动问题、MIG 重配、容器启动失败各占多少？
量化“不可用”是提升平台稳定性的前提。建议按原因分类统计失败次数和平均恢复时间（MTTR），并关注驱动、运行时、设备插件、镜像等对稳定性的影响。
成本如何归因？按租户/团队/项目的 GPU 成本是多少？
没有成本归因，资源治理就缺乏组织抓手。建议以 GPU-hours（按物理卡、MIG、vGPU 的等价口径）按 namespace/owner 聚合，并区分“占用成本”（allocated）与“有效使用成本”（used），以避免激励错误行为。
产能如何规划？未来一周/一月的供需缺口在哪里？
产能规划应以数据驱动，避免拍脑袋决策。建议关注历史队列等待、拒绝率、峰值利用率、碎片率等趋势，并以“可服务的 SLO”为目标进行容量规划，而不仅仅关注“平均利用率”。
指标口径：最容易踩坑的 6 个定义
在实际运营中，以下六个指标定义最容易出现歧义或误用。理解这些口径，有助于避免常见陷阱。
Allocated vs Used
Allocated 指调度分配到 Pod 的配额（治理口径），Used 指实际运行时消耗（性能口径）。Utilization vs Saturation
Utilization 表示 GPU 忙碌的比例，Saturation 则反映需求是否超过供给（排队/拒绝率更能体现）。碎片率（Fragmentation）
并非“剩余显存很少”即为碎片，而是“剩余资源无法满足典型请求”的比例。队列等待时间（Queueing delay）
对平台体验的影响远大于“GPU 平均利用率”，应作为一级运营 KPI。干扰系数（Interference factor）
指同一服务在独占与共享下的吞吐/延迟比值，建议按同卡邻居数量分桶统计。等价 GPU-hour（Normalized GPU-hour）
MIG/vGPU/整卡需有统一换算口径，否则计费与归因难以落地。
数据源：从轻量到体系化
不同阶段的数据采集方案适用于不同规模和成熟度的平台。以下分为三个层级：
Level 0：最小可用（1–2 天即可落地）
- 通过
nvidia-smi、容器日志和kubectl事件采集基础数据。 - 能回答 Q1/Q2/Q6/Q8 的最小版本，适用于 PoC、demo 或平台起步期。
Level 1：可观测成体系（1–2 周）
- 利用 DCGM Exporter 提供 GPU 利用率、显存、功耗、温度等指标。
- 结合 Prometheus + Grafana 实现统一采集、存储与可视化。
- 能回答 Q1–Q6，并对 Q4（抖动）做初步归因，适用于多租户与线上推理场景。
Level 2：可审计与可结算（1–2 个月，取决于组织流程）
- 采集调度决策审计日志（谁请求、谁批准、为何拒绝/抢占）。
- 建立资源分配账本（allocated）与使用账本（used）的对账机制。
- 支持成本归因与对外报表（team/project），实现治理闭环，能回答 Q1–Q10。
下图展示数据源建设的三个层级渐进路线。Level 0（蓝色区域）最小可用（1-2 天即可落地）：通过 nvidia-smi 容器日志 kubectl 事件采集基础数据，能回答 Q1/Q2/Q6/Q8 的最小版本，适用场景是 PoC demo 或平台起步期。Level 1（黄色区域）可观测成体系（1-2 周）：利用 DCGM Exporter 提供 GPU 利用率显存功耗温度 PCIe/NVLink，结合 Prometheus + Grafana 实现统一采集存储与可视化，采集自定义 Exporter（队列等待调度决策配额使用），能回答 Q1-Q6 并对 Q4 抖动做初步归因，适用场景是多租户与线上推理场景。Level 2（绿色区域）可审计与可结算（1-2 个月取决于组织流程）：采集调度决策审计日志（谁请求谁批准为何拒绝/抢占），建立资源分配账本（allocated）与使用账本（used）的对账机制，成本归因引擎（GPU-hours 等价口径多维度聚合），治理闭环（告警→触发→动作→反馈），能回答 Q1-Q10（全部十个问题）以及成本归因产能规划治理动作自动化，适用场景是生产环境多团队协作需要成本结算的平台。核心理念：数据源建设不是一蹴而就，而是渐进式演进，从能用到可观测再到可审计可结算，每一步都解决特定问题域。
与 HAMi / Kueue / Volcano 的映射（你需要的不是更多指标，而是闭环）
在平台治理中，HAMi、Kueue、Volcano 分别承担不同的角色。下表总结了三者的关键价值、观测重点与计量重点。
HAMi（数据平面侧）
- 关键价值：将共享资源做成“可声明资源请求”，并产生可对账的分配信息（如 Pod annotations）。
- 观测重点：allocated 的资源单元、同卡共址拓扑、配额兑现情况。
- 计量重点：vGPU-hours / gpumem / gpucores 的等价口径与对账。
Kueue（治理与准入侧）
- 关键价值：将 GPU 从节点资源升级为“组织可治理资源”。
- 观测重点：队列等待时间、准入拒绝率、配额使用趋势。
- 计量重点：按租户/团队的配额承诺与实际兑现。
Volcano（批作业调度侧）
- 关键价值：支持训练/批处理场景的策略表达（如 gang scheduling、公平、抢占）。
- 观测重点：作业级别的排队、抢占、重试与成功率。
- 计量重点：作业完成成本（GPU-hours/作业）与吞吐（samples/sec）。
下图展示 HAMi/Kueue/Volcano 三者的职责分工与协同闭环。HAMi（蓝色左侧）数据平面侧：关键价值是将共享资源做成可声明资源请求并产生可对账的分配信息（Pod annotations），观测重点是 allocated 资源单元同卡共址拓扑配额兑现情况，计量重点是 vGPU-hours/gpumem/gpucores 的等价口径与对账。Kueue（黄色中间）治理与准入侧：关键价值是将 GPU 从节点资源升级为组织可治理资源提供配额准入优先级与公平性保障，观测重点是队列等待时间准入拒绝率配额使用趋势，计量重点是按租户/团队的配额承诺与实际兑现。Volcano（绿色右侧）批作业调度侧：关键价值是支持训练/批处理场景的策略表达（gang scheduling 公平 抢占），观测重点是作业级别的排队抢占重试与成功率，计量重点是作业完成成本（GPU-hours/作业）与吞吐（samples/sec）。底部紫色区域展示三者协同形成的治理闭环：左侧 HAMi 定义资源单元→Kueue 治理准入与配额→Volcano 调度具体作业；中间观测数据反哺调度决策（HAMi 提供分配信息、Kueue 提供队列状态、Volcano 提供作业生命周期）；右侧计量口径统一（allocated vs used 对账、GPU-hours 等价换算、成本归因多维度聚合）。底部说明你需要的不只是更多指标，而是从数据采集到调度决策再到成本归因的完整闭环。核心理念：HAMi 负责资源暴露、Kueue 负责治理准入、Volcano 负责作业调度，三者各司其职形成治理闭环。
落地路线：用"问题驱动"替代"指标驱动"
建议以三张表作为后续迭代的骨架，逐步完善平台治理能力：
- 问题 → 指标 → 数据源 → 看板
- 告警 → 触发阈值 → 自动化动作（限流/驱逐/抢占/隔离）
- 成本归因 → 口径 → 账单报表 → 组织流程（预算/配额/采购）
验收清单（用于平台评审/对外交付）
平台最小可验收版本建议满足以下 10 条中的 7 条：
- 任意时刻能回答“某张 GPU UUID 上跑着哪些 Pod/属于谁”
- 能回答“某团队本周 allocated GPU-hours 与 used GPU-hours”
- 能给出队列等待时间分布（P50/P95）
- 能定位一次 P99 抖动事件发生时的同卡邻居与资源曲线
- 能输出按原因分类的失败率与 MTTR
- 能定义并展示碎片率（至少按显存维度）
- 能展示配额兑现情况（requested/allocated/used 对账）
- 能按租户生成月度成本报表（哪怕是 CSV）
- 有一套最小告警（GPU 掉卡、驱动异常、OOM、长时间 idle）
- 有一套“治理动作”手册（遇到什么告警做什么）
总结
观测与计量不是“运维附加项”，而是 GPU 共享与多租户成立的前提。最终交付的不是一个看板，而是一套可解释、可审计、可结算的资源运营体系：能回答关键问题、能触发治理动作、能形成治理闭环。
下一章将把这些口径固化为“验收标准与容量规划方法”，推动平台能力从“能跑”迈向“可交付”。