183 lines
8.3 KiB
Markdown
183 lines
8.3 KiB
Markdown
# 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（推理编译独立成领域）](https://arxiv.org/pdf/2512.23236v1)
|
||
- [TIRx：TVM 上的新 kernel DSL（2026-06）](https://tvm.apache.org/2026/06/22/tirx)
|
||
- [vLLM 切换 Triton MoE backend（PR #44220）](https://github.com/vllm-project/vllm/pull/44220)
|
||
- [AI Inference Engines 2026 全景](https://www.youngju.dev/blog/culture/2026-05-16-ai-inference-engines-2026-vllm-sglang-llama-cpp-tgi-tensorrt-llm-mlx-mistralrs-deepspeed-aphrodite-deep-dive.en)
|
||
- [KernelEvolve：Meta 生产级 LLM kernel 生成](https://www.ivoox.com/llm-inference-compiler-panorama-research-and-engineering-evolution-audios-mp3_rf_176267639_1.html)
|
||
|
||
## 相关链接
|
||
|
||
- [[大模型架构基础]] — 编译的对象：Transformer 结构
|
||
- [[DeepSeek V4 系列]] — 最新模型的 FP8/NVFP4、DSpark 都是 kernel 层优化
|
||
- [[FFN 前馈网络详解]] — MoE/SwiGLU 是最热的 kernel 优化对象
|
||
|
||
---
|
||
|
||
*最后更新：2026-08-05*
|