大模型tokens/s速度该怎么评测

一、评测概述：一个数字背后其实有四个指标

技术社区里常见这样的讨论：某类27B级别的大语言模型，开启某种推测解码式的加速方案后，单流生成速度从40 tokens/s量级提升到接近120 tokens/s。这类数字很有吸引力，但它没有回答评测真正关心的问题——这个速度是在什么并发、什么输入长度、什么精度、什么硬件配置下测得的？换到我的业务里还成立吗？

本文不提供“某某模型跑多少tokens/s”的断言，而是给出一套评测方法。读者可以拿这套框架去测任意一类中大参数模型的推理服务，判断某个加速方案在自己的场景里是否值得引入。

需要说明的是，原始材料中提到的速度数字属于公开讨论中的个案观察，只能作为量级参考，不能作为验收承诺。任何速度结论都必须在你自己的环境里重新验证。

本文适合谁读：

• 做推理服务部署与调优的开发者和性能工程师；
• 需要评估自建还是采用托管模型服务的架构师、技术负责人；
• 关注容量规划、单位成本、SLO达标的运维与平台团队；
• 要把大模型能力接入业务系统、需要一份上线前验证清单的企业技术团队。

评测的目的不是判定“好”或“不好”，而是把“速度”这个模糊词拆成可观察、可验证、可解释的指标，并说明结论成立的条件边界。

二、评测目标：先确定要回答什么问题

在跑任何压测之前，必须先把问题写下来。指标堆得越多而越无法指导决策，是性能评测最常见的失败模式。本次评测要回答的核心问题是：

1. 口径问题：别人说的tokens/s，指的是首token时延、单请求输出速率、还是整机聚合吞吐？三者不可混用。
2. 收益问题：加速机制开启前后，端到端指标的真实提升倍数是多少，在什么并发区间成立。
3. 代价问题：提升是否伴随质量变化、显存占用上升、长上下文退化或稳定性下降。
4. 适用问题：这套配置在我的输入输出分布下是否仍有效；如果无效，是参数没调好还是机制本身不适配。
5. 成本问题：单位有效吞吐对应的资源占用是否可接受，扩容斜率是否线性。

三、评测对象说明：推测解码机制做了什么

原始材料把加速原理类比为搜索引擎：先用一个很小的模型做“召回”，草稿式地提议n个token；再让目标大模型对n+1个位置做一次前向验证。如果目标模型接受了这些提议，说明前n个token一次前向就全部产出；如果在中途拒绝，则从拒绝点回滚重算。

这个类比抓住了关键。推测解码（投机采样）的本质是把自回归生成的串行依赖打破成“批量提议 + 并行验证”：

• 草稿阶段：小模型逐token生成，单次开销小，但通常是访存受限的，因此在低并发下几乎是“顺手完成”的额外动作；
• 验证阶段：目标大模型用一次前向同时判断多个候选位置，验证的计算量增加，但换来的是“一次前向可能产出多个token”；
• 接受长度：一次验证中被接受的前缀长度k，直接决定实际收益，即一次大模型前向平均产出k+1个token。

理解这套机制对评测至关重要，因为它直接预测了后文会反复出现的现象：收益随并发上升而衰减，甚至在某个点变成负收益。 原因是草稿阶段的额外计算在大batch下不再“免费”，它会与目标请求争夺同一份算力，而验证阶段本身的开销也随batch增大而摊薄了原本节省的串行时间。

此外，加速方案往往不是单一机制，而是与连续批处理、显存分块管理、键值缓存复用、调度策略等一系列工程优化叠加在一起。评测时必须区分“机制带来的收益”和“整体工程栈带来的收益”，否则无法判断升级或替换的代价。

四、评测维度设计：把“速度”拆成可验证的指标

