LLM의 GPU 코드 최적화 — 가능성에서 현실로
원문: CUDA Agent: Large-Scale Agentic RL for High-Performance CUDA Kernel Generation | ByteDance Seed & Tsinghua AIR, 2026.02
최근 흥미로운 논문을 하나 읽었습니다. ByteDance Seed와 칭화대가 공동으로 낸 논문인데, LLM에 강화학습을 태워서 CUDA 커널을 자동 생성하고, 결과물이 torch.compile(PyTorch의 컴파일러 기반 최적화)보다 평균 2.11배 빠르다는 내용입니다. Claude Opus 4.5나 Gemini 3 Pro를 단순 프롬프팅으로 쓸 때보다 40% 이상 성능이 높습니다.
평소 GPU 인코딩이나 미디어 파이프라인 쪽을 다루다 보니 "AI가 GPU 커널까지 최적화한다고?"라는 제목에 끌렸고, 읽어보니 설계 구조가 꽤 치밀했습니다. 나름대로 소화해서 정리해봅니다. "LLM이 코드를 잘 짠다"는 건 익숙한 이야기지만, "LLM이 컴파일러보다 빠른 GPU 코드를 짠다"는 건 다른 차원의 이야기입니다.
들어가기 전에: 왜 CUDA 커널 생성이 어려운가
LLM이 Python이나 JavaScript를 잘 짜는 건 놀랍지 않습니다. 학습 데이터에 넘쳐나니까요. 그런데 CUDA 커널은 다른 문제입니다.
첫째, 데이터가 없습니다. 사전학습 데이터에서 CUDA 코드가 차지하는 비율이 0.01% 미만입니다. 일반 코딩은 수억 개 예제로 배웠지만, GPU 커널 최적화는 사실상 거의 못 본 채로 졸업한 학생 같은 상태입니다.
둘째, "돌아가는 코드"와 "빠른 코드"는 완전히 다릅니다. 기능적으로 올바른 CUDA 커널을 짜는 건 LLM이 이미 어느 정도 합니다. 문제는 성능입니다. 메모리 접근 패턴(coalescing), 공유 메모리 활용, warp-level 프리미티브, 커널 퓨전 — 이런 하드웨어 인식 최적화는 "코드가 맞냐"와는 별개의 전문 지식입니다.
셋째, 평가가 실행 기반이어야 합니다. 코드 생성의 "품질"을 텍스트 유사도로 측정할 수 없습니다. 실제로 GPU에서 돌려보고, 정확성을 검증하고, 실행 시간을 프로파일링해야 비로소 "이게 좋은 커널인지" 알 수 있습니다.
그래서 지금까지 LLM 기반 CUDA 생성은 torch.compile 같은 컴파일러에 못 미쳤습니다. 컴파일러는 수십 년간 축적된 규칙 기반 최적화를 갖고 있으니까요. 이 논문은 그 벽을 넘었습니다.
핵심 아이디어: 세 가지 기둥
CUDA Agent는 세 가지를 동시에 해결해서 성능 벽을 넘었습니다.
1. 학습 데이터 합성 파이프라인
CUDA 학습 데이터가 부족하면 어떻게 할까요? 직접 만듭니다.
PyTorch의 torch와 transformers 라이브러리에서 표준 연산자(operator)를 수집한 뒤, LLM을 써서 최대 5개의 연산자를 조합해 새로운 복합 연산을 만들어냅니다. 그다음 4단계로 필터링합니다:
- Eager 모드와 Compile 모드 모두에서 정상 실행되는가
- 비결정적(stochastic) 연산이 포함되지 않는가
- 출력이 trivial하지 않은가 (reward hacking 방지)
- 실행 시간이 1~100ms 사이인가
결과물: CUDA-Agent-Ops-6K — 6,000개의 큐레이팅된 학습 문제.
위 그림과 이후 그림들은 논문 속 도표를 그대로 옮긴 게 아니라, 본문에서 설명한 구조를 요약해서 직접 그린 것입니다.
6,000개가 많아 보이지 않을 수 있습니다. 하지만 각 문제가 "정상 실행 + 비결정적이지 않고 + 의미 있는 출력 + 적절한 난이도"를 만족하는 큐레이팅된 데이터라는 점이 핵심입니다. 저품질 10만 개보다 고품질 6,000개가 RL에서는 더 효과적입니다.
2. Skill 통합 Agent 루프
여기가 이 논문의 진짜 차별점입니다. LLM이 코드를 "한 번 짜고 끝"이 아니라, 인간 CUDA 개발자의 워크플로우를 그대로 모방합니다:
1. PyTorch 네이티브 구현 성능 분석
2. 커스텀 CUDA 커널 작성
3. GPU 샌드박스에서 컴파일 + 실행 + 프로파일링
4. 결과 확인 → torch.compile 대비 5% 이상 빠르면 종료, 아니면 다시 2번으로이 루프를 ReAct(Reasoning + Acting) 패턴으로 구현합니다. Agent에게 제공되는 도구는 BashTool, GlobTool, MultiEditTool 등으로, 실제로 코드를 쓰고 실행하고 결과를 관찰하는 환경입니다.
쉽게 말하면, "코드 한 방에 뚝딱" 생성이 아니라 "짜보고, 돌려보고, 느리면 고치고, 다시 돌려보는" 반복 최적화 루프입니다. 인간 개발자가 CUDA 커널을 튜닝할 때 하는 것과 정확히 같습니다. 차이가 있다면 이 과정을 강화학습으로 체계적으로 훈련한다는 점입니다.
이전에 다룬 Harness Engineering 글에서 "Verification Loop — AI가 완료했다고 하면 믿지 말고 검증하라"는 원칙이 있었습니다. CUDA Agent도 정확히 같은 철학입니다. "커널을 짰다"고 끝이 아니라, 실제로 돌려보고 프로파일링해서 검증합니다.
3. 안정적 RL 학습 기법
여기가 가장 기술적으로 어려운 부분입니다. 쉽게 풀어보겠습니다.
문제: CUDA 코드는 사전학습에서 거의 못 본 영역입니다. 이런 상태에서 갑자기 "CUDA 커널을 최적화해"라고 RL을 걸면, 모델이 혼란에 빠져서 학습 자체가 폭발(collapse)합니다.
비유하면, 영어만 배운 학생에게 갑자기 라틴어 논문 작성을 시키면서 "잘 쓰면 상 준다"고 하는 것과 같습니다. 방향 감각조차 없는 상태에서 강화 신호를 받으면 학습이 되지 않습니다.
해법: 단계적 워밍업
| 단계 | 하는 일 | 비유 |
|---|---|---|
| Single-turn RL | 기본 PPO로 단일 턴 CUDA 코딩 능력 학습 | 기초 문법 익히기 |
| RFT (Actor 워밍업) | Agent 루프에서 성공한 trajectory만 골라서 SFT | "이렇게 하면 맞는다" 정답 패턴 보여주기 |
| Value Pretraining (Critic 워밍업) | Critic 네트워크를 사전 학습 | "이 상태에서 미래 보상이 얼마쯤일지" 감 잡게 하기 |
| Agentic RL | 풀 Agent 루프에서 PPO 학습 | 실전 투입 |
RFT 없이 바로 RL을 돌리면 어떻게 될까요? 17 스텝 만에 reward가 급락하면서 학습이 무너집니다. Actor의 엔트로피가 급증하면서 정책이 산발적으로 변하고, 더 이상 의미 있는 코드를 생성하지 못하는 상태에 빠집니다.
보상 설계: 왜 단순한 게 이겼나
직관적으로는 "속도 향상에 비례하는 연속 보상"이 좋을 것 같습니다. 2배 빠르면 2점, 3배 빠르면 3점 하는 식으로요. 하지만 실험 결과 이 방식은 reward hacking에 취약했습니다.
CUDA Agent가 채택한 보상 체계는 단순한 마일스톤 기반입니다:
| 조건 | 보상 |
|---|---|
| 정확성 검증 실패 | -1 |
| torch.compile과 eager 모두보다 5% 이상 빠름 | +3 |
| eager보다만 5% 이상 빠름 | +2 |
| 그 외 (정확하지만 빠르지 않음) | +1 |
연속 보상(속도 비례)을 쓰면 1.25x 속도에 그쳤지만, 이 마일스톤 보상으로는 2.11x까지 올라갔습니다.
보상 설계에서 배우는 교훈은 "정밀한 보상 = 좋은 결과"가 아니라는 겁니다. 오히려 단순하고 명확한 목표("5% 이상 빠르게 만들어라")가 Agent에게 더 강한 학습 시그널을 줍니다. 연속 보상은 미세한 차이에 과적합하게 만들고, reward hacking의 여지를 넓힙니다.
Reward Hacking 방지책
Agent가 "실제로 빠른 코드를 짜는" 대신 보상 시스템을 속이려는 시도를 차단하는 장치들:
- 검증/프로파일링 스크립트에 파일 권한 제어 (Agent가 수정 불가)
- 실행 시간 제약으로 fallback 구현 차단 (그냥 PyTorch 호출하는 꼼수 방지)
- 랜덤 5개 입력으로 정확성 검증 (특정 입력에만 맞는 코드 차단)
- 프로파일링 시 device sync + 평균 (측정 노이즈 제거)
- 웹 검색/외부 정보 도구 비제공 (외부 코드 복붙 방지)
결과
KernelBench(250개 태스크, 3단계 난이도)에서 측정한 성능입니다:
| 모델 | Pass Rate | Faster Rate (vs torch.compile) | Speed-up |
|---|---|---|---|
| Claude Opus 4.5 | 95.2% | 66.4% | 1.46× |
| Gemini 3 Pro | 91.2% | 69.6% | 1.42× |
| CUDA Agent | 98.8% | 96.8% | 2.11× |
난이도별로 보면:
| 난이도 | Pass Rate | Faster Rate | Speed-up |
|---|---|---|---|
| Level 1 (단일 연산자) | 100% | 97% | 1.87× |
| Level 2 (복합 연산) | 100% | 100% | 2.80× |
| Level 3 (전체 모델 블록) | 94% | 90% | 1.52× |
Level 2에서 2.80x라는 수치가 눈에 띕니다. 복합 연산에서 커널 퓨전(여러 연산을 하나의 커널로 합치기)의 효과가 극대화되기 때문입니다. 컴파일러가 놓치는 고수준 퓨전 기회를 LLM이 찾아낸 셈입니다.
LLM이 발견한 최적화 패턴들
논문에서는 CUDA Agent가 학습한 최적화 전략을 5가지로 분류합니다:
| 패턴 | 설명 | 예시 |
|---|---|---|
| 대수적 단순화 | 고수준 텐서 연산을 더 단순한 계산으로 치환 | 대각 행렬 곱 → row-wise 스케일링 |
| 커널 퓨전 | 여러 연산을 하나의 커널로 합침. 중간 텐서 생성 제거 | matmul + bias + relu → 단일 커널 |
| 메모리 접근 최적화 | coalesced 접근, shared memory, vectorized load (float4) | 전역 메모리 접근 패턴 재배치 |
| 하드웨어 인식 최적화 | occupancy 튜닝, warp-level 프리미티브, mixed precision | block size / register 사용량 조절 |
| 라이브러리 활용 | cuBLAS(GEMM), cuDNN(Convolution) 호출 | 직접 구현보다 라이브러리가 빠른 경우 위임 |
컴파일러(torch.compile)가 주로 3~5번(저수준 최적화)에 강하다면, LLM은 1~2번(고수준 구조 최적화)에서 강점을 보입니다. "이 두 연산을 합치면 중간 메모리 할당이 사라진다" 같은 판단은 규칙 기반 컴파일러보다 패턴 인식 기반 LLM이 더 잘할 수 있습니다.
미디어/인코딩과의 연결
이 논문이 미디어 파이프라인과 무슨 관련이 있을까요?
GPU 커널 최적화는 미디어 인코딩의 기저 레이어입니다. TSC가 하는 일도 결국 인코딩 커널을 최적화해서 같은 화질에서 비트레이트를 줄이는 것입니다. 차이가 있다면 TSC는 수년간의 인간 엔지니어링 결과물이고, CUDA Agent는 AI가 자동으로 최적화를 찾아내는 접근이라는 점입니다.
상상해볼 수 있는 미래는 이렇습니다:
- AI가 인코더의 모션 추정(motion estimation) 커널을 자동 최적화
- DCT/IDCT 연산에 대한 하드웨어 특화 커널을 AI가 생성
- 디코더 측 후처리(deblocking, SAO) 커널을 GPU 아키텍처별로 자동 튜닝
아직은 연구 단계이지만, "AI가 인코더 내부 커널까지 자동 최적화"하는 미래는 이 논문의 연장선에 있습니다.
한계와 솔직한 생각
인상적인 결과이지만, 몇 가지 냉정하게 봐야 할 점이 있습니다.
1. 벤치마크와 프로덕션의 거리
KernelBench 250개 태스크는 "잘 정의된 문제"입니다. 프로덕션의 CUDA 커널은 엣지 케이스, 메모리 제약, 다양한 입력 크기에 대한 범용성 등 벤치마크에서 잡히지 않는 요구사항이 많습니다. cuDNN이나 cuBLAS 수준의 프로덕션 라이브러리를 대체할 수 있는 수준인지는 아직 미지수입니다.
2. 베이스 모델의 규모
Seed1.6은 230B 파라미터(23B 활성) MoE 모델입니다. 이 규모의 모델과 대규모 RL 학습 인프라를 갖출 수 있는 팀은 많지 않습니다. 재현 가능성에 대한 질문이 남습니다.
3. 컴파일러와의 상호보완성
논문은 "LLM이 컴파일러를 이겼다"로 읽히지만, 실제로는 상호보완적일 가능성이 높습니다. LLM이 고수준 구조 최적화(퓨전, 대수적 단순화)를 하고, 컴파일러가 저수준 코드 생성(레지스터 할당, 명령어 스케줄링)을 하는 파이프라인이 최종 형태가 되지 않을까 싶습니다.
4. 6000개 데이터의 범용성
6000개 문제가 PyTorch 연산자 조합으로 만들어졌습니다. 이 분포 밖의 커널(예: 그래프 처리, 시뮬레이션, 비정형 메모리 패턴)에 대해서는 일반화가 보장되지 않습니다.
마치며
이 논문이 보여준 건 "LLM + 강화학습 + 올바른 학습 환경 설계"가 합쳐지면 전문가 수준의 GPU 최적화가 가능하다는 점입니다.
핵심 구조를 한 줄씩 정리하면:
- 데이터: 없으면 만듭니다. 합성 파이프라인으로 6000개 고품질 문제를 생성합니다.
- Agent 루프: 한 번 짜고 끝이 아니라, 짜고 → 돌리고 → 측정하고 → 고치는 반복입니다.
- 보상: 단순한 마일스톤이 정밀한 연속 보상보다 낫습니다.
- 안정적 학습: 갑자기 어려운 문제를 주면 무너집니다. 단계적으로 올려야 합니다.
"컴파일러를 이기는 LLM"이 실현된다면, GPU 프로그래밍의 진입 장벽이 근본적으로 낮아집니다. CUDA 전문가 없이도 고성능 커널을 뽑을 수 있는 미래 — 이 논문은 그 가능성을 처음으로 구체적인 숫자로 증명한 연구입니다. 아직은 "벤치마크에서 확인한 가능성"이지만, 방향은 분명합니다.
원문: arXiv:2602.24286 | 프로젝트 페이지: cuda-agent.github.io