diff --git a/BMM算子优化分析_Release/MergeBatch_vs_IterBatch分析_v1.0.html b/BMM算子优化分析_Release/MergeBatch_vs_IterBatch分析_v1.0.html new file mode 100644 index 0000000..02350b0 --- /dev/null +++ b/BMM算子优化分析_Release/MergeBatch_vs_IterBatch分析_v1.0.html @@ -0,0 +1,197 @@ + + + + + +MergeBatch vs IterBatch 分析 + + + + + +
+

MergeBatch vs IterBatch：BMM 小 tile 场景的两种实现路径分析

+
目标芯片：昇腾 950PR（DAV_3510）。理论分析基于《BMM 算子优化分析 v0.96》，源码参考 [cann-ops-nn](https://gitee.com/ascend/cann-ops-nn) 中 matmul/batch_mat_mul_v3 实现。
+
+

一、问题定义

+

BMM（BatchMatMul）中，当 B ≥ C（batch 数 ≥ AIC 核数）时，核间切 B 是免费的——每核独立处理若干 batch，无共享无依赖。核内的两种实现路径：

+ +

核心问题：什么条件下 MergeBatch 优于 IterBatch？

+
+

二、IterBatch 理论最优实现

+

2.1 执行模型

+

核间切 B，每核 $b_{core} = B/C$ 个 batch。核内逐 batch 做标准 Matmul：

+
对每 batch i ∈ [0, b_core):
+    GM→L1: 搬入 A_i[M, K] + B_i[K, N]（或按 kL1 分块）
+    L1→L0→Cube: 计算 C_i[M, N]
+    Fixpipe: L0C→GM 写回 C_i
+

2.2 L1 驻留形态

+

IterBatch 按 L1 容量分四种形态（v0.96 §六）：

+ + + + +
形态条件特征
a) 单 batch 全驻留$b_{core}=1$，$(MK+KN) \cdot dtype \le L1$零重复读
b) 双 batch 乒乓$b_{core}>1$，$2(MK+KN) \cdot dtype \le L1$batch 间流水掩盖
c) 一侧驻留+对侧切 K$MK \cdot dtype \le L1/2$（驻留侧）驻留侧零重复读
d) 两侧都切 K兜底两侧都有 K 段级重复读
+

2.3 实现方案

+ +
+

三、MergeBatch 理论最优实现

+

3.1 执行模型

+

核间切 B（同 IterBatch），核内把 $b_0$ 个 batch 合并计算：

+
对每合并组 g ∈ [0, b_core/b0):
+    GM→L1: 搬入 A'[b0·M, K] + B'[K, b0·N]（单次 DMA，ndNum=1）
+    L1→L0→Cube: 计算 C'[b0·M, b0·N]
+    Fixpipe: L0C→GM 写回（只取对角块，丢弃交叉项）
+

交叉项 $(b_0^2 - b_0) \cdot MN$ 被算出但丢弃——浪费比例 $(b_0-1)/b_0$。进入该分支的 case 必然访存 Bound（条件 5 保证），浪费的算力被搬移时延掩盖。

+

3.2 进入条件

+

同时满足（$b_0$ = 最小合并数，取 2）：

+
    +
  1. $BatchA = BatchB$ 且 $b_{core} = B/C \ge 2b_0$
    2. +
  2. $2(b_0 M)(b_0 N) \cdot 4B \le L0C$（合并后输出放得下 L0C 双缓冲）
    3. +
  3. $b_{core}(MK+KN) \cdot dtype \ge min\_DatamountPerCore$（单核搬移量足够）
    4. +
  4. $\max(MK, KN) \cdot dtype \ge min\_TileSize$（搬移 tile 不太小）
    5. +
  5. $2MN/(M+N) < R_{16}/b_0$（合并后仍访存 Bound）
    6. +
+

3.3 实现方案

+

Step 1：合并数 b₀（L0C + 算存比双上限）

+
$$ +b_0 = \min\Big(\sqrt{\frac{L0C}{2 \cdot MN \cdot 4B}},\; \frac{R_{16}(M+N)}{2MN},\; b_{core}\Big) +$$
+

**Step 2：L0 级 K 粒度 $k_{L0}$（由 b₀ 和 L0A/L0B 决定）**

