跳转至

1-Distributed Parallelism

Attention Cache and Sequence Parallelism

导言

KV cache 最容易造成的误解，是把所有名为 K/V 或 state 的张量都看成同一种“缓存”。事实上，训练时为反向传播保留的 K/V activation、推理时跨 decode step 存活的 KV cache、GDN 跨 token 改写的固定状态，生命周期和分布式处理都不同。

本文从一次 token 生成开始，逐对象解释 MHA、DSA 与 GDN 保存什么，再讨论 CP、USP 切开长序列后，临时 activation 和持久 cache 分别需要怎样的通信。

DeepSpeed Memory and Parallelism

导言

“显存不够”不是一个足够精确的诊断。可能是优化器状态常驻 GPU，可能是 ZeRO-3 跨节点通信暴露，也可能是单层矩阵本身无法放进一张卡。ZeRO-Offload、ZeRO++、MixZ++ 和 AutoTP 分别处理这四类问题，不能把它们当成同一开关的不同档位。

Kimi K3 NPU Training

导言

Kimi K3 的 NPU 适配不是给现有 MLA-MoE 模型换一组配置。它同时引入 Kimi Delta Attention（KDA）、Block Attention Residuals（AttnRes）和 Stable LatentMoE，分别改变层内状态、跨层残差和专家通信。

截至 2026 年 7 月 20 日，官方已确认 K3 是 2.8T 参数、原生多模态、1M 上下文、896 专家激活 16 个，并采用 3× KDA + 1× Gated MLA；但完整权重、精确 config 和技术报告仍待发布。因此本文严格区分 已确认事实、组件证据、工程推导和发布后必验项，目标是形成可执行的 NPU bring-up 与性能优化计划，而不是制造一份猜测配置。

VeRL Backend Parallelism

导言

判断并行能力不能只搜索配置名。一个并行轴至少要经过 配置校验、process group/device mesh、模型计算、loss/backward 和目标训练流程，才能算后端支持。

截至本文固定的 verl commit，结论最明确的一项是：原生 FSDP2 支持 Ulysses Sequence Parallel（USP），但不支持 Expert Parallel（EP）和 Context Parallel（CP）。如果希望 FSDP2 同时使用 EP，应选 VeOmni；如果需要 TP、PP、EP、CP 的完整模型并行组合，应选 Megatron。

XTuner Domino EP

导言

XTuner 的 Domino EP 不是一种新的 EP 通信算子，而是位于 MoE 层内部的跨微批调度方法：把多个原本独立做梯度累积的 micro-batch 一起送入模型，用异步通信流把一个 micro-batch 的 token dispatch/combine 与另一个 micro-batch 的专家计算重叠。

普通 EP 定义专家如何切分；All-to-All、DeepEP、AGRS 决定 token 如何搬运；Domino EP 决定多个 micro-batch 如何交错；MC2 则把相邻通信和矩阵乘融合进一个算子。只有先分清这四层，才能正确讨论它们的优劣和组合关系。

VeRL Async Policy

导言

VeRL async 的核心问题不是“开异步就一定更快”，而是把 rollout 长尾、训练更新、参数同步和旧样本容忍度放到同一个队列系统里调参。这篇笔记梳理 VeRL 老版 one_step_off_policy / fully_async_policy 与新版 trainer v1 的关系，解释 staleness 的真实语义，并给出 64P、128P NPU 场景下选择训推资源比例的第一轮计算方法。