AI Infra

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 暴露，而是在训练一段时间后才出现。 ...

本篇目标：了解 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。 ...