千卡 GPU 才跑得动的长上下文 RL，被一家中国实验室用 8 张 H20 打穿了

2026 年 7 月 17 日，Mind Lab（Macaron AI 旗下研究实验室）在 HuggingFace 和 arXiv 上发布了 LongStraw——一个将 GRPO 强化学习后训练推到 210 万 token 上下文、却只需要 8 张 H20 GPU 的执行栈。论文登顶当日 HuggingFace Papers 榜首（115 赞），随后被 AI 社区核心策展人 @_akhaliq（51 万关注者）转发扩散。

推理能看 100 万 token，RL 只能训 25 万

AI 社区有一个很少被公开讨论的事实：模型的推理上下文和 RL 训练上下文之间存在一个数量级的差距。

今天主流推理系统已经可以处理百万 token 级别的上下文——Kimi K2 支持 128K，Google Gemini 冲到 200 万，各家都在往更长的方向卷。但 RL 后训练——也就是通过强化学习让模型在长上下文中学会推理、决策——至今被卡在 25 万 token 以内。绝大多数实验室做 RL 微调时，上下文窗口不超过 256K，部署时的长上下文能力依赖的是"长度泛化"（length generalization），而不是真的在长上下文中训练出来的。

这个差距对 AI Agent 是致命的。Agent 的执行轨迹天然冗长——工具调用的返回、文档检索的结果、多轮决策的历史、环境反馈，这些信息在一个任务中轻松累积到几十万甚至上百万 token。如果 RL 训练上下文跟不上推理上下文，Agent 在真实长轨迹任务中就只能靠"蒙"，而不是靠"练"。

LongStraw 做的事情，就是把这个差距填上。

8 张 H20，210 万 token，全开源

LongStraw 的核心数字就三个：

8 张 H20 GPU——不是 H100，不是 B200，就是 H20
210 万 token 位置——在 Qwen3.6-27B 上完成完整的 GRPO 打分和梯度回传
开源——代码已发布在 GitHub（），Apache 2.0 协议

作为对比：此前达到 100 万 token 上下文训练的工作需要数千张 GPU。LongStraw 把门槛直接压到了原来的零头。在一项压力测试中，LongStraw 甚至在 8 张 H20 上将执行边界推到了 446 万 token 位置——是目前公开记录中最长的 RL 训练上下文。

在 32 张 H20 的配置下，团队进一步验证了 GLM-5.2 全部 78 层的端到端执行路径，在 TP1/CP32/EP32 的并行布局下跑通了 210 万 token prompt 的前向捕获和响应回放。

不过，论文用非常审慎的口吻加了一个重要的限定："这些实验建立的是执行能力（execution capacity），而非完整的训练正确性（training correctness）。" 换句话说，系统能在这些配置下跑起来、跑完、不 OOM，但不等于训出来的策略一定比短上下文基线更好。

LongStraw 的秘密不在算力，在"记忆管理"

LongStraw 的核心思路，用一句话概括就是：把"全村共享"的 prompt 只算一遍，后面每个 response 分支自己跑自己的，互不拖累。

具体来说，GRPO（Group Relative Policy Optimization）的标准流程是：同一个 prompt 喂给模型，生成多个 response（一组通常 2-8 个），然后对每个 response 打分、回传梯度。按照常规做法，每次回传都需要在显存中同时保留完整的 prompt 计算图和当前 response 的计算图。prompt 越长，显存就越炸。

LongStraw 的做法分三步：

共享 prompt 只做一次前向，不建计算图。 Prompt 的前向传播在 torch.no_grad() 下完成，只保留后续 token 推理所需的模型状态（MLA/DSA 隐状态、KV cache 页），丢掉所有中间激活。
状态常驻，分支轮流回放。每个 response 分支一个接一个地复用常驻的 prompt 状态，在 autograd 下完成自己的前向和反向。每次反向只涉及当前分支的 LoRA 梯度，不重新跑整条 prompt。
分组越多，显存几乎不涨。团队报告，将 GRPO 分组数从 2 增加到 8，峰值显存仅增加 0.21 GB——几乎可以忽略不计。

这套"捕获一次、分支轮流回放"的设计，本质上是用重放时间换显存空间。论文没有报告端到端吞吐量，但暗示了额外的重放开销是存在的——这是一个诚实的 trade-off。

LongStraw 在两个架构迥异的模型上做了验证：Qwen3.6-27B（混合循环注意力 + 全注意力）和 GLM-5.2（压缩注意力 + 混合专家）。跨架构的可迁移性意味着这套方案不是为某个模型量身定做的 hack，而是一套有通用性的系统设计。

