SubSpec：把目标模型自己的「低比特影子」当作草稿模型

选题与去重说明

本次轮转为周五 = 效率与系统。候选池共 25 篇（arXiv cs.LG / cs.CL 2510–2608、NeurIPS 2025、ICLR 2026 Oral、ICML 2026、HF Daily Papers），以 shuf -i 1-25 -n 3 抽取，首抽命中 #17 SubSpec，资料充分，未重抽。

去重索引未更新：本次为云端定时任务，用户桌面端不可达，ml-report-index.md 既未读取也未写回。去重基于本次会话内检索结果人工判断，建议在桌面端会话中补记本期条目（见文末）。

所有链接均在 2026-08-07 本次运行中实际尝试抓取，结果如实标注。✅ = 已成功抓取并核验内容；⚠️ = URL 来自可信检索结果但本次抓取被代理拒绝（PROVENANCE_REQUIRED / 403 / 人机验证），未逐字核验。

2.1 Motivation：痛点的量化

论文开篇给出的不是「LLM 推理慢」这类泛泛描述，而是一个具体到硬件的困境：在 8GB VRAM 的消费级显卡上跑 BF16 的 Qwen2.5 7B，纯参数卸载的解码吞吐是 2.77 tokens/s（表 1，Qwen2.5 7B / MT-Bench / None 行）；32B 模型在 24GB 限制下更低至 0.52 tokens/s。按人类阅读速度约 4–5 words/s 计，0.52 tok/s 意味着每输出一个词要等两秒——不是「慢」，是「不可用」。

成因是清楚的：每一次目标模型前向，被卸载到 CPU 内存的权重都必须经 PCIe 4.0 x16 搬运一次。7B 的 BF16 权重约 15GB，扣掉 GPU 常驻的 11 层，每 token 要搬运 10GB 量级的数据；PCIe 4.0 x16 理论带宽约 32GB/s。于是解码延迟完全由带宽决定，与 GPU 的 TFLOPS 无关。

现有解法各自的失败方式

2.2 论文的故事线（论证结构）

论文的论证不是「我们提出了 X，实验显示 X 更好」，而是一条相当紧的推导链：

第一步 · 写出加速比的解析式，看清分子分母。论文 §3.1 给出：

第二步 · 代入卸载场景的硬件常数。在卸载下 t_Target 被 PCIe 传输支配，比 GPU 常驻的 t_Draft 大 1–2 个数量级，于是 𝒟·t_Draft/t_Target 即使 𝒟 取到 48 也仍是 O(1)。结论：加速比 ≈ τ / O(1)。这是论文的核心转折点。

第三步 · 追问「什么样的草稿模型 τ 最大」。极限情况是草稿 = 目标本身。论文表 5 实测了这个上界：Self 行，T=0.2 时 τ = 34.50。这个数字定义了天花板。

第四步 · 在「装不下」的约束下逼近这个上界。既然完整目标装不下 GPU，就装它的 4-bit 版本——这就是 substitute layer。其余都是工程化：能共享的层直接共享、KV-Cache 共享、草稿概率锐化、异步预取。

2.3 方法论与机制解剖

关键机制表

与竞品的配置对比（表 1 隐含）

3.1 硬件与评测设置

3.2 主结果矩阵（表 1，T=0，MT-Bench）

五基准均值（表 1 Mean 列）：Qwen2.5 7B — None 2.68 tok/s，SubSpec 27.09 tok/s（10.10×）；Llama3.1 8B — None 2.39 tok/s，EAGLE-2 7.65 tok/s（3.20×）。

3.3 消融研究（表 2；Qwen2.5 7B，MT-Bench，8GB，贪心）

3.4 草稿温度敏感性（表 5，τ 值）

这是全文最有信息量的一张表，但论文没有充分挖掘它。三个观察：

