Jimmy Song – 可观测与验收

可观测与计量：你必须回答的十个问题

Jimmy Song — Tue, 30 Dec 2025 05:02:48 +0000

只有能被解释、能被治理、能被结算的资源体系，才是真正可运营的 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 平台。

图 1: 可观测与计量：十个必须回答的问题

现在是谁在占用 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（全部十个问题）以及成本归因产能规划治理动作自动化，适用场景是生产环境多团队协作需要成本结算的平台。核心理念：数据源建设不是一蹴而就，而是渐进式演进，从能用到可观测再到可审计可结算，每一步都解决特定问题域。

图 2: 数据源建设：三个层级渐进路线

与 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 负责作业调度，三者各司其职形成治理闭环。

图 3: 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 共享与多租户成立的前提。最终交付的不是一个看板，而是一套可解释、可审计、可结算的资源运营体系：能回答关键问题、能触发治理动作、能形成治理闭环。

下一章将把这些口径固化为“验收标准与容量规划方法”，推动平台能力从“能跑”迈向“可交付”。

GPU 指标语义：利用率的真相与多租户归因

Jimmy Song — Fri, 28 Aug 2026 00:00:00 +0000

“GPU 利用率 97%”是一句没有信息量的话：在你补齐另外两个数字之前，它既可能是“忙而无效”，也可能是“带宽满载的健康态”。

阅读位置：上一章《可观测与计量：十个问题》 · 下一章《基准、验收与容量规划》。

可观测与计量一章给出了平台必须回答的十个问题；本章为其中最容易被误读的部分，即利用率与归因，提供字段级语义。它是故障模式手册的前置，也是微架构Roofline 模型在监控层的直接应用。

GPU-Util 到底测的是什么

nvidia-smi 的“GPU-Util”（DCGM 字段 1001）的精确定义：

采样周期内，“至少有一个 kernel 在 GPU 上运行”的时间占比。

它不表示：用了多少 SM、跑了多少 FLOPS、带宽吃没吃满、活干得好不好。一个只来回搬运数据的循环也能让它显示 100%。它的正确用途只有一个：“这台卡有没有东西在跑”。

必须同看的三件套

字段	测的是什么	回答的问题
1001 GPU_UTIL	有 kernel 驻留的时间占比	有没有东西在跑
1002 SM_ACTIVE	平均多少比例的 SM 在工作	用了多少“机器”
1005 DRAM_ACTIVE	显存带宽利用率	带宽是不是瓶颈

表 1: 利用率三件套（DCGM 字段）

三个数字放在一起才能读出负载状态。三个标准签名：

1001	1002	1005	诊断
高	低	高	解码型推理的正常态（带宽满、算力闲，见推理物理层），不要再加租户
高	高	低/中	训练/预填充（算力型），健康
高	低	低	小 kernel 风暴或纯搬运，即“忙但没干活”
低	低	低	真空闲，或主机侧卡住（见 eBPF 一节）

表 2: 三件套签名速查

配套字段：1003（SM 占用率，kernel 配置健康度）、功耗/时钟/降频原因（共享场景的隐形干扰源，见微架构的功耗墙）。dcgm-exporter 默认只导出 1001 类指标。把 1002/1005 加进 gpu-metrics ConfigMap，是“把监控从假变真”的第一个动作。

采样看不见尾延迟

1 秒采样的 1001 是“这一秒有没有 kernel”，对 p99 的信息量为零：一个租户的解码步每秒被同卡邻居切断数次，在任何平均指标上都是不可见的。因此监控必须分层：

常驻（零成本）：三件套 + 功耗降频 + 引擎指标（TTFT/ITL、KV 水位、前缀命中率）；
触发式（低成本）：由告警自动抓取 10 秒级的追踪快照（nsys / torch profiler）。GPU 问题几乎无法事后复现，证据必须当场留；
事故级（高成本）：单 kernel 深度剖析。注意此类工具会重放 kernel、串行化设备，禁止对生产流量使用。

多租户归因的四条路径

“哪个 Pod 用了多少 GPU”没有原生答案，四条路径各有盲区：

