《GPU Mode》 L063 2025 · Compiler search High priority transcript · failed

Search-Based Deep Learning Compilers

전문가의 손으로 짠 schedule 보다 — 자동 search 가 찾은 schedule 이 더 빠를 수 있다. TVM 의 AutoTVM 과 Ansor 가 깐 paradigm: schedule space 를 정의하고, cost model 로 평가하고, ML 로 가속한다. Joe Fioti 의 Luminal 이 같은 frame 을 LLM 시대로 끌어와 — Rust 로 처음부터 짠 search-first 컴파일러로 작은 footprint 를 노린다. 이 노트는 search-based 컴파일러의 일반적 모양과 LLM 시대의 새 응용을 정리한다.

search-based compiler cost model AutoTVM Ansor Luminal Tensor Comprehensions e-graph learned cost model

Speaker

Joe Fioti

Luminal · Rust 기반 search-first ML compiler

강의 번호

L063

스피커

Joe Fioti

학습 우선순위

High · 정독

자료 상태

transcript 없음 · 일반 자료

하위 목차 · 12개 섹션↓ 클릭해서 이동

01강의가 풀려는 문제why search at all 02search 가 푸는 자리manual schedule 의 한계 03cost model 의 역할measure vs predict 04schedule space 정의tile · order · vector 05대표 시스템들TVM/AutoTVM/TC/Ansor 06LLM 시대의 searchLuminal · MLIR 07학습된 cost modelXGBoost · GNN · TabNet 08production 결과언제 이기는가 09다음 단계e-graph · LLM-guided 10기억할 메모와 자료key takeaways 11다른 강의로 이어지는 길connections 12열린 질문open questions

§ 01강의가 풀려는 문제· why search at all

같은 op, 같은 hw 인데 — schedule 의 search space 가 너무 커서 손으로는 못 푼다

한 GEMM 의 schedule 만 — tile size (M_tile, N_tile, K_tile), loop order (6 permutations), stage 위치 (shared / register), num_warps, num_stages, vector width — 의 곱이 10⁵ ~ 10⁷ 의 schedule space. 사람이 enumerate 할 수 없다. 그런데 그 안에 어딘가의 한 점이 — peak 의 95% 이상으로 — 답을 갖는다. search-based 컴파일러의 명제가 그 자리.

강의 transcript 가 비어 있으므로 본 노트는 — TVM / AutoTVM / Ansor 의 표준 자료, Tensor Comprehensions (Facebook 2018), Luminal (Joe Fioti 의 Rust 컴파일러) 의 공개 디자인 자료 위에서 재구성한다. 강의 안에서 다룬 정확한 비중 / case study 는 영상 검증 필요.

강의의 인지적 frame

search-based 컴파일러의 두 axis — (1) search space: 어떤 schedule 이 valid 한지를 어떻게 정의할 것인가. (2) cost model: 한 schedule 의 latency 를 어떻게 빠르게 estimate 할 것인가. 두 axis 가 좋아야 search 가 의미. 하나만 잘 해도 답을 못 찾는다.

“같은 GEMM 의 schedule space 안에 — 사람이 못 찾는 1만 개의 점이 있고 — 그 중 한 점이 peak 의 99%, 다른 점들이 peak 의 50%. search 의 가치는 그 1만 점을 빠르게 평가할 수 있느냐다.”학습 노트

§ 02search 가 푸는 자리· manual schedule 의 한계

전문가의 손으로 짠 라이브러리 (cuBLAS / cuDNN) 가 모든 걸 푸는가 — 아니다

cuBLAS / cuDNN / OneDNN 같은 vendor 라이브러리가 큰 GEMM / convolution 의 standard size 에서는 거의 peak 에 가깝다. 그런데 그 라이브러리들은 — training-time 에 미리 튜닝된 fixed shape 만 잘 푼다. 다음 자리에서 깨진다.

새로운 shape — 학습된 모델의 GEMM 이 cuBLAS 가 본 적 없는 (M, N, K) 면 fallback path 로 떨어져 50% peak 도 못 침.
fused operator — bias add + GeLU + dropout 같은 fusion 패턴은 cuDNN 에 없음. PyTorch 의 fallback 으로 떨어지면 여러 kernel launch.
새 hw — Hopper 의 WGMMA 같은 새 instruction 이 나오면 cuBLAS 가 따라잡는 데 시간이 걸림. 그동안 search-based 가 직접 채운다.
edge / accelerator — vendor 라이브러리가 없는 hw — 자기 op 의 schedule 을 search 로 자동 생성.