+
$$ +k_{L0} = \min\Big(\frac{L0A}{2 b_0 M \cdot dtype},\; \frac{L0B}{2 b_0 N \cdot dtype}\Big) \text{ 向下 16 对齐} +$$
+

**Step 3：L1 级 $k_{L1}$（先反推再截断）**

+

先令 $b_{L1}^* = b_0$，由 L1 容量反推 $k_{L1}^*$：

+
$$ +k_{L1}^* = \frac{L1}{2 \cdot b_0 \cdot (M+N) \cdot dtype} +$$
+

然后取 $k_{L1} = \min(k_{L1}^*,\; K,\; 512B/dtype)$——不超过 K（K 截断），也不超过 dValue 推荐值 512B。

+

**Step 4：$b_{L1}$ 最大化**

+
$$ +b_{L1} = \min\Big(\frac{L1}{2 \cdot k_{L1} \cdot (M+N) \cdot dtype},\; b_{core}\Big) +$$
+

若 $k_{L1}^* > 512B/dtype$，$k_{L1}$ 被 512B 截断，省出的 L1 空间可容纳更多 batch（$b_{L1} > b_0$），提升 batch 间流水深度。

+
+

四、MergeBatch vs IterBatch 分界分析

+

4.1 核心差异：GM→L1 搬移粒度

+

从 kernel 侧源码可直接观察：

+ +

每次 GM→L1 DMA 搬移有固定开销 $T_{cmd}$（描述符配置 + 地址生成 + 突发启动），与搬移数据量无关。MergeBatch 把 $b_0$ 次搬移合并为 1 次，$T_{cmd}$ 节省 $b_0$ 倍。

+

4.2 分情形分析

+

K 截断情形（$k_{L1} = K$，整个 K 装入 L1 一块）：

+

IterBatch 每 batch 一次 GM→L1 搬移；MergeBatch 每合并 batch 一次（覆盖 $b_0$ 个 batch），搬移次数少 $b_0$ 倍：

+
$$ +\Delta_K = \underbrace{(b_0-1)(T_{comp} + T_{write})}_{\text{drain 惩罚}} - \underbrace{b_{core}\Big(1-\frac{1}{b_0}\Big) T_{cmd}}_{\text{搬移命令节省}} +$$
+

L1 绑定情形（$k_{L1} < K$，K 需分块）：

+

MergeBatch 合并后 tile 更大 → $k_{L1}^m = k_{L1}/b_0$ → $n_K^m = b_0 \cdot n_K$。搬移次数相同（$b_{core} \cdot n_K$），每次搬移量也相同——MergeBatch 无搬移优势，只剩 drain 惩罚：

+
$$ +\Delta_L = (b_0-1)(T_{comp} + T_{write}) > 0 +$$
+

L1 绑定情形 MergeBatch 恒劣于 IterBatch。

+

4.3 统一分界条件

+
$$ +\text{MergeBatch 最优} \iff k_{L1} = K \;\land\; b_{core} > \frac{b_0 \cdot (T_{comp} + T_{write})}{T_{cmd}} +$$
+

即 MergeBatch 仅在 K 截断（小 M/N 使 $L1/(2(M+N) \cdot dtype) \ge K$）且 $b_{core}$ 足够大时才优于 IterBatch。

+ + + + +
维度IterBatchMergeBatch差异
稳态搬移吞吐相同相同总搬移量相同
GM→L1 搬移命令数$b_{core}$ 次$b_{core}/b_0$ 次**MergeBatch 少 $b_0$ 倍** ← 核心优势
drain 暴露$T_{comp} + T_{write}$$b_0(T_{comp} + T_{write})$IterBatch 少 $b_0$ 倍 ← 核心劣势
L0C 利用率低高访存 Bound 下不影响时延
+

4.4 $T_{cmd}$ 的物理成因

+

每次 GM→L1 DMA 搬移的固定开销包括：Nd2Nz 描述符配置（ndNum/nValue/dValue/srcStride 等 7 个字段写入 DMA 寄存器）、地址生成与突发启动、与 L1 buffer 的同步握手（SetFlag<MTE2_MTE1> / WaitFlag<MTE1_MTE2>）。量级估计为数十 ns，精确值需实测标定。

+
+

五、与源码实现的对比

+

5.1 MergeBatch 源码（batch_matmul_v3_mergebatch_basicapi_tiling.cpp）

+

IsCapable 条件：