路径	原理	盲区
`nvidia-smi pmon`	驱动按进程采样 SM/显存	需自制 pid→Pod 映射；MPS 下全记在服务进程头上
软切分监控（如 HAMi monitor）	采样 + 设备 cgroup 映射成 Pod	采样平均，看不见尾延迟；口径是配额口径
MIG 实例指标	按实例天然分离	只有切了 MIG 的节点有
引擎指标	推理引擎按请求记账（TTFT/TPOT/前缀命中）	只覆盖引擎内流量

表 3: 归因路径对比

分层结论：计费看配额计数器，排障看追踪，SLO 看引擎指标，不要用采样平均的“利用率”回答“谁用了多少”。归因口径与配额口径的对账（软切分账本 vs 设备真值）应作为周期任务，偏差是配额体系失信任的第一信号（见HAMi）。

eBPF 边界观测：把 GPU 延迟连回主机原因

eBPF 看不到 GPU 内部，但能看到边界：CUDA 运行时/驱动 API 调用（uprobes）、设备节点上的 ioctl（内核探针）、以及主机侧事件（cgroup 限流、调度迁移、网络重传）。把三者按时间戳与进程关联，就能构建因果链：“推理延迟尖刺 ← kernel 发射停顿 ← launch 线程被 cgroup 限流 ← 嘈杂的 sidecar”。

这类工具（如开源的 Ingero 等）填补的是传统 GPU 工具的反向盲区：Nsight 回答“GPU 做了什么”，eBPF 回答“主机为什么让 GPU 这么做”。对共享节点上的排障（谁拖慢了谁）、分布式训练的 straggler 定位（哪个 rank 因主机原因变慢）价值最大，且开销低（边界采样而非设备内省），适合常驻。

告警的语义化

把告警从计数器移到语义，是可观测层最划算的改进。三个示例：

DRAM_ACTIVE > 85% 持续 5 分钟（推理节点）→ 该节点带宽接近满，冻结新的解码型负载调度；
TTFT/ITL p99 连续越线 → 触发自动追踪快照 + 通知（而不是等工单）；
XID 79 级错误 → 节点隔离 + 硬件工单（见故障模式）。

常见误区

误区	真相
利用率 30% 说明还有富余	30% 的什么？带宽 90% 时加租户就是事故
平均没问题就是没问题	尾延迟在平均里消失；采样窗口 ≥ 突发周期时全盲
pmon 能看到每个容器	是每个进程，且 MPS 下失真
显存 100% 是泄漏	先分清框架缓存（reserved）与真实张量（allocated），见显存管理
深度剖析工具挂上去看看	会重放 kernel、串行化设备，生产禁止

表 4: 观测层的常见误区

总结

指标语义层的三个纪律：利用率必须三件套同读（否则既会误判健康也会误判故障）；SLO 与归因不依赖采样平均（追踪与引擎指标才是依据）；告警挂在语义上（带宽满载、SLO 越线、账实偏差），而不是挂在百分比上。它们与基准与验收共同构成“从能跑到可交付”的观测闭环。

参考资料

基准、验收与容量规划

Jimmy Song — Tue, 30 Dec 2025 05:01:13 +0000

性能验收不是“跑分”，而是将复杂现实转化为可交付、可治理的标准化口径。

为什么要把“性能”变成“验收”

在 GPU 平台的性能讨论中，很多人习惯于比拼“峰值吞吐”，但实际交付的并非峰值，而是在共享、多租户、队列治理、故障与抖动等复杂场景下的可预测体验。

因此，本章的核心观点是：性能不是单一指标，而是一组可被验收的口径。
你需要将“跑得快”细化为“跑得稳”“跑得可解释”“跑得可治理”，并将这些口径固化为 SLO（Service Level Objective, 服务级别目标）与验收测试，才能支撑选型、上线评审与容量规划。

三类基准：不要把不相干的东西放在同一张表里

在实际工作中，基准测试常被混淆。下面介绍三类常见基准及其适用场景。

图 1: 三类基准类型对比

三类基准分别对应不同决策目标：单卡峰值基准用于硬件健康检查，共享稳定性基准用于多租户方案选型，系统可交付基准用于平台治理与容量规划。混用这些基准会导致错误的容量判断。

单卡峰值基准（Peak）

目的：确定硬件与软件栈的上限，作为“健康基线”和回归基准。
风险：几乎无法代表线上共享环境。
常见输出：tokens/s、samples/s、训练 step/s、显存占用曲线、功耗曲线。

