从大模型 Infra 到 Agentic RL Infra：系统地图、关键原理与实操学习路线

读懂 PPO、GRPO 的公式以后，真正动手训练一个 Agent，往往会遇到另一组问题：模型为什么放不进显存？GPU 为什么在等工具返回？训练端和推理端明明使用同一份权重，为什么算出的 log probability 不一样？一条跑了十分钟的轨迹，回来时模型已经更新了很多次，还能不能训练？

这些问题共同构成 Agentic RL Infra。要理解它，先需要掌握大模型训练和推理基础设施，再理解环境交互如何进入学习闭环。

本文按“资源与算子 → 分布式训练 → 推理服务 → RL 数据流 → Agent 环境与异步系统”组织知识。默认读者会 Python、基本 PyTorch 和 Transformer，但没有大规模集群经验。资料核验于 2026 年 9 月 17 日，以原始论文、官方文档和项目仓库为主；框架能力会变化，复现实验应固定 release 或 commit。

文中的显存、吞吐和奖励算例均为教学构造，不是实测 benchmark；学习路线与排查建议是基于这些原理整理的工程建议。

1. 先画出整张系统地图

可以用三种工作负载建立直觉：

工作负载	数据从哪里来	主要执行过程	最容易忽视的成本
预训练 / SFT	预先准备的数据集	读数据、前向、反向、更新	激活、通信、数据供给、保存与恢复
在线推理	外部请求	Prefill、逐 token decode、返回结果	KV Cache、排队、长尾请求
Agentic RL	当前策略与环境的交互	采样、调用工具、评分、训练、刷新策略	环境等待、无效轨迹、策略滞后、权重搬运

第三行把前两行连成了循环。训练改变策略，策略又改变下一批数据的分布，因此系统调度可能直接改变学习结果。

一条任务如何变成一次模型更新

① 任务与环境任务采样、环境 reset、独立沙箱
输出：初始 observation → ②

② Agent 与推理引擎生成 action、工具执行、追加观察
循环交互后输出轨迹 → ③

③ 验证与轨迹存储验证结果、记录版本、检查 token 与 mask
输出：可训练样本 → ④

④ Learner计算优势、策略损失、反向与更新
输出：新参数 → ⑤

⑤ 权重同步重分片、传输、校验、切换版本
新策略回到 ②；评估副本 → ⑥

⑥ 独立评估固定任务、固定工具预算、统计成功率
用于比较、选 checkpoint 与发现回归

贯穿所有环节：资源调度、队列背压、trace、故障恢复与版本管理。验证器参与训练奖励；独立评估集不进入训练采样。

这里的 Agent 包含 harness：负责工具调用、上下文组织、终止条件和控制流的运行层。它不等于模型本身。2026 年的 Agent Lightning v1.0 预印本强调让部署时的 harness 直接参与训练，并讨论由此产生的 token 对齐、样本合并和调度问题。这是值得关注的方向，但不能据此认定所有框架已经有完全相同的接口。

2. GPU 基础：先学会解释时间和显存去了哪里

2.1 计算、显存带宽、通信和等待

一次训练或推理的耗时，至少可能受四类因素限制：

• 计算：矩阵乘法规模足够大，计算单元持续忙碌。
• 显存带宽：大量时间用于搬运权重、激活或 KV，算术运算相对少。
• 设备间通信：GPU 在交换梯度、激活或专家 token。
• 外部等待：等 CPU、数据加载、工具、沙箱或其他 worker。

用简化的 Roofline 思路可以估算一个算子的时间下界：

\[ T \gtrsim \max\left(\frac{F}{P_{\mathrm{eff}}},\frac{Q}{B_{\mathrm{eff}}}\right), \]

其中 \(F\) 是运算量，\(Q\) 是显存搬运字节数，\(P_{\mathrm{eff}}\) 与 \(B_{\mathrm{eff}}\) 分别是该工作负载下的有效算力和带宽。真实时间还可能包含通信、启动开销与同步，不能直接用硬件峰值代替有效值。

