8月1日第9回Meet AIコンパイラ技術サロンが北京で盛況のうちに閉幕しました。AIコンパイラの分野における複数の専門家や研究者が北京の中関村に集まり、技術革新と実践経験に関する知見を共有した。その目的は、言語表現、演算子計算、推論実行、シナリオアプリケーションなど、複数のレベルにわたるAIコンパイラの協調的な進化の全体像を示すことであった。

ティアンチー・チェンは、カーネギーメロン大学の機械学習学科およびコンピュータサイエンス学科の助教授であり、NVIDIAのディスティングイッシュド・エンジニアであり、世界的に有名なオープンソースプロジェクトであるXGBoost、Apache TVM、およびMLC LLMの中核開発者兼創設者です。彼は特別ゲストとしてイベントに参加した。AIコンパイラ分野の先駆者である彼は、TVMオープンソースコミュニティの現在の開発方向性について語り、参加者と深い意見交換を行った。

HyperAIは、陳天奇教授の発言内容を原文の意味を損なうことなく編集・要約しました。

皆さん、こんにちは。このイベントに参加し、私の知見を皆さんと共有できることを大変嬉しく思います。私は陳天奇と申します。私たちは長年AIコンパイラの分野を探求してきましたが、今年は非常に興味深い年となりました。年初からAIエージェントの波が急速に高まり、業界ではいくつかの新たな問題が浮上し始めています。

最初の疑問：AIコンパイラにはまだ価値があるのか？エージェントを直接プログラミングできるようになった今、コンパイラは必要なのだろうか？

2つ目の質問：自動化によって、より多くのことが可能になります。従来、小規模チームにとって最大のボトルネックはエンジニアリングリソースでしたが、エージェントの登場により、より少ないチームでより多くのことを達成できるようになりました。

今日お伝えしたいことは以下のとおりです。AIエージェントの時代において、AIコンパイラをどのように再考すべきでしょうか？将来のAIコンパイラはどのような方向性を目指すべきでしょうか？

エージェント固有の反復処理を加速する

重要な特徴の一つは、エージェントはコンテキストが限られているため、比較的迅速かつ専用の反復開発が必要となる点です。従来は、大規模なプロジェクト開発、特に大規模なモノリシックリポジトリを優先する傾向がありましたが、現在ではエージェント専用の反復開発が非常に重要な方向性になりつつあります。

まず、エージェント固有の反復処理を加速するために、プロジェクト境界の安定性、構成可能性、およびモジュール性が非常に重要であることがわかりました。

TVM FFIプロジェクトを例にとると、その目標は、大規模なTVMフレームワークの中核となる要素、つまり関数同士の呼び出し方法を明確に定義することです。これには、フレームワークのDSLから、cuteDSLやFlashInferといったバックエンドに至るまで、異なるコンポーネント間の関数境界を定義することが含まれます。以前はエンドツーエンドのソリューション構築に重点を置いていましたが、現在では、演算子やモジュール間を容易に切り替えられるような、より有機的な境界を定義する必要性が高まっています。そのため、境界そのものを明確に定義し、標準化することが非常に重要になってきています。

TVM FFIは昨年リリースされて以来、cuteDSL、FlashInfer、そして最近ではTensorRTなど、様々な技術と統合されてきました。その目的は、境界仕様がどのようなものであるべきかを定義することです。境界が明確に定義されれば、中間モジュールをより柔軟に置き換えることが可能になります。

第二に、エージェントが専用の反復処理を迅速に完了できるようにするため、今後、より多くの言語サポートが提供される予定です。

エージェントのフィードバック時間が1時間または2時間になると、試行錯誤にかかる時間はどんどん長くなります。そのため、コンパイラ自体がより多くの言語をサポートする必要があり、インフラレベルでより多くの言語をサポートするよう推進していきます。

従来、ユーザーは通常、プログラムと対話していましたが、そのプログラム自体が対話の対象でした。しかし、AIはより高度な知能を持つようになるため、人々がすべての計算を直接行うのではなく、ツールを作成するようになるかもしれません。例えば、数学的な計算を行う際、必ずしも頭の中で計算する必要はなく、ツールを利用すればよいのです。同様に、コンパイラの内部分析機能とインフラストラクチャが徐々に注目を集めるようになると私たちは考えています。コンパイラをモジュール化することで、AIが現在のニーズに合わせて独自の分析および反復プロセスを構築できるようになることを目指しています。

これを実現するために、最近は TIRx に取り組んでおり、Modern GPU Programming というチュートリアルも公開しました。もちろん、GPU に限定されるものではなく、より一般的なアクセラレータ プログラミングの概念を紹介しようとしています。過去 6 か月で、時間の約半分をコードを書くことに費やしたと Feng Siyuan に話しました。エージェントを使用すると、プロジェクト全体のコードを実際に戻ってリファクタリングできるからです。昨年、TVM FFI モジュールを比較的独立して安定させましたが、TIRx の独立性と安定性をさらに促進していきます。