1. 锐化的收益与对齐度成正比。对 EAGLE-2 和 1.5B 草稿，温度从 1.0 降到 0.2 反而略微有害（τ 下降 0.34 / 0.56）；对 Self 上界收益最大（+6.71），SubSpec 居中（+1.79）。锐化不是通用技巧——只有当草稿分布本身已接近目标时，把它推向 argmax 才有意义；对齐度差的草稿，锐化只是让它更自信地犯错。这个机制在论文里没有被点破。
2. SubSpec 与理论上界的差距 = 27.08 / 34.50 = 78.5%。4-bit 量化损失掉 21.5% 的接受长度。这是评估「更激进量化（2/3-bit）是否可行」的关键基线。
3. EAGLE-2 的 τ 在两个温度下都在 3.4–3.8，几乎不动——接受长度受限于架构而非采样策略，这解释了它在卸载场景无论怎么调都追不上。

3.5 两组关键对照

与「直接量化部署」对比（表 3；Llama3.1 8B，8GB）

SubSpec 比直接跑 4-bit 量化模型慢 5.59 倍。论文的辩护是「量化有损」，但全文没有报告任何一个下游任务准确率数字来量化这个「有损」到底损失多少。读者因此无法回答真正的决策问题：为保住 BF16 质量，值不值得付 5.59× 的吞吐代价？

与 SpecExec 正面对比（表 4；Llama3.1 8B，8GB 预算）

SubSpec 吞吐是 SpecExec 的 1.88×，且不需要额外草稿模型。论文对 SpecExec 的技术批评也很具体：其剪枝与 early-exit 引入动态 shape，阻碍 torch.compile——这是来自工程实践而非纸面复杂度的判断。

3.6 推理模型结果（表 6，长思维链场景）

随机解码退化：T=0.6 下吞吐下降约 60%，加速比降至 5.8×–7.8×，说明深树策略（𝒟=48）严重依赖低熵输出，论文对此讨论偏少。

统计显著性：论文报告 MT-Bench 上 5 次独立运行标准差 0.101 tokens/s（相对标准差 0.40%）。但这只覆盖一个基准的一个配置；表 1 中其余约 60 个数字均为单次运行，未报告方差。

3.7 关键超参汇总

𝒟 = 48 的选择依据（图 6）：论文称最优点出现在「投机时间与验证时间近似相等」处，但只给了定性图示，没有 𝒟 扫描的数值表。值得注意的是，𝒟=48 配 τ=27.08 意味着逐 token 接受率约 56.4%——草稿树的后半段（第 28–48 层）平均而言是被浪费的，这里存在明显的自适应深度优化空间。

4.1 真正的贡献是什么

不是「用量化模型做草稿」这个动作本身——ML-SpecQD（2025-03）已经做过 MXFP4 直铸草稿。SubSpec 真正的贡献有三层：

1. 重新定义了卸载场景下的优化目标。把加速比公式代入 PCIe 主导的硬件常数后，得出「t_draft 几乎免费，只需最大化 τ」的结论。这改变了草稿模型的设计空间——从「小而快」翻转为「大而准」。
2. 把「共享」推到极致作为对齐手段。权重共享 + KV-Cache 共享不只是省显存的技巧，更是对齐度的构造性保证：草稿与目标看到的 attention 上下文严格一致，误差只来自量化。vLLM 提案 #39427 的独立前置实验给出了定量效果：替身草稿与目标的 KL 散度 0.1176，传统小草稿是 0.5899——相差 5.02 倍。
3. 给出了真正 plug-and-play 的路径。免训练、无需同族小模型、不改目标权重。任何新发布的 dense 模型，当天就能用上，不必等草稿模型生态跟进。

可脱离本文单独复用的设计

5.1 论文自述的限制（附录 A 与结论章节）

1. 最低显存门槛：「Qwen2.5 7B 约需 7.1 GB 最低 GPU 显存」。8GB 卡上只剩 0.9GB 余量，几乎没有腾挪空间。
2. 量化粒度未探索：仅研究 4-bit 替身，2-bit / 3-bit 未做。
3. 架构范围：「SubSpec 主要适用于 dense LLM 架构」，MoE 需要后续工作。

5.2 本报告的补充批判（8 点）

批判 1 —「Lossless」是全文最大的字，却没有一个数字支撑它论证缺口 / 指标有效性

论文标题、摘要、结论反复强调 lossless，但全文不含任何下游任务准确率——没有 GSM8K accuracy、没有 HumanEval pass@1、没有输出一致率、没有分布检验。losslessness 完全建立在「投机解码验证机制在理论上保分布」这一架构性论证之上。而论文同时引入了草稿概率锐化 T=0.2，并在 T=0.6 下也报告结果；锐化是否在随机解码的修正采样中被正确处理，论文没有形式化说明。一个只需半页的实验（固定 seed 下 SubSpec 输出与纯目标模型输出的逐 token 一致率）就能关掉这个缺口，但它不在文中。