一个教学例子：假设每轮需要从显存读 16 GB 权重，有效带宽为 2 TB/s，仅权重读取的理想下界就是约 8 ms。实际系统还要读取 KV、执行算子，通常更慢。增加 batch 能让多个请求共享一次权重读取的成本，但也增加 KV 与排队压力。

第一项练习：用 PyTorch Profiler 观察一次 forward/backward，找出最耗时的三个算子，以及 CPU 与 GPU 之间的空白。测 CUDA 时间时要正确处理异步执行，使用 CUDA event 或同步后的计时；预热和正式测量分开。

2.2 权重大小不等于训练显存

对于 \(N\) 个参数，考虑一种常见的混合精度 Adam 账本：

项目	教学假设下每参数字节数
BF16 参数	2
BF16 梯度	2
FP32 master weights	4
Adam 一阶与二阶状态	8
合计	16

因此 8B 参数模型仅这部分就约为 \(8\times10^9\times16=128\) GB，即约 119 GiB，还没包含激活、临时工作区和通信缓冲。具体优化器可能使用 FP32 梯度、不同状态精度或不保留独立 master copy，因此 16 bytes/parameter 是一个明确假设下的估算，不是通用常数。

显存排查应先判断是哪类内存增长：参数状态过大、sequence 太长导致激活过大，还是 rollout 的 KV 占满。它们对应不同办法。

2.3 FlashAttention、重计算与低精度各解决什么

FlashAttention通过分块和片上存储复用，减少 attention 中间结果对 HBM 的读写；它是精确 attention 的高效实现，不等于把标准 dense attention 的算术复杂度自动从二次变成线性。

Activation checkpointing 则在反向时重算部分前向结果，用计算换显存。BF16、FP8 等精度选择会同时影响吞吐、容量和数值行为，低精度训练还涉及累加精度、缩放和算子支持。特别是在 RL 中，微小概率差异会进入 importance ratio，不能只看生成文本是否相同。

3. 分布式训练：到底把什么切开了

先区分两件事：让模型放得下，以及让训练跑得快。同一种并行方式可能改善容量，却因额外通信降低速度。

技术	切分对象	主要收益	主要代价
DDP / 数据并行	batch；每卡持有模型副本	扩大数据处理量	梯度同步、模型状态仍复制
ZeRO / FSDP	优化器状态、梯度、参数	降低每卡状态内存	参数收集、梯度归约、临时峰值
TP：张量并行	层内矩阵 / 张量	拆分大层的计算与存储	层内频繁通信
PP：流水线并行	模型层	按深度拆模型	流水线空泡与 stage 不均衡
CP：上下文并行	长序列	分摊长上下文相关开销	attention 所需的信息交换
EP：专家并行	MoE experts	分布式存储和执行专家	token dispatch/combine、负载不均

以上术语与组合可对照 Megatron Core 并行指南。框架里所谓 sequence parallelism 不一定等于 CP；例如某些 SP 主要切分 LayerNorm、Dropout 等部分的激活。不要仅凭缩写推断其通信和内存语义。

3.1 从 DDP 走到 ZeRO / FSDP

ZeRO 原论文的阶段划分很好记：ZeRO-1 分片优化器状态，ZeRO-2 再分片梯度，ZeRO-3 再分片参数。PyTorch FSDP2也围绕参数等状态的分片组织训练，但不能把不同实现的参数、通信时机和性能直接视为相同。

以刚才 128 GB 的状态账本为例，完全分片到 8 张卡时，持久分片状态的理想平均是 16 GB/卡；这不是实际显存峰值。计算某层之前可能要 all-gather 完整参数，还要存激活与临时 buffer。

学会三个 collective 就能读懂很多 trace：all-reduce 汇总后让每个 rank 得到结果；all-gather 收齐分片；reduce-scatter 汇总后只保留各自负责的分片。NCCL 官方说明给出了它们的语义。

3.2 并行度和 batch 不要混算

