推理端长上下文赛道的火药味，已经到了呛鼻的程度。Claude Sonnet 4.6全面开放100万Token窗口，DeepSeek V4和Qwen3.5-Plus紧随其后，Gemini 3.1 Pro把百万级上下文做成了标准配置。模型正在学会一口气读完一本厚书。
但翻开RL后训练那一面，时间仿佛被冻结了。
大多数大模型的RL训练，上下文长度仍然卡在128K到256K Token。业界走得最远的DeepScaleR，在1.5B模型上通过迭代延长，也只把训练上下文推到了24K。训练和推理之间，横亘着一条越来越宽的鸿沟。
这个鸿沟的根源不在算法，而在内存。训练必须对同一段历史条件生成多个响应，再逐条打分、反向传播。二次注意力的计算量和长生命周期的反向状态，让GPU显存成为不可逾越的墙。每当有人想突破训练上下文长度，行业的默认答案是加卡，加更大的集群，加更多的预算。
但MindLab和复旦大学的合作团队，给出了一个不太一样的答案。
他们刚刚提交的论文LongStraw，用8张NVIDIA H20 GPU，一款出口管制合规的PCIe中端卡，96GB显存，就跑通了超过200万Token的GRPO强化学习训练。在极端压力测试下，甚至推到了446万Token，距离OOM只有一步之遥。
不靠堆卡，而是靠算力效率的极致压榨。
现象层：裂谷正在变宽
2025年到2026年，大模型上下文窗口的军备竞赛进入了白热化阶段。Google的Gemini系列率先在百万级上下文上量产，Claude Opus 4.6和Sonnet 4.6全面开放100万Token，DeepSeek V4、Qwen3.5-Plus也都迈过了百万门槛。推理端的技术栈，KV Cache优化、Flash Attention、上下文并行，已经为长序列推理做好了准备。
但翻开RL后训练那一面，景象完全不同。
当前主流的大模型RL训练，上下文长度普遍卡在128K到256K Token。业界最激进的DeepScaleR也只把训练上下文推到了24K。即便是专门研究长上下文推理的LongR框架，其主要实验也集中在相对较短的长度上。
为什么训练和推理的差距如此之大？因为内存账本根本不是同一个量级。
推理时，模型只需要前向传播一次，生成一组Token，计算完成后KV Cache可以被释放或复用。但RL训练，尤其是GRPO这类Group-based策略优化，要求模型对同一段Prompt生成多个不同的响应，然后对这些响应逐条评分、反向传播、更新参数。训练显存的占用量大致等于Prompt一次前向造成的显存，加上每条响应反向传播的显存乘以Group大小再乘以响应平均长度。当Group大小为8时，仅反向传播的显存开销就是同长度推理的8倍以上，再加上二次注意力的计算复杂度和更长的梯度生命周期，训练上下文每增加一倍，显存压力呈超线性增长。
所以行业的标准答案是加GPU。用更多的卡分摊显存压力，用更大的集群支撑更长的训练序列。
但MindLab团队做了一个反直觉的选择。不是加卡，而是重新设计执行流程。
分析层：LongStraw的断舍离
核心洞察：状态生命周期才是关键
LongStraw最核心的洞察，用一句话概括：评估共享Prompt时不需要自动微分。
在标准的GRPO训练中，模型先读取一个长Prompt，比如200万Token，然后在这个Prompt条件下生成多个响应。传统做法是把整个Prompt和所有响应都放在自动微分（Autograd）的计算图中，一次性完成前向和反向。200万Token的Prompt加上8个响应，每个响应几千到几万Token，整张计算图动辄数百万节点，全部驻留在显存中等待反向传播。这是显存爆炸的直接原因。
LongStraw的做法是把Prompt和响应的计算图拆开。
第一步，Prompt前向一次完成，不追踪梯度。模型对长Prompt做一次完整的前向传播，但直接detach掉梯度追踪，只保留必要的中间状态，包括KV Cache和MLA状态等。第二步，响应逐条回放，只追踪梯度。对每一条生成的响应，从Prompt的末端状态重新开始，在自动微分下单独前向和反向。第三步，用完即弃。每条响应处理完成后，立即释放其计算图，下一条响应从共享的Prompt状态重新开始。
这个Capture Once, Replay the Suffix的设计，将训练计算图从完整Prompt加所有响应压缩为单条响应的大小。效果有多显著？Group大小从2增加到8时，峰值显存仅增加0.21GB。0.21GB，在动不动就80GB显存占用的训练场景里，几乎可以忽略不计。
两种架构，一套逻辑
LongStraw的另一个亮点在于，它不是针对某一种模型架构的特制方案，而是同时适配了两种截然不同的模型家族。
Qwen3.6-27B是一个混合架构，部分层使用循环神经网络（Hybrid Recurrent），部分层使用全注意力机制（Full Attention）。在8张H20上，LongStraw完成了Group大小为2和8的2.1M Token分组评分和响应反向传播。
GLM-5.2则是一个使用压缩注意力（MLA/DSA）的混合专家模型（MoE），架构复杂得多，有78层。在32张H20上，LongStraw验证了覆盖全部78层的端到端2.1M Token Prompt执行路径。
两种架构的显存瓶颈完全不同。Qwen的瓶颈在密集注意力层，GLM的瓶颈在MoE路由和专家计算。但LongStraw用一套统一的设计思路，状态生命周期管理加物理所有权控制，同时解决了两个问题。论文提出的核心结论是：状态的生命周期和物理所有权，才是决定RL训练上下文极限的关键因素，而非单纯的注意力稀疏性。
固定预算下的极限边界
LongStraw最令人印象深刻的数字，来自它的压力测试结果。
在8张H20的预算下，团队将Qwen模型的执行推到了4,456,448个Token位置，接近450万Token。在4,538,368位置时仍然通过，再多一个4096 Token的chunk就直接OOM了。这个边界几乎精确到了个位数。
论文提出了一个概念：固定预算执行信封（Fixed-Budget Execution Envelope）。不是这个模型能训练多长，而是在这几块卡上，最长能跑多长。这是一个更诚实、也更实用的衡量标准。
相比之下，市面上跑百万级推理上下文通常需要H100或H200集群，单张H100的价格在2.7万到4万美元之间，8卡系统动辄20万美元以上。而H20的定位是出口管制合规的中端卡，价格远低于H100。LongStraw用8张中端卡打出了远超预期的结果，这本身就是对算力堆砌逻辑的一次有力反驳。
清醒的局限
需要指出的是，LongStraw目前的实验验证的是执行容量（Execution Capacity），而非完整的训练正确性（Training Correctness）。
论文明确说明，截取的Prompt状态是detached的，不再追踪梯度，部分分布式前向和梯度合成的路径尚未完整实现。这意味着，目前的LongStraw可以跑通一个2.1M Token的GRPO训练流程，但梯度更新的完整性和一致性还需要进一步验证。
此外，LongStraw的单条响应回放机制虽然大幅降低了显存峰值，但代价是计算时间的增加。每条响应需要单独回放前向，而不是一次并行完成。这是典型的用时间换空间策略，在训练吞吐量上会有折损。不过，考虑到8张H20就撑起了百万级训练，性价比的账怎么算都划算。
结论与展望：谁最需要LongStraw？
AI Agent训练是最大的受益者
论文在引言中就点出了最紧迫的应用场景：AI Agent。
Agent的长期推理轨迹中，每一步的观察结果、工具输出、环境反馈和先前的决策都在不断累积。在长Agent轨迹上做RL训练，天然需要处理数十万到数百万Token的上下文。如果训练上下文始终卡在256K，Agent的RL训练就只能在短视范围内优化，无法真正学会长程决策。LongStraw为Agent训练打开了一扇门：在固定预算下，把训练上下文推到Agent实际需要的长度。
算力民主化的新信号
LongStraw最深远的意义，可能不在技术本身，而在于它传递的信号。
过去两年，AI领域的算力集中化趋势愈演愈烈。训练100万Token的RL需要多少计算资源？通常的回答是几百张H100，以及几百万美元的预算。这让长上下文RL训练几乎成了大公司和顶级实验室的特权游戏。
LongStraw证明了一个反直觉的事实：在算法工程足够聪明的前提下，中端卡也能做百万级长上下文训练。8张H20的硬件成本，不到一张H100 B200集群费用的零头。这不仅仅是省钱的问题。它意味着更多研究团队、更小的实验室、甚至独立开发者，都有可能参与到长上下文RL的训练探索中来。当参与者的基数扩大，创新的概率也随之提高。
留给行业的追问
LongStraw目前还只是一个执行容量的证明。它证明了在固定GPU预算下，长上下文RL训练在工程上是可行的。但完整的训练正确性验证、梯度一致性的闭环、以及执行容量到训练收益的转化，还需要后续工作来补齐。
另一个值得追问的问题是：Capture Once, Replay Suffix这个思路，是否可以推广到PPO、DPO等其他RL算法？如果答案是肯定的，LongStraw的影响将远超GRPO这一个场景。
但即使只站在当下，LongStraw也已经完成了一件事：它让人们意识到，大模型训练的算力效率可能比算力规模更值得关注。
当所有人都盯着加卡这个答案时，MindLab选择重新审视问题本身。
8张H20，200万Token。有时候，少就是多。
快报