llm-atlas/research/TRAINING_SYSTEMS_RESEARCH.md

# 大规模 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 定义下成立

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

```text
world_size = axis_1 × axis_2 × … × axis_k
```

不能不加说明地写成：

```text
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** |

因此原论文的基线是：

```text
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`：

```text
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` 增长；训练激活主要随：

```text
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 时间为：

```text
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 α–β 教学模型

```text
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：

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

近似 payload 与下列量成正比：

```text
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 教学通信量为：

```text
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 间隔是：

```text
正常训练 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](https://arxiv.org/abs/1206.5533) | DistBelief、参数服务器与早期分布式训练 |
| 2014 | [One Weird Trick for Parallelizing CNNs](https://arxiv.org/abs/1404.5997) | 数据/模型并行的通信直觉 |
| 2016 | [Training Deep Nets with Sublinear Memory Cost](https://arxiv.org/abs/1604.06174) | activation checkpointing |
| 2017 | [Mixed Precision Training](https://arxiv.org/abs/1710.03740) | master weights、loss scaling、FP32 accumulation |
| 2018 | [PipeDream](https://arxiv.org/abs/1806.03377) | 1F1B、异步 pipeline、weight stashing |
| 2018 | [Mesh-TensorFlow](https://arxiv.org/abs/1811.02084) | tensor layout 到 device mesh |
| 2019 | [GPipe](https://arxiv.org/abs/1811.06965) | synchronous micro-batch pipeline |
| 2019 | [Megatron-LM](https://arxiv.org/abs/1909.08053) | Transformer tensor parallel |
| 2019 | [ZeRO](https://arxiv.org/abs/1910.02054) | optimizer / gradient / parameter sharding |
| 2020 | [GShard](https://arxiv.org/abs/2006.16668) | MoE expert parallel 与自动分片 |
| 2021 | [3D Megatron-LM](https://arxiv.org/abs/2104.04473) | TP + PP + DP 与 interleaved schedule |
| 2021 | [ZeRO-Infinity](https://arxiv.org/abs/2104.07857) | GPU / CPU / NVMe heterogeneous memory |
| 2021 | [GSPMD](https://arxiv.org/abs/2105.04663) | general sharding propagation |
| 2021 | [Chimera](https://arxiv.org/abs/2107.06925) | bidirectional pipeline |
| 2022 | [DeepSpeed-MoE](https://arxiv.org/abs/2201.05596) | 多轴 MoE 训练/推理系统 |
| 2022 | [Alpa](https://arxiv.org/abs/2201.12023) | 自动 inter/intra-operator parallelism |
| 2022 | [Reducing Activation Recomputation](https://arxiv.org/abs/2205.05198) | Megatron SP 与 selective recomputation |
| 2022 | [FlashAttention](https://arxiv.org/abs/2205.14135) | IO-aware exact attention |
| 2022 | [Tutel](https://arxiv.org/abs/2206.03382) | adaptive MoE system |
| 2022 | [MegaBlocks](https://arxiv.org/abs/2211.15841) | dropless block-sparse MoE |
| 2023 | [PyTorch FSDP](https://arxiv.org/abs/2304.11277) | fully sharded 实现经验 |
| 2023 | [FlashAttention-2](https://arxiv.org/abs/2307.08691) | attention work partition 与占用率 |
| 2023 | [DeepSpeed-Ulysses](https://arxiv.org/abs/2309.14509) | sequence ↔ head All-to-All |
| 2023 | [Ring Attention](https://arxiv.org/abs/2310.01889) | blockwise P2P context parallel |
| 2023 | [Zero Bubble Pipeline Parallelism](https://arxiv.org/abs/2401.10241) | B/W 拆分与 schedule search |
| 2024 | [MegaScale](https://arxiv.org/abs/2402.15627) | 10K+ GPU 训练与可靠性 |
| 2024 | [DeepSeek-V2](https://arxiv.org/abs/2405.04434) | zero-bubble PP + EP + ZeRO-1，无 TP |
| 2024 | [USP](https://arxiv.org/abs/2405.07719) | Ulysses × Ring 2D sequence parallel |
| 2024 | [DeepSeek-V3](https://arxiv.org/abs/2412.19437) | DualPipe、cross-node All-to-All、FP8 |
| 2025 | [DeepEP](https://github.com/deepseek-ai/DeepEP) | expert dispatch / combine kernels |
| 2025 | [Kimi K2](https://arxiv.org/abs/2507.20534) | 1T MoE 预训练与 co-located RL |
| 2026 | [Kimi K2.5](https://arxiv.org/abs/2602.02276) | DEP 与 100K concurrent agent tasks |
| 2026 | [DeepSeek-V4](https://arxiv.org/abs/2606.19348) | million-token hybrid attention system constraints |
| 2026 | [Kimi K3](https://arxiv.org/abs/2607.24653) | 2.8T pretraining + 1M agentic RL stack |
| 2026 | [MoonEP](https://github.com/MoonshotAI/MoonEP) | perfect rank balance 与 static shape |
| 2026 | [AgentENV](https://github.com/kvcache-ai/AgentENV) | resumable microVM agent environments |
| 2026 | [K2 checkpoint engine](https://github.com/MoonshotAI/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. 高风险事实检查清单

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

## 首版页面完成闸门

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