自动调优

3 秒看懂

一句话：自动调优是让编译器/框架”自动试跑”成百上千种实现方案，找到在特定硬件上最快的那一套配置——本质是用搜索代替人工经验。

类比：厨师接到一道菜，要决定刀工大小、火候、翻炒时长。经验老道的大厨凭直觉选，自动调优则是让新手把所有组合都试一遍，用秒表计时，选出最优解。

3 分钟产业解释

为什么需要自动调优？

深度学习算子（如卷积、矩阵乘、注意力）在不同硬件上的”最优实现”天差地别：

人工调优的痛点：

• 不同 GPU 架构（Ampere vs Hopper vs CDNA）最优配置不同
• 不同输入形状（batch size、序列长度）最优配置不同
• 一个大模型有数百个 unique 算子，逐一手动调优不现实

自动调优的价值：让编译器自己搜索最优配置，开发者只需定义”正确性约束”。

产业影响

• 降低硬件适配成本：新芯片上市后，无需等厂商手写优化库，编译器可自动适配
• 释放异构算力：CPU/GPU/NPU/FPGA 统一调度，每种硬件自动找到最优实现
• 加速模型迭代：新架构（如 MoE、稀疏注意力）可快速获得高性能实现

15 分钟专家深入

核心工作流

┌─────────────────────────────────────────────────────┐
│                   Auto-Tuning Pipeline               │
├─────────────────────────────────────────────────────┤
│  1. 定义搜索空间 (Search Space)                       │
│     └─ 所有可能的优化配置集合                          │
│  2. 采样候选方案 (Proposal)                           │
│     └─ 从搜索空间中选择配置                            │
│  3. 编译 & 执行 (Build & Run)                         │
│     └─ 生成代码、实际跑 benchmark                      │
│  4. 评估性能 (Measure)                               │
│     └─ 收集 latency/throughput 等指标                 │
│  5. 指导下一轮搜索 (Guide)                            │
│     └─ 更新 cost model 或搜索策略                      │
│  6. 迭代至收敛或预算耗尽                                │
└─────────────────────────────────────────────────────┘

三大技术范式

范式 1：基于模板的调优 (Template-based)

代表：AutoTVM (TVM)

┌─────────────────────────────────────┐
│         Template-Based AutoTVM      │
├─────────────────────────────────────┤
│  人工定义 Template（带参数槽位）      │
│         ↓                           │
│  搜索算法填充参数值                   │
│         ↓                           │
│  代码生成 + 实测性能                  │
│         ↓                           │
│  Cost Model 预测未跑方案             │
│         ↓                           │
│  重复至收敛                          │
└─────────────────────────────────────┘

优点：搜索空间受模板约束，质量上限高（人工经验注入） 缺点：需要为每类算子写模板，扩展性受限

范式 2：基于调度原语的自动搜索 (Schedule-Primitives)

代表：Auto-Scheduler (TVM, 原 Ansor)

• 不需要模板，从算子的计算描述自动派生搜索空间
• 使用随机抽取 + 阶段规则（Sketch）生成合法调度
• Cost Model 使用基于 XGBoost（梯度提升决策树）的模型预测性能

优点：无需人工模板，覆盖更广的搜索空间 缺点：搜索空间爆炸，需要更智能的引导

范式 3：基于 DSL 的自动调优

代表：Triton (OpenAI)、Halide

# Triton 风格
@triton.jit
def matmul_kernel(A, B, C, M, N, K,
                  BLOCK_M: tl.constexpr,   # 自动调优参数
                  BLOCK_N: tl.constexpr,   # 自动调优参数
                  BLOCK_K: tl.constexpr):  # 自动调优参数
    # ... kernel 逻辑 ...

用户标注哪些是可调参数，框架自动遍历或搜索。

搜索算法分类

产业实践：多数系统采用”Cost Model 预筛 + 少量实测验证”的混合策略，平衡搜索效率与准确性。

技术原理（最深）

搜索空间定义

自动调优的核心是定义合法且有意义的配置空间。以矩阵乘 C[M,N] = A[M,K] × B[K,N] 为例：

搜索空间维度：
├── Tiling
│   ├── block_m ∈ {64, 128, 256}
│   ├── block_n ∈ {64, 128, 256}
│   └── block_k ∈ {16, 32, 64}
├── Unrolling
│   └── unroll_factor ∈ {1, 2, 4, 8}
├── Vectorization
│   └── vec_width ∈ {4, 8}  (float 时为 16/32 字节)
├── Memory Scope
│   └── use_shared ∈ {True, False}
│   └── use_register_tiling ∈ {True, False}
└── Parallelism
    └── warp_m × warp_n ∈ {(1,4), (2,2), (4,1)}