共享稳定性基准（Shareability）

目的：衡量共享时的抖动与干扰，决定平台能否多租户交付。
关键输出：P95/P99 延迟、干扰系数、长尾抖动事件率、邻居噪声敏感度。

系统可交付基准（Deliverability）

目的：在准入/队列/抢占/失败存在时仍能交付 SLO。
关键输出：队列等待时间、拒绝率、SLO 达标率、失败率与 MTTR、成本口径（allocated/used）。

这三类基准分别对应硬件/驱动健康、共享方案选型、平台治理与运营等不同决策。如果混在一起，结论必然偏离实际。

验收指标体系：吞吐只是其中一项

建议用“四象限”组织你的验收指标：性能、稳定性、效率、治理。每个象限至少定义 2–3 个可操作指标，形成闭环。

图 2: 验收指标四象限

验收指标的四个维度：性能关注吞吐与响应时间，稳定性关注尾延迟与失败率，效率关注资源利用率与碎片化，治理关注配额与队列。缺失任一象限都会导致无法交付可预测的服务质量。

性能（Performance）

吞吐：tokens/s、req/s、samples/s、step/s（按工作负载不同选择）
响应时间：P50/P95/P99（推理必须纳入）
冷启动：模型加载时间、Pod ready 时间（影响弹性）

稳定性（Stability）

P99 抖动幅度：同配置下 P99 的标准差/分位差
抖动事件率：单位时间内超过阈值的次数（例如 P99 > 2×SLO）
失败率与 MTTR：OOM、驱动异常、容器启动失败、掉卡等分类统计

效率（Efficiency）

碎片率（Fragmentation）：剩余资源无法满足典型请求的比例（显存/cores/实例单位）
有效利用率：used / allocated（避免“占着不用”）
能耗效率（可选）：tokens/J 或 samples/J（做规模化时很关键）

治理（Governance）

队列等待时间：P50/P95（控制面治理的直接体感）
拒绝率/超配阻断：请求超出配额是否被稳定阻断（可验收）
配额兑现率：requested → allocated → used 的对账一致性

关键定义：三个最重要、最容易被滥用的口径

在实际平台治理中，以下三个指标最为关键且易被误用。

干扰系数（Interference Factor）

用于度量共享对体验的影响，建议定义为：

吞吐干扰系数：IF_throughput = T_dedicated / T_shared
延迟干扰系数：IF_latency = P99_shared / P99_dedicated

解释方式：

IF 越接近 1 越好；
IF 越大，说明共享带来的性能损失或尾延迟放大越严重；
可按“同卡邻居数量/邻居类型/是否跨 Pod”分桶统计，形成可运营的经验曲线。

碎片率（Fragmentation）

碎片率不是“剩余显存很少”，而是“剩余资源不匹配请求形状”。

实用定义方式：用你的典型请求集合 R（如 10GB、20GB、30GB 这三种推理规格）做探测，统计：

资源池中满足任一典型请求的可用单元占比；
或者统计“被剩余资源困住”的容量比例。

MIG 的碎片率来自离散实例单位；vGPU 的碎片率更像“配额能否被兑现 + 干扰是否可控”。

可交付容量（Deliverable Capacity）

不要把“理论卡数”当容量。容量必须与 SLO 绑定：

在给定 SLO（如 P99 < X）与并发/模型组合下，资源池能稳定承载多少请求/作业。这会自然把“吞吐 vs P99”“共享 vs 隔离”“队列治理”统一到一个交付口径里。

基准设计：用“对照组”而不是“单点跑分”

为了获得可复现、可对比的基准结果，建议采用对照组设计。你可以将实验环境固定为三条路径，形成可持续的基准矩阵：

图 3: 对照组基准设计

三条基准路径形成完整对比矩阵：独占作为健康基线，无治理共享展示不可控风险，治理共享验证可交付性，MIG 展示隔离代价。通过统一的负载模板，将不同方案放在相同尺度下比较。

独占（baseline）

单 Pod 独占整卡（或 MIG 实例独占）

共享（机制验证）

无治理共享（同卡多进程/多容器）：用于展示“能跑但不可控”
治理共享（HAMi vGPU）：用于展示“可声明、可对账、可阻断”

