# DeepSeek 集合通信调研（官方一手资料）

检索日期：2026-08-24（工作区系统日期）。本笔记只记录官方 DeepSeek API 文档、DeepSeek-AI arXiv 技术报告、DeepSeek-AI GitHub/Hugging Face 的可直接核实内容；“集合通信”指跨 rank 的 all-to-all、all-gather、reduce-scatter 等，不把普通点对点传输误写成集合操作。

检索入口包括 Google 查询 `Ascend MC2 算子 官方`、`site:gitcode.com/cann MC2 HCCL`、`DeepSeek V4 technical report all-to-all` 和 `DeepSeek V3 all-to-all expert parallelism`。Google 结果只用于发现入口；下文的事实均回溯到官方文档、仓库源码、arXiv 报告、官方模型卡或公开工程源码。Google 页面存在验证码限制，因此以可下载的一手 URL 和本地源码为准。

## 摘要

- **MC2 的定位：** HCCL 文档中的 MC2 是 `Kernel Fusion Custom` 自定义算子框架，不是一个固定的 AllReduce 算子。公开接口可配置通信类型、数据类型、规约、算法配置和通信引擎；HCOMM 源码进一步显示其可映射到 AllReduce、AllGather、ReduceScatter、AlltoAll/AlltoAllV、Send/Recv 等通信语义。
- **DeepSeek-V4 已确认的通信：** MoE EP 使用 Dispatch All-to-All 和 Combine All-to-All；MoE 梯度同步使用 All-to-All 加本地 FP32 求和，替代传统 tree/ring ReduceScatter；长上下文 CP 使用相邻 rank KV 发送加 All-Gather。
- **Ascend 映射：** vLLM Ascend 的 `MC2`/`FUSED_MC2` 路径明确连接 MoE token dispatch/combine，并存在 `dispatch_ffn_combine`、`mega_moe`。这证明了公开 Ascend 工程的实现路径，但**没有证明 DeepSeek 官方训练或推理一定调用 HCCL MC2**。
- **建模建议：** 把 EP Dispatch/Combine 建模为多对多 token 交换，把梯度路径建模为 All-to-All 与本地 reduction 两阶段，把 CP 建模为 P2P 边界交换再 All-Gather；不要把融合算子直接拆成标准 collective 或底层 SQE/WQE 时序。

## 下载资料包

已下载到 [`docs/analysis/mc2-deepseek-v4-sources/`](/home/luosichen/workspace/cann_gitcode/docs/analysis/mc2-deepseek-v4-sources/)：

| 类别 | 文件 |
| --- | --- |
| DeepSeek-V4 | `deepseek-v4-technical-report.pdf`、`.html`、`deepseek-v4-preview-news.html`、`deepseek-v4-ga-news.html` |
| 对照报告 | `deepseek-v3-technical-report.pdf`、`deepseek-v2-technical-report.pdf` |
| DeepSeek 工程 | `deepseek-ai-deepep-readme.md`、`deepseek-ai-deepep-legacy.md`、`deepseek-ai-deepgemm-readme.md` |
| Ascend/HCCL/HCOMM | `hccl_mc2.h`、`hccl_mc2.cc`、`hccl-mc2-header-and-library.md`、`hcomm-mc2-type.h`、`hcomm-mc2-selector.cc`、`hcomm-aiv-mc2.cpp`、`hcomm-alltoallv-direct-fullmesh.cc` |
| vLLM Ascend | `vllm-ascend-envs.py`、`vllm-ascend-moe-comm-method.py`、`vllm-ascend-dispatch-ffn-combine-def.cpp` |

PDF、HTML 和源码快照均通过来源 URL 下载；资料包中的本地 HCCL/HCOMM 文件来自当前工作区对应仓库，未修改原仓库代码。文件大小和 SHA-256 可用 `sha256sum docs/analysis/mc2-deepseek-v4-sources/*` 复核。

## 本地 MC2 / Ascend 证据

### 资料范围和术语

