技術要約：トレーニング・推論カーネル・コントラクト（Kernel Contracts）

問題提起

現代のLLM（大規模言語モデル）におけるポストトレーニング・パイプラインは、方策記号 $\pi_\theta$ を単一の数学的対象として扱っています。しかし、有限精度においては、$\pi_\theta$ は2つの異なるプログラムによって評価されます。一つは、微分可能性に最適化されたトレーニング・カーネル（$K_{train}$：高精度アキュムレータ、固定形状、リファレンス・アテンションを使用）であり、もう一つは、スループットに最適化された推論カーネル（$K_{inf}$：低精度演算、ページドKVキャッシュ、動的アテンション・タイルを使用）です。

本論文は、決定的な「仕様の乖離（specification gap）」を特定しています。これら2つのカーネルは、同一の重み $\theta$ に対して、計算上異なる関数を算出します。この乖離は一様ではなく、特定の領域（例：長文コンテキスト入力、安全性に関わるプロンプトなど）に集中しており、これらは集計的なベンチマークでは過小評価されがちです。$K_{train}$ と $K_{inf}$ の混同は、以下の失敗モードを引き起こします：

1. RLにおけるオフポリシー・バイアス： 強化学習パイプライン（PPOやGRPOなど）は、$K_{inf}$ からロールアウトをサンプリングしますが、勾配の計算には $K_{train}$ を使用します。標準的なエスティメータは重要度比 $w = \pi^{K_{train}}_\theta / \pi^{K_{inf}}_\theta$ が 1 であると仮定していますが、これはバイアスを導入し、KL崩壊、報酬ハッキング、あるいは急激な性能低下として現れます。
2. デプロイメント・ドリフト： BF16で微調整されたモデルが、推論時にFP8やINT4にキャストされる際、特に稀な安全性プロンプトや構造化出力において、大幅にドリフトする可能性があります。
3. 非再現性： ヘテロジニアスなサービング・フリート（異なるハードウェアやカーネル構成）において、同一のリクエストに対して異なる出力が生成されるため、A/Bテストや安全性監査の再現性が失われます。

現在、どの程度の $K_{train}$ と $K_{inf}$ の乖離が許容されるか、どのデータ・スライスにおいて、また限界を超えた際にどのようなアクションを取るべきかを定義する、機械可読な仕様は存在しません。

手法：カーネル・コントラクト

著者らは、カーネル・コントラクト（Kernel Contract）と呼ばれる形式的な仕様オブジェクト $C = (N, S, R, \Pi)$ を提案しています。このコントラクトは、モデルのチェックポイントと共に、CI/CDパイプラインを通じてカーネルのビルドと共に移動します。

1. コントラクトの構造

コントラクトは、4つのファミリーの条項と、エスカレーション・ポリシーで構成されます。

• 数値的（Numerical, $N$）： ロジット・ドリフト（$\Delta_{logit}$）、KLダイバージェンス、全変動（TV）距離、およびRLにおける重要度比 $w$ など、生の数値的な不一致に関する制約。
• 統計的（Statistical, $S$）： top-$k$ トークンの一致、較正ドリフト（$\Delta_{ECE}$）、報酬デルタ、構造化出力のパース可能性を含む、行動結果に関する制約。
• ランタイム（Runtime, $R$）： レイテンシ、スループット、メモリ使用量（KVキャッシュを含む）、およびエラー率に関する運用上の制約。
• 観測可能性（Observability, $O$）： 違反の原因を特定できるようにするための、トレース・フィールド、カーネル・フィンガープリント、およびリプレイ・シグネチャに関する要件。
• エスカレーション・ポリシー（Escalation Policy, $\Pi$）： 違反の深刻度レベル（$L1$: 情報提供、$L2$: 品質への影響、$L3$: 安全性への影響）から、ルーティング・アクション（ログ記録、ガード、フォールバック/ロールバック）へのマッピング。

各条項は、閾値（$\tau$）、許容超過率（$\rho$）、および適用される特定のデータ・スライス（$\Sigma$）と共に定義されます。

2. 理論的境界（連鎖）

論文では、低レベルの数値誤差を高レベルの報酬誤差へと結びつける、リプシッツ連続的な境界の連鎖を導出しています。

