wuyang/llm-atlas
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
main
llm-atlas/research/TRAINING_SYSTEMS_RESEARCH.md
T
wuyang 3f995101ac docs: record training systems deployment
2026-07-29 01:32:02 +08:00

44 KiB
Raw Permalink Blame History

大规模 LLM 训练系统研究账本

最后核验：2026-07-29
章节状态：一手证据账本 v1；页面与交互实验室待实现

研究问题

训练系统不是“把模型分到很多 GPU 上”这么简单。它要同时回答九个互相牵制的问题：

  1. 模型状态怎样放得下；
  2. 激活怎样留到反向；
  3. 一层矩阵怎样拆；
  4. 多层流水线怎样少等；
  5. 通信到底搬什么、搬多少、多久搬一次；
  6. MoE 的 Token 怎样去往专家；
  7. 长序列怎样跨设备；
  8. 低精度与优化器状态怎样维持数值稳定；
  9. 训练、rollout、环境和故障怎样组成可恢复的系统。

教学主线固定为：

单卡训练先撞上容量墙
→ 数据并行扩大吞吐，却复制所有模型状态
→ Tensor / Pipeline Parallel 把单个模型切开
→ ZeRO / FSDP 把数据并行中的冗余状态切开
→ 3D 并行把不同通信频率映射到不同网络层级
→ Sequence / Context Parallel 再切长序列
→ MoE 用 Expert Parallel 扩容量，却把 All-to-All 和负载不均放上关键路径
→ 调度、重计算、低精度、卸载与通信重叠成为一体化问题
→ DeepSeek-V3 用 DualPipe、拓扑感知 All-to-All 和 FP8 协同
→ Kimi K2 选择内存更稳的 interleaved 1F1B，K2.5 解耦视觉编码器
→ K3 用 MoonEP、统一激活管理、Pipeline ZeRO-2、远端激活和 P2P Muon 支撑 2.8T 预训练
→ 百万 Token Agentic RL 又把 KV、权重、梯度缓冲、沙箱与长尾轨迹放进同一张时间—内存账。

0. 先统一量纲

0.1 五种资源不能混写

量纲 问题 常用单位 不能推出什么
算术量 一步理论上做多少乘加 FLOP / step、FLOP / token 不能直接推出 wall time
容量 某一时刻要驻留多少状态 byte / GPU 不能直接推出数据搬运速度
带宽 大消息每秒能搬多少 GB/s、Gbps 不能解释小消息启动延迟
延迟 一次同步、launch、P2P 等多久 µs、ms、s 不能替代大消息带宽模型
利用率 峰值硬件有多少变成有效训练 MFU、HFU、pipeline utilization 不同论文口径未必相同

0.2 本章统一符号

符号 含义
P 模型参数个数；MoE 场景必须注明 total 还是 activated
T 训练 Token 数
B batch 相关数量；出现时注明 global / micro
S 序列长度，或在 MoonEP 原文语境中每 rank 的本地序列长度
H hidden dimension
L Transformer 层数
M 一次 collective 的逻辑消息大小
n collective 参与 rank 数
m 一个 pipeline batch 的 micro-batch 数
p pipeline stage 数
v 每设备 virtual pipeline chunks 数
E routed expert 总数
K 每 Token 选择的 routed expert 数
R expert-parallel size
b 每元素字节数

0.3 “GPU 总数等于并行度连乘”只在特定 mesh 定义下成立

只有当多个并行轴被定义为互相正交的设备网格维度时，才可以写：

world_size = axis_1 × axis_2 × … × axis_k

不能不加说明地写成：

world_size = DP × TP × PP × EP × CP

原因：

  • EP 可能只作用于 MoE 层，dense attention 又使用另一套 group；
  • expert data parallel 与普通 data parallel 的定义可能不同；
  • Megatron sequence parallel 通常与 TP 共用 process group，不是新增独立乘数；
  • context parallel 可以是独立轴，也可以与其他序列切分组合；
  • 同一 rank 同时属于多个通信 group，group 数量不等于互相独立的 mesh 轴数量。

章节中的 topology lab 必须先定义设备坐标和 group membership，再计算 world size。

1. L1：模型状态内存账

1.1 为什么“参数 2 字节”不等于“训练每参数 2 字节”

ZeRO 论文用 FP16/FP32 mixed-precision Adam 作具体例子。每个参数的持久模型状态为：

状态 精度 bytes / parameter
前反向使用的参数 FP16 2
梯度 FP16 2
optimizer master parameter FP32 4
Adam momentum FP32 4
Adam variance FP32 4
合计 — 16

因此原论文的基线是：

M_model-state = 16P bytes

这是一个指定配方的字节账，不是所有 Adam、BF16、FP8 或 fused optimizer 的宇宙常数。实际系统还可能有：

  • FP32 gradient accumulation buffer；
  • EMA 参数；
  • flat / fusion buffer；
  • quantization scale；
  • allocator fragmentation；
  • 通信临时 buffer；
  • Muon 等不同优化器的矩阵状态。

1.2 ZeRO 三阶段到底切什么

令数据并行度为 N_d，沿用 ZeRO 原论文的 mixed-precision Adam 口径：

阶段 分片对象 每 rank 模型状态近似
普通 DP 无 16P
ZeRO-1 optimizer states 4P + 12P/N_d
ZeRO-2 optimizer + gradients 2P + 14P/N_d
ZeRO-3 optimizer + gradients + parameters 16P/N_d

这里的 “1/2/3” 不是性能等级，而是逐步增加分片对象。

1.3 ZeRO 没有凭空消灭状态

ZeRO 把“每张卡长期复制完整状态”改成：

  • 只保留本 rank 负责的 shard；
  • 在某层真正需要参数时再 gather；
  • 梯度产生后 reduce-scatter 到 owner；
  • 用生命周期管理及时释放临时完整参数。

因此收益是容量，代价是更细粒度的通信、prefetch、buffer 与调度复杂度。

1.4 ZeRO 论文的通信口径