强隔离共享（MIG）

用于展示隔离带来的 P99 稳定性与离散单位的碎片代价

每条路径都应采用统一的“工作负载模板”和“数据采集模板”，确保可回归、可对比、可长期更新。

你应该输出的“验收包”（平台评审最喜欢的形式）

平台评审时，建议将验收产物固定成一套可复制的包，便于标准化和复用。

测试矩阵（表格）

工作负载：vLLM（推理）、PyTorch（训练/微调）
资源形态：独占 / 无治理共享 / HAMi / MIG
指标：吞吐、P99、IF、碎片率、失败率、队列等待（如有）

SLO 断言（可写成验收条款）

例如：在 2 个共享 Pod 下，P99 不得超过独占的 1.5×
例如：超配请求必须被阻断（Pending/Rejected）并可解释

证据链

YAML、命令、关键输出、指标截图（或导出的 CSV）
一页结论：通过/不通过、风险与建议动作

这套“验收包”既可用于内部评审，也可成为对外 demo 的标准化资产。

从实验数据到容量规划：把曲线变成决策输入

容量规划的目标不是“要买多少卡”，而是回答以下三个核心问题。

图 4: 容量规划流程

容量规划的核心是建立从实验数据到资源承诺的映射：首先明确需求形状（模型、资源、SLO），然后利用基准数据获得可交付吞吐，最后为抖动、故障与治理预留安全边际，形成可解释的资源承诺模型。

需求形状是什么？

将需求抽象为三元组：

模型/作业类型（推理/训练、模型大小、并发形态）
资源请求形状（显存、算力、实例单位）
SLO/SLA（P99、作业完成时间、排队上限）

没有需求形状，容量规划容易退化为平均利用率游戏。

在目标 SLO 下，每张卡的可交付吞吐是多少？

利用基准数据，将“吞吐、P99、并发”关系曲线化：

推理：并发上升，吞吐上升但 P99 可能非线性恶化
共享：吞吐可能还行，但 P99 与 IF 才是硬约束

容量的核心输入应是：每张 GPU 的 deliverable throughput（在 SLO 下可交付吞吐）。

资源池需要预留多少安全边际？

建议考虑以下三个边际：

抖动边际：为 P99 波动预留（共享场景尤其重要）
故障边际：掉卡/驱动问题/维护窗口
治理边际：抢占、队列高峰、突发流量（推理）或集中提交（训练）

最终你得到的不是“平均利用率目标”，而是一个可解释的资源承诺模型：

承诺多少 SLO
承诺多少吞吐/并发
承诺多少队列等待上限
超出时如何降级/限流/排队

建议你在本书里固化的“默认验收模板”

你可以将以下模板作为本章的固定结尾，后续每次增加新方案或新硬件都按此填写：

场景

工作负载：vLLM / PyTorch / Ray
资源形态：独占 / MIG / HAMi

SLO

推理：P99 < X ms（或 P99 相对独占不超过 Y×）
训练：作业完成时间/step time 不超过 Y×；失败率 < Z%

基准结果

吞吐：____
P99：____
干扰系数 IF：____
碎片率：____
失败率/MTTR：____
（可选）队列等待：____

结论

是否可交付：通过/不通过
风险点：____
建议动作：隔离/限流/策略/扩容/观测补齐

总结

本章旨在将“性能讨论”升级为“交付语言”：

吞吐决定上限，但 P99、干扰系数与碎片率 决定平台能否共享与多租户；
验收要以 SLO 为中心，输出可复用的验收包；
容量规划必须基于 可交付吞吐 与明确的需求形状，而不是平均利用率。

下一章“排障”将把这些指标与实际故障模式对齐，形成从信号到动作的闭环。

故障模式与排障手册

Jimmy Song — Tue, 30 Dec 2025 05:01:49 +0000

排障的本质是用系统化方法缩短定位路径，而不是靠经验“拍脑袋”。分层收敛、证据链、最小修复，是高效排障的核心。

排障的总原则：先分层，再收敛

GPU 平台的故障排查难点在于，同一现象可能源自不同系统层级。例如，Pod Pending 既可能由于配额不足，也可能因为设备插件未上报资源；推理延迟抖动既可能是同卡邻居干扰，也可能是 CPU 或网络瓶颈。