对于没有 CP、EP 等额外维度的简单 dense 配置，假设 8 张卡使用 TP=2、PP=2，则剩余 DP=2。如果每个数据并行副本每个 microbatch 有 2 个样本，梯度累积 8 次：

\[ B_{\mathrm{global}}=2\times2\times8=32. \]

TP 和 PP 的 GPU 在共同计算同一批样本，不能把全体 8 张 GPU 再乘一遍。使用 packing 或 token budget 时，还要分别报告样本数和有效 token 数。MoE 的 EP 与其他并行维度如何组合，必须检查框架的 process group 定义，不能机械地把所有缩写相乘。

3.3 MoE、网络拓扑和数据供给

MoE 每个 token 只激活部分专家，但训练系统仍要管理整体专家权重及优化器状态。它减少的主要是每 token 的部分计算，不代表显存按 active parameters 等比例下降。专家负载偏斜还会让部分卡拖慢整个 step。

TP 通信频繁，通常更依赖高速互联；跨节点训练要关注网络带宽、延迟和拓扑。增加 GPU 之后，如果每卡计算量太小，通信比例反而会变高。应比较相同有效 batch 下的 step time 和扩展效率。

训练数据同样是 infra：离线 tokenization、分片读取、预取和 packing 能改善供给；恢复时还要知道数据读到了哪里。packing 独立样本时需正确处理 attention 边界、position 与 loss mask，避免样本间意外看到彼此答案。CS336把模型、系统和数据拆成作业，适合把这些能力逐步补齐。

4. 推理 Infra：把 KV Cache、调度和延迟放到一起看

4.1 Prefill 与 decode 是两类工作负载

Prefill一次处理已有 prompt，建立后续生成需要的 KV；decode逐步生成新 token，每一步使用之前的 KV。长 prompt 的 prefill 通常更容易形成大规模矩阵运算，小 batch decode 常受带宽影响，但具体瓶颈仍取决于模型、batch、上下文和硬件。

衡量推理至少需要：

• TTFT：请求发出到首个 token 的时间，可能包括排队和 prefill。
• ITL / TPOT：相邻输出 token 的间隔 / 每输出 token 的耗时，统计口径应明确。
• 吞吐：每秒输出 token 或完成请求，说明是否包含输入 token。
• 尾延迟：p95、p99，而不只是均值。

vLLM 的指标文档是核对这些观测口径的入口。RL rollout 往往更重视吞吐，但过长的完成时间也会增加策略滞后，所以延迟仍有学习上的后果。

4.2 手算一次 KV Cache

对标准 attention / GQA，一个未分片请求的 KV 容量可近似写为：

\[ M_{\mathrm{KV}}=2\times L\times H_{\mathrm{KV}}\times d_h\times S\times b. \]

\(L\) 为层数，\(H_{\mathrm{KV}}\) 为 KV head 数，\(d_h\) 为 head 维度，\(S\) 为缓存 token 数，\(b\) 为每元素字节数；最前面的 2 表示 K 和 V。

假设 \(L=32\)、\(H_{\mathrm{KV}}=8\)、\(d_h=128\)、\(b=2\)，每个 token 的 KV 是 131,072 bytes，也就是 128 KiB。8192 tokens 约占 1 GiB/请求；32 个这样的活跃请求约为 32 GiB，另加权重和运行时开销。

这是用于容量规划的简化模型。MLA、滑动窗口、KV 量化、分片与前缀共享会改变实际账本；也不能把 query head 数误当成 KV head 数。

4.3 三个经常一起出现、但职责不同的优化

技术	解决的问题	不应作出的推断
Continuous batching	每轮调度可接入新请求，减少固定 batch 的等待	并发无限增加就一定更快
PagedAttention / 分页 KV	KV 按块管理，减少连续大块预留与碎片问题	分页本身会让每 token 的 KV 消失
Prefix caching	复用相同前缀的已有 KV，节省重复 prefill	不同权重版本可以复用同一份 KV