エージェント時代において、コンパイラは何ができるのか？

従来のコンパイラには重要な特徴があることが分かりました。それは、通常、2種類の要素を同じスタックに格納しているということです。1つは自動スケジューリングなどの高レベルでインテリジェントな部分、もう1つは純粋にルールベースの処理などの低レベルでインテリジェントではない部分です。しかし、将来的にはこの傾向は変化すると考えています。安定した部分と迅速な反復が必要な部分を分離する必要性がますます高まるでしょう。つまり、比較的安定したコアモジュールが存在し、その上にエージェント関連の機能を柔軟に追加していくことで、エージェントが専用コンパイラを構築し、ニーズに応じてプロセスを最適化できるようになるということです。

本題に戻ります。エージェント時代において、コンパイラは何ができるのでしょうか？

来年の今頃、あるいは今年の終わりまでには、私たちが議論しているAIコンパイラは、今年以前に議論していたものとは間違いなく異なっているでしょう。これは、私たちが共にこのことを再考する非常に興味深い機会です。

逆に、道具を持つ人間は、肉体だけを持つ人間よりも明らかに強い。AIコンパイラ自体も一種の道具である。したがって、コンパイラ関連モジュールの設計・開発にAIをより効果的に活用できる能力があれば、今後も多くの興味深い機会が生まれるだろう。

以上が私が伝えたかったことです。皆さん、ありがとうございました。

質疑応答セッション

質問1：ハードウェアの種類がますます増えるにつれて、将来のコンパイラは汎用的なアーキテクチャへの適応を採用すべきでしょうか、それともハードウェア固有の適応を採用すべきでしょうか？

チェン・ティエンチー：エージェントの登場により、多くのことが変化するでしょう。従来、異なるバックエンド間でコードを共有できる場合、誰もが自然とコードを共有することを好みます。そのため、当初は統一的な開発のために大規模なモノレポシステムを構築する傾向がありました。しかし、エージェントの登場によりコード開発のコストが削減されるため、将来的にはより専門的な部分が登場することは間違いありません。これは、共有コードの抽象化がハードウェア自体の機能を十分にサポートできない場合に特に当てはまります。このようなケースは頻繁に発生します。例えば、GPU上でも、Hopper向けに設計されたコンパイラはBlackwell以降は全く使用できなくなる可能性があります。このような事態は頻繁に発生するため、将来的には専門化が不可欠となるでしょう。

逆に、何が共通性を保つことができるのかという疑問が残ります。エージェントがハードウェア固有のコンパイラを構築できるような、比較的安定した基盤が依然として必要です。例えば、TIRxに関する最近の研究では、異なるハードウェアが独自のディスパッチルールを登録できるようにし、エージェントがハードウェアの特性に基づいて関連知識を生成できるようにすることを目指しています。

今後、より特化型のコンパイラがますます増えていくでしょう。それはおそらく2つの部分に分かれると考えられます。1つ目は、ABI要件、コアIRデータ構造、言語間連携機能など、高い安定性が求められる、より安定した部分です。2つ目は、特定のシナリオに特化した部分で、将来的にはエージェント主導型になる可能性が高いでしょう。今後、このようなコンパイラがますます増えていくと予想されます。

質問2：学習過程において、情報検索（IR）における従来の抽象的な境界が崩壊し、融合されつつあることに気づきました。以前は明確に定義されていたものが、徐々にIRに吸収されつつあるようです。このような観点から、AIコンパイラの今後の発展方向はどのようなものだとお考えですか？

チェン・ティエンチー：これは大きく2つの部分に分けられると思います。まず、現在では異なるIR（情報表現）が異なって見えるかもしれませんが、実際には多くの点で非常に似通っており、基本的にはカーネルレベル、グラフレベル、そしてそれらの間の相互作用といういくつかのレベルに分けられます。数年の進化を経て、徐々にいくつかのより安定したレベルに収束していくでしょう。層が多すぎると、層間の遷移時に情報が失われることが多いため、実際にはメリットがありません。したがって、いくつかの主要なレベルに収束したら、核心的な問題は「必要な情報をどのようにエンコードするか」ということになるでしょう。

第2部では、これまで強力なコンパイラを必要としていた多くのタスクを、外部の担当者やエージェントに制御を委任できるかどうかという問題を取り上げます。言い換えれば、コンパイラをより軽量化したり、階層化したりできるかどうかということです。階層化とは、継続的に維持できる比較的安定した層と、迅速に反復できる別の層を持つことを意味します。少なくとも将来的には、この2つの層は確実に存在するでしょう。

質問3：AIコンパイラの観点から、将来的にAIがAIコンパイラを作成するようになるでしょうか？短期的には、AIが作成するのに適したコンパイラコンポーネントは何でしょうか？主な課題は何でしょうか？

チェン・ティエンチー：まず第一に、ここにいる多くの実務家は既にAIを使ってコンパイラを作成し始めていると私は考えています。ですから、これは将来の可能性の問題ではなく、今まさに起こっていることなのです。

