- はじめに — 拡散モデルがカーネルを書くという主張
- 自己回帰か拡散か — 左から右がコードに合わない理由
- 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 の誤りは固定され、後続はその上に積むだけ
拡散(並列精製):
[すべての位置が mask された状態]
| ステップ 1: 全体に粗い下書きを一度に埋める
v ステップ 2: どの位置でも、どの順でも直す
[一貫したカーネル] 大域構造が先、細部は後
一つはっきりさせておきます。上の「なぜ効きうるか」は、アブストラクトが示す 動機 と私の解釈であって、アブストラクトが証明した因果ではありません。拡散が本当にこの性質のおかげで勝ったのか、それともデータと訓練法のおかげなのかは、アブストラクトだけでは切り分けられません。
DICE が実際にしたこと — CuKe と 2 段階の強化学習
拡散がコードに合いそうだという直観と、それを CUDA カーネルで実際に効かせることとは別問題です。アブストラクトは二つの現実的な障壁を挙げます。一つは CUDA という領域の 高い専門性 、もう一つは 高品質な訓練データの深刻な不足 です。よくできた CUDA カーネルは、ありふれた Python コードほど無数にネット上に転がってはいません。
DICE はこれを二つの方向から攻めます。
- CuKe — 高性能な CUDA カーネル向けに増強した教師ありファインチューニング(SFT)データセットです。データ不足の問題を正面から狙います。
- BiC-RL(bi-phase curated reinforcement learning)— 2 段階の強化学習フレームワークです。第 1 段階は CUDA カーネルのインフィリング(infilling) 、すなわちカーネルの空所を埋める課題です(mask を埋める拡散の性質と自然にかみ合います)。第 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 は少なくとも、その仮説を真剣に試す価値があることを示しています。
参考資料
현재 단락 (1/27)
2026 年 2 月、Haolei Bai ほか 6 名は "DICE: Diffusion Large Language Models Excel at Generating CUDA Kernel...