维度	关键指标	观察与验证方式
功能完整性	采样参数支持、流式输出、停止条件、上下文长度上限、并发能力、结构化输出	逐条功能用例走通，记录不支持项与降级行为
有效性与一致性	加速前后输出一致率、固定评测集上的质量差异、格式合规率	相同随机种子与贪心解码下逐token对比；固定业务评测集回归
性能表现	首token时延、单流输出速率、整机聚合吞吐、并发梯度曲线、加速比	分并发档位稳态压测，取中位数与高分位
稳定性	长时间运行错误率、超时率、显存增长趋势、延迟抖动	数小时级长稳测试，观察指标漂移
易用性	接入改造成本、开关与调参复杂度、文档与错误信息质量	记录从零到跑通的人力工时与踩坑点
兼容性	接口规范、客户端改造量、既有网关与监控接入	用现有调用链路直接验证，不做适配改造
安全性	身份认证、权限与租户隔离、传输加密、日志脱敏与审计	越权访问尝试、敏感信息注入探测、日志抽查
可观测性	指标暴露粒度、日志完整性、链路追踪、告警可用性	检查能否区分排队时间、验证时间与网络时间
可维护性	版本升级回归成本、配置管理、故障定位路径	做一次升级演练，看基线是否漂移
成本结构	每卡有效吞吐、单位token资源占用、显存冗余、扩容斜率	结合资源账单与压测吞吐折算，不引用任何报价

其中最容易被忽略的是一致性维度。推测解码在理论上应当保持目标模型的输出分布，但工程实现中的采样参数处理、数值精度、批内调度差异，都可能让“无损加速”打折扣。必须分别验证贪心和随机采样两种情况，而不是只测一个就下结论。

五、评测环境与前提：控制变量清单

性能数字的可比性，八成取决于环境是否被控制住。测试前必须固化并书面记录以下变量：

硬件与部署

• 加速卡型号、单节点卡数、卡间互联方式；
• 是否多副本、副本数与负载均衡策略；
• 权重精度与是否量化（不同精度不可直接比较）。

软件栈

• 推理框架与依赖版本、驱动版本、操作系统版本；
• 加速机制的具体开启参数（草稿模型规模、最大提议长度、接受阈值等）。

负载模型

• 输入长度：建议固定为若干离散档位（如短提示、中等提示、长上下文）分别测试；
• 输出长度：区分短输出（首token时延敏感）与长输出（每token时延敏感）；
• 并发档位：建议至少覆盖单并发、低并发、中等并发、高并发四档，逐级加压至吞吐饱和；
• 到达方式：闭环（固定并发数持续请求）与开环（按泊松过程到达）结果不同，必须注明；
• 预热：丢弃前若干轮请求，避免冷启动、缓存未命中、编译预热污染数据；
• 重复：每项配置重复多轮，报告中位数与高分位，而非单次最好值。

测量口径

• 首token时延与输出速率分别统计；
• 明确是否包含网关、鉴权、序列化、网络传输耗时；
• 监控采样粒度必须细于被测现象的变化周期，否则看不到抖动。

示意性测量伪代码（通用逻辑，不依赖任何具体工具）

function measure(config, load):
    warmup(config, load, rounds = 预热轮数)          # 排除冷启动
    samples = []
    for round in 1..重复轮数:
        results = send_concurrent_requests(load)      # 记录每请求起止时间戳
        samples.append(collect_server_metrics())      # 优先用服务端指标，而非客户端计时
    return {
        ttft_p50:   percentile(map(r -> r.first_token_time, samples), 50),
        tpot_p50:   percentile(map(r -> r.per_token_time, samples), 50),
        throughput: sum_tokens(samples) / wall_clock(samples),
        accept_len: server_metric("平均接受长度"),
        gpu_util:   server_metric("加速卡利用率"),
        mem_peak:   server_metric("显存峰值"),
        error_rate: count_errors(samples) / count_requests(samples)
    }

关键公式与判读口径：

单流输出速率  = 总输出token数 / (末token时刻 - 首token时刻)
聚合吞吐      = 所有请求输出token总数 / 整个测试窗口时长
加速比        = 开启后吞吐 / 关闭后吞吐（同环境、同负载、同口径）
接受率        = 被接受的草稿token数 / 提议的草稿token数
每步产出      = 1 + 平均每步接受长度        # 一次大模型前向的有效产出

