如何读懂 DeepInfer 的基准测试：V4.1-Flash 性能
DeepInfer 的 V4.1-Flash 基准很容易被引用，却很难被解释。这篇笔记讲清单位、取舍，以及两张图背后的假设——让你能拿它们和自己的负载对比，而不是和一句标题对比。
DeepInfer 的 V4.1-Flash 基准很容易被引用，却很难被解释。每秒 token 数不是引擎的固有属性，而是引擎、模型、批量、上下文长度、硬件配置和负载共同作用的结果。那张图只是一段旅程的地图，不是对你那段旅程的保证。
单位陷阱
服务相关的讨论里会出现三种速率，它们不能互换：
| 单位 | 衡量什么 | 谁关心 |
|---|---|---|
| tokens/s/GPU | 总输出吞吐除以 GPU 数量 | 容量规划、成本建模 |
| tokens/s/user | 单个用户的流式输出推进得有多快 | 产品团队、延迟敏感型应用 |
| ms/step | 一次 prefill 或 decode 步的实际耗时 | 算子工程师、SLO 负责人 |
一个系统完全可以同时拥有高 tokens/s/GPU 和低 tokens/s/user。decode 图展示的正是这一点：并发上升时，总吞吐上升，而每个用户的流变慢。这两个数字都不是引擎的“那个速度”。
端到端延迟还要加上网络、排队、tokenization、调度和 API 开销。这些都不在两张图里。100 ms/步的 decode 数字，不意味着 100 ms 的 time-to-first-token；325 tokens/s/user 也不意味着 325 ms 的响应时间。
Prefill：批量换来吞吐，延迟是代价
Prefill 处理 prompt 并构建 KV cache。批量越大，权重读取被摊得越薄，GPU 利用率越高，吞吐随之上升。但每一步也更耗时，延迟因此上升。
DeepInfer 的 prefill 图使用 4 块 SM100 GPU、131,072 token 上下文。标签是从 4,096 到 65,536 的批量大小。曲线先陡峭上升，然后趋平：
- 每批 4,096 token 时，吞吐约 60k tokens/s/GPU，每步约 68 ms。
- 16,384 时，吞吐约 81k，每步约 200 ms。
- 65,536 时，吞吐约 89k，每步约 730 ms。
拐点比峰值更重要。如果你的 SLO 很紧，你就待在曲线左侧，用吞吐换延迟。如果你跑的是离线批量评测，可以待在右侧，接受更长的单步时间。哪一侧才对，图不会告诉你——你的负载会。
还要注意 prefill 图测的是什么：非缓存输入吞吐。如果你的 prompt 大部分都命中了缓存，prefill 的工作量会小得多，这条曲线就不是你的瓶颈。缓存命中率是另一个变量，也正是缺失的 KV cache 系统想要最大化的那个变量。
Decode：并发换来吞吐，交互性付账
Decode 每一步为每个请求生成一个 token。并发请求越多，GPU 每步做的有用功越多，总吞吐上升。但每个请求等待下一个 token 的时间变长，单用户速度下降。
DeepInfer 的 decode 图使用 64 块 SM100 GPU、131,072 token 上下文，nextn=3 fixed，单 token draft 接受率 75%。标签是每个 DP rank 的请求数：
- 每个 rank 8 个请求时，总吞吐约 2.6k tokens/s/GPU，每个用户约 325 tokens/s。
- 64 个请求时，吞吐约 15.5k，每个用户约 248 tokens/s。
- 256 个请求时，吞吐约 26k，每个用户约 103 tokens/s。
这就是经典的服务取舍曲线。聊天产品可能选左侧；批量摘要或离线 agent 负载可能选右侧。这张图有价值，是因为它展示了整条前沿，而不是单个点。
示例 README 给出了 decode 吞吐数字背后的计算方式：
decode throughput = avg_SPS × decode_num_requests × (1 + nextn) / cp这是“全接受记账”：它假设每个 draft token 都被接受，与真实接受率无关。图上的结果再按 0.75 的接受率假设缩放。如果你的文本更难预测，真实数字会更低；如果更好预测，则可能更高。
75% 这个假设
投机解码先提出 draft token，再一次性验证。收益取决于有多少 draft 被接受。decode 图假设单 token 接受率为 75%，对应每步平均接受长度约 3.25 个 token。
对于可预测的文本，这个假设是合理的；对于开放式推理、含有罕见标识符的代码，或者高度技术化的写作，就不那么合理了。DeepSeek 自己的生产数据显示，其 DSpark 配置的接受长度在 3.2–3.3 左右，所以图中的假设并非凭空而来——但它仍然是假设，不是你负载的属性。
相关的 DSpark 优化——变长验证——同样依赖负载。DeepSeek 称生产工作点吞吐提升 4–7%，但在低并发时会有小幅损失。这很好地说明了为什么“投机解码是免费的”是一种错误心智模型：收益取决于接受率，也取决于你还有多少验证算力可以闲置。
评测分数衡量的是什么
评测脚本不是服务基准。它们衡量模型在三个离线任务上的质量：
- AIME 2026：30 个任务，每个 32 个样本，Pass@1 99.9%。
- GPQA Diamond：198 个任务，每个 8 个样本，Pass@1 93.4%。
- HLE-Full：2,500 个任务（2,158 文本、342 图像），每个 1 个样本，Pass@1 42.6%。
Pass@1 是单次采样正确的概率。AIME 每题 32 个样本，99.9% 是 960 次 rollout 的平均；HLE 只采一次，噪声大得多。评测 README 提醒，重复运行结果会有差异，而且只有当 coverage_complete 为 true 时，Pass@1 数值才有效。
这些数字告诉你，模型在默认配置下于这些基准上具备相应能力。它们不会告诉你，这个引擎比另一个引擎更快、更便宜或更可靠。要回答那个问题，你需要一个在相同硬件、上下文和负载下做的服务基准——最好还有第三方来跑。
一份阅读清单
看到一份推理基准时，先问：
- 单位是什么？tokens/s/GPU、tokens/s/user，还是 ms/step？
- 负载是什么？上下文长度、输入输出比例、缓存命中率、请求到达模式。
- 硬件是什么？GPU/NPU 型号、数量、互联、内存，以及是单节点还是集群。
- 批量或并发是多少？高并发下的吞吐峰值，对延迟敏感的产品可能毫无意义。
- 包含了什么？只有引擎，还是带 KV cache、路由和 API 开销的完整服务栈？
- 假设了什么？draft 接受率、缓存命中率、量化、张量并行/流水线并行。
- 谁跑的？厂商自测、独立实验室，还是带 commit hash 的复现？
- 对比对象是什么？同模型、同硬件、同负载、同 SLO？
如果一条主张在其中三项或更多上答不出来，就把它当作方向性信号，而不是采购数字。
别问“DeepInfer 有多快？”要问“在我买得到的硬件上，DeepInfer 在什么批量、上下文长度和并发下能满足我的延迟 SLO，而每百万 token 的成本又是多少？”那张图可以开启这场对话，但没法替你结束它。