本章旨在提供一套可操作的排障顺序，将排障过程从“凭经验试错”转变为“分层收敛”，让你把时间花在最可能的根因上。

你可以将本章视为 GPU 平台的“诊断树”：先判定控制面与数据平面，再区分工作负载与运维配置，最后深入具体组件细节。

快速分诊：四个问题决定排障路径

遇到任何故障时，建议先用以下四个问题进行快速分诊，通常只需 2–5 分钟：

现象类型是什么？
- Pod Pending / 调度失败
- Pod Running 但不使用 GPU / GPU 不可见
- GPU 使用异常：OOM / 掉卡 / Xid 错误
- 性能异常：吞吐下降 / P99 抖动
- 资源“穿透”：声明与实际不一致（超用/偷用/配额不兑现）
影响范围多大？
- 单 Pod / 单节点 / 单队列 / 全集群
  范围越大，越倾向于数据平面或运维问题（驱动、runtime、device-plugin）。
最近是否发生变更？
- 驱动/CUDA/容器运行时升级
- MIG 重配置
- HAMi/Volcano/Kueue 版本变更或参数调整
- 节点增删/标签变更
  大多数生产故障都与变更强相关，优先回滚或对比变更前后差异。
是否可复现？
- 可复现：走“定位、验证、修复”闭环
- 不可复现：先补齐观测与采样，把现象固化成证据链

图 1: 故障分诊流程图

快速分诊决策树：通过现象类型、影响范围、变更历史和可复现性四个维度，在 2–5 分钟内快速锁定排障路径。

总体排障路径：四段式收敛流程

排障流程建议分为四步，帮助你高效定位问题：

确定是控制面还是数据平面

控制面问题：通常表现为“规则导致的不可用”，如 Pending 原因是配额、队列、优先级、准入、抢占等。
数据平面问题：表现为“资源本体不可用或不一致”，如节点上看不到 GPU、device-plugin 异常、容器无法访问设备。

判断依据：

kubectl describe pod 的 Events 是否明确说明“资源不足/准入拒绝/队列等待”。
kubectl describe node 是否仍然有 GPU capacity/allocatable（或对应的设备资源）。
相关组件是否健康：scheduler、device-plugin、runtime。

在选定层内，判定是“配置/运维”还是“工作负载行为”

配置/运维：版本不匹配、驱动/runtime 错误、MIG 重配、权限/安全策略、镜像环境不完整等。
工作负载行为：显存激增、KV cache 膨胀、batch 配置不当、训练通信/拓扑瓶颈等。

用最少命令拿到证据链

排障时应避免“到处翻日志”，优先获取以下三类证据：

资源视角：节点 GPU 是否存在、分配是否兑现（Pod 注解、GPU UUID 映射）。
调度视角：Pending 原因、准入/队列/抢占事件。
运行时视角：容器是否能看到 GPU，是否出现 OOM/Xid。

最小修复与回归验证

修复建议遵循“最小改动”原则：

先恢复可用性，再追求最优。
每次改动都要有回归用例（建议复用本书 Lab 的 YAML）。

图 2: 四段式收敛流程

四段式收敛流程：从确定控制面/数据平面，到判定配置/工作负载问题，再到获取证据链，最后最小修复与回归验证，形成闭环的排障方法论。

五大故障模式概览

图 3: 故障模式分类

GPU 平台五大常见故障模式：涵盖调度失败、GPU 不可见、显存 OOM、性能异常和 MIG 配置问题，以及对应的控制面与数据平面根因分类。

故障模式一：Pod Pending / 调度失败

本节介绍 Pod Pending 或调度失败的常见现象、根因及排查方法。

现象与高频根因

控制面根因
- Kueue：未准入（配额不足、队列拥塞、ResourceFlavor 不匹配）
- Volcano：队列/公平/抢占/Gang scheduling 条件不满足
- 原生调度：节点选择、污点容忍、亲和性冲突
数据平面根因
- device-plugin 未上报 GPU（节点上 Capacity 没有设备资源）
- HAMi scheduler 未生效（schedulerName 未指向 HAMi）
- 节点标签缺失（如 GPU 节点未被纳入管理）

最短诊断命令

以下命令可快速定位 Pending 原因、调度器及节点资源状态：

