验证量化与推测解码的实际提速

先分清加速的是哪一段

推理分预填充和解码两段。推测解码只加速解码；量化省的是显存和带宽。宣传里的倍数，通常只是被加速的那一段。LFM2.5-VL 的推测解码草稿模型在 M5 Max 上把解码提速 2.30 到 3.13 倍，端到端只有 1.56 到 2.62 倍：图像编码和预填充没变，而在端侧设备上它们占了很大一块时间。先量清楚自己的请求里两段各占多少。

在同样的条件下比

1. 同硬件、同批量。 Inferact 的 TPU 巨核让 Kimi K3 在 16 块 TPU v7 上比 16 块 GB200 上的 vLLM 快 57%；不开推测解码时，优势只在批量 1 到 8 之间，约为 1.4 到 2 倍。批量一变，结论可能就变。
2. 同接受率。 推测解码的收益取决于草稿被接受的比例，Inferact 那组数是每步平均接受 6 个 token。你的提示和输出分布不同，接受率也会不同。
3. 同一套正确性检查。 用贪心解码在固定基准上对比输出。推测解码按设计不改变输出，量化会改变。

Muse Glimmer 发布时给出的量化与推测解码数字，也要按这三条逐一对照，再决定能不能照搬到自己的机器上。

量化看质量下限，不看压缩率

Pinterest 在 1 亿条向量上比过：标量量化把 HNSW 索引从 121GB 压到 50GB，召回 92.92%；乘积量化压到 32GB，召回掉到 77.25%。选哪种取决于你能接受的召回下限。模型量化也一样，先定质量底线，再找最省的档位。

平均分会把弱点藏起来。采用分块 KV 缓存压缩的模型，检索准确率会随信息相对压缩窗口边界的位置周期性起伏，最多差 40 个百分点，只看平均数看不出来。

盯住容易漏的地方

• 精度不一致。 Ollama v0.32.4 修了 Qwen3 MoE 各专家量化精度不一致时的解码问题，还让推测解码草稿模型的输出头按指定精度量化——此前它可能留在更高精度上，吃掉推测解码本该省下的显存与带宽。
• 新路径的质量缺陷。 同一版本在 Apple GPU 上的 NVFP4 路径有输出质量下降的 bug，两天后的 v0.32.5 才修。输出流畅不代表没掉质量。
• 省显存的另一种代价。 Colibrì 把路由专家放在硬盘上按需读取，能在小机器上跑大模型，但每秒只有 0.05 到 1.8 个 token；它保证不改动模型，不保证速度。

SGLang、vLLM、Ollama 的新版本常带来新的量化或推测解码路径。每次升级引擎后，用同一组请求重跑一遍。

与相邻能力的分工

确认提速是真的之后，要多少卡、多少副本，交给「推理服务容量规划」；模型能不能在一台具体的机器上跑，见「端侧模型部署与硬件适配」。