《GPU Mode》
L047
2025 · APR
Low priority · 커뮤니티 도구
transcript · 실패 · KernelBot 공개 정보 기반
KernelBot · Benchmark GPU Kernels on Discord
GPU Mode 디스코드 서버 안에서 도는 커널 벤치마크 봇의 운영 시스템. 사용자가 채널에 코드 한 덩이를 올리면 봇이 자동으로 빌드, 정확성 검증, latency 측정, leaderboard 업데이트까지. 커널 최적화의 게임화가 어떤 학습 효과를 만드는가. transcript 누락된 강의이므로 본 노트는 KernelBot 의 공개 운영 정보 + GPU Mode 커뮤니티 자료 위에서 정리.
KernelBot
Discord
leaderboard
정확성 검증
latency 측정
커뮤니티 학습
PyTorch · CUDA · Triton
multi-GPU 지원
§ 01강의가 풀려는 문제· 왜 봇이 필요한가
커널 최적화 = 게임 — 측정 인프라가 곧 게임 룰
GPU 커널 최적화의 학습 곡선이 가파른 이유 중 하나 — 측정 자체가 어렵다. 자기 GPU 가 있어야 하고, async timing 패턴 알아야 하고, warmup/sync/baseline 다 챙겨야 하고, 비교할 baseline 도 직접 만들어야 한다. KernelBot 은 이 모든 단계를 봇 한 줄 명령으로 줄이는 시스템.
강의 transcript 가 누락되었지만 KernelBot 자체가 공개된 시스템 (GPU Mode 디스코드에서 도는). 본 노트는 KernelBot 의 운영 정보 + GPU Mode 커뮤니티의 공개 자료를 베이스로 강의 토픽을 추정한다.
강의의 인지적 frame · 추정
KernelBot 의 핵심 통찰 — 측정의 마찰을 0 으로 만들면 학습이 가속된다. 사용자가 새 커널 idea 가 있으면 디스코드 채널에 코드 올리고 한 명령. 30초 안에 정확성 + latency + leaderboard 위치까지 받는다. 이 빠른 feedback loop 가 곧 학습 가속 메커니즘.
“측정 인프라를 공유 자원으로 만들면 — 모든 사람이 매번 자기 환경 세팅 안 해도 된다. 마찰이 0 에 가까워질수록 시도 횟수가 폭발한다.”학습 노트 · 커뮤니티 메커니즘 정리
이 강의가 가리키는 자리 — single-user 의 도구가 아니라 커뮤니티 운영 자료. 같은 GPU(같은 baseline) 위에서 여러 사람이 같은 문제를 풀면 — leaderboard 가 자동으로 “어느 trick 이 어디서 효과적인지” 의 데이터셋이 된다.
§ 02커널 벤치마크 자동화의 가치· 매번 손으로 측정하지 않는다
“손으로 측정” 의 5가지 함정 — 봇이 한 번에 모두 해결
L001 / L056 의 어휘로 정리하면 — 손으로 GPU 커널 측정할 때 흔히 무너지는 자리들이 있다. KernelBot 은 이 자리들 모두에 sane default 를 박는다.
async timing
CUDA Event + warmup + synchronize. 잘못 짜면 launch overhead 만 측정. KernelBot 은 항상 같은 패턴.
baseline 동일성
새 커널 vs PyTorch reference 의 비교가 같은 환경에서. 사람마다 다른 GPU 사용 시 비교 불가. 봇은 항상 같은 GPU.
정확성 검증
빠르지만 잘못된 결과는 무가치. KernelBot 은 reference 와 element-wise 비교를 항상 먼저.
통계적 안정성
한 번 측정으로 끝나면 noise. 여러 번 + 분포 (median, p50, p99) 가 표준. 봇이 자동.
환경 격리
자기 데스크탑 환경에 다른 process 가 GPU 사용 중이면 noise. 봇은 깨끗한 sandbox.
leaderboard 비교
자기 결과가 SOTA 와 어디까지 가까운지 즉시 보임. 외부 벤치마크 페이퍼 안 찾아도 됨.
이 6개의 default 가 “그냥 쉬워서” 가 아니라 — 사용자의 학습 곡선에서 진짜 마찰이 있던 자리들이다. 마찰이 줄면 시도 횟수가 늘고 시도 횟수가 늘면 학습이 가속.
§ 03Discord 봇 워크플로· command → build → run → score
한 명령에서 결과까지의 전체 시퀀스
KernelBot 의 사용자 경험 — 디스코드 채널에서 명령 한 번. 그 한 명령 뒤에서 일어나는 일.
@user · #leaderboard
/leaderboard submit problem:vector_add gpu:H100 lang:cuda
[코드 첨부 — vector_add.cu]
@KernelBot 작업 시작 #38421
✓ compile (1.2s)
✓ correctness check (matched ref · max_diff = 0.0)
✓ benchmark (mean 0.014 ms · p99 0.018 ms · 50 runs)
RANK 3 / 28 on H100 · CUDA
submission saved · view leaderboard at ...
1사용자 명령/leaderboard submit problem:... gpu:... lang:...user · Discord
2queue 등록봇이 작업 ID 부여, 사용자에게 acknowledgebot · queue
3sandbox 컨테이너격리된 환경에 코드 + reference 설치runner · isolated
4buildnvcc / triton compile / pytorch importrunner · build
5correctness checkreference 와 element-wise 비교 (epsilon 허용)runner · validate
6benchmarkwarmup 5+ · 측정 50+ · CUDA Eventrunner · measure
7결과 정리median, p99, std, throughputrunner · stats
8leaderboard 업데이트data store + Discord 채널 알림bot · publish
sandbox 의 무게
"임의의 코드를 컴파일+실행" 은 보안 측면에서 위험하다. 컨테이너 격리, GPU access 제한, network 차단, time limit, memory limit 모두 필요. KernelBot 의 implementation 절반이 사실 이 sandbox 인프라.
§ 04채점 기준· correctness 먼저, 그 다음 latency
“빠르지만 틀림” 은 0점 — 정확성이 먼저
leaderboard 의 점수 함수가 명확해야 게임이 의미 있다. KernelBot 의 채점 기준 두 단계.
① correctness
reference 함수 (PyTorch eager) 와 element-wise 비교. dtype 별 epsilon — FP32 1e-5, FP16 1e-3, BF16 1e-2 등. 통과 못하면 leaderboard 에 들어가지 않음.
② latency
CUDA Event 기반 wall time. warmup 후 50회 이상. median 또는 min 이 leaderboard 점수. p99 / std 도 같이 표시.
throughput 환산
문제별 known FLOPs 또는 bandwidth 로 환산. peak 의 % 도 같이 표시.
tie-breaker
latency 1% 이내면 — 코드 줄 수, 또는 제출 시간 순. 또는 단순히 동률.
제출 횟수 제한
spam 방지. 한 사용자 / 한 문제 / 시간당 최대 N회. 마찰을 너무 줄이면 leaderboard 가 noise 로 가득.
deterministic seed
정확성 비교에서 random input 의 경우 같은 seed. 여러 사용자가 같은 input 으로.
정확성 epsilon 의 미묘함
FP16 / BF16 의 GEMM 결과는 reduction 순서에 따라 다르다. 사용자의 fast 커널이 PyTorch 와 element-wise 정확히 일치할 수 없는 경우가 흔하다. epsilon 를 너무 좁게 잡으면 valid optimization 이 거부됨, 너무 넓으면 buggy 커널이 통과. 실용적 경계를 잡는 게 운영의 한 축.
§ 05leaderboard 구조· problem · GPU · 언어
한 leaderboard 가 아니라 — N개의 작은 leaderboard 가 묶인 격자
"누가 GPU 커널을 가장 빠르게 짜는가" 같은 단일 leaderboard 는 무의미하다. 같은 GPU, 같은 문제, 같은 언어에서만 비교 가능. KernelBot 의 leaderboard 는 3차원 격자.
RKUSERMEDIANP99LANG
1@gpu_wizard0.011 ms0.014CUDA
2@triton_master0.013 ms0.016Triton
3@user0.014 ms0.018CUDA
4@hopper_fan0.016 ms0.020CUDA
5@torchitan0.022 ms0.025PyTorch
6@learner0.025 ms0.029PyTorch
↑ leaderboard 예시 — problem: vector_add · GPU: H100 (예시 데이터)
P
problem
vector_add, matmul_fp16, softmax, attention_qk, sort, reduce, ...
G
GPU
A100, H100, RTX 4090, T4, 또는 GPU 별로 별도 leaderboard
L
language
CUDA, Triton, PyTorch eager, JAX/Pallas, ROCm
S
size
같은 문제도 입력 사이즈별 — small (1K), medium (1M), large (1B)
왜 격자가 더 정직한가
같은 vector_add 라도 GPU 가 다르면 비교 불가능. CUDA 와 PyTorch 를 한 leaderboard 에 같이 두는 것도 노이즈 — PyTorch 는 어차피 일정 비율로 느릴 수밖에. 격자로 분리하면 “같은 조건” 안에서의 진짜 격차가 보인다. 그리고 같은 problem 의 다른 GPU 결과를 같이 보면 — "내 코드가 H100 에서 효과적이지만 A100 에선 안 빠르네" 같은 흥미로운 데이터가 나온다.
§ 06커뮤니티 contribution 패턴· 문제 추가 · reference 검증
운영진만 만드는 게 아니다 — 사용자도 문제를 추가
KernelBot 같은 시스템의 long-term 가치는 문제의 다양성에 달려 있다. 운영진 혼자 모든 문제 추가하면 곧 정체. 커뮤니티가 새 문제를 제출하는 메커니즘.
문제 제출 양식
PR 또는 봇 명령으로 — reference Python 함수 + 입력 generator + verification function + 예시 timing baseline.
문제 검증
운영진이 reference 가 정말 정답인지, baseline 이 적절한지 확인. correctness epsilon 결정.
문제 분류
난이도 (intro / intermediate / hard), 영역 (linear algebra / sort / reduce / fused).
평가 주기
각 문제마다 weekly digest. 누가 1위, 격차의 변화. 커뮤니티 활성화.
사용자 ranking
개인이 leaderboard 들 위에서 누적 점수. "GPU Mode 의 elite" 가시화.
코드 공개 정책
제출 후 일정 기간 (1주?) 후 코드 공개. 학습 자료가 됨. 또는 1위만 공개 등.
§ 07어떤 커널이 최적화되는가· GEMM · attention · sort · reduce
leaderboard 에 자주 등장하는 문제 카테고리
KernelBot 같은 시스템에서 자연스럽게 표적이 되는 커널들. 사용자가 실제로 도전하고 싶어하는 자리들.
CORE
vector_add
가장 단순. 모든 GPU 학습의 첫 커널. baseline 이 명확.
CORE
matmul
FP16 / BF16 / FP8. cuBLAS 가 baseline. tile 사이즈 sweep, 새 instruction 활용.
FUSED
layernorm
elementwise + reduce + scale. fusion 의 첫 사례.
FUSED
softmax
online algorithm + reduction. attention 의 sub-component.
ATTN
attention QK
FlashAttention 패턴. baseline 이 SDPA. tile + online softmax.
REDUC
argmax / topk
reduction + 정렬. warp shuffle 활용.
REDUC
sort
radix sort. CUB 가 baseline. multi-pass.
QUANT
int4 dequant + matmul
LLM inference 에 직접. weight-only quantization 의 표준.
왜 이런 커널이 인기인가
두 조건: baseline 이 분명(PyTorch eager 또는 cuBLAS) 하고, 변화시킬 수 있는 dimension 이 풍부. 이 두 조건 만족하는 커널들이 leaderboard 위에서 흥미롭다. 단순한 elementwise 는 PyTorch 가 이미 빠른 자리라 격차 만들기 어렵고, 너무 복잡한 end-to-end 는 측정이 모호해진다. 적당한 복잡도의 building block 이 sweet spot.
§ 08사례 학습· leaderboard 의 1위 코드 어떻게 짜였는가
제출 코드의 공개가 학습 자료로 — 가장 좋은 해설서
KernelBot 의 가장 큰 부산물은 leaderboard 자체가 아니라 — 1위 코드들의 archive. 같은 문제의 best 솔루션이 시간에 따라 어떻게 진화했는지가 그대로 학습 자료.
반복 패턴
같은 문제의 1위가 PyTorch → Triton → CUDA 로 진화. 또는 CUDA 안에서 naive → tiled → async copy → warp specialize.
trick 의 출처
coalescing, vectorized load (float4), warp shuffle, async pipeline, register tiling — leaderboard 위 코드에서 한 줄씩 학습.
언어별 격차
같은 문제의 PyTorch 1위 vs CUDA 1위 비율. 어떤 문제는 PyTorch 가 거의 같고, 어떤 문제는 CUDA 가 10배 빠르다. 패턴이 보임.
GPU 별 격차
같은 코드의 H100 vs A100 vs RTX. 어떤 trick 이 architecture-specific 인지.
“커널 최적화는 책으로 배우기 어렵다 — 다른 사람의 코드를 읽고 자기 코드와 비교하면서 배운다. leaderboard archive 가 가장 좋은 해설서다.”학습 노트 · 커뮤니티 학습 정리
§ 09다음 단계· multi-GPU · LLM 직접 평가
KernelBot 의 미래 — 어디로 확장될 수 있는가
강의 시점 (2025-04) 에 KernelBot 이 향하고 있던 자리들. transcript 가 없어 정확한 로드맵은 추정이지만, 자연스러운 확장 방향이 분명하다.
multi-GPU 문제
all-reduce, distributed GEMM (L046), pipeline parallel. 봇이 multi-GPU sandbox 를 띄울 수 있어야 함.
LLM 직접 평가
end-to-end inference latency. 토큰/초. 입력 길이 / batch 별 격자.
새 아키텍처
Blackwell GB200, AMD MI300, Apple M-series. 같은 문제의 cross-vendor 비교.
AI 가 coder
LLM 이 KernelBot 에 직접 제출. 사람과의 격차 측정. 학습 데이터로 활용.
교육 통합
대학 GPU 강의에서 과제 → KernelBot 자동 채점. 일관된 환경에서 학생 비교.
기업 내부판
private KernelBot. 기업 내부 GPU 인프라에 같은 워크플로 적용. CI 통합.
§ 10기억할 메모와 자료· key takeaways
측정 마찰 = 학습 마찰
async timing / baseline / sandbox / 통계 — 모두 봇이 처리. 시도 횟수 폭발.
leaderboard = 격자
problem × GPU × language × size. 단일 leaderboard 는 무의미.
correctness 먼저
epsilon 통과 못 하면 0점. dtype 별 epsilon 의 실용 경계.
median + p99 같이
단일 측정은 noise. median 이 ranking, p99 가 stability 신호.
코드 archive 의 가치
leaderboard 자체보다 1위 코드의 진화가 학습 자료.
커뮤니티 contribution
운영진 혼자 문제 추가는 정체. 사용자 PR 메커니즘 필요.
관련 시스템
Tianqi Chen 의 mlc.ai bench, NVIDIA cuBenchmark, MLPerf 등
§ 11다른 강의로 이어지는 길· connections
§ 12열린 질문· open questions
transcript 가 없어 강의의 정확한 강조점을 잡기 어렵다. 영상 직접 확인이 필요한 사항들.
- 강의 speaker — 영상 메타데이터에 speaker 누락. KernelBot 운영진(예: Mark Saroufim 또는 GPU Mode core team)일 가능성. 영상 직접 확인 필요.
- 구체적 운영 수치 — 등록 사용자 수, 제출 횟수, leaderboard 의 문제 수 — 영상에서 발화된 수치 직접 확인.
- sandbox 인프라의 실제 구현 — Docker / Kubernetes / 자체 솔루션. GPU 격리 방식 — MIG / dedicated nodes. 영상 확인 필요.
- 채점 epsilon 의 실제 값 — 본 노트의 1e-3 / 1e-2 같은 값은 일반적 표준. KernelBot 의 실제 정책이 더 엄격한지 느슨한지 영상 확인.
- 1위 코드 공개 정책 — 본 노트는 "공개" 가정. 실제로 비공개일 수 있음. 영상 확인.
- 경쟁 시스템과의 차이 — Tianqi Chen 의 mlc.ai bench, NVIDIA 의 cuBenchmark 같은 시스템과 어떻게 다른지 — 영상이 다뤘는지.
- cheating 방지 — 사용자가 reference 함수 자체를 호출하는 등의 cheating. 어떻게 막는지 — 영상 확인.
검증 메모
본 노트는 KernelBot 의 공개 운영 모습 + GPU Mode 디스코드의 일반적 작동을 베이스로 강의 토픽을 추정. 모든 sub-section 의 디테일은 강의의 발화 인용이 아니라 시스템 일반론의 정리. 실제 강의의 강조점과 운영 정책의 정확한 모양은 영상 직접 확인 필요.