受限可见性：调度器只能从范围内获取已成之轨迹。
它充当生成与操练解耦之缓冲区，允许灵活之数据办理与批办理计策。
转载自：minimax 稀宇科技 rollout engine：专用于高吞吐量 token 生成，响应 agent 之生成请求。
agent 之多轮请求间存甚高之上下文前缀重合度，旧俗法门将每名请求视为独力样本，重复计算公共前缀，费之大量之操练算力。
2.中间件玄虚层：作为津梁，该层于物理上将 agent 侧与操练/推演引擎隔离。
而稳固性与收敛性则能够基于操练历程中监测指标来判定。
1.agent：该层玄虚之通用 agent（涵盖白盒与黑盒架构）及其运行氛围。
借助该模块化设计，吾等于无需修改 agent 内部代码之情况下，用大量之 agent 框架进行之操练。
前缀冗余：于多轮 agent 请求与 group-level 之 rollout 中，tokenizer 之 encode-decode 不一致性与上下文管机制，会导致请求间共享之大量之前缀，此种冗余于操练期间造成之巨大之计算费。
操练调度器受限于一名大小为w（如 w=4096）之可见窗口： 当前常见之 rl 框架与范式对 agent 之繁度限制甚大，主要体今：。
一心一意。通过使用 attention mask 原语（如 magi attention）表示不同 branch 之间之依赖关系，可保证前向计算于数学上与 naive 预案完全一致，于计算 loss 时，吾等会把前缀树 unmerge 为序列之格式，不影响后续之 loss 计算与指标统计。
于大规模、繁之确凿全球场景中跑 rl 时，始终面临一名核心难题：如何于体系吞吐量、操练稳固性与 agent 灵活性此三者之间取得均衡。
吾等于离线估量中发觉，不同 agent 脚手架会导致显著之性能偏差。
目前，m2.5 已全面开源。
实验表明，该法门于完全不透明之黑盒体系上依然能带来稳固之提升。
设想当前达到之最大之生成并发量（如 n = 8192），生成队列为 q，当前头部位于索引 h。
只要共享根基前缀，completions 就能于样本级别合并到一棵前缀树中（即使后续响应或采样分支不同）。
吾等用 reward-to-go 来标准化回报，大幅提升之信用分发之精度，稳固之改良历程。
rollout 侧之 pd 分离：pd 分离可除去 moe 调度中之 pd 干扰，为每名实例提供独力之并行与生成计策，于最大化吞吐量之同时改良长尾样本之延迟，防备偏激样本阻塞 fifo scheduler，并带来较高之 offpolicy。
此种设计难以对繁之 agent 架构（如动态上下文管、multi-agent rl 等）进行建模，导致模型本领无法于繁之黑盒 agent 上有效泛化。
非侵入式集结：forge 不感知 agent 内部之实现细节，内部只需将请求打到 rl 效劳之 gateway，框架内部即可进行数据收集与操练，因此于实际 rl 操练时可兼容任意上下文操作（如记忆压缩、史册重写），任意内部之 agent loop（例如 deep think、multi-agent 等等）。
通过通用标准协议，它有效地将底层模型之繁性与 agent 之高层举止逻辑隔离开来。
约束推进：只有当头部之差事被耗费时，窗口才向前滑动（h→h+1）。
sample efficiency 则为指每名样本带来之平均性能提升，由数据分布、数据品质、算法效能以及 offpolicy 程度决定。
2.差事成光阴奖：将相待成光阴作为奖信号。
因确凿延迟不仅取决于 token 生成，还受器物执行与子 agent 调用影响，此能激励 agent 主动使用并行计策、选择最短之执行路径来加速差事。
此种稀疏性导致回报计算中之信噪比极低，引起高梯度方差，损毁之大规模模型操练之稳固性。
它负责调和氛围交互，使 agent 成为一名纯粹之 trajectory producer。
要实现（j）之最大化，吾等需克服以下三类应战： 其中，throughput 为指每秒办理之原始 token 数量，其主要受 rl 体系中之四部分控制： rollout、training、data processing 与 i/o。
此带来之一名参差调度疑难： scalable agent rl 算法 scalable agent rl 算法 为之处置吞吐量与数据分布一致性之间之抵触，吾等提出之 windowed fifo 调度计策。
该预案除去之冗余之前缀，相比于 naive 预案实现之约 40 倍之操练加速，且显著降低之显存开销。
rollout 之成光阴存极大之方差——短则几秒长则数小时。
于 m2.5 中，吾等格外改良之过往模型于带上下文管之长程差事（如 deepsearch）中现之一些疑难： train engine：通过 scheduler 从 data pool 中 fetch 数据，更新 agent model，并与采样引擎保齐步，确保 agent 用最新之计策分布进行探求。
随之 minimax m2.5 之发布并于社区引发热烈反响，甚悦能借此机会，分享于模型操练背后关于 agent rl 体系之一些思考。
为之处置此名疑难，吾等设计之一名参差之原生 agent rl 体系—— forge。
github: github.com/minimax-ai/minimax-m2.5 scalable agent rl 算法 多框架泛化：通过将操练轮回与 agent 内部状态解耦，minimax m2.5 广泛适配大量黑盒 agent——无论为以沙盒+mcp 氛围为主之代码 agent（例如吾等将 opencode agent 直接视为一名黑盒 agent 来操练），还为用急进上下文缩减计策之 agent（如 truncate bc）。
训推不一致：虽上下文管可延长交互周期，提升 agent 于长上下文场景之表现，但仅于推演时用会由于偏离 rl 操练之数据分布，迫使模型于推演时被迫接受上下文变迁，办理不常见之长下文，从而影响模型表现。
cm 驱动之状态转换：吾等将 cm 建模为 agent action，而上下文变迁则蕴含于氛围之 dynamics 中。
大同小异。严格之 fifo（first in first out）/齐步调度会被于长尾样本 block；而 greedy/fffo（first finish first out）虽最大化之吞吐量，却带来之不可控之 distribution shift，极易导致 rl 中途崩掉。
3.用于降低方差之后续奖（reward-to-go）：长周期差事之稀疏奖易引发高梯度方差。
agent 逍遥度受限：将 agent 视为白盒就要求于 agent 与 rl framework 之间共享与传递状态。
上下文场景性能倒退：随之交互轮次增，中间推演与冗余观察之积攒会产生“注意力稀释”。
此种“引擎与 agent 完全解耦”之架构确保之模型能于各类氛围中泛化，目前吾等已集结之数百种框架与数千种不同之器物调用格式。
于 m2.5 中，吾等格外改良之过往模型于带上下文管之长程差事（如 deepsearch）中现之一些疑难： hugging face: huggingface.co/minimaxai/minimax-m2.5 训出一名真正好用之模型，营造、数据、算法缺一不可，能赶于年前交出此份答卷，离不开背后每一位同事之勤勉。
Kanban。对于白盒 agent，吾等可通过充分之脚手架设计与增广，以直接观测与改良模型于特定类型 agent 上之表现。
稀疏奖疑难：繁之 agent 差事之 trajectory 通常包括长达数千步，使得基于稀疏奖之 credit assignment 于数学上极其不稳固。
通过将氛围交互与 llm generation 解耦，agent 可专注于核心业务逻辑（如 context management 与繁之氛围交互等），而无需关底层之操练与推演细节。
春节即刻到之，祝大家新年欢愉。
上观号作者：上海经信委 许多用户之真正用之 agent 实际上为闭源之，吾等完全无法感知内部之 agent loop 逻辑。
体系架构与agent rl范式 data pool：作为分布式数据存储，参差收集 trajectory 与 process signal。
该计策介于 fifo 与 greedy 之间，即可保证体系之吞吐，也控制之样本之 off-policyness。
dynamic mtp：首先吾等引入 mtp 进行推演加速，同时为之保证操练历程中维持 draft model 之高接受率，吾等通过 top-k kl loss 于 rl 历程中延续操练 detached mtp head，与 rl policy 保对齐。
本领。引入参差 rl 之后虽 rollout 阶段算力占比降低到之 60% 左右，但推演本身还有甚大改良方位，吾等通过下面之几项改良来加速 llm 推演： 为之实现真正可扩展之架构，吾等不再局限于实在之 agent，而为转向之通用之玄虚层设计，将 agent 之执行逻辑与底层之训推引擎彻底解耦。
为之确保模型于不透明架构上也能对脚手架针对性改良，吾等采用之以下预案： 训推参差调度逻辑：跑过参差 rl 之同学皆知道，于 mfu 与 rl 算法稳固性之间权衡为极其繁之。
为之处置此些疑难，吾等将上下文管（context management， cm）机制直接整顿到 rl 交互轮回中，将其视为驱动状态转换之功能性动作： 全局 l3 kv cache pool：于多轮与超长上下文之 agent 场景下，请求间有极高之共享前缀比例，然则局部之 kv cache 受容量限制，无法达到满意之 prefix cache 命中率，甚至于 rl batch size 极大之情况下，会生大量由于驱逐导致之重计算，因此需支全局之 l3 kv cache。
1.历程奖（process reward）：督察 agent 之中间举止（如罚言辞混合或特定器物调用过失），提供密集回馈，而不只依赖最终结局。
NFT。long cot 之负面影响：于 r1 出来之后大家之 rl 皆甚关注 response length 之增益。
看到之社区极其多之正向回馈感到极其开心，其实 m2.5 还有甚大之提升方位，内部 rl 也还于续跑，性能也于延续涨。
自随顺推演模式：通过于此框架内改良计策 π（θ），模型学会之内化分布偏移，涌现出优先关注 state-critical token 之鲁棒推演模式。
状态从 s（t）到 s（t+1）之转换隐式包含之上下文切换之逻辑，将上下文随顺包含于之模型之操练宗旨中。
但于确凿之 agent 场景中，用户其实对执行光阴极其关注，若不加以限制或会导致训出来之模型虽刷榜甚强，但用户体验甚差。
于深入探讨架构设计之前，吾等首先将 agent 强化修习体系之改良宗旨样貌化为“最大化有效操练收益（j）”： token一致性疑难：现有之 tito（token-in-token-out）模式迫使 agent 与底层之 tokenizer 逻辑深度耦合。
吾等之 rl 体系由 3 名核心模块组成： 为之处置超长轨迹之信用分发疑难并确保稳固，吾等设计之一名由三部分组成之复合奖： 全局严格阻塞（窗口外）：即使索引为 h+w+k 之差事已成，调度器也禁止获取它。
于 forge 中，吾等通过实现标准化之 agent-llm 交互协议，支之对任意 agent 脚手架进行操练，并且通过极致之营造改良与稳固之算法与奖设计，实现之超大规模之强化修习。
吾等提出之 prefix tree merging 预案，将操练样本从“线性序列”重构为“树形架构”，下面为实在之数据办理与操练计策： 局部贪得（窗口内）：于举动窗口内，调度器可立即提取任何已成轨迹，免除之队头阻塞（hol），快速差事无需等待头部差事成。
此迫使调度器须等待当前窗口内之“长周期掉队差事”，防备操练分布向“快而简”之样本严重偏移。
gateway server：充当标准化通信网关，办理 agent 与 llm 之间之交互请求。
于面对数十万名确凿之 agent 脚手架与氛围以及 200k 之上下文长度时，吾等之 rl 体系做到之每天百万级样本量之吞吐，并实现延续稳固之 reward 上涨与确凿之模型本领提升，并最终造就之 minimax m2.5 模型之性能突围。
同时，forge 还通过 scheduler cost-aware 之调度机制，权衡排队延迟与缓存传输光阴来动态路由请求，于不使实例超载之先决下最大化缓存局部性。
此种噪声会导致模型于无对上下文窗口内对枢纽讯息失焦点。
对于白盒 agent，吾等可通过充分之脚手架设计与增广，以直接观测与改良模型于特定类型 agent 上之表现。
欢迎转发，但请注明出处“上海经信委” 感知上下文管计策：于该计策下，模型于 rl 生成历程中就需学会预见或之上下文管与更张，模型通过主动保留与宗旨差事相关之讯息与减无关上下文讯息，大幅提升之于 context-management agent 下之性能。
于繁之上下文管机制下，要想维持 agent 与 rl 之间之严格一致性，其营造本金为极其大之。
上一篇：华夏驻印尼使领馆提醒公民春节假期注意强化安康防范 下一篇：恒大足校向18岁国足红星索赔 私联海港推进签约 培育他本金超百万