总配置数 = |block_m| × |block_n| × |block_k| × ...
         = 3 × 3 × 2 × ... × N
         = 数万至数十万种可能

Cost Model 训练

以 TVM 的基于 XGBoost 的 Cost Model 为例：

输入特征：
├── 循环结构特征（嵌套深度、是否有 reduction）
├── 内存访问特征（步长、是否连续、缓存命中率估算）
├── 计算密度特征（FLOPs / 内存字节 = Arithmetic Intensity）
└── 硬件参数（SM 数量、共享内存大小、寄存器文件大小）

输出：预测的执行时间 (latency)

训练数据：(configuration, actual_latency) pairs
          从少量实际执行中收集

关键技术：Cost Model 不需要非常准确，只需要能正确排序（哪个配置更好），因此用 ranking loss 训练更有效。

搜索策略（以 Auto-Scheduler 为例）

Auto-Scheduler 使用 Sample-then-Evaluate 策略：

Step 1: Sketch Generation（草图生成）
  └─ 使用一组预定义规则（Rules）从计算图派生调度骨架
  └─ 例如：是否使用 split、是否 reorder、是否 fuse

Step 2: Parameter Population（参数填充）
  └─ 在草图的槽位中随机采样参数值
  └─ 约束合法性（如 shared memory < 硬件限制）

Step 3: Cost Model 预筛选
  └─ 从大量候选中选出 Top-K 个最有希望的配置

Step 4: 实测验证
  └─ 对 Top-K 配置编译并实际执行，记录真实 latency

Step 5: 更新 Cost Model
  └─ 用新的 (配置, 性能) 对更新模型
  └─ 重复 Step 3-5

与硬件特性的交互

自动调优需要感知硬件限制：

约束示例（NVIDIA GPU）：
├── Shared Memory: 每 SM 有限（具体大小因架构而异，详见硬件手册）
│   └─ tiling 参数必须满足: block_m × block_n × dtype_size < shared_mem_limit
├── Registers: 每线程寄存器数量有限
│   └─ 过度展开 (unroll) 寄存器溢出 → 性能暴跌
├── Warp Divergence: 分支效率
│   └─ 某些配置会导致 warp 内线程走不同分支
└── Occupancy: 每 SM 并发 block/warp 数
    └─ 寄存器/共享内存占用过高会降低占用率

技术演进史

趋势：从”离线搜索 → 回放”向”即时调优 (Just-in-Time Tuning)“演进，支持动态 shape 和在线适应。

技术路线对比

补充对比：厂商原生调优

上下游

上游：自动调优依赖什么

┌─────────────────────────────────────────────────┐
│                   上游依赖                        │
├─────────────────────────────────────────────────┤
│  硬件描述 / 性能计数器                            │
│    └─ GPU: CUDA Profiling Tools, rocprofiler    │
│    └─ 需要获取真实 latency                       │
│                                                  │
│  编译器基础设施                                   │
│    └─ IR: MLIR, LLVM IR, TVM IR                 │
│    └─ 代码生成后端                               │
│                                                  │
│  算子语义定义                                     │
│    └─ 计算图描述（ONNX, torch.compile graph）    │
└─────────────────────────────────────────────────┘

下游：自动调优输出什么

┌─────────────────────────────────────────────────┐
│                   下游消费                        │
├─────────────────────────────────────────────────┤
│  优化后的 Kernel / 调度计划                       │
│    └─ 直接编译为可执行代码                        │
│    └─ 或序列化为调优记录（TVM tuning records）    │
│                                                  │
│  AI 推理/训练框架                                 │
│    └─ TensorRT, ONNX Runtime                    │
│    └─ PyTorch 2.x (torch.compile)               │
│                                                  │
│  硬件适配层                                      │
│    └─ 新芯片的算子库快速构建                      │
└─────────────────────────────────────────────────┘

关键指标

调优质量指标

典型性能数据（定性，具体数字因硬件/算子而异）

• GEMM 自动调优：相比朴素实现，通常可获得显著提速（数量级取决于基线质量）
• Attention 自动调优：FlashAttention 类内核需手动设计，自动调优在此类融合算子上仍有挑战
• 搜索开销：一次完整调优可能需要数十分钟至数小时，但结果可缓存复用

供需与市场数据

需求端：谁需要自动调优？

供给端：谁在提供自动调优能力？

市场规模（估算）

