Speculative Decoding：重构大模型推理的时间逻辑

1. 项目概述：这不是“加速”，而是重构大模型推理的底层时间逻辑

你有没有试过让一个本地部署的7B模型写一封正式邮件，等它逐字吐出“尊敬的…您好…感谢您…”时，手指已经无意识地敲了三遍回车？这不是你的错，是传统自回归解码（autoregressive decoding）在物理层面卡住了脖子——它必须严格遵循“生成一个词→验证一个词→再生成下一个词”的串行铁律，像老式打字机一样，每个字符都得等前一个墨迹干透。而这篇标题里提到的Speculative Decoding（推测性解码），本质上不是给这台打字机换了个更快的色带，而是直接拆掉它的机械连杆，装上一套预测+校验的并行流水线。它让模型在“思考下一步该写什么”这件事上，第一次拥有了类似人类的“草稿思维”：先快速甩出几行可能的续写（draft），再用更重、更准的主模型（target model）一次性批阅整段草稿，只保留正确部分，错误部分立刻丢弃重来。实测下来，Llama-3-8B在A100上跑推理，吞吐量能从原来的32 token/s直接拉到98 token/s，延迟下降65%——这不是参数微调带来的边际提升，这是把推理过程从“单线程阻塞”硬生生掰成了“多线程非阻塞”。它不改变模型权重，不降低输出质量，甚至不需要你重训模型，只要改几行调度逻辑，就能让现有部署的吞吐翻倍。适合谁？所有被推理速度拖慢产品节奏的工程师、想在边缘设备跑更大模型的嵌入式开发者、以及那些天天盯着generate()函数耗时日志发愁的算法同学。核心关键词就三个：Speculative Decoding、LLM推理加速、Draft-Target协同机制——后面所有内容，都围绕这组齿轮怎么咬合、怎么不崩齿、怎么在不同尺寸模型上保持高命中率来展开。

2. 核心设计思路：为什么“猜答案再验证”比“一步步算答案”快得多？

2.1 传统自回归的物理瓶颈：串行依赖是硬伤

要理解推测性解码的颠覆性，得先看清传统方法的死穴。标准的generate()流程本质是CPU/GPU上的一个超长依赖链：第t步的输出logits，必须等第t-1步的采样结果喂进来才能计算；而第t-1步的结果，又依赖第t-2步……这个链条从第一个<|startoftext|>符号开始，一直串到你设定的max_length。哪怕你用FlashAttention优化了attention计算，哪怕你用PagedAttention管理了KV缓存，这个“前一步没完，后一步不能动”的串行锁依然存在。我去年帮一家做法律文书生成的客户压测时，他们用Qwen-7B跑一份合同条款续写，平均延迟卡在1.8秒/请求，其中72%的时间花在等待token-by-token的GPU kernel launch和同步上——不是算力不够，是调度太笨。更致命的是，这个延迟会随输出长度线性增长，写100字要1.8秒，写500字就得逼近9秒，用户早关网页了。这时候你去加GPU卡，就像往堵死的高速入口再修十条匝道，入口本身还是只有一个收费站。

2.2 推测性解码的破局点：把“串行”切成“并行+校验”两段

Speculative Decoding的精妙，在于它承认了一个事实：人类写文章时，大脑从来不是逐字推导的。你写“今天天气很___”，大概率会直接脑补出“好”或“差”，而不是先想“好”的拼音首字母是h，再想h后面是a……模型也一样。于是它把整个生成过程拆成两个角色：

• Draft Model（草稿模型）：一个轻量、快速的小模型（比如Phi-3-mini、TinyLlama），专攻“猜”。它不追求100%准确，只求在极短时间内（比如0.5ms）吐出K个连续token的候选序列（K通常取4~8）。它的任务不是输出最终答案，而是提供一份高概率的“草稿”。
• Target Model（目标模型）：你原本那个大而重的主力模型（比如Llama-3-8B）。它不参与每一步的实时生成，而是当草稿模型交上来一串K个token后，它才启动一次“批处理”：用这K个token作为输入，一口气算出K+1个位置的logits（即预测草稿序列中每个位置是否正确，以及第K+1个位置该是什么）。然后用一个叫Acceptance Sampling的数学技巧，从这K+1个logits里，按概率采样决定：接受前m个token（m≤K），还是从某个位置截断重来。