# 查看 Pending 原因（最重要）
kubectl -n <ns> describe pod <pod> | sed -n '/Events/,$p'

# 查看调度到哪个 scheduler（防止跑错调度器）
kubectl -n <ns> get pod <pod> -o=jsonpath='{.spec.schedulerName}{"\n"}'

# 查看节点资源是否存在
kubectl describe node <node> | egrep -n "Capacity:|Allocatable:|nvidia|gpu" -n

典型修复动作

schedulerName 错误：修正为 hami-scheduler 或 volcano 对应名称。
节点未上报 GPU：重启 device-plugin，确认 runtime/driver 链路。
准入失败：调整配额/队列策略，或解释为“策略拒绝（符合预期）”。
资源请求写错：如 gpumem 与 gpumem-percentage 混用（互斥），或单位不正确。

故障模式二：Pod Running 但 GPU 不可见 / CUDA 初始化失败

本节聚焦于容器运行但无法使用 GPU 的排查思路。

现象信号

容器内 nvidia-smi 不存在或报错。
CUDA 报错 CUDA driver version is insufficient 或 no CUDA-capable device is detected。
框架侧报“torch.cuda.is_available() = False”。

最短诊断命令

以下命令可帮助你快速定位 GPU 链路问题：

# 宿主机 GPU 是否正常
ssh <node> nvidia-smi

# 容器内能否看到 GPU
kubectl -n <ns> exec -it <pod> -- nvidia-smi

# 节点 runtime 侧最小验证（如有节点操作权限）
docker run --rm --gpus all nvidia/cuda:12.4.1-base-ubuntu22.04 nvidia-smi

高概率根因

节点未正确安装/配置 nvidia-container-toolkit（runtime 没有 GPU hook）。
镜像缺少用户态库（只装了框架但没有匹配的 CUDA runtime）。
驱动与容器内 CUDA 版本组合不兼容（尤其在升级驱动后）。

修复策略

更换已知可用的 CUDA base 镜像验证链路。
修复 runtime 配置（containerd/docker）并重启运行时。
回滚驱动或统一驱动版本（生产环境建议做驱动“金镜像”）。

故障模式三：显存 OOM / “看起来还有显存但还是 OOM”

本节分析显存 OOM 的常见场景及排查方法。

现象信号

vLLM / PyTorch 报 CUDA out of memory。
nvidia-smi 显示显存剩余但仍 OOM（碎片化或临时峰值）。

核心判断：OOM 属于“工作负载行为”还是“配额/隔离问题”

工作负载行为：batch、并发、KV cache、activation checkpoint 等导致峰值超出预期。
配额/隔离问题：共享场景下邻居抢占显存、配额未兑现、显存策略不生效。

最短诊断命令

以下命令有助于定位 OOM 发生时的显存使用情况及同卡进程：

# 查看 OOM 发生时间与 GPU 显存曲线（如有 DCGM/Prometheus 更佳）
nvidia-smi --query-gpu=timestamp,memory.used,memory.total --format=csv -l 1

# 查看同卡有哪些进程（定位邻居）
nvidia-smi pmon -c 1

修复策略

降低并发、最大 tokens、batch（立即止血）。
通过调度与隔离减少同卡干扰（强隔离/MIG 或治理共享）。
将“显存峰值”纳入验收指标：不仅关注平均占用，还要关注峰值与抖动。

故障模式四：性能异常（吞吐下降 / P99 抖动）

本节介绍性能异常的排查思路，帮助你快速定位瓶颈。

先排除“假性能问题”

许多“GPU 性能问题”实际根因在 CPU、网络或存储：

CPU 饱和导致 GPU 喂不饱。
网络/存储瓶颈导致数据加载卡住。
NUMA/PCIe 拓扑导致跨 socket 访问变慢。

最短诊断命令

以下命令可在 3 分钟内完成初步性能排查：

# GPU 利用率与功耗是否明显下降
nvidia-smi dmon -s pucm -c 5

# 是否出现大量 CPU wait / IO wait
top -H # 或 iostat/vmstat（视工具链而定）

# 查看同卡邻居（共享场景必查）
nvidia-smi pmon -c 1

用“干扰系数”收敛问题域

将当前性能与“独占基线”对比：