ZeRO 论文把一个 P 元素张量的 reduce-scatter 与 all-gather 各近似计为 P 的数据移动：

  • 普通 DP AllReduce：2P；
  • ZeRO-2：gradient reduce-scatter P + updated parameter all-gather P = 2P；
  • ZeRO-3：forward 参数 all-gather P + backward 参数 all-gather P + gradient reduce-scatter P = 3P。

所以 ZeRO-3 在这个口径下相对普通 DP 是最多 1.5× 通信量，而 ZeRO-1/2 不增加总量。

严格的 ring 算法每 rank 单向发送量应带 (n-1)/n：

ReduceScatter sent/rank = (n-1)/n × M
AllGather sent/rank     = (n-1)/n × M
Ring AllReduce sent/rank = 2(n-1)/n × M

“论文近似体积”“每 rank 发送量”“发送+接收总字节”必须标出统计口径，不能直接横比。

1.5 FSDP 是实现语境，不是另一套物理定律

PyTorch FSDP 的 FULL_SHARD 与 ZeRO-3 在核心目标上相近：参数、梯度和 optimizer state 都按 data-parallel rank 分片，并按执行顺序 all-gather / reduce-scatter。工程差异集中在：

  • wrapping / flat parameter 边界；
  • prefetch 时机；
  • state-dict 与 checkpoint 语义；
  • mixed precision 与 CPU offload；
  • 与模型结构、编译器和其他并行方式的组合。

课程不把 “FSDP vs ZeRO” 教成简单优劣榜。

2. L2：激活内存账

2.1 激活为什么与模型状态不同

参数主要随 P 增长；训练激活主要随：

micro_batch × sequence × hidden × layers × saved_tensors

增长。标准注意力若保存完整 attention matrix，还会出现与 S² 相关的中间量。

这解释了两个常见现象：

  • 参数能放下，不代表长序列激活能放下；
  • 增大 DP 不会自动切开同一样本的激活。

2.2 四种激活策略是一张“保留位置”账

策略 forward 后把信息放哪里 backward 前做什么 主要代价
保留 GPU HBM 直接读取 容量
重计算 不保留或只留 checkpoint 重跑部分 forward FLOPs / latency
压缩 GPU 或 CPU 的低精度表示 解压/转换 精度风险、cast
卸载 CPU / 远端 GPU / NVMe prefetch / onload PCIe / RDMA / 存储带宽

这些策略可以按 tensor 粒度组合，不是互斥按钮。

2.3 Checkpointing 的历史节点

Chen 等人在 2016 年给出系统化计算—内存交换：

  • 对 n 层网络，用分段 checkpoint 可把 feature-map memory 从 O(n) 降到 O(√n)；
  • 文中 practical algorithm 的计算开销约为一次额外 forward，即总 forward 计算约翻倍；
  • 递归方案理论上可到 O(log n) 内存，但带来更多重计算。

这条结论是复杂度结果，不等于任意 Transformer 实现都获得同一比例。

2.4 选择性重计算：不要重跑昂贵的 GEMM

2022 年 Reducing Activation Recomputation 把两个机制结合：

  1. Megatron sequence parallel：对 TP 区域中原先复制的 LayerNorm / Dropout 等激活沿 sequence 分片；
  2. selective recomputation：优先重计算 memory-heavy、compute-light 的 attention 中间量，而不是整个 Transformer layer。

论文在其模型与硬件设置中报告：

  • activation memory 减少约 5×；
  • 相比 full recomputation，执行时间 overhead 减少超过 90%；
  • full activation recomputation 在其实测训练中有 30–40% execution-time overhead。

这些数字只用于说明该实验的量级，不能当作所有模型固定收益。

2.5 FlashAttention 解决的是 IO 与显式 S² 中间矩阵

FlashAttention 用 tiling 和在线 softmax 在 SRAM/HBM 层级重排计算：

  • 不把完整 S×S attention matrix 写回 HBM；
  • attention 的结果仍是精确值，不是稀疏近似；
  • 标准 dense attention 的算术复杂度仍含 S²；
  • 它不消灭 LayerNorm、MLP、残差等其他训练激活。

所以“FlashAttention 把注意力变成线性复杂度”是错误说法。

3. L3：计算划分账

3.1 Data Parallel：切样本

每个 rank：

  • 持有一份模型；
  • 处理不同 micro-batch；
  • backward 后聚合梯度；
  • 同步更新得到等价参数。

适合：

  • 单个模型副本放得下；
  • global batch 允许扩大；
  • 每步计算足以摊薄一次梯度 collective。

主要通信频率：每个 optimizer step。

3.2 Tensor Parallel：切一层矩阵

Megatron-LM 的核心做法是让一组 GPU 共同执行同一 Transformer 层：

  • MLP 第一矩阵按输出维切，GeLU 可在本地执行；
  • 第二矩阵按输入维切，之后聚合；
  • attention heads / projections 也按兼容方向切；
  • 通过列并行与行并行组合，把同步点压到少数 collective。

优点：

  • 同一层参数、GEMM 与部分激活被切开；
  • 单个 layer 太宽时仍可运行。

代价：

  • 每层、每个 micro-batch 都通信；
  • 小 GEMM 会降低算术效率；
  • 因频率高，TP 通常放在 NVLink / NVSwitch 域内。

3.3 Pipeline Parallel：切层

把连续 layer 段放到不同 stage，只在相邻 stage 间传 activation / activation gradient。

优点：

  • 跨 stage 通信是点到点；
  • 单次传输相对 TP 可更粗粒度；
  • 适合跨节点。

代价：

  • warmup / cooldown 气泡；
  • stage 划分不均；
  • 前部 stage 常驻留更多激活；
  • micro-batch 太小会伤 GEMM，太大又减少 m、增大气泡。

3.4 3D Parallel 的核心不是“乘起来”，而是按频率放拓扑

Megatron 2021 的 PTD-P 组合：

  • TP：高频 layer 内 collective，优先节点内；
  • PP：相邻 stage P2P，可跨节点；
  • DP：每 batch 聚合梯度，可使用更大范围网络。