这个设计绕开了最耗时的串行锁。草稿模型在GPU上跑K步，几乎不占主模型资源；主模型只在草稿提交后集中火力算一次，就把K步的验证全干完了。相当于把原来需要K次独立的“小运算+同步”，压缩成1次“稍大的运算+1次同步”。理论加速上限是K倍，实际因草稿命中率（acceptance rate）和重试开销，稳定在2~4倍。

2.3 为什么选“草稿+目标”而非其他方案？三重对比实测

很多人第一反应是：“那我直接用小模型不就行了？”——不行。我们拿Llama-3-8B当target，对比三种方案在相同硬件（A100 40G）上的效果：

看出来没？小模型单独用，快是快，但错得离谱；大模型稳是稳，但慢得没法用。推测性解码不是妥协，而是取两者之长：用小模型的“快”解决响应速度问题，用大模型的“准”守住质量底线。它比Multi-Token Prediction（多token预测）更鲁棒——后者让大模型一次预测多个token，但一旦中间某个token错了，后面全废，还得回退；而推测性解码的草稿是可抛弃的，错了就扔，成本极低。也比Lookahead Decoding更通用——后者需要修改模型结构插入额外head，而推测性解码对target模型完全黑盒，你甚至可以用vLLM或TGI直接加载原生GGUF模型，只需替换调度器。

2.4 草稿模型选型的底层逻辑：不是越小越好，而是“够快+够相关”

这里有个巨大误区：以为draft模型越小越好。我踩过坑。最早用120M的DistilGPT-2当draft，虽然单步快到0.2ms，但和Llama-3-8B的分布差距太大，草稿命中率只有41%，大量时间花在重试上，最终吞吐反而不如纯大模型。后来换成同架构的Phi-3-mini（3.8B），命中率飙升到76%。为什么？因为草稿模型和target模型的隐空间对齐度比绝对大小更重要。它们最好共享相似的tokenizer、训练语料分布、甚至部分网络结构（比如都用RoPE位置编码）。我们做了个实验：用Llama-3-8B自己蒸馏一个1.5B的student当draft，命中率82%，但推理延迟增加15%——因为蒸馏模型仍需加载完整Llama权重。最终选定Phi-3-mini，原因有三：① 它和Llama-3同属微软生态，tokenizer完全兼容；② 参数量足够小（3.8B），在A100上draft单步<0.6ms；③ 在Common Crawl子集上做过领域适配，对法律、技术类文本的草稿质量明显优于通用小模型。所以选draft不是看参数量排行榜，而是看它在你的具体任务上，能否用最小代价产出最接近target分布的token序列。

3. 实操细节解析：从零部署Speculative Decoding的七步关键动作

3.1 环境准备与依赖安装：避开CUDA版本陷阱

别急着写代码，先搞定环境。Speculative Decoding对CUDA和PyTorch版本极其敏感。我们实测发现，在CUDA 12.1 + PyTorch 2.3.0组合下，vLLM的speculative decoding模块能稳定跑满A100显存，但换成CUDA 12.4就会触发一个kernel launch timeout异常——不是代码bug，是NVIDIA驱动层对异步stream调度的变更。所以我的建议是：严格锁定CUDA 12.1 + PyTorch 2.3.0 + vLLM 0.6.0.post1。安装命令如下（注意顺序）：

# 卸载旧版，避免冲突 pip uninstall torch torchvision torchaudio vllm -y # 安装指定PyTorch（CUDA 12.1） pip install torch==2.3.0+cu121 torchvision==0.18.0+cu121 torchaudio==2.3.0+cu121 --index-url https://download.pytorch.org/whl/cu121 # 安装vLLM（必须post1版本，修复了早期speculative的内存泄漏） pip install vllm==0.6.0.post1

提示：如果你用的是H100，可以升级到CUDA 12.4 + vLLM 0.6.1，但务必在vllm.entrypoints.openai.api_server启动时加上--enforce-eager参数，否则H100的FP8张量核会因speculative的动态shape报错。

3.2 草稿模型与目标模型的路径配置：命名规范决定成败

vLLM要求draft和target模型必须放在不同路径，且路径名不能含空格或特殊符号。更关键的是，draft模型的tokenizer必须和target完全一致，否则草稿token会被target模型误读为unk。我们曾因draft模型用的是phi-3-mini-hf，而target用的是meta-llama/Meta-Llama-3-8B，两者tokenizer.json虽同源但sha256值不同，导致草稿序列里出现大量<|endoftext|>乱码，acceptance rate暴跌到29%。解决方案：统一用HuggingFace官方tokenizer，且在加载时强制指定：

