解码快 3.13 倍，端到端只有 1.56 倍：VLM 投机解码的天花板

原文对这件事给了正确但笼统的解释：投机解码只加速 decode，不加速视觉编码和 prefill；当这两段本来就占了大部分墙钟时间，再大的解码提速也只换来有限的端到端收益——这是阿姆达尔定律。原文还补充说，VLM 的 prefill 比纯文本更重，因为图像要先过视觉编码器，语言主干再处理几百个视觉 token；而端侧设备算力远低于数据中心 GPU，prefill 占比会更高（M5 的每核 GPU 神经加速器缩小了这个差距）。

这段解释是对的，但它停在了定性层面。而这两张图给的数据足以把它变成一个可以算的量。阿姆达尔定律的形式是：端到端提速 = 1 / ((1 − f) + f / s)，其中 s 是解码提速，f 是解码在原始墙钟时间里的占比。两个已知量解一个未知量，f 就能反推出来：

f = (1 − 1/端到端提速) / (1 − 1/解码提速)

把图里的数据代进去，结果相当有说服力：

看 M5 Max 上的 COCO 与 TextVQA 这一对：接受 token 数分别是 4.21 和 4.08，几乎一样；解码提速 3.13 倍对 2.69 倍，差距也不大。但端到端一个 2.59 倍、一个 1.56 倍。差别不在草稿模型猜得准不准，而在这两类任务的输出长度——图像描述要生成整段文字，解码占了九成墙钟时间；而 TextVQA 是看图回答一个短问题，输出没几个 token，超过四成的时间花在视觉编码和 prefill 上，投机解码碰都碰不到。

这条推论给出的选型规则，比「最高提速 3.13 倍」有用得多：投机解码的收益由你的输出长度决定，而不是由草稿模型的质量决定。长输出任务——文档结构化抽取、图表解读成段落、多轮视觉问答、长图文摘要——是这套东西的主场；短输出任务——图片打标、是非判断、单字段 OCR 校验、审核分类——几乎吃不到红利，哪怕接受率同样漂亮。

同一张表还能看出第二件事。M3 Ultra 上 COCO 的接受 token 数是 4.50，比 M5 Max 上同一任务的 4.21 还高，解码提速却只有 2.14 倍对 3.13 倍。接受率更高而提速更低，说明瓶颈不在草稿模型，而在运行时与硬件本身——同一个草稿模型换一套栈、换一代芯片，收益可以差掉三分之一。这也是为什么原文推荐 block size「8 或 9，取决于硬件」而不是给一个固定值。

五、它是无损的，而且自带可观测性

有一点必须说清楚，因为这是投机解码区别于量化、蒸馏这类提速手段的根本：它是精确的。目标模型会校验每一个被提议的 token，所以在贪心解码下，输出与不用草稿模型时完全一致。你不是在拿质量换速度，你是在拿显存换速度。

原文还提到了一个容易被忽略但很实用的细节：每次响应的计时报告里会给出 draft_n 与 draft_n_accepted。这两个数就是线上监控投机解码是否还在正常工作的抓手——接受率一旦掉下来（比如换了 prompt 模板、换了图像分辨率、业务流量分布漂移），提速会先于任何报错悄悄消失。上线时就把这两个指标接进监控，比事后查「为什么最近变慢了」省事得多。

六、三套栈怎么跑起来

SGLang 需要带 DSpark for LFM2 支持的构建（PR #40651），启动目标模型时挂上草稿模型：

python -m sglang.launch_server \
  --model-path LiquidAI/LFM2.5-VL-3B \
  --speculative-algorithm DSPARK \
  --speculative-draft-model-path LiquidAI/LFM2.5-VL-3B-DSpark \
  --speculative-draft-attention-backend flashinfer \
  --speculative-dspark-block-size 9 \
  --disable-radix-cache

随后在 http://localhost:30000/v1 访问 OpenAI 兼容接口。block size 从草稿模型的 config.json 里读取。这里有一个做基准测试时必须照做的细节：基线就是同一条命令去掉那三个 --speculative-* 参数——同样的构建、同样的目标模型、同样的缓存设置，只切换投机解码这一个变量。拿别的框架或别的配置当基线，测出来的倍数不成立。

llama.cpp 需要对应的构建（PR #29339）：

llama-server -m models/LFM2.5-VL-3B-F16.gguf \
  --mmproj models/mmproj-LFM2.5-VL-3B-F16.gguf \
  -md LFM2.5-2.6B-DSpark-F16.gguf \
  --spec-type draft-dspark --spec-draft-n-max 8 --spec-draft-n-min 0 \
  -fa on -ngl 99 -c 8192

MLX-VLM 需要对应的构建（PR #2280），命令最短：

mlx_vlm.server --model LiquidAI/LFM2.5-VL-3B --draft-model LiquidAI/LFM2.5-VL-3B-DSpark

MLX 这边的 block size 从随模型附带的 sidecar 元数据里读，n-max 会被钳制到该值。草稿模型在 Hugging Face 上同时提供 Safetensors 与 GGUF 两种格式，权重开放，可下载、可微调、可自行部署。

七、落到中国团队的部署清单上

第一件事是改掉提问方式。向供应商或内部平台要性能数据时，别问「投机解码能快多少倍」，要问「在我这类任务的输入输出长度下，端到端能快多少倍」。这两个问题的答案在 M5 Max + TextVQA 这一格里差了将近一倍，而前者是所有宣传材料默认会回答的那个。

第二件事是先量自己的 decode 占比。不需要先接草稿模型：跑一批真实请求，记录 time-to-first-token 与总耗时，两者之差就近似是解码段。占比低于六成，投机解码的端到端收益大概率压在 1.5 倍以内；高于九成，才有机会吃到接近解码提速的全部红利。这个测量在任何推理栈上都能做，不依赖 DSpark。

第三件事是算显存账。8.9% 的额外参数在 H100 上不值一提，但在把 3B VLM 塞进消费级设备的场景里，这一成可能正好是压垮 KV cache 预算的那部分。端侧选型时要把草稿模型的常驻显存和 block size 带来的临时开销一起算进去，而不是只算目标模型。

第四件事是别把 prefill 的账算到投机解码头上。VLM 的图像 token 数量由分辨率和切片策略决定，几百个视觉 token 过一遍语言主干的成本是实打实的。如果你的瓶颈在这里，该做的是降分辨率、裁切 ROI、复用图像编码结果，而不是换一个更好的草稿模型——阿姆达尔定律封死的那部分，换草稿模型是换不出来的。