+
// 源码：https://gitee.com/ascend/cann-ops-nn
+if (batchC < MIN_BATCH_L0 * aicNum) return false;  // B < 128，即 b_core < 4
+if (alignK < 64 || M > N) return false;             // K ≥ 64，M ≤ N
+if (L0 buffer check with b0=4) return false;        // L0C 容量
+

对比分析：

+ + + + + + + +
维度理论源码差异
合并数 b₀min(L0C 上限, 算存比上限, b_core)MIN_BATCH_L0 = 4（固定），实际由多项式动态求解源码 b₀=4 是硬编码下限，实际值由 L0C 容量动态计算
b_core 下限≥ 2b₀ = 4≥ 4（batchC ≥ 128）一致
L0C 约束2(b₀M)(b₀N)·4B ≤ L0CtempAlignM × tempAlignN × 4B × 2 ≤ L0C一致
搬移量约束b_core(MK+KN)·dtype ≥ 480KB无源码缺少
tile 大小约束max(MK,KN)·dtype ≥ 16KB无源码缺少
算存比约束2MN/(M+N) < R₁₆/b₀无源码缺少
额外约束无K ≥ 64，M ≤ N源码独有
+

结论：源码的 MergeBatch 进入条件偏宽——缺少搬移量、tile 大小、算存比三条约束。可能导致不应进入的 case 被误捕获（如计算 Bound 的 case 进入 MergeBatch 后冗余计算成为瓶颈）。

+

5.2 IterBatch 源码（batch_matmul_v3_iterbatch_basicapi_tiling.cpp）

+

IsCapable 条件：

+
// 源码：https://gitee.com/ascend/cann-ops-nn
+if (batchC <= aicNum) return false;  // B ≤ 32 不进 IterBatch
+if ((alignM*alignK + alignK*alignN)*dtype*2 > L1) return false;  // L1 双缓冲
+if (!l0CanLoadBatch_ && balanceRate < 0.8) return false;  // 负载均衡
+

对比分析：

+ + + +
维度理论源码差异
L1 形态四种（a/b/c/d）只覆盖形态 b源码缺 a/c/d
B 下限b_core ≥ 1B > 32（b_core ≥ 2）源码排除了 b_core=1 的形态 a
负载均衡B mod C ≥ minCoreNumbalanceRate ≥ 0.8实现方式不同，目的一致
+

结论：源码的 IterBatch 只覆盖形态 b（双 batch 乒乓），且要求 B > C。形态 a/c/d 的 case 由 ASW/AL1/BL1 分支承接。

+

5.3 综合评价

+

理论分析的价值在于：

+
    +
  1. 分界条件——源码无显式 MergeBatch vs IterBatch 分界，理论给出了 $k_{L1} = K \land b_{core} > b_0(T_{comp}+T_{write})/T_{cmd}$ 的闭式条件
    2. +
  2. L1 绑定情形——理论证明 MergeBatch 在 L1 绑定时恒劣于 IterBatch，源码未区分
    3. +
  3. T_cmd 的物理意义——GM→L1 DMA 命令固定开销，是 MergeBatch 优势的本质来源
    4. +
+

源码实现的价值在于：

+
    +
  1. 工程完备性——负载均衡、格式检查、bias 处理等
    2. +
  2. cubeBound 模型——经实测调优的 baseM/baseN 寻优
    3. +
  3. L2 Cache 管理——100MB 阈值 + transConflict 控制
    4. +
+
+

参考文献

+
    +
  1. [昇腾 950 NPU 架构白皮书](https://public-download.obs.cn-east-2.myhuaweicloud.com/ascend/%E6%98%87%E8%85%BE950%20NPU%E6%9E%B6%E6%9E%84%E7%99%BD%E7%9A%AE%E4%B9%A6.pdf)，华为技术有限公司，2026
    2. +
  2. [CANN AscendC 算子开发——Matmul 高阶 API 使能 UnitFlag](https://www.hiascend.com/document/detail/zh/canncommercial/850/opdevg/Ascendcopdevg/atlas_ascendc_best_practices_10_10003.html)，CANN 8.5.0
    3. +
  3. [cann-ops-nn 源码仓](https://gitee.com/ascend/cann-ops-nn)，matmul/batch_mat_mul_v3 目录
    4. +
+
+ + \ No newline at end of file