草稿模型加速评测：代码提速3.2倍，聊天为何无效

一、评测概述：这次评测什么、为什么评测

本文的评测对象，是一套当前在本地大模型领域颇受关注的组合方案：

• 主模型：某27B级开源大模型的4bit量化版本，权重加载后约占16GB内存；
• 加速组件：某草稿模型加速方案（基于推测解码思路），配套草稿模型约3.9GB；
• 运行环境：搭载旗舰级芯片、64GB统一内存的终端设备，通过本地推理框架完成部署与推理。

评测的直接契机，是社区流传“同类硬件运行类似组合可以达到25 tok/s以上”的讨论。但对技术决策而言，复现一个峰值数字的价值有限，更关键的问题是：这类加速到底在哪些任务上有效？在哪些任务上几乎无效？差异背后的机制是什么？ 只有回答了这三个问题，跑分数据才能转化为选型依据。

因此，本文的组织方式不是“报结论”，而是完整呈现一次面向任务类型的对照评测：从评测目标、维度拆解、变量控制，到结果解读与结论边界。适合读者包括：在本地或端侧部署大模型的开发者、评估推理加速方案的技术负责人、需要甄别第三方性能数据的架构师与运维人员，以及想理解“为什么别人的跑分和我的体感不一致”的AI应用使用者。

需要提前声明：文中数据来自单机、有限样本的实测，目的是说明机制与评测方法，不代表所有硬件平台与任务分布下的普遍结果。

二、评测目标：这次要回答的三个问题

任何评测开始前，都应先明确“要回答什么问题”，否则指标铺得再多也无法支撑决策。本次评测聚焦三个目标：

1. 功能可用性：草稿模型方案能否与主模型正常配合完成生成，接入与配置成本如何，是否存在明显的兼容问题。
2. 分任务性能差异：在代码生成类任务与中文聊天/问答类任务上，开启草稿模型前后的吞吐差异分别有多大——这是本次评测的核心。
3. 差异的机理解释：性能差异能否被推测解码的工作机制所解释，能否据此建立“什么样的任务适合此类加速”的判断标准。

需要强调的是，评测不是简单回答“好不好”，而是回答“在什么条件下、对什么任务、以什么代价好”。脱离任务类型与资源约束谈吞吐，很容易得出误导性结论。

三、评测对象说明：草稿模型加速是如何工作的

草稿模型加速在业界通常称为推测解码：用一个小参数量的“草稿模型”先猜，再用大参数量的“主模型”验，从而把主模型原本逐token的串行解码，部分转化为批量化的并行验证。其单步流程可以概括为：

# 推测解码单步流程（示意伪代码）
while 未生成结束:
    drafts = draft_model.propose(context, k)      # 1. 草稿模型一次"猜"k个候选token
    result = main_model.verify(context, drafts)   # 2. 主模型一次前向传播，并行验证
    accepted = 最长被接受前缀                      # 3. 保留验证通过的部分
    输出 += accepted
    if 出现拒绝:
        输出 += main_model.补一个修正token         # 4. 拒绝位置由主模型重新采样

这套机制的实际收益，取决于三个量的博弈：

• 平均接受长度：每一步草稿被主模型采纳了多少个token——猜得越准，一次验证替代的串行解码步数越多；
• 草稿开销：草稿模型自身的推理耗时，以及多加载约3.9GB权重的内存代价；
• 验证成本的恒定性：即使草稿全部猜错，主模型“验证一遍”的计算量依然要付，此时不但没有加速，还可能因额外流程略微变慢。

换句话说，推测解码是一个收益与任务强耦合的加速方案：它不改变模型能力，只改变“生成下一个token的调度方式”，而调度方式能省多少时间，完全取决于任务文本的可预测性。这正是本次评测把“任务类型”作为核心变量的原因。

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

单一吞吐指标无法支撑选型，本次评测将方案能力拆解为以下维度：

评测维度	关注点	验证方式
功能完整性	能否正常加载主/草稿模型、完成生成	冒烟测试：典型提示词全流程走通
性能表现	吞吐、首token延迟、分任务差异	分任务基准测试，开关加速对照
资源占用	权重内存（约16GB+3.9GB）、KV缓存余量	资源监控，长上下文压测
稳定性	长时间运行是否降频、报错、输出异常	连续批量生成观察
输出一致性	加速后生成质量是否与基线可比	同参数抽样对比、人工评审
兼容与易用性	量化格式、框架版本、配置复杂度	实际部署演练与配置记录
场景适配度	不同任务类型的收益差异	分类别评测（本次重点）