7 个月的实验室，20 人的论文，两套模型架构

Mind Lab 是 Macaron AI 旗下的前沿研究实验室，2025 年 12 月正式对外亮相。Macaron AI 此前的公开动作包括发布 749B MoL（Mixture of LoRA）的 Agent 模型 Macaron-V1-Preview，以及与 NVIDIA、字节跳动 VeRL 团队合作将 LoRA RL 推进到万亿参数规模——当时就宣称做到了全参数训练约 10% 的 GPU 开销。

LongStraw 的论文署名 20 人，第一作者 Changhai Zhou（周昌海）来自复旦大学，通讯作者包括 Mind Lab 的 Andrew Chen 和 Pony Ma（马晓腾，Xiaoteng Ma）——后者是 Macaron AI 的 CRO 兼 Mind Lab 负责人。

如果说这家实验室有一条贯穿所有项目的线索，那就是"让前沿 RL 训练不再被 GPU 数量锁死"。从万亿参数 LoRA RL 到 δ-mem（在线记忆压缩），再到 LongStraw，Mind Lab 始终在回答同一个问题：如果不加 GPU，只靠系统设计的聪明才智，RL 能被推到多远？

LongStraw 是目前最激进的回答。

超长上下文 RL，从"千卡入场券"到"8 卡自助餐"

LongStraw 不是第一个试图拉长 RL 训练上下文的工作。此前 Cerebras 展示了用 99% 更少的训练 token 扩展上下文的方法，NVIDIA 的 NeMo 框架也在长上下文训练上做了大量优化。但这些方案要么依赖专用硬件（Cerebras 的晶圆级芯片），要么仍然瞄准的是预训练和微调阶段的上下文扩展，而非 RL 后训练。

LongStraw 的独特之处在于：它直接在 GRPO 这个具体的 RL 算法上做系统级优化，目标不是在 A100/H100 集群上跑得更快，而是在消费级数据中心 GPU（H20）上跑得起来。这个定位的差异使得 LongStraw 的受众不是拥有万卡集群的 hyperscaler，而是那些只有几十张 H20、但想做前沿 RL 研究的大学实验室和创业团队。

HuggingFace 社区用户 O96a 在论文评论区提出了一个尖锐的问题：LongStraw 的"共享 prompt"假设在 Agent 的实际场景中可能站不住——Agent 的上下文不是一次性给完的，而是工具调用、文档检索和环境反馈在中途不断插入的。如果上下文"长"的方式是不可预测的增量式增长，而非一次性的大块 prompt，LongStraw 的常驻前缀策略是否仍然有效？这是开源后社区最值得追踪的验证方向。

AI Weekly 在报道中给出了一个精准的判断："如果开源代码在第三方的 Qwen 和 GLM checkpoint 上经得起检验，长上下文 RL 的游戏规则就会被改写。'RL 上下文比推理落后一代'这个借口，不再成立。"

一份诚实的论文：我们能跑通，但还没跑好

LongStraw 是一份罕见的、在标题和摘要里就把自己的局限写得清清楚楚的论文。

"执行能力而非完整训练正确性"——这不是谦虚，而是精准。论文明确列出了当前版本的缺失项：部分分布式前向路径和梯度合成路径尚未完成（"remain incomplete"），代码仓库标记为 review_only_not_runnable，NVIDIA 验证所需的镜像、fixture 和签名尚待补齐。

但这份诚实恰恰是 LongStraw 最值得认真对待的地方。在 AI 论文越来越像产品发布会的时代，一个团队选择先证明"系统能跑通"再证明"训出来的模型更好"，这种顺序本身就是一种学科素养。

Mind Lab 成立 7 个月，团队规模不大，硬件预算有限——但 LongStraw 传递的信号是清晰的：长上下文 RL 不是 GPU 数量的问题，是工程想象力的问题。如果社区接过开源代码继续推进，把"执行能力"变成"训练正确性"，超长上下文 RL 后训练将不再是 hyperscaler 的内部秘密，而是整个开源生态的基础设施。

参考链接：

论文：arXiv — LongStraw: Long-Context RL Beyond 2M Tokens under a Fixed GPU Budget
HuggingFace Papers：
代码：
AI Weekly 报道：
Mind Lab 官方推文：

AREX Agent 新闻热点追踪。本文基于一手信源（论文原文、官方推文、开源仓库）及社区反响编写，仅供行业参考。未经许可不得转载。_