Skip to content
←

Split View: 확산 LLM이 CUDA 커널을 쓴다 — DICE와 왜 병렬 생성이 도움이 되는가

|

확산 LLM이 CUDA 커널을 쓴다 — DICE와 왜 병렬 생성이 도움이 되는가

들어가며 — 확산 모델이 커널을 쓴다는 주장

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는 적어도 그 가설을 진지하게 시험해 볼 가치가 있음을 보여 줍니다.

참고 자료

Diffusion LLMs That Write CUDA Kernels — DICE and Why Parallel Generation Might Help

Introduction — A Diffusion Model That Writes Kernels

In February 2026, Haolei Bai and five co-authors released the preprint "DICE: Diffusion Large Language Models Excel at Generating CUDA Kernels" (v1 2026-02-12, v2 2026-06-16). The title is provocative on its face: a diffusion LLM is good at generating CUDA kernels. Nearly every code-generation model we know is autoregressive (AR) — it appends tokens one at a time, left to right. DICE instead adapts a diffusion-family LLM to this task and claims to outperform both autoregressive and diffusion LLMs of comparable scale, setting a new state of the art (SOTA).

This post reads that preprint's abstract through an engineer's lens: why the parallel, global nature of diffusion generation plausibly helps on a hard-but-verifiable task like writing fast GPU kernels, what DICE actually did, and where honest skepticism belongs — what to believe and what to leave open. One nail up front: this is a non-peer-reviewed preprint, and the abstract carries no concrete benchmark numbers. So words like "SOTA" and "outperforms" below are all the authors' claims, not independently verified figures.

Autoregressive vs Diffusion — Why Left-to-Right Fits Code Poorly

An autoregressive model predicts one next token, commits it, and moves on. That is natural for prose but awkward for code, because it fixes the early part too soon. A wrong data structure or tile size chosen near the top of a kernel gets baked in as every later token stacks on top of it. Even when the model later realizes "ah, I should have laid out shared memory differently," a strictly left-to-right generator has no natural path back to what it already wrote.

A diffusion LLM has a different generation shape entirely. Just as image diffusion starts from noise and refines the whole picture over several steps, a discrete diffusion language model roughly starts from a fully masked sequence and, over several steps, fills every position in parallel — and rewrites positions it has already filled. Because the order is not fixed left to right, it is natural to lay down global structure first and fill in details later, or to look ahead and fix what came before: non-sequential refinement. This is exactly why the abstract argues diffusion suits code — in the authors' words, code generation is a setting where "holistic structural planning and non-sequential refinement are critical."

Autoregressive (left -> right):
  tok1 -> tok2 -> tok3 -> ... -> tokN     one token at a time
  a mistake in tok2 is frozen; later tokens only build on it

Diffusion (parallel refinement):
  [every position masked]
     |  step 1: fill a rough draft everywhere at once
     v  step 2: revise any position, in any order
  [coherent kernel]     global structure first, details later

Let me be clear about one thing. The "why it might help" above is the motivation the abstract offers plus my own reading — not a causal result the abstract proves. Whether diffusion actually won because of this property, or because of the data and training recipe, cannot be separated out from the abstract alone.

What DICE Actually Did — CuKe and Two-Stage RL

The intuition that diffusion should fit code is one thing; making it actually work on CUDA kernels is another. The abstract names two concrete obstacles: the high specialization of the CUDA domain, and a severe lack of high-quality training data. Good CUDA kernels are not lying around the internet the way ordinary Python is.

DICE attacks this on two fronts.

  • CuKe — an augmented supervised fine-tuning (SFT) dataset built for high-performance CUDA kernels. It aims squarely at the data-scarcity problem.
  • BiC-RL (bi-phase curated reinforcement learning) — a two-stage RL framework. Stage one is CUDA kernel infilling: filling in the blanks of a kernel (which meshes naturally with diffusion's mask-filling behavior). Stage two is end-to-end kernel generation: producing the whole thing from scratch.

Trained this way, DICE is presented at three scales — 1.7B, 4B, and 8B — and, per the abstract, on KernelBench it significantly outperforms comparable autoregressive and diffusion LLMs, establishing a new SOTA for CUDA kernel generation. To repeat: the abstract does not state which scale beat what by how many points. "SOTA" and "significantly outperforms" are the authors' wording, and the magnitude is unknown until you read the body and tables directly.

Why CUDA Kernels Are a Good Testbed — and Exactly Where the Trap Is

Part of what makes CUDA kernel generation an interesting testbed is that the task is verifiable. A benchmark like KernelBench (Stanford) scores an LLM-written kernel on three mechanical criteria: does it compile and run, does it match a reference PyTorch implementation numerically (correctness), and how much faster is it than that reference (speedup). All three can be measured automatically, with no human judgment.

That automatic measurability is decisive. Reinforcement learning works best when it has a clean, dense reward signal, and "compiles + correct + N-times faster" is exactly such a signal. On top of that, diffusion's iterative refinement — take a draft and rewrite it over several steps — pairs well with this kind of verification loop. In short, CUDA kernels present nearly ideal conditions for diffusion plus RL to shine.

But that same fact is the trap in reading the result. Doing well where a verifiable reward is crisp is a very different thing from doing well on open-ended code — business logic, API design, fuzzy requirements — where correctness does not reduce to compile-and-measure. Whether DICE's edge is an advantage of the diffusion paradigm itself, or the happy alignment of a "verifiable plus RL" setup, cannot be told apart from the abstract alone.

Closing — What's Interesting, What's Uncertain

What is interesting. First, the data point itself: a diffusion LLM outperforming a same-size autoregressive model on a genuinely hard systems task. It suggests the "code generation is autoregressive" default is not the only answer. Second, the infilling stage is conceptually clean — it resembles how a human refines a kernel, keeping a skeleton and filling and fixing the inside. Third, it sits on the same line as a broader trend several recent results are converging on: pairing verifiable tasks with RL.

What is uncertain. Every quantitative phrase here — "SOTA," "outperforms" — is a claim from a non-peer-reviewed preprint, and the abstract has no concrete numbers. Generalization beyond kernels is not addressed, and the verifiability trap above remains. Until the code and weights are released and the community re-measures on varied hardware and varied kernels, read it with care. Still, the direction is clear. There is no law that code generation must go left to right, and global, parallel generation can yield a real edge on verifiable tasks — DICE at least shows the hypothesis is worth testing seriously.

References