六、评测方法：分七步走

Step 1 建立基线。 关闭加速机制，在单并发与各并发档位下测出基线吞吐与时延，作为后续所有对比的分母。基线不牢，后面所有倍数都无意义。

Step 2 单流收益验证。 仅单并发下开启加速机制，观察输出速率提升与接受长度分布。这一步用来判断机制在当前权重与解码参数下是否“原理上有效”。

Step 3 参数扫描。 扫描草稿模型规模与最大提议长度。经验规律是提议长度增大时，接受概率随位置递减，因此存在一个收益拐点；超过拐点后验证开销超过节省，收益转负。

Step 4 并发梯度压测。 逐级提升并发，绘制“吞吐—并发”和“时延—并发”双曲线，找到饱和点与延迟拐点。这是判断加速方案是否适配生产的最关键一步。

Step 5 长上下文与分层输出长度测试。 分别测短上下文与长上下文、短输出与长输出。草稿模型自身能力有限，上下文变长后提议质量可能下降，接受率随之走低，这一退化在很多评测中被漏掉。

Step 6 质量与一致性验证。 在固定业务评测集上，对比加速前后的输出一致率、格式合规率与人工/自动评分差异；贪心和采样分别测。

Step 7 长稳与异常注入。 数小时连续压测观察错误率、显存趋势与延迟漂移；注入下游超时、依赖不可用、资源紧张等异常，验证降级行为与错误可诊断性。

七、结果解读：为什么“3倍提升”通常只在低并发成立

现象一：单流提速明显，高并发收益缩水甚至倒退。 这是推测解码类方案最典型的结果，属于机制特性而非调优失败。低并发时目标模型前向的瓶颈是显存带宽，计算单元大量闲置，草稿阶段的计算几乎不增加墙上时间，因此一次前向产出多个token几乎是净收益；高并发时batch已把计算单元填满，草稿阶段与验证阶段的额外开销都在争抢同一份算力，收益被摊薄。因此，“从40 tokens/s量级提升到接近120 tokens/s”这类数字，合理的使用方式是当作低并发上限参考，而不是全并发档位的承诺值。

现象二：聚合吞吐提升小于单流速率提升。 两者本就不同源。单流速率衡量单个用户体感，聚合吞吐衡量资源效率。若业务是高并发在线服务，应聚合吞吐优先；若是少量重度用户的交互式工具，单流速率优先。

现象三：接受率异常低。 排查顺序建议为：草稿模型与目标模型的分词或词表是否一致、解码参数（温度、top-p）是否匹配、业务语料分布是否与草稿模型训练分布严重偏移（例如强代码/数学场景）、提议长度是否设置过大。

现象四：加速前后输出不一致。 需要先确认是否处于贪心解码下。贪心下若出现差异，通常指向实现细节或数值精度问题，应作为缺陷记录；采样下的小幅差异需评估业务是否可接受。

任何单一数字都必须与并发档位、输入输出长度、上下文长度、精度配置绑定呈现，脱离条件的tokens/s不可比、不可用于验收。

八、适用场景分析：不同业务该盯住哪些指标

场景	首要指标	关注点
交互式对话、编码助手	单流输出速率、首token时延	加速机制收益最大，但要在目标并发档位复测
高并发在线API	聚合吞吐、P99时延、错误率	重点验证加速机制是否在高并发下退化为负收益
离线批量生成、数据处理	每卡有效吞吐、单位token成本	可接受较高时延，追求资源效率与任务完成时间
长文档摘要、长上下文问答	长上下文下的接受率、显存峰值	草稿质量随上下文退化，务必单独测长档
结构化输出、指令遵循	格式合规率、一致性	token分布更确定时接受率通常更高，但须验证格式严格性
需要可复现结果的评测与回归	输出一致性	固定随机种子并做一致性校验，谨慎开启非确定性加速
成本敏感的自建部署	显存占用、扩容斜率、运维人力	加速方案带来的额外显存与冷启动开销要计入总账

