移动端投机解码加速方案——快厨帮工，主厨验收

可视化演示

展示Speculative Decoding投机解码在移动端的加速流程，以及与自回归解码在功耗和速度上的对比。

投机解码原理

聚福楼改了流程后，李师傅不再一道菜一道菜地做，而是让小王先备好四道菜的半成品，李师傅一次尝遍，合格的上桌，不合格的当场重做。客人等菜的时间从一刻钟缩短到五分钟。投机解码正是这套流程的翻版：用一个小草稿模型扮演帮厨小王，快速生成多个候选 token，再用主模型扮演李师傅，一次验证一整批。

所谓的“一次验证”，指的是主模型把草稿生成的 \(\gamma\) 个 token 连同当前真实 token 一起，做一次并行前向计算，一次性算出这 \(\gamma+1\) 个位置的概率分布。然后从左到右逐个对照：草稿 token 若与主模型的高概率 token 一致，就接受；遇到第一个不一致的位置，就改用主模型的采样结果，并且丢弃这之后的所有草稿 token。

衡量这套流程收益的核心指标是接受率 \(\alpha\)——帮厨的菜让主厨满意的比例。它直接决定了加速比：

\[

\displaystyle S_{\text{spec}} = \frac{1 - \alpha^{\gamma+1}}{(1-\alpha)(1+\gamma \cdot r)}

\]

1. 接受率 \(\alpha\)：草稿 token 被主模型认可的概率，就是帮厨的菜让主厨满意的比例。\(0 \le \alpha \le 1\)，它出现在等比数列求和的底数位置，对最终结果影响极大。

\[\displaystyle \alpha = \frac{\text{被接受的草稿 token 数}}{\text{草稿 token 总数}}\]

2. 草稿长度 \(\gamma\)：帮厨一次备几道菜，即草稿模型每轮预生成的候选 token 数。它决定了一次验证能“试吃”多少个位置。

\[\displaystyle \gamma \in \{1, 2, 3, \dots\}\]

3. 期望产出 \((1-\alpha^{\gamma+1})/(1-\alpha)\)：一次验证周期内期望被接受的 token 总数。这是等比数列 \(1 + \alpha + \alpha^2 + \cdots + \alpha^{\gamma}\) 的闭式解。\(\alpha=1\) 时产出 \(\gamma+1\) 个，\(\alpha=0\) 时只产出 1 个。

\[\displaystyle 1 + \alpha + \alpha^2 + \cdots + \alpha^{\gamma} = \frac{1-\alpha^{\gamma+1}}{1-\alpha}\]

4. 成本因子 \(1+\gamma \cdot r\)：一次迭代的总耗时比例：1 次主模型验证固定成本 + \(\gamma\) 次草稿生成成本，其中 \(r = c_{\text{draft}}/c_{\text{target}}\) 是草稿模型相对主模型的单 token 成本比。

\[\displaystyle r = \frac{c_{\text{draft}}}{c_{\text{target}}}\]

5. 整体加速比 \(S_{\text{spec}}\)：把期望产出除以总成本。它告诉我们：帮厨得力（\(\alpha\) 高）且成本低（\(r\) 小）时，翻台率才能大幅提升。

回到聚福楼，这套流程的精髓在于：主厨永远只做“验收”这一件事，绝不做重复劳动。投机解码也一样——主模型只算一次，就把草稿里能用的部分全部“免费”拿走。理解了这个原理，后面移动端的每一步优化，都是在回答同一个问题：怎么让帮厨更快、更省、更讨主厨喜欢。

移动端挑战

聚福楼的后厨有它的天花板：灶眼只有两个、备料台只有一平方米、燃气管道供气量也有限。李师傅手艺再好，在这样的小厨房里也施展不开。手机上部署大模型，同样面临着三重约束，这也是移动端投机解码与云端最大的不同。

第一重是算力受限。手机 SoC 的 AI 算力虽然逐年提升，但和云端 A100/H100 相比仍是杯水车薪。草稿模型和目标模型的每一次前向都要排队等待 NPU/GPU 调度，无法像云端那样随时抢到充足算力。第二重是内存容量，一个 7B 参数的模型 FP32 格式就要占 28GB，手机根本放不下，必须量化压缩后才有机会入驻。第三重是最隐蔽也最致命的——内存带宽瓶颈。自回归解码每生成一个 token，都要把模型权重从头到尾读一遍，权重越大，读取越慢：

\[

\displaystyle T_{\text{token}} \geq \frac{2 \times P_{\text{model}}}{B_{\text{mem}}}

\]

1. 模型参数量 \(P_{\text{model}}\)：模型权重占用的字节总量，是每生成一个 token 必须从内存搬进计算单元的“原材料”。参数越多，搬运越久。

