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

单个 Codex 或 Claude Code 窗口的问题，不只是“subagent 开得少”，而是人无法稳定回答四个问题：派了谁、做到哪、交了什么、谁验收。调研后的结论是：AutoResearch 已经拥有最重也最重要的持久控制面；下一步不应重写一个多智能体平台，而应补齐人工 UAT，把 Archon 限定为可选的阶段工作流，把 Pi、Codex 和 Claude 作为可替换 worker。

Attention 的发展并不是从 Full Attention 排成一条单向淘汰链。更准确的结构是三条并行路线：共享或压缩 KV cache、把历史压入固定状态、对历史 token 做稀疏选择。MQA、GQA 与 MLA 仍然读取全部历史；GDN 与 KDA 改写了记忆算法；DSA 则在 MLA 前增加轻量索引器，只让主注意力读取 top-k。

本文以首个公开论文或官方发布日为时间点，并把每种结构落到版本固定的开源代码：Q/K/V 从哪里产生、什么对象进入 cache、score 如何形成、复杂度到底被搬到了哪里。

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 与性能优化计划，而不是制造一份猜测配置。

判断并行能力不能只搜索配置名。一个并行轴至少要经过 配置校验、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 不是一种新的 EP 通信算子，而是位于 MoE 层内部的跨微批调度方法：把多个原本独立做梯度累积的 micro-batch 一起送入模型，用异步通信流把一个 micro-batch 的 token dispatch/combine 与另一个 micro-batch 的专家计算重叠。

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

HybridEP 论文进一步提出了一个更上游的问题：跨数据中心带宽太低、通信已经无法完全隐藏时，是否还应坚持“专家不动、所有 token 都跨域搬运”？它通过比例 (p) 在 token All-to-All 与压缩 expert AllGather 之间选择，改变的是通信对象与专家放置，而不是给 DeepEP 或 MC2 换一个名字。

2026 年 8 月的增量观察再补两层：MoonEP 用在线冗余 expert 与权重预取把路由偏斜转成每个 rank 固定的计算量；HyperParallel-MoE 则在 Ascend A3 上把 Dispatch、两次 GMM、SwiGLU 和 Combine 编译成 AIC/AIV 瓦片任务流。前者回答“热点 expert 怎么摊平”，后者回答“单个 MoE-FFN 内的通信与计算怎么细粒度交错”；二者都不是 XTuner 当前已有开关。

训练 profiling 通常围绕 forward、backward、optimizer 和通信几类稳定阶段展开；推理 profiling 则更像一条被压扁的多层时间带：prefill、decode、spec decode、采样、图模式、host 同步、调度空隙和特殊融合算子会叠在同一个 step 里。

这篇文章用一次 vLLM-Ascend trace 作为样本，先把 Free、vllm::gdn_attention_core、FusedInferAttentionScore、GemmaRmsNorm、fused_sigmoid_gating_delta_rule_update_kernel_0、aclnnInplaceUniform_DSARandomUniform_DSARandomUniform 这些名字拆开，再总结一套以后跟踪新模型融合算子的 checklist。

截至 2026-07-07，Ascend 950 A5 对多模态生成的公开支持已经不是零，但它更像三层拼图：vLLM-Omni 已把 Ascend NPU、Wan2.2/Qwen-Image 等 diffusion 量化路径写进文档；vLLM-Ascend 主分支出现 A5/950 与 MXFP/W8A8 等后端代码；VeRL-Omni 已能用 vLLM-Omni 做 Ascend NPU rollout，但量化默认仍是空配置，公开 recipe 还没有给出 A5 量化 RL 的性能和精度结论。本文只写可追溯来源，尤其区分“文档支持”“代码路径”“验证效果”和“仍需实测”。

这篇文章记录一次从“pod4 比 pod8 跑 Qwen3.5 397B SFT 慢约 10%”出发的集群健康定位。普通 allgather 打流没有复现差异，并不等于训练链路健康；真实慢点可能在 CPU 绑核、H2D、固定两卡 D2D、背景设备负载、rank-to-core 放置和框架调度之间。ClusterHealthDetect 的作用，是把这些变量拆成可复现实验矩阵，成为训练性能模型里的校准账本。

讨论 BSND/TND 时，最容易误判的是把 推理 prefill 支持 当成 训练全链路支持。对 Qwen3.5 这类含 Gated Delta Net 的模型，TND 不只是把 [B, S, N, D] reshape 成 [T, N, D]：训练还要覆盖 backward、recurrent state、cu_seqlens、label / loss mask、old logprob、ref logprob、actor update 和框架并行契约。

本文的结论是：推理 TND 是中等工程量，训练 TND 是大工程量；verl 已经支持 Qwen3.5 RL，但具体 layout 支持取决于 FSDP/Megatron/MindSpeed/vLLM 路径，不能一概而论。