这是一条“通信频率—网络层级匹配”原则，不是固定唯一配置。

3.5 自动并行分支

Mesh TensorFlow、GSPMD、Alpa 等工作把人工选择的 sharding / resharding 表达为：

  • 逻辑 device mesh；
  • tensor dimension 到 mesh axis 的映射；
  • 跨 operator 的 sharding propagation；
  • 代价模型与自动搜索。

它们没有消除通信，而是系统化寻找“在哪里切、何时重分片”。

4. L4：流水线气泡账

4.1 GPipe：先所有 forward，再所有 backward

设：

  • p 个 pipeline stages；
  • m 个 micro-batches；
  • 一个 stage 处理一次 micro-batch 的 forward / backward 时间分别为 F、B；
  • stages 理想平衡且忽略通信。

GPipe 的 flush bubble 时间为：

t_bubble = (p - 1)(F + B)
t_ideal  = m(F + B)
bubble / ideal = (p - 1) / m
utilization = m / (m + p - 1)

所以 m ≫ p 才能摊薄气泡。GPipe 原论文经验上观察到 M ≥ 4K 时气泡在其设置中接近可忽略；它不是通用阈值。

4.2 1F1B：主要先省激活，不自动消除 flush

PipeDream-Flush / non-interleaved 1F1B：

  1. warmup 注入若干 forward；
  2. steady state 交替一个 forward、一个 backward；
  3. cooldown 排空剩余 backward；
  4. flush 边界后再做同步 optimizer update。

相较 GPipe：

  • flush bubble 的基本规模仍由 p-1 决定；
  • outstanding backward 的 micro-batch 数受 p 限制，而不是必须保留全部 m；
  • 因而 activation memory 显著降低。

原始 PipeDream 用异步流水与 weight stashing 处理权重版本；课程必须把它与保持严格同步语义的 PipeDream-Flush / 1F1B 区分。

4.3 Interleaved 1F1B：用 virtual chunks 缩短 bubble 单元

每设备持有 v 个非连续 model chunks：

  • 单个 chunk 的 F/B 时间约缩为原来的 1/v；
  • 理想条件下 bubble 约缩小 v 倍；
  • 但相邻 virtual chunks 增加 pipeline messages；
  • m 还需满足相应 divisibility 约束。

4.4 Zero Bubble：先拆 backward

Zero Bubble Pipeline Parallelism 把 backward 拆为：

  • B / input-gradient：前一 stage 继续反传所必需，处于关键依赖链；
  • W / weight-gradient：只需在 optimizer step 前完成，可被延后填进空隙。

这让 scheduler 能用 W 填充原本的 bubble。论文同时：

  • 构造手工 schedule；
  • 用给定模型配置与内存限制搜索 schedule；
  • 处理 optimizer synchronization，保持同步训练语义。

论文报告在其设置下，相近内存时相对 1F1B 吞吐最高提升 23%，放宽内存时最高 31%；这不是任意 PP 配置的保证。

4.5 Bidirectional pipeline：Chimera 到 DualPipe

Chimera 从 pipeline 两端同时注入相反方向的 micro-batches，利用双向 pipeline 减少 bubble。

DeepSeek-V3 的 DualPipe 进一步针对重 MoE 通信：

  • 把 chunk 拆成 attention、dispatch、MLP、combine；
  • backward 再拆 input-gradient 与 weight-gradient；
  • 把一对 forward / backward chunk 的计算与通信重排；
  • 双向注入 micro-batches；
  • 手工分配通信与计算使用的 SM。

V3 Table 2 的边界必须保留：

  • DualPipe 需要两份模型参数；
  • peak activation memory 相对表中 1F1B 多一个 stage-normalized 单位；
  • 只有在通信能被相邻计算覆盖时，通信才从关键路径上近似消失；
  • “near-zero all-to-all overhead” 不表示传输字节为零。

5. L5：Collective 通信账

5.1 先问四个问题

任何“通信量”结论都要注明：

  1. 逻辑 tensor 多大；
  2. 统计每 rank 发送、接收，还是全网 aggregate；
  3. 使用什么 collective 算法与拓扑；
  4. 每 layer / micro-batch / optimizer step 调用多少次。

5.2 α–β 教学模型

time ≈ α × rounds + β × bytes_on_critical_path
  • α：每轮启动、同步、协议延迟；
  • β：每字节传输时间，即带宽倒数；
  • 小消息更容易被 α 支配；
  • 大消息更容易被 βM 支配；
  • 拥塞、拓扑、kernel contention 与 overlap 会让真实时间偏离简单式。

5.3 四种 collective 的语义

Collective 每 rank 输入 每 rank 输出 训练常见位置
AllReduce 完整 tensor 聚合后的完整 tensor DP 梯度、TP 部分输出
ReduceScatter 完整 tensor 聚合后的 1/n shard ZeRO/FSDP 梯度
AllGather 1/n shard 完整 tensor ZeRO/FSDP 参数、sequence/TP
All-to-All 给每个 peer 的不同 shard 来自各 peer 的 shard MoE dispatch、Ulysses

P2P send/recv 则常用于 pipeline stage 邻接传输与 Ring Attention。

5.4 “总量相同”也可能快慢不同

同样约 2M 的数据：

  • 一个大 AllReduce；
  • 多层小 AllReduce；
  • 先 ReduceScatter 再延迟 AllGather；
  • 与 GEMM 重叠的 All-to-All；

会因调用次数、依赖位置、拓扑与 overlap 得到完全不同的 wall time。

6. L6：MoE / Expert Parallel 账

6.1 两次 All-to-All

典型 MoE layer：

router
→ dispatch All-to-All
→ local expert GEMM
→ combine All-to-All
→ weighted sum

近似 payload 与下列量成正比：

tokens × top_k × routed_width × bytes

