自動調優

3 秒看懂

一句話：自動調優是讓編譯器/架構”自動試跑”成百上千種實現方案，找到在特定硬體上最快的那一套配置——本質是用搜索代替人工經驗。

類比：廚師接到一道菜，要決定刀工大小、火候、翻炒時長。經驗老道的大廚憑直覺選，自動調優則是讓新手把所有組合都試一遍，用秒錶計時，選出最優解。

---

3 分鐘產業解釋

為什麼需要自動調優？

深度學習運算元（如卷積、矩陣乘、注意力）在不同硬體上的”最優實現”天差地別：

變數	可選空間示例
迴圈切分 (Tiling)	對 M/N/K 維度分別切成多大的塊
並行策略	哪些維度分配給執行緒/Block/Warp
記憶體版面配置	NHWC vs NCHW、是否需要 transpose
向量化寬度	一次 load 多少位元組
融合策略	哪些運算元合併成一個 kernel

人工調優的痛點：

• 不同 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 邏輯 ...

使用者標註哪些是可調引數，架構自動遍歷或搜尋。

搜尋演算法分類

演算法類別	典型方法	特點
隨機/網格搜尋	Random Search	簡單基線，高維空間下隨機搜尋效率不差
貝葉斯最佳化	GP-BO, TPE	用機率模型建模目標函式，適合 expensive evaluation
進化演算法	Genetic Algorithm, CMA-ES	種群迭代，適合離散+連續混合空間
基於 ML 的 Cost Model	XGBoost, GNN, Tree-LSTM	訓練模型預測效能，減少實際執行次數
基於 RL 的搜尋	Policy Gradient, Q-Learning	把排程選擇建模為序列決策問題

產業實踐：多數系統採用”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 數
    └─ 暫存器/共享記憶體佔用過高會降低佔用率

---

技術演進史

時期	里程碑	意義
~2010s 早期	ATLAS / FFTW 等科學計算庫的自動調優	自動調優思想萌芽，但侷限於特定演算法
2015-2017	Halide 語言 + autoscheduler	將排程與計算解耦，開創”排程空間搜尋”範式
2018	TVM AutoTVM 釋出	首個面向深度學習的端到端自動調優系統
2019	XLA (TensorFlow) 持續迭代	Google 在編譯器中內建搜尋式最佳化
2020	Ansor (Auto-Scheduler) 釋出	無模板自動搜尋，突破人工模板瓶頸
2021-2022	Triton (OpenAI) 開源	DSL + 自動調優，降低 GPU kernel 編寫門檻
2022-2023	CUTLASS 3.x（含 CuTe 子庫）/ cuDNN 8 內建自動調優	廠商在原生庫中整合自動選擇邏輯
2023-2024	MLIR + LLVM 社群整合	自動調優作為編譯流水線標準組件

趨勢：從”離線搜尋 → 回放”向”即時調優 (Just-in-Time Tuning)“演進，支援動態 shape 和線上適應。

---

技術路線對比

維度	Template-based (AutoTVM)	Schedule-based (Auto-Scheduler)	DSL-based (Triton)
搜尋空間來源	人工模板	自動派生	使用者宣告引數
擴充套件新運算元成本	高（需寫模板）	低（只需計算定義）	中（需寫 kernel）
效能上限	高（專家經驗注入）	中高（受規則約束）	高（使用者可精細控制）
搜尋效率	較高（空間受約束）	較低（空間大）	中等
可移植性	中（模板與硬體相關）	高（規則通用）	中（kernel 與後端相關）
代表系統	AutoTVM	TVM Auto-Scheduler	Triton, Halide
適用場景	運算元庫快速最佳化	新運算元快速原型	研究 + 生產

補充對比：廠商原生調優

維度	開源編譯器調優	廠商原生調優 (如 cuDNN / oneDNN)
維護方	社群	晶片廠商
覆蓋範圍	廣（任意運算元）	窄（常用運算元）
效能上限	中高	高（深度硬體繫結）
更新速度	快	取決於廠商節奏
信任度	需驗證	生產級保障