批判 2 — 遗漏了直接前置工作 ML-SpecQD，新颖性主张因此不成立缺乏关键竞品对比

ML-SpecQD（Georganas et al., 2025-03-17）已提出「MXFP4 权重直接从 BF16 目标直铸草稿，plug-and-play，无需预训练或对齐」，与 SubSpec 核心构造高度重合，且早 6 个月。本报告核查了 SubSpec 的完整参考文献列表：未引用 ML-SpecQD，也未引用任何以量化草稿为核心的工作；最接近的引用是 CLASP [8] 与 SWIFT [40]，二者都是层跳过而非量化。论文因此把「training-free + 低比特替身」表述为无先例，这在文献上站不住。SubSpec 的真正差异化在于卸载场景的专门优化以及 τ 跃升到 27，但这个差异化必须通过 head-to-head 实验建立，而不是通过省略引用。

批判 3 — 与量化基线的对比结构性地回避了质量维度实验设计问题

表 3 显示 HQQ int4 独立部署 135.84 tok/s，SubSpec 24.29 tok/s——慢 5.59 倍。论文辩护是量化「不可避免地损害质量」，但它自己也不报告任何准确率（批判 1），这场辩论两边都没有证据。更尖锐地说：SubSpec 构造替身层用的正是 HQQ 4-bit，也就是表 3 里那个跑 135.84 tok/s 的方案。如果 HQQ 4-bit 的质量损失在实践中可忽略（7B+ 模型上是社区普遍经验），SubSpec 的整个价值主张就要重新论证。这是全文最需要而最缺失的一组实验。

批判 4 — 𝒟=48 这个关键超参只有定性依据超参敏感性证据不足

𝒟 是 SubSpec 与所有前人方法的最大配置差异（EAGLE-2 用 6，小草稿用 32，SubSpec 用 48）。论文用图 6 说明「𝒟=48 时投机与验证时间近似相等」，但没有给出 𝒟 ∈ {8,16,24,32,48,64,96} 对应的 τ 与 tok/s 数值表。因此：(a) 无法判断吞吐-𝒟 曲线是否存在平台或相变点；(b) 无法判断 48 对不同模型尺寸是否都最优（32B 的 t_target 远大于 7B，理论最优 𝒟 应更大，但论文对所有模型都用 48）；(c) 逐 token 接受率 27.08/48 = 56.4% 意味着树的后 20 层多数时间做无用功，自适应深度的空间未被量化。

批判 5 — 统计显著性覆盖率约 1.6%可复现性风险

论文只在 MT-Bench 的一个配置上报告 5 次运行标准差（0.101 tok/s）。表 1 的 4 模型 × 5 基准 × 3–4 方法约 60 个格子中，只有 1 个有方差信息。这在卸载场景尤其危险：吞吐直接受 PCIe 争用、CPU 页缓存命中、DDR5 通道状态影响。跨基准 9.6×–15.3× 的 1.59× 跨度究竟是任务性质的真实差异还是运行噪声，现有数据无法区分。

批判 6 — 加速比的分母选择放大了效果，且摘要未加限定指标有效性

「12.5× speedup」的分母是 0.52 tok/s——纯 BF16 卸载，也就是消费级用户几乎不会真的采用的配置（真实用户会直接跑 4-bit 量化）。在「无损」这一强约束下这个对比是公平的；但摘要里没有任何限定语。若换成「相对 4-bit 量化部署」，SubSpec 是 0.18×（负加速）。系统论文的头条数字应当明示其 baseline 的现实性。

批判 7 — 架构覆盖与 2026 年本地部署的实际趋势背离适用范围

论文自述仅适用 dense 架构。但本地部署重心正快速转向 MoE（gpt-oss、Qwen3-MoE、DeepSeek-V2-Lite），恰恰因为 MoE 的「大参数、小激活」天然适合卸载。而 MoE 的卸载瓶颈是按需加载专家，替身层策略无法直接迁移——同期工作 DraftExpert（2026-07）为 MoE 端侧自投机专门设计，解码吞吐提升只有 1.45×（草稿接受率 84–87%，预取命中率 86–88%）。1.45× vs 12.5× 说明：SubSpec 的巨大加速比很大程度上是 dense 卸载这个特定病理场景的产物，而非方法普适性的证明。