ここではモジュール化が非常に重要です。AIが大規模プロジェクトを完全に管理するのは確かに困難ですが、迅速な反復と試行錯誤のために特定のモジュールをAIに委任することは十分に可能です。鍵となるのは、問題を明確に定義されたサブ問題に分解することです。したがって、境界定義が不可欠です。当社のTVM FFIアプローチは、これらの境界を明確に定義することを目的としています。

同様に、優れたIRインフラストラクチャも非常に重要です。例えば、現在、Python、Rust、C++などの言語をサポートするコンパイラIRを作成したい場合、完全に実現可能なソリューションは存在しません。将来、そのようなインフラストラクチャを提供できれば、開発効率が大幅に向上するでしょう。

では、インフラストラクチャ以外に何ができるでしょうか？それは、共通のニーズを抽出できるかどうかにかかっていると思います。例えば、以前にも議論した問題があります。コンパイラの重要な部分の一つは、ホスト側のコスト削減です。この問題は、実際にはGPUアクセラレーションやハードウェアアクセラレーションとは比較的独立しています。しかし、ホスト側の最適化自体には、自動化の余地がまだたくさんあります。こうした共通のニーズを抽出できれば、将来的にAIはコンパイラ開発においてより大きな役割を果たすようになるでしょう。

質問4：低レベルDSLや高レベルDSLなど、さまざまなレベルのコンパイラは、将来的に業界や開発エコシステムにおいてどのような位置を占めるようになるでしょうか？

陳天奇：レベルごとにニーズが異なると思います。一般的には、低レベルを公開しつつ、低レベルと高レベルの両方を表現する手段を持つことが望ましいです。例えば、私たちが最近開発したTIRxは、異なるレベルごとに独自の表現手段を持ち、ネイティブパートナーレベルの表現手段も備えているため、両者間の柔軟な移行が可能です。ただし、原則として、エージェントはこれらの事柄を表現するためにできるだけ少ないトークンを使用し、同時にその機能を制限しないようにする必要があります。

質問5：これまでコンパイラについて議論する際、カーネルレベルに重点を置いてきましたが、実際にはIRを用いて表現できるものはたくさんあります。そこで、将来的にはカーネルレベルのIRだけでなく、マイクロレベルのIR、さらにはスケジューリングレベルのIRもAIコンパイラの研究方向となるのでしょうか？

チェン・ティエンチー：これは実際にはごく普通のことです。なぜなら、グラフレベルコンパイラは以前から存在していたからです。ただ、これまではカーネルコンパイラとグラフレベルコンパイラの連携が比較的弱かっただけです。グラフレベルコンパイラは主にグラフレベルの問題を解決し、カーネルレベルコンパイラは主にカーネルレベルの問題を解決していました。しかし、今後は両者の連携がますます必要になるでしょう。

近年の主要な研究方向の一つにMegaKernelがあり、これはカーネル間の相互作用を必要とします。そのため、私たちは両方のタイプの情報を単一のIR（統合リソース識別子）内にカプセル化する方法を検討してきました。これが将来的に実現できれば、興味深い発展につながると考えています。例えば、これまでのMegaKernelの研究では、最適化を実現するためにグラフレベルとカーネルレベルの相互作用を基本的に利用していました。

質問6：エージェントフレンドリーコンパイラは正しい命題ですか？

チェン・ティエンチー：将来的には、コンパイラが不要になり、エージェントが直接アセンブリを生成できるようなシナリオも考えられます。違いは、エージェントにこのタスクを直接実行させるか、エージェントにコンパイラを記述させてツール自体を作成させるかという点にあります。個人的には、コンパイラは多くの状況で開発効率を向上させることができるため、依然として価値があると考えています。

では、「エージェントフレンドリー」とは、正しい命題なのでしょうか、それとも誤った命題なのでしょうか？鍵となるのは、ソフトウェアが最初からこの特性を備えているかどうかではなく、むしろそれを目標として設計するかどうかにあるのではないでしょうか。エージェントが関与するようになったら、エージェントのパフォーマンスが優れている点、劣っている点を継続的に観察し、そのフィードバックに基づいて改善を繰り返していくのです。

例えば、言語間の互換性は現実的な課題です。エージェントは最初はPythonを使ってコンパイラパスを迅速に開発できるかもしれませんが、高速化が必要になった場合はC++やRustに切り替える必要があるかもしれません。これらの課題を目標として捉えるならば、それは決して悪いことではないと私は考えています。なぜなら、コードの大部分は既にエージェントによって書かれているからです。将来的には、コンパイラはエージェントが構築や最適化を支援するツールとしても活用できるようになるでしょう。

上記は、Meet AI Compiler Technical Salonにおける陳天奇教授の示唆に富んだプレゼンテーションの要約です。このイベントで行われたその他の興味深い講演についても、議事録の形で報告する予定ですので、ご期待ください！