vLLM / PagedAttention 论文适合理解内存管理；SGLang 论文适合理解多次模型调用中的前缀复用。两篇论文的历史性能结果都有特定实验条件，不能直接当作今天的框架排名。

进一步可以学习 chunked prefill 与 prefill/decode 分离：前者控制一次 prefill 占用的调度预算，后者让两种工作负载使用不同资源。分离也会引入 KV 传输和额外调度开销，是否有收益要实测。

5. RL Infra：一次更新究竟需要哪些模型和数据

5.1 先分清四种角色

角色	工作	是否必需
Actor / policy	生成动作，并接受策略更新	必需
Reference policy	提供固定或按方案更新的约束基准	取决于是否使用相关 KL 等目标
Critic / value model	估计价值，用于优势估计	PPO 常用；GRPO 等不一定需要
Reward model / verifier	评价输出或任务结果	需要奖励来源，但不一定是神经网络

这里的 actor 是 RL 的策略角色；Ray actor 指有状态远程进程，两者不要混淆。推理用 policy 与训练用 policy 也可能是同一逻辑模型在不同 GPU、不同引擎里的副本。

PPO中的概率比让新旧策略建立联系；DeepSeekMath提出的 GRPO 用同一题目的多个采样结果构造组内基线，省去独立 critic。这减少了部分模型开销，却仍要支付多次生成、评分和 logprob 计算的成本。

5.2 单轮 RL 的基本数据流

一个便于理解的同步版本是：

1. 用行为策略生成一批 response，保存采样所需的元数据。
2. 验证器计算 reward，记录正常结束、截断或异常。
3. 按算法计算 old/reference logprobs、value 和 advantage。
4. Learner 对相应 token 计算 loss、反向并更新参数。
5. 将新策略同步到 rollout 引擎，开始下一轮。

HybridFlow / verl 论文值得读的重点，是这些角色为什么需要不同的并行与资源组织，以及训练和生成之间的切换怎样实现。理解这一层之后，才容易看懂框架中大量 worker、RPC 与 device mesh。

5.3 概率字段必须有明确语义

至少区分：真正生成 token 的行为分布 \(\mu\)、PPO 本轮更新使用的旧策略锚点 \(\pi_{\mathrm{old}}\)，以及当前训练策略 \(\pi_\theta\)。固定的 reference policy 是另一回事，不应拿它替代 PPO 的 old policy。

一个 token 上，新策略相对行为分布的比率是：

\[ \frac{\pi_\theta(a_t\mid h_t)}{\mu(a_t\mid h_t)} =\exp\left(\log\pi_\theta(a_t\mid h_t)-\log\mu(a_t\mid h_t)\right). \]

若行为概率是 0.20，新概率是 0.24，比率为 1.2；如果把另一个模型重算出的 0.23 当成行为概率，得到的就是约 1.043，优化含义已经变了。

temperature、top-p、top-k、受约束解码和精度都会影响“采样分布”的定义。某个 API 返回的 logprob 可能是原始模型概率，也可能对应变换后的分布，必须检查接口契约。保存 token 概率字段，并不自动证明分母正确。 verl Rollout Correction明确区分了行为策略、旧策略与当前策略，并提供不同修正模式。

6. Agentic RL 新增的难点：训练对象是交互轨迹

6.1 一条轨迹不能只保存“问题和答案”

假设任务是“查询两个仓库的 issue 数并比较”。模型先生成工具调用，收到搜索结果，再生成第二次调用，最后回答。上下文包含：

用户问题                         loss mask = 0
模型生成的第 1 次工具调用          loss mask = 1
工具返回的 observation           loss mask = 0
模型生成的第 2 次工具调用          loss mask = 1
工具返回的 observation           loss mask = 0
模型生成的最终答案                loss mask = 1

在这种策略梯度训练设定中，工具文本是条件信息，不是模型采样的 action，因此不直接计算它的策略损失；模型生成的工具名称和参数则属于 action。verl Agent Loop用 response mask 区分模型 token 和工具 response token。