批判 8 — 长上下文可用性未被评估，而这正是 τ 收益最大的方向实验设计问题

论文全程使用 static KV-Cache，长度 2048；同时自述最低显存 7.1 GB。两个约束叠加意味着 8GB 配置几乎没有空间容纳更长的 cache。但表 6 已证明长思维链场景的 τ 高达 41.68，是 SubSpec 收益最大的方向；而长思维链天然需要长上下文。论文没有给出 4K / 8K / 16K 上下文下的显存-吞吐曲线。方法的最佳应用场景恰好落在实验设置的盲区之外。

6.1 FlexGen — 2023.03，ICML 2023 Oral

解决了什么问题。第一个系统性回答「单张商用 GPU 如何跑 175B 模型」。用线性规划在 GPU/CPU/磁盘三级存储间搜索最优放置策略，配合 4-bit 压缩，实现 OPT-175B 在单张 16GB 卡上 1 token/s（有效 batch 144）。一句话：把「装不下」从二元问题变成了调度优化问题。

遗留了什么缺口。所有收益建立在大批量之上——优化的是吞吐而非延迟。有效 batch 144 意味着单用户等待时间不可接受。SubSpec 直接点名：FlexGen「通过大批量提升吞吐」但「不适用于延迟敏感的在线推理」。缺口：交互式单请求（batch=1）场景下的卸载没有任何加速手段。

核心论文的回应。SubSpec 全程 batch=1，正面攻击 FlexGen 回避的场景。加速来源不是并行化多请求，而是在单个请求内部制造并行性——一次目标前向验证 27 个 token，把 27 步串行解码折叠成 1 步。FlexGen 在请求间找并行，SubSpec 在序列内找并行，二者正交。

关键设计的传递。FlexGen 的「4-bit 权重压缩降低搬运量」在 SubSpec 里被重新定位——不再是压缩目标模型（那会有损），而是构造一个常驻 GPU 的草稿。同一个技术动作，目的从「减少传输」变成了「减少传输次数」。

6.2 Speculative Decoding（Leviathan et al.）— 2023.05，ICML 2023

解决了什么问题。确立「草稿-验证」范式：廉价近似模型 M_q 自回归生成 γ 个 token，目标模型 M_p 一次前向并行验证，通过修正采样保证输出分布与直接从 M_p 采样严格一致。一句话：在不改变输出分布的前提下，把串行解码的步数除以接受长度。

遗留了什么缺口。框架要求存在「与目标对齐良好的小模型」。实践中意味着必须有同族小尺寸检查点，或付出额外训练。SubSpec 的表述：现有方法「常依赖同族预训练权重，但要与自训练模型对齐仍需额外训练」，且「涉及草稿训练的方法通常只带来适度加速」。缺口：草稿模型的获取本身是未解决的供给问题，对齐度是它的核心瓶颈。

核心论文的回应。SubSpec 把「获取草稿模型」从寻找问题变成构造问题。目标模型自己就是原材料，量化算子（HQQ，数据无关，7B–70B 处理时间分钟级）就是构造函数。供给问题彻底消失。

关键设计的传递。Leviathan 的加速比解析式在 SubSpec §3.1 被直接继承并改写。SubSpec 的全部洞察，本质上就是把这个式子代入一组极端的硬件常数，然后老老实实读出结论——理论工具被正确复用的范例。

6.3 SpecInfer — 2023.05，ASPLOS 2024

解决了什么问题。把线性草稿序列升级为 token 树，一次目标前向并行验证树上所有候选路径。分布式推理 1.5–2.8× 加速，基于卸载的推理 2.6–3.5× 加速；随机解码验证成功率从 52–57% 提升到 96–97%。一句话：用树结构把单次验证的期望收益从「一条路径的长度」提升到「多条路径的最优长度」。

