AIGC 开源一周｜推理服务接入 RL 训练，Agent Rollout 走向系统化

过去一周，开源 AIGC 基础设施最值得关注的变化，不是又多支持了几个新模型，而是训练系统与在线推理服务之间的边界开始变薄。

NVIDIA Dynamo v1.3.0 把强化学习 rollout 所需的 token 直通、权重热更新和 worker 生命周期管理接进分布式推理平台；Hugging Face TRL v1.9.0 则继续拆分异步 rollout、vLLM 客户端与权重同步，并开始处理多轮 Agent 轨迹在重新分词后发生改写的问题。

两边从不同方向逼近同一个工程目标：训练时用来采样轨迹的推理服务，不再是一台临时启动、训练完就丢弃的“生成服务器”，而是逐渐成为可路由、可扩缩、可更新、可观测的长期系统。

本周结论

• Dynamo v1.3.0：新增面向强化学习的 Tokens-in-Tokens-Out、原地权重更新和 worker 管理接口，同时大幅增强 KV-aware Router。
• TRL v1.9.0：GRPO/RLOO 支持流式数据集，AsyncGRPO 增加 message-level rollout，并把 vLLM 通信与权重同步进一步解耦。
• TensorRT-LLM v1.3.0rc22：继续补齐解耦式推理、单模型推测解码和 VisualGen，但它仍是 RC，不应与稳定版能力混为一谈。
• Transformers v5.14.1 / FlashAttention 4 beta23：主要是正确性修复，提醒生产环境不能只追逐 feature release。

Dynamo v1.3.0：推理平台开始直接服务训练循环

NVIDIA 在 7 月 22 日发布 Dynamo v1.3.0。这是一次体量很大的 feature release：v1.2.1 到 v1.3.0 之间合并了 930 个 PR，来自 125 位贡献者。

最值得单独拿出来看的，不是支持模型列表，而是新增的强化学习服务路径。

TITO：避免一次没有意义的文本往返

传统 RL rollout 服务通常复用 OpenAI 风格接口：

训练进程中的 token IDs
  → detokenize 成文本
  → HTTP 请求
  → 服务端再次 tokenize
  → 模型生成
  → 文本响应
  → 训练端再次 tokenize

Dynamo v1.3.0 新增的 Tokens-in-Tokens-Out（TITO）路径直接接收和返回 token ID，同时可返回 completion token IDs、logprobs 和 routed-expert capture。

这不只是省去 tokenizer 时间。对 on-policy RL 来说，训练端必须确认自己计算 advantage 和 log-prob 的 token，正是推理服务实际采样的 token。只要中间经过文本、chat template 或不同版本 tokenizer，token 边界就可能发生变化。TITO 把这条数据链收紧了。

权重更新不再等于重启推理服务

RL 训练会不断产生新权重。如果 rollout worker 每轮都完整重启、重新加载 checkpoint，GPU 空闲时间和集群抖动都会很明显。

Dynamo v1.3.0 的 vLLM、SGLang backend 新增原地权重更新，并统一提供 sleep、wake、显存释放与恢复接口；训练端还可以通过 /v1/rl/workers 发现 rollout worker。NeMo-RL 路径可通过 NCCL 更新权重，大体形成下面这条闭环：

Trainer
  ├─ 请求 rollout
  ├─ 接收 token / logprob / expert 信息
  ├─ 更新策略模型
  └─ 向现有 worker 同步新权重
          ↓
      下一轮 rollout

这些 RL 接口目前通过 DYN_ENABLE_RL 显式开启。这个开关很重要：它说明相关能力已经进入正式 release，但仍不是默认生产路径。

Router：Agent 与长上下文正在改变路由目标

Dynamo v1.3.0 对 Router 的改造，是另一条与训练系统相关的主线。

传统负载均衡主要看 worker 当前有多忙；LLM 服务还必须看请求前缀对应的 KV Cache 在哪里。Dynamo 这次把 slot selection 独立成服务，并增加 Branch-Sharded KV Indexer、拓扑感知路由和 (worker, dp_rank) 级 affinity。

官方 release note 给出的数据是：

• compressed radix tree 的 store/remove 事件处理约快 28 倍；
• 多 frontend 场景吞吐提高 13.7%；
• prefix matching 可以跨 shard 并行。

这些是项目方在特定测试条件下报告的数据，不应直接外推到所有生产负载。但架构方向值得关注：当 Agent 请求包含长历史、多轮工具输出，并且训练 rollout 会产生大量共享前缀时，“把请求发给空闲 GPU”不再足够，路由器需要同时理解负载、KV 重合度、拓扑和优先级。

TRL v1.9.0：多轮 Agent rollout 不只是拼接 token

Hugging Face 在 7 月 21 日发布 TRL v1.9.0。这次版本的主要变化集中在 GRPO、RLOO、AsyncGRPO 和蒸馏。

流式数据集终于进入 GRPO / RLOO

过去 GRPO 和 RLOO 依赖 RepeatSampler，把同一个 prompt 重复 num_generations 次，再跨进程组成 group。但 iterable dataset 没有固定长度和随机索引，旧路径会绕过 sampler，可能在没有明显报错的情况下破坏 advantage 分组。

v1.9.0 新增 repeat_iterable_dataset，直接变换数据流而不是重排索引，并要求 iterable dataset 显式设置 max_steps。这让大型或持续生成的数据集可以不先完整落盘：

