大语言模型推理速度评测：tokens/s到底该怎么测

评测概述

在部署大语言模型时，”生成速度是多少 tokens/s”几乎是被问得最多、也最容易被误读的问题。一个孤立的 tokens/s 数字既可能来自不同的硬件、不同的输入输出长度，也可能来自是否开启批处理、是否量化、是否启用投机解码等完全不同的条件。因此，本文不打算给出”某个数字就是好”的结论，而是帮助读者建立一套可复现、可解释、可对比的推理速度评测方法：搞清楚 tokens/s 到底衡量什么、哪些因素在影响它、如何设计公平的测试、以及拿到结果后该如何解读其适用边界。

评测目标

本次评测要回答的核心问题包括：

• tokens/s 这个指标究竟代表什么，它与首字延迟、单字延迟、整体吞吐之间是何种关系；
• 影响生成速度的关键变量有哪些，为什么两个不同来源的 tokens/s 不能直接比较；
• 如何在不夸大、不误导的前提下，设计一个控制变量的测速流程；
• 推测解码（投机采样）这类优化手段能带来多大收益，收益又依赖哪些前提；
• 在不同业务场景下（低延迟对话 vs 高吞吐批处理），应该重点关注哪些指标。

评测对象说明

评测对象包含两个层面。其一是性能指标 tokens/s，即模型每秒生成的 token 数量，通常用来衡量文本生成的”吐字速度”。其二是推理加速技术，本文以推测解码（也称投机采样）为典型代表来说明优化评测。

推测解码的基本思路，与”先小范围预测、再统一校验”的模式类似：先由一个轻量的草稿模型（或轻量预测头）快速推测出接下来的若干个候选 token，再让主模型对这 n+1 个位置做一次并行验证；如果主模型认可草稿的预测，那么这 n 个 token 就被一次性确认，相当于一次前向计算产出了多个 token；如果中途某个 token 不被接受，则从该位置起重新计算。由于大模型一次并行验证多个位置的成本，远低于逐个自回归生成，因此在实际项目中，有实践显示生成速度可以从约 40 tokens/s 的量级提升到接近 120 tokens/s 的量级。需要强调的是，这一提升高度依赖草稿模型的质量、任务的可预测性、批处理设置与硬件条件，不能视为普适的固定倍数。

评测维度设计

单一 tokens/s 不足以支撑选型，建议将其拆解为可观察、可验证的多个维度：

维度	关注问题	验证方式
吞吐（tokens/s）	单位时间内总生成量	固定并发下统计总输出 token / 总耗时
首字延迟（TTFT）	从请求到第一个 token 的时间	记录请求发出到首 token 到达的间隔
单字延迟（TPOT/ITL）	生成阶段的平均间隔	统计首 token 后相邻 token 的时间差
输出质量	加速后结果是否等价	与无加速基线做一致性/人工抽检比对
资源消耗	显存、算力、功耗占用	监控加速卡利用率与显存曲线
并发能力	多请求下的稳定性	逐级加压观察吞吐与延迟变化
稳定性	长时间、异常输入下的表现	长时压测、超长/异常输入注入
可观测性	指标是否可采集	检查是否暴露延迟、吞吐、接受率等指标

其中最容易被忽略的是输出质量与单字延迟：加速技术往往提升整体吞吐，但首字延迟可能因草稿阶段而略有变化；同时，投机解码是一种”结果应等价”的加速方式，评测时必须确认加速前后输出的一致性，而不是只看速度数字。

评测环境与前提

公平测速的前提是”变量可控”。测试前必须固定并如实记录以下条件：

• 硬件资源：加速卡型号类别、卡数、显存容量、互联方式；
• 模型精度：是否量化、量化位宽、上下文长度上限；
• 输入输出规格：输入 prompt 长度、生成长度（max tokens）需明确，因为长输出会显著拉高平均 tokens/s；
• 并发与批处理：单请求还是并发、批大小、调度策略；
• 软件栈：推理服务框架、运行时版本、是否开启投机解码及其草稿模型配置；
• 网络条件：客户端到服务的链路，避免把网络传输时间计入生成速度。

