@cannbot-plugin/cannbot-harness 0.0.0-stage → 0.1.5

package/assets/ops-direct-invoke/skills/ascendc-performance-best-practices/references/matmul/scale_coalescing_design.md

@@ -0,0 +1,282 @@
+# matmul 小数据块合并载入（Scale / 小矩阵 Access Coalescing）优化设计
+
+## 1. 优化目标
+
+解决 matmul 族（尤其是 **MXFP4 / MXFP8 量化变体**）在 L1 搬入路径上 **单次 MTE2 搬运量过小（< 20 KB）** 导致的 **访存带宽利用不足** 问题。将 K 方向上被 `baseK`/`kL1` 切碎的若干片 Scale（或其他小侧随路数据）**合并成一次大搬运**，使 MTE2 的**带宽利用率**从典型的 50%–70% 拉回到 80%+ 的健康区间，同时削减等价指令条数与 MTE2 段气泡。
+
+适用面比"仅 Scale"更广：任何在 kernel 内被反复从 GM 搬进 L1、单次数据量显著小于 20 KB、且在 K 方向上"内容相邻 + 读模式一致"的侧输入（Scale、Bias、小 LUT、少量常量张量等）都可以套同一思路（本文档统一称"**小数据块合并载入**"，英文 *small-block MTE2 coalescing* 或 *access coalescing*）。
+
+> **20 KB 物理根因**：昇腾 AI Core 的 MTE2 发射单元对 "发起一次 GM→L1 搬运" 有固定头开销（地址建立、Burst 描述符、DMA 通道配置）。单次搬运量达到约 20 KB 左右时，头开销被数据时间摊薄到 < 5%；若单次低于 20 KB，头开销占比显著拉高，表现为 *cycles/byte* 远高于 HBM 理论峰值。
+
+---
+
+## 2. 架构概览
+
+### 2.1 未优化路径（每 `kL1` 轮都搬一块 scale）
+
+```
+for iter0 in range(kL1Iter):                    # K 轴外层
+    MTE2: GM → L1  A[kL1]             (baseM·kL1 bytes)     ~ 32 KB  ✔ 够大
+    MTE2: GM → L1  B[kL1]             (kL1·baseN bytes)     ~ 32 KB  ✔ 够大
+    MTE2: GM → L1  scaleA[baseK]      (baseM·kL1/32 bytes)  ~  2 KB  ✘ 太小
+    MTE2: GM → L1  scaleB[baseK]      (kL1/32·baseN bytes)  ~  2 KB  ✘ 太小
+    MTE1: L1 → L0 + CUBE
+```
+
+每个 `kL1` 迭代都发一次小 scale 搬运，`kL1Iter = K / kL1` 轮下总计发出 `2 × kL1Iter` 次小搬运。MTE2 段有大量短指令 + 指令间小气泡，带宽利用率拉低。
+
+### 2.2 优化路径（合并 `scaleKL1Ratio` 个 kL1 的 scale 一次性载入）
+
+```
+scaleKL1 = scaleKL1Ratio × kL1        # 例如 16 × BASE_K，或直接置为 K
+for iter0 in range(kL1Iter):
+    if iter0 % scaleKL1Ratio == 0:             # 每 scaleKL1Ratio 轮才发一次 scale
+        MTE2: GM → L1 scaleA[scaleKL1]   (baseM·scaleKL1/32 bytes)  ~ 32 KB  ✔ 够大
+        MTE2: GM → L1 scaleB[scaleKL1]   (scaleKL1/32·baseN bytes)  ~ 32 KB  ✔ 够大
+    MTE2: GM → L1 A[kL1]
+    MTE2: GM → L1 B[kL1]
+    MTE1: L1 → L0 + CUBE
+    # L0 侧按 scaleKL1IterOffset = (iter0 % scaleKL1Ratio) × kL1 从同一块 scaleL1 里取
+```
+
+极端情形（`scaleKL1 = K` 且 L1 放得下）下整段 kernel 只在 `iter0=0` 发一次 scale，后续所有迭代只有 A/B 的大 MTE2。等价地把原来 `2 × kL1Iter` 次小 MTE2 压缩成 `2 × kL1Iter / scaleKL1Ratio` 次大 MTE2；单位数据量不变，但单次负载翻倍到 20 KB 以上。
+
+### 2.3 事件同步模型
+
+在 pingpong 事件模型（`pingpong_design.md` §2.3）基础上新增一对 "scale 独立 pingpong" 事件，与 A/B 的 L1 pingpong **事件 ID 分离**：
+
+| 事件类型 | 含义 | 新增用途（scale 合并） |
+|---------|------|------------------|
+| `MTE1_MTE2(SCALE_BUFFER_FLAG_0)` | scaleA/B 在 L1 双缓冲 ping 释放 | 当前 L0 已消费完前一份 merged scale，准许 MTE2 覆写 ping |
+| `MTE1_MTE2(SCALE_BUFFER_FLAG_1)` | scaleA/B 在 L1 双缓冲 pong 释放 | 同上，pong |
+| `MTE2_MTE1`（仍复用 A/B 轨） | A/B 搬入就绪 → L1→L0 | 合并后不变 |
+
+关键点：**scale 的 pingpong 周期拉长到 `scaleKL1Ratio × kL1Iter` 而非 `kL1Iter`**。只要 `SCALE_BUFFER_NUM = 2`（ping/pong）就足够覆盖所有稳态轮次。
+
+---
+
+## 3. 关键参数配置
+
+```cpp
+constexpr uint32_t BASE_M              = 128;    // 典型量化 matmul baseM
+constexpr uint32_t BASE_N              = 128;
+constexpr uint32_t BASE_K              = 512;
+constexpr uint32_t L1_BUFFER_NUM       = 2;      // A/B 的 K 覆盖倍数（沿用 pingpong）
+constexpr uint32_t PINGPONG_NUM        = 2;      // A/B 的 L1 pingpong
+constexpr uint32_t SCALE_L1_BUFFER_NUM = 16;     // *** 本优化核心 *** scale 相对 A/B 的 K 覆盖倍数
+constexpr uint32_t SCALE_BUFFER_NUM    = 2;      // scale 的 L1 pingpong 仍是 2
+
+// Host Tiling
+params.l1Params.kL1       = BASE_K * L1_BUFFER_NUM;            // A/B 的 kL1
+params.l1Params.scaleKL1  = BASE_K * SCALE_L1_BUFFER_NUM;      // scale 的 scaleKL1 = 16 × BASE_K
+params.l1Params.l1BufNum  = PINGPONG_NUM;
+// 要求：scaleKL1 是 kL1 的整数倍（scaleKL1Ratio_ = scaleKL1 / kL1 ≥ 2 整数）
+```
+
+### 3.1 `SCALE_L1_BUFFER_NUM` 的选取规则
+
+`scaleKL1` 过小则带宽没救回来；过大则 L1 放不下或把 A/B 的 pingpong 空间吃掉。按以下顺序搜索：
+
+1. **计算单次 scale 合并搬运量**：
+   $$ \text{Bytes}_{\text{scaleA}} = \text{baseM} \times \frac{\text{scaleKL1}}{32} \times |\text{dtype}_{\text{scale}}| $$
+   目标：`Bytes_scaleA ≥ 20 KB`（带宽拐点）。以 `baseM = 128, |dtype_scale| = 1 B` 为例：
+   - `scaleKL1 = 512`（即 `SCALE_L1_BUFFER_NUM = 1`）：2 KB ✘
+   - `scaleKL1 = 1024`（`=2`）：4 KB ✘
+   - `scaleKL1 = 5120`（`=10`）：20 KB ✔（**最低门槛**）
+   - `scaleKL1 = 8192`（`=16`）：32 KB ✔（**推荐**，兼容 K=8192 的整块覆盖）
+   - `scaleKL1 = K`（"一次装完"）：理想值；L1 容得下时首选
+
+2. **L1 预算校验**：
+   $$
+   \text{L1 used} = \underbrace{(\text{aL1OneBuffer}+\text{bL1OneBuffer}) \times L_1\text{BufferNum} \times \text{PINGPONG\_NUM}}_{\text{A/B 正常 pingpong}}
+   + \underbrace{(\text{scaleAL1OneBuffer}+\text{scaleBL1OneBuffer}) \times \text{SCALE\_BUFFER\_NUM}}_{\text{scale 合并后 pingpong}}
+   \le L1\text{Size} \ (524288\ B)
+   $$
+   `scaleXL1OneBuffer = baseX × CeilDiv(scaleKL1, MXFP_DIVISOR_SIZE_LOCAL) × MXFP_MULTI_BASE_SIZE_LOCAL`。溢出时回退 `SCALE_L1_BUFFER_NUM`（通常 16 → 8 → 4 → 2）直到成立。
+
+3. **`scaleKL1` 必须是 `kL1` 的整数倍**（`scaleKL1Ratio_ = scaleKL1 / kL1`）。否则 `iter0 % scaleKL1Ratio_ == 0` 的判定会丢 scale 对齐，精度出错。
+
+### 3.2 `scaleKL1Ratio_` 字段
+
+Device 侧新增私有状态：
+
+```cpp
+uint64_t scaleKL1Ratio_;   // = scaleKL1_ / kL1_
+
+// Init()
+scaleKL1Ratio_ = scaleKL1_ / kL1_;
+```
+
+用于两个关键判定：
+- **Scale 搬运触发**：`if (iter0 % scaleKL1Ratio_ == 0) { 发一次 scale MTE2; }`
+- **Scale L0 取数偏移**：`scaleKL1IterOffset = (iter0 % scaleKL1Ratio_) × kL1_`；L0 侧按该偏移从 merged scaleL1 中切对应片给 MMAD。
+
+### 3.3 L1 布局（与 pingpong 布局解耦）
+
+```
+L1 地址空间（L1_SIZE = 524 KB）:
+┌───────────────────────────────────────────────────────────────────────────┐
+│ A_ping │ A_pong │ B_ping │ B_pong │ scaleA_ping │ scaleA_pong │ scaleB_ping │ scaleB_pong │
+│ (kL1)  │ (kL1)  │ (kL1)  │ (kL1)  │ (scaleKL1)  │ (scaleKL1)  │ (scaleKL1)  │ (scaleKL1)  │
+└───────────────────────────────────────────────────────────────────────────┘
+       ↑                                       ↑
+   A/B 每 iter0 轮换                 scaleA/B 每 scaleKL1Ratio_ × iter0 轮换
+```
+
+- A/B 的 pingpong 周期仍然是 `kL1` 粒度（保留 pingpong 重叠 MTE2 / MTE1+CUBE）
+- scaleA/B 的 pingpong 周期被**拉长到** `scaleKL1Ratio_ × kL1`；L1 pingpong 同样是 2 份就够
+
+偏移公式（见 `block_mmad_mx_base.h::Init`）：
+
+```cpp
+l1BufferAOffset_[bufferId] = halfOffset + aL1OneBuffer_ * (bufferId >> 1);
+l1BufferBOffset_[bufferId] = halfOffset + aL1OneBuffer_ * (l1BufNum_ >> 1)
+                           + bL1OneBuffer_ * (bufferId >> 1);
+l1BufferScaleAOffset_[bufferId] = l1BufferBOffset_[bufferId] + bL1OneBuffer_ * (l1BufNum_ >> 1);
+l1BufferScaleBOffset_[bufferId] = l1BufferScaleAOffset_[bufferId] + scaleAL1OneBuffer_;
+```
+
+---
+
+## 4. 关键代码实施点
+
+本节给出从 pingpong（`kL1 = scaleKL1`）基线演进到 scale 合并载入需要改的**五处**：
+
+### 4.1 Host launcher：导出 `scaleKL1 = BASE_K × SCALE_L1_BUFFER_NUM`
+
+```cpp
+constexpr uint32_t SCALE_L1_BUFFER_NUM = 16;   // 新增
+params.l1Params.scaleKL1 = BASE_K * SCALE_L1_BUFFER_NUM;   // 原先 = BASE_K × L1_BUFFER_NUM
+```
+
+### 4.2 BlockMmad::Init：缓存 `scaleKL1Ratio_`
+
+```cpp
+scaleKL1Ratio_ = scaleKL1_ / kL1_;   // 新增私有成员
+// L1 偏移计算改为按 scaleKL1 而非 kL1 来算 scaleXL1OneBuffer
+scaleAL1OneBuffer_ = baseM_ * CeilDiv(scaleKL1_, MXFP_DIVISOR_SIZE_LOCAL) * MXFP_MULTI_BASE_SIZE_LOCAL;
+scaleBL1OneBuffer_ = baseN_ * CeilDiv(scaleKL1_, MXFP_DIVISOR_SIZE_LOCAL) * MXFP_MULTI_BASE_SIZE_LOCAL;
+```
+
+### 4.3 scale MTE2 搬运由"每轮"改为"每 ratio 轮"
+
+```cpp
+for (uint64_t iter0 = 0; iter0 < kL1Iter_; ++iter0) {
+    // ...
+    if (iter0 % scaleKL1Ratio_ == 0) {                 // 原先无此判定
+        uint64_t scaleKL1Offset = iter0 * kL1_;
+        uint64_t curScaleKL1 = scaleKL1_;
+        if (scaleKL1Offset + curScaleKL1 > k_) {       // 末段裁剪
+            curScaleKL1 = k_ - scaleKL1Offset;
+        }
+        // 发一次合并后的 scaleA MTE2
+        AscendC::Te::Copy(CopyScaleGM2L1, tensorScaleAL1Buf, gmBlockScaleA);
+        // 发一次合并后的 scaleB MTE2
+        AscendC::Te::Copy(CopyScaleGM2L1, tensorScaleBL1Buf, gmBlockScaleB);
+    }
+    // A/B 的 MTE2 每轮都发（不变）
+    // ...
+}
+```
+
+### 4.4 L0 取数按合并后的 scaleL1 加偏移
+
+`IterateL0()` 内部 scale → L0 拷贝的起点由 `(0, kL0Offset)` 改为 `(0, scaleKL1IterOffset + kL0Offset)`，其中：
+
+```cpp
+uint64_t scaleKL1IterOffset = (iter0 % scaleKL1Ratio_) * kL1_;
+
+AscendC::Te::Copy(
+    CopyL12L0MxScaleA, tensorScaleAL0, tensorBlockScaleAL1,
+    AscendC::Te::MakeCoord(0, scaleKL1IterOffset + kL0Offset));   // 关键偏移
+```
+
+B 侧同理（坐标维度反过来）。**漏加这个偏移会直接导致精度错误**（不同 K 段用同一份 scale 反量化）。
+
+### 4.5 Scale pingpong 释放条件
+
+`SetFlag<MTE1_MTE2>(SCALE_BUFFER_FLAG_*)` 不再每轮发，而是仅在"本 merged scaleL1 的所有 `scaleKL1Ratio_` 轮 L0 拷贝都完成后"发：
+
+```cpp
+AscendC::SetFlag<AscendC::HardEvent::MTE1_MTE2>(l1BufId);   // A/B 的每轮释放（不变）
+if ((iter0 + 1) % scaleKL1Ratio_ == 0 || iter0 == kL1Iter_ - 1) {
+    AscendC::SetFlag<AscendC::HardEvent::MTE1_MTE2>(SCALE_BUFFER_FLAG_0 + scaleL1BufId);
+    scaleLoopCnt_++;
+}
+```
+
+**漏掉"末轮强制释放"（`iter0 == kL1Iter_ - 1`）会导致 K 不是 `scaleKL1` 整数倍时 AIV 永远 Wait**。
+
+---
+
+## 5. 适用场景与适用性校验
+
+### 5.1 典型 Shape 特征（由策略专家判定）
+
+- **短 `baseK` 侧量化**：`baseM × baseK / 32 × |dtype_scale| < 20 KB`。最典型是 MXFP4 + `baseM=128, baseK=512` → scale 段 2 KB。
+- **K 向循环次数较多**：`kL1Iter = K / kL1 ≥ 4`。否则根本没有足够的重复次数让合并收益显现。
+- **L1 预算尚有余裕**：A/B pingpong 占完后剩余空间可容下 `SCALE_BUFFER_NUM × (scaleAL1OneBuffer + scaleBL1OneBuffer)`（以 `scaleKL1 = 16 × baseK` 计通常 < 65 KB，远小于 L1 余量）。
+
+### 5.2 不适用的情形（禁用条件）
+
+- `baseM × scaleKL1 / 32` 已经 ≥ 20 KB 但搬运仍不快：此时瓶颈在 B/B_scale 侧或 HBM 通道，合并 scale 救不动，需改查 HBM 带宽或改走 A-Full-Load。
+- 量化 group size 非 32 且使单份 scale 已经足够大：合并无收益。
+- L1 容不下 `SCALE_BUFFER_NUM × scaleXL1OneBuffer`：先回退 `SCALE_L1_BUFFER_NUM`（16→8→4→2），到 2 仍放不下说明 A/B pingpong 本身已经吃满 L1，此时本优化不可用。
+- StreamK 分支：StreamK 已经把 K 切成 `kCnt` 段分给不同核，每段的 `skSingleCoreK` 通常已经 ≥ 2048，scale 段天然不再小；且 StreamK 的 `l1BufferNum` 固定为 2、`scaleKL1` 受 workspace 拓扑约束，**不与本优化叠加**。
+
+### 5.3 与其他优化的关系
+
+| 叠加对象 | 是否兼容 | 说明 |
+|---------|----------|------|
+| pingpong 双缓冲（`pingpong_design.md`） | ✅ **强兼容** | scale 合并只改 scale 那对 buffer 的 pingpong 周期，A/B pingpong 不动 |
+| SWAT 负载均衡（`swat_design.md`） | ✅ 兼容 | SWAT 改的是 GetTileIdx 调度，不动 K 方向的 scaleKL1 |
+| StreamK（`streamk_design.md`） | ❌ **互斥** | StreamK 强制 `l1BufferNum=2`、切 K 分段后 scale 段已经够大 |
+| A-Full-Load（`modeling_reference.md` §2.2）| ✅ 兼容 | A 全载只影响 A 的 L1 布局，scale 段仍然在 K 方向被重复搬运，合并同样受益 |
+| L1 bank 冲突对半布局（step 5） | ✅ 兼容 | 本优化在同一对半布局下只改 scale 的 buffer 数量与偏移 |
+
+---
+
+## 6. 常见问题与解决方案
+
+| 问题 | 现象 | 解决 |
+|------|------|------|
+| **精度错误（最常见）** | 输出 C 局部明显偏离 golden；尾部 K 段错得更严重 | 检查 `scaleKL1IterOffset = (iter0 % scaleKL1Ratio_) × kL1_` 是否在 L0 拷贝的 `MakeCoord` 里加上；尾轮 `curScaleKL1 = k_ - scaleKL1Offset` 是否正确裁剪 |
+| **AIV/AIC hang** | K 不是 `scaleKL1` 整数倍时卡死 | 检查末轮 flag 释放：`if ((iter0+1) % scaleKL1Ratio_ == 0 || iter0 == kL1Iter_ - 1)` 的 `||` 必须保留 |
+| **L1 溢出** | 编译期或运行期报 L1 overflow | 回退 `SCALE_L1_BUFFER_NUM`（16→8→4→2）；或先校验 §3.1 的 L1 预算公式 |
+| **合并后性能反而劣化** | MTE2 时间下降有限甚至上升 | 检查是否 MTE2 总量本来就够大（A/B 已 32 KB+）；合并只对 <20KB 的小块有效 |
+| **`scaleKL1 % kL1 ≠ 0`** | `iter0 % scaleKL1Ratio_` 永远非 0 或错位 | 强制 `scaleKL1 = ratio × kL1`，Host Tiling 在搜索 `SCALE_L1_BUFFER_NUM` 时保证整除 |
+
+---
+
+## 7. 预期收益
+
+| 指标 | 优化前（SCALE_L1_BUFFER_NUM=2）| 优化后（SCALE_L1_BUFFER_NUM=16）| 变化 |
+|------|------|------|------|
+| 单次 scale MTE2 搬运量 | 1024 B | 8192–32768 B | +10× |
+| scale MTE2 次数 | `2 × kL1Iter` | `2 × kL1Iter / 16` | ÷16 |
+| MTE2 段时间（`[128, 8192, 4096]`）| 34.4 μs | 31.27 μs | **−9%** |
+| Task 总时间 | 39.53 μs | 36.76 μs | **−7%** |
+| MTE2 带宽利用率 | ~50–60% | ~80%+ | **+25 pp** |
+
+典型收益区间：**5%–15% 端到端 Task 时间缩短**，受 K 长度、`baseK`/`baseM`、Scale dtype 大小影响。K 越长、`baseK` 越小、scale 在 L1 的占比越低时收益越大。
+
+---
+
+## 8. 泛化：不止 Scale —— 小数据块合并载入的一般化
+
+以下场景可套同一模板（`合并 ratio × 原始覆盖`）：
+
+| 场景 | 小数据来源 | 合并后字段 | 预期收益 |
+|------|------|------|------|
+| MXFP4/MXFP8 量化 matmul 的 scaleA/scaleB | group_size=32 下，单 baseK 段 scale 只有 2 KB | `scaleKL1 = SCALE_L1_BUFFER_NUM × kL1` | 本文主体场景 |
+| Matmul with bias（小 bias 向量）| bias 大小 `N` 或 `M`，单次切片可能 < 4 KB | 一次性全载 bias 到 L1 | 1–5% 次要 |
+| 分组量化 GroupMatmul / MoE 专家权重的小 LUT | 每组的 routing 索引表 < 1 KB | 一次性载入 expert-routing 表 | 若 LUT 访问频繁，2–5% |
+| RNN / Attention 的 mask / pos_embed 小张量 | 切片后单次 < 8 KB | 合并到一次 MTE2 | 视 K 循环次数 |
+| 动态 shape 算子的 "尾片" 搬运 | 尾片普遍短 | Host 端融合尾片，kernel 端一次搬完 | 5–10%（尾部分带宽型场景）|
+
+共用前提：
+1. 小块数据在 K 向（或主循环轴）上**内容相邻、模式一致**（否则合并不能复用）；
+2. L1 / UB 有余量；
+3. 小块数据是**只读**或**累加型**（不存在写竞争）。
+
+在"是否启用合并"门禁校验阶段，**只需验证第 2 与第 3 条 + 单次原始搬运量 < 20 KB**；第 1 条通常由算子结构自然保证。

