17 算子 / Kernel 策略洞察
- 章节编号:17
- 所属层:C 编译与算子层(承接 15/16 编译器;落实 21 章算子 P0)
- 关联 ADR:ADR-054(算子获取策略:codegen vs 手写 vs 库)、ADR-055(具身 P0/P1 算子覆盖与里程碑)、ADR-056(Triton/外部 DSL 边界)、ADR-057(模板沉淀与跨代复用)
- 上游依赖:01(算子画像)、02(数据流/精度)、15/16(MLIR codegen)、18(Auto-tune,接口)、21(具身 P0 列表)
学习目标
- 前置知识:读过 15/16 章(MLIR codegen 的 Linalg → 硬件 IR 下降流程)、21 章(具身模型族与 P0/P1 算子列表);理解「GEMM/Attention 是 Transformer 算力大头」;知道 CUDA/CANN 各是 GPU/昇腾的算子生态即可。无需写过 kernel。
- 学完产出:① 能画出「一个新算子出现 → codegen / Triton / 手写 / decompose」的决策树,并说清每条分支的触发条件;② 能用「算子数量 vs 算力占比」两把尺子解释为何「手写 ≤20% 算子数量却承载 ~80% 算力」不矛盾,并亲手算一遍这个 80/20 的账;③ 能排出具身 P0/P1 算子的优先级顺序,说清「为什么 INT4 GEMM 与 fused SDPA 是 M2 的 P0 而非 M4 补丁」;④ 能界定 Triton 作为「迁移层」的性能口径——它能省什么、不能省什么、什么时候该退回手写;⑤ 能把这套策略对齐到 Demo
04-kernels与 M1–M5 里程碑,说清每个 Gate 的验收物。 - 阅读姿势:盯住一条主线——「算子策略的一切取舍,都是在『人力』与『峰值利用率』之间找平衡点」。纯 codegen 省人力但吃不满硬件,纯手写吃满硬件但人力爆炸;真正的工程解是「让编译器覆盖 80% 的长尾算子数量,把稀缺的手写人力集中砸在承载 80% 算力的那 20% 热点上」。
1. 范围与目标
本章定义算子性能如何获取:编译器自动 codegen 为主还是手写 kernel/算子库为主?具身 VLA 长尾算子如何覆盖?Triton 等可移植 DSL 的边界?与 Demo 04-kernels、M1–M3 里程碑如何对齐?
核心问题
- "codegen 为主 + 手写兜底" 如何量化落地(哪些算子手写)?
- 具身 P0/P1 算子(21 章)的覆盖路线与 Gate?
- TOP 厂商(NVIDIA/华为/高通/地平线)算子策略于我们有何借鉴?
- Triton(15 章可选前端)投入深度?
- 算子模板如何跨芯片代际复用(07 编译兼容)?
2. 需求洞察(具身驱动)
2.1 算子压力来源(点名)
| 来源 | 关键算子/模式 | 频率 |
|---|---|---|
| OpenVLA 7B | ViT conv/patch;MHA+KV;Llama FFN;256-bin action head | 3–5Hz |
| π0 / GR00T | 同上 + 流匹配/扩散 while-loop;cross-attn;chunk reshape | 10–50Hz 控制语义 |
| GR00T 双系统 | VLM backbone + DiT AOT;中间 activation 传递 | 10.9Hz(Thor 92ms) |
| 多相机 ViT | batch 多路 camera;patch embed + conv | 30–60Hz 感知 |
| Diffusion Policy | 小 U-Net conv/FC;迭代 loop | 10–100Hz |
| 感知前端 | depth/seg CNN;ViT | 10–60Hz |
| 控制小网 | 小 MLP/GEMM | 200Hz–1kHz |
2.2 硬性指标
- 小 batch GEMM(M=1) 利用率 ≥ 可接受阈值(02 章);P0 算子 bit-exact 对 ISS。
- P0 算子 M3 前全覆盖(21 ADR-049);含 INT4/NVFP4 GEMM + fused MHA/SDPA;P1 在 M4。
- 新 VLA 结构 ≤4 周 接入(自定义 op 路径,15 ADR-028)。
- 手写兜底算子 ≤15–20% 算子数量,但因热点集中,这部分算子承载 ~80%+ 算力/耗时(组织惯例,本洞察验证)。对应 ADR-054:codegen 覆盖 ≥80% 算子数量,手写 ≤20% 算子数量——两个 80/20 分别指「算力占比」与「算子数量占比」,勿混淆。
2.3 两把尺子:算子「数量」与算力「占比」
策略讨论最容易踩的坑,是把「算子」当成一维的东西数。实际有两把尺子:
- 数量尺:一个 VLA 子图会 lowering 出几百个不同的算子/融合模式——GEMM、Attention、LayerNorm、各种 elementwise(add/mul/gelu/silu)、reshape、gather、cast、量化 dequant……绝大多数是「长尾」:各自只出现一两次、算力占比极小。
- 算力尺:同一张子图里,GEMM(含 FFN)+ Attention 通常吃掉 70%~90% 的浮点运算;剩下几百个长尾算子加起来往往不到 10%~20%。
这两把尺子方向相反:热点算子在数量上是少数,在算力上是多数。工程决策必须分尺子谈——「codegen 覆盖 ≥80% 算子数量」说的是数量尺(把长尾都自动生成掉,省人力),「手写 elite 承载 ~80% 算力」说的是算力尺(把人力集中砸在热点上)。混用一把尺子,就会得出「手写 20% 却占 80%」这种看似矛盾、实则各说 各话的表述。思考题 1 会用具体数字把这本账算一遍。
3. 技术现状与趋势(点名 + 来源)
3.1 算子获取策略光谱
| 策略 | 描述 | 代表 |
|---|---|---|
| 库依赖 | cuDNN/cuBLAS/FlashAttention 手调库 | NVIDIA 传统 |
| 编译器 codegen | MLIR/LLVM 生成 + auto-tune | IREE structured codegen;TPU XLA |
| 手写 intrinsics | Ascend C/BANG C/CUDA 专家 kernel | 华为/寒武纪 performance 团队 |
| 可移植 DSL | Triton → Linalg/厂商 IR | 15 章:昇腾/摩尔/FlagTree |
| 封闭编译器 | 天工开物自动,新算子仅 CPU | 地平线 BPU |
3.2 TOP 级 AI 推理芯片算子策略横向对比(2025–2026)
| 公司/栈 | 主策略 | 手写/库占比 | 具身/VLA 相关 | 优势 | 劣势 |
|---|---|---|---|---|---|
| NVIDIA | 库(cuDNN/FA)+ Triton/CUTLASS + TensorRT fusion | 库+手写 elite kernel 为主 | GR00T DiT TRT engine;Edge-LLM 融合 | 性能天花板;生态 | 闭源;绑 GPU |
| 华为昇腾 | Ascend C 手写 + 编译器 + Triton→Linalg→AscendNPU IR | 关键算子手写+模板(CATLASS 式) | π0 走 torch_npu;算子靠 CANN | 软硬协同;Triton 接入 | 体量大;迁移成本 |
| Qualcomm | QNN 编译 + Hexagon NN;HTP 融合 | 预置 op 集;QNN 量化融合 | Dragonwing VLA 平台级 | 车规;ROS2 | 大模型长尾 op 依赖厂商更新 |
| Google TPU | XLA 全 codegen + Pallas/Mosaic 自定义 | 极少手写 | 云训练为主 | 编译兼容 | 端侧无 |
| 地平线 | 编译器自动生成;自定义 仅 CPU/DSP | BPU 算子固定 | 车载感知强;VLA 弱 | 能效 | VLA 演进慢 |
| Groq | GroqFlow 编译;curated op | 几乎无手写 | 非具身 | 确定性 | 不可编程 |
| IREE(我们的底座) | Structured codegen + 手写 microkernel 兜底 | 随后端 maturity 动态 | Vulkan/CPU 验证;DSA 待建 | MLIR 同源;可扩展 | 新后端工作量大 |
| Physical Intelligence | PyTorch eager;不绑芯片 | 框架层 | π0 中立 | 客户可选我们 | 无芯片特化 |
横向 规律:
- 性能关键路径终需手写或 elite 库——纯 codegen 在长尾/新结构(VLA cross-attn、flow loop)上需 手写兜底或 Triton 生态。
- Triton 成为"迁移层"而非核心(15 章):昇腾/摩尔/FlagTree 均 Triton→Linalg;我们 可选 接入。
- 地平线反例:封闭 BPU 算子集 → VLA 快速演进不适用;印证 07 章可编程性红线。
- 具身 P0 = GEMM/MHA/KV/LN/Softmax/迭代 loop + INT4 GEMM + fused SDPA——与通用 LLM 重叠 70%+;差异化在 loop 融合、chunk op、cross-attn mask、1-NFE 快路径。
口径校准(截至 2026 年中):NVIDIA GR00T on Thor 的 DiT 走 TensorRT engine(手写/库路径),VLM backbone 走 Edge-LLM,精度 LLM nvfp4 + ViT/DiT fp8;华为 Ascend C 手写 + Triton-ascend(2025-03 开放)+ CATLASS 模板是其算子主路径。roadmap 类目标(如 Triton→AscendNPU IR 的成熟度、FlagGems 覆盖清单)以官方为准,本表为工程判断而非承诺。
3.3a GR00T 式混合部署与算子边界
| 组件 | GR00T Thor 做法 | 我们算子策略 |
|---|---|---|
| VLM backbone | PyTorch eager / Edge-LLM | IREE VM 或 PyTorch+IREE 混合 |
| DiT 动作头 | TensorRT engine(49ms/4步) | IREE AOT vmfb + tuning spec(18) |
| 精度 | LLM nvfp4, ViT/DiT fp8 | INT4/NVFP4 模板(19 章),M2 起入 P0 |
| 中间 tensor | device 内传递 | dmabuf 共享,无 CPU 拷贝(09) |
判断:不必全栈 PyTorch;性能关键 DiT/Attention 走 AOT codegen+手写 elite;backbone 可渐进迁移。
3.3b LeRobot importer 算子边界
| LeRobot 模块 | 编译器须识别 | 手写/codegen |
|---|---|---|
action_expert flow loop | while-loop + cross-attn IR 原语 | M3 fused loop |
chunk_size / n_action_steps | shape 特化 dispatch | autotune shape 库(18) |
ViT image_features | multi-camera batch dim | conv+patch codegen |
| quant 权重(NF4/INT4) | per-channel dequant+GEMM 融合 | INT4 template M2 |
importer 不保证覆盖全部 PyTorch op;未识别 op → decompose 或 escalate 17 决策树。
3.3c 具身 P0/P1 算子覆盖路线(承接 21 ADR-049)
| 阶段 | 里程碑 | 算子/能力 | 获取方式 | 验收 |
|---|---|---|---|---|
| M1 | Demo tiny-gemm | linalg.matmul → DSA GEMM;INT4 GEMM stub | 16 章 codegen + 04-kernels 手写对照 | bit-exact ISS |
| M2 | 基线 VLA 子图 | fused MHA/SDPA;KV;LN;Softmax;FC;INT4/NVFP4 GEMM | codegen + 1 手写 fused attention | vs PyTorch golden |
| M3 | π0/OpenVLA 块 | flow/diffusion loop;cross-attn;ViT conv;multi-camera batch | codegen loop tiling + elite attention | E2E latency |
| M3+ | 1-NFE 快路径(OFP/OneDP) | 单步 flow 替代 5–10 步 loop | loop→single dispatch 融合 | vs 多步数值 |
| M4 | 感知+多模型 | 2D conv 扩展;chunk gather;INT4 GEMM | codegen + 19 章 quant kernel | rollout |
| M5 | 客户 POC | Model Zoo op 覆盖报告 | 模板库 + autotune(18) | 27 章 benchmark |
3.3d P0/P1/P2 优先级的排序逻辑
上表的阶段划分不是拍脑袋,而是三条排序准则的叠加。理解这套逻辑,才能在新算子来临时自己判断该塞进哪个 Gate:
| 准则 | 含义 | 抬升优先级的信号 |
|---|---|---|
| ① 算力占比 | 该算子/融合模式吃掉多少浮点运算 | GEMM/FFN/Attention 占 70%+ → 必然 P0 |
| ② 路径关键性 | 是否在端到端延迟的关键路径上、是否阻塞 Gate 验收 | flow loop 是 chunk 延迟主体 → P0/M3 |
| ③ 覆盖广度 | 有多少目标模型依赖它 | GEMM/MHA/LN 全模型共用 → P0;3D attn 仅世界模型 → P2 |
三条准则叠加,就能解释表里几个「反直觉」的排序:
- 为什么 INT4/NVFP4 GEMM 是 M2 的 P0,而非 M4 量化补丁? 因为准则 ① + ③ 同时命中:量化 GEMM 是算力大头(端侧 INT4 是唯一能让 7B VLA 塞进 ≥8GB 主存并跑到目标延迟的路径,见 21 章),又被几乎所有目标模型共用。若拖到 M4,M2/M3 的 VLA 子图根本跑不出可对标 GR00T 的延迟——它是能力基座,不是优化项。
- 为什么 fused SDPA(FlashAttention 形态)是默认而非可选? 准则 ① + ②:Attention 是算力第二大头,且不融合就会因反复读写 HBM 中间矩阵(见 21 章 KV-cache)撑爆带宽,直接卡在延迟关键路径上。
- 为什么 3D conv / video attn 是 P2? 三条准则全落空:仅世界模型(21 章界定为端侧基线阶段边界外)依赖,当前算力/覆盖/路径都不关键——但 IR 须预留 first-class loop 表达(21 章不可逆点),避免将来无法表达而返工。
3.4 手写兜底 vs codegen 决策树
新算子出现
├─ 标准 Linalg 可表达? ──Yes──► MLIR codegen + auto-tune(18)
│ No
├─ Triton 生态已有(FlagGems/vLLM)? ──Yes──► Triton→Linalg→DSA(15 ADR-027 可选)
│ No
├─ 算力占比 >5% 或 延迟关键路径? ──Yes──► 手写 DSA intrinsics(04-kernels 风格)
│ No
└─ 降级 CPU/DSP 或 复合 decompose
P0 强制 elite 清单(~5–8 个):INT4/NVFP4 GEMM、fused MHA/SDPA、flow-loop fused block、ViT patch+conv 融合、chunk gather/scatter。
读这棵树的关键:它是按「省人力」的优先级从上往下降级的。能 codegen 就绝不手写(数量尺上把长尾自动化);Triton 生态已有就复用(借外部人力);只有当「算力占比 >5% 或在延迟关 键路径」时,才动用最贵的手写 DSA intrinsics(算力尺上砸热点)。最后的 decompose/CPU 是兜底——保证功能正确、绝不 silent fallback,但明确接受性能损失。
3.5 多相机 ViT 与 batch 策略
| 配置 | 算子形态 | 调优要点(18) |
|---|---|---|
| 1–3 路 RGB | [B_cam, C, H, W] batch 或 concat | conv tile + DMA 双缓冲 |
| wrist + head | 异构分辨率 | per-view dispatch + 共享权重 |
| depth 可选 | extra channel / 独立 stub | P1 |
GR00T/Cosmos 类 多传感器 须 单 graph 多输入;避免 per-camera 独立 launch(09 launch overhead)。
3.6 LLM-Native 算子开发(衔接 15 ADR-033)
- KernelAgent/AutoKernel 范式:Profile(ISS/硅)→ 生成候选 → 执行验证 → 迭代。
- 具身场景:用 OpenVLA/π0 子图 作 internal KernelBench;ground truth 在 ISS。
- RAG:ISA intrinsics 手册 + 已有模板 → Agent 生成 Ascend C 式 intrinsics 代码。
3.7 趋势判断
- 算子归编译仍是方向,但 5–20% 手写 elite 不可消除(NVIDIA/华为均如此)。
- 融合 > 单算子:VLA 性能靠 attention+FFN+LN 融合、flow loop 融合(21 章 IR 原语)。
- 量化算子一体化:INT4/NVFP4 GEMM 是 P0(M2),非 M4 补丁(19 章);对标 GR00T nvfp4/fp8。
- 模板跨代:编译兼容(07)→ 参数化 tile template 随 ISA 扩展重编译,非二进制复用。
- 1-NFE 蒸馏成熟(OFP/OneDP):compiler 须 多步 loop + 单步快路径 双 IR 原语(21 章)。
- fused SDPA/FlashAttention 形态 为 MHA P0 默认,非可选优化。
3b. 由演进反推的诉求
| 演进 | 算子策略响应 |
|---|---|
| π0 5 步→1-NFE(OFP/OneDP) | loop 变单次;手写 loop 内核降优先级 |
| QVLA 混合 bit | per-channel quant GEMM 模板 |
| 世界模型(3D attn) | P2;规模化阶段 |
| 新 attention 变体 | 自定义 op + codegen 扩展(15 ADR-028) |
4. 候选方案与对比矩阵
| 候选 | 性能/能效 | 成本 | 风险 | 生态成熟度 | 演进性 | 可驾驭度 | 小结 |
|---|---|---|---|---|---|---|---|
| A. MLIR codegen 为主 + 手写 P0 elite | 5 | 4 | 3 | 3 | 5 | 4 | 建议方案 |
| B. 重度算子库(类 cuDNN) | 4 | 2 | 4 | 2 | 2 | 2 | 人力爆炸 |
| C. Triton 为主 | 4 | 3 | 4 | 4 | 4 | 3 | 15 章:可选,非核心 |
| D. 地平线式全编译零手写 | 3 | 4 | 5 | 2 | 1 | 3 | VLA 不适用 |
建议方向:A,Triton(C) 按客户迁移 ROI 增量投入;初判排除 D(地平线式全编译零手写)。
5. 关键权衡、风险与依赖
- Codegen 成熟度 vs 上市时间:M3 前 P0 必须有 手写 GEMM/Attention 兜底各一。
- 融合 pass 复杂度:flow loop 融合错误 → 静默数值错;需 lit + rollout 双验。
- 与 18 章:手写模板提供 auto-tune 搜索空间上界。
- 与 Demo
04-kernels:手写 GEMM 是 codegen 的 golden + 性能 floor。
6. 结论与待决项
6.1 初步结论
- MLIR structured codegen 为主 + P0 elite 手写(~5–8 个内核模板);含 INT4 GEMM、fused SDPA、flow-loop。
- M1–M3 路线:tiny-gemm+INT4 stub → fused MHA/SDPA → flow loop/cross-attn/multi-camera ViT;对齐 21 P0。
- GR00T 式混合:DiT/动作头 AOT IREE;backbone 可 PyTorch 过渡;中间 tensor dmabuf 共享。
- 1-NFE 快路径(M3+):OFP/OneDP 单步 dispatch 与多步 loop 共存。
- Triton:可选迁移层(15 ADR-027);不作为性能主路径。
- AI-Native:ISS-grounded Agent 生成 intrinsics 候选(15 ADR-033)。
- LeRobot importer:manifest 驱动算子边界;未识别 op 走决策树,非 silent fallback。
- 反模式:地平线式"新算子只能 CPU"——与 VLA 演进冲突。
6.2 待决项
- P0 fused attention 手写 vs codegen-only 的 M3 决策线。
- Triton 投入:是否 M4 前接 FlagGems 子集。
- INT4 GEMM 手写模板 vs 纯 codegen 第一版时间。
6.3 ADR 候选
- ADR-054 算子获取策略:codegen 为主 + elite 手写兜底;算力覆盖目标 ≥80% codegen、≤20% 手写;长尾 decompose 或 CPU。
- ADR-055 具身算子覆盖里程碑:M1 GEMM+INT4 stub;M2 fused MHA/SDPA+INT4/NVFP4 GEMM;M3 flow loop+cross-attn+multi-camera ViT;M3+ 1-NFE 快路径;M4 扩展 conv;对齐 21 ADR-049 P0/P1。
- ADR-056 Triton 边界:可选;Triton→Linalg→DSA;仅当客户迁移/FlagGems ROI 明确时投入;性能/确定性主路径仍 codegen+手写。
- ADR-057 模板沉淀:手写内核 参数化 tile template;编译兼容(07)跨代重编译;入 Model Zoo 性能基线(26 章)。
7. 端→边→中心演进影响
- 端侧:融合+INT4 模板;边/中心:更大 tile + batch>1 模板变体。
- 不可逆点:DSA intrinsics 命名与 tile 约束随 ISA 冻结 → template 参数化,避免硬编码 shape。
深入思考
下面三题每题先给题干,再用
<details>折叠一份图文并茂的参考答案。建议先合上答案自己想 3 分钟,再展开对照。
思考题 1:为什么 20% 的算子占了 80% 的算力
结合 2.3 节的两把尺子与 3.4 节决策树,论证「手写 ≤20% 算子数量却承载 ~80% 算力」为什么不是矛盾,而是同一分布的两种度量。用一个 π0 级 VLA 子图的数量级估算,把这本账算一遍:如果把稀缺的手写人力平摊到所有算子上,会浪费在哪里?
展开参考答案(含数量-算力双尺分布图 + 算一遍)
结论:算子在「数量」和「算力」两把尺子上服从的是一条高度倾斜的长尾分布——极少数热点算子(GEMM/Attention)吃掉绝大部分浮点运 算,而海量长尾算子(reshape/cast/elementwise)数量众多却几乎不耗算力;所以「手写覆盖数量上的 20%、却拿下算力上的 80%」不是矛盾,而是把稀缺人力精准砸在了分布的头部。
用具体数字算一遍(以一个 π0 级 VLA 子图为例,数量级估算):
- 假设 lowering 后子图有约 500 个算子实例,去重后约 60 种不同的算子/融合模式。其中「值得手写的热点模式」约 8~12 种(GEMM、FFN 的两个 GEMM、fused SDPA、flow-loop block、ViT patch+conv、chunk gather 等)——占种类数量的 ~15%~20%。
- 算力账:一层 Transformer 的 FLOPs 主要在两处——Attention 的 QKV/输出投影 + FFN 的两个 GEMM(隐层通常 4× 宽),二者相加吃掉单层 ~85% 的 FLOPs;LayerNorm、Softmax、残差 add、激活函数这些逐元素算子加起来往往 < 10%。ViT 前端的 conv/patch embed 同理是热点。把整张子图汇总,GEMM + Attention ≈ 80%+ 算力。
- 反证:若把手写人力平摊——假设有 5 个 kernel 工程师·季度的预算。平摊到 60 种算子,每种约 0.08 人·季度,连一个 fused SDPA 都调不出峰值;而那几百个 reshape/cast 本来 codegen 就能做到内存带宽上界,手写它们一点算力都省不下来(它们本就不是瓶颈)。人力全浪费在长尾上,热点反而没人调 → 端到端延迟纹丝不动。
- 正解:集中投放——同样 5 人·季度全砸在 8~12 种热点上,每种 ~0.5 人·季度,足以把 INT4 GEMM、fused attention 调到接近 ISS 峰值。手写覆盖了数量的 20%,却直接决定了 80% 算力的实际利用率——这才是决策树(3.4)从上往下降级、只在「算力 >5% 或延迟关键路径」才手写的经济学根据。
一句话:两个 80/20 分别站在数量尺和算力尺上,指向的却是同一批头部算子;策略的全部艺术就是让这两把尺子在头部对齐——codegen 扫平数量长尾,手写攻克算力头部。(回链:见 2.3 节两把尺子、3.4 节决策树、ADR-054。)
思考题 2:P0/P1 算子优先级如何排
来了一个新算子(比如某个 VLA 新变体引入的 grouped-query cross-attention 变体),你要决定它进 M2(P0)、M4(P1) 还是 P2 预研。结合 3.3d 节的三条排序准则,给出你的判断流程;并解释为什么「INT4/NVFP4 GEMM 是 M2 的 P0」而不是像传统那样当作 M4 的量化后处理补丁。
展开参考答案(含三准则打分决策图 + 对比表)
结论:优先级不是按「算子新不新」排,而是按「算力占比 × 路径关键性 × 覆盖广度」三条准则叠加打分——三者任一强命中就上抬。INT4/NVFP4 GEMM 之所以是 M2 的 P0,正因为它同时命中「算力大头」和「全模型共用」两条,是让 7B VLA 能在端侧跑起来的能力基座,而非可选的事后优化。
判断流程(套 3.3d 三准则):
- 量算力占比:cross-attention 属 Attention 家族,单次占比不低,但若该变体只在某一层出现,整体占比要实测 ISS profile 才能定——先给「候选高」。
- 看路径关键性:它在 flow-loop / chunk 生成的关键路径上吗?若是,直接上抬(准则②)。
- 看覆盖广度:只有这个新 VLA 用,还是多个目标模型共用?若仅个别模型,准则③ 偏弱,不足以单独推到 P0。
- 综合判定:①②强命中 → 倾向 P0,但落地可分两步——先用 codegen + decompose 保证功能(4 周接入红线,15 ADR-028),ISS profile 确认它确实是热点后,再决定是否升级为 elite 手写(3.4 决策树的「算力 >5% 或延迟关键」分支)。
为什么 INT4/NVFP4 GEMM 是 M2 的 P0(对比传统做法):
| 维度 | 传统「量化=后处理补丁」视角 | 本方案「量化 GEMM = P0 基座」视角 |
|---|---|---|
| 算力占比(准则①) | 忽略——先跑 FP16 再说 | GEMM 是算力第一大头,量化直接决定峰值利用率 |
| 路径关键性(准则②) | 量化是可选优化,不阻塞功能 | 端侧 7B VLA 不 INT4 就塞不进 ≥8GB 主存,更跑不到对标 GR00T 92ms 的延迟(21 章) |
| 覆盖广度(准则③) | 只影响追求极致的少数场景 | 几乎所有目标模型(OpenVLA/π0/GR00T)端侧都依赖低比特 GEMM |
| 落地时机 | M4 补丁 | M2 P0——与 fused MHA/SDPA 同期 |
三条准则全部强命中,所以它不是「优化项」而是「能力项」:若拖到 M4,M2/M3 的 VLA 子图根本跑不出可对标的延迟,整条里程碑链条会在 M3 的 E2E latency Gate 上翻车。这就是「量化算子一体化(3.7 趋势 3)」的调度含义——把量化 GEMM 当地基浇,而不是当装修补。(回链:见 3.3d 三准则、3.3c 里程碑表、ADR-055、21 章 P0 列表。)
思考题 3:Triton 作为迁移层的性能口径
有人主张「全用 Triton 写算子,一套代码跨 GPU / 昇腾 / 摩尔线程,省掉手写」。结合 3.2 节横向规律 2 与 决策树(3.4),界定 Triton 作为「迁移层」的性能口径:它在什么口径下能拿到几成峰值?为什么它替代不了 P0 热点的手写 elite?什么场景下用它才划算?
展开参考答案(含 Triton 迁移层定位图 + 性能口径对比表)
结论:Triton 的价值口径是「用一套可移植 DSL 换取长尾/新算子的快速跨硬件覆盖」,它能把长尾算子拉到「可用」水平(接近内存带宽上界、或峰值的六七成),但在 P0 热点(GEMM/fused attention)上,受限于其抽象层次拿不到最后那两三成峰值——那部分要靠贴着 ISA 的手写 elite。所以 Triton 是『迁移层/兜底层』,不是『性能主路径』;只有当客户迁移 ROI 明确、或 FlagGems/vLLM 生态已有现成 kernel 时投入才划算。
性能口径对比(同一算子在三条路径上的典型定位):
| 口径维度 | 纯 codegen | Triton(迁移层) | 手写 elite |
|---|---|---|---|
| 峰值利用率(P0 热点) | 中(结构化 GEMM 尚可,fused attn 偏弱) | 中高,常达峰值 60%~80% | 高,90%+ |
| 峰值利用率(长尾算子) | 高(本就带宽受限,codegen 已达上界) | 高(与 codegen 相当) | 无必要手写 |
| 跨硬件可移植 | 依赖后端成熟度 | 一套 kernel 多后端(Triton→Linalg→厂商 IR) | 不可移植,逐硬件重写 |
| 人力成本 | 零额外 | 低(写 Python 风格 DSL) | 最高(ISA 专家·季度) |
| 确定性/可控性 | 高 | 中(依赖 Triton 后端调度) | 最高 |
为什么替代不了 P0 热点的手写:Triton 的抽象(block-level 编程 + 自动调度)刻意隐藏了很多硬件细节——这正是它可移植的原因,也是它拿不到最后两三成峰值的原因。fused SDPA、INT4 GEMM 这类 P0 热点,峰值往往压在极致的 tiling、bank conflict 规避、寄存器/片上 buffer 精确排布、异步搬运与计算的显式重叠(昇腾尤甚,见 21 章 DSA 显式流水)上;这些正是 Triton 为了可移植而抽象掉的层次。规律 2 说得很直白:昇腾/摩尔/FlagTree 都做 Triton→Linalg,但都把它定位为迁移层而非核心——性能天花板仍靠 Ascend C / CUTLASS 式手写。
什么场景用它才划算(ROI 判断):
- 划算:① 客户带着一堆 Triton 写的自定义算子(vLLM/FlagGems 生态)要迁到我们芯片——直接过 Triton→Linalg→DSA,省掉逐个手写重写;② 新 attention 变体/长尾算子要快速覆盖、性能只需「可用」;③ 作为手写 elite 上线前的过渡兜底。
- 不划算:P0 热点追极致峰值(该手写)、或后端 Triton 支持尚不成熟时强上(会卡在调优)。
一句话口径:Triton 换的是**「覆盖速度 × 可移植性」,不是「峰值算力」**;把它放在决策树(3.4)的第二档——codegen 之下、手写之 上——按客户迁移 ROI 增量投入,恰如其分。(回链:见 3.2 规律 2、3.4 决策树、候选 C、ADR-056。)
延伸阅读
1. 核心文档 / 白皮书
- IREE Structured Codegen & HAL 文档(iree.dev)— 理解「structured codegen + microkernel 兜底」如何在 MLIR 同源栈里落地。
- NVIDIA CUTLASS / cuDNN / TensorRT 文档— GEMM/Attention 手写 elite kernel 与库调优的一手参照;GR00T DiT 的 TRT engine 路径。
- 华为 Ascend C 编程指南 + CATLASS 模板 + Triton-ascend(2025-03 开放生态)— DSA 手写 intrinsics 与 Triton→Linalg→AscendNPU IR 的官方阐述。
- Triton 官方文档与教程(triton-lang)— 看
python/tutorials/03-matrix-multiplication.py,体会 block-level 抽象为何可移植、又为何拿不到最后几成峰值。
2. 相关高 Star 仓库与源码必读路径
openai/triton— 看python/tutorials/与third_party/,理解 Triton IR 如何下降到不同后端;FlagOpen/FlagGems是评估「客户迁移 ROI」的现成 Triton kernel 来源。NVIDIA/cutlass— 看include/cutlass/gemm/,理解 P0 热点手写到峰值需要哪些 ISA 级排布。iree-org/iree— 看compiler/src/iree/compiler/Codegen/,structured codegen 与 microkernel 兜底的分界。
3. 优质博客 / 公开课
- OpenAI「Introducing Triton」与各厂商 Triton 后端接入博客,建立「迁移层」定位的直觉;华为昇腾社区「CANN 算子开发」「Ascend C」系列,理解 DSA 显式流水下手写 elite 的必要性。
- 21 章具身模型支持洞察 + 15/16 章编译器洞察——本章的上下游,读懂 P0 算子从何而来、往何处 lowering。
上游 → 21 具身模型支持洞察:P0/P1 算子列表与 VLA 模型族的来源。 下一篇 → 18 Auto-tune 洞察:手写模板如何为自动调优提供搜索空间上界,把「参数化 tile template」跑出每代 ISA 的最优配置。
附:信息来源
区分公开/估计;参考时间 2026-06。
- IREE structured codegen / HAL:iree.dev;12/15/16 章。[公开]
- NVIDIA cuDNN/TensorRT/GR00T DiT TRT + nvfp4/fp8:NVIDIA Isaac GR00T optimization docs;ModelOpt。[公开]
- LeRobot manifest / action_expert:github.com/huggingface/lerobot;21 章 ADR-046。[公开]
- OFP/OneDP 1-NFE:21 章;arXiv 2025–2026。[公开]
- 华为 Ascend C/CATLASS/Triton-ascend:华为 202503 开放生态;15 章。[公开]
- Qualcomm QNN op support:Qualcomm AI Engine Direct docs;ExecuTorch QNN。[公开]
- 地平线 BPU 算子策略:07 章天工开物引用。[公开]
- KernelAgent/AutoKernel:15 章 ADR-033 引用。[公开]
- π0.7 / GR00T N1.7 GA 时效:Physical Intelligence pi.website;NVIDIA Isaac 路线图,roadmap 以官方为准。[公开]
- 21 章具身 P0 算子列表;Demo
04-kernels/03-mlir-compiler。[内部/公开]