推理加速的三本账：解码、数值、潜空间各自在赌什么
同周推到台前的三篇论文分别动了解码调度、状态量化与潜空间压缩：一个把 wall-clock 再提 5%–41%，一个把服务内存砍掉 68.7%，一个把视频生成延迟从 863.2 秒压到 77.7 秒。三个数字的计量单位互不相同，代价也各记在各层的账上。
加速比写在纸上，代价记在别处
本周推到台前的三篇 arXiv 论文，各自动了推理栈的一层。DLoop（arXiv:2610.07659，NAVER AI Lab、NAVER AI Search Platform 与高丽大学，10 月 6 日提交）动解码调度，STEPQuant（arXiv:2609.38169，港城大、哈佛、浙大、自动化所、港中大与清华，9 月 29 日提交）动数值精度，GRACE（arXiv:2610.10524，KAIST 与 Kakao，10 月 7 日提交）动潜空间表示。
三篇没有一个是在让模型变小。它们做的是同一件事的不同版本：让每一步少干一点活。问题出在抄数字这一步——wall-clock 提速 5%–41%、服务内存降 68.7%、端到端延迟快 11.1 倍，这三个数的计量单位互不相同，代价也各记在各层的账上。只把收益列进周报，上线时踩的坑一个都不会少。
第一本账：解码层，赌 draft 模型可靠
推测解码的标准流程是 draft 提一串 token、target 验一次、接受多少算多少。DLoop 的作者注意到一件事：draft 模型越来越强之后，target 模型经常把一个 drafting stage 产出的 token 全盘接受，可 verification 一步也没省。draft 越准，验证越像纯粹的过路费。
已有的 adaptive draft length 方法能在解码时决定攒多少个 draft token 再验证，但它们只对自回归 draft 模型有效。并行 draft 模型要继续往下写，需要那些尚未被验证的 token 对应的 target hidden states，这一步卡住了。
DLoop 把 drafting 本身做成循环：draft 模型还自信就继续写，攒够了再把累积的全部 draft token 一次验完。多花的是 draft 模型的前向，省下的是 target 模型的验证前向。配套一个 loop-aware training——训练时把 draft 模型为未验证 token 生成的 hidden states 喂回它自己，否则它在多出来的那些 stage 上并不可靠。
数字是跨 EAGLE-3、DFlash、Domino、DSpark 与 multi-token prediction 等五种 draft 方案，wall-clock 加速比提升 5%—41%，且保持 lossless decoding。
工程提示：这一层的赌注是「draft 模型的置信度在额外 stage 上仍然可信」，能不能兑现取决于你做没做 loop-aware training。DLoop 的仓库 README 明写代码尚在内部评审，等不到开源也能先把账建起来——在自己的 serving 里记两个数：每个 decoding step 的 target forward 次数，以及被接受的 draft token 占比。后者长期贴着 100%，你就知道自己在交过路费。
第二本账：数值层，赌误差分布可预测
线性注意力把随长度增长的 KV cache 换成固定大小的 recurrent state，省了显存，却换来另一种增长：每个并发请求都要一份常驻 state，服务系统还要为缓存和调度多留 slot。STEPQuant 的图 1(a) 给出了交叉点——官方 SGLang 部署下，Qwen 的 FP32 state pool 在 70 个并发请求时就超过了它 BF16 权重的显存占用。
直接把 state 均匀量化会崩，因为 Delta rule 每次更新都作用在一个近似 state 上，误差一步传一步。论文把误差拆成两个维度：时间上，门控保留得越久的 state unit 累积误差越大（在 2304 个 Qwen head 上验证过）；空间上，同样幅度的误差落在不同的 key row 上，对输出的影响并不一样，而 state 的量级沿行和列都在变。
于是精度不再均匀分配。lifetime-aware bit allocation 给误差大且活得久的 unit 更多 bit，少数高风险 unit 直接留在 FP16；key-row-aware dual-axis fitting 给 key 行和 value 列分别配 scale，行 scale 一并兼顾当前量级与实测的输出误差影响。
BF16 权重、七项长生成任务（LCB v6 / EvalPlus / AIME 26 / MATH-500 / HMMT / GPQA-D / IFBench）的平均准确率：Qwen3.8-27B 从 FP32 的 80.60，到均匀 INT8 的 71.86、均匀 INT6 的 45.04、均匀 INT4 的 12.73，STEPQuant@6bit 是 80.59、@4bit 是 80.51。Kimi-Linear-48B-A3B-Instruct 同一张表：FP32 61.52，INT8 56.02，INT6 45.70，INT4 21.63，STEPQuant@6bit 61.47、@4bit 58.52。四张 A800、SGLang、batch 512、W4（4-bit AWQ）权重下，Qwen 总内存从 419.73 GiB 降到 131.18 GiB（−68.7%），state 内存降 80.1%（5.03×），state 更新耗时降 65.6%（2.91× 快）。
KDA（Kimi 侧）在同一实验里是另一组数：总内存 149.70 → 69.36 GiB（−53.7%），state 内存 100.04 → 19.70 GiB（−80.3%，5.08×），state 更新耗时 8.48 → 4.76 ms（−43.9%，1.78×）。同一套方法在两个架构上的收益并不对称——Qwen 拿到 68.7%，KDA 只拿到 53.7%，因为后者 state 占总显存的比例本就不同。
消融表里最该看的一格在 4-bit 档：只做时间维度分配（Temporal only）平均准确率掉到 12.87，只做空间拟合（Spatial only）还有 73.95，两者合起来 84.72。低比特下承重的是空间拟合，不是比特分配。另一条消融解释了为什么剩下那一点点 bit 要花在刀刃上：只用 FP16 保护 1.39% 的 Qwen head，4-bit 三任务平均就涨 6.70 分，6-bit 的 AIME 涨 14.16 分。
命令来自官方 README（实测栈为 SGLang 0.5.12、PyTorch 2.11.0、Triton 3.7.1）：
bash scripts/reuse_sglang_env.sh /path/to/sglang-env
.venv-eval/bin/python -m stepquant.reproduction \
--models qwen --formats stepquant6 --devices 0,1,2,3
CUDA_VISIBLE_DEVICES=0,1,2,3 .venv-serving/bin/python -m stepquant.sglang \
--model-path /path/to/Qwen3.8-27B --tp-size 4 \
--state-format stepquant6 --plan artifacts/reproduction/plans/qwen-stepquant6.pt \
--attention-backend triton --reasoning-parser qwen3 \
--context-length 131072 --chunked-prefill-size 2048 \
--mem-fraction-static 0.85 --served-model-name stepquant校准只用 32 段 WikiText-2 训练文本、每段 2048 token，一次离线做完。bit 分配与 FP16 pivot 在离线阶段定死，解码时 packed 布局跨请求固定，没有 per-token 分配开销；tilewise 重建、Delta 更新与当前 readout 融合进一个 kernel，scale 更新和数据回写丢到另一条 CUDA stream 上与模型计算重叠。
踩坑在论文自陈的 Limitations 里：BF16 权重配 4-bit state 时，KDA 在长生成任务上掉点，而 Qwen 虽然平均准确率贴着 FP32，输出却变长了。准确率这张表看不出成本上升。上线前把「平均生成 token 数」和准确率并排放进同一个看板，别只看后者。
第三本账：潜空间层，赌压缩后的 latent 还被原模型认得
视频扩散模型的算力主要花在 DiT 处理的 token 数上，注意力随序列长度平方增长。提高 VAE 压缩比是最直接的减速带，但压缩比一高重建质量就掉，靠加 latent 通道补回来又会拖慢 DiT 收敛。更麻烦的是换掉 latent 空间等于让预训练 DiT 面对一个它没见过的分布——要么从头重训，要么花大价钱适配。论文引用了 Open-Sora 2.0 的例子：在 Video DC-AE 上适配预训练 DiT，160 张 GPU 仍未完全收敛。
GRACE 用两阶段绕开这个死结。第一阶段保留冻结的预训练编码器在低分辨率输入上产出的 base latent，另学一个 residual latent 承接压缩丢掉的空间细节与帧间运动，并用冻结 DiT 的中间特征把压缩后的 latent 与原 latent 对齐——对齐目标是生成，不是重建，所以不用只靠 L1/L2 和感知损失。第二阶段轻量微调 DiT，配 asymmetric denoising：base latent 比 residual latent 先去噪，让已去噪的 base 给 residual 一个稳定锚点，两者在同一次采样内完成，不增加采样开销。
数字来自 Wan2.1-I2V-14B，480×832×81、50 步、单张 A100（SXM4-80GB，bfloat16，无推理时编译；延迟覆盖条件编码、去噪循环与视频解码，不含模型加载、文本编码与写 MP4）：推理延迟从 863.2 秒降到 77.7 秒（11.1×），T2V 从 851.5 秒降到 75.8 秒，latent token 从 32.8k 降到 4.3k（约 7.6×，论文表述为「近 8×」）；VBench-I2V 总分 87.92 → 87.90（差 0.02），T2V 总分 83.93 → 85.81（反而高 1.88）。736×1280×81 下加速到 15.5×。
代价写在附录表 G.1：Stage 1 自编码器 8.5 H200 GPU 天（全量 6.9 加 decoder-only 1.6），Stage 2 适配 DiT 30 H200 GPU 天，合计 38.5。
踩坑有两条。压缩后每帧 token 变少，小物体受损最重——远处的脸、招牌上的字、细结构会丢或者糊，736×1280 下这个效应更弱，因为同样的压缩比留下了更多 token。换一条预训练管线就要重跑一次 Stage 1，base latent 来自那条管线冻结的编码器、对齐损失也由它的 DiT 监督，一次 8.5 GPU 天，排期里要单列一行。
三本账并到一张表上
| 层 | 收益指标 | 收益 | 代价指标 | 代价 |
|---|---|---|---|---|
| 解码调度 | wall-clock 加速比 | +5%–41% | draft 可靠性 | 需 loop-aware training，否则额外 stage 不可靠 |
| 数值精度 | 服务内存 | −68.7% | 输出长度 | 4-bit 下 Qwen 分数持平但生成变长，KDA 掉点 |
| 潜空间表示 | 端到端延迟 | 11.1× | 训练预算与细节 | 38.5 H200 GPU 天，小物体与文字丢失 |
排查顺序按成本量级排。先数 target 前向次数与 draft 接受率，小时级，改 serving 埋点就能拿到；再看 state pool 占总显存的比例与并发交叉点，天级，要做量化和校准；最后才动潜空间，周级，得重训自编码器。前者近乎零成本，后者一动手就是几十 GPU 天。
多数团队卡住的地方是第二本账。线性注意力的 state 尺寸不随上下文涨，却在并发下变成新的显存大户，而这一点在单请求 benchmark 上完全看不出来——70 并发那个交叉点，只有把 batch 拉起来才现形。
参考来源
- DLoop: Looped Speculative Decoding（NAVER AI Lab，2026-10-06）
- STEPQuant: When and Where Errors Matter in Delta-Rule Recurrent State Quantization（2026-09-29）
- GRACE: Generation-aware latent compression for efficient video generation（KAIST AI / Kakao，2026-10-07）
- naver-ai/DLoop（仓库已建，README 明写「code is currently under internal review and will be released soon」）
- Dreamer-Toby/STEPQuant（含 SGLang 集成与复现脚本，README 自陈实测栈 SGLang 0.5.12 / PyTorch 2.11.0 / Triton 3.7.1）
引用核验记录
| 声明 | 出处 | 结果 |
|---|---|---|
| DLoop：跨 EAGLE-3 / DFlash / Domino / DSpark / MTP，wall-clock 提速 5%–41%，lossless | arXiv:2610.07659 abs 摘要（v1，2026-10-06） | ✅ 逐字一致 |
| DLoop：5%–41% 覆盖四 draft 模型 × Qwen3-4B/Qwen3-8B + MTP × Qwen3.5-9B/Gemma-4-12B，八 benchmark、H100、bf16、T=0；最大增益 DSpark；接受长度 +12%–102% | 论文 §4.2 + 结论段（PDF 全文，2026-10-08 读） | ✅ 终审补记 |
| STEPQuant：419.73 → 131.18 GiB 出于 W4 权重配置（非 BF16） | 论文 §5.6 原文 | ✅ 终审补记 |
| DLoop 代码未发布 | naver-ai/DLoop README（2026-10-08 读） | ✅ 原文「under internal review」 |
| STEPQuant：Qwen 80.60 / 71.86 / 45.04 / 80.59 / 80.51 | 论文表 1 + 仓库 README 结果表（2026-10-08 读） | ✅ 两处一致 |
| STEPQuant：Kimi 61.52 / 56.02 / 45.70 / 61.47 / 58.52 | 论文表 1（长生成，同表） | ✅ 与 README 一致 |
| STEPQuant：419.73 → 131.18 GiB（−68.7%）、state −80.1%（5.03×）、更新 −65.6%（2.91×） | 论文 §5.6 与图 3(c)(d) | ✅ |
| STEPQuant：四张 A800、TP4、batch 512 | 论文 §5.1 Setup | ✅ |
| STEPQuant：消融 12.87 / 73.95 / 84.72；pivot 1.39% head → +6.70 / +14.16 | 论文 §5.6 Component analysis | ✅ |
| STEPQuant：KDA 149.70 → 69.36 GiB、8.48 → 4.76 ms | 论文附录 F.4（图 F4） | ✅ |
| STEPQuant Limitations：BF16 + 4-bit 下 KDA 长生成掉点、Qwen 输出变长 | 论文附录 H Limitations 原文 | ✅ |
| GRACE：863.2 → 77.7（I2V）、851.5 → 75.8（T2V）、11.1× / 15.5× | 论文表 3 与附录表 G.1 | ✅ |
| GRACE：token 32.8k → 4.3k | 论文表 3 / 表 4 | ✅ 实测 7.6×，论文表述「近 8×」 |
| GRACE：8.5（6.9 全量 + 1.6 decoder-only）+ 30 = 38.5 H200 GPU 天 | 论文附录表 G.1 | ✅ 逐项一致 |
| GRACE：单张 A100、50 步、bfloat16、无推理时编译 | 论文附录 C.2 Evaluation Protocol | ✅ |
口径提示（终审补充）：DLoop 的 5%–41% 是跨全部实验设置的极差，不是某一种 draft 方法在某一负载下的取值。据论文 §4.2 原文，覆盖的组合是四个 draft 模型（EAGLE-3 / DFlash / Domino / DSpark）配 Qwen3-4B 与 Qwen3-8B，外加 MTP 模块配 Qwen3.5-9B 与 Gemma-4-12B，八个 benchmark、H100 80GB、bf16、greedy（T=0）；同一批实验里平均接受长度提升 12%–102%，四个 draft 模型中增益最大的是 DSpark（它的 full acceptance ratio 最高）。同理，STEPQuant 那组内存数字出于 W4 权重配置，GRACE 的 11.1× 与 15.5× 分别对应 480p 与 736p。三篇的吞吐/延迟数字均出自各自论文自报的硬件与负载，跨论文横向比较不成立。