search 의 sweet spot

(1) 비표준 shape / fused op 가 많은 model. (2) vendor lib 가 약한 새 hw. (3) compile time 에 충분한 시간이 있는 deployment. (4) 같은 모델을 같은 hw 에 반복 deploy — search cost amortize.

반대로 search 가 안 좋은 자리 — 매 inference run 에서 새 shape 가 들어오는 dynamic shape 모델, 또는 search 시간 자체가 user 의 wall-clock 인 interactive 환경. Just-in-Time search 의 cost 가 inference 를 망가뜨림. 그래서 — Ansor / AutoTVM 같은 시스템들은 모두 ahead-of-time search.

§ 03cost model· measure vs predict

한 schedule 의 latency 를 — GPU 위에서 직접 재거나 model 로 예측한다

schedule space 안 한 점의 “좋음” 을 어떻게 평가하는가. 두 갈래.

(a) Direct measurement

schedule 을 실제로 컴파일하고 GPU 위에서 ms 측정. 가장 정확. 하지만 한 schedule 에 ~100 ms 컴파일 + ~50 ms benchmark + sync = ~200 ms / sample. 1000 sample = 3분. search space 가 크면 시간 폭발.

최적화 — 같은 op 의 여러 shape 를 batch 로 컴파일 / measurement, GPU memory 의 alloc/free 한 번. 실용적으로 50ms / sample 까지 줄임.

(b) Predicted via cost model

schedule 의 features (tile sizes, memory access pattern, register usage) 를 ML model 에 넣어 latency 예측. ~1 ms / sample. 200× 빠름. 하지만 정확도 낮음 (R² 0.7~0.9).

전형 패턴 — predicted cost model 로 top-K (K=100) 을 고르고, 그 K 만 direct measurement. search 의 시간을 100× 줄이면서 정확도는 유지.

FIG · cost model 비교한 schedule 평가 시간 / 정확도

analytical (FLOPs/BW)

~0.01 ms

XGBoost (AutoTVM)

~1 ms

GNN / TabNet

~3 ms

direct measure

~50 ms

analytical · 정확도

R² ~.4

XGBoost · 정확도

R² ~.85

direct · 정확도

R² 1.0

analytical 모델은 빠르지만 정확도 낮음 — coarse filter 로만. ML cost model 이 sweet spot. direct measurement 는 final ranking 에만 사용. 수치 예시 (확인 필요).

§ 04schedule space 정의· tile · order · vector

한 op 의 schedule 을 어떻게 enumerate 가능한 형태로 잡는가

search 의 첫 단계 — search space 정의. “이 op 의 valid schedule 은 어떤 것들인가” 를 정형화. AutoTVM / Ansor 가 같은 op 에 대해 다른 space 를 갖는다 — Ansor 의 핵심 기여 중 하나가 더 큰 / 더 좋은 search space.

한 GEMM 의 search dimension

GEMM(M, N, K)

tile_M ∈ {16, 32, 64, 128, 256}

tile_N ∈ {16, 32, 64, 128, 256}

tile_K ∈ {8, 16, 32, 64}

num_stages ∈ {2, 3, 4}

num_warps ∈ {4, 8}

loop_order ∈ 6 permutations of (M,N,K)

vec_load ∈ {1, 2, 4, 8}

swizzle pattern ∈ {none, xor, ...}

총 sample 수 ≈ 5×5×4×3×2×6×4×3 = 21,600. 더 큰 op (conv2d) 는 추가 dim — kernel split, dilation, layout — 으로 10⁵+.

중요한 design 결정 — space 가 너무 작으면 좋은 schedule 이 그 안에 없음. 너무 크면 search 가 못 끝남. AutoTVM 은 사람이 정의한 templated space (작음, 좋은 covers). Ansor 는 자동 derive (큰, 더 광범위).

AutoTVM: “손으로 짠 schedule template” 안의 hyperparameter 만 search. 사람이 형태를 잡아주고 search 가 inside 를 푼다. 작은 space 에서 빠른 수렴.
Ansor (auto-scheduler): schedule rule 을 컴파일러가 자동으로 enumerate. 사람의 input 거의 없음. 큰 space, 큰 sample budget 필요.
Tensor Comprehensions: polyhedral analysis 로 valid schedule 을 derive. 큰 space, expressive 하지만 어려움.

search 알고리즘

