8.3 KiB
8.3 KiB
AI 编译器现状与前景
2026-08-05 分析笔记。源自一个判断：大模型时代模型结构收敛、数量变少，传统 AI 编译器必要性下降，"只需适配特定子网络深入优化即可"——这个判断对一半。
背景：原判断
作者背景：做过编译器工作，TVM 0.6 魔改 + 接触过 MLIR。
原判断：
- 大模型时代，模型结构越来越固定（decoder-only Transformer 一统）
- 模型数量远少于传统 CNN 时代
- 传统 AI 编译器（通用图级自动优化）必要性下降
- 只需适配特定子网络，深入优化即可
一、判断对的部分：通用图编译器退潮
在图级通用编译这一层，判断成立，有实证：
OctoML 案例（最重要的证据）
- NVIDIA 2024年5月收购 OctoML（TVM 团队），官方理由是"拿到能把固定硅片上最后几个点性能挤出来的人"
- 结果相反：编译流水线产品被逐步废弃，客户流向 vLLM 等 serving-first 引擎
- 结论：编译优先输给了服务优先——生产 LLM 系统真正花时间的是低 TTFT、持续吞吐、API 契约，而不是"把模型编译成最优 artifact"
AOT → JIT 的转移
| AOT（传统编译器） | JIT（2026 主流） | |
|---|---|---|
| 模式 | 模型进 → 优化 passes → 编译产物出 | 运行时按需编译 kernel，首次启动缓存 |
| 代表 | TVM、TensorRT-LLM | FlashInfer、DeepGEMM、Triton |
| 部署速度 | TensorRT-LLM 构建 engine 需数小时 | vLLM 加载 HF 模型只需几分钟 |
CNN vs LLM 的模型量
- CNN 时代：几百上千种网络结构 → 通用图编译"一套处理任意图"有价值
- LLM 时代：decoder-only 一统，结构高度收敛 → 为"任意图"做的通用优化确实浪费
二、判断的偏差："AI 编译器"分裂成了四个层
核心偏差：把"AI 编译器"等同于 TVM 0.6 式的通用图编译器。 实际 2026 年编译器工作量没有变少，而是转移到四个更深更专的层。
层 1：Kernel 层——最热战场
LLM 时代性能关键算子的集合比 CNN 时代更丰富：
| 算子/技术 | 为什么难 |
|---|---|
| FlashAttention / MLA | 每次新注意力变体 = 新 kernel 的数月专家工作 |
| MoE 路由 + GEMM | 专家调度、跨卡通信；vLLM 的 MoE backend 从 FlashInfer 切到 Triton（H200 更快） |
| FP8 / FP4 / NVFP4 量化 GEMM | 新数值格式把旧 cost model 和调度规则全部作废 |
| 长上下文 / PagedAttention | 变长序列、内存受限的 kernel 调度 |
当前 Kernel 层的生态谱系（从高层 DSL 到底层）：
Triton（事实标准，高层 tile 抽象）
↓
TileLang / Helion（布局自动推断）
↓
CuTe DSL（CUTLASS v4，可组合布局抽象）
↓
TIRx / TLX（硬件原生，显式 orchestration）
↓
CUDA / PTX（手工极限优化）
层 2：推理引擎层——"编译器/运行时边界模糊"
LLM 推理编译已被定义为独立学科：传统编译器五层框架（图→kernel→内存→运行时调度）被在线调度吸收。
- 动态形状（变长序列、KV cache）
- chunked prefill、continuous batching
- 这些调度问题本质上变成了编译问题
代表：vLLM、SGLang、TensorRT-LLM、llama.cpp。
2026 实战数据：
- vLLM V1 引擎比 V0 快 1.5~2×（异步调度、chunked prefill、torch.compile 集成）
- vLLM 默认 MoE backend 从 FlashInfer 切到 Triton：H200 上 57,821 vs 55,700 tokens/s
- TensorRT-LLM 高并发（32+ 并发）时仍快 10~30%，但需数小时 build engine
层 3：硬件使能层——传统编译器反而吃香
反转点：通用模型少，但硬件爆发式碎片化。
- NVIDIA Blackwell、AMD MI300X、华为昇腾、寒武纪、国产 ASIC
- 非 NVIDIA 芯片没有厂商 kernel 库 → 编译栈是必需的
- 国内芯片编译团队从"建设期"进入"换血期"：要求 codegen 优化、内存规划、target-specific 调度的深度人才
- TVM/MLIR"一套栈、多后端"思路在这一层真正兑现价值
层 4：LLM 生成 kernel——角色重塑
2025-2026 最大变量：LLM agent 成为 kernel 生成器和编译器优化器。
| 系统 | 结果 |
|---|---|
| KernelEvolve（Meta，已部署） | 480 个算子-平台组合 100% 正确率，1.25~17× 加速，开发时间从数周降到数小时 |
| KernelBench | LLM kernel 能力基准 |
| AutoTriton / TritonRL / KernelLLM | RL 驱动的 Triton 生成 |
| Compiler-R1 / REASONING COMPILER（NeurIPS 2025） | RL 驱动的编译自动调优 |
意义：未来编译器工程师核心技能从"手写 kernel"变为"引导 agent 搜索 + 验证正确性 + 设计搜索空间"。
三、反驳"只需适配特定子网络"
策略对，深度被低估：
- "只优化少量关键算子"是对的——这正是 vLLM/TensorRT-LLM 的做法
- 但"只需"严重低估深度：把 FlashAttention-4 或 MoE kernel 在 B200 调到峰值是数周专家工作
- 动态形状是关键分水岭：静态形状下融合是"规则问题"，动态形状下是"开放问题"（广播开销、索引计算、codegen 分支）。2026 人才市场把"动态形状编译"列为 LLM 推理团队硬性要求
- 值钱的是精通动态形状 pass 设计、memory-bound 优化、新数值格式的人，不是"会写 dialect 定义和基本 lowering"的人
MLIR 生态（2026 年已是"编译器基础设施的 Linux"）：
- torch.compile (Inductor) 是 MLIR 思想设计
- Google XLA 已迁移到 MLIR 底层
- IREE 是纯 MLIR 栈
- 需求已从"懂 dialect 机制"转向"自定义 pass 流水线设计、图融合策略、跨 IR 优化"
四、前景判断（2026）
通用图编译器（TVM 全自动调优式） ↘ 退潮，仅存于特定 niche
Kernel DSL（Triton/CuTe/TileLang） ↗ 繁荣，LLM 推理事实标准
推理引擎内部编译（vLLM/SGLang） ↗ 最热，编译器×分布式交叉岗位稀缺
硬件使能编译栈（昇腾/AMD/寒武纪） ↗ 确定性增长，国产芯片刚需
LLM agent 生成 kernel ↗ 爆发前夜，重塑工程师角色
关键结论
AI 编译器没有死，死的是"通用图编译"这个窄定义。
- AI 推理支出 2026 年已超过训练
- 编译器工程师是 AI 基础设施链上最稀缺岗位之一
- 能力栈从"覆盖任意图"转向"少量关键算子做到极致的深度 + 动态形状 + 新硬件 + 新数值格式"
五、职业建议（针对本笔记作者背景）
作者技能：TVM 0.6（Relay/TIR/AutoTVM 时代）+ MLIR。
| 技能 | 2026 年变现路径 |
|---|---|
| MLIR 了解 | 深入 torch.compile/Inductor 的 pass 设计、动态形状融合 |
| TVM 调度/调优思想 | 转向 Triton/CUTLASS——AutoTVM/Ansor 的调优心智模型可迁移 |
| 编译原理底子（IR/pass/调度） | vLLM/SGLang 内部，编译器×分布式调度是稀缺交叉 |
| 多后端思维 | 国产芯片（昇腾 CANN、寒武纪）使能，"适配子网络"直觉在此是核心竞争力 |
一句话建议：
不守"通用编译框架"这条船；把"适配特定子网络深入优化"做深到极致——但"深"是指动态形状 + 新数值格式 + 新硬件架构三个维度，而不是 TVM 0.6 时代的静态图自动调优。编译功底在这三个维度上直接可迁移，是"只会写 PyTorch 的 ML 工程师"够不着的护城河。
参考资料
- LLM Inference Compiler Panorama（推理编译独立成领域）
- TIRx：TVM 上的新 kernel DSL（2026-06）
- vLLM 切换 Triton MoE backend（PR #44220）
- AI Inference Engines 2026 全景
- KernelEvolve：Meta 生产级 LLM kernel 生成
相关链接
- 大模型架构基础 — 编译的对象：Transformer 结构
- DeepSeek V4 系列 — 最新模型的 FP8/NVFP4、DSpark 都是 kernel 层优化
- FFN 前馈网络详解 — MoE/SwiGLU 是最热的 kernel 优化对象
最后更新：2026-08-05