如果总共只有 30 个 action tokens，却有 300 个工具返回 tokens，把这 300 个 token 也当成策略动作，会构造错误的训练目标。还要注意：loss mask 与 attention mask 不同。后续 action 仍需要通过 attention 读取合法的工具结果。

6.2 原始 token、实际上下文与 segment

不要假设“保存对话字符串，训练时再 tokenize”就一定能还原采样过程。chat template、特殊 token、截断、思考内容保留规则，以及上下文压缩，都可能改变实际输入。verl 多轮文档专门讨论了 tokenization 一致性。

工程上应优先保存每次调用真正使用的 token IDs、生成 token IDs 和对应概率；如果 harness 在中途重写或压缩上下文，就按模型调用切成 segment，保存每段的实际输入。简单拼接全部历史可能制造出一个模型当时从未见过的条件分布。

下面是建议的数据契约示意，不是任何框架可直接运行的配置：

trajectory_id, task_id, group_id, attempt_id
env_version, harness_version, verifier_version
segments[]:
  request_id, policy_version, tokenizer_and_template_version
  actual_prompt_ids, generated_ids, action_loss_mask
  rollout_logprobs, logprob_semantics, sampling_config
  tool_events, start_time, end_time
reward, terminated, truncated, failure_type

如果同一条长轨迹的不同调用使用了不同策略版本，一个 trajectory 级别的 version 字段就不够了。对长生成中的版本切换，粒度甚至需要更细；入门实现可以先固定整条轨迹的版本，降低复杂度。

6.3 组内优势、长轨迹和归一化

以简化 GRPO 为例，同一道题采样 4 条轨迹，奖励为 \([1,0,1,0]\)。使用总体标准差时，均值为 0.5、标准差为 0.5，归一化优势约为 \([1,-1,1,-1]\)。实际实现还要核对标准差定义与 epsilon。

组内样本应该对应同一任务设定；若环境有随机性，要明确 seed 与初始状态的比较语义。若 4 条全得 0 或全得 1，组内归一化奖励提供不了差异化优势，不能把高吞吐直接等同于有效学习信号。

长短轨迹混在一起时，token 平均、sequence 平均、turn 平均会改变各轨迹的权重。比如 20-token 与 200-token 的轨迹，在直接汇总 token loss 时会有不同影响。选择哪种归一化是算法决定；infra 的职责是精确保留边界并实现它。

6.4 终止、预算截断与基础设施失败

三者需要独立记录：任务自然成功或失败；到达最大轮数或 token 上限；容器启动失败、网络超时等系统异常。对于带 value 的算法，终止与截断还关系到是否 bootstrap，不能随意合并。

如果系统超时一律记为任务 reward=0，模型可能因为环境服务不稳定而被惩罚。若超时本就是任务约束，可以纳入奖励，但必须事先定义，并在评估时使用一致的预算。

7. 异步 rollout：吞吐与数据新鲜度要一起优化

7.1 “用了 async”至少有三种含义

层级	含义	是否必然训练与采样并行
请求异步	多个 Agent 同时等模型或工具	否
rollout 内部流水	生成、环境执行、评分有所重叠	否
Learner 与 rollout 解耦	更新模型时仍在持续生产轨迹	是，但需要管理 off-policy 程度

某些配置中的 mode=async 表示推理服务或多轮请求的异步模式，不能据此断言训练已经是 fully asynchronous。必须沿调用链确认有没有“等整批采样完成”的 barrier。

7.2 长尾怎样浪费资源

假设 8 条轨迹分别用时 \([10,10,10,10,10,10,10,80]\) 秒，每条占一个独立槽位。整批等待最慢者时，槽位有效占用率为：

\[ \frac{7\times10+80}{8\times80}\approx23.4\%. \]

这是简化调度槽位利用率，不是 GPU 利用率的实测值。真实 LLM 引擎会交错执行请求，但 Learner 仍可能被整批完成条件挡住。

异步系统让空闲槽位接新任务，通常能减小此类等待。AReaL 论文是理解异步 RL 系统及其算法协同的入口。不过只接收最先完成的轨迹也会偏向短任务，改变训练分布；GRPO 还需要维护同题 group 的完整性。

