Commit Graph

8 Commits

Author SHA1 Message Date
8d42d958e4 Fix #38: 补全昇腾950系列硬件规格 (新增 Ascend950DT 等 4 个 SKU), 默认加载不变
- 数据源: 昇腾950_NPU架构白皮书 表3-1 (系列 SKU) / 表4-2 (Memory 层次)
- 新增 hardware/ascend950dt.py: ASCEND950DT (36AIC/72AIV, HBM 4TB/s 144GB,
  L2 128MB 主bin) + ASCEND950DT_C32 + ASCEND950DT_C28
- ascend950pr.py: 新增 ASCEND950PR_C28 (28核, 1.4TB/s, L2 112MB) 与
  gm_capacity_gb 信息字段; 注明 cube_peak_tflops 口径 (= 白皮书
  "Cube+Vector 总算力" 行, 与 Cube 单行 432 的 12.5% 偏差待用户裁决)
- __init__.py: SPECS 注册表 + get_spec(name), 默认仍为 ASCEND950PR,
  现有 import 与调用点零改动
- 共架构交叉验证: 单核 Cube 13.5T (432/32=486/36), Vector fp32
  27T/64核≈30T/72核 -> 128lane@1.65GHz; 表4-2 L1/L0/UB 各档一致
- docs/01_软件架构 + README 硬件层说明更新
- tests: TestIssue38 六例 (默认不变/注册表/DT派生量/AIV白皮书验证/DT路由
  冒烟/未知KeyError); 87/87 通过; examples 44例 0 diff;
  压力回归 10000 例干净, 分支分布与上轮逐数一致
2026-09-09 10:33:22 +08:00
b0b48b9073 Fix #36: MergeBatch 合并搬移效率收益建模 (move_eff) + t_cmd_ns 置 0
用户澄清: MergeBatch vs IterBatch 的本质区别不只是 DMA 命令数 —— 合并 b0 个
batch 的左/右矩阵一起搬入 L1, 使单块 tile = nValue*dValue*dt 放大 b0 倍 (堆叠
方向视转置: A ND 非转置沿 M(nValue), B ND 非转置沿 N(dValue)), 搬移效率更高,
即便 T_cmd=0 也有效益。

- models.move_eff: 单命令搬移效率 eff = min(1, tile/min_TileSize) (16KB 饱和,
  与进入条件4效率下限语义同源); gm_move_time 按 A/B 两侧字节加权
  t = (V_A/eff_A + V_B/eff_B)/BW_gm; 只影响时间列, GM 字节量仍 = V_in
- IterBatch: l1_form 补驻留侧返回; move_tiles 分侧口径 (a/b 双侧整K, c 驻留侧
  整K+对侧k_l1, d 双侧k_l1), evaluate 接入效率加权
- MergeBatch: 合并 tile 放大 b0 倍接入效率加权; beats_iterbatch 净收益 =
  命令节省(cmds差×T_cmd) + 效率节省(t_data差) − drain惩罚, K截断且效率打平且
  T_cmd>0 时严格退化为 v1.1 §4.5 闭式; 退役 T_cmd<=0 策略特判
- router: 退役 "T_cmd<=0 策略优先 MergeBatch" 覆盖, 时延模型统一终审
- hardware: t_cmd_ns 50 -> 0 (未标定按 0; 合并收益不再依赖 T_cmd 估计值)
- 作用域: 仅切B 两分支接入 (逐命令 tile 小、效率差显著); ASW/StreamK 单命令
  tile 通常已饱和, 极端小 tile 走 issue#34 效率降级标注通道
- 用户 case 家族 B=128,M=1~16,N=128,K=512: m=1~8 -> MergeBatch (效率节省
  ~0.61us > drain), m=16 -> IterBatch (iter A tile 恰达 16KB 饱和, 效率打平,
  drain 决定); 分界与时延全家族一致
- demo: merge_demo_k_trunc 形状 (2048,32,32,256)->(2048,16,64,128) (原形状
  两侧 tile 均已 16KB 饱和, t_cmd=0 下无收益转 IterBatch; 新形状 iter A tile
  4KB eff=0.25 vs 合并 16KB eff=1.0, 保持 MergeBatch 胜出演示且仍 K截断)
- 测试: 74/74 (新增 TestIssue36 5 例: 效率曲线/字节不变/效率差胜出/家族;
  TestArbitration/TestZeroCmdHandling 按 t_cmd=0+效率语义重写; TestIssue35
  家族期望更新)
- 文档: 01_MergeBatch §4/§5 效率模型+泛化净收益; 02_IterBatch 口径注;
  00_总纲胜出条件; 01_软件架构 T_cmd 标定说明; 05 时间列效率口径注; README 要点
- 验证: examples 重生成可复现 0 diff; 压力 10000 例 0 崩溃/0 NaN/0 违规/
  0 GM<V_in, 七分支覆盖 (MergeBatch 386 例)
2026-09-07 21:09:49 +08:00
b9e07edc1d Fix #27-#30: dtype感知算力(Cube/AIV速率表) / GM首读下限与整芯片字节列口径+设计文档 / Fixpipe输出落点R4(整case驻留L2否则直写GM) / MergeBatch Cube公式复核注释
- docs/05_L2驻留GM读写与dtype算力口径_设计分析.md: R1-R6公理、S_A/S_B/S_C场景、输出落点R4、dtype速率表(白皮书出处+待标定假设)、逐分支GM/L2归属表 (issue#29/#30 先文档后代码)
- hardware: CUBE_DTYPE_FACTOR(f16/bf16=1, fp8=2x, fp4=4x, fp32=1/2假设) + AIV_DTYPE_FACTOR + q_cube/aiv_elem_rate (issue#28)
- 全分支 t_mmad/t_comp/drain/尾轮主导项/θ_c/R16 语义按输入dtype取算力; 混精度取慢侧; StreamK归约保持fp32(AIV fp32部分和)
- Fixpipe输出落点R4: to_l2 <=> V_in+V_out(+workspace)<=L2; 否则直写GM计入共享总线; ASW场景改S_A整case全驻留(原单batch驻留判定漏计整case输出累积逐出)
- 字节列统一整芯片口径(gm/l2/fix/cube_flops), dma_cmd_count注明单核; GM>=V_in不变量入测试; MergeBatch每步flops=2(b0M)(b0N)K公式注释显式化(#27复核与CSV一致无数值改动)
- tests 39->49 全过; 双压力seed7/6000+seed2024/4000: 0违规/0占位/0NaN/0GM<输入; examples三件套重生成且可复现0diff
2026-09-04 16:26:10 +08:00
4843053ad3 Fix issues #23-#25 (+#26 标注): GM读写共享总线累加计时 / ASW-切M/N 共享块 GM首读1次+L2重复读(n-1)次、场景按单batch判定、分组预算不再除B / StreamK 按plan实际tile芯片口径评估 / 降核线性带宽假设文档标注 2026-09-04 11:43:23 +08:00
4bedf0a109 Fix review issues #11-#16: StreamK fixpipe 单次计账 / K=1 AIV单缓冲方案 / MergeBatch b0 L0A/L0B 上限+路由可行回退 / advice-StreamK / 输入校验 / .gitignore+死代码清理 2026-09-03 20:05:14 +08:00
7bcacef200 Update BMM_Theory: README.md (fix review issues #4-#10) 2026-09-03 11:34:06 +00:00
0ef5903d64 Update BMM_Theory: README.md 2026-09-03 09:25:34 +00:00
8ba289b56b Add BMM_Theory: README.md 2026-09-03 08:09:21 +00:00