1. ロジットから分布へ： ロジット・ドリフト（$\|\varepsilon\|_\infty$）の境界は、温度 $T$ によってスケールされた全変動距離（$\Delta_{TV}$）およびKLダイバージェンスへの境界を伝播させます。
2. 分布から報酬へ： 有界な報酬関数 $r$ に対して、期待報酬の差は $2R \cdot \Delta_{TV}$ によって抑えられます。
3. RLへの適用： サポートの重複と有界なアドバンテージの仮定の下で、論文は、重要度比 $w$（または同等に $K_{train}$ と $K_{inf}$ のポリシー間のTV距離）のトークンごとの境界が、標準的な方策勾配エスティメータのバイアスを制限することを証明しています。これは、PPOのクリッピング・パラメータ $\epsilon$ を、単なる方策更新のための信頼領域としてだけでなく、訓練・推論カーネルのペアに対する予算として再解釈したものです。

3. エンフォースメント・パイプライン

フレームワークは、コントラクトを強制するための4段階のプロモーション・パイプラインを提案しています。

1. オフラインCI： 固定データセットに対して、厳格な数値的条項を評価します。
2. シャドウ（Shadow）： ライブ・トラフィックを候補カーネルにミラーリングし、ワークロード依存のデグレを検出します。
3. カナリア（Canary）： エスカレーション・ポリシーを有効にした状態で、ライブ・トラフィックの少数を候補カーネルにルーティングします。
4. フル・プロモーション： 安定性の期間にわたって継続的にコンプライアンスが確認された後にのみ実行されます。

オンライン・ルーティング・ループは、コントラクトの健全性（$h_t$）を継続的に監視し、違反レベルに基づいて、ガードされた安全なカーネルへとトラフィックを切り替えます。

主な貢献

本論文の主な貢献は以下の3点です。

1. 概念的： 現代のLLMパイプラインにおける仕様の正しい単位は、チェックポイントやエンジン単体ではなく、$(K_{train}, K_{inf})$ のペアと、それらが一致すべき特定のデータ・スライスであるということを明らかにしました。
2. 技術的： 測定可能な数値レベル（ロジット）で制約を指定し、行動レベル（報酬）の保証を継承できる、境界の連鎖を提供しました。
3. 応用： 標準的なRLの安定化ヘリスティクス（PPOクリッピングなど）が、カーネルの乖離を制限する形式的なコントラクト条項として解釈できることを示し、これらのアーティファクトを実装するための最小限のYAML DSLの概要を述べました。

結果と検証

論文は、本研究がプロダクション規模での実証的な検証を報告していないこと、およびカーネルの乖離が議論されている失敗モードの唯一の原因であるとは主張していないことを明記しています。代わりに、本論文はフレームワークと語彙の提示を目的としています。

「結果」は、理論的な導出と、将来の検証のための実験プロトコル（セクション8）です。

• 理論的： ロジット・ドリフトの境界が報酬ドリフトの境界を意味すること、およびカーネルの不一致が方策勾配に計算可能なバイアスを導入することを示す証明。
• 提案される実験： 著者らは、フレームワークをテストするための5つの検証可能な実験（E1–E5）を概説しています。これには、数値的ドリフトのベースラインのマッピング、ハードウェア感受性のテスト、RLバイアス境界の検証、コントラクトを考慮した蒸留の探索、およびフォールト注入下での自己修復ルーティングのシミュレーションが含まれます。

意義と範囲

本論文は、RLのポストトレーニング、高スループット・サービング、形式検証、およびソフトウェア・コントラクトという、いくつかの並行する文献の間に橋渡しをする基礎的な仕様レイヤーとして位置づけられています。

• 謙虚さ： 著者らは、これが「フレームワークと語彙」の論文であることを明確にしています。カーネルの乖離を経験的に解決したと主張しているのではなく、$\pi_\theta$ に対する「欠落していたインデックス」を提供し、それを議論するための語彙を提供したと考えています。
• 今後の方向性： 論文では、4つの研究方向（コンテキストに応じた動的なコントラクト、コントラクトを考慮した蒸留、条項のサブセットに対する形式検証、自己修復ルーティング）を挙げています。
• 限界： 本フレームワークは、エンジニアリング上のオーバーヘッド（計算、ストレージ、観測性）を伴い、代理条項を最適化してしまうグッドハートの法則のリスクを伴います。また、現在の形式検証ツールはフルスケールのプロダクション・トランスフォーマーにはまだスケールできず、緩い境界と経験的なテストに依存していることも認めています。

要約すると、本論文は、訓練と推論のカーネルを、契約によって結ばれた別個のエンティティとして扱うことが、LLMデプロイメントにおける「経験則としての実装の脆弱性」から、監査可能で再現可能なエンジニアリングの実践へと移行するために必要であると主張しています。