\[\displaystyle P_{\text{model}} = \text{参数量} \times \text{每参数字节数}\]

2. 内存带宽 \(B_{\text{mem}}\)：手机 SoC 每秒能从内存读到数据的字节数，好比小厨房的传菜口宽度——传菜口越窄，上菜越慢。

\[\displaystyle B_{\text{mem}} = \frac{\text{单位时间读写的字节数}}{\text{秒}}\]

3. 系数 2：一次前向既要读权重、又要写激活值与 KV 缓存，相当于做了两趟搬运，所以分子是 \(2 \times P_{\text{model}}\)。

\[\displaystyle \text{搬运量} = P_{\text{model}}(\text{权重}) + P_{\text{model}}(\text{激活/KV})\]

4. 不等式含义：这个下限决定了无论软件怎么优化，单个 token 的生成延迟都不可能低于硬件带宽允许的物理极限。投机解码的意义，就是绕过这个极限——让便宜的小模型去“搬砖”，主模型只验证一次，从而摊薄权重读取的总开销。

在云端，带宽充裕时这个瓶颈不明显；但在手机上，带宽可能只有服务器的几十分之一。正因为如此，投机解码在移动端的价值反而被放大：帮厨小王搬砖的成本极低，主厨李师傅只需验收一次，整体搬运量大幅下降。移动端的每一分资源都弥足珍贵，这也引出了下一个问题：帮厨小王自己也得“轻装上岗”。

草稿模型部署

帮厨小王刚来时背着一大包家伙什，占了大半个备料台，李师傅直摇头：“厨房这么小，你先把行李精简了再说。”草稿模型部署到手机上面临同样的处境——它虽然是“小模型”，但如果以 FP32 全精度运行，依然会挤占宝贵的运行内存，甚至让主模型无地可容。因此草稿模型在移动端必须“轻装上岗”。

最常见的轻装手段是 INT4 量化。把模型权重从 32 位浮点数压到 4 位整数，内存占用直接缩到原来的八分之一，同时推理速度提升数倍。对于草稿模型这类“干粗活”的模型，INT4 量化带来的精度损失几乎不影响最终输出质量，因为最后的把关权始终在主模型手里——帮厨切歪的菜，主厨验收时会直接打回。量化后的内存账一目了然：

\[

\displaystyle M_{\text{int4}} = \frac{M_{\text{fp32}}}{8}

\]

1. 原始体积 \(M_{\text{fp32}}\)：FP32 格式下，每个参数占 4 字节，参数量乘以 4 就是模型文件体积。1 亿参数的模型约 400MB。

\[\displaystyle M_{\text{fp32}} = N_{\text{param}} \times 4\ \text{bytes}\]

2. 量化体积 \(M_{\text{int4}}\)：INT4 格式下，每个参数只占 0.5 字节，也就是半字节。1 亿参数的模型约 50MB。

\[\displaystyle M_{\text{int4}} = N_{\text{param}} \times 0.5\ \text{bytes}\]

3. 除以 8 的来源：4 字节 ÷ 0.5 字节 = 8，所以同样的参数量，INT4 体积是 FP32 的八分之一。

\[\displaystyle \frac{M_{\text{fp32}}}{M_{\text{int4}}} = \frac{4}{0.5} = 8\]

除了量化，KV 缓存复用也是草稿模型部署的关键技巧。草稿模型和目标模型共享同一段对话上下文，它们的 KV 缓存可以复用——帮厨切好的配菜，主厨不用重新切一遍。加载预热优化则让草稿模型常驻内存，避免每次对话重新加载的冷启动延迟。这三板斧下来，帮厨小王终于能在小厨房里自如转身，与主厨李师傅配合得严丝合缝。

部署搞定之后，还有一个隐形的账单要算清楚：小厨房的燃气是有限的。帮厨虽然手脚麻利，但如果他消耗的燃气比省下的还多，这生意就亏了——这就是功耗与加速的平衡问题。

功耗加速平衡

小厨房的燃气表转得比大饭店快得多，因为管道细、储备少。李师傅现在每做一道菜都要看一眼燃气表：小王备菜确实省时间，但如果备菜本身把燃气烧掉大半，那还不如李师傅自己慢慢做。移动端投机解码的功耗账，正是这样一笔精打细算的燃气账。

先看能耗画像。主模型生成一个 token 的平均能耗记作 \(e_{\text{target}}\)，草稿模型生成一个 token 的能耗记作 \(e_{\text{draft}}\)。投机解码每轮让草稿模型生成 \(\gamma\) 个 token，主模型做一次并行验证。若这轮产出的 token 接近满额（即接受率高），相比直出模式省下的能耗为：

