将模型规格与异步非共卡 Rollout 策略转化为可测量系统约束

你好。上一课我们把训练性能拆成了有效 FLOPs、实际 FLOPs、HBM 访问、通信 payload 与关键路径时间，并建立了吞吐、MFU/HFU、扩展效率和暴露通信占比的统一口径。

现在进一步把目标从一句“训练一个 5T MoE”变成工程上可验证的约束集。这里的重点不是立刻选定 TP、PP、CP、EP 的具体数值；拓扑、HBM 容量、模型层数与隐藏维度尚未确定，过早给出一个“最终并行方案”反而会制造伪精确。我们要先得到一份约束合同：任何候选映射、8/64 卡缩比实验和未来千卡方案，都必须能回答同一组内存、计算、通信、数值与异步协同问题。

1. 从产品规格变成系统变量

先把目标中已经确定的量写成符号：

类别	已知目标	工程含义
总参数量	$P_{total} = 5 \times 1 0^{12}$	决定全局权重、梯度、优化器状态与发布体积
专家数	$E = 384$	决定专家参数的放置、路由容量和 EP 组规模候选
路由	$k = 16$	每个 token 会产生 $16$ 个 token-expert assignment
最大上下文	$S_{m a x} = 131072$	决定注意力计算、激活、KV Cache 与 CP 压力
训练精度	BF16 / FP8 候选	决定计算路径、通信字节、缩放元数据和数值验收
rollout 部署	异步、独立资源池、非共卡	决定吞吐供需、权重版本发布与故障域

还必须补充一组待定但不可省略的输入。没有它们，就无法从“5T”得到设备数或带宽需求：

{L, h, h_{ffn}, n_{heads}, n_{kv}, q_{shared}, B_{global}, B_{micro}, γ, M_{HBM}, P_{peak}, B_{link}}

其中：

$L$ ：层数；
$h$ ：hidden size；
$h_{ffn}$ ：单专家 FFN 中间维度；
$n_{heads}$ 、 $n_{kv}$ ：注意力头与 KV 头数；
$q_{shared}$ ：总参数中共享参数的比例；
$B_{global}$ 、 $B_{micro}$ ：全局 batch 与 microbatch；
$γ$ ：专家容量因子；
$M_{HBM}$ ：单卡可用于训练的 HBM 预算；
$P_{peak}$ 、 $B_{link}$ ：目标精度下有效计算峰值与各层级互联带宽。

这里的“可用于训练 HBM”不是硬件标称 HBM。它应扣除运行时、通信缓冲、碎片化余量、CUDA/PyTorch 或 ASIC runtime 预留、profiling buffer、checkpoint staging buffer 等空间。

工程原则：规格不是结论，而是一个可代入测量值的模型。

2. 5T 的第一道硬约束：模型状态总账

对于 BF16 训练、FP32 master weight、FP32 Adam 一阶和二阶矩、以及 BF16 梯度，一个常见的理论模型状态预算是：

状态	每参数字节数	5T 参数的全局总量
BF16 训练权重	$2$ B	$10 TB$
BF16 梯度	$2$ B	$10 TB$
FP32 master weight	$4$ B	$20 TB$
Adam $m$ 与 $v$	$8$ B	$40 TB$
合计	$16$ B/参数	$80 TB$

因此：

M_{state, global} \approx 16 P_{total} = 80 TB

若梯度长期保留为 FP32，则总额会进一步接近：

18 P_{total} = 90 TB

这不是某个框架的特性，而是一个非常有用的下界级别信号：即使完全分片，5T 的训练状态在全局范围内也需要数十 TB 级存储。分片不会消灭这笔账，只会改变每张设备承担其中的哪一部分，以及何时临时物化参数。

若理想地把 $80 TB$ 均匀分到 64 卡：

\frac{80 TB}{64} = 1.25 TB/device

这还没有包括激活、临时 tensor、通信 buffer 和运行时空间。因此，除非单设备实际可用 HBM 超过这一量级，否则 64 卡不可能直接承载完整 5T BF16+Adam 训练状态。这意味着：

