- 引言 — 扩散模型会写内核的主张
- 自回归对扩散 — 从左到右为何不适合代码
- DICE 实际做了什么 — CuKe 与两阶段强化学习
- 为什么 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)方式,也就是把 token 从左到右一个接一个地拼接。DICE 则反其道而行,把扩散系的 LLM 针对这一任务加以训练,并主张同规模的 AR 模型和扩散模型两者均被其超越,创下新的最高性能(SOTA)。
本文是用工程师的眼光去读这篇预印本摘要的一份解读。并行、全局生成这一扩散特性,为什么可能对像写高速 GPU 内核这样"困难却可验证"的任务有帮助;DICE 究竟做了什么;以及一份诚实的怀疑 — 哪些可以相信、哪些要保持存疑 — 都会在这里梳理。先把话说死:这还是一篇未经同行评审的预印本,摘要里没有具体的基准测试数字。所以下文的"SOTA""超越"之类的表述全都是作者的主张,而非独立验证过的数值。
自回归对扩散 — 从左到右为何不适合代码
自回归模型预测并确定下一个 token,然后再往后走。对散文来说很自然,但对代码就有别扭的地方 — 因为它把前面的部分定得太早。在内核开头选错的数据结构或 tile 大小,会随着后续所有 token 堆叠在它之上而被事实上固定下来。哪怕之后才意识到"啊,共享内存本该换一种取法",对一个只从左往右写的模型来说,也没有一条自然的路径去回退已经写好的前半部分。
扩散 LLM 生成的形态本身就不同。就像图像扩散从噪声出发、分多个阶段打磨整幅画那样,离散(discrete)扩散语言模型从一个大体上全被遮蔽(mask)的序列开始,分多步并行地填充所有位置,并对已经填好的位置再做改写。由于顺序不被固定为从左到右,先定下全局结构、细节稍后再补,或者回头看后文来修正前文的非顺序修改就变得很自然。摘要说"扩散适合代码"的依据正在于此 — 用作者的话说,代码生成正是"整体结构设计(holistic structural planning)"和"非顺序精炼(non-sequential refinement)"至关重要的场合。
自回归(从左 → 到右):
tok1 → tok2 → tok3 → ... → tokN 一次一个 token
tok2 的错误就此固定 — 后续 token 只能堆在其上
扩散(并行精炼):
[所有位置都被遮蔽的状态]
│ 步骤 1: 一次性在整体上填入粗略草稿
▼ 步骤 2: 在任意位置、以任意顺序修改
[一致的内核] 先全局结构,细节在后
有一点要说清楚。上面的"为什么会有帮助"是摘要给出的动机加上我的解读,而不是摘要证明的因果。扩散究竟是真的靠这一性质取胜,还是靠数据和训练方法取胜,单凭摘要无法分辨。
DICE 实际做了什么 — CuKe 与两阶段强化学习
"扩散似乎很适合代码"这一直觉,和让它在 CUDA 内核上真正奏效,是两回事。摘要指出了两道现实的障碍。一是 CUDA 这一领域的高度的专业性,二是高质量训练数据的极度匮乏。写得好的 CUDA 内核,并不像普通 Python 代码那样在网上遍地都是。
DICE 从两条路径攻克这个问题。
- CuKe — 针对高性能 CUDA 内核做了增强的监督微调(SFT)数据集。它正面瞄准数据匮乏的问题。
- BiC-RL(bi-phase curated reinforcement learning)— 两阶段强化学习框架。第一阶段是 CUDA 内核填充(infilling),即填补内核空缺处的任务(这与扩散填充掩码的特性自然契合)。第二阶段是端到端(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 Ke...