用户嫌回答慢，团队便准备给大模型加一个草稿模型。问题是，等待可能来自检索、长输入或排队，而草稿也需要时间。推测解码应作为有条件的服务优化来验收。本文讨论独立草稿模型这一易于解释的路径；其他推测方法的资源结构不同，不能照搬同一成本估算。
能力已经可用，投入依据仍要回到实际负载
Leviathan 等在 2023 年提出通过候选生成与验证减少目标模型串行解码步骤的方法。[1] 本文不把这项已有研究包装成新发布。值得企业决策者关注的是：推测解码已进入可配置的推理框架，选型因此需要比较完整服务，而不能只比较模型本身。
本次查阅的 vLLM v0.22.0 文档把中低请求速率、受内存带宽限制的负载作为降低 token 间延迟的应用场景，也强调实际收益取决于模型、硬件、流量和采样设置。[2] 这不是“高并发必然无效”的定律，更不是任何兼容模型都能获得固定倍数提速的保证。
企业大模型服务容量验收讨论了任务质量、期限和峰值边界。本篇进一步追问：在这些条件固定以后，多付出的草稿成本能否换来足够多的有效输出？这是评估推测解码的核心增量，不应通过缩短输出、改变任务难度来制造优势。
如果使用的是托管 API，客户通常不能自行控制底层草稿与验证配置。此时可比较服务交付指标，但不应把供应商未公开的实现当成已启用能力。以下实施建议主要面向能够配置推理服务、采集运行指标的团队。
目标模型验证候选，不等于人工意义上的审稿
在经典路径中，较快的草稿模型提出一段候选，目标模型计算这些位置的概率，再按规定的接受与修正过程推进输出。出现拒绝后，不能把后面的候选直接当作已经批准的正文。正确采样算法的目标是保持目标模型的输出分布，而非让小模型自由替代大模型。[1]
这里的验证是概率计算，不是事实核查。目标模型原本会犯的业务错误不会因此自动消失；草稿接受率也不是答案准确率。若系统需要核对合同依据或计算金额，原有业务校验仍须保留，不能用“目标模型已经验证”省略。
保持分布与每次输出逐字相同不是同一个承诺。随机采样、数值精度和批处理方式都需区分。vLLM 文档明确讨论了浮点与批大小相关变化，以及 logprobs 稳定性的限制。[2] 验收应固定版本和解码配置，另做业务回归，不把一次文本差异直接解释为算法失效。
还应区分推测解码、量化和模型路由。量化改变数值表示，路由把任务交给另一模型，推测解码则改变目标模型输出的计算过程。若同时更换目标权重、量化配置和草稿策略，就无法把收益或退化归因于其中一个开关。
先测每轮推进的时间价值，再看接受率
建议记录三项量：每轮提出多少候选、最终提交多少新 token，以及该轮草稿、验证和调度的完整耗时。按一段稳定观测窗口累计时间除以累计提交 token，可以得到该窗口的解码时间成本。该比值是诊断工具，不替代逐请求尾延迟，也不等于整机多请求吞吐。
以下为构造算例，没有运行模型基准。假设普通解码每生成一个 token 需 40 毫秒；方案 A 每轮共耗时 60 毫秒，平均推进 3 个新 token，则为每 token 20 毫秒。方案 B 使用更重的草稿，每轮 100 毫秒，平均推进 4 个，则为 25 毫秒。B 推进更多，却比 A 慢。
若某类任务下 A 平均只推进 1.2 个 token，其成本变成 50 毫秒，反而慢于普通解码。这里的推进量包含该轮最终提交的输出，不能简单用“候选数量乘接受率”代替；还要核对实现中修正或额外 token 的统计口径。
Yan 等的研究发现草稿延迟是重要因素，语言建模能力并不强相关于推测性能；其相关实验包括批大小为一、贪心解码和四张 A100 的设置。[3] 据此可以提出候选筛选建议：同时测速度与接受行为，不只挑榜单更强的草稿。该研究不能证明企业不同硬件和并发下也有同样收益。
局部加速要经过端到端与峰值两道检验
构造一个十秒任务：七秒用于检索、输入处理及其他固定环节，三秒用于解码。即使解码时间减半，总时长也只是降到八点五秒，整体加速约 1.18 倍。这个分解仅在其他环节不变时成立；若新增草稿引起排队或内存竞争，整体收益还可能更低。
因此先用实际追踪确认解码占比，再选择试点任务。长输出且等待主要在生成阶段的任务值得优先测试；长输入、短回答或慢工具占主导的任务，应先处理对应瓶颈。不能仅按“模型很大”或“用户很多”判断适用性。
同一台设备承载草稿模型时，要预算其权重、状态和工作空间，并观察目标服务可容纳的并发是否下降。低负载交互更顺畅，与高峰能完成更多任务可以同时不成立。增加一张设备承担草稿时，也要把那张设备计入比较，而不是只报目标模型侧速度。
测试应至少覆盖平峰、目标峰值和短时突发，固定到达轨迹、输入输出长度分布及业务质量要求。报告首个有效内容时间、完整任务时间、超时与拒绝比例、内存峰值和按期完成量。仅从成功返回的请求计算速度，会掩盖被丢弃或未完成的任务。
把试点设计成可解释的三组对照
第一组是现有目标模型服务；第二组只开启一种推测策略；第三组是在相同总资源预算下的可行替代方案，例如改善批处理配置或保留更多目标服务容量。替代方案需真实可部署，不能将一个经过充分调优的方案与刻意保留低效设置的基线比较。
冻结目标与草稿版本、分词器兼容条件、采样设置、上下文限制、并行方式、推理引擎及硬件环境。按中文业务说明、代码、结构化字段和长文生成等真实任务分组，同时分开冷启动与稳定运行。分组不是预设哪类一定更容易接受，而是寻找不能被平均值遮蔽的退化。
业务回归先规定关键错误与合格条件，再看性能。随机输出任务应保留重复运行和有明确口径的质量评估；贪心配置可以检查输出一致性并记录数值差异。功能兼容还要覆盖流式返回、停止条件、工具调用及请求取消，避免单纯生成基准遗漏应用行为。
上线先限定到已证明获益的任务范围，保留可回到普通解码的配置。回退条件可包括关键业务退化、尾延迟超标、持续内存压力或特定分组净变慢，具体阈值由服务目标确定。切换若需要重启或释放模型，要把中断与容量恢复时间纳入演练，不能把开关存在当作无缝回退。
采购决定应写成条件，而非一个提速倍数
建议将结论分成三类：在明确任务与负载范围内采用；仅在特定低负载窗口或任务队列中采用；暂不采用并优先修复其他瓶颈。这是本文提出的决策框架，不是外部论文的通用结论。没有代表性流量时，结论应保留为试点假设。
成本按相同质量与期限计算，纳入设备时长、额外显存造成的容量损失、适配调优、版本升级回归和回退维护。更低的单请求延迟若没有减少资源或产生可确认的业务价值，不能自动报告为费用下降。购买托管服务时也应以实际账单和交付指标核算。
交付材料应包含负载范围、基线与候选配置、每轮推进和耗时分解、分组质量结果、峰值表现及回退记录。它让下一次目标模型升级能够重测，也能解释为何某个任务值得启用而另一个不值得。
本文资料核查于 2026 年 10 月 26 日，引用 2023 年算法研究、2025 年修订研究及明确版本的框架文档，不声称发现近期行业普遍变化。构造算例仅解释决策逻辑，不能替代目标环境压测，也不代表壹典客户项目或产品性能。