AI生成CUDA kernel、benchmark通過後にtrainingを壊したbf16の罠
Original: AI-generated CUDA kernels silently break training and inference [R] View original →
r/MachineLearningで、AI生成CUDA kernelの難しい失敗例が注目を集めた。NVIDIAのSOL-ExecBenchで上位に入ったkernelを実際のproductionに近いworkloadへ入れたところ、いくつかは意外な形で壊れたという。問題になった一つは、fused embedding-gradientとRMSNorm backward passを処理するkernelで、benchmark verifierは通過したが、小さなtransformerのtrainingではlossが発散した。
原因は単純な誤答ではなかった。embedding-gradient側の累積がfp32ではなくbf16で行われていた。tokenを均等にサンプリングすると寄与が分散し、bf16でも問題が見えにくい。実際のテキストでは一部のtoken IDに多数のgradientが集まり、小さな値が大きくなったaccumulatorに丸め込まれて消える。その結果、高頻度のembedding rowが少しずつdriftする。AdamWではper-parameter normalizationがこのbiasを吸収し、loss上では問題が隠れた。
コメント欄の論点は「verifierを通った」という言葉の弱さだった。bf16はよく使われるため見落としやすいという指摘や、optimizerとdataset sensitivityをkernel testに含めるべきだという意見が出た。厄介なのは、この種のbugが研究アイデアの失敗、datasetの問題、architectureの問題に見えてしまう点だ。
AIが生成するperformance codeは十分に速くなっている。次の課題は、実際のtrainingやservingで静かに間違えないかを検証することだ。速度を競うbenchmarkには、より広い分布とoptimizer条件を含む検証が必要になる。
Related Articles
重要なのは、長文脈やedge-side agentを実際に回せるかどうかが結局kernel最適化で決まる場面が増えていることだ。QwenはFlashQLAがNVIDIA HopperでFLA Triton比の前方2〜3倍、逆伝播2倍を出したとしている。
LocalLLaMAの最初の反応はCPネタだったが、スレッドが残った理由は別にある。GDN chunked prefillでforward 2〜3倍、backward 2倍という具体的な数字が出ていて、long-contextとedge-sideのagentic inferenceに話が直結していたからだ。
小さな新モデルより、下回りのカーネル最適化がコスト構造を動かす場面は多い。Qwenは今回のX投稿で、Hopper向け線形注意で順伝播2〜3倍、逆伝播2倍の高速化を打ち出し、コードも同時にGitHubへ置いた。
Comments (0)
No comments yet. Be the first to comment!