\[

\displaystyle E_{\text{saved}} = \gamma \times (e_{\text{target}} - e_{\text{draft}})

\]

1. 主模型能耗 \(e_{\text{target}}\)：主模型每生成一个 token 消耗的电量，相当于主厨做一道菜的燃气费，通常与模型参数量成正比。

\[\displaystyle e_{\text{target}} \propto P_{\text{target}}\]

2. 草稿能耗 \(e_{\text{draft}}\)：草稿模型每生成一个 token 的耗电量，是帮厨做一道半成品的燃气费。草稿模型小得多，所以 \(e_{\text{draft}} \ll e_{\text{target}}\)。

\[\displaystyle e_{\text{draft}} \propto P_{\text{draft}}\]

3. 差值 \((e_{\text{target}} - e_{\text{draft}})\)：每节省一次主模型调用所省下的能耗。差值越大，投机解码的节能效果越明显。

\[\displaystyle e_{\text{target}} - e_{\text{draft}} > 0 \iff \text{投机解码单位产出更省电}\]

4. 乘以 \(\gamma\)：每轮草稿生成了 \(\gamma\) 个候选 token，意味着最多有 \(\gamma\) 次本应由主模型完成的生成被草稿替代，所以总节省是单次差值的 \(\gamma\) 倍。

\[\displaystyle E_{\text{saved}} = \gamma \cdot (e_{\text{target}} - e_{\text{draft}})\]

实际工程中，端侧方案还会引入动态阈值调节：当检测到设备温度过高或电量告急时，自动调低草稿长度 \(\gamma\) 甚至完全关闭投机解码，让系统回到直出模式，避免功耗叠加引发热降频——手机一旦降频，延迟反而会恶化，加速就变成了减速。更进一步，端云协同策略会在本地算力紧张时把任务转交云端，形成“本地投机加速优先、云端兜底”的动态决策。

这笔燃气账算清楚之后，聚福楼开始记录每天的翻台率、燃气费和顾客满意度。数据是最诚实的——投机解码在移动端到底值不值，要看实测效果。

实测效果分析

李师傅是个较真的人，新流程跑了半个月，他翻出账本仔细比对：翻台率确实上去了，但燃气费降了吗？小王占的备料台会不会挤占了别的菜品准备空间？这些疑问，对应到工程上就是三个实测指标：端到端延迟、内存增量、功耗变化。

端到端延迟是最直观的成绩单。在典型移动端配置（如骁龙 8 系列 + 7B 量化主模型 + 0.3B~0.5B 草稿模型）下，投机解码能让首 token 之后的平均生成速度提升 1.5~2.5 倍。端到端加速比的定义是直出模式总延迟除以投机模式总延迟：

\[

\displaystyle S_{\text{net}} = \frac{T_{\text{direct}}}{T_{\text{draft}} + T_{\text{verify}}}

\]

1. 直出延迟 \(T_{\text{direct}}\)：不使用投机解码，主模型从头到尾逐个生成 token 的总耗时，这是所有对比的基准线。

\[\displaystyle T_{\text{direct}} = N \times T_{\text{token}}\]

2. 草稿延迟 \(T_{\text{draft}}\)：投机模式下，草稿模型为每个位置预生成候选 token 所花的时间，通常占用总延迟的 20%~30%。

\[\displaystyle T_{\text{draft}} = \gamma \times T_{\text{draft\_token}}\]

3. 验证延迟 \(T_{\text{verify}}\)：主模型做一次批量前向验证的时间。得益于并行计算，一次验证 \(\gamma+1\) 个位置与生成一个 token 的耗时几乎相同。

\[\displaystyle T_{\text{verify}} \approx T_{\text{target\_token}}\]

4. 比值 \(S_{\text{net}}\)：工程上真正感知到的加速比。它总是小于理论加速比，因为还包含调度开销、量化误差、采样分支带来的额外成本。

内存占用的实测结论是：草稿模型经 INT4 量化后通常只增加 100~200MB 内存，对现代手机（8GB+）完全可以接受；功耗方面，若接受率高于 0.5，单位 token 能耗较直出模式下降 20%~40%；若接受率过低，功耗可能不降反升，此时应触发动态阈值逻辑关闭投机解码。账本不会说谎——实测数据告诉我们，投机解码是移动端少有的“又提速又省电”的方案，但前提是配置得当。

应用场景

聚福楼的新流程并非所有菜都适用。李师傅发现，像响油鳝糊这种需要急火快炒的菜，小王备好料后他两三秒就能出锅，收益最大；而像佛跳墙这种一步都不能错的功夫菜，小王根本插不上手。投机解码在移动端的适用场景也有同样的边界——它最适合那些延迟敏感、重复度高、且草稿模型“靠谱”的任务。

