基准、验收与容量规划

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

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

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

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

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

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

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

单卡峰值基准（Peak）

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

共享稳定性基准（Shareability）

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

系统可交付基准（Deliverability）

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

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

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

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

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

性能（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 隔离”“队列治理”统一到一个交付口径里。

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

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

三条基准路径形成完整对比矩阵：独占作为健康基线，无治理共享展示不可控风险，治理共享验证可交付性，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 的标准化资产。

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

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

容量规划的核心是建立从实验数据到资源承诺的映射：首先明确需求形状（模型、资源、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 为中心，输出可复用的验收包；
• 容量规划必须基于 可交付吞吐 与明确的需求形状，而不是平均利用率。

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