🤖 machine learning

SOLAR: AI-Powered Speed-of-Light Performance Analysis

SOLARは、生成的な手法と決定論的な手法を組み合わせたハイブリッド・パイプラインを用いて、PyTorchおよびJAXのソースコードを検証済みの理論上の最大性能（Speed-of-Light）へと変換し、開発者が多様なディープラーニングのワークロードにおいて理論的な実行限界を定量化し、最適化の機会を特定し、ハードウェアのプロビジョニングを導くことを可能にする自動化フレームワークである。

原著者： Qijing Huang, Sana Damani, Zhifan Ye, Athinagoras Skiadopoulos, Siva Kumar Sastry Hari, Jason Clemons, Sahil Modi, Jingquan Wang, Aditya Kane, Edward C Lin, Humphrey Shi, Christos Kozyrakis

公開日 2026-06-26

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

CC BY 4.0

原著者： Qijing Huang, Sana Damani, Zhifan Ye, Athinagoras Skiadopoulos, Siva Kumar Sastry Hari, Jason Clemons, Sahil Modi, Jingquan Wang, Aditya Kane, Edward C Lin, Humphrey Shi, Christos Kozyrakis

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

あなたはレーシングドライバーだと想像してください。あなたには、新品の高性能な車（あなたのAIモデル）と、特定のレースコース（あなたのコンピュータチップ）があります。あなたが知りたいのは、**「この車がこのコースを周回できる、理論上の絶対最速タイムはどれくらいか？」**ということです。

現在、ほとんどのツールは、テスト走行で実際にどれくらいの速さで走ったか、あるいはエンジンの馬力（どれだけの数学的問題を解いたか）を数えることしかできません。しかし、それらのツールは、その特定の車とコースにおける理論的な速度限界を教えてはくれません。あなたの車は潜在能力の50%で走っていますか？90%ですか？それとも、道路設計の悪さによる渋滞に巻き込まれていますか？

この論文は、その理論的な「光速（Speed of Light: SOL）」の限界を自動的に算出する新しいツール、SOLARを紹介します。

SOLARの仕組みを、簡単な比喩を用いて解説します：

1. 問題点：推測か、把握か

複雑なAIモデルの速度制限を知りたい場合、現在は手作業で行う必要があります。それは、定規を使ってすべてのカーブや直線距離を一つずつ手動で計測し、最速のラップタイムを計算しようとするようなものです。これは時間がかかり、間違いやすく、しばしば不正確です。

従来のツールは、単に計算量を数えるだけ（渋滞を無視している）か、あるいは現在のドライバーがどれくらいの速さで走っているかを測定するだけ（車の潜在能力を無視している）です。
純粋なAIによる推測は、実行時間を予測しようとしますが、複雑なルートに対しては数学的な計算を間違えることがよくあります。

2. 解決策：「翻訳者」と「エンジニア」

SOLARは、**「翻訳者（Translator）」と「エンジニア（Engineer）」**という、巧妙な2人組のチームによってこの問題を解決します。

ステップ1：翻訳者（AIエージェント）
手書きの乱雑なレシピ（PyTorchやJAXで書かれたあなたのAIコード）があると想像してください。人間のシェフ（AI大規模言語モデル）がその乱雑なレシピを読み、Affine Loop IRと呼ばれる厳格で標準化された設計図へと書き換えます。
- 安全性チェック： 設計図が受理される前に、SOLARは元の乱雑なレシピと新しい設計図の両方を実行し、両者が全く同じ料理（結果）を作ることを確認します。もし料理の味が異なれば、AIはやり直しを行います。これにより、翻訳が100%正確であることを保証します。
ステップ2：エンジニア（決定論的計算機）
設計図が検証されると、厳格なルールに従うエンジニアが引き継ぎます。このエンジニアは設計図を見て、「もしこれを図面通りに構築したら、絶対的な最小時間はどれくらいになるか？」と問いかけます。
- 彼らは推測しません。設計図の構造に基づいて数学を計算します。
- 彼らは、データが次のステップへとどのように流れるかを示す依存関係のマップ（「Einsumグラフ」）を作成します。