8 卡和 64 卡的职责应是验证并行语义、通信模式、数值路径与性能模型；
千卡或更大规模才可能是完整 5T 训练映射的候选；
如果考虑 CPU/NVMe offload，必须把 offload 带宽和恢复时间写进关键路径模型，不能把它视作“免费内存”。

对于一个给定训练映射，真正需要验证的是：

M_{peak, i} = M_{state, i} + M_{activation, i} + M_{temporary, i} + M_{comm, i} + M_{runtime, i} \leq (1 - r) M_{HBM}

其中 $r$ 是预留比例。早期可以以 $10%$ 到 $15%$ 作为实验起点，但生产阈值必须由实际碎片化、重试、权重切换和通信缓冲峰值测量校准。

Mixture of Experts — Megatron Core - NVIDIA Documentation

阅读 NVIDIA Megatron Core 文档的这部分，建立“先用内存排除不可行映射，再比较通信与计算”的工作顺序。它提供的是成熟 GPU 栈的经验框架；对新 ASIC，应将其中的带宽域和实现假设替换为实测数据。

在 “Best Practices to achieve high performance on MoE training” 下，先读 “Step 1: Find the feasible parallel mapping under the memory capacity of the GPU”。从三类内存的说明和紧随其后的表格开始，关注 TP、EP、PP、CP、DP 分别如何影响激活、权重和优化器状态。然后继续读 “Step 2: Select Optimal Parallelism Strategy” 的 Guideline 1、2、3、4、5，直到 “Step 3” 前的结尾。尤其把并行选择原则翻译成待验证假设：哪些高通信并行组必须被限制在高带宽域内，哪些维度可以跨较慢链路扩展。

3. “5T 总参数”不等于“每个 token 计算 5T 参数”

MoE 的价值和系统难点都来自这个区别。

将总参数拆为共享参数和专家参数：

P_{total} = P_{shared} + P_{expert}

令共享参数占比为：

q_{shared} = \frac{P _{shared}}{P _{total}}

则一个 token 的近似激活参数量为：

P_{active} = P_{shared} + \frac{k}{E} P_{expert}

代入 $E = 384$ 、 $k = 16$ ：

\frac{k}{E} = \frac{16}{384} = \frac{1}{24}

所以：

P_{active} = [q_{shared} + \frac{1 - q _{shared}}{24}] P_{total}

如果暂时做一个“专家参数占绝大多数”的粗略估计，即：

q_{shared} \approx 0

那么每 token 激活专家参数约为：

P_{active} \approx \frac{5 T}{24} \approx 208.3 B

这不是最终模型 FLOPs 的精确值，因为 attention、共享 FFN、embedding、router 和输出 head 都尚未纳入；但它已经揭示了关键矛盾：

存储、优化器和发布仍必须面对完整的 $5 T$ ；
每 token 的专家计算只激活约 $1/24$ 的专家参数；
网络流量由 token 被送往何处决定，而不是简单地由总参数量决定；
系统不能只按“模型参数很大”设计，也不能只按“激活参数较小”设计。

因此，每个性能报告都应同时保留三种不同的规模口径：

名称	定义	用途
总参数量	$P_{total}$	状态内存、checkpoint、发布、训练成本
激活参数量	$P_{active}$	单 token 计算量、有效 FLOPs
assignment 数	$k U$	router、token 重排、All-to-All 与 Grouped GEMM 压力

这里 $U$ 是某 MoE 层路由域内的有效 token 数。不要把 assignment 数当成训练 token 数；Top-16 下，一个有效 token 会对应 16 个 assignment。

Stanford CS336 Language Modeling from Scratch | Spring 2025 | Lecture 4: Mixture of experts

观看 Stanford Online 的 “Stanford CS336 Language Modeling from Scratch | Spring 2025 | Lecture 4: Mixture of experts” 中关于 Top-K 路由的部分。目标是建立 token、专家、路由权重与聚合结果之间的精确对应关系，为后面的容量和 All-to-All 账本打基础。

观看 Top-K 路由。重点跟住三个对象：每个 token 产生的专家选择、所选专家输出如何按路由权重组合、以及 k 增大为何同时增加计算和分发压力。观看时将讲解中的 Top-K 替换为目标配置 k=16，并留意“专家总数变大”与“每 token 激活专家数变大”是两种不同变化。

