DeepSeek V3 / V4 Infra：
把 all-to-all 藏进计算

V3 的 64-way EP 跨 8 个节点；论文测到 compute:communication 约 1:1，通信不是背景噪声，而是决定 step time 的主项。

V3 的集群是 2048 张 H800，每节点 8 张 GPU：节点内 NVLink + NVSwitch，节点间走 InfiniBand（IB）。 模型是 671B 总参数、37B 激活的 MoE，61 层、hidden 7168、128 个 attention head； 每个 MoE 层 1 个 shared expert + 256 个 routed expert，每 token 激活 8 个 routed expert，每个 expert 的 intermediate hidden dimension 是 2048。

训练并行是 16-way PP、64-way EP（跨 8 个节点）、ZeRO-1 DP。 论文明确说没有用 Tensor Parallelism（TP）：显存优化做到位之后，TP 的通信开销不划算。 代价是 EP 的 all-to-all 要跨节点：每个 MoE 层，token 先按路由送到 64 个 EP rank 上的 expert，算完再 combine 回来。 论文在 §3.2.1 给出的测量是：跨节点 EP 带来的 compute-to-communication ratio 约 1:1。

V4 把这个问题放大而不是缩小。V4-Pro 是 1.6T 总参数、49B 激活，61 层、hidden 7168， 1 个 shared expert + 384 个 routed expert，每 token 激活 6 个 routed expert，每个 expert 的 intermediate hidden dimension 是 3072。 更重要的是，V4 取消了 V3 的节点数限制：V3 每个 token 最多送到 4 个节点，V4 不再加这个约束。 路由目标更多，通信拓扑更自由，但 all-to-all 的潜在压力也更大。

同时，V4 的目标是 1M token context。长上下文把第二个瓶颈推到前台：attention 的 FLOPs 和 KV cache 随序列增长， 即使 EP 通信藏住了，KV cache 的容量与带宽仍会限制吞吐。V3 的答案是 MLA + 128K YaRN 扩展；V4 的答案是 CSA/HCA 混合 attention 加异构 KV cache。两条线必须在同一个 step 里同时成立，Infra 才是完整的。

传统 PP 把 all-to-all 当成 chunk 之间的独立阶段；V3 的 DualPipe 先把它塞进 chunk 对，V4 再拆到 expert wave。

流水并行的基本单位是 chunk。1F1B 让每个 rank 先做若干个 forward chunk，再交替做 forward 与 backward； 它的 bubble 是 (PP−1)(F+B)，其中 F 是一个 forward chunk 的执行时间，B 是一个完整 backward chunk 的执行时间。 ZB1P 把 backward 拆成「backward for input」和「backward for weights」两部分，bubble 降为 (PP−1)(F+B−2W)，W 是 backward-for-weights chunk 的时间。 两者都只保留 1× 参数副本，activation 是 PP 个单位。

这些方法减少的是 pipeline bubble，不是 all-to-all 本身。通信仍以 chunk 或 stage 为单位排队： 一个 chunk 的 dispatch 完成，才能开始对应的 expert 计算；combine 完成，才能进入下一个 chunk。 当 compute:communication 接近 1:1 时，只减少 bubble 不够，必须让通信与计算在同一段时间里并行。

V3 的 DualPipe 和 V4 的 fine-grained EP 都在这个基础上再切一层：前者切 chunk 的内部组件，后者切 expert。 下一页的核心方法按这两条线展开。

V3 用 DualPipe 把 all-to-all 与 PP 塞进同一对 forward/backward chunk；V4 用 wave 让每个 expert 一完成通信就算，稳态下通信与计算连续。

V3 DualPipe：把一对 chunk 拆成四段，再手动排通信与计算的比例

DualPipe 的关键不是「更快的 all-to-all」，而是把一对 forward/backward chunk 拆成四个组件： attention、all-to-all dispatch、MLP、all-to-all combine。 backward chunk 里的 attention 与 MLP 再各拆成 backward for input 与 backward for weights，另有一个 PP communication 组件。 这些组件被重新排列，并手动调整「通信 SM / 计算 SM」的比例，目标是在一对 chunk 内同时藏住 all-to-all 与 PP 通信（V3 §3.2.1）。

DualPipe 用双向流水：从 pipeline 两端同时喂 micro-batch，两个方向的 micro-batch 对称。 论文的 Table 2 给出代价：bubble 是 (PP/2−1)(F&B+B−3W)， 参数副本 2×，activation PP+1 个单位。 论文的说法是：相比 1F1B / ZB1P，DualPipe 的 peak activation memory 只增加 1/PP； 相比 Chimera，它只要求 pipeline stages 和 micro-batches 能被 2 整除，不要求 micro-batches 能被 pipeline stages 整除。

