顾客等的那两秒，模型在猜什么
先分清顾客在等哪一段时间
顾客站在收银台前问「这个多少钱」，从开口到听见回答，中间有两段可以分开计的时延：
- 首字时间：从话音结束到喇叭里出第一个字。
- 整句时间：从话音结束到这句话说完。
顾客感知最强的是第一段。第一段里塞着语音识别、意图理解、检索或生成、语音合成四步，任何一步慢，整句都会被拖住。
不少方案报的「响应 300 毫秒」，是把其中某一项单独拎出来测的。要判断门店里到底快不快，得把首字时间和整句时间分别测出来，并且按现场同时有几路在用去测。
「答得快」的一种做法：先猜一批，再一起验
大模型生成文字是一个词一个词往外蹦的。每蹦一个词，都要把整个模型的权重从内存读一遍——真正忙的是搬运，算术单元大半时间在等数据。
投机解码（speculative decoding）改的是这个流程：先让一个小得多的草稿模型连着猜四个词，再让大模型对这四个位置一次性并行校验。猜对的直接采用，从第一个猜错的地方由大模型给出正确答案，然后进入下一轮。
它的好处是不用改大模型的权重，输出分布在校验规则严格时也不变。代价是要多放一个模型，并且多一道校验。
收益卡在两个地方
草稿得像。 草稿猜的和目标模型想的一致，接受率才高。草稿太小、训练语料和门店业务差得远、对话上下文风格突变，接受率都会掉。
草稿得快。 如果草稿每猜一个词花掉大模型三分之一的钱，省下的轮数还不够付草稿的账。
arXiv 上有一篇工作（2610.34103，T2D）把草稿的来源当成一个优化问题来做：不再单独训练一个小模型，而是用延迟感知的结构化剪枝加知识蒸馏，直接从目标模型上剪出一个草稿，优化目标里同时放实测延迟和「猜得像不像」。作者报告最多剪掉目标模型 92% 的结构仍然可用。
这篇论文真正有用的一句话在结论之外：草稿的架构和对齐程度是一对矛盾，得一起调。这话放到门店采购上同样成立——草稿和目标模型是一对，不能拆开换。
门店最容易踩的一个坑：把服务器的倍率搬到店里
投机解码在服务器上常见 2 到 6 倍的加速报告。这个数字成立的前提是批量足够大、算力已经被打满，草稿的开销能被摊薄。
门店的负载不是这样。多数时候一两个人在用，批量等于 1，算力本来就闲着。这时候再加一个草稿模型，多出来的调度、多一份内存占用，很可能比省下的那几步更贵。
arXiv:2610.31479 在 Apple 芯片上重测了四类优化，其中投机解码这一类在单请求负载下全部是降速的，而同类方法在服务器 GPU 上报的是 2 到 6 倍。同一个技术、同一个模型，换硬件换负载，结论就翻了。
所以门店判断这件事，不该问「用了什么加速技术」，而该问「在我这个负载下，绝对时延是多少」。
验收动作
- 首字与整句分开测。 用一个秒表和一个脚本都行，关键是把两段分开记，并且记录测试时的并发路数。
- 按真实并发压。 一路、两路、四路各测一遍。如果加速效果只在单路时存在，多路时消失，那就说明省下的算力被并发吃掉了。
- 看 P95，不看平均。 平均时延好看、偶发卡两秒，顾客记住的是那两秒。
- 改采样参数要重测。 温度、top-p、重复惩罚变化会改变草稿的接受率。有的方案在贪心解码下几乎无损，换成随机采样后要么变慢、要么文本风格漂移。
- 换模型、换草稿都要重跑。 目标模型升级、剪枝比例调整、提示词模板改版，这三件事任何一件发生，接受率都会变。
- 拔网线跑一遍。 本地推理如果不能在断网时工作，前面所有时延数字都不算数。
该问供应商的四个问题
- 这套方案里的草稿模型是从哪来的？独立训练的还是从主模型剪的？换主模型时它跟不跟着换？
- 报的加速倍率是在几路并发、什么采样设置下测的？单路时绝对时延是多少？
- 草稿模型额外占多少内存？在 4 GB、8 GB 的设备上还放得下吗？
- 如果关掉投机解码，时延会退化多少？退化太多说明这套方案把稳定性押在了一个附加组件上。
一句话
投机解码是拿闲置算力换更少的串行步数，收益依赖负载。门店要的不是「用了什么技术」，而是「我这个时段、这个并发下，顾客等多久」——把首字时间和整句时间分开测，比任何技术名词都可靠。