4. 384 专家、Top-16：把路由变成容量与网络约束

假设某个 MoE 路由域中有 $U$ 个有效 token。Top-16 会产生：

N_{assignment} = k U = 16 U

个 token-expert assignment。

若路由完全均衡，则每个专家的平均 assignment 数为：

a ˉ_{expert} = \frac{k U}{E} = \frac{16 U}{384} = \frac{U}{24}

例如，一个包含 $B$ 条完整 $128 k$ 序列的路由域有：

U = B \times 131072

则：

a ˉ_{expert} = \frac{B \times 131072}{24} \approx 5461.3 B

也就是说，即使只有一条完整 $128 k$ 序列，均衡情况下每个专家也会接收约 $5461$ 个 assignment。这是良好的 Grouped GEMM 形状还是过大的局部峰值，取决于 $h$ 、 $h_{ffn}$ 、EP 放置和 HBM 临时 buffer；不能只看 token 数下结论。

若采用容量因子 $γ$ ，每专家的固定容量通常近似为：

C = ⌈ γ \frac{k U}{E} ⌉

容量利用率是：

η_{capacity} = \frac{k U}{E C}

理想均衡且 $γ = 1$ 时：

η_{capacity} \approx 1

若 $γ = 1.25$ ，即使完全均衡，固定容量槽位中也只有约：

η_{capacity} \approx \frac{1}{1.25} = 80%

被有效 assignment 使用。其余 $20%$ 是为负载波动预留的空间；在当前 ASIC 仅支持 whole-group 定长 All-to-All 的条件下，它可能直接成为真实通信字节和 HBM buffer 的一部分。

设 hidden state 宽度为 $h$ ，传输精度为每元素 $q$ 字节。仅计一次 dispatch 与一次 combine，所有有效 assignment 的理想数据量近似为：

V_{useful} \approx 2 k U h q

若固定容量实现要求为全部专家预留 $C$ 个槽位，则一个简化的全局传输下界变为：

V_{fixed} \approx 2 E C h q

因此，容量造成的最小放大因子约为：

\frac{V _{fixed}}{V _{useful}} \approx \frac{E C}{k U} = \frac{1}{η _{capacity}}

实际 whole-group 定长 All-to-All 可能更差，因为还会受到每个源 rank 到每个目的 rank 的固定 buffer 形状约束。也就是说，上述公式应当被视为容量填充的乐观下界，而不是对通信库 payload 的最终预测。

这立刻给出三个必须持续采集的指标：

a_{e} = 第 e 个专家的 assignment 数

CV_{expert} = \frac{std ( a _{e} )}{mean ( a _{e} )}

ρ_{padding} = \frac{V _{actual} - V _{useful}}{V _{actual}}

其中：

$a_{e}$ 用于发现热点专家；
$CV_{expert}$ 用于量化负载倾斜；
$ρ_{padding}$ 用于量化定长通信浪费。

对于你的 ASIC，MoE 通信库的阶段性验收不应只写“支持 All-to-All”，而应写成：

支持指定 EP group 上的定长 whole-group All-to-All；
可报告每个 peer 的发送与接收字节；
可报告 collective 的 p50、p95、p99 延迟；
可报告因 capacity padding 和 per-peer padding 产生的额外字节；
后续支持变长或稀疏 token dispatch，使实际 payload 随真实路由分布变化，而非被最大容量主导。

5. 128k 上下文：先约束峰值，再讨论吞吐

$128 k$ 是：

131072

个 token，而不是“稍长一点的序列”。对 decoder-only Transformer，它带来至少三类压力。

注意力计算仍随序列长度的平方增长

即使采用 FlashAttention 类实现，不再物化完整的 attention score 矩阵，因果注意力的核心计算规模仍与：

S^{2}

相关。因此，FlashAttention 解决的是 attention score 的显式存储问题，而不是让 $128 k$ 的注意力计算变成线性复杂度。

这意味着测试中必须区分：

短序列吞吐测试：主要验证 GEMM、MoE dispatch 和基础通信；
真实 $128 k$ 序列测试：验证 attention、激活、CP 通信和长尾；
相同总 token、不同 packing 形状的测试：区分“总 token 数很多”与“单序列很长”的系统行为。