还要计入：

  • capacity / padding；
  • expert metadata 与 routing indices；
  • 负载不均导致的最大 rank makespan；
  • 跨节点与节点内的不同带宽；
  • redundant expert 的权重与梯度同步；
  • dispatch / combine 是否 zero-copy。

6.2 从 GShard 到 DeepSpeed-MoE / Tutel / MegaBlocks

  • GShard：把 Transformer MoE 与大规模自动分片结合，建立 top-2 gating 与 expert parallel 的关键范式。
  • DeepSpeed-MoE：组合 data / expert / tensor parallel，并面向训练与推理优化 MoE 系统。
  • Tutel：让 parallelism 和 kernel 在运行时自适应不同 MoE 配置与硬件。
  • MegaBlocks：用 block-sparse kernel 处理动态 expert token 数，避免固定 capacity 导致的 padding 或 dropping；“dropless”仍需承受真实不均衡计算。

6.3 DeepEP 的位置

DeepEP 是 DeepSeek 开源的 expert-parallel 通信库，提供：

  • 高吞吐 dispatch / combine；
  • 低延迟模式；
  • 面向 NVLink 与 RDMA 的通信 kernel；
  • 与计算重叠所需的 hook / buffer 设计。

它优化搬运路径，但不单独解决 router 造成的每 rank 总 Token 不均。

6.4 MoonEP：从“尽量均衡”变成“存在性保证”

K3 §5.2.1 定义：

  • E：experts；
  • R：EP ranks；
  • 每个 rank 本地有 S 个 Token；
  • 每 Token 选 K 个专家；
  • 全部 expert assignments 为 S×K×R；
  • 完美 rank balance 要求每 rank 最终恰好收到 S×K 个 assignments。

MoonEP 对当前 micro-batch、当前 layer 的 router output 在线规划 redundant experts：

  • forward 前 prefetch 远端冗余 expert；
  • backward 后把冗余 expert gradient reduce 回 home rank；
  • GPU heuristic planner 以离线 ILP 解作参考；
  • 始终遵守每 rank E/R 个 redundant-expert slots 的上界。

K3 Appendix E 的证明结构：

  1. 反复选一个 underloaded rank 和一个 overloaded rank；
  2. 从 overloaded rank 搬 Token，精确填满 underloaded rank；
  3. 每个 rank 最多被填一次，因此其 remote tokens 最多来自一个 source rank；
  4. source rank 本地最多有 E/R 个 experts；
  5. 所以每 rank 冗余 experts 不超过 E/R；
  6. 构造极端 routing 可达到 ceil(E(R-1)/R²) ≈ E/R，说明一般上界近似 tight。

6.5 完美 rank balance 仍不等于 kernel 完美 balance

K3 明确保留第二层问题：

  • 每 rank 的 assignment 总数相同；
  • 但 rank 内各 expert 的 Token 数仍可偏斜；
  • 固定顺序 GEMM 会让 SM worker makespan 不同；
  • MoonEP 另用 workload-aware expert-GEMM scheduler，并离线 autotune 代价模型系数。

6.6 MoonEP 的静态 shape 与 buffer 边界

K3 报告称：

  • 每 rank 固定接收 S×K assignments，因此 layer computation shape 可预知；
  • 消除 conventional dynamic expert count 引起的逐层 host-device shape sync；
  • fused permute/unpermute 直接把 Token 写到远端 expert-grouped position；
  • 在报告定义的 worst-case imbalance 与 copy-free 路径下，DeepEP buffer 需 S×K×R，MoonEP 固定为 S×K。

这是 K3 指定比较条件下的 buffer 上界，不应外推为所有 DeepEP 配置的常态占用。

7. L7：长上下文状态与 Context Parallel

7.1 “Sequence Parallel”有至少两种常见含义

  1. Megatron sequence parallel
    与 TP 绑定，把 TP 区域间原本复制的 element-wise activation 沿 sequence 分片；用 AllGather / ReduceScatter 替代 AllReduce，通信量近似不变，主要省激活。

  2. 长上下文 attention sequence/context parallel
    把一个样本的 Q/K/V 序列切到多 rank，共同完成全局 attention；典型为 Ulysses、Ring Attention、USP。

正文首次出现 SP 时必须注明是哪一种。

7.2 Ulysses：sequence shard ↔ head shard

每个 rank 初始持有长度 S/n 的 Q/K/V：

  1. attention 前 All-to-All；
  2. 每 rank 改为持有完整 sequence、但只持有部分 heads；
  3. 本地用标准 attention kernel 计算这些 heads；
  4. 再一次 All-to-All，把输出转回 sequence shard。

论文给出的每 layer、每 link 教学通信量为：

QKV all-to-all: 3SH/n
output all-to-all: SH/n
total: 4SH/n

当 S 与 n 同比例增加时，该口径保持常量。

边界：

  • Ulysses degree 受 attention / KV head 数可切分性限制；
  • GQA / MQA 的 KV heads 少时尤其明显；
  • All-to-All 需要较强拓扑。

7.3 Ring Attention：固定 Q，轮转 KV

每 rank：

  • 保留本地 Q block；
  • 用本地或收到的 K/V block 更新在线 softmax；
  • 同时把 K/V 发给下一 rank、从上一 rank 接收；
  • 轮转完成后得到本地 Q 对全局 K/V 的精确 attention。

收益：

  • sequence、Q/K/V 与输出均分片；
  • P2P 易映射到 ring / 跨节点链路；
  • 通信可与 block attention 重叠。

边界：

  • block 变小会降低 GEMM / fused attention 效率；
  • causal mask 下简单连续切分会产生计算不均；
  • overlap 只有在 block compute 足以覆盖 P2P 时成立。

7.4 USP：用二维 mesh 组合 Ulysses 与 Ring

USP 把一个 sequence-parallel group 看作二维网格：

  • 一轴执行 Ulysses All-to-All；
  • 另一轴执行 Ring P2P；
  • 两轴乘积等于总 sequence-parallel degree。

