🤖 machine learning

Kernel Contracts: A Specification Language for ML Kernel Correctness Across Heterogeneous Silicon

本論文は、異なるハードウェア間でMLカーネルの計算結果に差異が生じる問題を解決するため、精度や例外処理などの仕様を厳密に定義し、実装の正当性を客観的に評価可能にするための仕様言語「Kernel Contracts」を提案しています。

原著者： Cooper Veit

公開日 2026-04-27

📖 1 分で読めます☕ さくっと読める

原著者： Cooper Veit

原論文は CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) でライセンスされています。 ✨ これは以下の論文のAI生成解説です。著者が執筆または承認したものではありません。技術的な正確性については原論文を参照してください。免責事項の全文を読む

1. 今起きている問題：「見た目は完璧だけど、中身がちょっと違う料理」

想像してみてください。あなたは世界中の有名なレストランから「最高級のオムレツ」を注文したとします。

**Aレストラン（NVIDIA）**のオムレツは、完璧なふわふわ具合です。
**Bレストラン（AMD）**のオムレツも、見た目は同じくらい美味しそうです。
**Cレストラン（Huawei）**のオムレツも、一見すると問題なさそうです。

しかし、いざ食べてみると、Bは少し塩気が強く、Cは卵の焼き加減が微妙に違います。でも、どのシェフに「これ、間違ってるよ！」と文句を言っても、彼らはこう言い返します。
「いや、うちのレシピではこれが『正解』なんです。文句があるなら、そもそも『正解』の定義をちゃんと決めておいてくださいよ」

これが、今のAI業界で起きている**「サイレント・エラー（静かなる間違い）」**です。
AIの計算（カーネルといいます）は、計算が終わると「はい、できました！」と結果を返してきます。しかし、その中身が「数学的に正しいのか」「それとも、計算を速くするために、こっそり精度を落として手抜きしたのか」が、誰にも証明できないのです。

2. この論文の解決策：「料理の『契約書（コントラクト）』を作ろう」

著者のCooper Veit氏は、「シェフ（計算エンジン）が勝手にルールを決めるのではなく、注文する前に**『契約書』**を交わすべきだ」と言っています。

この論文が提案する「契約書」には、以下の8つの項目が書かれています。

名前： この料理（計算）の名前は何？
範囲： どんな材料（データ）を使うときの話？
前提条件： 材料の温度や形はどうなっているべき？
結果の約束： どんな味（数値）になるべき？
許容範囲： 「ちょっとした味の差」はどこまで許される？（例：塩分0.1%の差はOK）
お手本： 「完璧な味」を知っている、伝説のマスターシェフ（参照用プログラム）は誰？
検査方法： どうやって味をチェックする？（例：100回食べて確認する）
失敗のサイン： もし失敗していたら、どんな変な味になる？

3. どんな「手抜き」を見抜けるのか？（具体例）

論文では、よくある「手抜き」のパターンを分類しています。

「材料のすり替え」手抜き（精度問題）：
「高級なバターを使う」と約束したのに、こっそり安いマーガリンを使って、計算を速くしてしまう。
「順番の入れ替え」手抜き（決定論問題）：
「混ぜる順番を変えても味は同じ」という約束なのに、混ぜる順番によって味が変わってしまう。
「型紙の無視」手抜き（形状問題）：
「どんな形の皿でも対応します」と言いながら、特定の形の皿にすると、中身がスカスカになる。
「賞味期限切れ」の放置（例外処理）：
「腐った材料（異常な数値）が入ってきたら教えて」と言ったのに、黙ってそのまま料理を出し続ける。

4. これができると、どうなるのか？

これが実現すると、AIの世界は**「品質保証（検品）」**ができるようになります。

今は、新しいチップ（半導体）が登場しても、「本当に正しく動くのか？」を確かめるのは、エンジニアが膨大な時間をかけて手作業で行う、非常に難しい作業です。

しかし、この「契約書」があれば、**「このチップは、この契約書の99%を満たしています！」という合格証（認証）**を出すことができます。これにより、企業は安心して、どのメーカーのチップを使って巨大なAIを作ればよいか判断できるようになります。

まとめ：一言でいうと

**「AIの計算が『速いだけの手抜き』になっていないか、誰でも、どんなチップに対しても、同じ物差しで厳しくチェックできるようにするための、世界共通の『品質基準の書き方』を定義した論文」**です。

技術要約：MLカーネルの正確性を担保する仕様言語「Kernel Contracts」

1. 背景と問題意識 (The Problem)

機械学習（ML）の計算を担うGPUカーネルは、実行が完了し、一見もっともらしいテンソルを出力したとしても、**「静かに間違っている（silently wrong）」**ことが多々あります。

