AIコンパイラの現在地と未来:主要技術の比較と直面する課題

深層学習コンパイラに関する包括的なサーベイ論文を基に、代表的なAIコンパイラの横比較を行い、各ツールの特徴を紐解く。さらに、現在AIコンパイラが直面している技術的課題を分析し、将来的な展望を考察する。

主要なAIコンパイラの比較と特徴

先行研究では、TVM、nGraph、TC、Glow、XLAという5つの主要なAIコンパイラが比較されている。それぞれのアーキテクチャと得意領域を見ていく。

TVM

Apache財団がホストするオープンソースの深層学習コンパイラスタック。CPU、GPU、アクセラレータなどの多様なハードウェアでニューラルネットワークを効率よく実行することを目的としている。 TVMは2層構造になっており、上位のRelay層が計算グラフの大域的最適化とフロントエンドフレームワークの統合を担当する。演算子の融合や定数畳み込み、共通部分式の除去などを行う。下位のTVM層は個別の演算子(オペレータ)の最適化とコード生成に特化しており、計算ロジックを定義するComputeと、実行スケジュールやメモリレイアウトを制御するScheduleを分離する設計を採用している。これにより、ユーザーは新規オペレータの計算定義と最適化戦略を独自に記述でき、ハードウェアの性能を最大限に引き出すカーネルコードを生成可能である。

XLA

XLA(Accelerated Linear Algebra)は、TensorFlowの計算処理を高速化するためのドメイン特化型線形代数コンパイラ。モデルのソースコードを変更することなく、計算グラフを最適化し、ハードウェア固有の実行コードにコンパイルする。 最適化の要点は、大きな演算子を細かく分解し、再構成して融合させることにある。HLO(High Level Optimizer)などの高位中間表現からLLVM IRなどを経てコードを生成し、あらかじめ定義された最適化パスを適用することで、推論時の実行効率を大幅に向上させる。

nGraph

Intelが開発したオープンソースのコンパイラフレームワーク。計算グラフを変換し、CPUやGPU、FPGAなどターゲットデバイスに応じた最適なコードを生成する。 推論時にはレイテンシの最小化とスループットの最大化を図り、訓練時には並列処理やメモリ最適化によって収束速度の向上を図るなど、推論と訓練の各フェーズで最適な効率バランスを提供する基盤として機能する。

TC (Tensor Comprehensions)

Metaによって開発されたコンパイラツール。ドメイン特化言語(DSL)を用いてテンソル計算を表現し、Just-In-Time(JIT)コンパイル技術によって実行時にGPUコードを動的生成する。 通常、オペレータの計算ロジックの実装は容易だが、ハードウェアの特性を考慮したSchedule(実行順序やメモリ配置など)の開発は困難である。TCは、多面体モデル(Polyhedral model)を活用した自動スケジューリング機能を提供し、手動でのスケジュール定義なしに高性能な計算戦略を自動導出することを可能にしている。

Glow

Metaがオープンソース化した深層学習推論フレームワーク。メモリの事前割り当てや非同期実行、低精度計算などのランタイム最適化機能を豊富に備えている。エッジデバイスからクラウドサーバーまで柔軟にデプロイ可能であり、実アプリケーションにおける推論の高速化とスループットの向上を実現する。

AIコンパイラが直面する課題

現在、AIコンパイラの実用化に向けて5つの重大な課題が存在する。

動的Shapeの汎化

既存のコンパイラは固定サイズの入力を対象とした静的最適化が得意である。しかし、自然言語処理における可変長シーケンスや、特徴ピラミッドネットワークのような多スケール処理では、実行時にテンソルの形状が変動する。この動的Shapeや制御フローにより計算グラフの構造が実行時まで確定しない場合、コンパイラは静的な最適化を適用できず、ランタイムの動的追跡に依存せざるを得なくなる。

フロントエンド言語の静的化

Pythonの動的型付けや柔軟な文法を、コンパイラの中間表現(IR)の静的な仕様に変換する難しさがある。 Pythonの実行方式として、バイトコードを解釈実行するCPythonと、JITコンパイルで機械語を生成するPyPyが存在する。これを踏まえ、AIフレームワークでは主に2つの静的化アプローチが採用されている。 1つ目はTracing Based(関数抽出)手法であり、PyTorchのtorch.fxが代表例である。実行時のトレースにより計算グラフを抽出する。
@torch.fx.wrap
def generate_noise(tensor, size):
    return torch.randn(size)

