論文の概要: The Correctness Illusion in LLM-Generated GPU Kernels

• arxiv url: http://arxiv.org/abs/2606.20128v1
• Date: Thu, 18 Jun 2026 11:52:46 GMT
• ステータス: 翻訳完了
• システム内更新日: 2026-06-19 18:23:39.831336
• Title: The Correctness Illusion in LLM-Generated GPU Kernels
• Title（参考訳）: LLM生成GPUカーネルの正確性イリュージョン
• Authors: Dipankar Sarkar,
• Abstract要約: LLM生成GPUカーネルのベンチマークは、固定形で小さなオールクローススタイルのチェックによって正確性を評価する。 我々は24のトリトンとCPUのスタンドインカーネルの制御コーパスを構築した。 同じプロトコルを5つのGPUクラスで再実行します。
• 参考スコア（独自算出の注目度）: 0.0
• License: http://creativecommons.org/licenses/by/4.0/
• Abstract: Benchmarks for LLM-generated GPU kernels (KernelBench, TritonBench, GEAK) score correctness through fixed-shape, small-sample allclose-style checks. The number of inputs varies between benchmarks. The shape, dtype, and tolerance are fixed for each kernel. We test that oracle empirically. We construct a controlled corpus of 24 Triton and CPU stand-in kernels (15 correct controls and 9 LLM-style buggy variants seeded with documented transcription errors) and re-evaluate it under op-schema-aware seeded fuzzing with a high-precision (fp64) CPU reference and per-(op, dtype) absolute tolerances. The seeded oracle flags 9 of 9 buggy kernels and passes 15 of 15 correct controls, at zero precision cost on controls. We extend the corpus to 26 ops (adding a flash-attention pair) and re-run the same protocol on five GPU classes (RTX 3060, A10, L40S, A100 SXM4, H100 NVL). The verdicts are identical across all five GPUs: 10 of 10 illusions caught and 16 of 16 controls clean. The corpus result is about LLM-style transcription bugs that the allclose-on-one-shape oracle certifies as correct, not about the bug rate of any specific deployed LLM. Every flagged failure replays byte-for-byte from a stored seed.
• Abstract（参考訳）: LLMが生成するGPUカーネル(KernelBench, TritonBench, GEAK)のベンチマークは、固定形、小型のオールクロース型チェックによって正当性を評価する。 インプットの数はベンチマークによって異なる。 各カーネルに対して、形状、d型、および耐性が固定される。 私たちはその神託を経験的にテストする。 我々は、24のTritonおよびCPUスタンドインカーネルの制御コーパス(15の正しい制御と9のLLMスタイルのバギーバリアント)を構築し、それを高い精度(fp64)のCPU参照と、(op,dtype)絶対許容度で、オペスキーマ対応のシードファジングの下で再評価する。 シードされたオラクルフラグは、9個のバギーカーネルの9つであり、15個の正しいコントロールのうち15個を制御の精度ゼロで通過する。 コーパスを26ops(フラッシュアテンションペアを追加)に拡張し、5つのGPUクラス(RTX 3060, A10, L40S, A100 SXM4, H100 NVL)で同じプロトコルを再実行します。 判定は5つのGPUすべてで同一で、10のイリュージョンのうち10と16のコントロールがクリーンだ。 コーパスの結果は LLM スタイルの転写バグについてであり、特定の LLM のバグ率ではなく、オールクロース・オン・ワン・シェイプのオラクルが正しいことを証明している。 フラグ付き障害は、格納されたシードからバイト単位のリプレイを行う。

関連論文リスト

• Auditing Reward Hackability in Code RL Training Environments [0.0]
  コードRL環境が誤った解を正しく受け入れる速度を計測する。 SWE-bench Verifiedの49タクのサンプルでは、28.5%のタスクがテストスイートが弱く、Dockerで検証された不正確なパッチがそれらをパスしている。
  論文  参考訳（メタデータ） (2026-06-14T23:31:42Z)
• GPU Forecasters: Language Models as Selective Surrogates for Kernel Runtime Optimization [73.92934811090163]
  カーネル評価のための選択的なGPUサロゲートとしてLLMがどのように機能するかを検討する。 限られたGPU測定予算下での高速カーネルの復旧に,その予測が正確で校正され,実用的に有用であるかどうかを計測する。 実験により,LLMは相対的なカーネル性能を正確に予測し,強化学習により性能を向上できることを示した。
  論文  参考訳（メタデータ） (2026-05-29T15:56:08Z)