V3 Table 2：三种 pipeline 方法的 bubble、参数副本与 activation 单位。F = forward chunk，B = 完整 backward chunk， W = backward-for-weights chunk，F&B = 两个互相重叠的 forward/backward chunk。

DualPipe 只解决了 chunk 内的重叠。跨节点 all-to-all 还需要一个足够快的 kernel：V3 的 NVLink 带宽是 160 GB/s，IB 是 50 GB/s，NVLink 约为 IB 的 3.2 倍。 为了压 IB 流量，V3 限制每个 token 最多送到 4 个节点， 并让每个节点平均承载 3.2 个 expert。 这样每个 token 实际只选 8 个 routed expert，但同样的通信成本下可以扩到 最多 13 个 expert（4 节点 × 3.2 expert/节点）。 通信 kernel 只用 20 个 SM，分成 10 个通信 channel，用 warp specialization 处理 IB 发送、 IB-to-NVLink 转发与 NVLink 接收；论文还用了自定义 PTX 与自动调优的 chunk size 来降低 L2 cache 干扰。

这 20 个 SM 是 H800 的 132 个 SM 中的 20 个，约 15.2%。 它们不跑 tensor core，只做通信搬运；论文在 §3.5.1 明确说，这会限制计算吞吐，而且通信时 tensor cores 完全闲置， 并建议未来硬件把通信卸载到 GPU co-processor 或 network co-processor。V4 的 fused kernel 也把通信与计算融进一个 pipelined kernel（V4 §3.1）。

V4 fine-grained EP：把 expert 切成 wave，让通信与计算连续

V4 的一层 MoE 被分成四个 stage：两个通信受限的 Dispatch、Combine， 两个计算受限的 Linear-1、Linear-2。 论文 profiling 的结论是：在单个 MoE 层内，通信总时间小于计算总时间， 所以只要把通信藏到计算下面，计算就是主瓶颈，系统可以容忍更低的互联带宽。

V4 的做法是把 expert 分成若干 wave：每个 wave 只含一小部分 expert。 一个 wave 内的所有 expert 通信完成，计算立刻开始，不等其他 wave。 稳态下，当前 wave 的计算、下一个 wave 的 token 传输、已完成 expert 的结果回传同时进行。 论文在 NVIDIA GPU 与华为 Ascend NPU 上都验证了这套方案：相对强非融合基线， 通用推理 1.50–1.73×，延迟敏感场景最高 1.96×。 CUDA 版的 mega-kernel 叫 MegaMoE，已作为 DeepGEMM 的一个组件开源。

V4 还给出一个可计算的「重叠预算」。设峰值算力为 C、互联带宽为 B，计算量为 V_comp、通信量为 V_comm； 当 C/B ≤ Vcomp/Vcomm 时，通信可以完全藏住。 对 V4-Pro，每个 token-expert pair 需要 6hd FLOPs（SwiGLU 的 gate、up、down 三个投影）， 但只有 3h bytes 的通信（FP8 Dispatch + BF16 Combine），于是：

这里有一个口径要说明：V4 §3.1 写 2d=6144，反推 d=3072； V4 §4.2.1 写 V4-Pro 的 hidden dimension 是 7168、每个专家的 intermediate hidden dimension 是 3072。 两处都叫 d，但按 6hd/3h=2d 的结构，公式里的 d 对应 expert 的 intermediate dimension。 推断（依据：2d=6144 得 d=3072，与 §4.2.1 的 expert intermediate hidden dimension 相同）。 页面的交互按 6144 使用，不把 7168 代入；换模型或换精度组合要重新算。

训练可行性不是单一精度技巧：V3 的账本是 FP8 分块量化 + BF16 optimizer；V4 的账本是 Muon 的 ZeRO 分桶、mHC 重算、上下文并行和逐位可复现。

V3 FP8：1×128 的激活 tile、128×128 的权重 block、每 128 个元素回 FP32 累加

V3 的 FP8 不是把整个训练步压到 8 bit，而是「大部分 GEMM 用 FP8 输入、FP32 累加，关键算子留在高精度」。 激活按 1×128 tile 量化（per token per 128 channels）， 权重按 128×128 block 量化（per 128 input channels per 128 output channels）。 所有张量都用 E4M3；attention 之后 Linear 的输入是一个例外，用自定义的 E5M6 格式，因为这份激活还要供 attention backward 使用，对精度更敏感。

