16 后端 Codegen 与指令调度洞察
- 章节编号:16
- 所属层:C 编译与算子层(核心壁垒;DSA 自研 codegen 是性能命脉)
- 关联 ADR:ADR-029(后端 Codegen 路径)、ADR-030(静态调度与解耦访问/执行)、ADR-031(片上 SRAM/DMA 分配)、ADR-032(Auto-tuning/Cost model/微内核兜底)
- 上游依赖:02(数据流/精度)、03(SRAM/DMA)、07(张量 CISC ISA)、08(静态调度/显式 DMA)、15(IR/DSA Dialect)
学习目标
- 前置知识:读过 15 章(IR 与 DSA Dialect,知道 tiling/fusion 是在 IR 层怎么表达的)、03 章(片上 SRAM 稀缺、DMA 显式搬运)、07/08 章(张量级 CISC ISA、静态调度与弱序内存语义)。会看 Roofline(知道算子是「算力受限」还是「带宽受限」),写过基础 GEMM 循环即可,无需写过真实编译器后端。
- 学完产出:① 能画出后端 codegen 的完整流水——从 DSA Dialect 到芯片指令,中间经过 tiling → fusion → 片上内存分配 → 指令调度 → DMA 双缓冲这几个关键阶段,并说清每一阶段在解决什么物理约束;② 能用「让 tile 恰好放进 SRAM」一句话讲清 tiling 尺寸为什么不是越大越好,并亲手算一遍一个 GEMM tile 的 SRAM 占用;③ 能量化 fusion 的收益——算出「融合前 vs 融合后」一段
matmul → add → gelu的 HBM 读写次数差,理解为什么 fusion 是带宽受限算子的第一优化;④ 能说清「双缓冲 + 解耦访问/执行」如何用一次 DMA 预取把下一块数据的搬运延迟藏进当前块的计算里;⑤ 能解释为什么后端 codegen 是自研 DSA「不可外包的第一壁垒」。 - 阅读姿势:盯住一条主线——「后端 codegen 的每一个 pass,都是在跟『片上 SRAM 太小、HBM 太慢』这两堵墙讨价还价」。tiling 是为了让数据放得进 SRAM;fusion 是为了不把中间结果写回 HBM;双缓冲是为了让计算单元在等数据时不空转。看懂这条主线,ADR-029~032 的所有取舍就都串起来了。
1. 范围与目标
后端把 DSA Dialect(15 章) 降为芯片可执行的高效指令。DSA + 编译兼容 ⇒ 性能在很大程度由自研 codegen 决定(无论上层是框架直降还是 Triton 前端),这是不可外包的第一壁垒。
核心问题
- 后端路径:复用 LLVM 还是自定义汇编?张量引擎指令如何生成?
- 指令调度(软流水)、寄存器/片上 SRAM 分配、DMA 编排如何做?
- 如何实 现 静态调度 + 解耦访问/执行(确定性 + 延迟隐藏)?
- Auto-tuning + cost model 与手写微内核兜底如何配比?
2. 需求洞察(承接上游)
- 张量级 CISC + 向量/标量(07 章) ⇒ 后端做张量指令选择 + 向量/标量指令 + repeat/解耦语义。
- 软件管理 scratchpad + 显式 DMA + 弱序(08 章) ⇒ codegen 自动编排片上内存分配 + DMA 搬运 + 同步插入(最难)。
- 确定性(01/08 章,Groq 印证) ⇒ 关键路径静态可调度、时序可预测。
- batch≈1(01 章) ⇒ tiling/软流水把小 GEMM/算子打满,隐藏访存延迟。
- 混合精度/块缩放(02 章) ⇒ 指令级支持 INT4/8/FP8 + 块缩放 + BF16 累加。
- 编译兼容(07 章) ⇒ 每代重调,需 cost model + auto-tuning 保性能可移植。
2.1 后端 codegen 全流水:一张图看清「Dialect → 指令」
后端不是一个黑盒,而是一串目的明确的 pass。下图把 DSA Dialect 降到芯片指令的关键阶段拆开,标注每一阶段跟哪堵物理墙对话:
读这张图的关键:tiling 与内存分配对着「SRAM 太小」这堵墙,fusion 与 DMA 编排对着「HBM 太慢」这堵墙。后端的性能上限,就是这几个 pass 跟两堵墙讨价还价的结果——这也是为什么 codegen 无法外包:墙的位置(SRAM 容量、DMA 带宽、张量单元形状)每代芯片都在变,pass 的启发式必须跟着重调。
3. 技术现状与趋势(点名 + 来源)
3.1 结构化 Codegen(MLIR/IREE)
- MLIR/IREE 的 structured codegen(Nicolas Vasilache 等)是 IREE 的核心;把 tiling/fusion/数据布局沉淀进 MLIR,后端生成各硬件高效 kernel。
- 判断:复用 MLIR structured codegen 框架,自研 DSA 后端(指令选择/调度/分配)。
3.2 全代码生成 + cost model(降手写依赖)
- PolyBlocks:分析性 cost model + 启发式,多级 tiling、片上 scratchpad 使用、映射 matmul/conv 到矩阵单元、attention 融合;JIT 媲美/超过 TorchInductor/XLA,单算子 competitive with cuDNN/cuBLAS。
- TPP/libxsmm:Linalg→XSMM 微内核,编译器做 tiling/fusion/layout,底层用微内核做向量化/指令选择。
- 判断:编译器自动生成为主(cost model + auto-tuning),手写微内核/算子兜底(17 章),高频 pattern 回流为模板。
3.3 静态调度 + 解耦访问/执行(确定性 + 延迟隐藏)
- TPU:解耦访问/执行(地址发出即完成,重叠 DMA 与计算)。
- Groq:编译期把每条指令/搬运/同步排到时钟周期,零抖动确定性(02 章 3.5)。
- 判断:关键实时路径采静态调度(确定性);通用路径软流水 + 解耦访问/执行隐藏访存延迟。
3.4 后端基座:LLVM
- LLVM 提供成熟的指令调度/寄存器分配/RISC-V 后端;张量引擎为自定义指令/intrinsic。
- 判断:RISC-V 标量/控制走 LLVM 后端;张量/向量自定义 codegen(可经 LLVM IR 或自定义汇编)。
3.5 后端选型:业界是否都用 LLVM?有无替代?为什么
这是本章的关键决策:既要极致性能,又要快速构建 + 稳定演进。结论:高/中层业界已收敛到 MLIR;后端则「分叉」——标量/GPU 类走 LLVM,张量引擎多在 MLIR 层「切出」自定义后端。
3.5.1 LLVM 的能与不能(为何不能全靠 LLVM)
- LLVM IR 是 CPU 中心、过于低层,丢失张量/内存层级的高层语义(「语义鸿沟」);其指令选择/调度主要面向最内层循环体,难以重建并映射「跨多重循环的多维数据块」到张量单元(MLIR Rationale 明确指出)。
- 因此张量引擎(脉动/VLIW/数据流)的高效映射、软流水、片上内存编排,LLVM 后端做不好;这些更适合在 MLIR 层完成(MLIR 设计上承担部分低层调度/向量映射/软流水)。
3.5.2 业界后端选型对比(点名,2025–2026 最新)
| 芯片 | 高/中层(MLIR 化) | 后端 codegen | 是否基于 LLVM | 原因 |
|---|---|---|---|---|
| NVIDIA | Triton IR / CUDA Tile IR(MLIR) | NVPTX→PTX;新增 tileiras(Tile IR) | 是(LLVM,NVVM) | GPU 与 LLVM 契合;Tile IR 引入张量级抽象但仍接 LLVM/PTX 工具链 |
| AMD | ROCm/Triton(MLIR) | AMDGPU(LLVM) | 是(LLVM) | GPU 后端 LLVM 化 |
| 华为昇腾 | AscendNPU IR(MLIR) | 毕昇 BiSheng → CCE intrinsics | 是(LLVM 基的毕昇 fork) | MLIR 做张量抽象,毕昇(LLVM fork) 做后端 + 自定义 CCE 固有函数 |
| 寒武纪 | BANG/MLIR | CNCC(LLVM/Clang 基) | 是(LLVM) | 复用 LLVM 前端/标量 + 自定义扩展 |
| Google TPU | StableHLO/Mosaic(MLIR) | XLA 自有 codegen | 大体否 | 张量/脉动 + 软件管理内存,LLVM 标量后端不契合 |
| Groq | GroqFlow(MLIR) | 自研后端(周期级静态调度) | 否(MLIR 层切出) | 确定性静态调度需自控,LLVM 无法表达周期级编排 |
| Cerebras / Tenstorrent | MLIR | 自研后端(MLIR 层切出) | 多为否 | 晶圆级/数据流硬件 LLVM 不适配 |
规律:多数厂商后端基于 LLVM 或其 fork(NVIDIA NVVM、AMD AMDGPU、华为毕昇 BiSheng、寒武纪 CNCC)——即「MLIR 做张量级抽象 + LLVM(或 fork)做最终 codegen + 自定义 intrinsics」;纯自研(不经 LLVM)集中在数据流/确定性芯片(TPU、Groq、Cerebras),因其周期级静态调度/晶圆级互联 LLVM 难以表达。这进一步印证我们 ADR-029 的合理性——LLVM 是后端的现实主力,差异化靠 MLIR 张量 Dialect + 自定义 intrinsics。
3.5.3 对我们的建议(性能 × 快速构建 × 稳定演进)
业界张量后端有两条可行模式:
- 模式 A:MLIR → LLVM(或 fork)+ 自定义 intrinsics(华为毕昇 BiSheng + CCE、寒武纪 CNCC)——复用 LLVM 指令调度/寄存器分配/工具链,快速构建 + 稳定,张量靠自定义 intrinsics + MLIR 张量 Dialect。
- 模式 B:MLIR 层 tap-off → 自研后端(TPU/Groq)——周期级静态调度/确定性极致,但后端全自研,构建慢、人力重。
我们的建议:
- ✅ 标量/控制核(RISC-V)用 LLVM 后端(复用,快速稳定)。
- ✅ 张量/向量引擎优先走模式 A(自建 LLVM fork + 自定义 DSA intrinsics + MLIR 张量 Dialect)——在「性能 × 快速构建 × 稳定演进」间取最优,复用 LLVM 大幅降人力(对标华为毕昇路径);
- ✅ 仅对硬实时控制关键路径采用模式 B 的静态调度思想(周期级确定性,关联 08/13、Groq 案例),其余走模式 A。
- ✅ 稳定演进:MLIR structured codegen + cost model + auto-tuning 支撑编译兼容每代重调;LLVM 跟随上游。
- 结论:「LLVM(含自建 fork,标量 + 张量 intrinsics)+ MLIR 张量 Dialect,关键路径叠加静态调度」 最契合三目标——印证并细化 ADR-029(多数厂商后端基于 LLVM/fork,纯自研仅数据流芯片)。
3.6 三大 codegen 变换:tiling / fusion / 双缓冲的物理动机
后端最核心的三个变换,本质都在解决「数据搬运比计算慢」这堵物理墙,但下手的地方不同。下表把三者对齐,让读者一眼看清各自的输入信号、优化目标与失败模式:
| 变换 | 对着哪堵墙 | 优化目标 | 关键旋钮 | 调过头的后果 |
|---|---|---|---|---|
| Tiling(分块) | SRAM 太小 | 让工作集放进片上 SRAM,提高数据复用 | tile 尺寸 (M×N×K) | tile 太大 → 溢出 SRAM;太小 → 复用不足、DMA 次数暴涨 |
| Fusion(融合) | HBM 太慢 | 相邻算子共享片上数据,少写回中间结果 | 融合边界(哪些算子并进一个循环) | 融合过广 → 单 tile 工作集撑爆 SRAM,被迫缩 tile,反伤复用 |
| 双缓冲(double-buffer) | DMA 搬运有延迟 | 用两块 buffer 交替,让预取与计算重叠 | buffer 数(2 / 多级流水深度) | buffer 翻倍占 SRAM,挤压 tile 容量;深度过大收益递减 |
三者相互牵制:fusion 想把更多算子塞进一个 tile,双缓冲想多留几块 buffer,而 SRAM 总量是固定的一块蛋糕。后端 codegen 的手艺,就是在这块固定蛋糕上,为 tiling 工作集、fusion 中间结果、双缓冲预取槽三者分配份额——这正是 ADR-031「片上 SRAM/DMA 分配是最难的 codegen」的由来。
3.7 解耦访问/执行:双缓冲之所以成立的硬件前提
双缓冲能藏住 DMA 延迟,前提是搬运引擎和计算引擎能各干各的、异步并行。这就是「解耦访问/执行(decoupled access/execute)」:
要点:访问端搬 tile N+1 时,执行端在算 tile N,两者踩着 buffer A/B 交替。只要「一块 tile 的计算时间 ≥ 一块 tile 的 DMA 时间」,搬运延迟就被计算完全掩盖——这与 GPU 靠海量 warp 隐式掩盖延迟殊途同归,只是 DSA 把同步交给编译器显式插 set/wait flag(08 章弱序语义)。后端 codegen 要做的,就是自动算准 buffer 大小、自动插对同步点,插错一个 flag 就是数据竞争或死锁。
3b. 由演进反推的诉求(定性)
| 维度 | 当前 | 未来 | 后端含义 |
|---|---|---|---|
| 算子覆盖 | 核心集自动生成 | 80%+ 自动生成 | 强 cost model + auto-tuning |
| 调度 | 软流水 + 解耦 | 多任务并发 | 静态调度(实时路径)+ 动态(认知层) |
| 内存 | scratchpad/DMA 编排 | KV/长上下文 | 自动内存分配 + DMA double-buffer |
| 精度 | INT4/8/FP8+BF16 | + 块缩放 FP4 | 指令级混合精度/microscaling |
3b.1 具身负载对后端的额外要求
对齐 M 层(21 章具身模型支持),VLA/流匹配动作头给后端 codegen 压了几条具身特有的担子:
| 负载特征(来自 21 章) | 后端 codegen 影响 | 对应能力 |
|---|---|---|
| batch≈1 的小 GEMM(M=1) | 张量单元易「喂不饱」 | 激进 tiling + 软流水打满 pipeline |
| 流匹配/扩散迭代 loop(5–10 步) | 循环体需 tiling + fusion 复用 KV/权重 | loop tiling + 跨步 buffer 驻留 |
| 动作专家 300M 可驻 SRAM(21 章 3b) | 权重常驻,省去反复 DMA | 片上驻留分配 + 权重 pinning |
| RTC 异步 chunk(双缓冲) | 当前 chunk 执行 + 下一 chunk 生成并发 | runtime 双缓冲 ⇄ codegen 双缓冲对齐(12 章) |
| cross-embodiment 动态 shape 子集 | tile 尺寸随 action/state 维度变 | shape polymorphism + padding 到 max dim |
注:π0.7、GR00T N1.7 等 2026 具身模型的 GA 状态与算子清单以官方为准;此处仅取「流匹配 loop + 小 GEMM + 双缓冲 chunk」这一稳定的后端诉求骨架,roadmap 细节以官方为准。
4. 候选方案与对比矩阵
4.1 后端路径
| 候选 | 性能上限 | 复用 | 风险 | 可驾驭度 | 小结 |
|---|---|---|---|---|---|
| A. 纯自定义汇编后端 | 5 | 1 | 5 | 2 | 性能极致但人力/风险大 |
| B. LLVM(标量)+ 自定义 DSA codegen(张量) | 5 | 4 | 3 | 4 | 建议方案:复用 LLVM,自研张量后端 |
| C. 完全依赖第三方库 | 2 | 5 | 2 | 4 | DSA 无现成库,不可行 |
4.2 调度策略
- 关键实时路径静态调度(确定性,Groq 式);通用路径软流水 + 解耦访问/执行。
4.3 性能获取
- Auto-tuning + 分析性 cost model(PolyBlocks 式) 为主,手写微内核兜底(17 章),AI-Native(LLM 生成候选 + 搜索筛选)。
建议方向:B + 静态/软流水混合 + auto-tuning + 微内核兜底。
5. 关键权衡、风险与依赖
- 自动生成性能 vs 手写(核心):自研 DSA ⇒ codegen 在很大程度决定性能;cost model/auto-tuning 不达标则需更多手写算子(预算与 02/15/组织一致)——全栈最大风险。
- 片上 SRAM/DMA 分配是最难的 codegen:SRAM 稀缺(03 章)+ 软件管理 ⇒ 分配/复用/double-buffer 策略直接决定能效;需与数据流(02)协同。
- 静态调度 vs 灵活性:全静态确定但僵;实时路径静态、认知层动态的折中。
- 编译兼容的重调成本:每代重调依赖 cost model + CI(30 章)。
- 依赖:07/08(ISA/调度语义)、15(DSA Dialect)、17(微内核)、18(auto-tuning)、03(SRAM)、30(CI/AI-Native)。
6. 结论与待决项
初步结论
- LLVM(标量/RISC-V)+ 自定义 DSA codegen(张量/向量);复用 MLIR structured codegen。
- 关键实时路径静态调度(确定性)+ 通用路径软流水 + 解耦访问/执行(延迟隐藏)。
- 自动 SRAM 分配 + DMA 编排(double-buffer) 是核心壁垒,与数据流协同。
- Auto-tuning + 分析性 cost model 为主 + 手写微内核兜底;AI-Native 候选生成。
待决项
- cost model 精度路线(分析性 vs 学习型)——与 18 章联合。
- 静态调度覆盖范围(仅实时路径 vs 更广)——与 08/13 联合。
- LLVM 自定义后端 vs 自定义汇编的边界——与硬件/07 联合。
ADR 候选
- ADR-029 后端路径(细化):标量/RISC-V 走 LLVM;张量引擎优先「自建 LLVM fork + 自定义 DSA intrinsics + MLIR 张量 Dialect」(模式 A,对标华为毕昇/寒武纪 CNCC),关键实时路径叠加 Groq 式周期级静态调度(模式 B);复用 MLIR structured codegen。兼顾 性能 × 快速构建 × 稳定演进。
- ADR-030 调度:实时路径静态调度 + 通用路径软流水 + 解耦访问/执行。
- ADR-031 内存分配:自动片上 SRAM 分配 + DMA 编排(double-buffer),与数据流协同。
- ADR-032 性能获取:auto-tuning + 分析性 cost model 为主 + 手写微内核兜底 + AI-Native 候选生成。
7. 端→边→中心演进影响
- 同后端框架对不同规模 DSA 重定向(更多 PE/更大 batch),靠 cost model + auto-tuning 适配;编译兼容(07 章)使软件栈一致。
- 不可逆点:codegen 依赖的 ISA/内存语义随 RTL 冻结;后端需为新指令/精度预留扩展。
深入思考
下面三题每题先给题干,再用
<details>折叠一份图文并茂的参考答案。建议先合上答案自己想 3 分钟,再展开对照。
思考题 1:tiling 尺寸如何匹配片上 SRAM 容量
你在为一个 DSA 后端写 GEMM 的 tiling pass,SRAM 只有几 MB。若把 tile 开太大,编译报「SRAM 溢出」;开太小,DMA 次数暴涨、张量单元喂不饱。结合 3.6 节的 tiling 动机,推导「一个 M×N GEMM tile 到底要占多少 SRAM」,并说明你会怎么选 tile 尺寸。
展开参考答案(含 tiling-SRAM 约束图 + 算一遍)
结论:一个 GEMM tile 的 SRAM 占用 = A 分块 + B 分块 + C 分块三者之和,且还要为双缓冲预留一份;tile 尺寸的上限由 SRAM 容量硬性卡死,下限由数据复用率决定,最优点是在「放得进 SRAM」的前提下把复用率吃满。
用具体数字算一遍(设 SRAM = 4 MB,数据类型 FP16 = 2 字节/元素,做单缓冲估算):
- 取 tile 尺寸
Mt = Nt = Kt = 256。 - A 分块 = Mt×Kt = 256×256 = 65536 个元素 → 65536 × 2 = 128 KB。
- B 分块 = Kt×Nt = 256×256 = 128 KB(同上)。
- C 累加器 = Mt×Nt = 256×256,累加常用 FP32(4 字节)→ 65536 × 4 = 256 KB。
- 单缓冲小计 = 128 + 128 + 256 = 512 KB;开双缓冲(预取下一 tile)≈ 1 MB,占 4 MB SRAM 的 1/4,合法且留有余地。
- 若把 tile 放大到 512:A、B 各 512 KB,C 累加器 1 MB → 单缓冲 2 MB,双缓冲 4 MB 正好撑满整块 SRAM,再无空间给 fusion 中间结果或其他 buffer → 溢出风险,
ncu式工具会报 SRAM 分配失败。 - 若把 tile 缩到 64:单缓冲仅 ~40 KB,但每个 K 方向的分块要反复从 HBM 拉 A/B,DMA 次数按 (K/Kt) 线性上升,复用率骤降,张量单元大量时间在等 DMA。
怎么选:先用「三块 ×2 ≤ SRAM」定出 tile 尺寸上限,再在上限内向大取——tile 越大,K 方向复用越充分、DMA 次数越少,直到把 SRAM 吃到留出 fusion + 双缓冲余量为止。这正是 PolyBlocks 式分析性 cost model 做的事:枚举合法 tile 尺寸,按「复用率 / DMA 次数」估分选最优。(回到 3.6 节看 tiling 的失败模式表。)
思考题 2:fusion 如何减访存
一段 y = gelu(matmul(x, W) + b) 在未融合时,matmul、add、gelu 各是一个 kernel,中间结果反复进出 HBM。结合 3.6 节的 fusion 动机,算一遍「融合前 vs 融合后」这段计算的 HBM 读写次数差,说明 fusion 为什么是带宽受限算子的第一优化。
展开参考答案(含 fusion 访存对比图 + 算一遍)
结论:未融合时,每个算子都要把整块中间张量写回 HBM、下一个算子再从 HBM 读回,来回搬运;融合后中间结果只在片上 SRAM 里流转,一次都不落 HBM——省下的 HBM 读写次数,对带宽受限算子几乎等价于直接省时间。
用具体数字算一遍(设中间张量每块 T 字节,忽略 x/W/b/y 的固定读写,只数中间结果 t1、t2 的搬运):
- 未融合:
- matmul 把 t1 写 HBM:+1 次 T。
- add 把 t1 读回:+1 次 T;算完把 t2 写 HBM:+1 次 T。
- gelu 把 t2 读回:+1 次 T。
- 中间结果 HBM 流量小计 = 4T(t1 写+读、t2 写+读)。
- 融合:matmul 结果留在 SRAM 里直接喂给 add,add 结果再留在 SRAM 喂给 gelu,t1、t2 一次都不落 HBM → 中间结果 HBM 流量 = 0。
- 省了多少:
4T → 0,这段计算的中间访存被完全消除。若原本是带宽受限(HBM 搬运时间 > 张量单元计算时间),省掉 4T 的 HBM 流量近似等价于把这几步的墙钟时间压到接近纯计算时间。
为什么是「第一优化」:elementwise 算子(add/gelu/norm)算力极低、几乎纯搬运,单独成 kernel 就是「读一遍、写一遍」的带宽账单;把它们融进前面的 matmul,让它们「顺路」在 SRAM 上算掉,访存账单直接归零。这正是 21 章把 LayerNorm/Softmax 标为「融合」P0 算子、PolyBlocks 把 attention 融合作为核心能力的原因。代价见 3.6 节:融合过广会撑爆单 tile 工作集,被迫缩小 tile,反伤 GEMM 复用——所以 fusion 边界要由 cost model 权衡。(回到 3.6 节对照三变换的相互牵制。)
思考题 3:双缓冲指令调度如何掩盖搬运延迟
你的 GEMM kernel 里,张量单元经常在「等 DMA 把下一块数据搬进 SRAM」时空转。结合 3.7 节的解耦访问/执行,说明双缓冲的软流水如何把 DMA 搬运延迟藏进计算里,以及后端 codegen 要为此做对哪些事、什么条件下延迟藏不住。
展开参考答案(含双缓冲流水时序图 + 算一遍)
结论:双缓冲用两块 SRAM buffer 交替——张量单元算 buffer A 里的 tile N 时,DMA 同时把 tile N+1 预取进 buffer B,下一拍交换;只要「一块 tile 的计算时间 ≥ 一块 tile 的搬运时间」,DMA 延迟就被计算完全盖住,张量单元不再空转。
用具体数字算一遍(设每块 tile 计算耗时 Tc = 100 μs,搬运耗时 Tdma = 60 μs,共 10 块 tile):
- 无双缓冲(串行):每块 = 搬 60 + 算 100 = 160 μs,10 块 = 1600 μs,其中 600 μs 纯耗在等搬运。
- 有双缓冲(重叠):除了第一拍的填充 60 μs,之后每拍计算 100 μs 完全盖住并行的 60 μs 搬运 → 总时间 ≈ 填充 60 + 10×100 = 1060 μs。
- 省了多少:
1600 → 1060,省下的正好约等于被掩盖的 9 块搬运时间(9×60≈540 μs),张量单元利用率从 100/160=62.5% 拉到接近 100/100≈100%。 - 延迟藏不住的临界点:若把 tile 缩小到搬运比计算还慢(
Tdma > Tc,如 Tdma=120 > Tc=100),则每拍瓶颈变成 DMA,计算单元反而要等搬运——此时双缓冲只能把总时间压到≈10×120,掩盖失效。这就是「算子从算力受限滑向带宽受限」时双缓冲收益消失的物理原因。
后端 codegen 要做对的事:① 为 buffer A/B 各分配一块 SRAM(占用翻倍,要挤进 3.6 节那块固定蛋糕);② 在正确位置插 set/wait flag(08 章弱序),让「算完 A 才复用 A、搬完 B 才读 B」的依赖成立,插错就是数据竞争或死锁;③ 用 cost model 估 Tc vs Tdma,判断双缓冲是否划算、要不要开更深的多级流水。这正是 ADR-030(软流水 + 解耦访问/执行)与 ADR-031(DMA double-buffer)落到指令层的样子。(回到 3.7 节看 set/wait flag 的同步图。)
8. 端→边→中心演进影响(补:调度粒度)
| 维度 | 端侧 | 边缘 | 中心 |
|---|---|---|---|
| tiling 目标 | 小 SRAM、batch≈1 打满 | 中等 batch 平衡复用 | 大 batch 吞吐优先 |
| 调度 | 静态 + 双缓冲(确定性) | 静态/动态混合 | 动态多任务并发 |
| fusion 深度 | 激进(省带宽即省功耗) | 中等 | 按吞吐权衡 |
不可逆点:codegen 依赖的 ISA/内存语义随 RTL 冻结;后端需为新指令/精度预留扩展。tiling/fusion/双缓冲的 cost model 参数应外置为可配置,避免每代硬编码。
附:信息来源
区分公开/估计;参考时间 2026-06。
- 结构化 Codegen / IREE:IREE structured codegen(iree.dev、《Unveiling IREE》分享,Nicolas Vasilache 等论文)。[公开]
- 全代码生成 + cost model:PolyBlocks(arXiv:2603.06731 待核,分析性 cost model + 启发式、多级 tiling、片上 scratchpad、映射矩阵单元、attention 融合、媲美 cuDNN/cuBLAS);TPP/libxsmm(arXiv:2404.15204,Linalg→XSMM 微内核)。[公开]
- 静态调度/解耦访问执行:TPU 论文(decoupled access/execute);Groq(编译期周期级静态调度,见 02 章 3.5)。[公开]
- 后端基座:LLVM(指令调度/寄存器分配/RISC-V 后端)。[公开]
- LLVM vs 替代后端(3.5,2025–2026 最新):MLIR Rationale(LLVM IR CPU 中心/语义鸿沟、MLIR 承担低层调度/软流水/向量映射);Modular《Democratizing AI Compute Part 8》(Cerebras/Groq MLIR + 自研后端,custom silicon MLIR 层 tap-off);华为毕昇 BiSheng(LLVM fork)+ AscendNPU IR + CCE intrinsics(昇腾社区 2025-05);NVIDIA CUDA Tile IR(developer.nvidia.com,MLIR 基,接 tileiras/NVVM/PTX);寒武纪 CNCC(LLVM 基);NVPTX/AMDGPU(LLVM);TPU XLA/Groq GroqFlow(自研后端)。[公开 + 媒体]
- 具身负载对后端诉求(3b.1):对齐 21 章具身模型支持;π0.7 / GR00T N1.7 GA 状态与算子清单以官方为准。[公开 + 估计]
- 后端路径/调度/分配/LLVM 选型取舍、tiling/fusion/双缓冲算例:基于上述公开资料的工程判断与数量级估算。[估计]