dataset = load_dataset(
    "trl-lib/DeepMath-103K",
    split="train",
    streaming=True,
)

trainer = GRPOTrainer(
    model="Qwen/Qwen3-4B",
    args=GRPOConfig(max_steps=1000),
    train_dataset=dataset,
    reward_funcs=accuracy_reward,
)

这里的关键不只是“支持 streaming”。新版实现还会保持同一 prompt 的 generations 在跨进程 gather 后仍属于正确分组，否则 GRPO 的相对优势计算会从数据层就开始出错。

Message-level rollout：承认对话历史可能被改写

AsyncGRPO 新增可选的 rollout_protocol="message"。它不会默认假设每一轮新消息在 token 层都只是追加，而是重新 tokenize 整段对话，并检查新 token 是否仍以前一轮 token 为前缀。

TRL 把结果分成三类：

• CLEAN：纯追加，可以延续当前训练行；
• REALIGN：最后一段回答出现轻微 token 漂移，覆盖当前行；
• FORK：历史发生真实改写，关闭当前行并新建一条与模型实际输入一致的轨迹。

这个设计触及了 Agent RL 中一个容易被忽略的问题：工具返回、chat template、reasoning block 和消息规范化都可能改变历史文本对应的 token。训练数据如果仍假设轨迹永远是 token append-only，就可能拿错误的上下文去解释后续动作。

vLLM 通信和权重同步继续解耦

TRL v1.9.0 新增小型 VLLMClient，统一负责 readiness、模型长度查询、pause/resume 和权重更新接口；权重同步则抽象成可注入的 WeightTransferProtocol，不再与特定 rollout worker 绑死。

这与 Dynamo 的变化可以拼成一张更完整的图：

层次	Dynamo v1.3.0	TRL v1.9.0
数据协议	token IDs、logprobs、expert capture	message/token 两种 rollout 协议
服务生命周期	worker discovery、sleep/wake、显存管理	readiness 与 rollout client
权重更新	worker 原地更新	独立 WeightTransferProtocol
扩展方向	路由、Kubernetes、KV locality	GRPO/RLOO、异步 Agent 轨迹

两者不是开箱即用的一套联合方案，版本依赖也不完全一致。Dynamo v1.3.0 的 release matrix 仍固定在 vLLM v0.23.0、SGLang v0.5.14；TRL v1.9.0 则已声明支持 vLLM v0.24.0、v0.25.0 和 v0.25.1。真正组合部署前，必须先处理版本和自定义接口兼容性。

TensorRT-LLM rc22：解耦式推理继续下沉

7 月 22 日发布的 TensorRT-LLM v1.3.0rc22 仍是候选版本。

本次值得关注的新增包括：

• disaggregated coordinator 与 multi-process orchestrator fleet；
• 单模型推测解码的 rejection sampling；
• DeepSeek DSpark 与 Laguna DFlash drafter；
• Qwen3-VL 混合图像、视频请求；
• Wan 原生 VAE 路径和 Qwen Image CUDA Graph 修复；
• 自动按模型选择 transceiver runtime，这是一项 breaking change。

它也列出了多项已知问题，包括部分 torch.compile 多 GPU 路径崩溃、DeepSeek-V3.2 FP8 block-scale 在 H200 上 OOM、Kimi K2.5 在 GB300 上的解耦 KV 传输失败等。

因此 rc22 更适合验证 DeepSeek V4、VisualGen 和解耦式推理的新路径，不适合因为“版本号更高”就直接替换生产稳定版。

两个小版本提醒：正确性修复也是性能系统的一部分

Transformers v5.14.1 在 7 月 16 日发布，主要修复 EncoderDecoderCache 辅助生成、带 position bias 的 StaticCache prefill、FP8 kernel 版本和多设备 DeepGEMM。

FlashAttention 4 beta23 在 7 月 22 日发布，只包含两个主要修复：paged-KV block table 越界检查，以及 SM100 上 FP8 e4m3 的准确性问题。

它们没有新架构发布那么醒目，却直接关系到结果是否正确。尤其在 FP8、KV Cache、CUDA Graph 和推测解码叠加后，吞吐数字只有在准确性回归通过的前提下才有意义。

本周判断

如果只记住这一周的三件事，可以是：

1. Rollout serving 正在成为独立基础设施。 token 协议、权重更新、worker 管理和路由逐渐从训练脚本中抽离。
2. Agent 训练不能再假设轨迹只是不断追加的 token。 多轮消息、工具调用和模板重写需要显式的轨迹对齐机制。
3. 训练栈和推理栈的版本矩阵会成为新风险。 TRL、vLLM、SGLang、Dynamo 和 TensorRT-LLM 各自快速迭代，接口看起来相似并不代表可以直接组合。

下一周值得继续观察两个问题：第一，TITO 这类 token 直通协议能否形成跨框架的稳定接口；第二，KV-aware routing 能否在真实 Agent 与 RL rollout 负载下给出可复现的端到端收益。

---

统计口径：本文覆盖 2026-07-16（含）至 2026-07-24（不含）由项目官方 GitHub 仓库发布的 release，并补充与主线直接相关的正式 release note。RC 与 beta 均已在正文中明确标注；项目方性能数字仅按原始口径引用，不视为跨环境通用结论。