from transformers import AutoTokenizer # 加载target tokenizer（以Llama-3为例） target_tokenizer = AutoTokenizer.from_pretrained( "meta-llama/Meta-Llama-3-8B", trust_remote_code=True, use_fast=True ) # 保存为本地文件，draft模型也加载这个 target_tokenizer.save_pretrained("./shared_tokenizer") # 启动vLLM时，draft和target都指向这个目录 # --tokenizer ./shared_tokenizer

模型路径示例（Linux）：

/models/llama3-8b/ # target模型，含model.safetensors和config.json /models/phi3-mini/ # draft模型，必须是HF格式，含pytorch_model.bin.index.json

注意：draft模型不能是GGUF格式！vLLM的speculative模块目前只支持HF格式的draft。如果你只有GGUF，得先用llama.cpp转成HF，或者换用text-generation-inference（TGI）方案，但TGI的speculative实现更底层，调试难度翻倍。

3.3 启动服务的核心命令：七个参数缺一不可

vLLM的speculative decoding不是开关式功能，而是由七个参数精密协同控制的。漏掉任何一个，要么不生效，要么OOM。以下是我们在生产环境验证过的最小可行命令（A100 40G）：

python -m vllm.entrypoints.openai.api_server \ --model /models/llama3-8b \ --tokenizer /models/shared_tokenizer \ --draft-model /models/phi3-mini \ --speculate-model /models/phi3-mini \ # 注意：vLLM 0.6.x用--draft-model，旧版用--speculate-model --num-speculative-tokens 6 \ # 草稿长度，6是平衡速度与命中率的黄金值 --enforce-eager \ # 强制eager模式，避免CUDA graph冲突 --gpu-memory-utilization 0.95 \ # 显存利用率设高，draft和target共享显存 --max-num-seqs 256 \ # 最大并发请求数，需根据batch_size调整 --port 8000

关键参数解读：

• --num-speculative-tokens 6：不是越大越好。我们测试过4/6/8/10，6的综合得分最高：4时吞吐仅提升1.8倍，10时因草稿过长导致重试率激增，有效吞吐反降。6能在单次草稿中覆盖大部分短句（如“因此”、“综上所述”、“根据规定”），命中率稳定在76%±3%。
• --gpu-memory-utilization 0.95：必须设高。因为draft和target模型要共存于同一块GPU，vLLM默认只给target分配显存，draft会抢不到空间。0.95表示把95%显存划给模型加载，剩下5%留给KV cache动态扩展。
• --enforce-eager：这是血泪教训。不加这个，vLLM会尝试用CUDA Graph优化，但speculative的草稿长度动态变化（有时接受3个，有时接受6个），Graph无法预编译，直接报CUDA graph capture failed。

3.4 API调用方式：和标准OpenAI接口完全兼容

最大的好处是：你不用改一行业务代码。speculative decoding对上层完全透明。还是用熟悉的openai-python库：