这样可以：

  • 把 Ulysses 轴限制在 head 数以内；
  • 把高带宽域用于 All-to-All；
  • 把较慢跨域链路用于可重叠的 P2P；
  • 用首尾配对的 token reorder 平衡 causal triangular work。

7.5 K3 KDA Context Parallel

K3 的 KDA 是 recurrent linear attention 分支，不能照搬 softmax attention CP：

  • 每 rank 先对本地 tokens 计算 fixed-size transition / state fragments；
  • rank-level update 可结合；
  • 用 prefix scan 恢复每 rank 的 incoming state；
  • K3 实现用一次 all-gather 交换固定尺寸的 fragments；
  • 通信对象不随完整历史 KV 线性增长；
  • 本地 token compute 随 CP 近似线性切分。

K3 仍对 MLA / multimodal encoder 使用其他 CP 机制，不能把 KCP 当成全模型唯一 CP。

8. L8：数值、低精度与优化器系统账

8.1 Mixed Precision 的三个经典机制

2017 Mixed Precision Training 提出并验证：

  • FP32 master weights；
  • loss scaling，减少小梯度在 FP16 下变成零；
  • FP16 乘法、FP32 accumulation。

低精度不是简单把 dtype 改小，而是对 storage、GEMM input、accumulation、reduction 与 update 分别选精度。

8.2 DeepSeek-V3 FP8 是细粒度 mixed precision

V3 报告中：

  • 主要 compute-intensive GEMM 使用 FP8；
  • 某些敏感操作保留 BF16 / FP32；
  • tile-wise / block-wise scaling 处理动态范围；
  • Wgrad 使用 FP8，使部分 backward 所需 activation 可按 FP8 存；
  • 对累加精度采取额外实现补偿；
  • 通过与 BF16 baseline 的训练曲线比较验证稳定性。

因此不能简写成“整个模型状态与所有计算都是 FP8”。

8.3 K2：FP8 只存 activation，不做 FP8 compute

Kimi K2 明确：

  • MoE up-projection 与 SwiGLU 的部分输入压到 FP8-E4M3；
  • 使用 1×128 tile 与 FP32 scale；
  • 初步研究观察到计算精度风险，因此没有把 FP8 用于 compute；
  • 剩余 activation 继续 CPU offload。

这与 DeepSeek-V3 的 FP8 training framework 是不同选择。

8.4 Muon 增加了新的完整矩阵需求

K3 使用 Per-Head Muon。分布式 optimizer 虽把参数按 DP rank 分片，Newton–Schulz orthogonalization 却需要完整矩阵。

K3 对 naive all-gather 的改造：

  • rank 只向 owner ranks P2P 获取自己负责更新的参数 shards；
  • 不在每 rank 建立全参数 buffer；
  • 减少内存和通信量；
  • 以 model-chunk buffer 为粒度 pipeline 通信与 orthogonalization。

这说明优化器算法会反向改变通信图。

9. L9：可靠性、弹性与 Agentic RL 系统账

9.1 Checkpoint 不只是“多久保存一次”

完整恢复链包括：

  • model / optimizer / scheduler；
  • RNG states；
  • data-loader cursor 与 shuffle；
  • distributed sharding metadata；
  • rollout / environment state；
  • 是否能在不同 world size 下 reshard。

checkpoint 间隔是：

正常训练 I/O 开销
vs
故障后重算损失

的权衡。

9.2 K2：同机训练/推理与 checkpoint engine

K2 的 RL 使用 co-located architecture：

  • training engine 与 inference engine 共用 workers；
  • 一方运行时，另一方释放或 offload GPU state；
  • 独立 checkpoint engine 处理不同 sharding 之间的参数转换；
  • 每个 checkpoint worker 先拿到本地参数，再广播完整参数集；
  • inference worker 只取需要的 shard；
  • 按参数 pipeline，降低峰值内存；
  • K2 报告其 1T 模型一次完整参数更新少于 30 秒。

报告也承认广播量高于理论最优，但用额外传输换取训练/推理引擎解耦与更简单的同步。

9.3 K2.5：多模态和 Agent rollout 都是系统问题

Decoupled Encoder Process：

  1. 全局 batch 的视觉 forward 先按 image / patch load 分到所有 GPU；
  2. 丢弃中间视觉 activation，只保留最终输出并 gather 到 PP stage 0；
  3. backbone 按成熟 text pipeline 完成 forward/backward；
  4. 重新计算 vision forward，再做 vision backward。

K2.5 报告在其设置下达到 text-only training 约 90% 的多模态训练效率。

Agentic RL：

  • 每个 agent task 是独立异步 coroutine；
  • Rollout Manager 支持最高 100,000 concurrent agent tasks；
  • environment pool、LLM gateway、logprob 记录与监控共同参与。

9.4 K3 预训练：统一 activation manager

每个为 backward 保存的 tensor 都绑定可插拔 storage backend：

  • recomputation；
  • block-wise FP8 quantization；
  • local offload；
  • remote offload。

K3 的实现边界：

  • 策略在 tensor 粒度组合；
  • function-granularity recomputation 支持跨层；
  • GPU allocation 统一在主 compute stream 的单一 memory pool；
  • layer-granularity prefetch 与计算重叠；
  • element-wise operators 使用 recomputation；
  • 大部分 activation 组合 block-wise FP8 与 offload / remote-offload。

9.5 K3：MoE、AttnRes、PP rank 内存与 gradients

  • MoE：改写 permuted probability gradient 的依赖，减少必须保存的 forward output；group GEMM input 在 backward 前通过重做 dispatch 恢复，并把通信与部分 GEMM backward 重叠。
  • Block AttnRes：block representation 在边界 layer 生成一次并共享；AttnRes 内部 checkpoint；跨 PP stage 只增量传新 blocks。
  • remote activation：interleaved 1F1B 的前部 PP ranks activation 更多，K3 用 Mooncake Transfer Engine 把 activation 远程放到其他 PP rank memory，平衡容量。
  • Pipeline ZeRO-2：gradients 在 DP ranks 分片后存 CPU；GPU 保留 double grad buffer，reduce 后累加进 CPU shards。