• WiCER: Wiki-memory Compile, Evaluate, Refine Iterative Knowledge Compilation for LLM Wiki Systems [0.0]
  我々は17のRepLiQAドメイン間のコンパイルギャップを特徴付ける(6,800の質問)。 本稿では,このギャップを埋める反例誘導抽象化改良(CEGAR)にインスパイアされた反復アルゴリズムであるWiCERを提案する。 全17項目のアブレーションにより、汎用ピンニング(+0.16)ではなく、ターゲット診断(+0.95)がゲインを駆動していることが確認された。
  論文  参考訳（メタデータ） (2026-05-08T00:25:16Z)
• Xe-Forge: Multi-Stage LLM-Powered Kernel Optimization for Intel GPU [38.81440160993858]
  ディープラーニングアルゴリズムを新しいハードウェアアクセラレータに移植するには、開発者はコードベースのすべてのTritonカーネルに同じ低レベル最適化を適用する必要がある。 我々は、このプロセスをIntel GPU向けに自動化するマルチステージLCM駆動パイプラインであるXe-Forgeを紹介する。 キュレートされた知識ベースは、LLMトレーニングデータにはないIntel GPU制約を符号化し、モデルをアーキテクチャ上有効なバウンダリ内に保持する。
  論文  参考訳（メタデータ） (2026-04-16T20:21:01Z)
• ARGUS: Agentic GPU Optimization Guided by Data-Flow Invariants [12.49256588033198]
  LLMベースのコーディングエージェントは、機能的に正しいGPUカーネルを生成することができるが、その性能は、重要な計算に関する手動最適化ライブラリよりもはるかに低いままである。 データフロー不変量を通じてこの問題に対処するエージェントフレームワークであるArgusを紹介します。 我々は、GEMM、フラッシュアテンション、MoEカーネルにわたるAMD MI300X GPU上でArgusを評価する。
  論文  参考訳（メタデータ） (2026-04-16T15:49:31Z)
• FlashSampling: Fast and Memory-Efficient Exact Sampling [62.5203057469482]
  FlashSamplingは正確なサンプリングプリミティブで、LMヘッドのマトゥルにサンプリングを融合し、ロジットテンソルを生成しない。 H100、H200、B200、B300 GPU全体で、FlashSamplingはカーネルレベルのデコードワークロードを高速化する。 エンドツーエンドのvLLM実験では、テストしたモデルで出力トークン当たりの時間を最大19%削減します。
  論文  参考訳（メタデータ） (2026-03-16T19:37:08Z)
• Outrunning LLM Cutoffs: A Live Kernel Crash Resolution Benchmark for All [57.23434868678603]
  Live-kBenchは、新たに発見されたカーネルバグのエージェントをスクラップし、評価するセルフ進化ベンチマークの評価フレームワークである。 kEnvは、カーネルのコンパイル、実行、フィードバックのためのエージェントに依存しないクラッシュ解決環境である。 kEnvを用いて3つの最先端エージェントをベンチマークし、最初の試行で74%のクラッシュを解決したことを示す。
  論文  参考訳（メタデータ） (2026-02-02T19:06:15Z)
• Counting Without Running: Evaluating LLMs' Reasoning About Code Complexity [2.7389338551082605]
  性能ボトルネックを予測するため,LLM(Large Language Models)のベンチマークを開発した。 FLOPBenchは577カーネルの単精度と倍精度のFLOP数を予測する。 われわれはFLOPBenchをLLMツールの開発に焦点をあてたテストベッドとして位置づけた。
  論文  参考訳（メタデータ） (2025-12-04T01:03:20Z)
• Understanding and Mitigating Numerical Sources of Nondeterminism in LLM Inference [31.2331188304598]
  評価バッチサイズ、GPUカウント、GPUバージョンなどのシステム構成の変更は、生成されたレスポンスに大きな違いをもたらす可能性がある。 この変数の根本原因は、限定的な数値精度で浮動小数点算術の非連想性に遡る。 そこで我々は16ビットの精度で重みを格納するが、FP32では全ての計算を実行する軽量な推論パイプラインLayerCastを開発した。
  論文  参考訳（メタデータ） (2025-06-11T08:23:53Z)
• CrashFixer: A crash resolution agent for the Linux kernel [58.152358195983155]
  この作業は、システムレベルのLinuxカーネルバグのベンチマークと、Linuxカーネルで実験を実行するプラットフォームを共有するkGymの上に構築されている。 CrashFixerはLinuxカーネルのバグに適応する最初のLCMベースのソフトウェア修復エージェントである。
  論文  参考訳（メタデータ） (2025-04-29T04:18:51Z)

関連論文リストは本サイト内にある論文のタイトル・アブストラクトから自動的に作成しています。

指定された論文の情報です。
本サイトの運営者は本サイト（すべての情報・翻訳含む）の品質を保証せず、本サイト（すべての情報・翻訳含む）を使用して発生したあらゆる結果について一切の責任を負いません。