H800 的 FP8 Tensor Core 累加精度大约只有 14 bit。 论文用两个 K=4096 的随机矩阵做初步测试，发现有限累加精度会导致 接近 2% 的最大相对误差。 修正方法是每 N_C=128 个元素把部分和搬到 CUDA Cores，用 FP32 寄存器继续累加； 128 个元素约等于 4 个 WGMMA，这是「能明显改善精度、又不引入实质开销」的最小间隔。

综合 V3 §3.3：FP8 混合精度的量化粒度、累加与低精度存储/通信。表中每个设置都带有模型/算子条件，不能单独外推到其他硬件。

这套配方在约 16B/1.33T 与约 230B/0.9T 两个模型规模上做了 FP8 vs BF16 对照， 相对 loss error 保持在 0.25% 以下。 但边界也很清楚：如果把 Dgrad 的激活梯度也改成 128×128 block-wise 量化， 论文在约 16B 模型、300B tokens 上观察到模型发散； 作者的解释是激活梯度在 token 间高度不平衡，block-wise 量化压不住 token-correlated outliers。 这不是「FP8 一定能训」的证据，而是「这套细粒度量化 + 高精度累加能训」的证据。

显存侧还有三条工程手段：反向重算所有 RMSNorm 与 MLA up-projection，避免持久保存它们的输出激活； EMA 参数放 CPU、每步异步更新；DualPipe 把 embedding 与 output head 放在同一个 PP rank 上， 让 MTP 模块与主模型物理共享参数和梯度（V3 §3.2.3）。 这些手段合起来，才让 V3 在不用 TP 的情况下把 671B MoE 放进 2048 张 H800。

V4 Muon / mHC：把「全矩阵更新」和「更宽的 residual」压进同样的 step time

V4 把 optimizer 换成 Muon。Muon 需要完整梯度矩阵来算更新，这和 ZeRO 的「按元素切参数」冲突。 论文的解法是混合 ZeRO 分桶：dense 参数限制 ZeRO 并行度，用 knapsack 把参数矩阵分配到各 rank， 每个 rank 的 bucket padding 到最大 bucket；在「每个 rank 最多管 5 个参数矩阵」的设置下， padding 通常带来 低于 10% 的显存开销。 当 DP 规模超过 ZeRO 限制时，额外的 DP group 冗余计算 Muon 更新，用计算换 bucket 显存。 MoE 参数按 expert 独立优化：先把所有层的 down projection 展平，再 up projection、gate， 最后 padding 到能整除所有 rank；expert 数量大，所以不对 MoE 参数设 ZeRO 并行度上限，padding 开销可以忽略。

通信侧，V4 观察到 Muon 的 Newton-Schulz 迭代在 BF16 矩阵乘下仍然稳定，于是把跨 DP rank 同步的 MoE 梯度 用 stochastic rounding 量化到 BF16，把通信量减半。 为了避免低精度加法器的累积误差，它不用 tree/ring reduce-scatter，而是先 all-to-all 交换本地梯度， 每个 rank 再做 FP32 本地求和。这个取舍是「梯度同步精度换带宽」，不是「所有状态都 BF16」。

mHC 把 residual stream 的宽度扩大到 nhc×d（V4 配置 nhc=4）， 增加了 activation 显存与 pipeline stage 之间的通信量。V4 用三件事把开销压住： 训练/推理的 mHC fused kernel；选择性 checkpoint（重算层间大部分 hidden states 和所有 normalized layer inputs， 但不重算 compute-intensive 操作）；调整 DualPipe 1F1B 的重叠方案，让 mHC 的部分操作并发。 最终 mHC 的 wall-clock 开销是重叠 1F1B 阶段的 6.7%。

长上下文侧，V4 的 Context Parallelism 不能沿用「每 rank 连续 s 个 token」的朴素切分： CSA/HCA 的压缩需要 m 个连续 KV entry，可能跨 rank 边界；压缩后的长度还可能小于 s/m 且各 rank 不同。 论文用两阶段通信：rank i 把自己最后 m 个未压缩 KV entry 发给 rank i+1；rank i+1 与本地 s 个 entry 一起压缩， 产生固定长度 s/m+1 的压缩 entry（含 padding）；第二阶段 all-gather，所有 rank 的压缩 entry 经 fused select-and-pad 组织成总长度 cp_size·s/m 的完整集合（V4 §3.4.3）。