一个由大量 $2 k$ 序列组成的 batch，不能代替一条 $128 k$ 序列。

激活与 KV 状态需要按上下文维度分片

训练时，需要控制 attention 激活、残差流、checkpoint 重算输入和临时 buffer 的峰值；rollout 时，则需要特别关注 KV Cache。单条序列、单层 BF16 KV Cache 的近似大小为：

M_{KV, layer} \approx 2 S n_{kv} d_{h} q

其中：

前面的 $2$ 分别表示 K 和 V；
$n_{kv}$ 是 KV head 数；
$d_{h}$ 是每个 head 的维度；
BF16 下 $q = 2$ 。

所有层、所有并发生成请求都会叠加。因此，rollout 池必须以“并发序列数 $\times$ 上下文长度 $\times$ 生成长度”来建模，而不是只按模型权重大小分配显存。

CP 是长期上下文下的必要候选，而不是可选装饰

下面的图展示了 TP 与 CP 组合时一个 Transformer 层的执行组织：不同 GPU 对持有不同 sequence chunk，Transformer 子算子之间插入 AllGather、ReduceScatter 等通信，使每台设备不必永久持有完整序列状态。

图中 GPU0/1 处理 sequence chunk 0，GPU2/3 处理 sequence chunk 1；同一上下文分片内还叠加张量并行。黄色块表示 AllGather/ReduceScatter 等集合通信，说明 CP 降低本地序列状态的同时，会将通信插入注意力和线性层的执行路径。

若 CP 大小为 $c$ ，理想情况下每张设备承载的局部序列长度约为：

S_{local} \approx \frac{S}{c}

因此：

S_{local} = \frac{131072}{c}

但 CP 不是“把内存除以 $c$ 就结束”。你还必须测量：

各 CP rank 的实际激活峰值；
causal mask 导致的 rank 间工作不均衡；
CP collective 的有效带宽与暴露时间；
CP 与 TP、EP 是否跨越了慢链路；
CP 通信是否被 attention 或其他计算真正隐藏。

对于低带宽 ASIC，建议将下面的不等式写进候选配置准入条件：

T_{CP, exposed} \leq ϵ_{CP} T_{step}

其中 $ϵ_{CP}$ 不是预设常数，而是你们根据整体 MFU、吞吐目标和成本模型设定的允许暴露比例。关键是让它成为可测条件，而不是一句“尽量 overlap”。

6. 把低带宽风险写成 EP 的计算—通信比

对一个简化的 SwiGLU MoE expert 层模型，MegaScale-MoE 给出了 EP 计算时间与通信时间的近似比：

R_{EP} \approx \frac{3}{2} h_{ffn} \frac{B _{link}}{P _{peak}}

这里应使用同一精度、同一单位口径下的有效链路带宽与有效计算吞吐，而不是硬件宣传峰值。

这个表达式有一个非常重要的含义：在理想均衡、忽略额外调度成本的近似下，能否隐藏 EP 通信，主要取决于：

专家 FFN 的中间维度 $h_{ffn}$ ；
ASIC 的计算能力；
ASIC 的有效互联带宽。

而不是单纯取决于总专家数、Top- $k$ 或 batch 大小。

若：

R_{EP} > 1

则专家计算在理论上有机会覆盖通信；若：

R_{EP} < 1

则即使路由完全均衡，EP All-to-All 也很可能出现在关键路径上。

但它只是一个筛选指标，不能替代 profile。真实系统还会受到以下因素影响：

whole-group 定长通信的 padding；
Top-16 引发的更高 assignment 压力；
Grouped GEMM 的小矩阵碎片化；
router、permute/unpermute 的访存；
同时发生的 DP、TP、CP、PP 通信竞争；
最慢专家和最慢 rank；
通信引擎与计算核是否争用片上资源。

因此应建立两个版本的比值：

R_{ideal} = \frac{T _{expert compute, model}}{T _{A2A, model}}

R_{measured} = \frac{T _{expert compute, actual}}{T _{A2A, actual}}

前者用于架构筛选，后者用于找 ASIC、通信库和算子实现的差距。