自动调优作为编译器工具链的一部分，难以单独统计市场规模。可参考的口径：

• AI 编译器/优化工具链整体市场 [行业报告，具体数字来源各异]
• 其价值主要体现在降低工程人力成本和提升硬件利用率两个维度

代表公司与资本映射

投资逻辑

核心逻辑

1. 硬件碎片化加剧 → 自动调优是降低适配成本的关键技术

   • AI 芯片从 NVIDIA 独占走向多元化（AMD、Intel、自研 ASIC）
   • 每种新硬件都需要优化库，人工方式不可持续

2. 编译器成为 AI 基础设施竞争的焦点

   • PyTorch 2.x 的 torch.compile 将编译器推到前台
   • 谁的编译器+调优能力更强，谁的硬件生态更有竞争力

3. 动态场景增多 → JIT 调优价值凸显

   • 动态 shape（NLP 变长序列）、动态 batch（推理服务）
   • 静态离线调优不够，需要在线适应能力

风险

• 开源替代风险：TVM、Triton 等开源项目进展快，商业公司需提供显著差异化价值
• 厂商绑定：NVIDIA 等厂商可能将最优调优能力锁定在自家生态中
• LLM 对编译器的挑战：大模型优化更多依赖算法创新（如 FlashAttention），编译器自动调优难以触及算法层面

常见误读纠偏

误读 1：“自动调优能替代手写 kernel”

纠偏：自动调优擅长在已知算法框架内寻找最优参数配置，但无法发明新的算法。例如：

• FlashAttention 的 IO-aware 算法设计是人类智慧，不是搜索出来的
• 自动调优可以在此基础上进一步调优 tiling 参数，但无法替代算法创新
• 真正的高性能 = 好的算法 × 好的调优，两者缺一不可

误读 2：“搜索空间越大，调优结果越好”

纠偏：

• 搜索空间过大 → 搜索效率下降，可能在有限预算内找不到好解
• 存在”维数灾难”：配置数随参数维度指数增长
• 实践中需要人工约束 + 好的搜索策略来平衡覆盖率与效率
• 有时一个精心设计的小搜索空间，比盲目大的空间效果更好

误读 3：“调优一次，永久有效”

纠偏：

• 硬件型号变更（A100 → H100）→ 最优配置可能完全不同
• 输入形状变化（batch size 从 1 变 64）→ 切分参数需要调整
• 驱动/编译器版本更新可能影响性能特性
• 生产环境中需要调优记录管理和条件性复用

学习路径

入门（1-2 天）

1. 理解动机：阅读 TVM 官方教程中的 Auto-Tuning 章节
2. 动手实践：用 TVM AutoTVM 对一个简单算子（如 conv2d）进行调优
3. 观察现象：对比调优前后的性能差异

进阶（1-2 周）

1. 深入 Auto-Scheduler：学习 Ansor/Auto-Scheduler 的无模板搜索原理
2. Triton 实践：用 Triton 写一个 matrix multiplication kernel，体验 DSL + 自动调优
3. 阅读论文：
   • “Ansor: Generating High-Performance Tensor Programs for Deep Learning” (OSDI 2020)
   • “TVM: An Automated End-to-End Optimizing Compiler for Deep Learning” (OSDI 2018)

专家（持续）

1. MLIR 学习：了解现代编译器基础设施如何支持自动调优
2. 硬件 Profiling：学习 Nsight Compute / rocprofiler，理解硬件瓶颈
3. Cost Model 设计：研究如何训练更准确的性能预测模型

一句话总结

自动调优是 AI 编译器的”自动驾驶”——它不发明新算法，但能在给定算法框架下，自动找到在特定硬件和输入上的最优执行配置，是解决硬件碎片化和降低 AI 部署成本的关键技术。

延伸阅读与来源

核心论文

教程与文档

• Apache TVM 官方文档：https://tvm.apache.org/docs/
• Triton 官方教程：https://triton-lang.org/
• MLIR 官方文档：https://mlir.llvm.org/

产业报告

• AI 编译器市场分析：[各咨询机构报告，具体数据来源各异，需独立核实]

开源项目

• Apache TVM: https://github.com/apache/tvm
• OpenAI Triton: https://github.com/openai/triton
• MLIR: https://github.com/llvm/llvm-project/tree/main/mlir

数据说明：

• 本文中的技术原理描述基于公开论文和开源项目文档
• 具体性能数据因硬件、算子、输入形状而异，未给出绝对数字
• 融资信息基于公开报道，具体金额请以公司官方披露为准
• 标注 [估算] 的数据为行业定性判断，非精确统计