遗留了什么缺口。树仍由外部小模型生成，宽度受草稿质量限制。它证明了「更多候选 = 更高接受」，但没回答「候选质量的天花板在哪」。缺口：树结构解决了验证侧的并行度，没解决草稿侧的对齐度。

核心论文的回应。SubSpec 直接继承树验证，但把树推向深而窄（k=6, 𝒟=48）而非 SpecInfer 式的宽而浅。逻辑很清楚：树宽用来对冲草稿不准，树深用来榨取草稿很准时的长程收益。

关键设计的传递。token tree verification 被完整保留，但树的形状参数从「宽度主导」翻转为「深度主导」——同一机制在不同对齐度制度下的最优配置迁移。

6.4 EAGLE-2 — 2024.06，EMNLP 2024 Main（pp. 7421–7432）

解决了什么问题。发现草稿 token 接受率不只依赖位置、也依赖上下文，据此提出上下文感知的动态草稿树。三个模型系列、六个任务上最高 5× 加速，是 EAGLE-1 的 1.3 倍，且保持输出分布不变。一句话：让树的形状随上下文自适应，而不是用固定模板。

遗留了什么缺口。草稿模型是特征级单层自回归头，需要训练。它把 t_draft 压到极限，这在数据中心是正确方向。但接受长度天花板很低——SubSpec 表 1 实测 τ = 3.73–3.90，表 5 显示这个值在温度 0.2 与 1.0 之间几乎不动（3.42 vs 3.76），说明是架构性上限而非调参问题。缺口：在 t_target 极大的场景下，「轻草稿」这个优化方向本身是错的。

核心论文的回应。这是 SubSpec 最直接的靶子，也是它最有力的论据。表 1 显示 EAGLE-2 在 8GB 卸载下只有 2.89×，被朴素 1.5B 小草稿（5.70×）打败，更被 SubSpec（9.15×）拉开 3.17 倍。

关键设计的传递。EAGLE-2 的动态树被 SubSpec 有意放弃（改用固定 k=6, 𝒟=48 静态树），理由是动态 shape 阻碍 torch.compile。这是「继承其问题意识、拒绝其技术方案」的典型案例。

6.5 SpecExec — 2024.06，NeurIPS 2024

解决了什么问题。第一个把投机解码专门为消费级卸载场景设计的工作。观察到现代 LLM 的 token 概率分布高度尖锐，据此构造大规模候选缓存树，单次目标迭代最多产出 20 个 token；50B+ 模型上 4-bit 权重 4–6 tok/s、16-bit 权重 2–3 tok/s。一句话：把「概率分布尖锐」这个统计事实转化为大规模并行投机的可行性论证。

遗留了什么缺口。仍需独立的外部草稿模型，其显存与目标常驻层直接竞争。SubSpec 表 4 给出代价：SpecExec（budget=512）峰值显存 8.79 GB，超出 8GB 预算，吞吐只有 12.95 tok/s、τ=12.93。缺口：「大规模投机」思路正确，但草稿模型的显存与对齐度双重瓶颈没解开。

核心论文的回应。SubSpec 保留「深/大规模投机」的核心主张（𝒟=48 是其延续），用两个动作解开瓶颈：(a) 草稿不是外部模型而是目标的量化影子，显存可控且对齐度极高（τ 从 12.93 → 28.35）；(b) 固定 shape，torch.compile(max-autotune) 可用。结果 24.29 vs 12.95 tok/s，1.88× 优势且在预算内。

关键设计的传递。「概率分布尖锐 ⇒ 深树可行」被继承，并进一步用概率锐化主动制造尖锐性——从「利用一个既有性质」变成「主动强化这个性质」。

6.6 ML-SpecQD — 2025.03，arXiv（未被核心论文引用）

解决了什么问题。提出用 MXFP4 权重直接从 BF16 目标直铸得到草稿模型，无需单独预训练或对齐；并递归地用投机加速草稿自身生成（多级投机）。单级最高 2×，多级最高 2.72×。一句话：草稿模型可以是目标模型的一个纯粹的数值投影，不需要是另一个模型。

遗留了什么缺口。加速比（2–2.72×）远低于 SubSpec，原因很可能是没有针对卸载场景优化——在 GPU 常驻的正常场景下 t_target 不大，量化草稿的高 t_draft 无法被摊销。它证明了构造可行，但没找到这个构造真正有价值的硬件制度。