只要上述任一条件不同，两组 tokens/s 就不可直接比较。

评测方法

建议按以下流程执行：

1. 定义指标口径：明确统计的是端到端吞吐还是纯生成吞吐，是否包含排队与网络时间；
2. 准备代表性样本：使用贴近真实业务的 prompt 集合，覆盖短/中/长输入；
3. 建立基线：先测关闭优化的原始版本，记录吞吐、TTFT、TPOT；
4. 分段测量：区分 prefill（预填充）阶段与 decode（解码）阶段，避免长输入掩盖生成阶段真实速度；
5. 控制变量对比：仅改变单一变量（如是否开启推测解码）再测一次；
6. 记录资源与分布：同步采集显存、利用率，并对多次运行取分布（中位数、P95），而非单次峰值；
7. 质量校验：对加速前后的输出做一致性比对或人工抽检，确认速度提升没有牺牲结果。

示意性的测量伪代码（通用示例，非特定工具）：

def measure_generation_speed(client, prompts, max_tokens, runs=5):
    results = []
    for _ in range(runs):
        total_tokens = 0
        t0 = now()
        first_token_time = None
        for p in prompts:
            stream = client.generate(prompt=p, max_tokens=max_tokens, stream=True)
            for i, tok in enumerate(stream):
                if i == 0:
                    first_token_time = now()   # 记录 TTFT
                total_tokens += 1
        elapsed = now() - t0
        results.append({
            "tokens_per_sec": total_tokens / elapsed,
            "ttft_ms": first_token_time - t0,
        })
    return summarize(results)  # 输出中位数与 P95

结果解读

拿到结果后，重点不是”哪个数字大”，而是”这个数字在什么条件下成立”：

• 吞吐提升要看接受率：推测解码的收益取决于草稿 token 被主模型接受的比例（接受率）。任务越可预测（如结构化输出、代码补全），接受率越高，加速越明显；开放域创作类任务接受率偏低，收益会打折。
• 平均 tokens/s 可能被长输出抬高：如果测试里输出很长，平均生成速度会偏高，需结合单字延迟一起看。
• TTFT 与 TPOT 需分开解读：交互式对话更在意首字延迟，批处理更在意总吞吐，两者的最优配置往往不同。
• 质量必须回归验证：只有当加速前后输出一致性达标，速度数字才有意义。

适用场景分析

• 低延迟交互（对话、助手）：优先关注 TTFT 与 TPOT，可接受略低吞吐换取稳定响应；
• 高吞吐离线批处理（数据生成、批量摘要）：优先关注总吞吐与资源利用率，投机解码收益通常更明显；
• 质量敏感场景（专业问答、生成校验）：需把输出一致性作为前置门槛，再谈速度。

风险与限制

• 样本偏差：prompt 分布不代表真实业务时，接受率与速度都会被高估或低估；
• 环境差异：不同硬件、精度、批处理下的数字不可横向对比；
• 优化条件依赖：投机解码的收益随草稿模型质量与任务类型波动，不能套用固定倍数；
• 质量风险：任何加速都应回归验证输出一致性，避免”快而错”。

选型与使用建议

建议读者以”分维度、控变量、看分布、验质量”为原则做决策：先明确业务更在意延迟还是吞吐，再在固定条件下建立基线并逐项对比；对推测解码等加速技术，务必同时评估接受率、输出一致性与资源占用；最终结论应表述为条件化判断，例如”在高可预测性的批量生成场景下，该类加速手段通常能带来可观吞吐提升，但需以质量回归为前提”，而非绝对化的”最快/最优”。

总结

tokens/s 是大语言模型推理的重要速度指标，但脱离条件的单一数字几乎没有决策价值。本文从指标口径、维度拆解、环境控制、测试流程、结果解读到场景适配，给出了一套可复现的评测框架，并说明了推测解码这类优化手段的收益来源与适用边界。真正可靠的选型，来自对速度、质量、资源与场景的综合权衡，而非对某一峰值数字的追逐。