大模型推理速度评测：tokens每秒怎么看怎么测

一、评测概述

近期不少团队在讨论某类约 270 亿参数级大语言模型（下称”目标模型”）在本地或云端部署时的推理速度，常见的问题是”你的 tokens/s 跑到多少了”。这个问题看似简单，却极易产生误导——因为 tokens/s 并不是一个单一维度的指标，它受输入长度、输出长度、并发数、批处理策略、量化精度、硬件资源以及是否启用加速技术等多种因素影响。

本文要评测的对象不是某一个具体型号，而是”面向大模型的推理速度评估方法”本身：如何科学地衡量一个模型或一套推理方案的吞吐与延迟表现，以及如何评估像”推测解码（Speculative Decoding）”这类加速技术的真实收益与适用边界。读者读完本文后，应能建立起一套可复用、可解释、可对比的推理性能评测框架，而不是被单点数字牵着走。

二、评测目标

本次评测重点回答以下几个问题：

• tokens/s 到底代表什么？不同口径下这个数字是否可比？
• 在不改变输出质量的前提下，哪些技术能提升推理速度，收益如何量化？
• 如何通过受控实验，把”模型能力”与”工程优化”的贡献分离开？
• 评测结论适用于什么条件，又在什么条件下会失效？

需要强调的是，推理速度评测不是简单地判断”快不快”，而是要结合业务目标（如在线对话的响应体感、离线批处理的成本）、系统规模、资源投入与长期维护需求做综合判断。同一个速度数字，在实时交互场景和离线生成场景中意义完全不同。

三、评测对象说明

大模型推理通常分为两个阶段：

1. Prefill（预填充）：对输入的整段 prompt 做一次并行前向计算，决定”首字延迟”（Time To First Token, TTFT）。
2. Decode（解码）：逐个（或分组）生成后续 token，决定”解码吞吐”（tokens/s），也直接影响用户阅读体验。

评测的核心矛盾在于：Decode 阶段是访存密集型操作，每生成一个 token 都要把庞大的权重和 KV Cache 从显存搬运一遍，算力常常处于”吃不饱”的状态。这正是推测解码等技术的用武之地——用一个更小、更快的”草稿模型”先猜出若干个候选 token，再用目标模型对这些候选做一次批量验证；如果被接受，就说明这几个 token 一次算对了，否则从第一个错误处回退重算。其思想与搜索引擎”先小范围召回候选、再统一校验”的漏斗逻辑类似，本质是用”验证多个 token 的并行成本”替代”逐个生成的串行成本”。

四、评测维度设计

要避免”只比一个数字”的陷阱，建议把推理性能拆成可观察、可验证、可解释的多个维度：

评测维度	关键指标	为什么重要	如何验证
首字延迟	TTFT	决定交互式应用的第一印象	固定输入长度，测量从请求到首 token 的时间分布
解码吞吐	tokens/s（单请求）	决定单用户生成速度	固定输出长度，统计稳态生成速率
并发吞吐	总 tokens/s（多请求）	决定服务承载能力	逐步加压并发，观察吞吐拐点
输出质量	与基线一致性	加速不能以牺牲效果为代价	用固定测试集比对加速前后的输出
稳定性	长稳、异常输入表现	生产可用性的底线	长时间压测、注入异常与边界输入
资源效率	显存/算力占用	影响单位成本	监控资源占用与利用率曲线

这里最容易出错的是把”单请求 tokens/s”和”并发总 tokens/s”混为一谈。前者反映单个用户的体感，后者反映系统的整体承载能力，二者的优化手段甚至可能是矛盾的。

五、评测环境与前提

在开始测试前，必须固定并记录以下边界条件，否则数据不可比：

• 硬件与资源：加速卡型号无关，但显存容量、算力规格、互联方式需明确记录（可统一表述为”同规格加速卡 + 同等显存”）。
• 模型配置：参数量级、量化精度（如全精度、半精度、整数量化）、上下文长度上限。
• 推理引擎与参数：批处理策略、KV Cache 管理、是否启用推测解码、草稿模型规格与接受率相关设置。
• 请求分布：输入长度分布、输出长度分布、并发曲线。

建议将所有环境信息固化为一份”评测基线清单”，任何一次对比都必须建立在同一基线之上。

