Visual Compiler Playground - 보는 순간 이해되는 AI Compiler / Kernel Runtime

왜 이 카테고리가 필요한가

AI Compiler, AI Framework 글들은 보통 이렇게 나뉜다.

• 이론 중심: IR, Graph, Lowering, Fusion, Scheduling
• 코드 중심: LLVM, MLIR, CUDA kernel, CMake, pass 구현

문제는 둘 사이의 **“인지 갭”**이다.

IR이 왜 필요한지,
커널 선택이 언제, 왜 바뀌는지,
프레임워크가 “자동으로 최적화한다”는 말이 실제로 무슨 뜻인지
를 눈으로 본 적이 없다는 점.

이 카테고리는 그 갭을 메우는 게 목적이다.

 

핵심 아이디어 한 줄 요약

Scratch처럼 ops를 쌓아 올리면,
AI Compiler가 내부에서 무엇을 판단하고
어떤 커널을 선택·교체하는지가 실시간으로 보이는 Playground

 

컨셉: Scratch × AI Compiler

Scratch가 직관적인 이유

• 블록 = 실행 단위
• 연결 = 데이터 흐름
• 실행하면 즉각적인 반응

AI Compiler에 그대로 대응하면

블록	Op (GEMM, Bias, ReLU…)
연결선	Tensor flow
실행 버튼	Lower → Kernel Select → Run
캐릭터 반응	Kernel 선택/교체

 

Playground에서 다루는 최소 단위

1️⃣ Op Block

각 블록은 연산 + 메타데이터를 가진다.

[GEMM]
- input : (M,K), (K,N)
- dtype : FP16
- attrs : transB=True

블록 위에 항상 보이는 정보:

• shape
• dtype
• layout / transpose 여부

 

2️⃣ Lowered Ops View

블록을 쌓으면 자동으로 LoweredOps 리스트가 생성된다.

#000 gemm       -> kid=gemm_f16_tc_wmma_v0
#001 bias_add   -> kid=bias_add_f16_vec2_v0
#002 relu       -> kid=relu_f16_vec_v0

👉 여기서 중요한 점
“Lowering은 분해이지, 최적화가 아니다”
→ 이 메시지를 시각적으로 전달하는 게 목적

 

3️⃣ Kernel Candidates Panel (핵심)

각 op마다 가능한 커널 후보들이 펼쳐진다.

GEMM candidates:
- gemm_f16_tc_wmma_v0
- gemm_f16_tc_wmma_v1
- gemm_f16_simt_v0

각 후보는:

• heuristic score
• 제약 조건 (shape, alignment)
• 예상 latency

 

Online Kernel Selection을 어떻게 보여주는가

이 Playground의 정수.

단계 1: Heuristic 선택

• Lower 직후 “예상 베스트 커널” 자동 선택
• 블록에 🟢 heuristic 뱃지 표시

단계 2: Runtime 측정

• Run / AutoTune 클릭
• 동일 op에 대해 여러 kid 실제 실행
• 결과 비교 후 더 빠르면 교체

kernel switched:
gemm_f16_tc_wmma_v0
→ gemm_f16_tc_wmma_v1  (-11.8%)

 

이게 AI Framework 이해에 왜 중요한가

1️⃣ “자동 최적화”의 실체를 보여준다

• 커널 선택은 마법이 아니라 조건 + 측정의 결과
• shape 하나 바꾸면 결과가 달라지는 이유가 보임

2️⃣ IR / Lowering 개념이 살아난다

• IR = 블록 연결 상태
• Lowering = 실행 가능한 최소 단위로 분해
• Kernel Select = 진짜 성능을 결정하는 단계

3️⃣ 커널 최적화 공부가 추상에서 현실로 내려온다

• “왜 epilogue fusion이 중요한지”
• “왜 GEMM이 대부분의 시간을 먹는지”
• “왜 어떤 커널은 특정 shape에서만 빠른지”