SH

Soloharness

概念 · 辨析 · Agent

← 返回概念辨析

Concept Contrast Fable

快猜慢验的方法和负责快猜的小模型

推测解码是让一个小模型快速生成候选、再由大模型并行验证的加速策略。草稿模型就是负责快猜的那个小模型。两个概念经常在一张架构图里同时出现,但一个是方法,一个是方法里的组件——把方法等于组件,会在替换或升级草稿模型时丢失对整体策略的理解。

寓言

大厨让学徒切菜,自己只尝味——快了两倍,但学徒不能换

城东有家老字号酒楼,掌勺的张师傅一个人炒菜,慢是慢,但从没出过差错。生意越来越好,排队排到街角,张师傅发现自己的锅铲跟不上单子。他想了个办法:让徒弟李二先切配好每道菜的主料和辅料,自己只掌最后下锅的三分钟。单子多的时候,李二在案板上同时准备四五道菜的配料,张师傅炒完一道接一道,出菜速度快了一倍。

这办法好用了一年。直到后厨换了新菜单,加了三道需要用特殊刀工的菜——片鱼要斜刀薄切、拆鸡要划关节缝、雕花需要十几刀连切。李二的刀工只练过家常菜,新菜切出来的料大小不一,张师傅下锅时发现火候不对,有些厚了夹生,有些薄了焦底。

张师傅试了两个方向。第一个是让李二重新练刀工——李二每天切两百斤配料,练了两个月,新菜单的三道菜勉强合格,但此时后厨又换了菜单。张师傅意识到,换菜单的速度比练刀工的速度快。第二个方向是把李二换成王三——王三在另一家大酒楼干过五年配菜,刀工全面。换了之后,新菜单不再出问题。

食客以为换的是后厨的方法,其实换的是人。张师傅的方法没变——还是学徒切料、师傅验锅。但这个方法的效率跟切料的人直接挂钩。老主顾有次问张师傅怎么后厨快了这么多,张师傅说:方法叫试味先配,但真正干活的是那位配菜的。很多人把方法和工具混成一句话,拿去跟别的酒楼比,就没法比了。

王三干了半年,又出了新问题。热菜系列上来后,需要同时准备凉菜和汤底,王三一个人配不过来。张师傅又加了一个专门切凉菜的学徒。现在方法是试味先配的方法,但组件从一个人变成了两个人。如果当初把方法和一个学徒绑死,加人的时候整个架构描述就得重写。

后厨后来在培训手册里把两件事分开了:一页写流程——学徒提前备料、师傅并行验证的方法论;另一页写人员——当前负责备料的是谁、技能范围是什么、什么时候该换人。分开之后,换菜单只需要更新人员那页,换流程只需要更新方法那页。

张师傅退休前说了一句:只讨论方法不足以让后厨跑快,只讨论人不足以说清后厨在干什么。两个都拎清,才不怕菜单一年换三次。

推测解码

用小模型快速生成多个候选 token,再由大模型并行验证的推理加速方法。核心是投机执行和验证博弈,不绑定任何特定的小模型。

草稿模型

推测解码中负责快速生成候选序列的小模型。草稿模型可以替换、升级或组合——它只是推测解码策略中的一个组件,不是策略本身。

故事对应

  • 试味先配的方法:推测解码,小模型快猜、大模型验证的整体加速策略
  • 李二切菜:草稿模型,负责快速生成候选的小模型
  • 新菜单出错:草稿模型能力不足时推测解码的整体吞吐会下降
  • 把李二换成王三:草稿模型可以替换,推测解码的方法不变
  • 加一个凉菜学徒:推测解码的草稿模型可以组合多个组件
  • 培训手册分两页:方法和组件在工程文档里应分开描述

落到推理加速方案设计

设计推测解码方案时,先确认你的任务类型适合哪种草稿模型——是同一个模型的小版本、还是专门的轻量模型、还是基于 n-gram 的统计草稿。草稿模型的接受率直接影响加速比,替换草稿模型前先跑接受率基准测试。当供应商说用了推测解码但没有说明草稿模型的具体构成时,加速比的承诺缺乏约束力。