7.3 队列长度也是算法参数

假设每秒生产 6 条合格轨迹，训练端只能消费 4 条，如果没有背压，队列每秒增长 2 条。越排越久的样本，对应的策略版本也越旧。

定义版本滞后 \(\Delta v=v_{\mathrm{learner}}-v_{\mathrm{rollout}}\) 可以方便监控，但同样的版本差不代表同样的分布差。还应看样本年龄、logprob 差异、importance ratio 分布和拒收比例。

常用控制手段包括限制在途请求、限定允许的策略滞后、减小队列、按算法重加权或筛除数据。它们都存在取舍：importance weighting 可能增大方差，截断会引入偏差，丢弃长尾又可能破坏任务覆盖。PPO clipping 本身不能保证任意陈旧数据都可安全使用。

7.4 权重同步不是一个免费函数

训练端可能用 FSDP 或 TP+PP，推理端采用另一种 TP 布局。同步要经历：导出训练状态中的参数、重分片或转换布局、传输、加载并切换版本。

一次同步应有明确的可见性边界：不能让一半层读新权重、另一半层读旧权重。还要定义已有请求是继续旧版本、排空后切换，还是中断重开。权重变了，旧 KV 一般也不能继续视为新模型的精确缓存；若继续服务旧请求，需要保留对应旧版本，或按新版本重新计算。

如果每次更新用 20 秒、权重同步又花 10 秒，优化 2 秒的反向并不一定是最有效的投入。先把导出、传输、加载和等待分别计时。

8. 环境、调度、容错：Agentic RL 的另一半

8.1 沙箱是一种训练资源

代码 Agent 需要工作目录、依赖、CPU、内存和测试进程；浏览器 Agent 需要浏览器状态、页面及账号隔离。GPU 容量够，不代表环境容量够。

一个可复用环境接口至少要能描述 reset、step、结束原因、超时与清理；环境、任务和验证器应版本化。可以做到时保存 snapshot；做不到精确恢复的外部网站，应记录这一限制并保留输入输出证据。

验证器还必须评价真实结果：代码任务不能只信 Agent 的“测试通过”文本，应由独立执行得到状态和结果。测试集、任务来源和环境模板也要区分训练与评估，防止测到记忆或泄漏。

8.2 调度框架负责什么

Ray 提供远程任务、有状态 actor 和资源调度；placement group 可以成组预留资源，适合多个训练 rank 一起启动。Ray 官方文档同时说明了资源 bundle 和放置策略。

但资源标签不等于显存强隔离，也不代表系统自动具备训练语义上的正确恢复。Kubernetes、Slurm、Ray 与训练框架各自承担不同层次，入门时先画清谁管理节点、谁管理进程、谁管理模型状态。

资源池可以拆成训练 GPU、rollout GPU、CPU 沙箱和 verifier。也可以让训练与推理复用 GPU、按阶段释放或卸载内存。前者便于流水重叠，后者节约常驻资源；哪个更合适取决于任务时长分布和显存预算。

8.3 可恢复性不仅是保存模型

继续训练一般还需要 optimizer、scheduler、随机数状态、数据位置和训练 step。Agentic RL 又增加了轨迹队列、已消费样本 ID、策略版本，以及在途任务的处理规则。PyTorch Distributed Checkpoint是了解分布式状态保存的入口，但应用级队列仍需要自己定义恢复协议。

一个实用做法是给 trajectory 与 attempt 分别编号：同一任务重试可能产生多个 attempt，但提交到训练数据时应能去重。工具操作若会改变环境状态，重试前必须判断它是否已经生效。仅仅重启 worker，可能导致重复执行或重复奖励。

这些是系统设计建议，不意味着前述所有开源框架都已经实现全部能力。

9. 如何选择框架与阅读源码

推荐的学习主线：PyTorch / FSDP → vLLM 或 SGLang → verl → 再对照 slime、AReaL。 这是为降低学习跨度安排的顺序，不是性能排行榜。