Mixture of Experts — Megatron Core - NVIDIA Documentation

阅读 “FP8 Training” 和 “FP8 Recipes” 两张表，把 FP8 从一个笼统的“更低精度”概念，转化为激活、参数通信、EP dispatch 与缩放元数据的具体约束。文中列出的实现选项依赖 NVIDIA 软件栈；对目标 ASIC，应将其视作能力清单，而非可直接照搬的配置。

在 “FP8 Training” 小节，阅读从三面性能墙的表格开始，再读紧随其后的 “FP8 Recipes” 表。重点记录三件事：FP8 可使哪些 payload 的原始字节数减半；缩放粒度为何会改变元数据与实现成本；训练主路径和 rollout 权重发布路径不必采用完全相同的精度方案。

7. BF16 训练、FP8 rollout：发布不只是一次 cast

对完整 5T 参数模型而言，原始权重 payload 为：

V_{BF16 weight} = 2 P_{total} = 10 TB

若 rollout 使用 FP8 权重，则 FP8 权重数据本身约为：

V_{FP8 weight} = P_{total} = 5 TB

这解释了为什么 BF16 到 FP8 的转换对 rollout 池有吸引力：原始权重数据量近似减半。但不能遗漏缩放元数据、量化 kernel、重分片缓冲和校验副本。

例如，若权重按 $128 \times 128$ block 进行缩放，忽略边缘 padding，则 scale 数量约为：

N_{scale} \approx \frac{P _{total}}{128 \times 128} = \frac{5 \times 1 0 ^{12}}{16384} \approx 3.05 \times 1 0^{8}

若每个 scale 使用 FP16：

M_{scale} \approx 0.61 GB

其字节量相对 $5 TB$ 权重较小，但 scale 的布局、读取方式、更新和校验仍可能影响 kernel 融合与运行时复杂度。真实数值还会受矩阵边界、padding 和不同层缩放策略影响。

完整发布延迟至少可表示为：

T_{publish} = T_{quantize} + T_{reshard} + T_{transfer} + T_{verify} + T_{activate}

其中传输下界为：

T_{transfer} \geq \frac{V _{FP8 release}}{B _{effective}}

这里的 $B_{effective}$ 必须是端到端有效吞吐：它已经包含链路竞争、源端读取、目的端写入、协议开销、分片布局不一致和校验影响。

因此发布系统应明确记录一个版本清单：

字段	作用
`train_version`	对应的 BF16 训练权重版本
`rollout_version`	rollout 池实际激活的版本
`fp8_format`	FP8 格式与转换规则
`scaling_recipe`	逐 tensor、逐通道或分块缩放配置
`sharding_layout`	训练端与 rollout 端的分片布局
`checksum`	权重与 scale 元数据校验
`activation_time`	rollout 池原子可见的时间
`rollback_parent`	可回滚版本

必须特别避免下面这种中间状态：

rollout 请求的一部分 expert 使用版本 $v$ ，另一部分 expert 使用版本 $v + 1$ 。

在 MoE rollout 中，这会造成单个 token 的多专家输出来自不同策略，后续很难解释 logprob、奖励和训练样本版本。正确约束是：一个请求从 prefill 到 decode 完成期间，必须绑定单一 rollout 权重版本。

8. 异步、非共卡 rollout：把两个资源池视为两个独立系统

训练池和 rollout 池不共卡，带来了清晰的故障域和资源隔离，但也使得“总卡数足够”不再等于“RL 系统稳定”。

令：

R_{rollout, accepted}

表示 rollout 池经过生成、奖励计算、过滤和版本检查后，实际进入训练队列的有效 token 速率；令：

R_{train, consume}

表示训练池消费 RL 样本的有效 token 速率。

长期稳态至少要求：

R_{rollout, accepted} \geq R_{train, consume}

若不成立，训练池会周期性等待样本，实际 step time 应写为：

T_{step, actual} = T_{step, compute} + T_{sample wait}

即使训练 kernel 的 MFU 很高，端到端 RL 产能仍然会低。

反过来，若 rollout 长期显著快于训练，队列会积压；样本使用时的策略版本差将增加。可定义最直接的版本陈旧度：