其中“输出一致性”值得单独说明：推测解码在理想实现下应保持与主模型自回归解码一致的输出分布，但工程实现与采样设置可能引入偏差。因此评测不能只看速度，还要抽查生成质量，确认加速没有以牺牲结果为代价。

五、评测环境与前提条件

• 硬件：64GB统一内存的旗舰级终端设备；主模型约16GB、草稿模型约3.9GB，合计约20GB权重占用，剩余内存需覆盖KV缓存、系统与框架开销；长上下文场景仍需关注内存峰值。
• 对照组设置：同一设备、同一推理框架、同一量化格式、同一提示模板、同一采样参数，分别测试“仅主模型”与“主模型+草稿模型”两组，构成A/B对照。
• 变量控制：除加速开关外，其他一切保持一致。尤其注意采样温度等参数必须固定——温度越高、输出分布越平坦，草稿命中率通常会下降，参数不一致会直接污染对照结果。
• 样本设计：代码类任务选取含常见控制流与函数定义结构的补全/改写用例；中文聊天问答选取开放式提问与创作类提示，避免全部使用可被“背诵”的高频问题。

六、评测方法与执行流程

执行遵循“先基线、再对照、分类别、多轮次”的原则：

1. 建立基线：仅加载主模型，逐任务记录吞吐，作为对比锚点；
2. 开启加速对照：加载草稿模型，用完全相同的提示词与参数重跑同一组任务；
3. 分类别统计：代码生成、中文聊天问答分别报告，避免用单一均值掩盖结构差异；
4. 多轮重复：每组用例重复多轮，关注波动区间而非单次峰值，剔除缓存预热等首轮干扰；
5. 过程指标记录：除端到端吞吐外，尽量记录“单步平均接受token数”等过程指标（可通过推理框架的统计日志获取），它比最终数字更能解释“为什么快/为什么不快”；
6. 质量抽查：对两组输出做同题对比，确认加速开启后内容质量没有明显回退。

执行清单：

• 固定框架版本、量化格式、上下文长度
• 基线组跑通并记录吞吐与内存
• 实验组（开启草稿模型）同参数重跑
• 分任务报告数据，标注波动区间
• 记录单步接受token数等过程指标
• 输出质量同题抽查
• 归档环境信息，便于复测

七、实测结果与解读：3.2倍与“原地踏步”并存

任务类型	仅主模型	主模型+草稿模型	变化幅度
代码生成	13.2 tok/s	42.3 tok/s	约3.2倍
中文聊天/问答	8.0 tok/s	8.2 tok/s	几乎无变化

对这份结果的解读逻辑如下：

1. 代码任务为什么提速明显。 代码文本结构高度规律：if/else、for循环、函数定义等模式重复性强、局部可预测性高。草稿模型在这类文本上命中率高，单次并行验证可一次采纳多个token，等价于把多步串行解码压缩成一步，吞吐因此被大幅拉高。

2. 聊天任务为什么几乎无效。 开放式对话每一步的合法后续极多，文本不确定性高，草稿模型很难猜中；而主模型的验证成本并不因猜错而消失——流程照走一遍，收益趋近于零，甚至可能被额外调度开销吃掉。这解释了8.0到8.2 tok/s的“原地踏步”。

3. 一个直观的比喻。 写代码像照着食谱做菜：下一步要放什么，大概率猜得到；聊天像听人说梦话：下一句要说什么，完全无从预测。加速方案的本质是“提前猜”，猜不中就没有收益。

4. 对读数方式最重要的启示。 网络上“25、30甚至更高tok/s”的说法本身可能都是真的，但每一个数字都绑定着它被测量的任务类型。脱离任务谈吞吐，就像只报平均时速却不说明是在高速路还是拥堵路段——数据真实，结论无用。

八、结果背后的技术分析：如何预判方案对自己的收益