本节基于当前工作区的 HCCL/HCOMM 源码和其官方 GitCode 镜像（访问时间：2026-08-24）。这里的 MC2 是 HCCL 文档定义的 **MC2（Kernel Fusion Custom）自定义算子框架**，不是一个单独的集合通信原语。用户通过 MC2 参数对象/tiling 指定通信算子类型、数据类型、规约类型、算法配置和通信引擎，再由 HCOMM 选择并编排通信资源。

| 证据 | 可核实内容 | 证据等级 |
| --- | --- | --- |
| [HCCL 头文件与库文件说明](https://gitcode.com/cann/hccl/blob/master/docs/zh/api_ref/hccl_header_and_lib.md) | HCCL 对外集合通信接口包括 AllReduce、Broadcast、AllGather/AllGatherV、ReduceScatter/ReduceScatterV、Scatter、Reduce、AlltoAll/AlltoAllV/AlltoAllVC；点对点包括 Send、Recv、BatchSendRecv；`hccl_mc2.h` 是 MC2 自定义算子框架接口 | 官方文档/高 |
| [`hccl_mc2.h`](https://gitcode.com/cann/hccl/blob/master/include/hccl_mc2.h) | `HcclKfcAllocOpArgs`、数据类型/规约/计数/算法配置/通信引擎 setter，以及 `HcclCreateOpResCtx` | HCCL 源码/高 |
| [`hccl_mc2.cc`](https://gitcode.com/cann/hccl/blob/master/src/common/hccl_mc2.cc) | 参数默认值为 FP16/SUM/count=0；`count` 有上限校验；当前实现只接受 `COMM_ENGINE_AICPU` 或 `COMM_ENGINE_AIV`（源码注释为 A3 场景），然后调用 `HcclCreateOpResCtxInner` | HCCL 源码/高 |
| [`hcomm` 架构说明](https://gitcode.com/cann/hcomm/blob/master/docs/zh/architecture/architecture-brief.md) | HCCL（L1 算子）通过 HCOMM 集合通信域和基础通信层；HCOMM 对算子开发开放拓扑/资源查询（L2）与 Write/Read/Reduce/Notify 原语（L3） | 官方文档/高 |

HCCL public MC2 setter 中的 A3/AICPU/AIV 限制，与 HCOMM Ascend950 legacy selector 中的 CCU MS/CCU Sched 条目属于不同产品/版本路径；本笔记并不把它们拼成一个统一的运行时合同。

### MC2 可表达的算子和类型

[`hcomm/src/legacy/ascend950/common/types/mc2_type.h`](https://gitcode.com/cann/hcomm/blob/master/src/legacy/ascend950/common/types/mc2_type.h) 的 `AicpuComType` 和 `MC2_OP_TYPE` 是 MC2 类型映射的直接证据：

- 映射为有效 `OpType` 的通信包括 `BROADCAST`、`ALLREDUCE`、`REDUCE`、`SEND`、`RECV`、`ALLGATHER`、`REDUCESCATTER`、`ALLTOALLV`、`ALLTOALLVC`、`ALLTOALL`、`GATHER` 和 `HALFALLTOALLV`。
- 同一枚举还列出了 `GATHER`、`SCATTER`、`BATCHSENDRECV`、`BATCHPUT`、`BATCHGET`、`ALLGATHER_V`、`REDUCE_SCATTER_V`、`BATCH_WRITE` 等编码，但当前 `MC2_OP_TYPE` 数组对其中部分条目映射为 `INVALID`；不能仅凭枚举名字声称这些条目在 MC2 当前路径可用。
- 支持 `SUM`、`PROD`、`MAX`、`MIN` 规约映射，并有 HCCL 数据类型到 HCOMM `DataType` 的映射。`Mc2Tiling`/`Mc2CcTilingInner` 包含 `opType`、输入/输出数据类型、`reduceType`、`algConfig`、`groupName`、`stepSize`、`protocol`、`communicationEngine` 等字段；V1/V2 tiling 版本常量分别为 3/100。

**重要边界：** MC2 的 `opType` 只描述通信意图；底层执行可能由 CCU、AICPU 或 AIV 路径编排，不能把 MC2 API 调用直接等价成某一个 A5 UBDMA SQE，也不能从 `opType=ALLREDUCE` 单独推导 Ring/NHR/mesh 的逐包时序。

### MC2 算法选择和拓扑

[`mc2_selector.cc`](https://gitcode.com/cann/hcomm/blob/master/src/legacy/ascend950/service/collective/alg/selector/mc2_selector.cc) 是当前源码中最清晰的 MC2 算法清单。`ExecuteSelector::Run` 只有在 `params.isMc2` 时进入 MC2 selector（priority 18），并按 accelerator state 选择；不支持的 state 直接失败，不自动回退。

| 通信引擎/拓扑 | 源码中的默认算法名 | 能确认的集合原语 |
| --- | --- | --- |
| CCU MS，1D mesh | `CcuAllGatherMesh1D`、`CcuReduceScatterMesh1D`、`CcuAllReduceMesh1D`、`CcuReduceMesh1D`、`CcuAlltoAllMesh1D`、`CcuAlltoAllVMesh1D`、`CcuHalfAll2AllVMesh1D` | AllGather、ReduceScatter、AllReduce、Reduce、AlltoAll、AlltoAllV、HalfAlltoAllV |
| CCU MS，2D mesh | `CcuAllGatherMesh2D`、`CcuReduceScatterMesh2D`、`CcuAllReduceMesh2DOneShot`、`CcuReduceMesh2D`、`CcuAlltoAllMesh2D` | AllGather、ReduceScatter、AllReduce、Reduce、AlltoAll |
| CCU Sched，1D mesh/1D-clos | `CcuAllGatherMeshMem2Mem1D`、`CcuReduceScatterMeshMem2Mem1D`、`CcuAllReduceMeshMem2Mem1D`、`CcuAlltoAllMesh1D`、`CcuAlltoAllVMesh1D`、`CcuHalfAll2AllVMesh1D` | AllGather、ReduceScatter、AllReduce、AlltoAll、AlltoAllV、HalfAlltoAllV |
| AICPU TS，1D mesh | `InsAllGatherMesh`、`InsReduceScatterNHR`、`InsAllReduceNHR`、`InsReduceNHR`、`InsAlltoAllMesh`、`InsAlltoAllvMesh`、`InsBatchSendRecv`、`InsBroadcastNHR`、`InsScatterNHR`、`InsSend`、`InsRecv` | 集合 + Send/Recv；具体实现名是 NHR 或 mesh，但不应把名字当作硬件时序证明；源码中的 MC2 AICPU 2D 默认 map 当前为空 |

MC2 CCU 选择器目前明确只允许 1D/2D mesh（Sched 另允许 1D-clos）。这是“当前仓库实现的选择合同”，不是所有 Ascend 产品或芯片微架构的通用结论。

### AIV/URMA 与 AIV/UB-memory MC2 路径

[`aiv_mc2_compont.cpp`](https://gitcode.com/cann/hcomm/blob/master/src/legacy/ascend950/framework/aiv/aiv_mc2/aiv_mc2_compont.cpp) 显示 AIV MC2 资源上下文包含 `rankId`、`rankDim`、工作区和每个 rank 的 `windowsIn/windowsOut`；它从 full-mesh links 建资源，并根据 protocol=0（UB-memory）或 protocol=1（URMA）设置预处理器。V2 tiling 读取 `opType`/dtype/reduce，并调用 `MC2OpType`、`MC2DataType`、`MC2ReduceType`。

这说明 MC2 可以把跨 rank window/URMA 资源交给 AIV 通信内核，但源码没有证明某个 DeepSeek 模型实际调用了 HCCL MC2；两者只能做语义层映射，不能当作产品集成事实。

### 具体 AlltoAll/AlltoAllV 代码证据

在 A2/A3 兼容路径的 [`alltoallv_direct_fullmesh.cc`](https://gitcode.com/cann/hcomm/blob/master/src/legacy/ascend910/algorithm/base/alg_template/temp_alltoallv/alltoallv_direct_fullmesh.cc) 中，`mc2Handler.stepSize > 0` 会进入 MC2 fine-grained AlltoAllV：本地 SDMA 并发降为 1、限制 `totalStep` 只能为 0/1，并在每个通信轮执行 `Mc2WaitValue` → full-mesh send/receive → `Mc2WriteValue`；`stepSize` 要求不超过 rank size 且 rank size 必须整除 stepSize。这个证据可支持“该 legacy MC2 AlltoAllV 路径存在按轮次 wait/write 的细粒度全连接调度”，不能泛化成所有 MC2 算子或 A5 当前路径。

### MC2 与 DeepSeek 集合通信的关系

- **已证实：** MC2/HCCL 代码提供 AlltoAll/AlltoAllV、AllGather、ReduceScatter、AllReduce 等候选通信语义，并支持 CCU/AICPU/AIV 资源路径；DeepSeek-V3/V4 官方资料分别明确了 MoE EP 的 Dispatch/Combine All-to-All 等通信。
- **合理推断：** 若将 DeepSeek 的 EP token dispatch/combine 迁移到 Ascend/HCCL，最接近的高层候选是 `ALLTOALL` 或 `ALLTOALLV`（按 token/expert 路由量是否固定选择），而不是把它直接标成 `ALLREDUCE`。V4 的“梯度 all-to-all 后本地 FP32 sum”也更接近 AlltoAll + 本地 Reduce，而非一个已证实的 HCCL ReduceScatter 算子。
- **未知/不可由当前资料证明：** DeepSeek 官方公开资料没有声明 V3/V4 使用 HCCL MC2、Ascend CCU、AIV 或 HCCL 算法名；V3 报告明确以 H800/NVLink/NVSwitch/InfiniBand 为训练硬件，V4 只说在 NVIDIA GPU 和 HUAWEI Ascend NPU 平台验证 EP 方案，未给出 HCCL/MC2 接口调用或 Ascend 拓扑的逐 rank 合同。不要将 DeepSeek 的 All-to-All 论文描述直接转换成 MC2 的具体 SQE/WQE、Jetty 或 STARS 时序。

## DeepSeek-V4

### 一手来源与发布状态

- 官方 API Docs 新闻：[DeepSeek V4 Preview Release](https://api-docs.deepseek.com/news/news260424)，页面标注 2026-04-24；明确称 V4 Preview 已上线并开源，给出 V4-Pro/V4-Flash 参数量、1M context、技术报告链接和 open weights 集合。
- 官方 API Docs 新闻：[DeepSeek-V4-Pro GA Release](https://api-docs.deepseek.com/news/news260813)，页面标注 2026-08-13；这是当前检索日期可见的 GA 发布公告。它不替代技术报告中对通信原语的描述。
- 技术报告：[DeepSeek-V4: Towards Highly Efficient Million-Token Context Intelligence](https://arxiv.org/abs/2606.19348)（DeepSeek-AI，v1，2026-04-26）；报告摘要给出 V4-Pro 1.6T/49B active、V4-Flash 284B/13B active、1M context；模型检查点指向 [official HF collection](https://huggingface.co/collections/deepseek-ai/deepseek-v4)。证据等级：官方技术报告（高）。
- 官方权重卡：[DeepSeek-V4-Pro](https://huggingface.co/deepseek-ai/DeepSeek-V4-Pro)、[DeepSeek-V4-Flash-0731](https://huggingface.co/deepseek-ai/DeepSeek-V4-Flash-0731)。两者 README 均链接 V4 技术报告 `arXiv:2606.19348`；Flash README 的官方 vLLM 示例使用 `--data-parallel-size 4 --enable-expert-parallel`，但这是部署示例参数，不应推断为训练固定拓扑。
- 官方 CUDA kernel：[DeepGEMM](https://github.com/deepseek-ai/DeepGEMM)，README 将 Mega MoE 描述为融合/重叠 EP dispatch、Linear-1、SwiGLU、Linear-2 和 EP combine；[PR #304](https://github.com/deepseek-ai/DeepGEMM/pull/304)（2026-04-16/17）为公开发布说明。

### 报告明确的通信原语和并行维度

1. **Expert Parallelism（EP）MoE dispatch/combine：all-to-all。** V4 报告第 3.1 节将每层 MoE 拆成 Dispatch、Linear-1、Linear-2、Combine；图 5 明确标注 `Dispatch All-to-All` 和 `Combine All-to-All`。方案把专家分成 wave，下一 wave 的 token transfer、当前 wave 的计算、完成 wave 的结果发送重叠，形成通信-计算流水。
2. **EP 的通信实现：pull-based remote reads。** 报告第 3.1 节“Communication Primitives”明确说 dispatch 采用 pull-based：每个 GPU 主动读取远端 GPU activation，以避免细粒度 push 的通知延迟。这是实现策略，不是额外的 MPI/NCCL 集合原语；不能把 pull 读直接等价为 all-gather。
3. **Muon/ZeRO 参数同步：reduce-scatter 被两阶段 all-to-all + 本地 FP32 sum 取代。** 第 3.4.1 节先说明 dense parameter bucket padding 便于 reduce-scatter；对 MoE gradients，先量化为 BF16 后同步。由于低精度加法误差，报告明确写道：用“两阶段方法”替代传统 tree/ring reduce-scatter，第一阶段各 rank 做 all-to-all 交换 local gradients，第二阶段每 rank 本地 FP32 求和。证据等级：报告原文，高；这是训练优化器梯度同步路径，不是 MoE activation dispatch。
4. **Context Parallelism（CP）长上下文：邻居点对点 + all-gather。** 第 3.4.3 节：第一阶段 rank `i` 将最后 `m` 个 uncompressed KV entries 发给 rank `i+1`，由后者压缩；第二阶段在所有 CP ranks 上执行 all-gather，收集各 rank 的 compressed KV entries，再 fused select-and-pad 重排成完整集合。证据等级：报告原文，高。
5. **mHC pipeline 通信：增加 pipeline-stage 通信并配合 1F1B overlap。** 第 3.4.2 节称 mHC 比 conventional residual 增加 activation memory 和 pipeline stage 间通信，调整 DualPipe 1F1B 使部分 mHC 操作并发；报告没有把这一项命名为具体集合原语，不能进一步推断 all-reduce/all-gather。

### V4 可落到仿真的集合通信动作

```text
MoE EP layer:       Dispatch all-to-all -> expert GEMMs -> Combine all-to-all
Muon/ZeRO MoE grad: all-to-all gradients -> local FP32 sum
Long-context CP:    neighbor send(last m KV) -> local compress -> all-gather compressed KV
```

报告没有公开 V4 训练的固定 `TP/PP/EP/DP/CP` 数值拓扑；上述 CP、EP 是并行维度和语义，不能从 V4 权重卡里的 vLLM `data-parallel-size 4` 示例反推训练配置。官方 V4 报告只说 V4 继承 V3 的 DeepSeekMoE/MTP 框架，并称“重新设计并行策略”，且移除 V3 的 target-node 数量约束。

## DeepSeek-V3（可作 V4 通信背景基线）

- 官方报告：[DeepSeek-V3 Technical Report](https://arxiv.org/abs/2412.19437)（DeepSeek-AI，2024-12-27；v2 2025-02-18）。官方代码：[DeepSeek-V3](https://github.com/deepseek-ai/DeepSeek-V3)。
- 固定训练并行维度（报告第 3.2 节）：16-way Pipeline Parallelism (PP)、64-way Expert Parallelism (EP，跨 8 节点)、ZeRO-1 Data Parallelism (DP)，明确“不使用 costly Tensor Parallelism (TP)”。训练集群 2048 H800，节点内 NVLink/NVSwitch，节点间 InfiniBand（报告第 3.1/3.2）。
- DualPipe 将 forward/backward chunk 分成 attention、all-to-all dispatch、MLP、all-to-all combine，并让 all-to-all 与 PP 通信被计算隐藏（第 3.2.1）。
- Cross-node all-to-all kernel（第 3.2.2）：跨节点 GPU 通过 IB，节点内 NVLink；token 最多派发到 4 个节点，以降低 IB traffic；先 IB 到目标节点同 in-node index GPU，再通过 NVLink 转发到承载目标 expert 的 GPU；只用 20 SM 充分利用 IB/NVLink 带宽。
- 推理并行（第 3.4）：prefill 最小单元 4 节点/32 GPU，attention TP4+SP、DP8，MoE EP32；MoE all-to-all 仍采用 IB 跨节点后 NVLink 节点内转发。decode 最小单元 40 节点/320 GPU，attention TP4+SP、DP80，MoE EP320；dispatch/combine all-to-all 采用跨节点 IB 的 direct point-to-point，结合 IBGDA 降低延迟。注意这是 V3 报告明确的推理配置，不应当移植成 V4 配置。

### DeepEP 官方实现（V3 相关工程证据）

- [DeepEP README](https://github.com/deepseek-ai/DeepEP/blob/main/README.md)（DeepSeek-AI 官方仓库，访问 2026-08-24）将 EP 的高吞吐/低延迟 GPU kernels 直接定义为 MoE dispatch/combine all-to-all，并支持 FP8 dispatch；V2 使用 NCCL Gin backend，可复用 NCCL communicator，实验性支持 PP/CP/远程内存原语。
- [DeepEP V1 legacy 文档](https://github.com/deepseek-ai/DeepEP/blob/main/docs/legacy.md) 明确说明该实现参考 DeepSeek-V3 的 group-limited gating，但实现可能有差异；节点内使用 NVLink、节点间使用 RDMA/InfiniBand，测试覆盖 EP 8/16/32/64 和 FP8 dispatch + BF16 combine。
- 这证明 DeepSeek 生态中存在公开的专用 EP all-to-all 实现和网络分层优化，但不等于 V3 论文中的 HAI-LLM 生产实现，也不等于 HCCL MC2；应将 DeepEP 标作独立工程实现证据。

## DeepSeek-V2（早期通信设计背景）

- 官方报告：[DeepSeek-V2: A Strong Mixture-of-Experts Language Model](https://arxiv.org/abs/2405.04434)（DeepSeek-AI，2024-05-07）。
- Device-Limited Routing：报告第 2.2.2 节说明 expert parallel 下 token 的 MoE 通信量随覆盖设备数增长；每 token 最多发往 `M` 个设备。训练配置第 3.1.2 节采用每层专家均匀部署到 8 devices（`D=8`）、每 token 最多发送到 3 devices（`M=3`）；并以 communication balance loss 约束每设备接收量。
- 训练并行：HAI-LLM 使用 16-way zero-bubble PP、8-way EP、ZeRO-1 DP；不使用 TP。报告明确把 shared experts 的计算与 expert-parallel all-to-all 通信重叠，并定制 CUDA communication/routing/fused kernels（第 3.1.2 节）。节点内 NVLink/NVSwitch、节点间 InfiniBand。

## 结论和证据边界

- 不能再说“DeepSeek-V4 没有公开资料”：截至检索日期，官方 API Docs、官方 arXiv 技术报告和官方 HF 权重都已公开 V4；报告版本标为 preview，API Docs 另有 2026-08-13 GA 页面。
- V4 最强的集合通信证据是：EP Dispatch/Combine all-to-all、Muon/ZeRO 梯度 all-to-all（取代 reduce-scatter）和 CP compressed-KV all-gather。V4 报告没有公布完整硬件拓扑、各并行组大小或每一步精确调度时序。
- V3 的 16 PP/64 EP/ZeRO-1 DP、IB+NVLink 分层 all-to-all、prefill EP32/decode EP320 是明确数字基线；若要映射到集合通信仿真，应标为 V3 代码/报告证据，不能冒充 V4 硬件事实。
- DeepEP/DeepGEMM 是 DeepSeek-AI 公开的专用 EP kernel 工程，适合用来研究 dispatch/combine 的 buffer、RDMA/NVLink 和 overlap 实现；它们仍不是 HCCL MC2 的证据。