- Published on
확산 LLM이 CUDA 커널을 쓴다 — DICE와 왜 병렬 생성이 도움이 되는가
- Authors
- Name
- Youngju Kim
- @fjvbn20031
- 들어가며 — 확산 모델이 커널을 쓴다는 주장
- 자기회귀 대 확산 — 코드에 왼쪽에서 오른쪽이 안 맞는 이유
- DICE가 실제로 한 것 — CuKe와 2단계 강화학습
- 왜 CUDA 커널이 좋은 시험대인가 — 그리고 바로 그 점이 함정
- 마치며 — 무엇이 흥미롭고 무엇이 불확실한가
- 참고 자료
들어가며 — 확산 모델이 커널을 쓴다는 주장
2026년 2월, Haolei Bai 등 6명은 "DICE: Diffusion Large Language Models Excel at Generating CUDA Kernels" 프리프린트를 공개했습니다(v1 2026-02-12, v2 2026-06-16). 제목부터 도발적입니다 — 확산(diffusion) LLM이 CUDA 커널 생성을 잘한다. 우리에게 익숙한 코드 생성 모델은 거의 다 자기회귀(autoregressive, AR) 방식, 즉 토큰을 왼쪽에서 오른쪽으로 한 개씩 이어 붙이는 모델입니다. DICE는 그 대신 확산 계열 LLM을 이 과제에 맞춰 학습하고, 같은 규모의 AR 모델과 확산 모델을 모두 능가해 새로운 최고 성능(SOTA)을 세웠다고 주장합니다.
이 글은 그 프리프린트의 초록을 엔지니어의 눈으로 읽는 해설입니다. 병렬·전역 생성이라는 확산의 성질이 왜 빠른 GPU 커널을 쓰는 것처럼 어렵지만 검증 가능한 과제에 도움이 될 법한지, DICE가 실제로 무엇을 했는지, 그리고 정직한 회의 — 어디까지 믿고 어디를 열어 둘지 — 를 정리합니다. 먼저 못을 박아 둘 것: 이건 아직 동료평가를 거치지 않은 프리프린트이고, 초록에는 구체적 벤치마크 수치가 없습니다. 그래서 아래의 "SOTA", "능가" 같은 표현은 모두 저자들의 주장이며 독립적으로 검증된 값이 아닙니다.
자기회귀 대 확산 — 코드에 왼쪽에서 오른쪽이 안 맞는 이유
자기회귀 모델은 다음 토큰 하나를 예측해 확정한 뒤 그다음으로 넘어갑니다. 산문에는 자연스럽지만 코드에는 불편한 구석이 있습니다 — 앞부분을 너무 일찍 확정해 버리기 때문입니다. 커널 앞머리에서 잘못 고른 자료구조나 타일 크기는, 뒤에 오는 모든 토큰이 그 위에 쌓이며 사실상 고정됩니다. 나중에 "아, 공유 메모리를 다르게 잡았어야 했네"를 깨달아도, 왼쪽에서 오른쪽으로만 쓰는 모델에게는 이미 쓴 앞부분을 되돌릴 자연스러운 경로가 없습니다.
확산 LLM은 생성의 모양 자체가 다릅니다. 이미지 확산이 노이즈에서 시작해 그림 전체를 여러 단계에 걸쳐 다듬듯, 이산(discrete) 확산 언어 모델은 대략 전부 가려진(mask) 시퀀스에서 시작해 여러 스텝에 걸쳐 모든 위치를 병렬로 채우고, 이미 채운 위치도 다시 고쳐 씁니다. 순서가 왼쪽에서 오른쪽으로 고정되지 않으니, 전역 구조를 먼저 잡고 세부를 나중에 메우거나 뒤를 보고 앞을 고치는 비순차적 수정이 자연스럽습니다. 초록이 "코드에 확산이 잘 맞는다"고 말하는 근거가 정확히 이것입니다 — 저자들의 표현으로, 코드 생성에는 "전체적 구조 설계(holistic structural planning)"와 "비순차적 정제(non-sequential refinement)"가 중요하다는 것입니다.
자기회귀(왼쪽 → 오른쪽):
tok1 → tok2 → tok3 → ... → tokN 한 번에 한 토큰
tok2의 실수는 그대로 고정 — 뒤 토큰은 그 위에 쌓일 뿐
확산(병렬 정제):
[모든 위치가 가려진 상태]
│ 스텝 1: 전체에 거친 초안을 한꺼번에 채움
▼ 스텝 2: 어느 위치든, 어떤 순서로든 다시 고침
[일관된 커널] 전역 구조 먼저, 세부는 나중에
한 가지 분명히 해 둡니다. 위의 "왜 도움이 되는가"는 초록이 제시하는 동기이자 제 해석이지, 초록이 증명한 인과가 아닙니다. 확산이 정말 이 성질 덕분에 이겼는지, 아니면 데이터와 학습 방법 덕분인지는 초록만으로 갈라낼 수 없습니다.
DICE가 실제로 한 것 — CuKe와 2단계 강화학습
확산이 코드에 잘 맞을 것 같다는 직관과, 그것을 CUDA 커널에서 실제로 통하게 만드는 것은 다른 문제입니다. 초록은 두 개의 현실적 장벽을 지목합니다. 하나는 CUDA라는 영역의 높은 전문성, 다른 하나는 고품질 학습 데이터의 극심한 부족입니다. 인터넷에는 잘 짜인 CUDA 커널이 평범한 파이썬 코드만큼 널려 있지 않습니다.
DICE는 두 갈래로 이 문제를 공략합니다.
- CuKe — 고성능 CUDA 커널에 맞춰 증강한 지도학습(SFT) 데이터셋. 데이터 부족 문제를 정면으로 겨냥합니다.
- BiC-RL(bi-phase curated reinforcement learning) — 2단계 강화학습 프레임워크. 1단계는 CUDA 커널 인필링(infilling), 즉 커널의 빈 곳을 메우는 과제입니다(마스크를 채우는 확산의 성질과 자연스럽게 맞물립니다). 2단계는 종단(end-to-end) 커널 생성, 즉 처음부터 끝까지 통째로 만들어 내는 과제입니다.
이렇게 학습한 DICE는 1.7B·4B·8B 세 가지 규모로 제시되며, 초록에 따르면 KernelBench에서 같은 규모의 자기회귀·확산 LLM을 모두 유의미하게 능가해 CUDA 커널 생성의 새로운 SOTA를 세웠다고 합니다. 다시 강조하지만, 초록은 어느 규모가 무엇을 몇 점 이겼는지 구체적 수치를 제시하지 않습니다. "SOTA"와 "유의미하게 능가"는 저자들의 서술이고, 본문과 표를 직접 확인하기 전까지는 그 크기를 알 수 없습니다.
왜 CUDA 커널이 좋은 시험대인가 — 그리고 바로 그 점이 함정
CUDA 커널 생성이 흥미로운 시험대인 이유는, 이 과제가 검증 가능하기 때문입니다. KernelBench(스탠퍼드) 같은 벤치마크는 LLM이 쓴 커널을 세 가지 기계적 기준으로 채점합니다 — 컴파일되어 도는가, 기준 PyTorch 구현과 수치가 일치하는가(정확성), 그리고 그 기준보다 얼마나 빠른가(속도 향상). 세 가지 모두 사람의 판단 없이 자동으로 잴 수 있습니다.
이 "자동으로 잴 수 있음"이 결정적입니다. 강화학습은 깨끗하고 촘촘한 보상 신호가 있을 때 가장 잘 작동하는데, "컴파일 성공 + 정답 + 몇 배 빠름"이 바로 그런 신호입니다. 게다가 확산의 반복적 정제 — 초안을 놓고 여러 스텝에 걸쳐 고쳐 쓰는 방식 — 은 이런 검증 루프와 궁합이 좋습니다. 요컨대 CUDA 커널은 확산과 강화학습이 빛나기에 거의 이상적인 조건을 갖춘 과제입니다.
그런데 바로 그 점이 이 결과를 읽는 함정이기도 합니다. 검증 가능한 보상이 명확한 과제에서 잘 되는 것과, 정답이 컴파일·측정으로 딱 떨어지지 않는 열린 코드(비즈니스 로직, API 설계, 애매한 요구사항)에서 잘 되는 것은 전혀 다른 이야기입니다. DICE의 강점이 확산이라는 패러다임 자체의 우위인지, 아니면 "검증 가능 + 강화학습"이라는 조건이 마침 잘 맞아떨어진 결과인지 — 초록만으로는 구분되지 않습니다.
마치며 — 무엇이 흥미롭고 무엇이 불확실한가
무엇이 흥미로운가. 첫째, 확산 LLM이 진짜로 어려운 시스템 과제에서 같은 규모의 자기회귀 모델을 능가했다는 데이터 포인트 자체입니다. "코드 생성은 자기회귀"라는 기본값이 유일한 답은 아닐 수 있음을 시사합니다. 둘째, 인필링 단계가 사람이 커널을 다듬는 방식 — 골격을 두고 안을 채우며 고치는 — 과 닮았다는 점이 개념적으로 깔끔합니다. 셋째, 검증 가능한 과제와 강화학습의 결합이라는, 요즘 여러 결과가 수렴하는 방향과 맞닿아 있습니다.
무엇이 불확실한가. 이 글의 모든 정량 표현 — "SOTA", "능가" — 은 동료평가 전 프리프린트의 저자 주장이고, 초록에는 구체적 숫자가 없습니다. 커널 밖으로의 일반화는 초록이 다루지 않으며, 앞서 말한 검증 가능성 함정이 그대로 남습니다. 코드와 가중치가 공개되어 커뮤니티가 여러 하드웨어·여러 커널에서 다시 재기 전까지는 신중하게 읽는 게 맞습니다. 그럼에도 방향성은 또렷합니다. 코드 생성이 반드시 왼쪽에서 오른쪽이어야 할 이유는 없고, 전역·병렬 생성이 검증 가능한 과제에서 실질적 이점을 낼 수 있다 — DICE는 적어도 그 가설을 진지하게 시험해 볼 가치가 있음을 보여 줍니다.