Activation checkpointing 也做到了 tensor 级：开发者只写 forward，并标注需要 checkpoint 的 tensor； 框架用 TorchFX 追踪完整计算图，为每个标注 tensor 找到重算所需的最小子图，插到对应梯度计算之前。 重算通过释放标注 tensor 的 GPU 显存、复用重算 tensor 的 storage pointer 实现，不做显存拷贝； 共享 storage 的 tensor（例如 reshape 的输入输出）会自动去重。论文说这套设计与手工实现相比 不引入额外训练开销。

V4 后训练：FP4 QAT 把 MoE 权重与 indexer QK 压到 4 bit

V4 在 post-training 阶段做 FP4（MXFP4）QAT，对象是两部分：MoE expert weights（显存占用的大头）， 以及 CSA indexer 的 QK path（QK activations 在长上下文里要被缓存、加载、相乘）。 同时把 index scores 从 FP32 量化到 BF16。论文报告 top-k selector 2× 加速，KV entry recall 99.7%。

FP4→FP8 的反量化被论文称为 lossless：FP8（E4M3）比 FP4（E2M1）多 2 个 exponent bit， 只要每个 FP8 量化 block（128×128 tile）内、各个 FP4 sub-block（1×32 tile）的 scale 最大值/最小值之比不超过阈值， FP4 的细粒度 scale 信息就能被 FP8 的动态范围吸收。论文说当前权重满足这个条件， 所以整个 QAT 流程可以复用现有 FP8 训练框架；反向传播对前向的同一份 FP8 权重求梯度， 直接回传到 FP32 master weights，相当于在量化操作上做 straight-through estimator（STE），也避免了对转置权重重新量化。

综合 V3 §3.1–§3.4 与 V4 §3.1–§3.5、§4.2.1：两代训练系统的对照。表中「未获取」表示该报告没有给出对应数字， 不是「没有这项技术」。

V3 把 forward/backward chunk 拆成 attention、dispatch、MLP、combine；V4 把一层 MoE 拆成 Dispatch、Linear-1、Combine、Linear-2，再把 expert 切成 wave。

把流程拆成五步

1. V3 切 chunk。forward 与 backward chunk 各拆成 attention、all-to-all dispatch、MLP、all-to-all combine；backward 再拆 input/weights。这样 all-to-all 不再是 chunk 之间的黑盒，而是可以和 attention/MLP 交错排布的组件（V3 §3.2.1）。
2. V3 排双向流水。从 pipeline 两端同时喂 micro-batch，两个方向对称；一对 forward/backward chunk 内的通信与计算被手动重排，目标是 all-to-all 与 PP 通信都被藏住（V3 Figure 4/5）。
3. V3 用 20 个 SM 跑通信 kernel。10 个通信 channel，warp specialization 处理 IB 发送、IB-to-NVLink 转发、NVLink 接收；dispatch 与 combine 都走这条路径（V3 §3.2.2）。
4. V4 切 expert wave。一层 MoE 的 Dispatch / Linear-1 / Combine / Linear-2 四段中，expert 被分成小 wave；一个 wave 通信完成就开始算，不等其他 wave；稳态下当前 wave 计算、下一 wave 传输、已完成 expert 回传并行（V4 §3.1）。
5. V4 管 KV cache。CSA/HCA 产生多种 KV entry：经典 KV cache 存压缩后的 CSA/HCA entry，state cache 存 SWA 的最近 n_win 个 entry 和尚未压缩的尾部 token。每个 cache block 覆盖 lcm(m,m′) 个原始 token，产生 k1=lcm(m,m′)/m 个 CSA entry 与 k2=lcm(m,m′)/m′ 个 HCA entry（V4 §3.5.1）。

先看条件：V4 的加速比相对强非融合基线，V3 的 GPU-hours 是 2048 张 H800 的官方训练账本。

V3 Table 1：按 H800 租金 $2/GPU-hour 计算；只含官方训练，不含前期研究、架构/算法/数据消融。

V3 的预训练每 trillion token 需要 180K H800 GPU-hours， 在 2048 张 H800 上约 3.7 天；预训练阶段总计 2664K GPU-hours， 上下文扩展 119K，后训练 5K， 全量 2.788M，按 $2/GPU-hour 算是 $5.576M。 这组数字经常被当作「低成本训练」的引用，但它的条件很具体：2048 张 H800、V3 的 MoE 结构、FP8 + DualPipe、且不含前期研究与消融。

综合 V3 Table 1 / §3.3 与 V4 §1 / §3.1 / §3.4.2 / §5.2.1：两代 infra 的可比指标。 空白「—」表示该报告没有给对应项；「未获取」表示页面没有找到，不等于该项不存在。