9.6 K3：把 ViT 放进 pipeline bubble

K2.5 DEP 先把 vision encoder 与 text backbone 解耦；K3 再细分：

  • 最前若干 ViT forward 同步执行；
  • 其余 forward 填入 text pipeline bubbles；
  • backward 同理；
  • dynamic CP 沿 patch 切大图，并用 sub-CP groups 平衡多个大图；
  • K3 报告称大部分 ViT compute 因而被隐藏在 PP bubbles。

“隐藏”仍依赖 bubble 是否足够、视觉负载与 stage 调度，不等于视觉编码器零成本。

9.7 K3 百万 Token RL：外置 KV 与自动节流

K3 采用 co-located RL，把每个 1M-context experiment 控制在几百张 GPU 内，并用 partial rollout 缓解超长轨迹尾部。

External KV pool 是 write-back，不是 write-through：

  • active decode blocks 留在 GPU；
  • reusable idle prefix 仅在 GPU eviction 时写入 CPU DRAM；
  • 下次复用前 prefetch；
  • KDA states 与 MLA KV blocks 绑定生命周期；
  • rollout 阶段为外部 KV 腾 DRAM：training iteration 后把 model / optimizer states offload 到 NVMe；
  • rollout 完成后释放 pool，避免与训练争资源。

Auto-throttling：

  • 读取 active requests；
  • queued requests；
  • KV utilization；
  • 动态限制进入 inference engine 的请求数；
  • 早期上下文短时提高并发，后期 KV 压力上升时降并发。

9.8 K3：gradient buffer 复用

reference 等 forward-only model：

  • 常驻 CPU；
  • 需要时把权重 materialize 到 policy model 的 FP32 gradient-buffer storage；
  • 真正 backward 前该 buffer 会被真实梯度覆盖，因此生命周期不冲突；
  • Pipeline ZeRO-2 下每 GPU 只保留两个 VPP chunks 的 gradient buffers；
  • 一个 slot 当前计算，另一个 slot prefetch 下一 chunk。

9.9 AgentENV：环境状态也是训练状态

K3 报告的 AgentENV：

  • 以 Firecracker microVM 提供比普通 container 更强的隔离和更接近真实系统的能力；
  • incremental checkpoint / resume 最低报告 133 ms / 49 ms；
  • paused sandbox 不消耗 memory / CPU；
  • 推理等待在报告场景可占 sandbox lifetime 最高 98%；
  • 支持 pause/resume、fork、snapshot；
  • 使用 OverlayBD、custom ublk、storage sharing 与 P2P；
  • real workloads 中 memory overcommit 最高 6.5×；
  • K3 训练/评估累计创建 51,219,741 个 sandboxes，跨 1,505,678 images。

这些数值是 K3 团队报告的生产统计，不是通用 microVM benchmark。

10. DeepSeek 训练系统谱系

DeepSeek-V2：少 activated parameters 改变并行选择

原报告配置：

  • 16-way zero-bubble PP；
  • 8-way EP；
  • ZeRO-1 DP；
  • 不使用 TP；
  • 共享专家 compute 与 EP All-to-All overlap；
  • 自定义 communication、routing 与 fused kernels。

不使用 TP 的原因是该模型 activated parameters 较少，加上部分 operator recomputation 后 activation 可放下；这是特定架构与硬件配置的选择，不是“MoE 永远不需要 TP”。

DeepSeek-V3：通信、调度、路由和 FP8 协同

原报告训练集群与并行：

  • 2048 NVIDIA H800；
  • 节点内 8 GPU，经 NVLink / NVSwitch；
  • 节点间 InfiniBand；
  • 16-way PP；
  • 64-way EP，跨 8 nodes；
  • ZeRO-1 DP；
  • 不使用 TP。

关键系统机制：

  1. DualPipe 双向调度；
  2. forward/backward 内重排 attention / dispatch / MLP / combine；
  3. backward 拆 input-gradient / weight-gradient；
  4. communication kernels 使用专门 SM，并与 compute stream overlap；
  5. node-limited routing：每 Token 最多去 4 个节点；
  6. IB 先送到目标节点同 local-index GPU，再经 NVLink 转给 expert owner；
  7. FP8 mixed-precision framework 降低 compute 与 activation storage 压力；
  8. selective recomputation、CPU EMA、共享 embedding/head 继续省内存。

原报告称在其集群上只需 20 个 SM 即可充分利用 IB / NVLink 带宽；这是 V3 具体 kernel、拓扑与 workload 的测量，不是硬件常数。

DeepSeek-V4：长上下文使系统账再改变

DeepSeek-V4 的百万 Token 架构把注意力进一步改为压缩/稀疏与 recurrent components。对训练系统的含义：

  • context parallel 传输对象不再只有 full K/V；
  • recurrent state、稀疏 block 与 dense component 有不同生命周期；
  • 不能拿标准 MHA 的 CP 通信式直接估计完整 V4；
  • 页面只引用 V4 报告明确给出的机制与配置，不从架构图反推未披露集群数字。

11. Kimi K2 → K2.5 → K3 系统谱系

K2：优先保持可复用配置

K2 原报告：

  • H800 cluster；
  • 节点内 NVLink / NVSwitch；
  • 节点间 8×400 Gbps RoCE；
  • 16-way PP with virtual stages；
  • 16-way EP；
  • ZeRO-1 DP；
  • 可运行在任意 32 的倍数个节点上；
  • 1T 模型 BF16 parameters + FP32 gradient accumulation buffer 约 6 TB，跨 256 GPU；
  • 各 GPU 约 30 GB 用于 states，剩余给 activations。

K2 明确没有沿用 DualPipe：

  • DualPipe 会让 parameters + gradients 的内存翻倍；
  • 需要增加 PP 或 EP 补容量；
  • 更大 PP 增加 bubble，更大 EP 增加通信/均衡成本；
  • K2 改用多 warmup micro-batches 的 interleaved 1F1B 覆盖 EP communication；
  • weight-gradient 与 PP communication 并行。

