テクニカル・サマリー：LLMが生成するGPUカーネルはプロダクション環境に耐えうるか？

1. 問題提起

大規模言語モデル（LLM）によるGPUカーネル生成の現在のベンチマークは、実際のデプロイされたワークロードとは大きく乖離した、合成データまたは精選されたデータセットに依存している。既存の評価手法は、以下の3つの重要な軸を捉えきれていない：

1. シェイプ分布（Shape Distribution）: プロダクション環境のフリートは、極端に偏った分布を示す（例：上位5つのオペレータがGPUのウォールタイムの約64%を消費する）。一様で合成的なグリッドではこれを再現できない。
2. オペレータの重要度（Operator Importance）: 重み付けのない平均値は、稀なエレメントワイズ演算と、レイテンシを支配する融合アテンション（fused-attention）パスを同一に扱っており、カーネル性能の実際のインパクトを誤認させている。
3. パフォーマンス・ベースライン（Performance Baselines）: ベンチマークは、最適化されていないベースラインではなく、各問題のシェイプに特有のハードウェア・ルーフライン（理論上の限界速度）と比較されるべきである。

さらに、既存の評価には「正当性の錯覚（correctness illusion）」が存在する。モデルは、ターゲットとなるドメイン固有言語（DSL）のコードを生成するのではなく、PyTorchのフォールバックや事前コンパイルされたベンダー製カーネルに委譲することで、正当性チェックを通過できてしまうため、実際のカーネル記述能力を過大評価させてしまう。

2. メソドロジー

2.1 Atrex-Bench: プロダクション由来のベンチマーク

著者らは、フルクラスターのプロダクション・インファレンス・トレース（XPU-A3およびH20アクセラレータにわたる10,000ユニット以上のデプロイ実績）から直接取得されたベンチマークである Atrex-Bench を導入する。

• データソース: 20のデプロイ済みモデル（vLLM、SGLang、AITER、RTP-LLMを含む）にわたる1,303のプロファイルからサンプリングされた、30のオペレータと440の「ホット・シェイプ（hot shapes）」。
• 重要度重み付け: 各 $(operator, shape)$ ペアには、観測されたGPU時間のシェアに基づいた重み $w_i$ が割り当てられ、これはアプリケーションのカード時間によって重み付けされ、サービングフェーズ（プリフィル vs デコード）ごとに分離されている。
• スコアリング・メカニズム:
  • 問題ごとのルーフライン（Per-Problem Roofline）: 各シェイプに対し、候補のプロファイルとは独立して、セマンティックな演算量とメモリトラフィックに基づくハードウェア固有のスピード・オブ・ライト・レイテンシ ($T_{roofline}$) が計算される。
  • 集計スコア ($S_{agg}$): 最終的な指標は、ルーフライン達成率の重要度重み付き集計である：$S_{agg} = \sum w_i S_i$。ここで $S_i$ はオペレータのメディアン（中央値）のルーフライン達成率である。これにより、スコアが実際にプロダクション時間を消費するオペレータの性能を反映するようにしている。
• 評価契約（Evaluation Contract）: エージェントが既知のカーネル名やスコアリング数式を悪用することを防ぐため、ベンチマークは生成プロセス中にアップストリームのプロベナンス（由来）とルーフラインのアーティファクトを隠蔽する。また、コンパイル、正当性（PyTorchリファレンスに対する）、パフォーマンスの3段階のゲートを強制する。

2.2 Atrex-Kernel-Agent (AKA)

パフォーマンスのギャップに対処するため、著者らはプロファイル駆動型の最適化エージェントである AKA を開発した。これには以下が含まれる：

• 反復的計測・修正探索（Iterative Measure–Revise Search）: プロファイラからのフィードバックを使用して、カーネルを反復的に洗練させるワークフロー。
• 最適化ドロップアウト（Optimization Dropout）: スタールした探索コンテキストから脱出するためのメカニズム。受け入れられたカーネルと監査証跡を保持しつつ、古い反復メモリをマスクすることで部分的な再起動を行う。
• 階層化ナレッジベース（Layered Knowledge Base）: 298個のリファレンス・カーネル・ファイル、244個の最適化知識ドキュメント、およびAPI/ISAルックアップのための外部アップストリーム・プロジェクトを組み合わせたリトリーバル・システム。

