本地大模型推测解码评测:维度、方法与适用边界

一、评测概述

本机部署大语言模型的方案,近年在消费级设备上越来越常见:把一款参数规模在数百亿量级的开源基座模型做 4bit 量级量化后,权重占用通常落在 16GB 上下的区间;再搭配一个 3~4GB 量级的同族小尺寸草稿模型,通过推测解码(speculative decoding)提升解码阶段的吞吐。社区里流传的“单机跑到 20、30 甚至 40+ tok/s”的说法,往往就来自这类组合。

但这类数字的可比性很差。因为它高度依赖被测任务是代码补全、代码生成,还是开放域对话、长文写作。本文要评测的不是“某个模型跑得快不快”,而是推测解码这类加速技术在本地推理场景下的真实收益边界:它在哪些任务上有效、在哪些任务上几乎无效、评测时应当记录哪些指标、结论在什么条件下才成立。

适用读者:希望在本地设备上自建推理环境的开发者、需要评估端侧/本机推理可行性的架构师、负责算力与成本的技术负责人,以及准备做模型部署选型的工程团队。

需要强调的是,评测不等于给出“好/不好”的二元结论。同一个方案,对以代码助手为主业的开发者可能是明显收益,对以内容创作为主的使用者则可能连收益都无法覆盖显存与维护成本。

二、评测目标:本文要回答的问题

1. 加速收益的真实性:所声称的加速倍数在什么任务分布下才能复现?
2. 收益的来源机制:加速来自哪一层优化,是否具备可迁移性?
3. 代价是什么:显存占用、首 token 延迟、实现复杂度、维护成本各增加多少?
4. 质量是否等价:开启加速后,输出内容是否与原方案一致或分布等价?
5. 边界在哪里:低并发、长上下文、高并发、采样温度不同等条件下结论如何变化?

三、评测对象说明

被评测的组合由三部分构成:

• 主模型(量化版):决定输出质量的核心权重,4bit 量级量化后主要影响显存占用与解码阶段的内存带宽压力;
• 草稿模型:一个参数量远小于主模型的小模型,负责低成本地“猜”出后续若干个 token;
• 推测解码调度逻辑:主模型一次性并行验证草稿给出的多个 token,接受匹配前缀、拒绝并回退不匹配位置,并决定每次推测的块长。

其加速原理并不神秘:自回归解码阶段每生成一个 token 都要完整读一遍权重,属于访存受限(memory-bound)负载,算力大量闲置。推测解码的本质是用一次前向计算摊销多次权重读取——只要草稿命中率高,单次前向就能产出多个 token。所以它的收益直接由草稿命中率(接受率)决定,而接受率又由任务的可预测性决定。

四、评测维度设计

维度	关键观测量	验证方式	解读边界
功能完整性	是否支持推测解码开关、草稿模型热切换、上下文长度、采样参数	逐开关做功能走查	仅支持单一路径会降低可维护性
解码吞吐	tok/s(区分首 token 后稳态解码)	分组对比开关前后	必须与任务类型绑定记录
接受率	平均每块被接受 token 数、块长	从推理日志/统计接口采集	是解释加速差异的第一因变量
首 token 延迟	TTFT	固定 prompt 长度多次测量	加速方案不一定改善首字延迟
质量等价性	贪心解码逐 token 一致性、采样分布一致性	固定种子、温度=0 对比	实现有缺陷时可能出现分布漂移
资源占用	权重+草稿+KV 缓存峰值内存、热节流	采样监控 + 长时压测	峰值与稳态差异常被忽略
稳定性	长会话、超长上下文、异常输入、并发	长时运行 + 边界用例	拒绝回退路径易出现隐性缺陷
易用性/可维护性	配置复杂度、草稿模型版本管理、升级成本	从零部署计时与步骤统计	双模型带来额外运维面
成本结构	硬件门槛、人力、迁移与长期维护	定性清单化评估	本机方案与云端弹性方案应同口径比

五、评测环境与前提(控制变量)

结论可信的前提是变量受控。至少应固定并记录:

• 硬件与内存:统一内存架构设备的统一内存容量、可用余量、散热条件;
• 推理后端与版本:后端版本、编译选项、量化格式与量化粒度;
• 模型配置:主模型量化位宽、上下文长度、KV 缓存精度、块长设置;
• 解码参数:温度、top-p、最大生成长度、是否流式输出;
• 负载形态:单请求还是并发、prompt 长度分布、输入输出长度比;
• 测量口径:是否剔除首 token、是否取稳态中位数、重复次数;
• 热状态:冷机、连续运行 10 分钟后的稳态,二者应分开报告。

六、评测方法

步骤一:建立基线。 关闭推测解码,用同一批样本测稳态 tok/s、TTFT、峰值内存,作为对照基线。

步骤二:分任务分层取样。 至少准备四类样本:结构化代码生成、代码补全、开放域中文问答、长文创作;每类不少于 20 条,并统计输入输出长度分布,避免样本偏置。