3. 「光速」の計算

エンジニアがマップを手に入れたら、以下の2つの主要な要因を用いて速度制限を計算します。

演算（Compute）： エンジンがどれだけ速く数学的処理を行えるか。
メモリ（トラフィック）： データがどれだけ速くエンジンに出入りできるか。

SOLARはマップを見て次のように判断します：

「ナイーブな速度（Naïve Speed）」： もし食料品（データ）を積み込むために、あらゆる交差点で立ち止まるとしたら、どれくらいの時間がかかるか？
「融合された速度（Fused Speed）」： もし2つの停車を1つにまとめれば（演算の融合）、時間を節約できるか？
「現実的な速度（Realistic Speed）」： トランク（キャッシュ）が小さく、一度にすべてを運べないことを考慮した場合、どれくらいの時間がかかるか？

4. SOLARが教えてくれること（「ヘッドルーム」）

最もエキサイティングな部分は、SOLARが明らかにする**「ギャップ」**です。

もし現在のAIモデルの実行に10秒かかり、SOLARが理論的限界を1秒だとしたら、あなたには**10倍の「ヘッドルーム（余白）」**があります。

「ヘッドルーム」の比喩： 時速100km制限の道路を時速60kmで走っていると想像してください。SOLARはこう教えてくれます。「あなたは60kmで走っていますが、車と道路は100kmまで対応可能です。ここで減速している原因はどこにありますか？立ち止まりすぎですか？トランクが小さすぎるからですか？それともルート選びが悪いからですか？」

5. 論文による実世界の例

著者らは、SOLARを3つのシナリオでテストしました：

標準的なベンチマーク： 複雑なタスクにおいて、現在のソフトウェアは理論的限界よりも50倍遅いことが分かりました。これは、コードの実行方法を並べ替えるだけで、大幅な改善の余地があることを意味します。
ロボティクス： 即座に反応する必要があるロボット（1秒間に500回動作）を調査しました。SOLARはこう告げました。「現在のコンピュータチップは、データの移動速度が足りないため遅すぎます。このロボットをリアルタイムで動作させるには、20倍の帯域幅を持つチップが必要です。」
異なるハードウェア： 未発表の新しいチップを購入することなく、数学的な計算を行うだけで、そのモデルが新しいチップ上でどのように動作するかを予測できることを示しました。

まとめ

SOLARは、AIパフォーマンスのための**「GPS」**のようなものです。単に旅行にどれくらいの時間がかかったかを教えるのではなく、あなたの特定の車と道路における、絶対的に最速の旅行時間を計算します。そして、ルート計画のミス（アルゴリズム）、立ち寄りの多さ（メモリトラフィック）、あるいはトランクの小ささ（キャッシュ）など、どこで時間を無駄にしているのかを正確に指摘し、「光速」に到達するためにどのように修正すべきかを教えてくれるのです。

技術要約: SOLAR – AI駆動型「光速（Speed-of-Light）」性能解析

1. 問題提起

現代のディープラーニング・アクセラレータはペタFLOPS級のピークスループットを実現しているが、実際のワークロードがこれらの理論的限界に達することは稀である。モデルがターゲットハードウェア上で「どれだけ速く動作し得るか」と「実際にどれだけ速く動作しているか」の間に存在する決定的なギャップを理解するためのツールが不足している。既存のツールには以下の課題がある：

FLOPカウンタ（例：fvcore, ptflops）は、演算子のカバレッジが狭く（KernelBenchにおいて75–84%）、I/Oトラフィックを無視しており、理論上の最小実行時間（Speed-of-Light、以下SOL）を導出できない。
ハードウェアプロファイラ（例：NCU, NSys）は、特定のインプリメンテーションの達成性能を測定するものであり、アルゴリズム的な制約によって物理的に到達不可能な「ヘッドルーム（余剰性能）」を報告してしまう可能性がある。
純粋なLLMによる推定は、複合的なワークロードに対してエラーが発生しやすく、キャッシュを考慮した解析に必要な系統的な探索能力を欠いている。
既存の性能モデリングフレームワーク（例：Timeloop, AccelForge）は、手動でのワークロード指定を必要とし、それがエラーの原因となりやすく、迅速なモデル開発から乖離している。

