# ApproxMLIR: Accuracy-Aware Compiler for Compound ML System > [!info] Talk metadata > - **会議:** [[MLSys2026]] Day 4 (May 21 / Thu)、Grand Ballroom 2、17:30 - 17:45 PDT > - **登壇者:** Hao Ren ほか（University of Illinois Urbana-Champaign） > - **URL:** https://mlsys.org/virtual/2026/oral/3757 > - **OpenReview:** https://openreview.net/forum?id=nKm25GWbuB > - **Code:** https://github.com/uiuc-arc/approxMLIR > [!abstract] 概要 > 複合 AI システム（LLM と RAG・ツール呼び出しなどの非 ML コンポーネントを組み合わせたシステム）は本質的に近似的である。ML 部分は確率モデルであり、非 ML 部分はヒューリスティクスだからである。こうしたシステムでは結果品質と性能のトレードオフが有効だが、ML と非 ML のコンポーネントはコンパイラスタック・実行環境・ハードウェアが異なるため、エンドツーエンドの精度認識コンパイルは困難であった。ApproxMLIR は MLIR 上に `approx` ダイアレクトを導入し、近似変換の定義・管理・適用を統一的に扱う再利用可能なコンパイルツールチェーンである。3 種の複合 AI システム（LLM + 情報検索、LLM + ツール呼び出し）で評価し、静的近似戦略と比較して一貫した高速化とより優れたパレートフロンティアを達成した。 ## テーゼ・背景 複合 AI システムの台頭により、ML カーネルと非 ML カーネルの双方を横断的に最適化する必要性が増大している。エージェント型 AI ではエンドツーエンドレイテンシに占める CPU 処理（ツール・検索・オーケストレーション）の割合がツール多用型で 88% にも達し、GPU 演算だけでなく非 ML 側の最適化も重要である。 しかし既存のコンパイラエコシステムには 4 つの課題がある。 1. **ツールチェーンの断片化**: 非 ML コード（C/C++）は Polygeist 経由で `scf`/`arith` ダイアレクトへ、ML コード（JAX）は IREE/XLA 経由で `stablehlo` へコンパイルされ、別々のスタックで最適化・実行される。近似を横断的に調整する場所が存在しない。 2. **従来の統一は低レベルすぎた**: ApproxHPVM や ApproxTuner は LLVM IR レベルで近似を統一するが、ローレベルに下がった時点で形状・型・構造的制御フローなどの高レベル意味論が失われ、高度な最適化が困難になる。 3. **静的近似は柔軟性に欠ける**: 実行時の入力特性やシステム状態に応じて近似を動的に切り替えることで、より良い精度・性能トレードオフが得られるが、MLIR ツールチェーンはこれをネイティブに支援しない。 4. **MLIR には近似の置き場がない**: 近似情報を既存オペレーションのアトリビュートとして付与するナイーブなアプローチでは、タイリングなど標準パスによる書き換え時にアトリビュートが暗黙に破棄され、近似メタデータが消失する。 ## 提案手法: ApproxMLIR ApproxMLIR は「近似にコンパイラ上の正式な抽象化を与える」ことを主眼とするツールチェーンであり、3 つの主要コンポーネントからなる。 ### approx ダイアレクト MLIR 上の独立ダイアレクトとして設計され、近似のスコープ・ポリシー・実装を第一級オペレーションとして定義する。標準 MLIR パスによる変換を経ても消失しない。主要オペレーションは以下の 3 つである。 - **`approx.knob`**: 近似対象のコード領域をラップし、オートチューナとのインタフェースを提供する。`id`（ノブ識別子）、`params`（チューナが操作するパラメータの符号化）、`transform_types`（許容する変換種別）を属性にもつ。すべての近似箇所はここから始まる。 - **`approx.decision_tree`** (管理オペレーション): ランタイム関数の返値と閾値に基づいて分岐を制御し、「いつ・どこで」近似を適用するかを決定する。アプリケーション状態に応じた動的近似の切り替えを可能にする。 - **`approx.transform`**: 「どのように」近似するかの具体的な書き換え規則を定義する。`transform_type` 属性でループパーフォレーション、関数代替、タスクスキッピングなどを指定し、`transform_value` で近似強度を整数で制御する（0 = 厳密、1 = 緩やか、2 = 積極的）。 さらに以下の補助オペレーションが定義される。 - **`approx.try`**: try-check-recover パターンを実装する安全契約オペレーション（De Kruijf et al., 2010; Achour & Rinard, 2015; Joshi et al., 2020 に由来）。ユーザ定義のチェック領域が近似結果を検証し `i1` を返す。検証に失敗した場合は `recover` 属性で指定されたフォールバック関数（コードの再実行や補正処理など）が呼ばれる。`approx.decision_tree` と同様に管理オペレーションであり、具体的な近似戦略と直交し、`approx.transform` の適用前に独立してローワリングされる。 - **`approx.yield`**: `approx.knob` オペレーション内のターミネータとして機能し、近似対象領域の計算結果を外部に返す。 #### approx ダイアレクトの形式構文（Table 1 準拠） 論文 Table 1 および Appendix A に定義される各オペレーションの MLIR 構文を以下に示す。 ```mlir // knob: スコープ定義 + オートチューナインタフェース %r = approx.knob <{ id = ... , params = "...", transform_types = "..." }> (%arg0, ...) -> (type, ...) (...region...) // decision_tree: 動的近似の分岐制御 approx.decision_tree (%runtime_input) <{ runtime = "...", thresholds = [...], decisions = [...], transform_type = "..." }> { ... } // try: 安全契約（チェック + リカバリ） approx.try (%recovery_args) <{ recover = "@..." }> { // check region -> i1 } // yield: knob 領域のターミネータ approx.yield // transform: 具体的な近似書き換え指定 approx.transform <{ transform_type = "...", transform_value = ... }> ``` #### 設計原則: 管理と実装の分離 `approx` ダイアレクトの核心的な設計原則は、近似の**管理**（いつ・どこで近似するか）と**実装**（どのように近似するか）の明確な分離である。`approx.knob` と `approx.decision_tree` は管理オペレーションであり、`approx.transform` は実装オペレーションである。この分離により、`decision_tree` のローワリングパスは一度だけ実装すれば全ての具体的な変換型（`loop_perforate`、`func_substitute`、`task_skipping` など）に適用でき、新しい近似戦略の追加は対応する `RewritePattern` を追加するだけで済む。 #### 独立ダイアレクトとする理由 既存オペレーションへのアトリビュート付与ではなく独立ダイアレクトとする理由は 3 つある。(1) アトリビュート方式は**侵襲的**であり、囲まれた全オペレーションの変更を要する。(2) **表現力が不足**しており、アトリビュートでは任意のコード領域にスコープを定義できない。(3) 標準パス（タイリング、バッファリゼーションなど）がアトリビュートを**暗黙に破棄**するため脆弱である。独立ダイアレクトであれば `approx-opt` が明示的にローワリングするまでオペレーションは保全される。 ### approx-opt（コンパイラパス群） `approx` ダイアレクトを標準 MLIR コードへ段階的にローワリングするパス群であり、6 段階で処理される。 - **Step 0**: ソースコード注釈（C/C++ の構造化コメントまたは `#pragma`、Python API）を `approx.knob` オペレーションへ変換。 - **Step 1**: `approx.knob` がループなどの対象コード領域をラップし、チューナインタフェースを生成。ノブは下流パスに対して不透明であり、標準パスに破壊されない。 - **Step 2**: `approx.decision_tree` オペレーションを生成し、ランタイム分岐ロジックを捕捉。この段階では実際の書き換えは遅延される。 - **Step 3**: `decision_tree` を標準 MLIR 制御フロー（`scf.index_switch` など）にローワリング。各分岐が `approx.transform` を保持する。 - **Step 4**: ユーザ定義のランタイム関数（状態取得関数など）をバインド。 - **Step 5**: `approx.transform` を適用し、具体的な近似変換（ループパーフォレーション = ストライド変更、関数代替、タスクスキッピング）を MLIR 書き換え規則として実行。この時点で `approx` オペレーションはすべて消滅する。 新しい近似戦略の追加は、対応する書き換え規則を追加するだけでよい。 #### 近似変換の具体的実装 `approx.transform` のローワリングは MLIR の `RewritePattern` API を用いた書き換え規則として実装される。ドライバ API が適用可能な規則を貪欲（グリーディ）に適用する。たとえばループパーフォレーションの書き換え規則は、`transform_type` が `"loop_perforate"` に一致する `approx.transform` オペレーションを検出すると、その親リージョン内の最初のループのストライドを `transform_value` に応じて変更する。任意個数の `transform` オペレーションをリージョン内に合成（スーパーポジション）できるため、近似戦略の重ね合わせが容易である。 現在の実装が提供する 3 種の古典的近似変換は以下の通りである。 1. **ループパーフォレーション**: ループのストライドを変更してイテレーションをスキップする 2. **関数代替**: 精密な関数呼び出しをユーザ提供の近似版に置換する 3. **タスクスキッピング**: 制御フローを書き換えて関数呼び出しや分岐全体をバイパスする ### approx-runtime（ランタイムシステム） 実行時の動的近似選択とオートチューニングを担う。 - **動的近似**: ユーザ定義のランタイム関数をバインドし、アプリケーション状態に基づいて近似の強度を実行時に切り替える。たとえば検索類似度が高い場合は積極的近似、低い場合は厳密実行といった制御が可能になる。バインドプロセスはユーザ提供のランタイムライブラリを検索し、`decision_tree` の `runtime` 属性で指定された関数名に一致する関数を、先に生成された呼び出し命令にリンクする。ユーザはランタイムディレクトリに関数を配置し、注釈で関数名を指定するだけでよい。 - **カーネル間協調**: 重み量子化のように単一カーネル内の近似では対処できない場合、`approx-runtime` が複数ノブ（pack 関数と dot 関数のビット幅・グループサイズなど）を一つの統合構成として OpenTuner に公開し、相関するノブ間の整合性を保証する。たとえば LLM の重み量子化では `approx.knob id=7`（pack）と `approx.knob id=8`（dot）がペアになり、`pack_w_int8_g128` と `dot_i8_g128` のようにスケールテンソルの形状が一致する組み合わせのみが許容される。チューナは 1 ステップで両カラムから 1 行ずつ選択し、整合性を自動保証する。 - **オートチューニング**: OpenTuner と統合し、大規模な構成空間をプロファイリングベースで探索する。QoS 評価関数と QoS ターゲットをユーザが指定すると、パレートフロンティア上の最適構成を自動発見する。 #### オートチューニングパイプラインの詳細 オートチューニングは以下の手順で動作する。 1. **構成空間の抽出**: MLIR コード内の全 `approx.knob` オペレーションをパースし、`params` フィールドからチューナブルパラメータの範囲を抽出して構成配列を構築する 2. **構成の選択**: OpenTuner の組み込み探索アルゴリズムが新しい構成を選択する 3. **MLIR コードへの書き戻し**: 選択された構成を対応する `approx.knob` の `params` 属性に符号化して書き戻す。`params` にはデシジョン閾値、選択された変換型、決定値など囲まれたオペレーションの全情報が符号化される 4. **プロファイリング**: ユーザが定義する `run_application` 関数がワークロードを実行し、精度とパフォーマンスを返す 5. **終了条件の確認**: 時間予算（複合 AI システムで 12 時間、カーネルベンチマークで 2 時間）に達するまで 2--4 を反復する ユーザはデフォルトのドライバクラスを継承し、`run_application` 関数を定義するだけでよい。MLIR ファイルの内部パースと `approx` オペレーションの操作はデフォルトドライバが処理するため、ユーザは個別の `approx` オペレーションを理解する必要がない。 #### ML カーネルのバックエンドフロー ML カーネル（JAX 経由）は非 ML カーネルとは異なるバックエンドフローを辿る。動的選択ロジック（`decision_tree` から生成された `scf.index_switch` など）は CPU ターゲットの実行可能ファイルにコンパイルされる。一方、ML カーネル本体は IREE コンパイラバックエンドによって複数の近似バリアント（例: LLM-pro、LLM-fast）として個別にコンパイルされ、GPU にオフロードされる。`approx-runtime` が実行時にアプリケーション状態に応じて適切なバリアントを選択する。 ### ML カーネルへの適用例: LLM デコード活性量子化 スライドでは ML カーネルにおける `approx` ダイアレクトの適用例として、LLM のデコード活性量子化が示されている。カーネル内部では `approx.knob` が行列積演算をラップし、`approx.transform` に `transform_type = "decode_quantize"` を指定する。ローワリング後は活性の量子化関数 `quantize_activation` が挿入され、`tt.dot` 演算が `tensor<1xKxi8> * tensor<KxNxi8> -> tensor<1xNxi32>` 型の INT8 行列積に置換される。逆量子化関数 `dequant` が出力をもとの精度に復元する。 この例は、単一カーネル内で完結する近似（カーネル内近似）であり、`approx.knob` + `approx.transform` の 2 オペレーションで表現できる。一方、重み量子化は pack 関数と dot 関数にまたがるカーネル間近似であり、`approx-runtime` によるカーネル間協調が必要になる。 ### ソースコード注釈 C/C++ カーネルには構造化コメント形式と `#pragma` 形式の 2 種が利用可能であり、ML カーネル（JAX/Python）にも同様の Python API を提供する。注釈は `runtime`（動的近似用の状態取得関数名）、`thresholds_range`（閾値範囲）、`decision_values`（分岐の決定値）、`transform_type`（近似戦略）を共通に指定する。 ## 近似変換の分類（論文 Section 3） 論文では近似変換を以下のように分類している。 - **細粒度**: ループパーフォレーション（ループストライドの変更によるイテレーションスキップ; Misailovic et al., 2010; Sidiroglou-Douskos et al., 2011）、メモイゼーション（過去の計算結果の再利用; Chaudhuri et al., 2011; Samadi et al., 2014） - **粗粒度**: タスクスキッピング（関数呼び出しやコード領域全体のバイパス; Rinard, 2006; Meng et al., 2009） - **関数代替**: 精密関数を高速な近似版に置換（Zhu et al., 2012; Ansel et al., 2011） - **データフォーマット**: FP16 半精度化、INT8/INT4 量子化（Frantar et al., 2023; Lin et al., 2024; Cheng et al., 2025; Yang et al., 2025） - **モデル圧縮**: プルーニング（Ma et al., 2023; Sun et al., 2024; Wei et al., 2025; Liu et al., 2025） ApproxMLIR は上記の個別手法に依存せず、近似の**管理インフラストラクチャ**を提供する。新しい変換を追加する場合は `approx.transform` の書き換え規則を追加するだけでよい。 ## BM25 RAG における近似機会の具体例 論文 Section 2 では BM25 ベースの RAG パイプラインを走行例として、非 ML・ML の双方にまたがる 4 種の近似ノブを具体的に示している。 1. **コーパスサブセッティングノブ**（非 ML）: 前処理段階で関数代替を用い、文書を確率的にスキップして検索対象数を削減する 2. **ターム（項目）スコアリングノブ**（非 ML）: メインスコアリングループ内でクエリの各固有トークンに対して実行される。ランタイム状態に基づき、文書のスコア計算を 10% または 20% の確率でスキップする関数代替を適用する 3. **コンテキスト選択ノブ**（非 ML）: プロンプト組立て段階で、検索結果の類似度などのランタイム状態に応じてプロンプトを切り詰める 4. **LLM 近似ノブ**（ML）: 生成段階で、ML カーネルを近似バリアント（より小さいモデルや量子化モデル）に置換する これら 4 ノブはそれぞれ独立したツールチェーン（C++ は Polygeist 経由、JAX は IREE/XLA 経由）でコンパイルされるが、ApproxMLIR の `approx` ダイアレクトが統一的なインタフェースを提供する。 ## 評価用ワークロード ### カーネルベンチマーク（5 種） | カーネル | 内容 | ノブ数 | 構成数 | |---|---|---|---| | lavaMD | 粒子シミュレーション | 2 | 1,600 | | knowledge base (kb) | ベクトル類似度ランキング | 2 | 450 | | bm25 | キーワード検索 | 3 | 4.8 x 10^6 | | pagerank | グラフランキング | 3 | 2,250 | | kmeans | クラスタリング | 3 | 5 x 10^10 | ### 複合 AI システムベンチマーク（3 種） | システム | 構成 | ノブ数 | 構成数 | |---|---|---|---| | LLM + RAG (bm25) | BM25 検索 + LLM 生成 | 4 | 約 1.8 x 10^7 | | LLM + RAG (kb) | ベクトル検索 + LLM 生成 | 4 | 約 9.6 x 10^8 | | LLM + tools | トリアージ LLM + ツール呼び出し | 12 | 約 1.7 x 10^25 | LLM には Gemma 3（1B および 4B）を使用（オープンソース、JAX 対応、IREE 互換のため選定）。データセットは NQ（Natural Questions、90,011 文書）。LLM + tools では拡張版 NQ データセット（augmented-NQ）を使用し、クラスタリング関連の質問など各ツールを呼び出す質問が追加されている。ツールとして bm25・lavaMD・pagerank・kb・kmeans を含む。 データセットはチューニングデータと評価データにランダム分割される。重複はなく、**評価データのサイズはチューニングデータの 5 倍**である。 ### QoS 指標の定義 **複合 AI システム**（LLM + ツール）の QoS は正答率で定義される。NQ データセットは短答形式であり、モデルの生成文に短答が含まれていればスコア 1、含まれなければスコア 0 とする。 $\text{accuracy} = \frac{\sum_{\text{question}} \text{score}}{\text{総質問数}}$ **非 ML カーネル**の QoS は以下のカーネル種別に応じて異なる指標を用いる。 - **kmeans・lavaMD**: L2 ノルム誤差を使用。$\text{Accuracy}_{L2} = 1 - \frac{\|y_{\text{exact}} - y_{\text{approx}}\|_2}{\|y_{\text{exact}}\|_2}$ - **pagerank・bm25・kb（エンベディング）**: RBO（Rank-Biased Overlap）類似度を使用。持続パラメータ $p = 0.95$ とし、比較深度 $D = \min(1000, \max(|S|, |T|))$ で算出する。RBO は順位ベースのシステム中心指標であり、上位ランクの一致をより重視する ## 実験結果 ### 動的近似 vs 静的近似（固定 QoS バジェット下） スライド準拠の主要数値を以下に示す。 **LLM + RAG (kb)**: - QoS 損失 3% 以下: 動的 2.64 倍 vs 静的 1.69 倍 - QoS 損失 6% 以下: 動的 2.64 倍 vs 静的 1.93 倍 - QoS 損失 9% 以下: 動的 3.04 倍 vs 静的 2.27 倍 **LLM + RAG (bm25)**: - 静的近似は改善なし（1.00 倍）。動的近似は QoS 損失 9% 以下で最大 1.57 倍を達成。 **LLM + tools**: - QoS 損失 3% 以下: 動的・静的ともに 1.09 倍 - QoS 損失 6% 以下: 動的・静的ともに 1.20 倍 - QoS 損失 9% 以下: 動的・静的ともに 1.20 倍 動的近似が静的近似を上回る理由は、ランタイム関数を通じてアプリケーション状態と入力特性を観測し、近似強度を適応的に調整できるためである。静的近似はアプリケーションの状態も入力特性も利用できないため、一部のベンチマーク（LLM + RAG (bm25)）では QoS 制約内での改善が全く得られない。これは動的近似の構成空間が静的近似より遥かに大きく、12 時間の時間予算内ではオートチューナが最適構成を発見できない場合があることも関係する。 なお、エンドツーエンド近似はカーネル単体の近似より優れた性能を示す。たとえば LLM + RAG (kb) ベンチマークでは、個別カーネルの近似を合算するより複合システム全体の協調近似の方が高いスピードアップを達成する。 ### チューニングの汎化性能 チューニングセットと評価セットの間でスピードアップの乖離は LLM + bm25 で 18.6%、LLM + kb で 19.5%、LLM + tools で 3.7% にとどまり、良好な汎化を示した。 ### パレートフロンティア比較 論文では**トレードオフポイント**を三つ組 $(QoS, ExecTime, config)$ として形式的に定義し、パレートフロンティア（トレードオフ曲線）を「品質と性能の双方で支配されない非支配点の集合」と定義している。 3 種の複合 AI システム（論文 Figure 7）および 5 種のカーネルベンチマーク（論文 Figure 8）すべてにおいて、動的近似のパレートフロンティアは静的近似のそれより**低い位置**（同一 QoS 損失で実行時間が短い = より良いトレードオフ）にあり、かつ動作点が**密**（ユーザの選択肢が豊富）であった。 各プロットではチューニング時間を色の濃淡で示しており（薄い = 初期、濃い = 12 時間後）、動的近似も静的近似もチューニング時間の増加とともにフロンティアが改善されるが、動的近似は常により良いフロンティアを維持する。動的近似がフロンティア上のポイントを多く持つ理由は、`decision_tree` の閾値組み合わせにより同じ近似戦略でも入力依存の挙動が分岐し、より細粒度の動作点を生成できるためである。 カーネル粒度（lavaMD、kb、bm25、pagerank、kmeans）でも同一のパターンが確認された。 ### コンパイラ統計 - ML カーネルのコンパイル: 平均約 120 秒（パラメータ化された ML カーネルはメモリ負荷が高い） - 非 ML カーネルのコンパイル: 平均約 5 秒 - オートチューニング: 複合 AI システムで 12 時間、カーネルベンチマークで 2 時間 ### カーネル単体の高速化 カーネル単体では最大 7.38 倍（動的近似）、複合 AI システムでは最大 3.04 倍の高速化を達成した。カーネルベンチマークのパレートフロンティア（論文 Figure 8）からは以下の傾向が読み取れる。 - **lavaMD**: 実行時間が約 3.00 秒（厳密）から約 1.25 秒まで低下（QoS 損失 ~24% 以下） - **kb**: 約 3.25 秒から約 1.50 秒へ低下、動的フロンティアが密 - **bm25**: 約 12 秒から約 6 秒へ低下、動的近似のフロンティアが静的を大きく支配 - **pagerank**: 約 3.0 秒から約 1.0 秒へ低下 - **kmeans**: 約 1.4 秒から約 0.0 秒近傍まで低下可能（高 QoS 損失許容時） いずれのカーネルでも動的近似のパレートフロンティアが静的近似を支配する一貫したパターンが確認された。 ## 関連研究 論文 Section 8 では 3 つの軸で関連研究を整理している。 ### 複合 AI システムの精度・性能トレードオフ 単一モデル生成（GPT 系、BERT）から RAG や複合 AI システムへの進化に伴い、ML コードと非 ML コードの双方にまたがる最適化の必要性が増大した。従来のコンパイラは意味的等価性の保証が求められるが、複合 AI システムの構成要素はベストエフォートかつヒューリスティックであり、これを近似コンパイルの機会として活用できる。 ### 精度認識コンパイル 精度と性能のトレードオフを探索するフレームワークとして、Sculptor（Li et al., 2018）、Approxcaliper（Zhao et al., 2023）などが存在する。これらは QoS 仕様を入力として受け取り、QoS 制約を満たしつつ性能を最大化する。ノブ抽象化やソースコード注釈は 2010 年代初頭の精度認識コンパイラに端を発するが、MLIR フレームワーク上での統一的な実現は ApproxMLIR が初めてである。 安全性・精度の形式的解析では、Misailovic ら（2011, 2014）、Fernando ら（2019）の確率的正確性解析、Ugare ら（2022, 2023）や Singh ら（2025）による近似 DNN の形式検証が挙げられる。ApproxMLIR は中間表現上に近似プリミティブを明示的に公開するため、これらの解析手法を MLIR 上に導入する基盤としても機能する。 ### ML 向けコンパイラインフラストラクチャ フロントエンドとして PyTorch（Paszke et al., 2019）、JAX（Bradbury et al., 2018）、非 ML 向けの Polygeist（Moses et al., 2021）や Mojo（Modular, 2025）がある。ミドルエンドでは TVM（Chen et al., 2018）、IREE、Triton（Tillet et al., 2019）が最適化を担うが、従来は断片的であった。ApproxMLIR は MLIR インフラストラクチャ上に構築されることで、複数の抽象化レベルにまたがるコードの統一的な表現と最適化を実現している。 ## 結論・オープン課題 ApproxMLIR は「特定の近似手法」ではなく「近似にコンパイラ上の正式な抽象化を与える」ことに主眼がある。`approx` ダイアレクトが近似のスコープ・ポリシー・実装を第一級オペレーションとして保全し、`approx-opt` が段階的かつ合成可能なローワリングパスを提供し、`approx-runtime` がアプリケーション状態に基づく動的分岐選択とパレートフロンティアの探索を可能にする。 本研究が示した主要な知見は、近似管理と近似実装の分離が複合 AI システムの精度・性能トレードオフ空間の探索を大幅に容易にすること、および動的近似が静的近似を一貫して上回ることである。 オープン課題としては以下が挙げられる。 1. **構成空間の爆発とチューニング時間**: オートチューニングの時間予算（12 時間）に対して構成空間は LLM + tools で約 $1.7 \times 10^{25}$ に達する。動的近似の構成空間は静的近似より遥かに大きいため、一部のベンチマークでは時間予算内で最適構成を発見できず改善が得られない場合がある（LLM + tools の一部 QoS バジェットで動的・静的が同スコアとなった事例）。より効率的な探索アルゴリズム（ベイズ最適化、強化学習ベース探索など）の統合が有望である 2. **フロントエンドの限定**: 現在の実装は JAX フロントエンド（ML カーネル）と Polygeist フロントエンド（C/C++ 非 ML カーネル）に限定されており、PyTorch など他のフレームワークへの拡張が課題となる 3. **近似変換の種類**: 現在実装されている変換は `loop_perforate`・`func_substitute`・`task_skipping` の 3 種だが、`approx.transform` の設計は新しい書き換え規則の追加で容易に拡張可能である（論文 Appendix D 参照）。量子化（`decode_quantize` 型）も走行例として示されているが、より多様な近似戦略の体系的な実装が期待される 4. **チューニング結果の汎化**: チューニングセットと評価セットの乖離は最大 19.5% であり、概ね良好だが、入力分布が大きく変化する実運用環境での頑健性は未検証である ### 資金・計算環境 本研究は NSF（Grants CCF-2217144 および CCF-2313028）の支援を受けた。計算資源には DeltaAI（NSF award OAC 2320345 およびイリノイ州の支援）が使用された。