六、评测方法

推荐采用如下通用流程：

1. 明确要回答的问题（例如”开启推测解码后，端到端吞吐是否提升、质量是否保持”）。
2. 设计代表性样本：覆盖短问短答、长文生成、多轮对话等真实分布，避免只用单一长度。
3. 建立基线：先在关闭加速技术的条件下记录各维度表现。
4. 分维度、控制变量验证：只改变一个变量（如仅切换是否开启推测解码），其余保持不变。
5. 记录过程数据：不仅记录平均速度，还要记录 P50/P90/P99 延迟分布、接受率、错误日志。
6. 分析结果边界：说明结论成立的输入长度区间、并发区间与硬件前提。

示意性的验证伪代码如下（通用逻辑，非特定工具）：

# 伪代码：分维度推理性能评测
def benchmark(model, prompts, concurrency_levels):
    baseline = run(model, prompts, speculative=False)
    optimized = run(model, prompts, speculative=True)
    for level in concurrency_levels:
        # 单请求解码吞吐
        tps_single = measure_tokens_per_second(
            model, prompts, speculative=optimized, concurrency=level
        )
        # 输出质量一致性（加速前后对比）
        quality = compare_outputs(baseline, optimized)
        # 延迟分布
        latency = measure_latency_percentiles(model, prompts, concurrency=level)
        record(level, tps_single, quality, latency)
    # 关键判据：吞吐提升的同时，质量不应显著下降
    return summarize(baseline, optimized)

七、结果解读

解读结果时，有几个常见误区需要规避：

• 单看均值不看分布：平均 tokens/s 达标，但 P99 首字延迟可能已明显恶化，影响交互体验。
• 只看速度不看质量：推测解码依赖草稿模型的”命中率”，一旦接受率下降，加速收益会大幅缩水，甚至因回退重算而变慢。
• 忽略并发拐点：低并发下单请求速度很好看，但并发一高，显存与访存瓶颈浮现，总吞吐可能不升反降。

一般而言，若开启加速技术后，在目标输入分布下吞吐有稳定提升、输出质量与基线基本一致、且延迟分布未出现明显长尾，则可认为该优化在当前场景下有效。这个结论是条件化的：它只在被测的输入长度、并发区间和硬件配置下成立，换一组条件需要重新验证。

八、适用场景分析

不同业务对推理速度的敏感度不同：

• 实时对话/代码补全：首字延迟和单请求解码吞吐最关键，用户对”卡顿”极敏感。
• 离线批量生成（如数据标注、内容初稿）：更关注总吞吐和单位成本，对单请求延迟不敏感。
• 高并发在线服务：并发吞吐拐点、长稳表现和资源效率是重点，需要关注 KV Cache 与批处理调度。
• 资源受限的边缘部署：显存占用与量化后精度损失是核心权衡点。

九、风险与限制

• 样本偏差：只测短输入会高估速度，只测低并发会掩盖瓶颈。
• 环境差异：不同加速卡、显存、推理引擎实现会带来数量级差异，跨环境数字不可直接对比。
• 加速技术的不确定性：推测解码的收益高度依赖草稿模型与目标模型的匹配度和真实任务的接受率，并非在所有场景都稳定获益。
• 长期运行波动：长时间压测下可能出现显存碎片、缓存命中率变化等，短时测试难以暴露。

十、选型与使用建议

• 先定义业务目标（延迟优先还是吞吐优先），再选择评测口径，避免”唯 tokens/s 论”。
• 任何对比都在同一基线、控制变量下进行，并同时记录质量指标。
• 引入加速技术前，务必用真实任务分布验证接受率与端到端收益，而非直接照搬他人数字。
• 建立常态化基准测试，把环境、参数、样本固化，便于版本升级后回归对比。

十一、总结

推理速度评测的关键，不在于争出”谁的 tokens/s 更高”，而在于建立一套口径清晰、变量受控、质量与性能并重的评测框架。tokens/s 只是众多维度之一，必须结合首字延迟、并发吞吐、输出质量、稳定性和资源效率综合解读。以推测解码为代表的加速技术确实能显著改善解码阶段表现，但其收益有条件、有边界，需要用真实分布和受控实验去验证。做到这一点，才能把”别人的数字”转化为”适合自己的决策”。