def compute_sum(input_val):
    return input_val + generate_noise(input_val, 5)
fx.symbolic_trace(compute_sum)
2つ目はAST Transform(ソースコード変換)手法であり、torch.jitが代表例である。抽象構文木を解析して静的なグラフを構築する。
def linear_calc(a, b):
    return 2 * a + b

traced_calc = torch.jit.trace(linear_calc, (torch.rand(3), torch.rand(3)))

@torch.jit.script
def exec_calc(val):
    return traced_calc(val, val)
これらのアプローチでも、動的型から静的型への型推論、if/forなどの制御フローの静的表現、スライスや辞書操作といった動的構文の処理、そしてJITコンパイル自体のオーバーヘッドといった課題が残る。

ハードウェア性能の限界までの引き出し

多様なハードウェアアーキテクチャに対応するためには、コンパイラの適応能力が極めて重要になる。しかし、レイヤレベルとオペレータレベルの独立した最適化だけではチップの性能を発揮しきれず、サブグラフの分割や垂直・水平方向の融合といったグラフとオペレータの境界を越えた最適化が求められる。また、ハードウェアの複雑化に伴い専用の最適化が増え、汎用的な最適化の実装が困難になっている。

特殊なアルゴリズムの最適化

大規模モデルの訓練におけるメモリや性能の壁を越えるため、データ並列や張量並列、パイプライン並列などの複雑な並列戦略が必要となる。これらを手動で設定するのは非常に煩雑であり、コンパイラ技術や最適化問題を用いた自動並列化が求められる。また、HPC領域では制御フローを含む動的グラフの自動微分や、ヤコビアン・ヘッセ行列の効率的な計算を伴う高階微分のサポートも難題となっている。

利便性と性能の両立

複数のAIフレームワーク間で仕様が異なる中、透過的な計算グラフのサポートを実現する難しさがある。また、TVMのようにユーザーが高水準な抽象テンプレートを提供する必要がある場合、学習コストや開発負担が増大する。さらに、コンパイル時間自体のオーバーヘッドが開発サイクルを阻害したり、手動チューニングを下回る性能しか出せなかったりする問題、そしてプロダクションレベルでの堅牢性の不足も課題である。

AIコンパイラの未来像

こうした課題を踏まえ、将来のAIコンパイラは次のような進化を遂げると予想される。
  • コンパイラ形態: 推論では事前コンパイル(AOT)を採用して効率を極限まで高め、訓練では動的需求に対応するため即時コンパイル(JIT)を採用するなど、目的に応じた最適なコンパイル方式を選択可能になる。
  • IRの統一: MLIRのような拡張性の高い統一中間表現が普及し、異なるフレームワークや言語間でのシームレスな最適化と変換が可能になる。
  • 自動並列化: クラスタを跨いだ自動並列化機能が標準化され、システムリソースに応じてタスクの割り当てと调度を自動で最適化する。
  • 高階自動微分: 高階微分をサポートし、計算グラフの構造を柔軟に操作できる高度な自動微分機能が実装される。
  • カーネル自動生成: Polyhedralモデルや機械学習を用いた探索により、ハードウェア固有のカーネルコードを自動生成し、手動チューニングを不要にする。

フロントエンド最適化のアーキテクチャ

AIコンパイラのフロントエンドは、フレームワーク(TensorFlowやPyTorchなど)から出力されたGraphIRを受け取り、レイヤレベルの最適化を実行する。 具体的には、定数畳み込み、定数伝播、オペレータ融合、式の簡略化、共通部分式除去などの複数の最適化Passが順次適用される。各Passの処理結果もGraphIRとして出力され、次のPassへと渡されるパイプライン処理を構成している。このフロントエンド最適化の完了後、最適化されたGraphIRはバックエンドの処へと受け渡される。

タグ: TVM XLA nGraph Glow TensorComprehensions

5月28日 18:53 投稿