


JITでコンパイルするGPUカーネルライブラリに、カーネルを足してテストする
使う時にコンパイルする(JIT)GPUカーネルライブラリを、AIに直させる時に使う。カーネルを全部の層に通して足し、生成したファイルは書き込める場所にだけ置き、GPUの種類ごとにテストし、結果が正しいかを確かめてから速さを測る。
このAIルールを使うには
## カーネルを直すと自動でコンパイルし直される、編集可能インストールを用意する
環境内の既存フレームワークとアクセラレーターのバージョンを維持できる編集可能インストールを使用する。
互換性のないランタイムパッケージを取り込む可能性がある場合、分離された依存関係解決を無効にする。
ビルドまたはテストの前に、必要なすべてのソースサブモジュールを初期化する。
ジャストインタイムコンパイルをデフォルトの開発ループとして扱う。
カーネルソースを編集して限定テストを実行し、ソースハッシュによって再コンパイルを起動させる。
パッケージングコード自体を変更していない限り、カーネルを編集するたびにパッケージを再インストールしてはならない。
古い成果物が診断対象に含まれる場合に限り、JITキャッシュを消去する。
初回利用の高速化または配布で必要な場合に限り、プリコンパイル済みカーネルパッケージを使用する。
通常の開発では、プリコンパイル済み成果物を任意とする。
検出されたローカルGPU以外のデバイス向けにビルドするときは、対象アーキテクチャを明示的に設定する。
利用可能なメモリに応じて、コンパイラスレッド数と並列ビルドジョブ数に上限を設ける。
総コンパイルメモリを、ジョブ数、コンパイラスレッド数、スレッド当たりの必要量の積として見積もる。
テストパラメーターのサイズによって回避可能なデバイスメモリ枯渇を起こしてはならない。
正確なハードウェア計時が必要な場合に限り、プロファイリング支援機能をインストールする。
レビュー前にフォーマット処理とリポジトリフックを実行する。
## 生成ファイルは書き込めるワークスペースにだけ書き、インストール先には書かない
各コンパイルツールチェーンを共通の仕様インターフェースで表現する。
各仕様に一意の名前、ソース一覧、コンパイラフラグ、リンカーフラグ、対応アーキテクチャを与える。
共有のビルド・ロードテンプレートを使用し、キャッシュ検索、ロック、コンパイル、ロードを調整する。
ライフサイクルを明示する。まずキャッシュからのロードを試し、必要ならビルドし、その後コンパイル済みモジュールをロードする。
無効化フラグが設定され、有効なキャッシュ済みモジュールまたはプリコンパイル済みモジュールが存在しない場合は、JITコンパイルを拒否する。
インストール済みパッケージのディレクトリは読み取り専用の場合があるため、生成ファイルをそこへ書き込んではならない。
ソーステンプレートとプリコンパイル済みパッケージデータは読み取り専用に保つ。
レンダリング済みソースとコピーしたコンパイル単位は、生成ソース用ワークスペースにのみ書き込む。
オブジェクトファイル、共有ライブラリ、メタデータ、ビルドファイルは、JIT成果物用ワークスペースにのみ書き込む。
正確なソース一覧とコンパイルフラグからビルドマニフェストを生成する。
共有環境、一時作業環境、制限付き環境に合わせて、ワークスペースの場所を上書きできるようにする。
アーキテクチャコンテキストを使用し、検出したデバイスと明示的に要求された対象を組み合わせる。
コンパイル開始前に、モジュールを対応アーキテクチャファミリーに限定する。
要求されたアーキテクチャがどれもサポートされていない場合は、明確に失敗させる。
異なるデバイスファミリー向けに暗黙的なコンパイルを行ってはならない。
## 新しいカーネルを、デバイスコードから公開APIまで順に足す
フレームワークに依存しないデバイスコードを、生ポインターと移植可能なカーネル型に対して実装する。
再利用可能なカーネルのインクルード層にフレームワークのヘッダーを含めない。
バインディング層にランチャーを追加し、テンソルを検証して呼び出しパラメーターを準備する。
プロジェクトの型付き言語間FFIを通じてランチャーをエクスポートする。
特殊化パラメーターから決定論的な操作URIを計算する。
書き込み可能なソースワークスペース内に、操作ごとの生成ディレクトリを作成する。
具体的な型またはパラメーターの特殊化が必要な場合に限り、テンプレートを使用する。
内容が異なる場合に限り、レンダリング済み構成を書き込む。
必要なコンパイル単位を生成ディレクトリへコピーする。
URI、ソース、フラグ、アーキテクチャ制限を含むコンパイル仕様を返す。
ロード済みモジュールを再利用するキャッシュ付き上位APIを提供する。
配布で必要な場合は、事前コンパイルパッケージ生成用に操作を登録する。
パッケージのエントリーポイントから外部向けAPIをエクスポートする。
軸、入力、出力、任意の参照を定義するトレーステンプレートを関連付ける。
計画・実行APIでは、実行を行うメソッドにトレースを関連付ける。
現実的なトレース例を追加し、ベンチマーク定義成果物を再生成して、期待される結果をコミットする。
再生成後、トレース整合性テストとエンドツーエンドテストを実行する。
## 対応しないGPUはテストを飛ばし、速さは正しさの確認と一緒に示す
広範な検証には完全なテストスイートを実行し、反復中は限定テストを実行する。
サポート対象外のハードウェアは、中央の能力判定ヘルパーを通じて意図的にスキップする。
APIが判定関数を提供する場合は、デバイスの計算能力とバックエンドの対応状況の両方を確認する。
各機能のアーキテクチャ要件を明示する。
サポート対象外のアーキテクチャをテスト失敗に変えてはならない。
ローカルデバイスが異なるという理由で、サポート対象のアーキテクチャをスキップしてはならない。
回避可能なメモリ不足によるスキップを起こさずに、契約を検証できるテスト形状を選ぶ。
変更の影響を受けるアテンション、行列乗算、専門家混合、通信、ユーティリティの各経路を対象にする。
集合テストまたは分散テストには、複数デバイス対応の起動ツールを使用する。
比較可能なバックエンドとバッチ構成をサポートする統一ハーネスを通じてベンチマークを実行する。
ハードウェアレベルのプロファイラー計時を優先し、利用できない場合はアクセラレーターイベントを使用する。
各ベンチマーク結果を生成した計時機構を記録する。
中央値、変動、反復回数、ワークロード形状、データ型、アーキテクチャ、バックエンドを報告する。
カーネルを比較するときは、参照結果との照合を有効にする。
正しさの確認と再現可能なパラメーターなしに、速度を主張してはならない。
性能に影響するカーネルを承認する前に、ベンチマークとテストの証拠を必須とする。
## ソースや対象のGPUが変わったら、キャッシュしたカーネルを作り直す
ロード済みモジュールにはプロセス内キャッシュを、コンパイル済み成果物にはディスクキャッシュを使用する。
ソース、フラグ、アーキテクチャ、パラメーター、ライブラリバージョンが変わった場合は、キャッシュ済みモジュールを無効化する。
操作種別、パラメーター、ソースハッシュ、フラグ、対象アーキテクチャからキャッシュIDを導出する。
特殊化の種類およびツールチェーンの違いをまたいで、キャッシュキーを一意に保つ。
成果物の隣に互換性メタデータを保存し、ロード前に検証する。
並行プロセスが共有成果物を破損しないよう、ロックでコンパイルを保護する。
単一アーキテクチャ用DSLの生成結果は、メタデータ付きの単一モジュールディレクトリと、特殊化ごとのオブジェクトに保存する。
DSLのコンパイル対象またはアクティブなデバイスからアーキテクチャを導出する。
コンパイラパッケージのバージョンまたはカーネルソースのハッシュが変わった場合は、DSLモジュールを無効化する。
診断時にはキャッシュを無効にできるようにしつつ、デフォルトでは再利用を有効に保つ。
データ型とブロックサイズの組み合わせ空間は、ディスパッチマクロまたは生成コードで管理する。
ディスパッチの選択肢を明示し、サポート対象外の組み合わせをテストする。
直接記述したソースで十分な場合は、テンプレート化を追加してはならない。
古いプリコンパイル済みパッケージがバージョン互換性検査を迂回できないようにする。
意図的に診断する混在バージョン実験に限り、バージョン検査を迂回する。
## クラッシュを再現できるよう、カーネルを動かす前にAPIの入力をログに残す
デバイス障害が起きてもクラッシュを引き起こしたパラメーターが残るよう、カーネル実行前にAPI入力をログへ記録する。
無効時にはロギングのオーバーヘッドを発生させない。
呼び出し名、入力と結果、高コストな統計という段階的なレベルを提供する。
統計と無効値の走査は、明示的に指定した詳細診断に限定する。
グラフキャプチャ中は、互換性のない統計収集をスキップする。
診断ダンプをイベント数と合計サイズで制限する。
高コストなキャプチャの対象を関連APIだけに絞れるよう、包含フィルターと除外フィルターをサポートする。
ダンプを環境間で移動する必要がある場合は、移植可能なテンソル形式を選ぶ。
専用の書き込み可能なダンプディレクトリを使用する。
失敗の診断中に限り、詳細なコンパイル結果とデバッグシンボルを有効にする。
生成ソース、ビルドマニフェスト、コンパイル済みモジュール、キャッシュメタデータをまとめて調査する。
クラッシュを再現するときは、形状、データ型、アーキテクチャ、フラグ、選択したバックエンドを記録する。
プロファイラーまたはデバッガーでソースの対応付けが必要な場合は、行情報を使用する。
通常の最適化設定をデバッグビルドから分離する。
アルゴリズムまたはバックエンドの強制選択は、製品環境のデフォルトではなく診断用の制御として扱う。
結果の再現に使用したデフォルト以外の制御をすべて文書化する。
## ダウンロードした成果物を確かめ、決めたGPUの一覧でリリースを作る
オフライン環境またはロックダウン環境でローカル成果物が欠けている場合は、必ず失敗させる。
信頼できるミラーでデフォルトの成果物リポジトリを置き換えられるようにする。
ダウンロードした成果物のチェックサムをデフォルトで検証する。
一時的なデバッグ手段としてのみ、チェックサム検証を無効にする。
並列成果物ダウンロード数に上限を設ける。
ダウンロードを試す前に、設定済みのローカルソースを優先する。
コンパイルフラグとランチャーの上書きを明示的かつ観測可能に保つ。
成果物ローダーのロギング制御を、API呼び出しのロギング制御と区別する。
イベント計時が信頼できない場合にハードウェアのグローバルタイマーを使うなど、自動調整には安定した計時を使用する。
制御されたCI診断では、機密コンピューティングの検出を上書きできるようにする。
明示的なキャッシュ場所と互換性のある環境がある場合に限り、自動調整結果を永続化する。
現在のスタックでハングまたはクラッシュすると判明しているカーネルを避けるため、戦術ブロックリストをロードする。
実験的なルーティングとカーネル選択の上書きは、文書化されたデフォルトのままにする。
明示的なアーキテクチャ一覧に対して事前コンパイルパッケージをビルドする。
単一の正式なバージョン情報源からパッケージのバージョンメタデータを生成する。
カーネル、デバイス対応、バグ修正には後方互換性のあるバージョン増分を使用する。
互換性のないAPI変更は、アーキテクチャ上のバージョン境界に限定する。
## 公開APIとドキュメントを、カーネルのコードと合わせておく
同じカーネルを複数のホストフレームワークから利用できるよう、型付き言語間ABIを使用する。
フレームワーク固有のテンソル処理は、デバイスヘッダーではなくバインディングに置く。
コンパイルとグラフキャプチャで必要な場合に限り、ホストフレームワークへカスタム操作を登録する。
Python API、JITジェネレーター、バインディングのエクスポート、事前コンパイルレジストリ、パッケージのエクスポートを同期させる。
高度なワークスペース設計や計画・実行設計を採用する前に、最も単純で動作するカーネルパターンから始める。
パラメーターを変更するときは、関数シグネチャ、テンプレート、ランチャー、テストをまとめて更新する。
近くにある動作済みの例から、確立されたスタイル、複雑さ、防御性、効率性を学ぶ。
意図的に異なる設計と性能上重要なアルゴリズム選択について、検討した代替案とともに文書化する。
アーキテクチャ固有の動作については、正式な命令セットおよびツールチェーンの文書を参照する。
外部文書が古い場合は、同梱された依存関係のソースを優先する。
トレーステンプレートと生成済みベンチマーク定義を、外部向けAPIと同期させる。
ロギング、要件、FFI、コード生成のパターンを変更した場合は、インフラストラクチャの例とチュートリアルを更新する。
非推奨の手法を明確に示すか、現行ガイダンスから除外する。
コントリビューションポリシーに従い、意味のあるAI支援を開示する。
ソース、生成成果物、キャッシュ、テスト、ベンチマーク、エクスポート、ドキュメントが一致した場合にのみ承認する。