가장 흔한 — simulated annealing + genetic algorithm. AutoTVM 은 SA 로 cost model 위에서 random walk. Ansor 는 GA 로 다양한 schedule 의 mutate / crossover. 둘 다 ~1000 iteration 안에 수렴. 모두 cost model 에서 prefilter + direct measurement 로 final ranking.

최근의 진화 — RL 기반 search (Tensor Comprehensions 의 강화학습 변형, Microsoft 의 Roller). action 이 다음 schedule choice. policy gradient 로 학습. random walk 보다 빠르게 좋은 영역 탐색.

§ 05대표 시스템들· TVM/AutoTVM/TC/Ansor

같은 frame 의 서로 다른 권장 디자인

시스템

space 정의

cost model

차별점

TVM (2018) scheduling primitive (Halide-like) analytical + sampler ML 컴파일러의 base. 다양한 backend.

AutoTVM 사람 template + hyperparameter XGBoost (transfer) 실용적. 작은 space, 빠름.

Ansor (2020) 자동 derive XGBoost + simulated annealing 사람 template 불필요. 큰 space.

Tensor Comprehensions polyhedral 자동 derive RL + measurement einsum-style DSL. Facebook 2018.

PyTorch Inductor Triton fixed templates autotune (직접 sweep) JIT-friendly. heuristic 위주.

Luminal e-graph rewrite analytical + measurement Rust 처음부터. LLM-first.

search 의 표준 loop

space 정의

valid schedules

초기 sample

random N개

cost model 평가

XGBoost 등

top-K 측정

direct GPU run

retrain + iter

best schedule

매 iteration 에서 측정한 sample 을 cost model 에 다시 학습. “이 hw 에서 이 op 에 대해 cost model 이 점점 정확해진다”. 1000 sample / 30분이면 보통 vendor lib 의 95~110% 까지 도달.

§ 06LLM 시대의 search· Luminal · MLIR

LLM 모델은 같은 op 만 반복한다 — search 를 amortize 할 자리가 많다

LLM inference / training 은 같은 transformer block 을 80번 반복. 같은 (M, N, K) GEMM 이 layer 마다 등장. 한 번 search 한 schedule 을 80번 reuse 하면 — search cost 가 거의 0 으로 amortize. 이게 LLM 영역에서 search-based 가 다시 의미를 갖는 이유.

Luminal — Rust 의 search-first 컴파일러

Joe Fioti 의 프로젝트. Rust 로 처음부터 짠 ML 컴파일러. 디자인 결정:

e-graph 기반 rewrite — 같은 결과를 만드는 모든 schedule 을 동시에 표현. equality saturation 으로 best 를 찾음.
compile-time-first — JIT 보다 AOT 위주. user 가 모델을 한 번 컴파일하고 그 binary 를 deploy.
작은 footprint — Python / PyTorch 의존성 없음. Rust 의 small-footprint 친화.
LLM 위주 — transformer block 의 op 들 (GEMM, RMSNorm, attention, RoPE) 에 fokus.

MLIR / IREE 의 search

Google 의 IREE 는 MLIR 의 stack 위에 — schedule search 를 dialect 의 transform 으로 표현. “이 op 를 이 schedule 로 변환” 이 MLIR 의 rewrite rule. 다른 컴파일러보다 더 modular.

최근 — MLIR + Triton 의 hybrid 가 떠오름. high-level 은 MLIR 에서 schedule, low-level 은 Triton 에서 launch config sweep. PyTorch Inductor 도 비슷한 방향.

e-graph 의 매력

e-graph (equality graph) 는 — 같은 결과를 만드는 모든 표현을 한 그래프 안에 압축해서 들고 있는 자료구조. “(a+b)+c = a+(b+c)” 같은 모든 결합법칙을 동시에. equality saturation 으로 grow 시킨 뒤 cost function 으로 best 추출. 중복 search 가 없어진다. Luminal 의 핵심 디자인 결정이 이 e-graph 기반이라는 점.

§ 07학습된 cost model· XGBoost · GNN · TabNet

cost model 이 곧 search 의 속도를 결정한다

cost model 의 진화는 — analytical → XGBoost → GNN → transformer-based. 각 단계가 R² 정확도와 sample 효율성을 향상.

model

feature

정확도

학습 데이터

analytical FLOPs / BW / occupancy R² ~0.4 없음 (rule-based)

XGBoost schedule features (tile, etc.) R² ~0.85 ~1000 sample / op

TabNet / NN same + token embeddings R² ~0.90 ~10K sample