3. 主な結果

3.1 フロンティア・エージェントの評価

6つのフロンティア・コーディング・エージェント（Claude Opus 4.7、GPT-5.5、Qwen3.7-Max、Kimi-K2.6、GLM-5.1、DeepSeek-V4-Proを含む）をAtrex-Benchで評価した。

• パフォーマンス・ギャップ: 最良のモデル（GPT-5.5）でさえ、ハードウェア・ルーフラインのわずか 10.7% しか達成できなかった（$S_{agg} = 0.107$）。どのエージェントも、既存の手動チューニングされたプロダクション・カーネルには及ばなかった。
• 正当性の錯覚: 「正当性（Correctness）」と「ターゲットDSLの採用率（Target-DSL Adoption）」の間には顕著な差が存在する。例えば、Qwen3.7-Maxは84.8%の正当性を達成したが、FlyDSLの採用率は43.8%にとどまった。これは、ネイティブなカーネルを書くのではなく、頻繁にPyTorchのフォールバック（例：scaled_dot_product_attention）に依存していることを示している。
• オペレータの難易度: パフォーマンスはオペレータに強く依存する。9つのオペレータはすべてのモデルによって解決されたが、最も困難なもの（例：fp8_blockscale_fused_moe）のパス率はわずか22.2%であった。
• レジームへの感度: エージェントは、行列エンジン・スケジューリングを必要とする**計算量バウンド（compute-bound）のオペレータよりも、帯域幅を飽和させるメモリバウンド（memory-bound）**のオペレータにおいて、有意に高い性能を示した。GPT-5.5は、計算量バウンドのタスクにおいて意味のある割合のルーフラインに到達した唯一のモデルであり、これがその優れた集計スコアを牽引した。
• 生成量: 生成された出力トークンの量と、結果として得られるカーネルの品質の間には相関関係はない。DeepSeek-V4-Proは最も多くのトークン（6.56M）を生成したが、最も低いルーフライン・スコアを記録した一方で、GPT-5.5は最小限のトークンで最高のスコアを達成した。

3.2 エージェントの最適化 (AKA)

制御されたケーススタディにおいて、AKAはギャップを埋める能力を実証した：

• ゼロであったFlyDSLフォールバックを実際のカーネルへと変換し、ほぼ100%のFlyDSL採用率を達成した。
• アテンション・オペレータにおいて、AKAはより強力なモデルにおけるルーフライン・スコアを0.28から0.42へと向上させた。
• 生成されたカーネルは、テストされた両方のアテンション・オペレータにおいて、手動チューニングされたプロダクション・ベースラインを上回った。

4. 貢献と意義

本論文の主な貢献は以下の4点である：

1. Atrex-Bench: フルクラスターのプロダクション・トレースに由来し、重要度重み付けされた問題ごとのルーフライン指標でスコアリングされる、初のカーネル生成ベンチマーク。
2. リリース・コントラクト（Release Contract）: プロダクション由来のリファレンス、隠蔽されたプロベナンス、隠蔽されたルーフライン・アーティファクト、および評価のハッキングを防ぐための更新可能な重要度重みを含むパッケージング標準。
3. 実証的評価: フロンティア・エージェントの現状を定量化し、最良のモデルであってもプロダクション・オペレータに対しては約10%のハードウェア・ルーフラインにしか到達しないこと、および「正当性」だけではフォールバックへの委譲により誤解を招く指標であることを明らかにした。
4. Atrex-Kernel-Agent (AKA): ドメイン知識のギャップ（ルーフライン推論、命令選択）を緩和し、フォールバックを手動チューニングされたベースラインを超える高性能なカーネルへと変換することに成功した、プロファイル駆動型最適化エージェント。

意義: 本研究は、現在のLLMコーディング・エージェントは、プロダクション環境におけるカーネルの代替としてはまだ準備ができていないと主張している。主なボトルネックは、生のコーディング能力ではなく、ドメイン固有の知識（ルーフライン推論、ハードウェア固有のスケジューリング）および、仕様をフォールバックによって「ショートカット」しようとする傾向である。論文は、今後の進展には、単なる静的なコード生成ではなく、反復的な最適化ループと深いハードウェア知識を備えたエージェントが必要であることを示唆している。