项目	适合重点学习什么	阅读时带着的问题
Megatron Core	训练并行与通信	每个 process group 在切哪一维？
vLLM	推理调度、KV、服务指标	token budget 与 KV 容量如何限制并发？
SGLang	推理运行时、多调用与缓存复用	路由和缓存亲和性有什么关系？
verl	RL 数据流、训练后端与 Agent Loop	token、mask、reward 如何抵达 loss？
slime	SGLang 与 Megatron 的后训练集成	rollout、data buffer、权重同步如何解耦？
AReaL	异步 RL、服务拆分与策略滞后	如何限制和修正过旧的数据？
OpenRLHF	Ray 组织的 RLHF / Agentic RL	多个模型角色如何部署和协作？
Agent Lightning	harness 与训练连接	怎样把实际 Agent 调用转换成训练 segment？

截至核验日，AReaL 仓库已介绍 2.0 的训练、推理、Agent 与权重更新服务拆分；slime 当前文档强调 SGLang-native 设计，并列出多轮与 fully async 示例。这些是项目当前描述，不保证任意模型、精度和硬件组合都可直接使用；具体以目标版本的支持矩阵和例子为准。

读源码时不要从整个仓库逐文件开始。只追一条最小任务：

1. 谁读配置、创建 worker 和资源组？
2. 谁抽取 task，谁启动 rollout？
3. 模型请求从哪里发出，token 和 logprobs 从哪里返回？
4. 工具 observation 如何加入上下文，loss mask 在哪里构造？
5. reward、advantage、loss 在哪里计算，如何归一化？
6. 更新后谁同步权重，什么时候切版本，checkpoint 保存了什么？

以当前 slime README 给出的路径为例，可以从 train.py 顺着 rollout 管理与训练 dispatch 往下看；verl 可从 Agent Loop 文档连接到 trainer。路径随版本变化，先固定 commit，再记录函数之间的数据契约。

10. 一个可以逐步完成的练手项目

建议做“能调用受控计算工具的多轮算术 Agent”。任务简单到可以独立验证，又足以覆盖工具等待、token mask、组内奖励、超时和版本管理。第一版不需要开放式 shell 或复杂浏览器环境。

10.1 先跑通闭环，再扩大规模

准备程序生成的算术任务，按表达式模板或复杂度区分训练与评估；工具使用受限解析器或预定义操作，不用任意代码执行。允许模型经过若干轮工具调用后提交答案，以独立计算器比较结果。

按下面顺序增加复杂度：

阶段	实现内容	验收结果
A	Mock 模型 + 本地环境	reset、step、超时、轨迹保存与去重可验证
B	固定真实模型，仅推理	每次调用的 token、工具结果和结束原因可追踪
C	小规模同步 GRPO	reward、advantage、mask、loss 和参数更新连通
D	多个并发 rollout	吞吐提高时，任务覆盖与轨迹契约仍正确
E	Learner / rollout 解耦	记录版本滞后，并比较同步与异步的效果

先选择目标框架官方示例已经支持的小模型和精度。不要仅凭“某参数量模型能推理”就判断它也能完整 RL 训练：多副本、优化器、KV 和激活都会增加需求。

10.2 用六个不变量检查正确性

• 每段用于训练的 action token 与对应 rollout 记录一致。
• 工具输出和 padding 的策略 loss mask 为 0，目标 action 按设计为 1。
• 版本一致时，训练与推理 logprobs 的差异在选定精度和后端允许范围内，并被记录。
• group 的任务归属、样本数和 reward 归一化符合算法定义。
• checkpoint 恢复后不悄悄重复消费已训练轨迹，评估任务不混入训练。
• 同时报告独立评估成功率、资源成本和失败分类，而非只展示训练 reward。

这些检查比“程序跑完且 loss 有数值”更能说明实现可信。logprob 不必逐 bit 相同，但容差应通过固定输入、固定权重的对照测量确定，不能随意设大。