---

上下游

上游：自動調優依賴什麼

┌─────────────────────────────────────────────────┐
│                   上游依賴                        │
├─────────────────────────────────────────────────┤
│  硬體描述 / 效能計數器                            │
│    └─ 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)               │
│                                                  │
│  硬體適配層                                      │
│    └─ 新晶片的運算元庫快速建置                      │
└─────────────────────────────────────────────────┘

---

關鍵指標

調優質量指標

指標	定義	重要性
Speedup vs Baseline	相對於預設實現的加速比	核心價值體現
Percentage of Peak	達到硬體理論峰值的百分比	衡量調優深度
搜尋時間 (Search Time)	找到最優配置所需時間	實用性
搜尋空間覆蓋率	探索的配置佔總空間比例	搜尋效率
Cost Model 準確率	預測排序與真實排序的相關性	決定搜尋效率

典型效能資料（定性，具體數字因硬體/運算元而異）

• GEMM 自動調優：相比樸素實現，通常可獲得顯著提速（數量級取決於基線質量）
• Attention 自動調優：FlashAttention 類核心需手動設計，自動調優在此類融合運算元上仍有挑戰
• 搜尋開銷：一次完整調優可能需要數十分鐘至數小時，但結果可快取複用

---

供需與市場資料

需求端：誰需要自動調優？

場景	痛點	自動調優價值
AI 晶片廠商	新晶片沒有最佳化庫，等庫太慢	快速建置運算元庫，縮短上市時間
大型模型訓練	模型架構迭代快，每次都要重新最佳化	編譯器自動適配
邊緣部署	碎片化硬體（手機 SoC、車載晶片）	統一編譯+自動調優降低適配成本
推論服務	動態 batch、動態 shape	JIT 調優即時適配

供給端：誰在提供自動調優能力？

型別	代表	模式
開源編譯器	TVM, Triton, XLA	社群維護，免費使用
晶片廠商工具	NVIDIA (TensorRT, cuDNN), AMD (rocBLAS)	與硬體繫結，閉源為主
編譯器創業公司	OctoML (TVM商業化), Modular (MAX)	商業支援+雲端服務
雲端廠商內部	AWS (Inferentia), Google (TPU)	內部使用，不對外

市場規模（估算）

自動調優作為編譯器工具鏈的一部分，難以單獨統計市場規模。可參考的口徑：

• AI 編譯器/最佳化工具鏈整體市場 [行業報告，具體數字來源各異]
• 其價值主要體現在降低工程人力成本和提升硬體利用率兩個維度

---

代表公司與資本對映

公司/專案	定位	技術路線	融資/狀態
OctoML	TVM 商業化	Apache TVM + 雲端調優服務	已融資，具體金額未確認
Modular	下一代 AI 編譯器	Mojo 語言 + MAX 引擎	已完成多輪融資 [公開報道]
MLIR/TVM 社群	開源編譯器基礎設施	社群驅動	Google/多家公司貢獻
NVIDIA	垂直整合	cuDNN + TensorRT + Nsight	上市 (NVDA)
AMD	編譯器追趕	ROCm + MIOpen	上市 (AMD)
Google	內部編譯器	XLA + MLIR	Alphabet 子公司

---

投資邏輯

核心邏輯

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 部署成本的關鍵技術。

---

延伸閱讀與來源

核心論文

論文	年份	關鍵貢獻
TVM (OSDI 2018)	2018	端到端 ML 編譯器 + AutoTVM
Ansor (OSDI 2020)	2020	無模板自動調度搜索
Triton (ICML 2019)	2019	面向 GPU 的 DSL + 編譯器
FlexTensor (ASPLOS 2020)	2020	多平台自動張量最佳化

教程與文件

• 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

---

資料說明：

• 本文中的技術原理描述基於公開論文和開源專案文件
• 具體效能資料因硬體、運算元、輸入形狀而異，未給出絕對數字
• 融資資訊基於公開報道，具體金額請以公司官方揭露為準
• 標註 [估算] 的資料為行業定性判斷，非精確統計