大模型压测方法论：如何让性能数据可信

大模型推理基础设施实战系列 · 第 5 篇

1. 背景与问题：性能数字是最容易被"无意中造假"的东西

大模型服务的性能报告里，充斥着口径不明但不算说谎的数字：含缓存输入的"总吞吐"、直方图截断出来的"p99"、跨卡平均抹掉的热点卡、用公式估算却写成实测的 FLOP/s。项目记录覆盖多轮受控压测，并经历了多轮第三方视角的复核纠偏——包括撤回自己已发布结论的痛苦经历。这篇文章把沉淀下来的方法论完整公开。

先说我们的立场：性能数字应能追溯到原始记录，结论范围不能超过实验设计。下面区分项目历史案例与建议采用的检查规则。

2. 方法论框架：六步流水线，每步有门禁

压测六步流水线

① 准备：冻结执行清单。 计分前把 RUN ID、模型 revision 与权重 manifest、官方固定版本 tag 与核验后的镜像 digest（命令保留可读 tag）、并行方式、GPU UUID、上下文、输入/输出目标、并发、轮数、缓存模式、预算上限冻结成 plan.json。开始计分后不可原地修改——改任何一项就新建配置 ID。这条防的是"边看成绩边调参数直到好看为止"。

② 采集预检：采集器 ready 才发请求。 逐卡核对指标值、单位、错误码、采样周期、时钟和时间覆盖。指标缺失必须在提交前失败，或经显式批准声明"该项缺测及原因"——不能静默跳过，事后也不许用空闲值回填负载窗口。

③ 运行：共同墙钟 + 冷暖配对。 采样提前启动、请求结束后停止；同一请求组共享墙钟作为硬件窗口。冷/暖缓存配对测量；不靠删除共享缓存制造冷态（flush 会改变 allocator 状态，"flush 后的冷"和"运行已热、新前缀无命中"不能混排）。

④ 汇总：先列失败，再比性能。 逐请求 → 逐轮 → 配置三级汇总；正确率、失败/超时/取消/unknown 先列，才轮到吞吐和延迟。短测不外推稳态产能。

⑤ 交付：每个必填项有值或 N/A+原因。 报告、单文件源数据、图表三者一致；缺字段、少卡、错时间窗、单位不明时，不得声明"指标采集完整"。

⑥ 收尾：证据归档 + 辅助进程退出核对。 原始证据按 SHA 索引归档；每个 benchmark 活动本地只维护一份紧凑源数据 JSON；临时文件归并清理，失败证据保留。

3. 统一口径：公式、分位数与硬件窗口

指标可比的前提是公式统一。我们的核心约定（节选）：

指标	口径
总 TPM	`60 × Σ实际(prompt_tokens＋completion_tokens) ÷ 同一墙钟 T`；缓存输入仍在分子内
输出 TPM	`60 × Σ实际 completion_tokens ÷ 整轮墙钟 T`；整轮含排队、失败等待与排空，截止仍在途的单列不删除
TPOT	`(末个非空输出事件时间 − 首个非空输出事件时间) ÷ (completion−1)`；n≤1 记 N/A；SSE 片段不等于 token
p 分位数	排序后 `(n−1)p` 线性插值，必须展示样本量 n；小样本分位数只作描述不作 SLO
多轮汇总	三轮汇总 = 总 token ÷ 总时间；不平均三个吞吐，也不用总量÷中位时间
逐卡硬件	先逐卡算时间均值与该卡采样峰值，保留 node/序号/UUID/有效样本数；跨卡均值与全局最大只能另列，不能替代逐卡表
合计功耗峰值	逐时刻求和再取峰；不能相加各卡不同时刻的峰值（那不是同一时刻的整机功率）
板卡能耗	按时间积分并报告边界处理与覆盖率；覆盖不完整不给"精确 token/J"

最容易被忽视的一条：总 token/s ≠ prefill 计算吞吐。命中缓存的输入 token 也计入吞吐，所以暖请求的"总吞吐"可以是冷请求的 15 倍而 GPU 几乎没算 prefill。报告吞吐时必须同窗展示复用与重算 token。

4. 数据陷阱实录：六条都来自我们自己的复核

指标误读对照

除了图中六条，还有几个值得展开的案例：

案例 A：估算被当成实测发布。 一份早期报告给出"约 5,670 TFLOP/s"的算力数字。复核发现这是用模型公式 × 目标长度 × 未验证的长上下文近似算出来的估算，不是硬件实测。处理：整段撤回，该报告 MFU/HFU 保持 N/A；硬件计数与模型 FLOPs 估算须分开，不把 NCU 当作计算 MFU 的唯一方法。教训：公式推导值必须标注"工程估算"，与实测分栏展示。