核心论文的回应。SubSpec 在同一构造上叠加层共享、KV 共享、深树、锐化、异步预取，并放进 PCIe 主导的场景，把 2.72× 变成 12.5×。但论文没有引用 ML-SpecQD，因此这个「回应」是本报告的重构，不是论文自述的定位。SubSpec 的真实贡献是「找到了量化草稿的正确应用制度并做深了工程」，而不是「首创量化草稿」。

7.1 演进的内在逻辑：草稿模型「来源」的三次迁移

这条线的推动力不是「算法越来越聪明」，而是硬件瓶颈位置的迁移倒逼目标函数重写。当瓶颈是 GPU 算力时，草稿必须便宜；当瓶颈是 PCIe 带宽时，草稿可以任意昂贵，只要它准。

阶段间的关键转折点：

• 转折一（2023.05）：从「优化单次前向」到「减少前向次数」——加速问题从算子层面搬到解码调度层面。
• 转折二（2023.05 → 2024.06）：从「一条草稿序列」到「一棵草稿树」——设计空间从 1 维（γ）扩展到 2 维（k, 𝒟）。
• 转折三（2025.09）：从「草稿是另一个模型」到「草稿是同一个模型的另一个精度」。草稿不再需要被「对齐」，它天生就是对齐的，误差只来自量化算子。KL 从 0.5899 降到 0.1176 是这个转变的量化印记。

社区关注点的转移：早期（2023）关注加速比本身；中期（2024）关注无损性与分布保真；当前（2025–2026）关注在给定硬件预算下的可部署性——注意 SubSpec 全部实验都用「程序限制显存为 8/12/24GB」这种消费级视角，而不是「在 A100 上快多少」。这个视角转移本身就是效率研究成熟的标志。

论文给出了加速比公式，但没有用它回过头审视自己的数据。本报告用表 1 的实测值反解隐含的分母项 𝒟·t_draft/t_target + γ：

数据来源：表 1，Qwen2.5 7B / MT-Bench / 8GB，T=0；分母 = τ ÷ 加速比。

1. SubSpec 的 τ 是 EAGLE-2 的 7.26 倍，但加速比只有 3.17 倍。差距被草稿开销吃掉了——分母从 1.291 涨到 2.960（2.29 倍）。这意味着 SubSpec 的 4-bit 全模型草稿并不「免费」，论文 §3.1 中「t_draft 在卸载场景可忽略」的定性论证在自己的数据上并不完全成立。
2. 单位 τ 的兑换率单调下降（0.775 → 0.465 → 0.338）。草稿越重，每多换一点接受长度就越贵。这是一条清晰的边际收益递减曲线，论文没有画出来。
3. 可量化的性能余量：如果 SubSpec 能把草稿开销压到 1.5B 小草稿的水平（分母 2.153）而保持 τ=27.08，加速比将达到 12.58×——比当前的 9.15× 高出 37%。这指向明确的后续方向：在替身层上再做一次投机（多级投机），或对替身层做结构化剪枝。收益上界可以事先算出来，而不是碰运气。

10.1 理论层面

（1）给定显存预算 B，最优的「投影算子 + 树形状」联合解是什么？可形式化为约束优化：在 mem(substitute) + mem(KV) ≤ B 下最大化 τ(bits, shared_layers) / (𝒟·t_draft(bits)/t_target + γ)。SubSpec 只采样了这个空间中的一个点。具体实验空白：固定 8GB 预算，扫描 bits ∈ {2,3,4,8} × shared_layers ∈ {0,4,8,11} × 𝒟 ∈ {16,32,48,64,96}，报告 τ 与 tok/s 的完整曲面。高价值低门槛——所需代码在 SubSpec 仓库里已有 90%。

（2）量化误差到接受长度的传递函数。表 5 给出两个锚点：Self（无量化）τ=34.50，4-bit τ=27.08，损失 21.5%，中间没有任何数据点。具体问题：τ(bits) 是平滑的还是存在相变？若 3-bit 处断崖下跌，4-bit 就是唯一可行点；若 3-bit 仍有 τ≈24，用省下的 2.5GB 换更长 KV-Cache 可能是净胜。