吞吐下降但 P99 稳定：更可能是资源配额/cores 限制或 CPU 瓶颈。
P99 明显变差：优先怀疑共享干扰、显存抖动、调度共址策略。

没有对照组或基线，性能排障会变得极为困难。

故障模式五：MIG 相关问题（重配置、实例不可用、资源不一致）

本节聚焦于 MIG（Multi-Instance GPU）相关的常见故障与排查顺序。

典型现象

节点上 MIG 实例与 Kubernetes 资源视图不一致。
重配置后 Pod 仍调度到旧的实例视图。
MIG 实例无法创建或创建后不可用。

排障顺序

节点侧确认 MIG 状态与实例列表。
device-plugin 是否识别新实例。
集群侧资源是否刷新（必要时重启相关插件）。
避免在高峰期做 MIG 重配（重配本身属于运维事件，需纳入变更管理）。

HAMi 特有排障：配额兑现与“治理共享”的证据链

当你使用 HAMi 进行细粒度共享时，排障的关键不只是“能否运行”，而是以下三点：

Pod 是否走了正确的 scheduler。
分配结果是否写入可对账信息（如 Pod 注解）。
超配是否被稳定阻断且可解释。

建议将 Lab 3 中用于验证的命令，作为本章的“HAMi SOP”长期固化：

查看 schedulerName
查看分配注解
提交超配 Pod 验证阻断

这样无论对外演示还是内部评审，都更具说服力。

补充命令速查：NCCL 挂起与拓扑拒绝

分布式训练的两类高频故障，命令入口如下（完整流程仍走本章四段式收敛）。

NCCL 挂起/分布式训练卡死，按“InfiniBand 健康 → NCCL 环境 → 版本 → GPU Direct → 跨节点基准”的顺序排查：

# InfiniBand 健康
ibstat
ibv_devices

# NCCL 环境变量
env | grep NCCL
# NCCL_IB_DISABLE 应为 0（IB 集群启用）
# NCCL_SOCKET_IFNAME 应指向正确网卡（如 ens3f0）
# NCCL_DEBUG=INFO 输出详细日志

# 容器内 NCCL 版本与 GPU Direct RDMA
python3 -c 'import torch; print(torch.cuda.nccl.version())'
nvidia-smi nvlink -s

# 跨节点基准（在结论前必须复现）
/opt/nccl-tests/build/all_reduce_perf -b 1G -e 4G -f 2 -g 8

TopologyAffinityError（Pod 被拓扑管理器拒绝），症状是 Pod 已调度到节点却一直 Pending：

kubectl describe pod <pod> -n <namespace> | grep -i topology
# 'TopologyAffinityError: Resources cannot be allocated with Topology locality'

journalctl -u kubelet --since "15 min ago" | grep -i -E 'topology|admit|hint'

# 检查单 NUMA 节点内是否有足够 GPU
kubectl get nrt -o yaml

处置原则（详见NUMA 感知调度）：短期可放宽为 best-effort，长期必须部署 NRT 更新器与拓扑感知调度器；不要先削弱策略，先问 Pod 的 CPU、内存、GPU 与设备插件提示能否物理放得下，这次拒绝可能正在保护你免受一个看不见的性能悬崖。

最小化的“排障工具箱”

建议你长期维护一个最小化的排障工具箱，做到随时可用：

集群视角：kubectl get/describe/events/logs
节点视角：nvidia-smi（含 pmon/dmon）、dmesg（查看 Xid）
观测视角（进阶）：DCGM Exporter + Prometheus + Grafana
回归用例：本书的 Lab YAML（独占/共享/超配/负载压测）

排障的最终交付：把一次事故沉淀成资产

每次排障结束，建议沉淀以下三类资产，这将直接提升你在平台治理中的影响力：

触发条件与证据链：事件、日志、指标、YAML。
根因分类：控制面、数据平面、工作负载、运维配置。
防复发措施：告警阈值、准入策略、验收项、回归用例。

这样可以让平台治理从“靠专家”转向“靠系统”。

总结

排障的核心不是更懂某个组件，而是能在多层系统中快速收敛。先分层（控制面 vs 数据平面），再分因（工作负载 vs 运维配置），用最少命令拿证据链，做最小修复并回归验证。只要你将这套流程固化为 SOP，GPU 平台的可用性将实现阶跃式提升。