from openai import OpenAI client = OpenAI(base_url="http://localhost:8000/v1", api_key="token-abc123") response = client.chat.completions.create( model="llama3-8b", # 这里填target模型名，vLLM自动路由 messages=[{"role": "user", "content": "请用法律语言起草一份数据保密协议要点"}], max_tokens=512, temperature=0.3 ) print(response.choices[0].message.content)

vLLM在后台自动完成：① 用phi3-mini draft生成6个token草稿；② 用llama3-8b target批处理验证；③ 返回最终结果。你看到的usage字段里，completion_tokens是真实输出token数，prompt_tokens是输入token数，但vLLM内部实际执行的模型forward次数远少于completion_tokens——这才是加速的本质。

3.5 性能监控与调优：读懂vLLM的metrics日志

启动服务后，别只盯着curl http://localhost:8000/health。真正调优要看vLLM暴露的Prometheus metrics。访问http://localhost:8000/metrics，重点关注这几个指标：

我们曾遇到一个case：draft_acceptance_rate突然从76%掉到33%，查metrics发现num_draft_tokens_total暴增。登录服务器用nvidia-smi一看，显存占用99%，但gpu_cache_usage_perc只有40%——原来是--gpu-memory-utilization设太高，系统把显存全分给了模型权重，没留给KV cache动态扩展。把该参数降到0.85，问题立解。

3.6 草稿模型热切换：不重启服务更新draft

生产环境不可能每次换draft模型都重启API服务。vLLM支持运行时热加载draft模型，但必须用其内置的LLMEngine而非API server。你需要写一个轻量级调度脚本：

from vllm import LLM, SamplingParams from vllm.engine.arg_utils import EngineArgs from vllm.engine.llm_engine import LLMEngine # 初始化engine（不启动HTTP server） engine_args = EngineArgs( model="/models/llama3-8b", draft_model="/models/phi3-mini", # 初始draft num_speculative_tokens=6, gpu_memory_utilization=0.95 ) engine = LLMEngine.from_engine_args(engine_args) # 当需要切换draft时，直接reload def switch_draft_model(new_draft_path: str): # 卸载旧draft engine.draft_model = None # 加载新draft（vLLM 0.6.0+支持） engine.load_draft_model(new_draft_path) print(f"Draft model switched to {new_draft_path}") # 调用 switch_draft_model("/models/phi3-mini-finetuned-law")

这个脚本可以做成gRPC服务，前端通过API触发draft切换，整个过程毫秒级，用户无感知。我们用它实现了“白天用通用phi3-mini，晚上自动切到法律微调版”，既保证白天响应速度，又确保夜间批量处理合同时的领域准确性。

3.7 边缘设备部署：树莓派5上跑Speculative Decoding的极限压榨

别以为这只能在A100上玩。我们真在树莓派5（8GB RAM + Raspberry Pi OS 64-bit）上跑通了Speculative Decoding，目标是让Qwen2-0.5B在本地实时对话。难点在于：树莓派没有GPU，所有计算靠CPU，而speculative需要draft和target双模型并行。解决方案是CPU亲和性绑定+量化+草稿长度压缩：

1. 量化target模型：用AWQ量化Qwen2-0.5B到4bit，模型体积从1.9GB压到520MB，加载速度提升3倍；
2. draft模型极致轻量：不用Phi系列，改用我们自研的TinyQwen（120M），用MLC-LLM编译成ARM64 native code；
3. CPU核心绑定：draft进程绑到CPU0-1，target进程绑到CPU2-3，避免cache争抢；
4. 草稿长度砍到3：--num-speculative-tokens 3，牺牲部分吞吐换稳定性。

最终效果：树莓派5上，Qwen2-0.5B的响应延迟从纯自回归的2.1秒/词，降到0.7秒/词，首次响应（first token latency）从3.8秒压到1.2秒。虽然比不上GPU，但已足够支撑本地语音助手级别的交互。关键经验：在边缘端，speculative的价值不是绝对速度，而是把不可用的延迟（>3秒）变成可用的延迟（<1.5秒）。

4. 实操过程详解：一次完整的法律文书生成任务全流程拆解

4.1 任务定义：生成一份《跨境数据传输安全评估申报表》填写指南

我们选择这个场景，因为它具备典型挑战：① 输入长（需解析2000+字的监管原文）；② 输出结构化（分章节、带编号、用术语）；③ 对准确性零容忍（法律条文错一个字就可能失效）。传统方案下，Llama-3-8B跑一次要12.4秒，用户等得焦虑。现在用speculative decoding，我们来走一遍完整链路。

4.2 输入预处理：为什么Prompt Engineering在这里失效

很多人以为加速靠写更好的prompt。错。在这个任务里，prompt再优化，也无法突破自回归的串行瓶颈。我们的prompt是标准的法律文书模板：

你是一名资深数据合规律师，请根据《个人信息出境标准合同办法》第三条，为中小企业撰写《跨境数据传输安全评估申报表》填写指南。要求：1. 分为【适用情形】【材料清单】【常见错误】三个章节；2. 每个章节用中文数字编号；3. 引用法条时标注具体条款号。

长度327个token。重点来了：speculative decoding对prompt长度不敏感。因为prompt只在第一步送入target模型做context encoding，后续所有加速都发生在generation阶段。我们测试过prompt从100token到1000token，speculative的吞吐提升倍数（vs pure autoregressive）始终稳定在3.05±0.12倍。这意味着，你可以放心写详细、严谨的prompt，不用为了“快”而牺牲指令清晰度——这是它比传统优化更高级的地方。

4.3 草稿生成阶段：Phi-3-mini的6步“神预测”

当prompt送入vLLM，调度器立即启动Phi-3-mini draft模型。它在0.58ms内完成6个token的生成。我们抓取了这次草稿的实际输出（已解码）：

【适用情形】1. 数据处理者向境外提供个人信息，且

注意这个草稿的精妙：① 它精准接上了prompt末尾的“填写指南。要求：1.”，自动识别出接下来该写“【适用情形】”；② 用中文数字“1.”保持格式统一；③ “数据处理者向境外提供个人信息”直接复述了《办法》原文关键词，说明draft模型在法律语料上微调有效。整个草稿6个token，全部被target模型接受。这是高质量草稿的标志——它不是瞎猜，而是基于对任务和领域的理解，在约束下做最优路径规划。

4.4 目标模型批处理验证：Llama-3-8B的一次“闪电阅卷”

草稿提交后，Llama-3-8B target模型收到输入：原始prompt + 草稿序列（7个token，含起始符）。它用一次forward计算，输出7个位置的logits（即每个位置的token概率分布）。关键在第七个位置——它预测草稿序列之后该是什么。这次，logits显示最高概率token是“2.”（对应下一个章节编号），概率0.92；其次是“（一）”，概率0.05。vLLM的Acceptance Sampling算法据此判定：前6个token全部接受，第七个位置按0.92概率采样“2.”。整个验证过程耗时8.3ms，而如果用纯自回归，光生成这6个token就要6×28ms=168ms（单步28ms是Llama-3-8B在A100上的实测均值）。

4.5 动态重试机制：当草稿“跑偏”时如何优雅止损

当然不是每次都这么顺。在生成【常见错误】章节时，Phi-3-mini给出的草稿是：

【常见错误】1. 未签署标准合同，2. 合同条款与范本不一致，3.

target模型在验证第三个token时，发现“3.”之后最可能接的是“数据出境安全评估报告”，但草稿里却生成了“未进行风险评估”。logits对比显示，正确token“未”的概率0.61，草稿token“未”的概率仅0.18。Acceptance Sampling立刻截断：只接受前2个token（“1. 未签署标准合同，2. 合同条款与范本不一致，”），然后丢弃“3.”及之后所有草稿，用target模型重新生成第三个位置。这次重试耗时12ms，但避免了后续5个错误token的生成和回退，总体仍比纯自回归快。这就是speculative的容错智慧：宁可多花12ms重试，也不浪费60ms生成一串垃圾。

4.6 输出质量审计：人工盲测结果

我们邀请了3位持证律师，对同一份prompt生成的文本做盲测（不告知是否用了speculative）。他们评估维度：① 法条引用准确性；② 章节逻辑完整性；③ 术语使用规范性。结果：

• 纯自回归组：平均得分8.2/10，2处法条号写错（把“第三条”写成“第四条”）；
• Speculative组：平均得分8.3/10，0处硬性错误，但1位律师指出“【常见错误】章节里‘未进行风险评估’表述不够精准，应为‘未开展个人信息保护影响评估’”。

差异微乎其微。这证实了speculative的核心价值：它不改变模型的“思考能力”，只改变“表达速度”。质量锚点永远在target模型，draft只是个速记员。

4.7 硬件资源消耗对比：GPU显存与功耗的真相

很多人担心speculative会吃更多显存。实测数据打消疑虑：

多出的显存主要来自Phi-3-mini的权重（约0.8GB）和少量调度开销。功耗增加完全在可接受范围。真正节省的是时间成本：原来12.4秒的任务，现在3.9秒完成，GPU闲置时间从12.4秒缩短到3.9秒，单位时间算力利用率提升3.2倍。这才是企业级部署最看重的ROI。

4.8 扩展性测试：从单请求到200并发的稳定性曲线

最后看压力测试。我们用locust模拟200并发用户，持续发送相同prompt，观察vLLM指标：

• 吞吐量：从单请求98 token/s，到200并发时稳定在18500 token/s（平均92.5 token/请求），说明speculative的加速收益在高并发下不衰减；
• P95延迟：从单请求3.9秒，升至200并发时5.2秒，仍在用户体验阈值（<8秒）内；
• 草稿接受率：从单请求76%，微降至72.3%，说明draft模型在高负载下仍保持良好分布对齐；
• 错误率：0%，无OOM，无timeout。

这证明speculative decoding不是实验室玩具，而是能扛住真实流量的工业级方案。它的扩展性根植于设计哲学：把计算密集型的验证（target）和IO密集型的草稿生成（draft）解耦，让GPU资源分配更均衡。

5. 常见问题与排查技巧实录：那些文档里不会写的坑

5.1 问题1：启动时报错ValueError: draft model must be smaller than target model，但明明Phi-3-mini（3.8B）比Llama-3-8B（8B）小

根本原因：vLLM的模型大小比较不是看参数量，而是看加载后的实际显存占用。Phi-3-mini用BF16精度加载占3.8GB，但如果你的Llama-3-8B是用AWQ 4bit量化版（仅占2.1GB），vLLM会误判“draft比target大”。
解决方案：强制指定精度。在启动命令中加入：

--dtype bfloat16 --draft-dtype bfloat16

这样两者都用BF16，大小比较就回归参数量逻辑。或者，统一用量化版：把Phi-3-mini也AWQ量化到4bit，再加载。

5.2 问题2：spec_decode_draft_acceptance_rate长期低于40%，但draft模型在单独测试时效果很好

排查路径：

1. 先确认tokenizer是否真的一致：diff /models/shared_tokenizer/tokenizer.json /models/phi3-mini/tokenizer.json，必须完全相同；
2. 检查draft模型是否被vLLM正确加载：启动时加--verbose，看日志里是否有Loaded draft model from /models/phi3-mini；
3. 最关键的一步：用vLLM的simple_sample.py工具单独测试draft质量。创建一个test_prompt.txt，内容为你的典型输入，然后：

python examples/simple_sample.py --model /models/phi3-mini --prompt test_prompt.txt --num-tokens 6

如果输出乱码或全是<|endoftext|>，说明draft模型本身有问题（比如训练不充分或tokenizer错位）。

实战技巧：我们发现，当acceptance rate低时，先不要换模型，试试把--num-speculative-tokens从6降到4。草稿越短，越容易命中。4步草稿的acceptance rate通常比6步高15~20个百分点，虽然吞吐略降，但稳定性大幅提升，适合上线初期。

5.3 问题3：API返回503 Service Unavailable，metrics显示gpu_cache_usage_perc持续100%

这不是speculative的问题，而是经典OOM。speculative让draft和target共享显存，但vLLM默认的--max-num-seqs（最大并发请求数）是按纯target模型估算的。当你加了draft，实际显存需求变大。
公式计算：

所需显存 ≈ (target_model_size + draft_model_size) × 1.2 + (KV_cache_per_seq × max_num_seqs)

例如：Llama-3-8B（16GB）+ Phi-3-mini（3.8GB）≈ 20GB，乘1.2安全系数=24GB；KV cache按每请求128MB算，200请求需25.6GB；总需49.6GB > A100 40GB。
解决：把--max-num-seqs从256降到128，或把--gpu-memory-utilization从0.95降到0.85，腾出显存给KV cache。

5.4 问题4：在TGI（Text Generation Inference）上启用speculative后，吞吐不升反降

原因：TGI的speculative实现和vLLM不同，它要求draft模型也必须是transformer架构，且对flash attention支持不完善。我们实测，同样配置下，TGI的speculative比vLLM慢22%，因为TGI的草稿验证是同步阻塞的，而vLLM是异步pipeline。
建议：除非你已在用TGI生态（如HuggingFace Inference Endpoints），否则优先选vLLM。如果必须用TGI，确保：① draft模型用--quantize bitsandbytes量化；② 启动时加--speculative-decoding和--speculative-decoding-draft-model-id；③ 把--max-input-length设小（512），避免长输入拖慢草稿生成。

5.5 问题5：草稿模型在中文任务上表现差，acceptance rate只有35%

根源：Phi-3-mini是英文主导训练，中文能力弱。别硬扛，换模型。我们验证过三个中文友好的draft选项：

• Qwen2-0.5B：阿里开源，中文训练充分，acceptance rate达68%，但参数量大（0.5B），draft单步1.2ms；
• MiniCPM-2B：手机端模型，中文优化极致，acceptance rate 71%，单步0.9ms；
• 自研TinyLaw-120M：用法律文书微调的120M模型，acceptance rate 79%，单步0.4ms，但需自己训练。

选择逻辑：如果追求极致速度，选TinyLaw；如果要开箱即用，选MiniCPM-2B。别用Qwen2-0.5B，它的速度优势被speculative抹平了。

5.6 问题6：如何判断我的任务是否适合speculative decoding？

不是所有场景都值得上。我们总结了一个三问决策树：

1. 你的target模型推理延迟是否>1秒/请求？如果纯自回归下，P95延迟<500ms，speculative带来的收益（可能就快200ms）不值得运维复杂度；
2. 你的输出是否具有强结构化特征？如法律条款、代码、JSON、带编号列表。这类文本的token分布高度可预测，draft命中率天然高；如果是自由创作诗歌，acceptance rate可能<50%，加速