（3）自适应草稿深度的最优停止理论。实测逐 token 接受率 56.4%，树的后段大部分时间在做无用功。具体问题：给定当前草稿的置信度轨迹，最优停止规则是什么？形式化为 optimal stopping 问题，其解应能在不损失 τ 的前提下把 𝒟 期望值压到 30 以下，直接兑现上一节算出的 37% 余量。

10.2 工程与应用层

（4）无损性的经验验证协议缺失。整个投机解码文献都在声称 lossless，却极少给出验证协议。具体建议：定义标准检验——固定 seed，报告 (a) 逐 token 完全一致率，(b) T>0 下的输出分布 KL 估计，(c) 下游任务准确率差值的置信区间。这应成为该子领域的投稿要求。

（5）长上下文下的卸载投机基准缺位。现有工作几乎都用 2K 上下文。具体空白：在 8GB/24GB 预算下构建 ctx ∈ {2K, 8K, 32K, 128K} 的卸载投机基准，报告显存分配（替身 vs KV）、τ 随上下文的变化、KV-Cache 是否也需卸载后的二阶效应。表 6 已暗示长输出场景 τ 更高，但长输出 ≠ 长输入，两者尚未分离评估。

（6）MoE 卸载：替身层策略的迁移形式尚未确定。具体问题：MoE 的「替身」应该是 (a) 全部专家的低比特版本，(b) 高频专家全精度 + 长尾专家低比特，还是 (c) 一个蒸馏出的稠密替身？三者在显存/τ/预取命中率上的 trade-off 完全未知。建议实验：在 DeepSeek-V2-Lite / Qwen3-MoE 上做三种替身构造的 head-to-head，统一 8GB 预算与 PCIe 4.0 硬件。

（7）SubSpec vs ML-SpecQD 的 head-to-head 是最紧迫的空白。两者构造高度相似，加速比却相差 4.6 倍（2.72× vs 12.5×）。这个差距有多少来自「卸载 vs 常驻」，多少来自四项工程优化，多少来自 HQQ vs MXFP4 的量化质量差异？建议：相同硬件、相同显存预算、相同目标模型下三方对比（ML-SpecQD / SubSpec / SubSpec-minus-optimizations）。在这个对比出来之前，SubSpec 的新颖性主张只能算部分成立。

（8）SubSpec 与 4-bit 直接部署的质量-速度帕累托前沿。值得单独作为一篇短论文：在 GSM8K / HumanEval / MMLU / MT-Bench 上报告 BF16、HQQ-int4、AWQ-int4、SubSpec 四点的（准确率，tok/s）坐标。如果 HQQ-int4 准确率损失小于 1pp 而速度是 5.59 倍，SubSpec 的适用场景就要收窄到「质量绝对不能妥协」的少数领域。这个实验的结果会直接决定这条技术路线的市场规模。

10.3 新兴方向

（9）多级替身投机。用 2-bit 替身给 4-bit 替身做草稿，4-bit 替身给 BF16 目标做草稿。ML-SpecQD 已证明多级可行（2× → 2.72×，+36%）。具体目标：把分母从 2.960 压到 2.2 以下，兑现 12.58× 的理论上界。

（10）替身层的「按需精度」。不同层对量化的敏感度差异极大。具体问题：按层敏感度分配 2/4/8-bit（总显存不变），τ 能提升多少？这是一个混合精度搜索问题，与 SubSpec 正交性很好。

（11）跨请求的替身共享与多租户。SubSpec 全部实验 batch=1。在小规模多租户场景（家用服务器服务 2–8 用户），替身层可被所有请求共享，目标层的 PCIe 搬运可被批量摊薄。具体问题：随 batch 增大，SubSpec 的优势在何处消失？这个交叉点决定了它与 FlexGen 式方案的分界线。

（12）能耗维度。所有相关工作都以 tok/s 为唯一指标，但消费级/边缘场景下 J/token 同样关键。PCIe 传输的能耗成本远高于 GPU 计算；SubSpec 减少了 27 倍的传输次数，能耗收益可能比吞吐收益更大。具体空白：目前没有任何一篇卸载投机论文报告能耗数据。

Kimi Linear: An Expressive, Efficient Attention Architecture（2025.10，arXiv）
线性注意力与全注意力的混合架构，来自生产级实践。值得看是因为它给出了混合比例的工程判据，而非纯学术消融。
arXiv 2510.26692