GNN (TenSet) schedule graph 구조 R² ~0.92 ~100K sample, transfer

transformer-based schedule 의 token sequence R² ~0.94 ~1M sample

수치 예시 — TenSet (UC Berkeley) 같은 dataset 의 일반적 트렌드. 절대값은 op / hw / search space 에 따라 변동 (확인 필요).

cost model 의 큰 이슈는 — transfer. 한 hw 에서 학습한 cost model 이 다른 hw 에 옮겨가는가? 학술적으로는 GNN / transformer 가 더 좋은 transfer. 실용적으로는 — 각 hw 마다 따로 학습.

그래서 — vendor 가 "이 hw 의 표준 cost model checkpoint" 를 publish 하는 패턴. 사용자는 그 checkpoint 위에서 자기 op 만 fine-tune.

측정의 noise 문제

같은 schedule 을 같은 GPU 에서 두 번 측정해도 — frequency scaling, thermal, neighbour 영향으로 5~10% 차이. cost model 의 R² 가 0.95+ 가 안 되는 이유 중 하나가 이 측정 noise 자체. 그래서 search 는 relative ranking 이 절대값보다 중요한 task.

최근 — LLM-guided search 가 작은 trend. ChatGPT / Claude 에게 “이 op 의 best schedule 패턴” 을 prompt 로 묻고 그 hint 로 search 가 starts. 신뢰성 미확인.

§ 08production 결과· 언제 이기는가

같은 op 에 대해 — manual schedule, vendor lib, search 의 비교

cuBLAS GEMM (표준 shape)

98%

cuBLAS GEMM (비표준)

62%

manual Triton (전문가)

88%

manual Triton (대학원생)

65%

AutoTVM

92%

Ansor

95%

PyTorch Inductor

85%

수치는 일반적 트렌드 — peak 의 % 표시. 비표준 shape 영역에서 search 의 우위 가장 큼. 정확한 절대값은 op / hw / shape 에 따라 변동 (확인 필요).

중요한 관찰 — 표준 shape 의 표준 op 에서는 vendor lib 가 여전히 dominant. cuBLAS / cuDNN 이 NVIDIA 의 internal team 이 hand-tune 한 결과. 그러나 — fused op, 비표준 shape, edge hw 에서 search 의 우위가 큼. “search 가 이기는 자리는 vendor lib 의 sparse 한 지점” 이라고 봐야 정확.

Production 채택의 트렌드

(1) Apache TVM 은 일부 회사 (Amazon, Microsoft) 의 production 에 채택 — 주로 inference. (2) PyTorch Inductor 는 search 보다는 fixed Triton template 을 autotune 하는 hybrid — 가장 큰 사용자층. (3) Ansor 는 학술 계열, production 채택은 제한적. (4) IREE / MLIR 는 진행 중. (5) Luminal 같은 새 영역의 컴파일러는 지켜볼 자리.

§ 09다음 단계· e-graph · LLM-guided

2024–25 의 새 방향

e-graph 기반 컴파일러 — Luminal, egglog. equality saturation 으로 redundant search 제거. 더 큰 space 를 다룸.
LLM-guided search — 코드 생성 모델 (Claude, GPT, Gemini) 이 schedule 의 첫 sample 을 제안. search 가 이를 보강. 신뢰성 / 실효성 검증 중.
auto-discovered op — search 가 새 fused op 까지 자동으로 발견. 사람이 손으로 짤 수 있는 fusion 의 범위를 넘어섬.
cross-op global schedule — 한 layer 가 아니라 전체 model graph 의 schedule 을 한 번에 search. fusion / persistent kernel 같은 large-scope 결정이 자연.
compile-time vs runtime hybrid — 일부는 컴파일 타임에 search, 일부는 runtime profiling 으로 calibrate. 모델의 dynamic shape 영역에 대응.

“search 의 다음 단계는 — 더 똑똑한 알고리즘이 아니라, 사람의 prior 와 ML 모델의 prior 를 합쳐서 search budget 을 줄이는 길이다.”학습 노트

§ 10기억할 메모와 자료· key takeaways

다시 열었을 때 빠르게 잡혀야 할 것

search 의 두 axis

space 정의 + cost model. 둘 다 좋아야 search 의미.

space 의 trade-off

너무 작으면 답 없음. 너무 크면 못 끝남. AutoTVM (작음) vs Ansor (큼).

cost model 의 hierarchy

analytical → XGBoost → GNN → transformer. 정확도와 학습 cost 의 trade-off.

prefilter + measure