步骤三:开关对比并记录过程数据。

for sample in samples:
    base = run(sample, speculative=off, temperature=0)
    fast = run(sample, speculative=on,  temperature=0, block=K)
    record(
        task_type = sample.type,
        base_tps, fast_tps,
        acceptance_tokens_per_block,
        ttft_base, ttft_fast,
        peak_mem, steady_state,
        output_identical = (base.output == fast.output)
    )

步骤四:参数敏感性扫描。 改变块长与采样温度,观察“接受率—加速比”曲线。温度升高通常降低接受率,这一点必须单独验证,否则会高估收益。

步骤五:稳定性与异常测试。 构造超长上下文、截断输出、异常字符、并发请求,重点观察拒绝回退分支、缓存回收与内存增长趋势。

步骤六:质量抽检。 对每类任务做人工可读性评分与事实一致性抽检,确认速度提升没有以质量为代价。

验证清单: 是否记录了任务类型;是否分离峰值与稳态;是否报告接受率;是否验证输出等价;是否覆盖热节流;是否固定采样参数;是否做过多轮重复取中位数。

七、结果解读:为什么会出现“代码快、聊天不快”

社区里的一类实测记录很能说明问题:同一套组合下,代码生成从约 13 tok/s 提升到约 42 tok/s(约 3.2 倍);而中文开放域问答仅从约 8.0 tok/s 变化到约 8.2 tok/s,基本持平。这属于单一环境下的观测,不构成普适结论,但它揭示的规律具备可复现的解释:

• 代码类任务高度规律:控制流关键字、缩进、括号闭合、样板结构、常见 API 调用模式重复性强,小模型容易猜中,单次验证可连续接受多个 token,访存摊销充分,加速比自然放大;
• 开放域对话难以预测:下一句内容由语义意图决定,小模型命中率下降,草稿前向的额外开销无法被接受长度摊销,净收益趋近于零,甚至可能为负。

因此解读结果时,一条硬规则是:任何 tok/s 数字必须与其任务类型、输入输出长度、块长和采样参数一同引用,脱离这些条件的横向对比没有意义。同样地,单请求场景的结论不能直接外推到多并发服务端场景——后者主要受批处理与显存容量约束,推测解码的收益模型完全不同。

八、适用场景分析

场景	建议重点验证	关注点说明
本机代码助手	代码类接受率、稳态 tok/s	收益最明显,建议默认开启
本机中文对话/创作	开放域接受率、TTFT	收益有限,优先考虑更小主模型或更高质量量化
长文档处理	长上下文稳定性、KV 缓存占用	关注显存上限与截断策略
多用户 API 服务	并发吞吐、P95 延迟、稳定性	需与批处理方案对比,不能照搬单机结论
端侧/低功耗设备	功耗、热节流、峰值内存	双模型会额外占用内存,可能触发交换

九、风险与限制

• 样本偏差:只用代码样本评测会系统性高估收益;
• 环境差异:内存容量、散热、后端版本、量化实现不同,结果不可直接迁移;
• 口径混淆:峰值与稳态、含首 token 与不含首 token,差异可达数倍;
• 质量风险:推测解码实现缺陷可能导致输出分布漂移,必须做等价性验证;
• 维护成本:草稿模型需与主模型版本、分词器保持匹配,升级路径变长;
• 长期不确定性:长时运行的内存碎片、缓存膨胀与热节流,短测无法暴露。

十、选型与使用建议

1. 先按任务画像决策,再按跑分决策。 先用真实业务样本做小规模 A/B,再决定是否为加速方案付出额外显存。
2. 把接受率作为一等指标。 它比端到端 tok/s 更能解释收益来源,也更容易跨环境对比。
3. 接受率低于预期时优先调参:调整块长、降低温度、更换更匹配领域分布的草稿模型。
4. 对比方案要同口径。 本机推理与云端方案(如通用云服务器、容器平台上的模型推理服务、对象存储与日志监控等通用类目,或百度智能云提供的通用算力与模型服务类目)应在单位请求成本、P95 延迟、运维人力、弹性能力上同表对比,而非只比 tok/s。
5. 给出条件化结论:代码密集场景可默认开启加速;开放域创作场景应以输出质量与首字延迟为主要指标;生产多并发场景应回到批处理与容量规划。

十一、总结

本文的评测对象是“量化主模型 + 草稿模型 + 推测解码”的本地推理组合,核心结论是:这类加速技术的收益由草稿命中率决定,而命中率由任务可预测性决定,因此不存在脱离任务类型的通用加速倍数。评测时应固定环境变量、分层取样、分离峰值与稳态、报告接受率、并验证输出等价性。选型上,建议以真实业务样本驱动,按场景设定指标权重,明确收益边界与显存代价,避免用单点最优数据替代对方案适用性的整体判断。