10.3 做三组有解释力的实验

实验一：并发扫描。固定模型、任务集合和长度预算，比较并发 1、4、8、16。画完成轨迹/秒、p95 时长、KV 占用和超时率，找出吞吐开始饱和的位置。

实验二：长尾注入。人为让少数工具调用变慢，比较整批 barrier 与持续补充任务两种调度。检查是否因只采纳快任务而改变任务分布。

实验三：策略滞后。比较同步与不同滞后上限的异步配置，同时画横轴为 wall-clock 与累计训练 token 的评估曲线。前者看实际效率，后者帮助区分系统加速与数据效率变化。

应保存配置、commit、随机种子、样本长度分布和原始指标。本文没有实际执行这些 GPU 训练实验，因此不提供未经测量的加速或收敛结论。

11. 八周学习路线与资料清单

下面按每周约 6–10 小时设计；已有基础可以合并阶段。目标是每周产出一个可检查的结果，而不是收集更多链接。

周次	主题与优先资料	本周产物
1	CS336 基础、Profiler	小模型 forward/backward trace 与显存账本
2	FlashAttention、ZeRO、FSDP2	单卡 / 分片状态对照，解释显存峰值来源
3	Megatron 并行指南、NCCL	并行拓扑图、global batch 推导、通信时间线
4	PagedAttention、SGLang、vLLM 指标	不同长度与并发下的推理曲线
5	PPO、DeepSeekMath / GRPO、HybridFlow	一条 RL 样本从采样到 loss 的数值推演
6	verl Agent Loop、多轮 rollout	计算工具 Agent、segment schema 与 mask 检查
7	AReaL 论文、slime、Rollout Correction	同步 / 异步调度对照与策略滞后分布
8	Agent Lightning v1.0、Ray 调度、Checkpoint	故障注入、恢复说明和完整实验报告

只有笔记本时：先完成 CPU/mock 环境、数据契约、队列、数值算例和源码阅读；这些足以理解闭环。真实 CUDA kernel、NCCL 多卡通信和大模型性能需要对应硬件验证。Apple Silicon 上可做概念实验，但其性能不能直接代表 NVIDIA 集群。

有单张 GPU 时：优先小模型推理 profiling 与紧凑的训练实验；是否容纳全参 RL，要先按实际框架测显存。LoRA 可以减少可训练状态，但不能消除基座权重、激活、KV 和后端兼容性问题。

有多卡时：先把单卡基线做好，再验证分片、通信与训练推理分离。第一轮实验不要同时引入大模型、MoE、超长上下文和 fully async，否则难以归因。

12. 用问题检查自己是否真的理解了

观察到的现象	首先收集的证据	可验证的假设
训练 OOM	参数状态、激活、临时峰值分别占多少	状态分片不够，或 sequence / microbatch 过大
rollout OOM	活跃请求长度、KV 占用、缓存回收	并发与上下文预算超过容量
GPU 很闲	模型、工具、队列、CPU 的时间线	卡在环境或数据，不在矩阵计算
多卡反而更慢	collective 耗时、rank 间差异	通信盖过计算，或拓扑 / 负载不合适
reward 上升但评估下降	独立评估、verifier 版本、任务覆盖	奖励漏洞、分布偏移或过拟合
异步更快但更难收敛	样本年龄、版本差、ratio、丢弃率	策略陈旧或偏向快任务
同权重 logprob 不一致	token IDs、模板、精度、采样变换	输入或概率语义不一致，或数值后端差异
重启后曲线异常	optimizer、RNG、队列和消费记录	只恢复了权重，或重复使用样本

最终应该能回答四个问题：一张 GPU 的显存被谁占了；一个 step 的时间被谁花了；一条轨迹为什么能用于当前更新；一次成功率提升花了多少真实资源。

这四个问题把大模型 Infra 与 Agentic RL Infra 连在一起。学习的终点不是背下所有框架名称，而是能沿着 token、参数、奖励与时间线，解释系统为什么正确，以及下一步该优化哪里。