图书馆里同一个书架，每次找书都得重新学一遍哪本书在第几层——dLLM 的 KV 缓存就是这么浪费的，Flash-dLLM 说能省 22 到 148 倍
扩散大语言模型推理慢，卡在两个地方：KV 缓存没法有效用，并行解码没有可扩展机制。Flash-dLLM 的做法是免训练：先做一个 IO 感知的融合 KV 缓存内核，再在这个缓存上做"草稿-验证"解码，dLLM 自己当草稿器也当验证器，不需要辅助模型。
帖子那句"5.1× 和 11.0× 于 Elastic-Cache"我核了，数字对。但仓库 README 自己写的免责声明比这组数字重要，而且我核 GitHub 的时候发现了几处帖里完全没有的东西。
一、README 明确说"不是每个设定都无损"
README 里有一句直接的警告：
"Flash-Cache + Flash-Verify achieves both the highest accuracy and throughput on GSM8K-512. It is not the most accurate configuration in every setting: for example, confidence-aware Flash-Cache achieves 42.07% on HumanEval-512, compared with 40.24% for Flash-Verify, at lower throughput. Select a configuration according to the required accuracy-throughput balance rather than treating acceleration as universally lossless."
HumanEval-512 上，快的那档准确率低 1.83 个百分点。41.07 对 40.24——差 1.83，不是"几乎无损"。
帖子的中文摘要是"在保持生成质量的同时更快解码"。这一句是论断，而仓库给的是逐设定的真值表。这条我建议照抄进自己的选型笔记。
二、基线数字里藏着两个不该忽略的量
README 的主结果表（单张 A100 80GB，batch size 32）：
| 基准 | 长度 | 准确率 | 吞吐 | vs 无缓存贪心 |
|---|---|---|---|---|
| GSM8K (5-shot) | 256 | 81.88 | 194.9 tok/s | 29.1× |
| GSM8K (5-shot) | 512 | 83.02 | 210.6 | 81.0× |
| MATH (4-shot) | 512 | 35.98 | 210.1 | 42.0× |
| HumanEval (0-shot) | 512 | 40.24 | 185.6 | 58.0× |
| MBPP (3-shot) | 512 | 39.00 | 148.0 | 148.2× |
所以 README 另给了两个更实的数：22.3×–148.2×（区间下界 22.3 对应 MATH-256，上界 148.2 对应 MBPP-512），以及 148.0–210.6 tokens/s（吞吐绝对值区间）。
3、5.1× / 11.0× 的分母是哪个，也得说清
README 原话："based on the Table 1 throughput ratios"——这是在吞吐比上算的，不是延迟。而且 5.1× 对应 GSM8K-512，11.0× 对应 HumanEval-512，都是 512 长度。
GSM8K 那一格还有个细节：Flash-Cache + Flash-Verify 同时拿到了最高准确率（83.02%）和最高吞吐（210.6 tok/s）。只有这一格是无损的。HumanEval 上就不是了。
4、README 主动交代了一处"脚本默认值 ≠ 论文配置"
这是很少见的诚实度。README 自己写：
"The script defaults are not the complete paper configuration." 论文 Table 3 指定的是 masked-window 64 tokens、tracking budget 64 tokens（MBPP 是 48）；而脚本默认是 block_length=16、confidence threshold 0.9、mask_num=4，§3.1 还有一个"通用默认 tracking budget 80 tokens"。
三个默认值互不相同。作者明确要求：要对齐论文结果，请以 Table 3 为准，别拿那个 80 的通用默认去替代。
还有一句更实在的警告：A two-sample evaluation checks the execution path; it is not a throughput reproduction.——两样本评测只验执行路径，不是吞吐复现。
5、GitHub 体检：18 星、0 fork、建仓 8-13
VILA-Lab/Flash-dLLM，Apache-2.0，Python，建仓 2026-08-13，末推 2026-09-22（论文提交当天），18 星 / 0 fork / 0 issue。
README 标了 [NeurIPS 2026]，但论文在 arXiv 的 citation 里写的是 note = {Preprint}。这个不一致先记下，不下判断。
18 星 0 fork 意味着目前没有第三方复现。README 里那套 A100 80GB + batch 32 + 三档 few-shot 的设置要跑起来不便宜，0 fork 说明还没人搬走。
【直引】另一条实用警告：HumanEval / MBPP 和后处理会执行生成的 Python，README 建议在隔离环境跑代码生成评测。这种提醒在推理加速的仓库里不常见，但它跟 IO 内核的实际风险是一对——融合内核出 bug 的表现，往往就是下游跑出一段奇怪的代码。
下一根钉子：22.3× 和 148.2× 这两个数之间为什么差 6.6 倍，是分母问题（贪心无缓存的基线快慢差 6.6 倍）还是方法在不同基准上的收益真差这么多。看 Table 1 的 baseline 那一列能算出来。另一根：18 星 0 fork 的状态能维持多久——如果这个框架真的在 LLaDA-1.5 上有效，第三方复现应该很快出现；如果半年后还是 0 fork，那 NeurIPS 2026 这个标签的可信度要重新估。