01 · 一层里的计算和通信依赖
以行并行 Linear 为例，把输入维度和权重的对应维度切到两卡：X=[X₀,X₁]，W 按输入维度分成 W₀、W₁。每卡先得 Yᵣ=XᵣWᵣ，最终 Y=Y₀+Y₁。若输出需要每卡持有完整结果，可用 AllReduce；若后续只需要各卡不同分片，可采用匹配布局的 ReduceScatter。
这两类通信输出布局不同，不能为了融合而任意替换。另一个常见模式是先 AllGather 补齐输入，再做 MatMul。传统串行方案会等完整前序算子结束，才能启动下一步。
依据：Megatron Core · Parallelism Guide ↗ · NVIDIA · cuBLASMp Tensor Parallelism ↗
02 · MC² 的计算—通信协同
MC² 是昇腾通算融合方案。官方给出 AllGatherMatMul、MatMulReduceScatter、MatMulAllReduce 等组合。核心阅读方式是看复合算子怎样划分数据、释放局部就绪条件并推进流水，而不是只看 API 数量。
对 MatMul→AllReduce，可以按输出行分块：第1块计算结束后开始归约，同时计算第2块。对 AllGather→MatMul，可以在足够输入块到达后开始相应计算，其余数据继续传输。输出块是否独立、输入块如何累积，取决于切分轴和矩阵乘法语义。
NVIDIA cuBLASMp 文档也给出 AG+MatMul、MatMul+RS 及 MatMul+AllReduce 的相关路径。两家都存在通算协同，API、布局和设备支持不同；不能把 MC² 当作“只有华为在做”的方向。
依据：昇腾 · MC² 通算融合最佳实践 ↗ · NVIDIA · cuBLASMp Tensor Parallelism ↗
03 · 两卡与四个输出块
自设例子：Xᵣ=[128,1024]、Wᵣ=[1024,2048]，每卡局部 Yᵣ=[128,2048]。按 M=128 切成4块，每块32行；在2字节输出假设下，每个完整局部输出为512 KiB、每块128 KiB。各卡对同一行块归约，得到该块正确的 Y。
for chunk in same_order_on_all_ranks:
local_y = matmul(X_local[chunk], W_local)
signal_compute_ready(chunk)
# 由协同调度让此通信和后续块计算并行
all_reduce_when_ready(local_y, group)
wait_for_all_output_chunks()上面的普通顺序 Python 循环本身不会实现内部融合，代码只展示数据依赖。设4块计算各3 ms、通信各2 ms：串行20 ms；理想流水3+3×max(3,2)+2=14 ms。这个30%的耗时下降是自设模型，不是官方设备收益。
计算—通信时间线 · 算子内分块
理想双引擎、同块先算后传；未计启动、争用与切块导致的性能变化。真实切块后每块耗时可能上升。若碎块导致 GEMM 利用率降低或通信启动太频繁，流水节省的等待会被新增开销抵消。不能假设整矩阵耗时可以按块数等比例缩小。
04 · 调优时按这条路径检查
- 先确认层的通信语义、rank 分组、张量布局与输出要求，保持与基线一致。
- 分别测完整 MatMul 和完整集合通信，判断哪一段占主导。
- 尝试候选切块，记录小块 GEMM、通信以及额外启动成本。
- 调用适配的复合算子 / 库，检查就绪事件、缓冲复用和实际时间线。
- 比较完整层的输出误差；训练还要比较反向与参数梯度。
官方 Ascend C 最佳实践中的特定 MatMulAllReduce 样例按 M 轴划分连续块；这是该样例布局和接口约束，不应推广成“所有通算融合只能切 M”。NVIDIA 路径也需核对行 / 列主序与转置解释。
依据：昇腾 · MC² 通算融合最佳实践 ↗ · NVIDIA · cuBLASMp Tensor Parallelism ↗
05 · 它与本地算子融合到底有什么不同
| 方法 | 例子 | 关注点 |
|---|---|---|
| 本地算子融合 | 残差 + 归一化 | 减少中间写回、启动与多次读写。 |
| 运行时重叠 | 归约已就绪梯度 + 后续反向 | 利用不同任务间可并行的依赖。 |
| 通算融合 | MatMul + ReduceScatter | 在算子级共同切块并控制通信 / 计算进度。 |
融合接口可能内部启动多个 kernel、使用多个执行单元和缓冲，所以不能用“底层只有一个 kernel”定义 MC²。更小的 Decode 矩阵可能缺少可切块的计算量；网络瓶颈、资源争用、跨机拓扑都可能影响收益。
06 · 跨平台比较应记录什么
- 相同数学层、M/N/K、dtype、输出分片语义与 rank 数。
- 实际库版本、设备互联、分组、布局和切块方案。
- 分离基线、融合耗时、HBM / 工作区峰值、输出与梯度误差。
- 模型端到端吞吐与延迟：某一层提速不能直接当作整个模型的提速。
当前文章比较执行机制，不给两家设备作同负载实测排名。官方示例与库文档是可追查的实现入口；具体型号与算子版本仍应按运行环境选择。
依据：昇腾 · MC² 通算融合最佳实践 ↗ · NVIDIA · cuBLASMp Tensor Parallelism ↗
07 · 自查与小实验
- 推导两卡行并行 Linear 的 Y 为何需要求和，而不是拼接。
- 把计算块3 ms改成1 ms、通信块2 ms改成5 ms，观察通信主导时的重叠上限。
- 解释为什么 AllReduce 输出和 ReduceScatter 输出不能在不改变后续布局时直接互换。
流程位置与关联方法
这个方法可能出现在多个位置；计算线包含模型计算与算子实现，执行线包含运行时、内存和通信。
资料与核查范围
原理依据以原始论文和官方文档为主；算例与时间线是教学推导。文档核查日期：2026-10-10。引用 main / latest 文档时，实际接口以安装版本为准。
代码为接入片段或教学伪代码；本页没有声称完成 NVIDIA / 昇腾硬件实测。