package/assets/ops-direct-invoke/skills/ascendc-performance-best-practices/references/matmul/small_m_wide_n_pipeline_design.md

@@ -0,0 +1,137 @@
+# 小 M、宽 N Matmul：从载入量出发选择分块与流水
+
+## 1. 问题：左矩阵 A 的多次重复搬运加重访存压力
+
+本方法面向小 M、长 K／宽 N，且 A 重复搬运加重访存压力的 Matmul，也适用于 BatchMatmul 和 GMM。
+沿 N 切分输出时，各任务使用不同的 B 列块，却需要读取相同的 A。若这些读取没有被有效复用，Cube 就可能等数据。
+优化思路是：让一次载入的 A 服务更多输出列，再通过容量规划和流水衔接，避免把等待转移到权重准备阶段。
+本方法主要面向 memory bound 的场景。
+
+
+下文用 `M、K、N` 表示完整矩阵维度：A 为 M×K，B 为 K×N；`baseM、baseN` 表示一个 L0C 输出块的行数、列数。
+`K_L1` 表示一次准备到 L1 的 K 深度，`K_L0` 表示一次送入 L0 计算的 K 深度，两者不必相等。
+
+## 2. 理论模型分析性能瓶颈
+
+### 2.1 载入量分析
+
+假设每个输出块独立加载所需的 A/B，遍历完整 K，且不同输出块之间没有额外的片上驻留复用。
+记 `sA、sB` 为 GM 中每个元素的字节数；暂不计对齐填充、scale、bias 和输出，则一个矩阵的逻辑载入量为：
+
+$$
+\begin{aligned}
+\mathrm{qM} &= \left\lceil \frac{M}{\mathrm{baseM}} \right\rceil, \qquad
+\mathrm{qN} = \left\lceil \frac{N}{\mathrm{baseN}} \right\rceil \\
+D_A &\approx M \times K \times \mathrm{sA} \times \mathrm{qN} \\
+D_B &\approx K \times N \times \mathrm{sB} \times \mathrm{qM} \\
+D &= D_A + D_B
+\end{aligned}
+$$
+
+直观上，A 被 N 方向的任务重复读取，B 被 M 方向的任务重复读取。
+在小 M、长 K／宽 N 的访存受限场景下，A 的重复载入会占用搬运带宽，却不增加有效数据量；当它拉长执行时间时，按有效数据量计算的 MBU 就会被拖累。因此，即使搬运通路已经很忙，减少重复载入仍有机会提高有效带宽利用率。
+
+### 2.2 缩 baseM、扩 baseN 的优化思路
+
+基于上述分析，可以尝试减小 baseM、增大 baseN，以减少 A 的重复载入次数。
+当调整前后均满足 $M \le \mathrm{baseM}$ 时，qM 始终为 1。此时缩小 baseM 不会增加 B 的载入次数，却可能腾出容量扩大 baseN。
+扩大 baseN 后，qN 减少，同一份 A 可服务更多输出列，这是调整分块的直接依据。
+反过来，如果缩小 baseM 使 qM 增加，就会多搬 B，需要比较 A 的节省与 B 的新增开销。
+
+在 $M \le \mathrm{baseM}$ 且 N 能被 baseN 整除时，令有效计算量 $F=2MKN$，可得到：
+
+$$
+\frac{D}{F} \approx \frac{\mathrm{sA}}{2 \times \mathrm{baseN}} + \frac{\mathrm{sB}}{2 \times M}
+$$
+
+维持计算吞吐 $P_{\mathrm{eff}}$ 所需的带宽：
+
+$$
+\mathrm{BW}_{\mathrm{req}} \approx P_{\mathrm{eff}} \times \frac{D}{F}
+$$
+
+第一项随 baseN 增大而下降，第二项不变。因此，扩 baseN 的收益会递减；M 很小时，也可能主要受 B 的必需载入量限制。
+还可以考虑让 A 在 L1 驻留并跨多个输出块复用，或调整遍历顺序改善缓存复用；这些方法同样需要付出容量或并行度代价。
+
+### 2.3 注意前提条件：memory bound or compute bound？
+
+可用同一统计范围内的有效带宽和有效计算吞吐估算：$T_{\mathrm{load}}\approx D/\mathrm{BW}_{\mathrm{eff}}$，$T_{\mathrm{cube}}\approx F/P_{\mathrm{eff}}$。
+若 T_load 明显大于 T_cube，此时模型表明很可能是 memory bound，减少载入量才有较明确的方向性收益；若 Cube 已持续饱和，应优先找计算侧问题。
+
+
+## 3. 加宽 baseN 需要考虑的约束
+
+### 3.1 满足 L0 容量约束
+
+FP32 累加、单槽时，L0C 占用约为 $\mathrm{baseM}\times\mathrm{baseN}\times 4$ 字节。
+256×256、128×512 均需要 256 KiB，但等面积不代表它们的整个数据通路都可行。
+L0A/L0B 还需满足 $\text{槽数}\times\mathrm{baseM}\times K_{\mathrm{L0}}\times\mathrm{sA}_{\mathrm{L0}}$、$\text{槽数}\times\mathrm{baseN}\times K_{\mathrm{L0}}\times\mathrm{sB}_{\mathrm{L0}}$ 各自不超过容量，并计入对齐要求。
+注意使用所在层级的元素宽度：FP4 在 GM 中占半字节，转换后的 L0B 权重可能占一字节。
+
+例如，64 KiB L0B 存两槽 8 位权重时，baseN=512、K_L0=64 恰好放满。
+继续加宽 baseN 时，若仍保留双槽，就需要减小 K_L0，并检查所用矩阵指令的 K 对齐和最小粒度是否允许。
+也可以评估单槽或改变装载方式，但会改变流水重叠能力，不能按“同样的面积”推断性能。
+
+### 3.2 L1、UB 和 Vector 尽量一起算
+
+L1 中的 B 占用近似为 $\text{槽数}\times K_{\mathrm{L1}}\times\mathrm{baseN}\times\mathrm{sB}_{\mathrm{L1}}$，还需给 A、ScaleA、ScaleB、bias 及对齐预留空间。
+baseN 加宽可能挤压 K_L1，导致外层分段和同步次数增加；这可能抵消减少 A 搬运的收益。
+scale 应按实际量化分组、驻留窗口和排布计算；MX 的 A 即使为 FP8，也仍需要 ScaleA。
+UB 需分别核算压缩输入、转换输出和临时区；两个 Vector 的 UB 不能当作一块共享空间使用。
+如果整段转换放不下，可以分小块转换并写入 L1，但要检查新增的 Vector 循环和交接成本。
+
+### 3.3 避免牺牲多核的并行度
+
+每个矩阵的输出任务数约为 $\mathrm{qM}\times\mathrm{qN}$。baseN 越宽，任务越少，需要结合执行核数和尾轮分配检查是否有核空闲。
+例如 M=64、N=6144、baseN=512 时只有 12 个输出任务，单个 Matmul 未必适合在 32 个核上使用该方案。
+BatchMatmul/GMM 可以有更多矩阵任务，但仍要检查实际调度能否利用这些任务，不能只看任务总数。
+
+## 4. 实验方法：模型给出搜索范围，根据测量选出最优策略
+
+可按以下顺序开展实验，每一步都保留可回退的对照。
+
+| 步骤 | 建议实验 | 要回答的问题 |
+|---|---|---|
+| 1. 建立基线 | 固定输入、精度和计时范围，记录任务数及主要流水等待 | 是否确实存在供数或准备阶段的瓶颈？ |
+| 2. 筛选分块 | 例如比较 256×256、128×512 等模板，也允许不占满 L0C 的块；先排除容量、指令或并行度不合适的组合 | A 节省多少，B 是否增加，约束代价多大？ |
+| 3. 只改分块 | 保持其余策略尽量一致，记录为满足容量而必须做的附带改动 | 分块本身及其必要配套是否有效？ |
+| 4. 联合调流水 | 对可行分块尝试 K_L1=128/256/512 等合法深度，分别比较单槽、双槽与异步预取 | 更少的交接能否抵消更大的准备开销？ |
+| 5. 评估访问顺序 | 有并发热点或长尾迹象时，再测保持任务集合不变的编号重映射 | 工作量相同，访问时序能否改善耗时？ |
+| 6. 确认结果 | 精度验证、交错重复 A/B，再覆盖相邻 M、尾块和不同组分布 | 收益是否稳定，适用范围在哪里？ |
+
+增大 K_L1 减少的是 $\left\lceil K/K_{\mathrm{L1}} \right\rceil$ 次外层准备与交接，不会减少总 B 字节数和总乘加量。
+双槽流水让“搬下一段”和“转换当前段、Cube 消费已就绪段”尽量重叠；K_L0 可保持不变，将一个 L1 段分多次计算。
+UB 槽须等 Vector 读完才能覆盖，L1 槽须等 Cube 侧读完才能覆盖；尾段和 scale 窗口边界需单独处理同步。
+若 Vector 已是瓶颈，更深的分段不一定有效，应继续检查转换指令、布局和小块粒度，而不是盲目加大缓冲。
+每轮记录分块、K 深度、槽数、实际布局及耗时；有预排布或其他预处理时，同时说明其成本和输入复用次数。
+
+## 5. 案例：用 M=64 的 GMM 验证上述思路
+
+以下是一个实验案例，可迁移的是载入量分析、约束筛选和实验选型方法。
+平台为 950PR；G=24，每组 M=64、K=7168、N=6144。输入为 MX FP8×FP4，量化分组大小 32，保留 BF16 bias，输出 BF16。
+按第 2 节模型，sA=1、sB=0.5，各方案的 qM 均为 1，每组的逻辑载入量如下（不含 scale 等；1 MiB=2²⁰ 字节）：
+
+| baseM×baseN | A 载入次数 | A 载入量 | B 载入量 | 合计 |
+|---|---:|---:|---:|---:|
+| 256×256 | 24 | 10.5 MiB | 21 MiB | 31.5 MiB |
+| 128×512 | 12 | 5.25 MiB | 21 MiB | 26.25 MiB |
+
+128×512 的 A 载入量减半，A+B 总量减少约 16.7%。
+阶段实验中，仅调整分块及必要配套，耗时由 221.549 降至 214.642 μs，降低约 3.118%，说明载入量的收益未完全转化为时间收益。
+在此基础上，再进行以下配套优化：
+
+- **加深 L1 权重段**：将 K_L1 从 128 增至 256，完整 K=7168 对应的外层分段数由 56 减为 28，减少权重准备与交接次数。K_L0 仍为 64，每个 L1 段分四次送入 Cube，计算量不变。
+- **配套双槽异步流水**：Vector 处理当前段时，提前将下一段压缩权重搬入另一个 UB 输入槽；L1 也采用双槽，尽量让权重准备与 Cube 计算重叠。各槽在消费者读完后才允许覆盖，减少等待且保证数据依赖正确。
+- **重规划 L1 和 scale 缓冲**：根据加宽后的 baseN 和加深后的 K_L1，重新计算权重、scale 等区域的容量与双槽偏移。ScaleA 按实际 M=64 所需空间分配，避免按较大的 baseM 预留空间，为权重流水腾出容量。
+- **调整任务编号映射**：保持任务集合及 Cube/Vector 配对不变，以一一对应的方式重新分配执行块与逻辑任务编号，改变并发访问次序。该改动不减少搬运量，收益通过对照测试确认。
+
+上述改动组合后的完整实现结果如下：
+
+| 实现 | 中位耗时（μs） | MBU | MFU |
+|---|---:|---:|---:|
+| 优化前：物理 256×256 | 221.599 | 67.520% | 71.469% |
+| 改进后：物理 128×512 + 配套流水与任务重映射 | 195.101 | 76.809% | 81.301% |
+
+完整实现耗时降低 **11.958%**，加速比 **1.1358×**；这是包括调整分块策略在内的一系列配套优化的结果。
+
+**迁移该案例时，可以先算分块改变了哪些载入次数，再检查容量、指令与并行度，最后用分阶段实验解决模型无法准确估计的缓存和流水问题。**