cost model 로 top-K → 그 K 만 direct measure. search cost 100× 줄임.

vendor lib 와의 관계

표준 shape 에서는 vendor 가 이김. 비표준 / fused / edge 에서 search 가 이김.

LLM amortize

같은 op 80번 반복 = search cost amortize. search-friendly 워크로드.

e-graph

equality graph 로 redundant search 제거. Luminal 의 디자인 결정.

vs Exo / manual

Exo 는 사람 통제. search 는 자동. 같은 문제의 정반대 axis.

YouTube youtube.com/watch?v=_aT2eo-0uWk

Luminal github.com/jafioti/luminal

TVM tvm.apache.org

AutoTVM 논문 Learning to Optimize Tensor Programs · arXiv:1805.08166

Ansor 논문 Ansor · OSDI 2020 · arXiv:2006.06762

Tensor Comprehensions arXiv:1802.04730

e-graph / egglog egraphs-good.github.io

손에 새기기 — 실습 시퀀스

AutoTVM 첫 GEMM — 자기 GPU 에서 (M=1024, N=1024, K=1024) GEMM 의 schedule search. cost model log 와 best schedule 비교.
cuBLAS 와 비교 — 같은 shape 의 cuBLAS 와 search 결과 ms 비교. peak 의 % 어디까지 도달하는지.
비표준 shape 시도 — (M=731, N=1023, K=137) 같은 shape. cuBLAS 의 fallback 이 얼마나 떨어지는지, search 가 어떻게 더 나은지.
cost model 의 정확도 측정 — 1000 sample 의 predicted vs measured latency 의 R². 작은 budget 으로 model 이 어디까지 학습되는지.
Ansor 와 head-to-head — AutoTVM 의 template-based 와 Ansor 의 자동 derive 가 같은 op 에서 어떻게 다른지.
Luminal 시도 — Rust 환경 setup 후 Luminal 의 sample 모델 빌드. PyTorch 대비 binary size / inference time 비교.
e-graph tutorial — egg / egglog 의 simple rewrite 예제. equality saturation 을 직접 손으로 본다.

§ 11다른 강의로· connections

이 강의의 frame 이 다른 강의에서 어떻게 다시 등장하는지

L062

Exo 2 — Scheduling Language

— search 의 정반대 axis. manual control vs auto search

L007

torch.compile

— PyTorch Inductor 의 fixed-template autotune. search 의 대중적 버전

L029

Triton Internals

— search 가 lowering 하는 Triton 의 내부

L014

Practitioner's Guide to Triton

— autotune 의 user-facing 자리. 작은 search 의 일종

L053

torch.compile Q&A

Richard Zou — Inductor 의 search 메커니즘 디테일

L061

D-Matrix Corsair

— vendor lib 가 약한 새 hw. search 가 이기는 자리

§ 12열린 질문· open questions

transcript 가 비어 있어 직접 검증해야 할 것들

강의에서 다룬 정확한 시스템 — TVM/AutoTVM/Ansor 의 어디에 시간을 더 썼는지, 본인 Luminal 이야기의 비중 — transcript 없어 미확인.
Luminal 의 정확한 architecture — e-graph 위에서의 schedule rewrite 가 어떻게 정의되는지 더 디테일.
LLM-guided search 의 실제 작동 — 강의에서 demo 가 있었는지, Claude/GPT 가 어디까지 valid schedule 을 제안하는지.
specific benchmark 수치 — 본 노트의 % 수치는 일반 트렌드. 강의에서 보여준 정확한 hw / op 수치는 미확인.
e-graph 의 search budget — equality saturation 이 실제로 얼마나 빠른지, naive search 와의 비교.
cross-op global schedule 의 status — 한 model graph 단위 search 의 진행 상태. 학술적 시도가 어디까지.
LLM 시대의 dynamic shape — KV cache 가 매 step 늘어나는 inference 에서 search 가 어떻게 작동하는지 — 강의 안 다뤘는지 미확인.

검증 메모

본 노트는 search-based 컴파일러의 표준 자료 (AutoTVM/Ansor 논문, TVM blog) 와 Luminal 의 공개 디자인 자료 위에서 재구성. 강의에서 Joe Fioti 가 강조한 정확한 디자인 결정 / 자기 work 의 디테일은 영상 시청으로 검증해야 한다.

← Lecture 062 Exo 2 — manual scheduling 의 정반대 axis Lecture 064 → Multi-GPU programming — 통신과 동기화의 표준 모델