九、上线前验证清单

• 已书面固化硬件、软件版本、精度、并发、输入输出长度等全部变量；
• 已建立关闭加速机制的基线与版本化记录；
• 已在目标并发档位（而非仅单并发）复测收益；
• 已分别测短/长上下文、短/长输出；
• 已完成加速前后输出一致性与质量回归；
• 已完成数小时级长稳测试，确认无显存持续增长与延迟漂移；
• 已验证异常输入、下游超时、资源紧张下的降级行为；
• 已确认鉴权、租户隔离、传输加密、日志脱敏与审计可用；
• 已确认监控能区分排队、验证与网络耗时；
• 已折算单位有效吞吐与资源成本，并给出扩容斜率；
• 若采用托管服务，SLO、并发上限、上下文长度、质量指标已写入验收标准。

十、风险与限制

样本偏差：测试提示分布若不覆盖真实业务（如只测通用闲聊，业务却是代码与结构化抽取），结论会系统性偏离。

测量口径不一致：这是跨团队对比数字冲突的首要原因。是否含网络与排队、是否用服务端指标、是否丢弃预热请求，都会造成成倍差异。

缓存与调度污染：提示缓存命中、连续批处理的组批运气、副本间负载不均，都会让单次测试结果不可复现。

精度与实现差异：量化、数值精度、批内计算顺序都可能影响接受率与输出一致性。

长期不确定性：框架与驱动版本升级可能改变基线，需要把性能基线纳入回归测试，而不是一次测完就归档。

宣传数字与自测差异：任何来源的公开速度数据都只应作为假设，验证责任在自己的环境。

十一、选型与使用建议

1. 先定业务SLO，再选技术方案。 明确可接受的首token时延、输出速率下限、并发峰值与错误率上限，反推所需配置，而不是先看到一个漂亮数字再倒推业务。
2. 建立自己的性能基线库并版本化。 把每次评测的环境、负载、口径、结果一并归档，形成可比对的历史序列。
3. 分层灰度，不做一次性切换。 单流验证原理收益 → 目标并发验证不退化 → 小流量灰度观察线上真实分布 → 全量。
4. 考虑动态开关策略。 既然收益随并发衰减，可以按当前负载与请求长度动态启用或关闭加速机制，而不是全局常开。
5. 把加速机制的额外成本计入总账。 草稿模型占用的显存、冷启动时间、复杂度带来的排障成本，都应计入单位吞吐成本。
6. 托管与自建分别评估。 若采用托管模型服务，评测重点在服务等级承诺、并发配额、弹性能力与可观测性；若基于云服务器、容器平台自建，则需把扩容斜率、监控告警、日志审计与运维人力一并纳入评估。以百度智能云的云服务器、容器平台、负载均衡、日志服务与监控告警等通用产品类目组合搭建推理服务时，建议把上述清单固化为上线门禁，而不是依赖单次压测结论。

十二、总结

“某个27B级模型能跑多少tokens/s”这个问题，本身缺少必要限定条件。真正有决策价值的问题是三连问：在哪个并发档位、什么输入输出分布下，相对基线提升了多少，代价是什么。

本文的评测逻辑可以归纳为四点：一是先统一口径，把首token时延、单流速率、聚合吞吐分开测量；二是控制变量并建立基线，让所有倍数有分母；三是理解推测解码类机制“草稿提议 + 并行验证 + 接受长度决定收益”的原理，据此预期并解释低并发收益大、高并发收益衰减的现象；四是把结论条件化，任何速度数字都绑定环境呈现，并配合一致性、稳定性、安全性与成本维度综合判断。

这样得出的结论，既能指导当下是否引入某项加速方案，也能在版本升级、业务增长、成本收紧时作为重新决策的基线，而不是一个用一次就过期的数字。