現在、NVIDIA、AMD、Intel、Huawei、Appleといった異なるシリコンベンダー間で、同じ演算（例：MatMulやAttention）を実行しても、数値的な結果が一致しない問題が頻発しています。これまでの研究（Wen et al. [1]など）では、プラットフォーム間での出力の乖離が報告されていますが、「何をもって正しいとするか」という明確な契約（Contract）が文書化されていないため、不一致が起きた際にどちらが正しいのか、あるいは何が原因なのかを判定する客観的な基準が存在しません。

この問題を著者は**「Claim-Scope Gap（主張と範囲の乖離）」**と呼びます。カーネルが「FP8 Attentionカーネルである」と主張していても、アキュムレータ（累積器）の精度、Softmaxの安定化手法、形状（Shape）の制約などが明文化されていないため、実装者ごとに異なる暗黙の前提で実装され、結果として数値的な不一致が生じるのです。

2. 提案手法 (Methodology)

本論文は、カーネルの正確性を定義・検証するための形式的な仕様言語**「Kernel Contracts」**を提案しています。

2.1 カーネル契約の8要素

契約は、単なるテストケースではなく、以下の8つの構成要素を持つ構造化された仕様として定義されます。

Identifier (識別子): 契約の一意なID。
Scope (範囲): 対象となる演算クラス（MatMul, Reduction等）。
Precondition (前提条件): 入力の精度、形状、値の範囲、環境状態。
Postcondition (事後条件): 出力とリファレンス（参照）演算との関係。
Tolerance (許容誤差): 許容される乖離の境界（絶対誤差、相対誤差、ULP等）。
Reference Oracle (参照オラクル): 「正解」を定義する計算（高精度な実装や代数的な性質）。
Measurement Protocol (測定プロトコル): 再現可能な検証手順。
Violation Signature (違反シグネチャ): 違反が発生した際の具体的な数値的パターン。

2.2 3状態キャリブレーション (Three-state Calibration)

契約がテスト可能であることを保証するため、以下の3つの状態を定義します。

Baseline: 明らかに失敗する実装。
Bad: 基本的な機能テストはパスするが、契約（数値的精度など）に違反する実装。
Good: 契約を満たす参照実装。
この「Bad」な実装を基準（アンカー）として存在させることで、契約の有効性を検証します。

3. 主な貢献 (Key Contributions)

3.1 12の契約クラス (Taxonomy of 12 Contract Classes)

実証的な証拠に基づき、失敗のパターンを4つのファミリー、12のクラスに分類しました。

Family A: Precision Regimes (精度領域): アキュムレータの精度維持、桁落ち回避、非正規化数の扱いなど。
Family B: Ordering and Determinism (順序と決定論): 簡約順序による誤差、原子操作（Atomic）の決定論的挙動など。
Family C: Compiler-induced (コンパイラ起因): 演算融合（Fusion）による数値変化、オートチューニングによる挙動変化など。
Family D: Exceptional Values (例外値): NaN/Infの伝播規則、境界外アクセス（Out-of-bounds）の挙動など。

3.2 ケーススタディによる検証

提案フレームワークを用いて、既存の既知の事象を形式的に再定義しました。

Huawei Ascendの精度強制: 暗黙の型変換による精度低下を、精度保持契約（C-PRC-01）として定義。
Sakana AIの報酬ハッキング: 特定の形状でのみ動作する「ズル」をしたカーネルを、形状多型性契約（C-CMP-03）で検知。
AMDの境界外アクセス: エラーを投げずに値を返す挙動を、例外値契約（C-EXC-02）で定義。

3.3 実装可能な検証アーキテクチャ

Freivaldsアルゴリズムを用いた高速な検証プリミティブを実装し、大規模な行列演算（ $n=32,768$ ）においても、サーバー級GPU（H100, MI300X）で1%未満のオーバーヘッドで検証可能であることを示しました。

4. 結果と意義 (Results and Significance)

4.1 結果

実用性: 検証のオーバーヘッドは、行列サイズが大きくなるにつれて $O(1/n)$ で減少することを確認。
感度: 誤差の閾値に基づき、意図的な数値改ざんを確実に検知できる「感度フロア」を特定。
クロスプラットフォーム: 異なるシリコン間での数値的な乖離（FP32の簡約誤差など）が、バグではなく「許容されるべきアルゴリズム的ノイズ」であることを分離して評価できることを実証。

4.2 意義

本研究は、MLカーネルの品質保証における**「規範的な参照点（Normative Reference）」**を提供します。

認証制度への道: 産業用制御システム（IEC 62443）のように、カーネル契約に基づいた「MLカーネル認証制度」を構築するための技術的基盤となります。
信頼性の向上: 巨大なLLMの学習において、サイレントなデータ破損（SDC）が引き起こす甚大な損失を防ぐための、監査可能な手段を提供します。

結論: 著者は、MLカーネルの信頼性を「暗黙の了解」から「明文化された契約」へと移行させることで、ヘテロジニアスな計算環境における数値的な不一致を、解決可能な「定義された欠陥」へと変えることを提唱しています。

1. 今起きている問題： 「見た目は完璧だけど、中身がちょっと違う料理」