高レベルのソースコード（PyTorch/JAX）から、広範な演算子カバレッジを持つ「検証済み」のSOL境界を自動的に導出できる既存のツールは存在しない。

2. 手法

SOLAR（Speed-of-Light Analysis for Runtime）は、生成的な翻訳と決定論的な解析を分離する3段階のパイプラインを通じてこのギャップを埋める、ソース・トゥ・SOLフレームワークである。

ステージ1: 検証済みエージェント・フロントエンド

第1段階では、任意のソースプログラムを、実行可能な**アフィンループIR（Affine Loop IR）**へと翻訳する。

パーサーとしてのLLM: LLMエージェントがソースコードを、言語に依存しない中間表現であるアフィンループIRへと翻訳する。
IRの構造: IRはプログラムを以下のように分割する：
- 制限付きアフィンループカーネル: 名前付き次元テンソル上の、静的な境界とアフィンインデックス式を持つ、完全にネストされたループ。これらはeinsumへの機械的なリフティング（lifting）のために設計されている。
- 無制限の構成レイヤー: 制御フロー、データ移動（reshape, slice）、およびスパース演算を処理する。
検証ループ: 正当性を確保するため、システムは元のプログラムを実行して「ゴールデン（正解）」の出力を取得し、LLMを介してIRを生成し、そのIR（Numbaを使用）を実行して出力を比較する。不一致が発生した場合、診断フィードバックがLLMを誘導して翻訳を修正させる。この「生成・検証」ループにより、ダウンストリームのパイプラインには数値的に検証された翻訳のみが渡されることが保証される。

ステージ2: 決定論的なEinsum生成

検証されたIRに対し、決定論的なコンパイラがそれをEinsumグラフへとリフトする。

グラフ構築: バックエンドはIRをトレースして、拡張されたeinsum（集約操作としてのmaxをサポート）をノードとし、テンソルデータの依存関係をエッジとする有向非巡回グラフ（DAG）を構築する。
機械的導出: Einsumの添字構造から、システムは正確なMACカウントとメモリトラフィックの数式を機械的に導出する。
融合性（Fusibility）解析: グラフ構造により、オンチップバッファを共有できる隣接する演算子を特定し、融合された操作と独立した実行のコストを計算できる。

ステージ3: SOL解析

解析バックエンドは、ターゲットハードウェアの仕様（ピークスループット $\Pi$ およびDRAM帯域幅 $\beta$ ）に対して、理論的な最小実行時間（ $T_{SOL}$ ）を算出する。

ルーフラインモデル: $T_{SOL} = \max(\frac{\text{FLOPs}}{\Pi}, \frac{\text{Traffic}}{\beta})$ 。
マルチフィデリティ・モード:
1. 非融合（Unfused）: 中間データのDRAMへのフルラウンドトリップを想定した、独立した実行。
2. 融合（Fused）: 融合された演算子がオンチップバッファを無限に持つと仮定することで、中間データのDRAMトラフィックを排除する。
3. キャッシュ認識型融合（OROJENESIS）: 有限のオンチップバッファ容量をモデル化する。整数線形計画法を用いてタイリング戦略を最適化し、ワーキングセットがキャッシュ制限を超える際のDRAMからの再読み込みを考慮する。
逆ルーフライン（Inverse Roofline）: 目標レイテンシが与えられたとき、システムは最小限必要なハードウェア仕様（ $\Pi_{min}$ および $\beta_{min}$ ）を導出する。

3. 主な貢献