第一个典型场景是端侧智能助手。用户对着手机说“帮我定个明早七点的闹钟”，这类指令的上下文短、句式相对固定，草稿模型的接受率高，投机解码能把响应延迟从 900ms 压到 400ms 以内，让对话真正“无感”。第二个场景是离线实时翻译。旅行途中没有网络，翻译必须本地完成，投机解码让 3B 翻译模型的中英互译延迟从 1.2s 降到 0.6s，达到可用的交互水平。第三个场景是隐私敏感推理，比如医疗问答、金融分析，数据不出设备是刚需，本地模型的响应速度决定产品能不能用。

工程上如何判断一个任务该不该启用投机解码？设定一个简单的决策条件：

\[

\displaystyle \Delta L = T_{\text{direct}} - T_{\text{spec}} > L_{\text{threshold}}

\]

1. 直出延迟 \(T_{\text{direct}}\)：该任务在主模型直出模式下的端到端延迟，是“不启用投机解码”的对照基线。

\[\displaystyle T_{\text{direct}} = \text{直出模式总耗时}\]

2. 投机延迟 \(T_{\text{spec}}\)：同一任务启用投机解码后的端到端延迟，取决于草稿模型的接受率和该任务的序列长度。

\[\displaystyle T_{\text{spec}} = T_{\text{draft}} + T_{\text{verify}}\]

3. 延迟收益 \(\Delta L\)：两者之差，即开启投机解码实实在在为用户省下的等待时间。差异越大，方案越值得部署。

\[\displaystyle \Delta L = T_{\text{direct}} - T_{\text{spec}}\]

4. 阈值 \(L_{\text{threshold}}\)：用户能感知到“变快了”的最小延迟差，一般取 150~300ms。低于这个阈值，用户的体感几乎没有变化，却要付出额外的内存和功耗，得不偿失。

\[\displaystyle L_{\text{threshold}} \in [150\text{ms}, 300\text{ms}]\]

回顾聚福楼的经营哲学：帮厨不是越多越好，而是要在对的菜、对的时段、对的火候下出现。移动端投机解码的落地，同样需要工程师在“收益与成本”之间找到那个甜蜜点。选对场景、配好草稿模型、算清功耗账，这套方案就能成为端侧大模型落地的利器。

AI 应用场景

Python 演示

import random  def build_dist(vocab_size, seed):    random.seed(seed)    raw = [random.random() for _ in range(vocab_size)]    total = sum(raw)    return [p / total for p in raw]  def sample(dist):    r = random.random()    acc = 0.0    for i, p in enumerate(dist):        acc += p        if r <= acc:            return i    return len(dist) - 1  def verify_accept(tok, target_dist, draft_dist):    pt = target_dist[tok]    pd = draft_dist[tok]    if pt >= pd:        return True    return random.random() < pt / pd  def run_speculative(target_dist, draft_dist, gamma=3, rounds=500):    total_tokens = 0    verify_calls = 0    for _ in range(rounds):        drafts = [sample(draft_dist) for _ in range(gamma)]        for tok in drafts:            total_tokens += 1            verify_calls += 1            if not verify_accept(tok, target_dist, draft_dist):                break    return total_tokens / verify_calls  def main():    vocab_size = 32    target = build_dist(vocab_size, seed=1)    draft = build_dist(vocab_size, seed=2)    print("=== 移动端投机解码模拟 ===")    for gamma in (1, 2, 3, 4, 6):        sp = run_speculative(target, draft, gamma=gamma, rounds=500)        print(f"gamma={gamma}: 加速比 {sp:.2f}x")  if __name__ == "__main__":    main()

1. raw = [random.random() for _ in range(vocab_size)]为每个词生成一个随机权重，模拟模型的词表概率分布。
2. def sample(dist)核心采样函数：按概率分布随机抽取一个 token 编号，相当于帮厨从自己的“手艺库”里挑一道菜。
3. verify_accept(tok, target_dist, draft_dist)判断草稿 token 是否被主模型接受，是投机解码的心脏。
4. if pt >= pd: return True当主模型给该 token 的概率不低于草稿模型时，直接放行。
5. return random.random() < pt / pd否则以概率比接受，这保证了最终输出分布与主模型单独解码完全一致，是对主厨口味的忠实模拟。
6. total_tokens / verify_calls用“产出 token 数 ÷ 验证次数”度量加速比，对应公式里的期望产出除以总成本。
7. for gamma in (1, 2, 3, 4, 6)遍历不同草稿长度，观察 γ 从 1 增大到 6 时加速比先升后降的规律，说明草稿长度不是越大越好。

常见误区

面试题