Δ v = v_{train, current} - v_{rollout, sample}

并同时记录时间陈旧度：

Δ t = t_{consume} - t_{generate}

以及 token 陈旧度：

Δ N = N_{train tokens advanced}

三者都应进入样本数据契约。不同算法对它们的敏感度不同；在当前阶段，不需要预设 PPO、GRPO 或未来算法的统一阈值，但必须让系统具备按版本差、时间差或 token 差接收、降权和丢弃样本的能力。

异步非共卡设计因此形成四条可测约束：

供给约束

R_{rollout, accepted} \geq R_{train, consume}

发布约束

T_{publish} \leq T_{staleness budget}

队列约束

Q_{m i n} \leq Q (t) \leq Q_{m a x}

其中 $Q (t)$ 是可消费样本队列中的有效 token 数。

版本一致性约束

\forall trajectory, v_{policy} = constant

也就是一条轨迹内部不能混合权重版本。

9. 一份可落地的“5T MoE 约束合同”

从现在开始，每一个候选模型映射或缩比实验，都应输出以下表格，而不是只报告“能跑”或“tokens/s”。

约束域	必须记录的量	可验证判定
模型结构	$L, h, h_{ffn}, E, k, q_{shared}$	可复算总参数、激活参数和每层工作量
长上下文	最大真实序列长度、有效 token、CP size、attention 实现	至少有包含真实 $128 k$ 序列的测试
训练状态	权重、梯度、master weight、optimizer、激活、通信 buffer 峰值	$M_{peak, i}$ 不超过可用 HBM 预算
MoE 路由	$a_{e}$ 的 min/mean/p95/max、容量利用率、丢弃率	负载倾斜与溢出可定位到专家和 rank
EP 通信	dispatch/combine 字节、padding 字节、有效带宽、暴露时间	fixed-size All-to-All 浪费可量化
计算效率	有效 tokens/s、MFU、HFU、Grouped GEMM 形状	区分计算低效与通信等待
精度	BF16 基线、FP8 格式、缩放元数据、误差统计	loss、logprob、router 和输出通过验收
权重发布	量化、重分片、传输、校验、切换耗时	$T_{publish}$ 满足陈旧度预算
异步协同	rollout 供给、训练消费、队列长度、版本差	无持续饥饿、无不可接受样本陈旧
拓扑	每个 TP/CP/EP/DP/PP group 的物理位置	高通信组不在未经验证的慢链路上扩展

一个很实用的工程交付物，是维护三份配置清单：

模型清单：模型形状、MoE 结构、精度与路由策略；
映射清单：DP、TP、PP、CP、EP 的大小及其物理放置；
运行清单：global batch、microbatch、容量因子、重算、通信 overlap、版本策略。

只有当三份清单与 profile 数据绑定，性能回归才是可复现、可归因的。

小结

这一课把目标规格转成了可测系统约束：

$5 T$ 总参数在常见 BF16+FP32 Adam 训练状态下，对应约：

80 TB

的全局状态总账；64 卡应定位为缩比验证平台，而非默认的完整 5T 训练承载方案。

$384$ 专家、Top-16 意味着每个 token 产生：

16

个 assignment；在均衡路由下，每专家平均接收：

\frac{U}{24}

个 assignment。

$128 k$ 上下文要求单独验证真实长序列，而不能用同 token 数的短序列 batch 替代；CP 是关键候选，但其通信与负载均衡必须实测。
在定长 whole-group All-to-All 下，容量因子不仅影响训练质量，也会直接放大通信 buffer 与实际 payload。
BF16 训练到 FP8 rollout 的发布链路必须计入量化、重分片、传输、校验和原子切换；FP8 将原始 5T 权重 payload 从约 $10 TB$ 降至约 $5 TB$ ，但不是“无成本转换”。
异步非共卡 rollout 的核心不是把两个池子分别跑快，而是同时满足供给、队列、发布和版本一致性约束。

下一课将进入分布式通信模型：用 $α$ - $β$ 模型定量估算 P2P、AllReduce、AllGather、ReduceScatter 和 All-to-All 在候选 ASIC 拓扑上的时间，并将今天的 payload 账转成带宽与时延需求。

Recommended resources