V4 的 1M 效率数字来自 Figure 1 的估算：在 1M token 上下文下，V4-Pro 的单 token inference FLOPs 是 V3.2 的 27%，累计 KV cache 是 10%； V4-Flash 更低，分别是 10% 与 7%。 其中 FLOPs 以 equivalent FP8 FLOPs 计，KV cache 是 size 比例；比较对象是 V3.2，不是 V3，也不是端到端延迟。

值得注意的三个取舍

V3 的 2.788M 是 2048 张 H800 的官方账本；V4 的加速比是相对非融合基线；1M 上下文效率是相对 V3.2 的估算。

V3：集群与并行度是账本的一部分

2.788M H800 GPU-hours 的条件是 2048 张 H800、 16-way PP / 64-way EP（8 节点）/ ZeRO-1 DP、FP8 训练和 DualPipe。 换成更小的集群、不同的 IB/NVLink 带宽、或不同的 EP/PP 比例，重叠收益和 step time 都会变。 V3 的 deployment 也偏大：prefill 最小 32 GPU，decode 最小 320 GPU；论文在 §6 明确说 "the recommended deployment unit ... is relatively large"，对小型团队可能是负担。

FP8 的边界同样具体：H800 的 Tensor Core 累加精度约 14 bit， 论文靠 N_C=128 的 CUDA-core 提升来补； 如果换成没有同等 FP8 累加能力的硬件，这个配方不能直接搬（推断，依据：§3.3.2 的 14 bit 是 H800 的测量值）。 Dgrad 的 block-wise 量化在 16B 模型、300B tokens 上会发散， 说明「激活梯度」比「权重/激活」更敏感；这也是为什么 V3 只对部分张量用低精度缓存。

V4：加速比是推理、相对非融合基线；1M 效率是估算

1.50–1.73× 与 1.96× 都是 inference 的 speedup，比较对象是「strong non-fused baselines」， 不是 V3 的 DualPipe，也不是训练吞吐。1.96× 只出现在 latency-sensitive 场景（RL rollout、high-speed agent serving）； 通用推理是 1.50–1.73×。论文在 NVIDIA GPU 与华为 Ascend NPU 上都验证过，但开源的 MegaMoE 是 CUDA 版。

1M 上下文的 27%/10%（Pro）与 10%/7%（Flash）是论文的估算值， 其中 FLOPs 以 equivalent FP8 FLOPs 计、KV cache 是 size 比例；相对 V3.2，不是端到端 latency，也不是相对 V3。V4 报告没有给出全量训练 GPU-hours，页面写「未获取」， 不用 V3 的 2.788M 去推算 V4 的成本。

训练稳定性：两篇报告给出的是不同模型的观察

V3 在 §1 写：整个训练过程没有出现不可恢复的 loss spike，也没有 rollback。 V4 在 §4.2.3 写：训练 trillion-parameter MoE 时遇到了 notable instability，simple rollbacks 只能暂时恢复， 最终用 Anticipatory Routing 与 SwiGLU Clamping 处理。 这是两个模型、两套训练配方下的报告；V3 的「稳定」不能外推到 V4，V4 的「不稳定」也不能反推 V3。 V4 还明确说，这两种技术的底层原理仍未被充分理解（§6），所以它们是工程手段，不是可证明的通用规则。

什么时候别用

• 集群互联远低于 V3 的 IB 50 GB/s / NVLink 160 GB/s。DualPipe 的重叠预算会变；先按 V4 §3.1 的 C/B ≤ 6144 算一遍，再决定是否值得上 EP-heavy 的并行。
• 模型不是 EP-heavy 的 MoE。DualPipe 的收益来自跨节点 all-to-all；dense 模型或 EP 很小的模型，PP bubble 可能才是主项，1F1B/ZB1P 的性价比更高。
• 需要严格逐位复现，却只照搬 V3 的 FP8 配方。V3 报告未涉及 batch invariance/determinism；V4 专门做了 batch-invariant + deterministic kernel（§3.3）。如果复现性是硬要求，应该按 V4 的 kernel 设计，而不是只换精度。
• 小团队或小集群。V3 的 prefill/decode 最小部署单元是 32 GPU / 320 GPU；V4 的百万上下文服务也需要可观的 KV cache 与落盘带宽。先确认部署单元，再谈单位成本。
• 把 V4 的推理加速当成训练加速。1.50–1.73× / 1.96× 是 inference；V4 没有报告全量训练 GPU-hours，不能用它去推算训练成本。
• 把 FP4 QAT 的 2× 当成端到端 2×。2× 是 top-k selector 的加速，99.7% 是 KV entry recall；两者都不是整模型吞吐或精度。