这是很重要的反例：更新的调度算法不一定适合更大 total-parameter MoE。

K2 activation ladder

按从便宜到昂贵的顺序：

  1. LayerNorm、SwiGLU、MLA up-projection selective recomputation；
  2. MoE down-projection recomputation；
  3. insensitive activations 压到 FP8-E4M3；
  4. 其余 activations CPU offload；
  5. offload previous forward micro-batch 与 prefetch next backward micro-batch 同时进行。

K2.5：先解耦 ViT，再复用 K2 主干

  • 主干继续 16 PP / virtual stages、16 EP、ZeRO-1；
  • selective recompute + FP8 activation storage + CPU streaming；
  • DEP 把可变视觉 workload 从 PP stage 0 的关键路径拆出；
  • agentic RL 把 rollout 作为异步 task graph 管理。

K3：为 2.8T 与 1M agentic RL 重构执行层

预训练并行：

  • PP with virtual stages；
  • EP；
  • ZeRO-1 DP；
  • Pipeline ZeRO-2 gradient sharding；
  • Context Parallel；
  • MoonEP；
  • dynamic multimodal CP。

相对 K2/K2.5 的系统增量：

  • MoonEP 对 EP rank load 给出可行性保证；
  • unified activation manager 把重计算、量化与多级卸载统一；
  • remote PP activation balancing；
  • Pipeline ZeRO-2 CPU gradient shards；
  • P2P Muon orthogonalization；
  • ViT compute 填 pipeline bubbles；
  • 1M RL external KV write-back pool；
  • request auto-throttling；
  • policy gradient buffer 复用；
  • AgentENV microVM 生命周期。

12. 关键论文与一手实现阅读链

本专题首版目标为 30+ 个一手节点。PDF/text 只存本地忽略目录；公开仓库只提交账本和 canonical URL。

年份 来源 它改变了哪张账
2012 Large Scale Distributed Deep Networks DistBelief、参数服务器与早期分布式训练
2014 One Weird Trick for Parallelizing CNNs 数据/模型并行的通信直觉
2016 Training Deep Nets with Sublinear Memory Cost activation checkpointing
2017 Mixed Precision Training master weights、loss scaling、FP32 accumulation
2018 PipeDream 1F1B、异步 pipeline、weight stashing
2018 Mesh-TensorFlow tensor layout 到 device mesh
2019 GPipe synchronous micro-batch pipeline
2019 Megatron-LM Transformer tensor parallel
2019 ZeRO optimizer / gradient / parameter sharding
2020 GShard MoE expert parallel 与自动分片
2021 3D Megatron-LM TP + PP + DP 与 interleaved schedule
2021 ZeRO-Infinity GPU / CPU / NVMe heterogeneous memory
2021 GSPMD general sharding propagation
2021 Chimera bidirectional pipeline
2022 DeepSpeed-MoE 多轴 MoE 训练/推理系统
2022 Alpa 自动 inter/intra-operator parallelism
2022 Reducing Activation Recomputation Megatron SP 与 selective recomputation
2022 FlashAttention IO-aware exact attention
2022 Tutel adaptive MoE system
2022 MegaBlocks dropless block-sparse MoE
2023 PyTorch FSDP fully sharded 实现经验
2023 FlashAttention-2 attention work partition 与占用率
2023 DeepSpeed-Ulysses sequence ↔ head All-to-All
2023 Ring Attention blockwise P2P context parallel
2023 Zero Bubble Pipeline Parallelism B/W 拆分与 schedule search
2024 MegaScale 10K+ GPU 训练与可靠性
2024 DeepSeek-V2 zero-bubble PP + EP + ZeRO-1，无 TP
2024 USP Ulysses × Ring 2D sequence parallel
2024 DeepSeek-V3 DualPipe、cross-node All-to-All、FP8
2025 DeepEP expert dispatch / combine kernels
2025 Kimi K2 1T MoE 预训练与 co-located RL
2026 Kimi K2.5 DEP 与 100K concurrent agent tasks
2026 DeepSeek-V4 million-token hybrid attention system constraints
2026 Kimi K3 2.8T pretraining + 1M agentic RL stack
2026 MoonEP perfect rank balance 与 static shape
2026 AgentENV resumable microVM agent environments
2026 K2 checkpoint engine train/inference resharding

13. 页面视觉与交互设计

13.1 必须重绘的架构图

  1. 四层成本栈：FLOPs / HBM / network / idle time。
  2. 每参数字节账：从 2 bytes 误解展开到 16P example，再切 ZeRO-1/2/3。
  3. 3D parallel device mesh：TP 节点内、PP 跨节点、DP 跨副本。
  4. pipeline schedule 对照：GPipe、1F1B、interleaved、ZeroBubble、DualPipe。
  5. collective 动画：AllReduce / ReduceScatter / AllGather / All-to-All。
  6. MoE 两次 All-to-All：再叠加 MoonEP redundant expert migration。
  7. context parallel 对照：Ulysses transpose、Ring KV rotation、USP 2D mesh。
  8. activation lifecycle：store / recompute / compress / CPU / remote GPU。
  9. DeepSeek-V3 execution strip：compute 与 communication overlap。
  10. K2 → K2.5 → K3 系统谱系。
  11. K3 1M RL memory seesaw：training states ↔ KV pool ↔ gradient buffer。
  12. AgentENV lifecycle：run → pause → snapshot / fork → resume。

13.2 Interactive Training Systems Lab

四个 tab：

A. Memory Ledger

输入：

  • total parameters；
  • parameter / gradient / master / optimizer precision；
  • DP / ZeRO stage；
  • activation base；
  • checkpoint、FP8 storage、CPU/remote offload。

输出：

  • per-GPU persistent states；
  • peak activation；
  • communication buffer；
  • CPU / remote tier；
  • 哪一项首先 OOM。

B. Parallel Mesh

输入：

  • GPU nodes 与每节点 GPU；
  • TP / PP / DP；
  • dense 或 MoE；
  • EP / CP group definition；
  • network topology。