MiniMax Sparse Attention（2026.06，arXiv）
稀疏注意力的又一次生产级验证，与 Kimi Linear 构成「线性 vs 稀疏」两条路线的对照。适合与本期核心论文并读——同样是效率问题，一个从架构改，一个从解码调度改。
arXiv 2606.13392 · HF Papers

GLIDE: Guided Layerwise Hybrid Attention for Efficient LLM Inference（2026.07，arXiv）
逐层决定用哪种注意力，而非全局固定混合比例。与 SubSpec 的「逐层决定用 BF16 还是 4-bit 替身」在方法论上同构，都是层粒度的异构资源分配。
arXiv 2607.24788

Hierarchical Sparse Attention Done Right: Toward Infinite Context Modeling（2026.07，arXiv）
标题里的 "Done Right" 暗示对前人层次化稀疏注意力的系统性纠错，这类论文通常包含高质量的失败分析。
arXiv 2607.02980

EAGLE-3: Scaling up Inference Acceleration via Training-Time Test（2025.03，NeurIPS 2025）
EAGLE 系列最新一代。本期核心论文只对比到 EAGLE-2；EAGLE-3 在卸载场景下的表现是一个开放问题，也是复现 SubSpec 时值得补的一组基线。
arXiv 2503.01840 · OpenReview · Code

KVzip: Query-Agnostic KV Cache Compression with Context Reconstruction（NeurIPS 2025 Oral）
3–4× 显存压缩、2× 延迟下降的查询无关 KV 压缩。与 SubSpec 高度互补——SubSpec 的显存瓶颈之一正是 KV-Cache（static 2048 的限制），叠加 KVzip 可能直接解开批判 8 指出的长上下文问题。
NeurIPS Poster · Code

DraftExpert: Expansion-Aware Self-Speculative Decoding for End-Device MoE Inference（2026.07，arXiv）
本期核心论文自述 MoE 空白的直接后继。1.45× 与 SubSpec 的 12.5× 形成强烈对比，是理解「dense 卸载的病理性有多特殊」的最佳参照。
arXiv 2607.24434

TileLang: Bridge Programmability and Performance in Modern Neural Kernels（ICLR 2026 Oral）
在 H100 上相对 Triton 最高 5× 加速的 kernel DSL。SubSpec 严重依赖 torch.compile(max-autotune) 且明确把「动态 shape 阻碍编译」列为竞品缺陷——kernel 层工具链的进步会直接改变这类系统论文的设计约束。
ICLR 2026 Oral

1. 未获取的一手材料：OpenReview 上的评审意见与 rebuttal（页面被人机验证拦截）、GitHub 仓库 README 正文（抓取受代理限制）。因此本报告无法核实审稿人提出了哪些质疑、作者如何回应，也无法核实代码的实际可复现程度。第五节的批判全部基于论文正文，可能与评审中已被讨论的点重叠。
2. 表格数据的获取方式：SubSpec 的全部数值来自对 arXiv PDF v2 的结构化抽取。过程中曾出现同一数字的不同读数（如 EAGLE-2 加速比 2.89× vs 2.91× vs 3.20×），本报告通过定向复查确认了口径差异（MT-Bench 单列 vs 五基准均值列 vs 不同目标模型），最终采用的数字均已标注表号与配置。仍不排除个别数字存在抽取误差，引用前建议核对原文。
3. 图 6（草稿深度扫描）无法读取数值：只能引用其文字说明。10.1(3) 的相关论断因此是推断而非实测。
4. 索引未更新：本次为云端定时任务，用户桌面端不可达，ml-report-index.md 既未读取也未写回。本期条目建议手工补记为：
   2026-08-07 | 效率与系统 | SubSpec: Speculate Deep and Accurate | NeurIPS 2025 | 卸载场景下草稿模型应最大化对齐度而非速度；用目标自身 4-bit 替身作草稿， τ 从 3.7 提到 27–42，9.15×–13.76× 加速
   相关工作已覆盖（14 天内不重复）：FlexGen、Leviathan SD、SpecInfer、EAGLE-2/3、SpecExec、ML-SpecQD、Dovetail、DraftExpert、KVzip。