适用读者：做 RL 训练平台、或要回答"模型为什么这样设计"的工程/架构人员。
前置：S23-J02、S22（Agent 工程）、S20（注意力机制）。
覆盖旧文：A-1988 → 26 点（RL 训推分离、SeamlessFlow、算术强度、roofline、AFD 联合设计）。
扩展点：E-S23-006（算术强度与 roofline 的计算）、E-S23-007（训推分离的气泡与资源标签）。
上一篇：S23-J02 · 分布式推理：PD 分离、DOPD 与 AFD
下一篇：S23-J04 · TileLang 与算子开发。
1. 一句话结论
RL 训练和推理是两种"性格相反"的负载：硬绑在一起，谁都不好优化；完全分开，又会产生算力气泡。真正的解法不是二选一，而是"可切换的资源池 + 一条记录全部输入输出的数据平面"。
| 阶段 | 负载特征 | 优化目标 |
|---|---|---|
| RL 训练（梯度更新） | 计算密集、通信密集（并行策略复杂） | 吞吐 / 收敛 |
| 推理（生成轨迹） | 访存密集、延迟敏感 | TTFT/TPOT、并发 |
| Agent 处理（调用 LLM 前后） | I/O 与状态密集 | 一致性、可恢复 |
2. RL 训推分离与"气泡"（§2）
原文的推理链：
- RL 的数据集由推理产生（模型 rollout），或推理 + 人工标注；
- 同集群混部部署/调度简单，但问题明显：两阶段优化思路不同、耦合后互相干扰；硬件需求不同，无法用异构硬件提升性价比；一方异常会波及另一方；
- 分离后又出新问题：推理输出要经 Agent 复杂处理，训练与推理的时序依赖造成"气泡"式算力浪费（一方等另一方）。
SeamlessFlow 的两个设计（原文给的方案）：
| 问题 | 方案 | 关键点 |
|---|---|---|
| 一致性：轨迹（Agent 与 LLM 的全部输入输出）要可追溯 | 在 Agent 与 LLM 之间加数据交互平面，核心是轨迹管理器 | 精准记录全过程；对 Agent 完全透明 |
| 气泡：分开后资源互相等待 | 不选边，用标签机制给资源标任务，按需在推理/训练间切换 | 资源可在两阶段间流动，消除等待 |
2.1 气泡与资源标签（E-S23-007）
气泡 = 资源在"等别人"的时间 / 总时间
来源：① 训练等 rollout 数据；② 推理等新权重；③ Agent 后处理等 LLM 返回
消除手段（按成本从低到高）：
1) 流水线重叠：上一批数据在训练时，下一批已经在推理
2) 资源标签 + 抢占：把空闲资源临时切给另一阶段（需可中断的任务粒度）
3) 异构资源池：训练/推理各用最合适的卡，靠调度器分配
判据：记录一次完整 RL step 的时间线（rollout、Agent 处理、训练各占多久、等待多久）。等待占比 > 30% 才值得引入标签调度；否则先做流水线重叠。
3. 算术强度与 roofline：模型设计要"贴着硬件"（§3）
原文的核心概念：算术强度 = 与显存交互平均每字节所进行的运算次数；它与 Attention 模块的设计有关，与 batch size、上下文长度无关；硬件的"算力/带宽比"（roofline）固定。
3.1 一次可复算的 roofline（E-S23-006）
roofline 斜率 = 峰值算力 ÷ 峰值带宽
例（H100 SXM 量级，厂商标称，需按实际卡核对）：
FP16 稠密算力 ≈ 989 TFLOPS；HBM 带宽 ≈ 3.35 TB/s
→ roofline ≈ 989e12 / 3.35e12 ≈ 295 FLOP/Byte
若某模块算术强度 < 295 → 带宽瓶颈（memory-bound）
若 > 295 → 算力瓶颈（compute-bound）
| 场景 | 算术强度量级 | 结论 |
|---|---|---|
| decode 阶段的 Attention（batch 小、KV 长） | 个位数 ~ 几十 | 访存瓶颈 → 量化 KV、PagedAttention 收益大 |
| 大 batch 的 FFN / 大矩阵乘 | 数百以上 | 算力瓶颈 → 换更强算力或降精度 |
3.2 协同设计的三条结论（§3）
- Attention 的算术强度应尽量接近主流硬件的 roofline——太低（纯带宽）浪费算力，太高（纯算力）浪费带宽；
- 量化会改变算术强度：不同精度下 AI 变化，若硬件池里有能匹配的卡，就能"以精度换匹配"（原文：Step-3 无论 AI 升降都有可匹配硬件）；
- AFD 下 batch 不能无限大：batch 过大 → 网络传输耗时上升 → TPOT 变差；因此要联合设计"稀疏度 / 隐状态维度 / 层数 / 卡型 / 网络带宽 / 目标 TPOT"。
判据：模型结构与部署方案必须一起评审。 只评审模型（"这个结构更强"）或只评审部署（"加卡就行"），都会在 roofline 上撞墙。
4. 前提与边界
| 结论 | 成立条件 | 不成立时 |
|---|---|---|
| 训推分离提升性价比 | 有异构硬件 + 调度能力 | 小规模、单一卡型 → 混部更简单 |
| 标签调度消除气泡 | 任务可中断、状态可保存 | 长任务不可中断 → 只能靠流水线重叠 |
| 算术强度指导设计 | 已知目标硬件的 roofline | 多卡型混布 → 取加权 roofline |
| SeamlessFlow 式数据平面透明 | Agent 侧不感知记录开销 | 记录本身成为瓶颈（高频大 payload） |
原文未给出 SeamlessFlow 的具体实现细节与性能数字，本系列按"设计思路"使用，具体收益标
needs_verification。
5. 常见误区
| 误区 | 纠正 |
|---|---|
| "训推分离是银弹" | 分离会产生气泡，需要调度与数据平面配套 |
| "算术强度随 batch 变" | 原文明确：与 batch/上下文无关，是结构属性 |
| "精度越低越快" | 精度改变 AI 与 roofline 的匹配关系，要看哪一侧是瓶颈 |
| "batch 越大吞吐越高" | AFD 下大 batch 拉高 TPOT，需按目标延迟定 batch |
6. 自测
- 用你的卡算一次 roofline（算力 ÷ 带宽），再判断 decode 的 Attention 属于哪一侧瓶颈。
- 你的一次 RL step 里，等待时间占比多少？超过 30% 吗？
- 你们的模型评审有没有"部署方案"这一节？没有 → 结构与硬件没对齐。
7. 下一篇
S23-J04 · TileLang：把数据流与调度解耦 —— 为什么算子优化需要一门"面向 Tile"的语言，三层抽象各适合谁。