LLM 推理性能的评测口径：为什么 token/s 会骗人

为什么口径比硬件更重要

同一张加速卡、同一个模型，只改三个变量，token/s 就能差出一倍以上：

• 输出长度从 128 token 改成 1024 token（固定开销被摊薄，数字变好看）；
• 单流改成 64 并发（吞吐上升，但单请求延迟变差）；
• 是否开前缀缓存、是否把首次加载算进去。

所以看到“某卡每秒多少 token”时，先别比较，先问一句：输入多长、输出多长、几路并发、预热了吗、看的是平均还是 P99？

必须写清楚的五个字段

1. 输入长度：均值、P50/P95，以及是否共享前缀。
2. 输出长度：固定生成还是 max_tokens 截断；两者不可混比。
3. 采样参数：temperature、top_p、是否贪心解码；非确定性采样会让延迟波动。
4. 并发与批量：单流、固定并发、阶梯并发，或者固定到达率；必须与吞吐一起报。
5. 预热与缓存：首次请求（含模型加载/编译）与稳态请求分开；prefix cache 命中率单独说明。

五个核心指标

流式场景可以用一个近似关系做交叉校验：

E2E ≈ TTFT + (输出 token 数 - 1) × TPOT

示例：输出 512 token、TTFT 0.35 s、TPOT 22 ms，则 E2E ≈ 0.35 + 511 × 0.022 ≈ 11.6 s。 这只是公式演示，不是任何真实设备的测试结果。

六个最常见的错误

1. 只报 token/s，不报长度与并发——最常见的“不可比”来源。
2. 把首次加载混进稳态数据——模型编译、显存分配、cache 冷启动会显著拉高首轮。
3. 用平均值代替 P99——平均值漂亮、P99 崩掉，是生产环境最常见的翻车。
4. 把编排层瓶颈算到硬件头上——连接池、序列化、日志、队列都可能先于 GPU/NPU 成为瓶颈。
5. 跨 tokenizer 比较 token/s——不同分词器切分粒度不同，必要时同时给出字符级速率。
6. 不同框架/版本混在一张表里——框架版本、驱动版本、模型精度必须逐项列出。

一份最小可复现报告清单

• 硬件型号与数量（可做角色化脱敏，但需说明类别与显存）
• 驱动 / 框架 / 模型精度 / 模型版本
• 输入与输出长度分布
• 并发模型（单流 / 固定并发 / 阶梯）
• 预热策略与缓存开关
• 至少 3 轮重复，报告 P50 与 P99
• 原始数据与复现脚本
• 利益披露：设备来源、是否收费、是否送测

本站所有评测都会按这套口径执行，详见 评测方法论。