GPU最適化の前に「このモデルは理論上どこまで速くなれるか」を知りたい。NVIDIAが公開したSOLARは、PyTorchやJAXのソースコードからその答えを自動で導き出すツールです。

この記事でわかること

  • SOLARが解く課題とSpeed-of-Light（SOL）分析の意味
  • ソースコードから理論下限を求める3段階パイプラインの仕組み
  • KernelBenchやロボティクスモデルでの評価結果
  • インストール方法と基本的な使い方

手作業の性能分析がボトルネックになる理由

深層学習のワークロードが複雑化するほど、「実測値」と「ハードウェアが許す理論上の最短実行時間」の差は大きくなります。後者をSpeed-of-Light（SOL）分析と呼び、カーネル開発者はボトルネックの特定に、研究者は精度と速度のトレードオフ判断に、ハードウェア設計者は必要な演算性能と帯域幅の見積もりに使います。

従来はSOL境界を手計算で導くのが一般的でした。FLOPカウンタ（fvcoreやptflops）は演算回数は数えられますが、メモリトラフィックを扱えないためSOLには使えません。プロファイラ（NVIDIA Nsight Computeなど）は「実装がどれだけハードウェアを使えたか」を測るもので、「アルゴリズムの理論下限」は別問題です。LLMに直接SOLを推定させる手法もありますが、NVIDIAの論文ではKernelBenchの複合ワークロード（L3）で正答率が38%に落ち込むと報告されています。

SOLARがソースコードからSOLを自動導出する

https://github.com/NVlabs/SOLAR

SOLAR（Speed-of-Light Analysis for Runtime）は、NVIDIAが論文「Solar: AI-Powered Speed-of-Light Performance Analysis」（arXiv:2606.26383）で発表し、GitHubでオープンソース公開したフレームワークです。PyTorchとJAXのソースコードを入力に、対象GPUアーキテクチャ上での理論最短実行時間を自動算出します。

論文で示された処理の流れは3段階です。

  1. 検証付きLLMフロントエンド — LLMがソースコードをAffine Loop IR（アフィンループ中間表現）に翻訳し、元プログラムとの数値出力比較で正しさを検証します
  2. 決定論的Einsum生成 — 検証済みIRをEinsumグラフ（テンソル縮約の有向非巡回グラフ）に変換します
  3. SOL分析 — ルーフラインモデルに基づき、演算性能とメモリ帯域幅の両面から理論下限を計算します

公開ツールでは、この分析を5段階のCLIパイプラインとして実装しています。PyTorchグラフ抽出 → Einsum変換 → ハードウェア非依存分析（MACs・FLOPs・バイト数） → アーキテクチャ別性能予測 → Timeloop形式エクスポート（任意）という流れです。

3段階の精度レベルで最適化のヒントを出す

SOLARの強みは、SOL境界を1種類だけ返すのではなく、精度の異なる3モードを提供する点です。

  • Unfused（非融合） — 各演算子を独立に分析し、中間テンソルのDRAM往復をすべてカウントします
  • Fused（融合） — 隣接する融合可能な演算子をまとめ、中間テンソルのメモリアクセスを除外します
  • Cache-aware fused（Orojenesis） — オンチップバッファ容量を考慮し、タイル化による再読み込みコストまで含めたより厳密な下限を算出します

KernelBench L3（モデル部分グラフ）では、演算子単位の分析と比べ融合グラフ分析で最大7.8倍の追加ヘッドルームが見えると論文に記載されています。キャッシュ考慮のOrojenesis分析は、単純なルーフライン比で最大2.25倍タイトな境界を出します。

既存ツールとの比較

NVIDIAの論文は、KernelBench 270問（L1〜L4）でのカバレッジを比較しています。

ツール カバレッジ SOL導出
fvcore 75% 不可
ptflops 84% 不可
SOLAR 100% 可

SOLARはKernelBench全問で検証済みSOL境界を導出し、SOL違反（実測が理論下限を下回るケース）は観測されなかったと報告されています。JAX/Flaxの8プログラムでも動作し、ヘッドルームはBatchNormの1.1倍からFlaxMNISTCNNの85.9倍まで幅があります。

実用例：どこに使えるか

最適化余地の定量化 — KernelBench L3ではPyTorch eager実装のジオメトリック平均SOLスピードアップが54.6倍、torch.compileでも47.7倍と、グラフレベルの融合が不可欠な規模の余地が残ると示されています。

クロスプラットフォーム比較 — Qwen3-4Bブロックを4種のGPU（B200、H100、A6000、Jetson Thor）に投影すると、融合SOLは0.61ms（B200）から3.56ms（A6000）まで5.8倍の差が出ます。ハードウェアを手元に持たなくても設計判断が可能です。

ハードウェア要件の逆算 — ロボティクス向け500Hz制御を目標にJetson Thorで分析すると、DreamZero WAM（14B）は現行帯域幅の19.7倍、演算性能の8.3倍が必要と算出されます。帯域幅か演算性能のどちらか一方を上げるだけでは足りないケースを事前に把握できます。

SOLARはGPUカーネルベンチマーク「SOL-ExecBench」の分析バックエンドとしても使われ、3,957ワークロードのSOLスコア算出に利用されています。

使い方の概要

リポジトリをクローンし、開発モードでインストールします。

cd solar
pip install -e .

Attentionモデルの例では、ディレクトリ内のrun_solar.shで全5段階を一括実行できます。個別に実行する場合は以下のCLIを使います。

# Stage 1: PyTorchグラフ抽出
solar-process-model --model-file model.py --output-dir output/graph

# Stage 2: Einsum変換
solar-toeinsum-model --graph-path output/graph/pytorch_graph.yaml \
                     --output-dir output/einsum --no-copy-graph --save-graph

# Stage 3: ハードウェア非依存分析
solar-analyze-model --einsum-graph-path output/einsum/einsum_graph_renamed.yaml \
                    --output-dir output/analysis

# Stage 4: 性能予測（H100 PCIe向け）
solar-predict-perf-model --analysis-path output/analysis/analysis.yaml \
                         --output-dir output/perf --arch-config H100_PCIe

対応アーキテクチャ設定にはH100_PCIe、A6000、B200などがあり、KernelBenchモデルはsolar-toeinsum --level level1 --kernel-ids 1 2 3で一括処理できます。出力はすべて人間が読みやすいYAML形式です。

注意点

SOLARの分析はテンソル形状に基づくもので、値依存の最適化（定数畳み込みや圧縮など）は捉えられません。SOL境界は理論下限であり、電力制限やサーマルスロットリングなど実ハードウェアの変動要因は含みません。未知の演算子にはLLMエージェントによるフォールバック処理がありますが、翻訳の正しさは数値検証に依存するため、入力サンプルで検出できない誤りが残る可能性があります。

導入を検討するなら

SOLARはMITライセンスで公開されており、論文とリポジトリの両方が揃っています。まずはexamples/Attentionのrun_solar.shを動かし、自分のモデルに対するSOLヘッドルームを確認するのが手早い入り口です。カスタムカーネルの最適化前に理論下限を押さえておくと、改善の優先順位づけがはるかに楽になります。