00 NINE LEDGERS
训练系统的核心：把等待、容量和数据移动分别记账
“模型放不下”可能是参数、Adam 状态、激活或临时通信 buffer；“扩展效率低”可能是 GEMM 太小、 网络太慢、最忙专家拖尾或 pipeline 没填满。只有先拆账，才知道优化是在消灭成本，还是把它搬到另一层。
{question}
气泡、长尾、故障恢复、环境等待
NVLink、IB/RoCE、PCIe、存储 I/O
HBM、CPU DRAM、remote GPU、NVMe
Tensor Core、CUDA Core、kernel launch
GPU 算力是厨师；HBM 是手边案台；跨卡网络是传菜通道；pipeline bubble 是厨师在等上一道工序。 增加厨师，如果案台太小、传菜口拥堵或订单全堵在某个专家窗口，仍然不会线性提速。
01 ONE TRAINING STEP
先看一步训练，所有系统优化才有落点
一个同步训练 step 并不是一次“模型运行”。它包含数据进入、forward、保存或处理 activation、 backward、梯度聚合、optimizer update，以及下一步开始前必须完成的同步。不同状态只在特定时间被需要。
读入并 pack Token / 图像 / 视频
storage → CPU → GPU按 layer 产生 activation 与 loss
parameter + compute逆序消费 activation，产生 gradient
recompute / prefetch跨 replica 聚合或分片 gradient
collective用 optimizer states 更新参数
master weights“不是什么状态都要一直在 GPU”
如果一个状态当前不需要，就不必在每张 GPU 上完整常驻。区别在于：ZeRO 把状态放到其他 rank， checkpointing 把中间量变成未来的重计算，offload 则把它放到更慢的存储层。
02 MODEL-STATE MEMORY
“BF16 参数 2P bytes”只是训练账单的第一行
ZeRO 用 FP16/FP32 mixed-precision Adam 说明：前反向权重和梯度各 2 字节，更新还保留 FP32 master parameter、 momentum 与 variance，各 4 字节。于是基线是 16P，而不是 2P。
{role}
这条式子依赖具体 dtype 与状态实现。BF16 gradient、FP32 accumulation、EMA、FP8 scale、flat buffer、 Muon state 或 fused optimizer 都会改变账单。正确做法是逐张量列 byte ledger。
ZeRO：沿数据并行轴逐步取消复制
{name}
{split} {memory}{traffic}
ZeRO 论文把 ReduceScatter 与 AllGather 各近似为 P 的数据移动，所以普通 DP 与 ZeRO-2 都约为 2P， ZeRO-3 约为 3P。严格 ring 每 rank 的单向发送量还要乘 `(N−1)/N`。不同口径不能直接相除。
03 ACTIVATION LIFECYCLE
参数按模型大小增长，激活按 batch × sequence × hidden × layers 增长
增大 DP 只切 batch，不会切开一个超长样本的 activation。标准注意力如果显式保存 `S×S` matrix， 还会出现平方级中间量。因而 7B 长上下文训练可能比更大参数的短上下文配置更早撞上 HBM。
{move.title}
{move.body}
新账单：{move.debt}Backward 直接读取；activation memory 随层数线性增长。
只留边界 checkpoint；Backward 经过某段时重跑该段 forward。
关键论文怎样逐步把重计算变细
分段 checkpoint 把 n 层 feature-map memory 从 O(n) 降到 O(√n)；递归可继续换内存。
优先重算 memory-heavy、compute-light 中间量，并用 Megatron SP 分片原本复制的 element-wise activation。
用 SRAM tiling 与 online softmax 避免把完整 S×S attention matrix 写回 HBM；dense attention FLOPs 仍是平方级。
把 recompute、FP8、local / remote offload 变成 tensor 粒度的可组合 storage policy。
04 PARALLEL AXES
五种并行，切的是五个不同对象
如果只背缩写，很容易把“更多 GPU”误解成同一种扩展。判断任何配置时，先问： 每张 GPU 持有什么、每次通信发生在哪个频率、哪个维度真的独立。
{cut}
{body}
{comm}只有互相正交的 device-mesh axes 才连乘。Megatron SP 与 TP 共组；EP 常只作用于 MoE layer； dense attention、shared expert 和 context group 还可能用另一套 process groups。先画 rank membership。
05 COLLECTIVE COMMUNICATION
通信量必须同时写：消息大小、rank 口径、算法和调用频率
小消息、同步、协议与 kernel launch 更敏感。
大 tensor 搬运由链路吞吐主导。
只减关键路径时间，不减物理传输字节。
为什么相同字节数也可能完全不同
消息大，但能被一整个 batch 的计算摊薄。
高频，强依赖节点内低延迟高带宽。
点对点；stage 越多，消息与 bubble 越复杂。
All-to-All；payload 与 top-k、路由宽度和负载相关。
06 PIPELINE BUBBLES
流水线不改变模型数学，只改变谁在什么时候做哪一段
理想平衡 stage、忽略通信。
m 个 micro-batches 的有效计算。
GPipe / non-interleaved flush 的简化式。
{wave.title}
{wave.gain}
留下的债：{wave.debt}两部分绑成一个调度单元，必须一起完成。
先让前一 stage 继续反传，再把 W 放进之后的空隙。
“近零 All-to-All 开销”不是“没有 All-to-All”
V3 把 forward/backward chunk 拆成 attention、dispatch、MLP、combine，再把 input-grad / weight-grad 分开； 双向注入 micro-batches，并手动划分通信与计算使用的 SM。通信字节仍真实经过 IB/NVLink， 只是多数传输在该配置下被相邻计算覆盖，不再暴露在关键路径。
边界：DualPipe 需要两份参数，并比表中的 1F1B 多一个 stage-normalized activation 单位。07 EXPERT PARALLEL
MoE 省的是每 Token 计算，不会自动省通信与等待
逻辑 payload 近似随 `tokens × top-k × routed width × bytes` 增长；但 end-to-end time 还受 capacity、 padding、路由 metadata、跨节点比例和最忙 rank makespan 影响。MoE 专题 已详细解释模型路由，本章只聚焦执行系统。
路由、自动分片与跨设备 expert execution 成为一体。
不同专家数、capacity、硬件下切换执行策略。
不靠固定 capacity padding / dropping，但真实不均衡工作仍存在。
高吞吐与低延迟 kernel；不单独保证每 rank token load 相同。
MoonEP：先给 rank 级完美均衡一个上界保证
每 rank 本地 S Tokens，每 Token 选择 K experts。
remote tokens 最多来自一个 source rank。
每个 source rank 本地最多 E/R experts。
固定 buffer，消除逐层 shape host sync。
每 rank 总 assignments 相同以后，rank 内不同 experts 仍可一多一少。K3 还需要 workload-aware scheduler 平衡 SM makespan。MoonEP 的 `S×K` vs DeepEP `S×K×R` 也只适用于报告定义的 worst-case copy-free buffer 对照。
08 CONTEXT PARALLEL
长序列并行不是一种算法，而是一组不同的数据布局
把 sequence shard 转成 head shard；attention 后再转回来。
K/V0Q1
K/V1Q2
K/V2Q3
K/V3
每 rank 固定本地 Q，在线累积对全局 K/V 的精确 softmax。
KDA 是 recurrent linear attention：每 rank 从本地 Token 计算 fixed-size transition/state fragments， 一次 AllGather 后用 prefix scan 恢复 incoming state。它不搬完整历史 KV，但只覆盖 KDA 分支； K3 的 MLA 与视觉 encoder 仍有各自 CP。
09 NUMERICS & OPTIMIZER
低精度训练要分别回答：存什么、算什么、在哪里累加
权重与 activation 占多少 HBM。
Tensor Core 使用何种格式。
大量乘加与 reduction 是否丢失小量。
优化器状态和参数更新精度。
FP8 compute framework
主要 compute-intensive GEMM 使用 FP8；敏感操作保留更高精度；tile/block scaling 管动态范围； WGrad FP8 也让相关 activation 可按 FP8 保存。
FP8 activation storage
部分 MoE / SwiGLU 输入压成 FP8-E4M3，scale 为 FP32；K2 明确没有用 FP8 compute， 因为前期研究观察到潜在性能退化风险。
Muon 改写通信图
Newton–Schulz orthogonalization 需要完整矩阵；K3 不全量 AllGather，而让 owner rank P2P 获取自己更新所需 shards，并按 model chunk pipeline。
10 DEEPSEEK SYSTEMS LINEAGE
DeepSeek 的亮点不是单个 kernel，而是模型、路由、调度与网络共同设计
{body}
V3 的四层闭环
少 activated parameters；但跨节点 expert traffic 重。
限制 IB fan-out，再在节点内经 NVLink 转发。
warp specialization 与动态任务分配；这是报告集群的实测配置。
把 A2A 与 attention / MLP / backward 重排进同一时间轴。
V3 借助大 EP、ZeRO-1、selective recomputation 与 FP8 把状态放下，避免高频 TP 通信。 换硬件、batch、专家布局或上下文长度后，最优并行配置可能改变。
11 KIMI SYSTEMS LINEAGE
K2 → K3：从“稳定复用一套并行配置”走向统一执行与存储系统
{mechanism}
{body}
K2 为什么主动不采用 DualPipe
K2 是 1T total-parameter MoE。报告指出，DualPipe 的额外状态会迫使系统增加 PP 或 EP： 更大 PP 增加 bubble，更大 EP 提高通信与负载成本。因此团队保留 16 PP / 16 EP / ZeRO-1， 用更多 warmup micro-batches 覆盖 EP communication，并让 WGrad 与 PP communication 并行。
K3 3T-class 预训练执行图
在线冗余 expert 规划 → rank perfect balance → static shape
recompute + block FP8 + local/remote offload
GPU double buffer → DP reduce → CPU shards
只取 locally owned matrices 的远端 shards
大图切 patch；大部分 ViT compute 放入 text PP 空隙
12 INTERACTIVE LAB
亲手改变配置，看瓶颈怎样从一张账移动到另一张账
推荐依次尝试：在显存账中把 70B 切到 ZeRO-3；在 device mesh 选择“故意冲突”； 在 pipeline 中比较 1F1B 与 DualPipe 的参数副本；最后把通信 overlap 拉到 95%，观察 bytes 不变、exposed time 下降。
13 MILLION-TOKEN AGENTIC RL
到 Agentic RL，训练系统还要管理 KV、环境和跨迭代长尾
Policy update；model、optimizer 与 gradient 占 GPU/CPU。
训练布局转成 inference layout；K2 用 checkpoint engine。
百万 Token KV、tool latency、partial trajectory 与 sandbox。
Reference / judge forward；权重可能无法常驻 GPU。
K3 的三次“生命周期复用”
active decode blocks 留在 GPU；idle reusable prefix 才进入 external pool，KDA state 与 MLA KV 一起管理。
一个 VPP slot 当前 forward，另一个 prefetch 下一 chunk；真实 backward 前再被 gradient 覆盖。
AgentENV 用 Firecracker microVM，支持 incremental checkpoint、resume、fork 与 snapshot。
报告最低延迟
报告最低延迟
真实 workload 报告
K3 训练与评估累计
系统数字高度依赖镜像、内存 dirty rate、存储层和并发形态。课程保留原始口径，不把最小延迟或最高 overcommit 外推到其他环境。
14 CONFIGURATION PLAYBOOK
没有“最好并行策略”，只有当前最先触顶的约束
先算精确 byte ledger；考虑 ZeRO/FSDP、TP/PP/EP 或 optimizer offload。
减 micro-batch；selective recompute、FlashAttention、SP/CP、压缩或 offload。
检查 GEMM shape、kernel fusion、micro-batch、低精度和 launch overhead。
先定位 collective、频率和拓扑；再谈减少体积、换 group、chunk 或 overlap。
增加 m、virtual chunks、B/W split 或双向 schedule，同时重算 activation 与参数副本。
分开 router balance、rank placement、redundant experts 与 rank 内 GEMM scheduling。
按 attention 类型选择 Ulysses、Ring、USP 或 recurrent-state CP；不要只增 DP。
计算 checkpoint 恢复时间、数据确定性、world-size reshard 与环境状态恢复。
每项优化都要写两句话：它省了什么；它把代价搬到了哪里。
↳ PRIMARY-SOURCE CHAIN
从分布式深度学习到 K3：37 个一手阅读节点
这不是按引用数排序的“必读榜”，而是一条问题链。建议先读带有当前瓶颈的节点： 容量读 ZeRO；层内切分读 Megatron；气泡读 GPipe / ZeroBubble；MoE 执行读 MegaBlocks / DeepEP / MoonEP； 长序列读 Ulysses / Ring / USP；最后回到 DeepSeek 与 Kimi 的整机协同。
{note}
))}本页机制和数字回查论文、官方技术报告或作者仓库；图均为课程原创简化示意。 性能提升只属于论文的模型、集群和基线，不作跨系统排行榜。