LLM System: 算法和 Infra 交织的 RL 杂谈 01 - RL Align 会议纪要与一点思考（AI 总结）

Sun, 21 Jun 2026 00:00:00 +0800

RL AIGC 开发者交流纪要：从模型适配到异步训练系统

这次交流的核心不是单一算法，而是 RL AIGC 训练在工程落地中的系统问题。整体看下来，主要矛盾是：RL 链路把训练、推理、数据流、权重同步、checkpoint 和调试工具全部耦合在一起，而现有框架对这些问题的支持还不够完整。让AI总结了一下会议纪要。

1. 多模态 RL 的更新稳定性

多模态 RL 中，有一种做法是：如果某次参数更新和当前模型之间的 diff 超过阈值，就直接舍弃这次更新。

这个机制可以避免异常 update 破坏模型状态：

异常 batch / 异常 reward / 异常 rollout
 ↓
参数更新过大
 ↓
超过阈值后舍弃本次更新

但它只能止损，不能解释问题来源。真正需要的是面向 RL 的 debugger，能够定位是 reward、logprob、rollout、并行切分还是权重同步出了问题。

2. 新模型接入成本高

如果要把一个新模型接入 RL 训练框架，往往需要手写 Megatron、FSDP 或其他并行逻辑的适配。

难点不只是 forward 能跑，而是整个 RL 链路都要对齐：

模型结构
并行切分
checkpoint / reshard
rollout 权重同步
logprob 计算
loss 计算
训练侧和推理侧的数据格式

RL 场景下，模型适配错误不一定马上报错，很多时候只表现为训练逐渐崩掉。因此新模型适配需要更强的调试工具，比如检查权重版本、logprob 对齐、reshard 正确性和并行切分一致性。

3. RL 训练周期长，问题复现成本高

RL 训练周期通常很长，一个周期可能需要几天。很多问题不会在前几个 step 暴露，而是在训练一段时间后才出现。

LLM System: Transformer Engine 01 - 在 AI Infra 技术栈中的位置

Thu, 21 May 2026 06:10:00 +0800

本篇目标：了解 Transformer Engine 的技术定位，搞清楚它为什么存在，以及它和 PyTorch、cuBLAS、Megatron-LM 的边界。

基本接口

Layer 类定义接口非常直接，最表层的使用方式就是把 torch.nn 模块替换成 transformer_engine.pytorch 模块。

普通 PyTorch 写法：

self.linear = torch.nn.Linear(hidden_size, 4 * hidden_size)

TE 写法：

import transformer_engine.pytorch as te

self.linear = te.Linear(hidden_size, 4 * hidden_size)

量化上下文：

from transformer_engine.pytorch import fp8_autocast

with fp8_autocast(enabled=True):
 y = module(x)

进入 TE 的 FP8 上下文之后，TE 会围绕量化、反量化、fused path、tensor cache 和 backend 选择做一系列处理。相较于纯 PyTorch 计算图优化，TE 会拿到更多信息 tensor parallel、sequence parallel、FP8 recipe 等。这些额外信息给底层算子优化留下了空间。

这一点目前还是比较 general 层面的认知，后面要继续顺着源码和 profiler trace 去验证。

TE 和 Megatron 的边界

Megatron-Core 负责模型并行、训练 loop、optimizer、activation checkpoint、MoE routing、pipeline schedule 和 config。

AI Infra on Echo的技术博客