初のソース・トゥ・SOLフレームワーク: SOLARは、PyTorchおよびJAXのソースコードから直接、検証済みのSOL境界を導出する初のツールであり、KernelBenchにおいて100%の解析カバレッジを達成した。
ハイブリッド生成・決定論的パイプライン: 言語に依存しない翻訳のためのLLM（数値検証付き）と、再現可能な性能解析のための決定論的コンパイラを独自に組み合わせている。これにより、純粋なLLMによる推定の誤りを回避しつつ、従来のモデリングに伴う手動作業をバイパスする。
包括的な評価: カーネル、アルゴリズム、およびアーキテクチャの各ユースケースにおいてエビデンスを提供し、ヘッドルーム解析、最適化の特定、クロスプラットフォーム探索、およびハードウェア・プロビジョニングにおける能力を実証している。

4. 結果

評価は、KernelBench（270問）、JAX/Flaxモデル、およびJetson Thor上のロボティクス・ワークロードに対して行われた。

ヘッドルーム解析: SOLARは顕著な最適化のギャップを明らかにする。KernelBenchにおいて、実測ランタイムと融合後のSOLとの差は、PyTorch Eager実行においてL1で4.3倍からL3で54.6倍に及ぶ。torch.compileを使用した場合でも、依然として大きなヘッドルーム（例：L3で47.7倍）が残っており、複合的なワークロードにおいてはグラフレベルの融合が極めて重要であることを示している。
マルチフィデリティによる洞察:
- 融合: 融合解析は、KernelBenchにおける演算子ごとの解析と比較して、最大7.8倍の追加のヘッドルームを明らかにしている。
  এটিは、融合が性能向上に寄与することを示す。
- キャッシング: キャッシュ認識型境界は、ナイーブな融合境界よりもSOLを最大2.25倍タイトにし、特定のシナリオにおいてタイリングがボトルネックであることを特定した。
- アルゴリズム最適化: Einsumチェーンの順序変更（例：DeepSeek MLA）により、ナイーブな順序と比較して2.04倍のFLOP削減を達成した。
クロスプラットフォーム投影: SOLARは、物理的なアクセスなしに4つのハードウェアターゲット（B200, H100, A6000, Jetson Thor）への性能を投影する。融合による恩恵はプラットフォームによって大きく異なり（B200では1.8倍に対し、Jetson Thorでは14.5倍）、帯域幅と融合の相互作用を浮き彫りにしている。
ハードウェア・プロビジョニング（逆ルーフライン）: 500 Hzの制御ループをターゲットとするロボティクスモデルにおいて、SOLARは帯域幅が主要な制約であることを特定した。例えば、DreamZero WAMモデルは、レイテンシ目標を達成するために現在の帯域幅を19.7倍改善する必要があり、これはシリコンのアップグレードだけでは不十分で、モデル圧縮やアルゴリズムの変更が必要であることを示唆している。

5. 意義と主張

本論文は、SOLARが性能最適化へのアプローチを根本的に変え、理論的限界を容易かつ実行可能なものにすると主張している。

ギャップの解消: 高速なモデル開発とハードウェア性能解析の間の断絶を解消し、「検証済み」の天井を提供する。
実行可能な洞察: マルチフィデリティ解析を提供することで、エンジニアがボトルネックの原因が「融合の欠如」なのか、「不適切なタイリング」なのか、あるいは「根本的なアルゴリズムの非効率性」なのかを区別できるようにする。
ハードウェア非依存のデザイン: アーキテクトやアルゴリズム設計者が、シリコンが存在する前から設計空間を探索し、ハードウェア要件をプロビジョニングすることを可能にし、残りのヘッドルームが少ない作業に対して計算リソースやトークンを浪費することを防ぐ。

著者らは、本解析がテンソル形状に基づいていること（値は考慮しない）、および理想的なハードウェア挙動を想定していること（熱スロットリングは無視する）を前提としつつも、ディープラーニングのワークロードに対する、自動化され検証された包括的な「光速（SOL）」の視点を提供するものであると強調している。