你让一个 AI 助手连续工作很久：读文档、调用工具、查看结果、修改计划。到了最后，它不仅要记住前面的全部过程，还要根据任务成败复盘并调整策略。前一件事已经开始迈向百万词元上下文；后一件事却常停在 256K 词元或以下。
词元（token）是模型处理文字、代码和工具输出时切分出的基本单位。上下文长度，则是模型一次能放进“工作记忆”的词元数量。两百万词元意味着一段极长的交互历史。模型在推理时读得下，不等于训练时也改得动：训练还要保存大量中间结果，以便反向计算每个参数该怎样调整，内存压力会陡增。
LongStraw 想缩小这道差距。论文把它定义为一套“架构感知”的执行栈：它会根据模型结构重新安排计算和状态保存，让百万词元级强化学习后训练有机会装进固定的 GPU 预算。这里的证据全部来自 2026 年 7 月 16 日提交的 LongStraw 论文，尚无独立信源交叉验证；更重要的是，论文目前证明的是执行容量，不是一次已经正确完成并稳定收敛的两百万词元 RL 训练。
真正难的不是读完，而是回头改
强化学习后训练发生在预训练之后。模型先学会语言，再完成任务、获得奖励，并根据结果调整行为。可以把它理解为做完整套练习后按得分纠正解题策略。交互轨迹越长，训练时需要处理的观察、工具输出、文档和先前决策就越多。
LongStraw 以 GRPO（Group Relative Policy Optimization，组内相对策略优化）来实例化这套系统。GRPO 会让模型针对同一个问题生成一组回答，再依据组内的相对奖励更新策略。它通常不需要额外训练一个价值模型或“评论家”，但仍要由规则、验证器或奖励模型给出奖励。
麻烦在于，这组回答通常共享同一段很长的 prompt——也就是模型收到的共同输入。若每条回答都把这段输入连同训练所需的全部中间结果保留一遍，就像几位学生共用一本两百万字的题册，却要求每人都复印整本题册并保存所有草稿。组越大，显存越容易被共同部分挤满。
先保存必要状态，再逐条重放
LongStraw 的关键做法，是把共同输入与后续回答分开处理。
系统先在不启用 autograd 的情况下执行共享 prompt。autograd 是自动求导机制：训练时，它会记录计算过程，方便之后沿着这条路径反向计算梯度，也就是参数应当调整的方向和幅度。不启用它，意味着系统不为整段超长 prompt 保留一张庞大的实时训练计算图。
LongStraw 只留下后续词元继续生成时必需的、与具体模型结构有关的状态。随后，它把较短的 response 分支——模型针对共同输入生成的不同回答——一次重放一条，并完成相应计算。
还是用题册来类比：系统不再让每名学生都带着整本题册和全部演算纸进入批改环节，而是先读完公共题目，只保存后面答题确实需要的信息，再依次调出每份答案处理。
代价也很直接。部分计算需要重放，因此时间会增加。LongStraw 用更多重放时间，换取更小的实时训练图和更低的峰值内存占用。这不是消灭计算成本，而是重新安排“何时算、何时存”。固定 GPU 预算的意义也正在这里：系统不能靠无限增加显卡解决问题，只能更精细地调度数据、计算和中间状态。
论文已把这条路径适配到两种结构不同的模型：Qwen3.6-27B，以及 GLM-5.2。前者被论文描述为混合循环与全注意力架构，后者则采用压缩注意力和混合专家结构。所谓“架构感知”，就是系统不能假设所有模型都以同一种方式保存长期状态，而要针对各自结构留下后续计算真正需要的部分。
两组实验说明了什么？
在 8 张 H20 GPU 上，LongStraw 对 Qwen 完成了 grouped scoring 和 response backward。前者是对同一 prompt 下的一组回答进行评分，后者是沿回答部分反向计算。实验覆盖 group size 为 2 和 8 的任务，序列位置总量达到 2.1M。
值得注意的是，group size 从实验中的较小设置增至较大设置时，论文报告的 peak allocated memory——运行期间实际分配显存的峰值——只增加了 0.21 GB。这个结果符合 LongStraw 的设计目标：回答数量增加时，不必为每条分支重复长期保留共享 prompt 的完整训练图。不过论文摘要没有给出基线显存、两种设置各自的完整显存数字及其他显存口径，因此 0.21 GB 更适合视为特定条件下的容量展示，不能外推成普遍比例。
论文还报告，一项独立压力测试达到 4.46M positions。这里的 positions 是实验统计的序列位置，不能直接写成“完成了 446 万词元 RL 训练”，也不应与另一项实验中的 2.1M-token prompt 混为同一口径。
另一组验证使用 32 张 H20 GPU。LongStraw 针对一个 2.1M-token prompt，在 GLM-5.2 的全部 78 层跑通了端到端执行路径。它说明这套编排不只停留在局部组件，也能跨越该模型的完整层数。但两组结果使用的硬件规模不同：Qwen 相关结果是 8 张 H20，GLM-5.2 验证则是 32 张 H20。因此，“固定 GPU 预算”指各项实验在给定资源内寻找执行办法，并不代表所有结果都由同一数量的 GPU 完成。
为什么这一步值得关注？
长上下文的发展过去更容易在推理端被看见：模型能读进多少材料，回答时能引用多远之前的信息。LongStraw 把问题推进到后训练端。对于会连续观察环境、调用工具并积累决策的 AI agent——也就是能分步骤执行任务的 AI 系统——只在部署时读得更长，并不能自动保证它学会利用如此漫长的轨迹。
LongStraw 最有意义的地方，不是宣布“两百万词元 RL 已经解决”，而是展示一种系统方向：共享的超长历史不必始终挂在训练图上；可以保存模型后续真正需要的状态，再逐条处理短回答分支。它把长轨迹 RL 的瓶颈，从单纯追求更多硬件，转向计算图、状态和重放次序的重新设计。
局限与未知
- 论文明确说，现有实验验证的是执行容量，而非完整 RL 训练的正确性。被捕获的 prompt 状态已经 detached，也就是与原训练计算图断开；部分分布式前向计算和梯度组合路径仍未完成。
- 因此，目前不能据此断言系统能稳定收敛、产生有效的策略提升，或已经完成两百万词元规模的端到端 RL 训练。
- 2.1M positions、2.1M-token prompt 与 4.46M positions 来自不同设置和统计口径。它们共同说明系统能够承载很长的执行路径，但不能合并成一个更醒目的“最长训练纪录”。
LongStraw 跨过的是一道系统容量门槛，而不是训练有效性的终点。它让“两百万词元如何进入 RL 后训练”从一个容易爆显存的设想，变成了已经跑通关键执行路径的问题。下一步仍要回答：断开的 prompt 状态如何正确参与梯度更新，尚缺的分布式路径如何补齐，以及完整训练最终是否真的让模型学得更好。