推理系统正接近百万 Token 上下文，但强化学习后训练通常仍停留在 256K 或更短，再依赖部署时的长度泛化。对 AI 智能体而言，这个落差尤其明显：观察、工具输出、文档和历史决策会沿轨迹持续累积。LongStraw 试图解决的不是模型能否读取长上下文，而是固定 GPU 预算下，训练执行栈能否承载百万 Token 级轨迹。
核心做法：把长提示与短分支拆开
LongStraw 以 GRPO 为具体实现。它先对组内共享的长提示执行不带自动微分的计算，只保留后续 Token 所需、且与模型架构相关的状态；随后不让多个响应分支同时驻留在训练图中，而是逐个重放较短的响应分支，完成评分和反向传播。
这个设计本质上是用额外计算时间换峰值内存：共享提示不建立完整梯度图，响应分支则串行重放，从而缩小任一时刻存活的训练图。它并非通用的上下文压缩算法，而是针对混合循环、全注意力以及压缩注意力等架构特征设计的执行方案。
数百万位置已经能跑，但验证范围有限
作者在混合循环与全注意力架构的 Qwen3.6-27B 上完成实现。使用 8 张 H20 时，组大小为 2 和 8 的 Qwen 分组评分与响应反向传播都能运行到 210 万个位置；组大小从 2 增至 8，峰值已分配内存只增加 0.21 GB。另一项压力测试达到 446 万个位置。
在采用压缩注意力、混合专家架构的 GLM-5.2 上，作者使用 32 张 H20，验证了 210 万 Token 提示词贯穿全部 78 层的端到端 LongStraw 执行路径。这说明方案不只适用于单一注意力结构，但两组实验的 GPU 规模并不相同，不能据此直接比较模型效率。
我的判断
LongStraw 的价值很具体：它把超长上下文强化学习从依赖部署时泛化，推进到可以实际验证训练执行容量的阶段，对长轨迹智能体尤其相关。代价也很明确，串行重放会增加运行时间。
更重要的边界是，论文当前证明的是执行容量，不是完整训练正确性。摘要明确指出，捕获的提示状态被分离，部分分布式前向与梯度组合路径仍未完成充分验证。因此，它更像一套有说服力的系统原型，还不能直接视为已经可用于稳定训练百万 Token 策略模型的成熟方案。