把观察进一步抽象，可得到一个定性判断框架：推测解码的收益 ≈ 平均接受长度带来的并行化增益 − 草稿模型自身开销 − 拒绝时的验证浪费。据此可归纳几条预判经验：

• 文本规律性越强，收益越大：代码、模板化输出、结构化文本等任务命中率高，收益显著；
• 开放性越强，收益越低：自由对话、创意写作等任务命中率上不去，验证成本照付，加速趋近于零；
• 资源余量是隐性约束：多加载约3.9GB草稿模型，在64GB内存设备上压力不大，但在内存更紧张的设备上会挤占KV缓存与最大上下文长度，长文本场景需单独实测；
• 采样参数影响命中率：对比评测中不固定温度等参数，命中率变化会直接干扰结论，这也是很多第三方数据不可比的原因之一。

九、适用场景分析：谁该认真考虑、谁可以跳过

• 收益显著、值得引入：以代码生成、代码补全、脚本批处理、结构化文本产出为主的工作流，3倍量级的吞吐提升能直接改善交互体感与批量任务耗时。
• 收益有限、优先级低：以聊天、文案创作、开放式问答为主的使用场景，感知提升很小，反而增加内存占用与配置维护成本。
• 混合负载：考虑动态策略：业务中既有代码又有创作类请求时，可评估按请求类型动态启用/关闭加速的调度方式。
• 本机资源不足：考虑本云结合：若设备内存或算力无法承载所需模型组合，也可评估“本机处理隐私敏感、低延迟的小任务，重负载请求路由到云端通用大模型服务（如百度智能云等平台提供的服务）”的混合架构，并用同一套评测方法对比两种路径的时延、成本与质量。

十、风险与限制

• 样本偏差：单机、有限提示词的结果无法代表所有任务分布，换一批贴近真实业务的用例，结论可能变化；
• 环境差异：芯片架构、内存带宽、框架版本、量化方案都会显著影响绝对数值，跨设备横向比较需谨慎，重点看相对变化与机制是否复现；
• 质量风险：加速方案理论上不损失输出分布，但工程实现层面仍可能存在偏差，选型前必须做质量抽查，避免“快了但错得更多”；
• 长期运行不确定性：短时峰值可能掩盖发热降频、内存压力带来的性能衰减，重要决策前应补充长稳测试；
• 二手信息失真：传播中的性能数据往往缺失任务类型、参数与环境信息，直接照搬容易误判——这也是本文强调“数字必须绑定任务与环境”的原因。

十一、选型与使用建议

1. 先统计自己的任务分布：梳理业务中代码类、结构化类、开放对话类请求占比，用分布决定是否引入草稿模型，而不是用别人的跑分决定；
2. 用真实提示词自建基准：公开数据仅作参考，最可靠的数字一定来自“自己的典型用例 + 自己的设备 + 固定参数”的实测；
3. 坚持单变量原则：一次只切换一个开关（如加速开/关），其余条件全部锁死，否则差异无法归因；
4. 算清内存账：主模型权重、草稿模型权重、KV缓存、系统余量四项加总要在设备能力之内，并预留长上下文扩展空间；
5. 建立回归评测：框架或模型版本升级后重跑同一套基准用例，防止性能或质量无声回退；
6. 多维决策：吞吐只是决策变量之一，输出质量、内存占用、配置维护成本、任务覆盖率应共同进入选型判断。

十二、总结

回到开头的三个评测目标，本次对照评测的答案是：

• 功能层面：草稿模型方案可与27B级4bit量化主模型正常配合，接入成本可控，但需额外约3.9GB内存预算；
• 性能层面：加速效果高度依赖任务类型——代码生成从13.2提升至42.3 tok/s，约3.2倍；中文聊天问答从8.0到8.2 tok/s，几乎无变化；
• 机理层面：差异根源在于推测解码依赖草稿命中率，代码文本规律性强、命中率高，开放对话不确定性高、命中率低，而验证成本恒定存在。

由此提炼出本次评测最重要的方法论结论：性能数据必须绑定任务类型、参数配置与环境条件才有解读价值；“模型跑得快”从来不等于“你的任务跑得快”。 对开发者而言，与其追逐别人报出的峰值数字，不如用一套控制变量的对照评测，在自己的真实任务上验证收益边界——这才是评测数据转化为技术决策的正确路径。