你让一名助理替主笔续写一份越来越长的工作日志。助理每写一句，都要从第一页重新翻到最后一页。日志短时，这样确实省时间；写到几十万页，助理光翻资料就可能比主笔直接写更慢。
这正是长上下文里的投机解码难题。投机解码让便宜的草稿模型先猜出若干 Token——也就是模型处理文本时的基本单位——再由昂贵的目标模型并行检查。连续猜中的部分可以直接采用。可一旦历史不断增长，草稿模型也要读取和保存大量上下文，加速收益便可能被成本吃掉。
两项新工作从不同方向提出同一个判断：草稿模型未必需要亲自重读整段历史。目标模型已经处理过上下文，其内部状态可以把历史信息传给草稿模型。一个方案改造推理过程，另一个方案重新设计并训练草拟组件。两者方向相近，但不是同一种方法，实验结果也没有相互复现。
把助理的参考页数固定下来
Aref Jafari 等人的论文《Long-Context Drafting Does Not Require Long-Context Drafters》处理的是一个直接问题：现成的短上下文草稿模型，能否原封不动地用于超长上下文？
通常的答案是另做一个长上下文草稿模型，或者训练、微调相关组件。论文认为不一定需要。它观察到，实际使用的草稿模型会读取目标模型生成的隐藏状态——可以把它理解为大模型读完上下文后留下的一组内部摘要。远处历史的信息已经由目标模型处理并传了过来，因此草稿模型不必再用自己的注意力机制完整扫描一遍。
作者冻结已有的短上下文草稿模型，也就是不修改权重，只在推理时加入两个机制。
第一个机制限制草稿模型能够看到的 attention cache。这里的 cache 是模型为避免重复计算而保存的中间结果；限制可见范围，相当于只给助理最近几页材料，让其每次草拟的成本不再随整份档案一起增长。
第二个机制重新映射 rotary position indices。它们是模型辨认 Token 所处位置的一套编号。上下文远超训练长度后，位置编号也会跑出模型熟悉的范围；论文把这些编号重新落回训练范围内。作者还给出证明：在特定条件下，统一平移位置编号不会改变草稿模型的计算。
这两个机制缺一不可。据论文报告，拿掉缓存限制或位置重映射中的任意一个，随上下文增长仍保持平坦加速效果的能力都会消失。
保住的是加速曲线，不是固定倍数
这项工作的实验跨越三个目标模型—草稿模型组合和五个语料库。作者称，一套部署在 vLLM 一侧的统一配置，可以覆盖从 4,000 到 200 万 Token 的上下文；短上下文下付出的加速损失最多为 0.16x。不过，材料没有给出这一表述的完整定义，因此不能把它解释成“最终速度只有 0.16 倍”，更稳妥的理解是作者所说的加速收益损失指标。
论文最重要的限定也写得很清楚：它要保持的是加速曲线的平坦程度，而不是承诺某个固定加速倍数。换句话说，一个冻结的草稿模型在短上下文时原本能提供多少加速，作者称这种效果可以维持到 200 万 Token；但它究竟快多少，仍取决于具体组合。
而且，加速并非无条件成立。每生成一个有效 Token 所花的投机成本，必须低于匹配条件下目标模型独自生成的成本。否则即使草稿质量没有继续恶化，整套流程也未必更快。
DLite干脆不保存历史
Jiaming Xu 提出的 DLite 面向 agentic workloads，也就是模型反复对话、调用工具并把观察结果持续追加进上下文的智能体任务。这类上下文不仅长，还一直变化。论文称，现有草稿模型在这些任务中的接受长度最多会下降 80%。接受长度表示一轮草稿里有多少连续 Token 通过目标模型验证；它越短，一次昂贵检查换回的有效输出通常越少。
DLite 将自己称为 history-free speculative decoding，即“无历史投机解码”。它不显式维护完整历史，而是直接复用目标模型的上下文隐藏状态，在局部范围内预测后续 Token。为了恢复同一批草稿 Token 之间的先后依赖，它加入一个轻量的 sequential head；这可以理解为一个按顺序整理局部候选的小组件。由于整体结构不同于普通草稿模型，作者还设计了两阶段训练策略。
这点必须与前一项工作分开看：前者冻结现成的短上下文草稿模型，只改变推理时的缓存与位置处理；DLite 则包含新的顺序预测组件和专门训练，不能笼统概括成“无需训练”。
DLite 论文称，它在通用、长上下文和智能体任务上取得“2-6 acceptance length”，并比 DSpark 最多提高 70%。但现有材料没有说明“2-6”究竟是接受长度为 2 到 6，还是缺失了倍数符号，因此不宜把它改写成明确的倍数结论。70%也是作者报告的最高结果，而非跨场景的统一提升。
为什么这条路线值得看
这两项工作的共同价值，不只是替一个解码器省掉一些缓存。它们重新划分了任务：目标模型负责理解完整历史，草稿模型只利用目标模型已经提炼出的信息，完成便宜的局部预测。
如果这个分工在更多模型和真实工作流中成立，投机解码就不必让两个模型都背着同一份不断增长的档案。超长文档和持续运行的智能体，正是这种成本最容易滚大的场景。两篇论文因此共同打开了一条路线：与其打造一个同样擅长长上下文的小模型，不如先问，小模型是否真的需要再次阅读全部历史。
局限与未知
- 两项工作的性能数字都来自各自论文，目前材料没有提供独立复现；“到 200 万 Token”“最多下降 80%”和“最多提升 70%”都应视为作者自报的边界或最佳结果。
- S1强调加速随长度保持稳定，不等于保证固定加速倍数；其 0.16x 指标的精确定义仍需结合正文表格核对。
- DLite 的“2-6 acceptance length”存在单位或符号歧义；现有材料也不足以判断它在不同智能体流程中的成本分解。