输出：

  • 每 rank 坐标与 group membership；
  • 高频 collective 落在节点内还是跨节点；
  • invalid topology 原因；
  • 每种通信的调用频率。

C. Pipeline Scheduler

输入：

  • stages p；
  • micro-batches m；
  • virtual chunks v；
  • F / input-grad / weight-grad 时间；
  • schedule 选择。

输出：

  • 实际 timeline；
  • bubble ratio；
  • peak in-flight activations；
  • communication slots；
  • DeepSeek/Kimi 选择的对应关系。

D. Communication / MoE

输入：

  • collective；
  • ranks；
  • tokens / hidden / bytes；
  • expert top-k；
  • imbalance；
  • overlap ratio。

输出：

  • per-rank bytes；
  • α / β time；
  • exposed vs hidden communication；
  • DeepEP-style dynamic buffer 与 MoonEP fixed buffer 对照；
  • rank balance 与 intra-rank expert makespan 分开显示。

所有模拟必须标注为 deterministic teaching model，不冒充任何真实集群 benchmark。

14. 高风险事实检查清单

  • 16P 明确限定为 ZeRO 论文的 FP16/FP32 Adam 配方。
  • ZeRO-1/2/3 的分片对象与内存公式逐项核对原文。
  • collective 体积注明论文近似口径与 ring 精确因子。
  • GPipe / 1F1B 的 bubble 与 activation memory 区分。
  • 原始 PipeDream 异步语义与同步 PipeDream-Flush 区分。
  • interleaved schedule 的 v 收益与额外 PP communication 同时写。
  • ZeroBubble 的 input-gradient / weight-gradient 拆分回查原文。
  • DualPipe 的两份参数与特定 overlap 条件保留。
  • “near-zero A2A overhead” 改写为 critical-path overhead。
  • Megatron SP 与长上下文 SP 分开。
  • Ulysses 的 head-count 限制保留。
  • Ring causal load imbalance 与 block efficiency 边界保留。
  • EP 与 DP/TP/CP 不机械全部连乘。
  • DeepSeek-V2/V3 的“不使用 TP”限定在报告配置。
  • MoonEP S×K 的 S 明确为每 rank 本地 Token 口径。
  • MoonEP E/R 上界与 tight construction 回查 Appendix E。
  • rank aggregate balance 与 rank 内 expert-GEMM balance 分开。
  • MoonEP / DeepEP buffer 比较保留 worst-case copy-free 条件。
  • K2 FP8 activation storage 与 V3 FP8 compute 分开。
  • K2 不用 DualPipe 的原因回查 K2 §2.4.2。
  • K2.5 DEP 三阶段和 90% 报告口径回查原文。
  • K3 unified activation manager 的后端与粒度回查原文。
  • K3 remote activation target 是其他 PP rank memory。
  • K3 Pipeline ZeRO-2 的 CPU shard 与 GPU double buffer 区分。
  • K3 Muon P2P 只取 locally owned parameter shards。
  • K3 external KV 是 write-back，不是 write-through。
  • K3 training states 在 rollout 前 offload 到 NVMe 的时序写清。
  • gradient-buffer reuse 的生命周期安全条件写清。
  • AgentENV 数字标为 K3 报告统计，不外推。
  • 所有 30+ 论文链接发布前做可达性检查。
  • 页面每个数字回链到邻近的一手来源。
  • 互动公式写单元测试与浏览器断言。
  • desktop / mobile / reduced-motion / keyboard 全部验证。
  • immutable image、NAS、VPS、NPM、HTTPS、公开 Forgejo 全链验证。

14.1 首版生产发布证据（2026-07-29）

  • 源提交：c6306fe2602bf0631784fa7feb545ad497a2fbc8。
  • 不可变镜像：docker.k1412.top/wuyang/llm-atlas:20260728T172750Z-c6306fe。
  • Registry digest：sha256:4759d17e1118659c0c12e6dd0e2a70ec57252533b617591705d538c3de4e2b68。
  • NAS：Compose Manager 管理的 llm-atlas 容器为 healthy，端口保持 12010→8080。
  • VPS / Tailscale：100.94.16.3:12010 的首页、训练系统、论文库、进度、健康检查、favicon 与 sitemap 均返回 200。
  • NPM：host 31 继续转发至 100.94.16.3:12010，certificate 41、强制 HTTPS 与 host enabled 状态正常。
  • 公网：11 个页面路由、/healthz、/favicon.svg、/sitemap-index.xml 全部返回 200；HTTP 返回 301 到 HTTPS。
  • TLS：证书 CN 为 llm-atlas.k1412.top，有效期至 2026-10-26。
  • 生产 Chrome：显存 OOM / K3 分层、合法与非法 device mesh、1F1B / DualPipe、collective overlap、MoonEP buffer、桌面与移动布局、菜单与零 JS 异常断言全部通过。
  • 公开仓库：匿名 API 返回 private: false，main 指向同一源提交。

首版页面完成闸门

  • 初学者能在不懂分布式系统的情况下读懂“为什么单卡放不下”。
  • 能用 byte ledger 解释参数、梯度、master weights 与 optimizer state。
  • 能区分 DP / TP / PP / EP / SP / CP 的切分对象。
  • 能解释为什么同样通信字节数仍可能有不同 wall time。
  • 能从时间轴上读出 GPipe、1F1B、ZeroBubble 与 DualPipe 差异。
  • 能解释 Ulysses、Ring 与 USP 的数据布局变化。
  • 能解释 DeepSeek-V3 的系统协同，而不是只背 DualPipe 名字。
  • 能解释为什么 K2 主动不采用 DualPipe。
  • 能沿 K2 → K2.5 → K3 读出内存与调度演进。
  • 能操作四个互动实验并触发至少一个 invalid / OOM / imbalance 情景。
  • 论文阅读链、类型检查、链接、浏览器与容器验证全部通过。
Reference in New Issue View Git Blame Copy Permalink