案例 B：派生元数据污染主数据。 审计脚本第 41 行把 228 行记录的硬件写死为 NVIDIA H20——实际测试卡是另一型号。这是派生元数据错误，不是硬件实测，不能据此把成绩归到 H20。教训：硬件身份必须来自当轮清点（UUID + 型号），不能沿用目录名或旧脚本常量。

案例 C：重复运行范围不重叠。 3:1 配比三轮 TPM 极差/中位 3.96%，5:1 三轮极差 0.82%——三轮范围互不重叠。"中位数之比 +7.05%"与"配对增幅的中位数"是不同统计量；重复运行能描述波动，不能消除缓存、预热和空队列起窗的共同偏差。

案例 D：两个 352K 窗口 TPM 完全相同。 在窗口时长也相同或取整后相同的条件下，可由相同完成数与 token 和解释——既不证明抄数，也不证明无噪声。记录事实，不做无证据的指控，也不做无证据的开脱。

案例 E：histogram 截断。 Gateway 报告的 p95/p99=240 秒，实际是直方图最高有限桶的截断值，真实分位数可能远超。教训：读分位数先问统计方法——是原始样本插值还是直方图桶估计。

5. 实验设计：让每一组对照只回答一个问题

一次测试不能同时证明所有事。我们的实验类型与固定项：

实验	回答的问题	必须固定
组合筛选	指定负载下哪个 P:D 组合更高效	模型/版本/单实例配置/计数口径；每行明示 C/N
同资源配比	同 GPU 预算多 P 还是多 D	GPU 数、负载、到达率、缓存、SLO
固定需求扩容	加副本能否降低同一需求延迟	请求集、总 N、并发或开放到达率
等比负载扩容	算力翻倍产出是否近似翻倍	P:D、单实例参数；负载按比例增长
可售产能	多少输出同时满足质量与时延	自然 EOS、固定评分器与 SLO；只计合格输出

配套规则：

至少三轮、交错或随机化；A-B-A 各一次不算"双方三轮"；差异在波动内、配对换号或证据不足时写"表现接近"；
固定到达速率测排队，独立并发阶梯找容量——固定并发压测会在响应变慢时自动降低发压速度（闭环效应），不能用它证明突发不排队；
线性度只对同 P:D 系列计算（3P1D→6P2D→9P3D），不与 1:1 系列拼接；小样本"效率略超 100%"可能是波动，不裁成 100% 也不宣称超线性；
诊断轮不进容量榜：profiling 与容量压测分账；start_profile 返回 200 只是启动确认，要等全 rank 完整文件。

6. 证据链：任何数字都能回放

统一 run_id，每请求关联：request_id → 池配置版本 → P/D 实例 → 全 rank 日志与状态 → 客户端结果。

保留实际启动 argv、镜像/源码/依赖身份、队列/传输计时、首错和退出码；远端原始请求/SSE/逐卡采样打包后逐成员核 SHA，本地源数据 JSON 记录每个证据包的 SHA256。跨机事件记录时钟偏差——不直接相减不同主机的 monotonic 值，也不把 P、D 两侧计数相加当"两倍业务量"。

回报是双向的：对别人，任何结论可复核；对自己，三个月后还能回答"当时这条数据是怎么来的"。

7. 效果与总结

这套方法论的直接产出：

两款 Flash 模型各 32 点、2,520/2,520 请求的全组合矩阵，已用核心计量项完成交付；FLOP/s、MFU/HFU 等未测项仍为 N/A；
多次复核纠偏全部留痕：撤回的估算、修订的门禁、更正的口径都与原文并存，不就地改写历史；
支撑了本系列前四篇可复核的倍数结论；本次审校仍发现边界遗漏，说明方法清单不能替代逐项检查。

一张可以打印贴在工位上的检查清单：

□ 负载可比（同模型/版本/语料/缓存口径）
□ n/N 与失败齐全（完成 n/计划 N，unknown 列出）
□ 总/输出 token/s 与 TPM 齐全（含 reasoning 已注明）
□ TTFT/TPOT/停顿齐全（分位数带样本量）
□ 缓存分层与冷暖分类齐全（复用与重算同窗）
□ SM 与 busy 分开；DRAM% 不写成 GB/s
□ 逐卡显存/功耗/覆盖齐全（未去低活动卡）
□ 全部 N/A 有具体原因
□ 来源 SHA 与运行窗口可追溯
□ 辅助任务已退出，账本已闭

下一篇讲支撑这套方法论的采集系统本身：推理集群可观测性：64 卡监控体系与缓存证据链。

系列目录

数据声明：本文引用的反面案例均为本团队自身历史数据与复核记录，已按原貌保留在项目档案中。