Ali BladeDISC Deep Learning Compiler Officially Open Source

第 1 章：はじめに

ディープラーニングの継続的な発展に伴い、AI モデルの構造は急速に進化しており、基盤となるコンピューティングハードウェア技術も次々と登場しています。開発者にとって、複雑で変化に富むシナリオにおいてコンピューティング能力を効果的に活用する方法を検討するだけでなく、コンピューティングフレームワークの継続的なイテレーションにも対処する必要があります。ディープラーニングコンパイラは、こうした課題に対処するための広く注目されている技術方向であり、ユーザーが上位レベルのモデル開発にのみ集中できるようにし、手動パフォーマンス最適化の人的開発コストを削減し、さらにハードウェアパフォーマンスの可能性を最大限引き出します。Alibaba Cloud Machine Learning PAI は、業界内でいち早く実業務アプリケーションに導入された動的シェイプ対応ディープラーニングコンパイラ BladeDISC をオープンソース化しました。本記事では、BladeDISC の設計原理とアプリケーションについて詳しく解説します。

第 2 章：BladeDISC とは

BladeDISC は、Alibaba が最新にオープンソース化した MLIR ベースの動的シェイプ対応ディープラーニングコンパイラです。

1 主な機能

*複数のフロントエンドフレームワークサポート：TensorFlow、PyTorch
*複数のバックエンドハードウェアサポート：CUDA、ROCM、x86
*動的シェイプセマンティクスコンパイルの完全サポート
*推論とトレーニングのサポート
*軽量 API、ユーザーにとって汎用的かつ透明
*ホストフレームワークにプラグインモードで組み込んで実行するサポート、および独立したデプロイモード

第 3 章：ディープラーニングコンパイラの背景

近年、ディープラーニングコンパイラは比較的新しい技術方向として非常に活発に研究されており、古くからある TensorFlow XLA、TVM、Tensor Comprehension、Glow や、後に高く人気を集めた MLIR とその異なる分野での拡張プロジェクト IREE、mlir-hlo などがあります。さまざまな企業やコミュニティがこの分野で多くの探求と前進を行っていることがわかります。

1 AI の波とチップの波が共同で育んだ - 萌芽から力強い発展へ

ディープラーニングコンパイラが近年継続的に注目されている理由は、主にいくつかの理由から来ています：

モデル汎化におけるフレームワークパフォーマンス最適化の要件

ディープラーニングは日進月歩で発展しており、革新的なアプリケーション分野が次々と登場しています。複雑で変化に富むシナリオにおいてハードウェアのコンピューティング能力を効果的に活用することが、AI アプリケーションチェーン全体の非常に重要な部分となっています。かつて、ニューラルネットワークデプロイの焦点はフレームワークとオペレーターライブラリにありました。この責任の大部分は、ディープラーニングフレームワーク、ハードウェアベンダーが提供するオペレーターライブラリ、およびビジネスチームの手動最適化作業によって担われていました。

上の図は、近年のディープラーニングフレームワークを大まかに 3 世代に分類したものです。1 つの傾向は、上位のユーザー API レベルでは、これらのフレームワークはますます柔軟になっており、同時に、基盤となるパフォーマンス問題に対してより大きな課題を提起していることです。第 1 世代のディープラーニングフレームワークは Caffe のようなもので、layer のシーケンスを使用してニューラルネットワーク構造を記述していました。第 2 世代は TensorFlow のようなもので、オペレーターのより細かい粒度のグラフを使用して計算グラフを記述していました。第 3 世代は PyTorch、TensorFlow Eager Mode の動的グラフのようなものです。フレームワークがますます柔軟になり、記述能力がますます強くなっていることがわかります。それによってもたらされる問題は、基盤となるパフォーマンスの最適化がますます難しくなっていることです。ビジネスチームはまた、必要な手動最適化を補う必要がよくあります。これらのタスクは特定のビジネスと基盤となるハードウェアの理解に依存しており、 人的集約的で汎化が困難です。ディープラーニングコンパイラは、コンパイル時レイヤーの最適化と自動または半自動コード生成を組み合わせ、手動最適化の原理を汎化して、純粋な手動最適化によって引き起こされるさまざまな問題を置き換え、ディープラーニングの柔軟性とパフォーマンスの間の矛盾を解決します。

ハードウェア汎化に対する AI フレームワークの要件

表面的には、近年の AI の発展は誰の目にも明らかで勢いがありますが、その背景にある数十年のハードウェアコンピューティング能力の発展が AI の繁栄を触媒する原動力となっています。トランジスタのスケーリングが直面する物理的課題の増大に伴い、チップのコンピューティング能力の向上はますます難しくなってきており、ムーアの法則は失敗に直面しており、革新的なアーキテクチャを持つさまざまな DSA チップが熱狂的な波を迎えています。従来の x86、ARM もそれぞれ異なる分野で競争力を強化しています。ハードウェアの繁栄は、AI フレームワークの開発に新たな課題をもたらしています。

ハードウェアの革新は 1 つの問題ですが、実際のビジネスシナリオにおいてハードウェアのコンピューティング能力をどのように活用するかは別の問題です。新しい AI ハードウェアメーカーは、ハードウェア上で革新するだけでなく、ソフトウェアスタックに多額の人的投資を行う必要のある問題に直面しなければなりません。コンパイラによる下位互換性を確保する方法が、今日のディープラーニングフレームワークの核心的な難しさの 1 つであり、ハードウェア互換性の問題はコンパイラによって解決される必要があります。

フロントエンド AI フレームワークの汎化に対する AI システムプラットフォームの要件

今日の主流のディープラーニングフレームワークには、TensorFlow、PyTorch、Keras、JAX などがあります。いくつかのフレームワークにはそれぞれ長所と短所があり、ユーザーへの上位レベルのインターフェースで異なるスタイルを持っていますが、ハードウェア適応とハードウェアコンピューティング能力の完全な活用という問題にも直面しています。異なるチームは、それぞれのモデリングシナリオと使用習慣に応じて異なるフレームワークを選択することがよくありますが、クラウドベンダーやプラットフォームのパフォーマンス最適化ツールとハードウェア適応ソリューションは、異なるフロントエンドフレームワークや将来のフレームワーク進化のニーズさえも考慮する必要があります。Google は XLA を使用して TensorFlow と JAX を同時にサポートしています。同時に、他のオープンソースコミュニティでは Torch_XLA や Torch-MLIR などのアクセスソリューションが進化しています。これらのアクセスソリューションは使いやすさと成熟度の面でまだいくつかの問題を抱えていますが、AI システムレイヤーの作業に対するフロントエンド AI フレームワークの汎化要件と技術トレンドを反映しています。

2 ディープラーニングコンパイラとは

従来のコンパイラは高級言語を入力として使用し、ユーザーが直接機械コードを書くことを避け、比較的柔軟で効率的な言語で作業し、コンパイルプロセスで最適化を導入して、高級言語によって導入されるパフォーマンス問題を解決し、開発効率とパフォーマンスの間の矛盾をバランスさせます。ディープラーニングコンパイラの役割も同様です。その入力はより柔軟で、計算グラフ記述のより高い抽象度を持ち、出力は CPU、GPU およびその他の異種ハードウェアプラットフォーム上の基盤となる機械コードと実行エンジンを含みます。

従来のコンパイラの使命の 1 つは、プログラマーの負担を軽減することです。コンパイラの入力として使用される高級言語は、しばしばロジックを記述することに重点を置いており、プログラマーの便宜のために、高級言語の記述はより抽象的で柔軟なものになります。このロジックがマシン上で効率的に実行できるかどうかは、しばしばコンパイラの重要な指標です。近年非常に急速に発展したアプリケーション分野であるディープラーニングは、そのパフォーマンス最適化が非常に重要であり、高級記述の柔軟性と抽象化、および基盤となるコンピューティングパフォーマンスの間の矛盾もあり、ディープラーニング専用のコンパイラが登場しました。従来のコンパイラの別の重要な使命は、プログラマーが入力した高級言語が異なるアーキテクチャと命令セットを持つハードウェアコンピューティングユニットで実行されることを保証することです。これはディープラーニングコンパイラにも反映されています。新しいハードウェアデバイスに直面して、すべてのターゲットハードウェアに対してフレームワークが必要とするすべてのオペレーターを再作成する人的エネルギーがあることはまずありません。ディープラーニングコンパイラは中間層の IR を提供し、最上位フレームワークのモデルフローグラフを中間層に変換し、中間層 IR に対して汎用層の最適化を実行し、最適化された IR からバックエンドで各ターゲットプラットフォームの機械コードを一般的に生成します。

ディープラーニングコンパイラの目標は、AI コンピューティングタスクに対して汎用コンパイラの形でパフォーマンス最適化とハードウェア適応を完了することです。これにより、ユーザーが上位レベルのモデル開発に集中できるようになり、ユーザーがパフォーマンスを手動で最適化するための人的開発コストを削減し、さらにハードウェアパフォーマンスの可能性を最大限引き出します。

3 距離の大規模アプリケーションが直面するボトルネック問題

ディープラーニングコンパイラは今日まで発展してきました。目標と技術アーキテクチャの面で従来のコンパイラと多くの類似点を持ち、技術方向で良好な可能性を示していますが、現在の実用的なアプリケーション範囲は従来のコンパイラからまだ大きな隔たりがあり、主な難しさは次のとおりです：

使いやすさ

ディープラーニングコンパイラの本来の目的は、パフォーマンスの手動最適化とハードウェア適応の人的コストを簡素化することです。しかし、現段階では、ディープラーニングコンパイラの大規模デプロイとアプリケーションはまだ大きな課題であり、コンパイラを使用するための閾値は比較的高いです。この現象の主な理由は次のとおりです：

フロントエンドフレームワークとのドッキングの問題。異なるフレームワークは、ディープラーニングタスクに対して異なる抽象記述と APIインターフェイスを持ち、セマンティクスとメカニズムでそれぞれの特徴があり、コンパイラの入力として使用されるフロントエンドフレームワークのオペレータータイプの数はオープンです。すべてのオペレーターが完全にサポートされることを保証せずに、ユーザーの計算グラフ記述を透過的にサポートする方法は、ディープラーニングコンパイラがユーザーに広く使用されるための重要な要素の 1 つです。

動的シェイプ問題と動的計算グラフ問題。現段階では、主流のディープラーニングコンパイラは主に特定の静的シェイプ入力に対してコンパイルを完了します。さらに、制御フローセマンティクスを含む動的計算グラフに対して限定的なサポートしか提供できないか、まったくサポートを提供できません。しかし、AI のアプリケーションシナリオにはこのようなタスク要件が多数あります。この時、計算グラフを手動で静的または半静的な計算グラフに書き直すか、コンパイラに適した一部のサブグラフを抽出してコンパイラに渡す方法を見つけることしかできません。これは間違いなくディープラーニングコンパイラを適用する際のエンジニアリング負担を増大させます。より深刻な問題は、多くのタスクタイプが手動で静的に書き直すことができないことであり、これはこれらの場合においてコンパイラが完全に使用できないことを意味します。

コンパイルオーバーヘッドの問題。パフォーマンス最適化ツールとしてのディープラーニングコンパイラは、そのコンパイルオーバーヘッドがそれによってもたらされるパフォーマンスメリットと比較される場合にのみ、真の実用的な価値を持ちます。一部のアプリケーションシナリオではコンパイルオーバーヘッドに対する要件が高く、たとえば通常の規模でトレーニングタスクを完了するのに数日かかり、数時間のコンパイルオーバーヘッドは許容できない可能性があります。アプリケーションエンジニアにとって、コンパイラを使用する際にモデルのデバッグを迅速に完了できないことは、開発とデプロイの難しさと負担を増大させます。

ユーザーに対する透明性の問題。一部の AI コンパイラは完全自動コンパイルツールではなく、そのパフォーマンスはユーザーが提供する高レベル抽象実装テンプレートに依存します。主にオペレーター開発エンジニア向けの効率ツールを提供し、ユーザーがさまざまなオペレーター実装を手動でチューニングするための人的コストを削減することです。しかし、これはユーザーのオペレーター開発経験とハードウェアアーキテクチャの熟悉度に比較的高い要件を提起しています。さらに、新しいハードウェアのソフトウェア開発者にとって、既存の抽象化では革新的なハードウェアアーキテクチャで必要なオペレーターの実装を記述するには不十分であることがよくあります。コンパイラアーキテクチャを十分に理解して二次開発や構造的再構築を行う必要があり、間敷きと開発負担はまだ高いです。

堅牢性

現在、主流の AI コンパイラプロジェクトのほとんどはまだ実験的な製品であり、製品の成熟度と産業アプリケーションの間には大きな隔たりがあります。ここでの堅牢性には、入力計算グラフのコンパイルが正常に完了できるかどうか、計算結果の正しさ、およびパフォーマンスの面で コーナーケースにおける極端な不良ケースの回避が含まれます。

パフォーマンス問題

コンパイラの最適化の本質は、手動最適化方法の汎化された沈殿と抽象化、または人間が容易に探求できない最適化方法を通じて、限られたコンパイルオーバーヘッドで手動最適化の人的コストを置き換えることです。しかし、方法論をどのように沈殿させ抽象化するかが、全体のリンクにおいて最も本質的で困難な問題です。ディープラーニングコンパイラは、パフォーマンスの面で手動最適化を本当に置き換えまたは超越できる場合、または人的コストを大幅に削減できる場合にのみ、その価値を本当に発揮できます。

しかし、この目標を達成することは容易ではありません。ほとんどのディープラーニングタスクはテンソルレベルの計算であり、並列タスクの分割に対して高い要件を持っています。しかし、手動最適化と汎化をどのようにコンパイラ技術に統合し、コンパイルオーバーヘッドの爆発を回避し、階層化後の異なるレベル間の最適化リンクを行うかについては、まだ探求・発掘が必要な未知の領域が多く残っています。これは、MLIR フレームワークに代表される次世代のディープラーニングコンパイラが注目して解決する必要がある問題となっています。

第 4 章：BladeDISC の主な技術的特徴

本プロジェクトの本来の目的は、XLA と TVM の現バージョンの静的シェイプ制限を解決することでした。内部的に DISC（DynamIc Shape Compiler）と名付けられ、動的シェイプセマンティクスを完全にサポートし、実際のビジネスで使用できるディープラーニングコンパイラを作成することを望んでいました。

チームが 4 年前にディープラーニングコンパイラの作業を開始して以来、動的シェイプ問題は実際のビジネス実装を妨げる深刻な問題の 1 つでした。当時、XLA を含む主流のディープラーニングフレームワークは、静的シェイプセマンティクスに基づくコンパイラフレームワークでした。典型的なソリューションでは、ユーザーが入力シェイプを指定するか、コンパイラがランタイム時にコンパイルされるサブグラフの実際の入力シェイプの組み合わせをキャプチャし、各入力シェイプの組み合わせに対してコンパイル結果を生成する必要がありました。

静的シェイプコンパイラの利点は明らかです。静的シェイプ情報がコンパイル時に完全にわかっている場合、コンパイラはより良い最適化判断を下し、より良い CodeGen パフォーマンス、およびより良いビデオメモリ/メモリ最適化プランとスケジューリング実行プランを取得できます。しかし、その欠点も非常に明らかで、次のようなものがあります：

コンパイルオーバーヘッドが大幅に増加します。オフラインコンパイルウォームアッププロセスが導入され、推論タスクデプロイプロセスの複雑さが大幅に増加します。トレーニングのイテレーション速度が不安定になり、さらには全体のトレーニング時間が負に最適化されることさえあります。
一部のビジネスシナリオでは、シェイプ変化の範囲が無限大に近くなる傾向があり、コンパイルキャッシュが決して収束せず、ソリューションが利用不能になります。

メモリ使用量の増加。コンパイルキャッシュによって占有される追加のメモリとビデオメモリは、実際のデプロイ環境でメモリ/ビデオメモリの OOM を引き起こすことが多く、ビジネスの実際の実装を直接妨げます。

静的シェイプに対する人工パディングなどの緩和ソリューションはユーザーフレンドリーではなく、アプリケーションの汎用性と透明性を大幅に低下させ、イテレーション効率に影響を与えます。

2020 年夏、DISC は TensorFlow フロントエンドと Nvidia GPU バックエンドのみをサポートする最初のバージョンを完成させ、Alibaba 内部で正式にリリースされ、実用的なアプリケーションに投入されました。最初に、長期的に動的シェイプ問題に悩まされていたいくつかのビジネスシナリオに投入され、期待される結果を達成しました。つまり、1 回のコンパイルでユーザーが計算グラフの特別な処理を行わない場合でも、動的シェイプセマンティクスを完全にサポートし、そのパフォーマンスは静的シェイプコンパイラとほぼ同等でした。TensorRT のような手動オペレーターライブラリに基づく最適化フレームワークと比較して、コンパイラ自動コード生成に基づく DISC の技術アーキテクチャは、しばしば非標準のオープンソースモデルである実際のビジネスにおいて、パフォーマンスと使いやすさの面で明らかな利点を達成しました。

2020 年第 2 四半期以来、DISC は研究開発に継続的に投資してきました。クラウドプラットフォームの観点から、大規模デプロイとアプリケーションに向けた前述のディープラーニングコンパイラのボトルネックに取り組むために、パフォーマンスとオペレーターカバレッジを向上させました。カバレッジレートおよび堅牢性、CPU と新しいハードウェアサポート、フロントエンドフレームワークサポートなどが徐々に改善されました。現在、シナリオカバレッジとパフォーマンスの面で、XLA や TVM などの静的シェイプフレームワークに基づくチームの以前の作業を徐々に置き換え、PAI-Blade が Alibaba の内外のビジネスをサポートする主な最適化方法となっています。2021 年以降、CPU と GPGPU アーキテクチャのバックエンドハードウェアでの DISC のパフォーマンスは大幅に向上し、新しいハードウェアのサポートにより多くの技術力を投資しました。2021 年末、より多くの技術交流と協力、および共同構築のニーズを引き付け、より広い範囲のユーザーフィードバックを得るために、正式に BladeDISC に改名され、最初のバージョンのオープンソースが完了しました。

第 5 章：主要技術

BladeDISC の全体的なアーキテクチャと Alibaba Cloud の関連製品との関係を下図に示します：

1 MLIR インフラストラクチャ

MLIR は 2019 年に Google によって開始されたプロジェクトです。MLIR の核心は、柔軟な多層 IR インフラストラクチャとコンパイラユーティリティライブラリです。LLVM の影響を深く受け、その優れた概念の多くを再利用しています。ここで MLIR ベースを選択する主な理由には、比較的豊富なインフラストラクチャサポート、拡張が容易なモジュール式設計アーキテクチャ、および MLIR の強力なグルー能力が含まれます。

2 動的シェイプコンパイル

上の図は BladeDISC の主要なパスパイプライン設計を示しています。現在の主流のディープラーニングコンパイラプロジェクトと比較して、主な技術的特徴は次のとおりです：

レイヤー IR 設計

BladeDISC は HLO を核心レイヤー IR として選択し、異なるフロントエンドフレームワークにアクセスしますが、HLO は元々 XLA 向けに設計された純粋な静的シェイプセマンティクスを持つ IR です。静的シナリオでは、HLO IR のシェイプ式は静的になり、すべてのシェイプ計算はコンパイル時定数として固化され、コンパイル結果に保持されます。一方、動的シェイプシナリオでは、IR 自体がシェイプ計算と動的シェイプ情報の伝送を十分に表現する能力を持つ必要があります。BladeDISC はプロジェクトの設立以来 MHLO コミュニティと緊密な協力関係を維持しており、XLA の HLO IR を基に、完全な動的シェイプ表現能力を持つ IR のセットを拡張し、フロントエンドフレームワークの対応するインフラストラクチャとオペレーター変換ロジックを追加しました。この実装の一部は MHLO コミュニティに完全にアップストリームされ、他の後続の MHLO 関連プロジェクトでの IR の一貫性が保証されています。

ランタイムシェイプ計算、ストレージ管理、カーネルスケジューリング

動的シェイプコンパイルの主な課題は、静的コンパイル時に動的計算グラフセマンティクスを処理できる必要があることです。動的シェイプを完全にサポートするために、コンパイル結果はランタイム時にリアルタイムのシェイプ導出計算を実行できる必要があり、データ計算のためだけでなく、シェイプ計算のためのコード生成も行う必要があります。計算されたシェイプ情報は、メモリ/ビデオメモリ管理、カーネルスケジューリング時のパラメーター選択などに使用されます。BladeDISC のパスパイプラインの設計は、動的シェイプセマンティクスサポートに対する前述の要件を十分に考慮し、ホストデバイスとコード生成を組み合わせたスキームを採用しています。GPU バックエンドを例にとると、シェイプ計算、メモリ/ビデオメモリアプリケーションリリース、ハードウェア管理、カーネル起動ランタイムを含むすべてのプロセスが自動的にコード生成され、完全な動的シェイプエンドツーエンドサポートソリューションとより極端な全体的なパフォーマンスを取得します。

動的シェイプ下でのパフォーマンス問題

シェイプが不明または部分的に不明な場合、ディープラーニングコンパイラが直面するパフォーマンス課題はさらに増幅されます。ほとんどの主流のハードウェアバックエンドで、BladeDISC は計算集約型部分とメモリ集約型部分を区別する戦略を採用し、パフォーマンスと複雑さおよびコンパイルオーバーヘッドの間のより良いバランスを達成しています。

計算集約型部分では、異なるシェイプはより良いパフォーマンスを達成するためにきめ細かいスケジュール実装を必要とします。パスパイプラインの設計での主な考慮事項は、ランタイム時に異なる特定のシェイプに応じて適切なオペレーターライブラリ実装の選択をサポートし、動的シェイプセマンティクス下のレイアウト問題を処理することです。

ディープラーニングコンパイラのパフォーマンスメリットの主な源泉の 1 つとして、メモリ集約型部分の自動オペレーターフュージョンも、シェイプが不明な場合にパフォーマンス課題に直面します。静的シェイプセマンティクス下の多くの決定論的な問題、たとえば命令レベルのベクトル化、コード生成テンプレート選択、暗黙的なブロードキャストが必要かどうかなどは、動的シェイプシナリオではより大きな複雑さに直面します。これらの問題に対して、BladeDISC はコンパイル時からランタイム時に一部の最適化判断を沈下させることを選択しました。つまり、コンパイル時に一定のルールに従って複数のバージョンのカーネル実装を生成し、ランタイム時に実際のシェイプに応じて最適な実装を自動的に選択します。このメカニズムはスペキュレーションと呼ばれ、ホストデバイスジョイントコード生成に基づいて BladeDISC に実装されています。さらに、コンパイル時に特定のシェイプ値がない場合、層線形代数の簡素化、フュージョン判断から命令レベルの CSE、定数畳み込みまで、各レベルで多くの最適化機会を失いやすいです。IR とパスパイプラインの設計プロセスで、BladeDISC は IR におけるシェイプ制約の抽象化とパスパイプラインでの使用に重点を置きました。たとえば、コンパイル時に不明な異なる次元サイズの間の制約関係などです。これは全体的なパフォーマンスを最適化する際に明らかに大きな役割を果たし、静的シェイプコンパイラのパフォーマンス結果に十分に近いか、あるいはそれを超越することを保証します。

大きな粒度のオペレーターフュージョン

BladeDISC プロジェクトを開始する前に、チームは静的シェイプコンパイラに基づいて大きな粒度のオペレーターフュージョンと自動コード生成でいくつかの探求を行っていました。基本的な考え方は、共有メモリまたは CPU のメモリアクセスオーバーヘッドが低いメモリキャッシュを使用して、異なるスケジュールの計算サブグラフを同じカーネルにスティッチングし、複数の並列ループの複合化を実現することとして要約できます。このコード生成方法はフュージョンスティッチングと呼ばれます。このメモリ集約型サブグラフの自動コード生成は、従来のループフュージョンと入出力フュージョンのフュージョン粒度に対する制限を打破しました。コード生成の品質を保証しながら、フュージョンの粒度を大幅に増加させ、複雑さとコンパイルオーバーヘッドの爆発を回避しました。そして、プロセス全体はユーザーにとって完全に透明で、スケジュール記述を手動で指定する必要はありません。

動的シェイプセマンティクス下でのフュージョンスティッチングの実装は、静的シェイプセマンティクス下よりも大きな複雑さに対処する必要があります。動的シェイプセマンティクス下のシェイプ制約抽象化はこの複雑さをある程度簡素化し、全体的なパフォーマンスを手動計算の実装に近づけるか、あるいはそれを超越します。

3 複数のフロントエンドフレームワークのサポート

AI コンパイラフレームワークの設計には、異なるフロントエンドフレームワークのサポートを拡張する考慮も含まれます。PyTorch 側は、TorchScript を DHLO IR に変換する軽量なコンバーターを実装し、PyTorch 推論ジョブのカバレッジを達成します。MLIR の比較的完全な IR インフラストラクチャは、コンバーターの実装も容易にします。BladeDISC には、コンパイラと異なるフロントエンドフレームワークに適応する Bridge 側が含まれます。その中で、Bridge はさらに 2 つの部分、つまりホストフレームワーク内のレイヤーパスと、プラグインとしてホストフレームワークに接続されるランタイム Op に分割されます。この作業方法により、BladeDISC はフロントエンドの計算グラフを透過的にサポートし、ユーザーのホストフレームワークのさまざまなバージョンに適応できます。

4 ランタイム環境適応

コンパイル結果を TensorFlow/PyTorch およびその他のホストとそれぞれの動作環境で実行し、IR レイヤーで表現するのが容易ではない状態情報をランタイム時に管理するために、異なるランタイム環境に対して統一されたコンパイラアーキテクチャを実装し、ランタイム抽象化レイヤーである RAL（Runtime Abstraction Layer）レイヤーを導入しました。

RAL はさまざまな動作環境の適応サポートを実装しており、ユーザーはニーズに応じて選択できます。次のものがあります：

全グラフをコンパイルして独立して実行。全計算グラフがコンパイルをサポートする場合、RAL はシンプルなランタイムのセットとその上の RAL ドライバーの実装を提供し、コンパイラのコンパイル結果をフレームワークなしで直接実行できるようにし、フレームワークオーバーヘッドを削減します。

TF 内のサブグラフコンパイルと実行。

PyTorch 内のサブグラフコンパイルと実行。

上記の環境ではリソース管理と API セマンティクスに違いがあります。RAL は最小限の API セットを抽象化し、それらのセマンティクスを明確に定義して、コンパイラとランタイムを分離し、異なる環境でコンパイル結果を実行できるようにします。さらに、RAL レイヤーはステートレスコンパイルを実装しており、計算グラフがコンパイルされた後にコンパイル結果が複数回実行される可能性のある場合の状態情報処理の問題を解決します。一方ではコード生成の複雑さを簡素化し、他方ではマルチスレッド同時実行（推論など）シナリオのサポートを容易にし、エラー処理とロールバックのサポートも容易にします。

第 6 章：アプリケーションシナリオ

BladeDISC の典型的なアプリケーションシナリオは厳密に 2 つのカテゴリに分類できます：1 つは、主流のハードウェアプラットフォーム（Nvidia GPU、x86 CPU など）での汎用的で透明なパフォーマンス最適化ツールとして、ユーザーが AI ジョブをデプロイする際の人的負担を軽減し、モデルのイテレーション効率を向上させることです。もう 1 つの重要なアプリケーションシナリオは、新しいハードウェアが AI シーン適応とアクセスサポートを行うのを支援することです。

現在、BladeDISC は Alibaba Cloud 上で Alibaba の内外のユーザーの多くの異なるアプリケーションシナリオで広く使用されています。カバレッジモデルタイプは NLP、機械翻訳、音声 ASR、音声 TTS、画像検出、認識、AI for Science など、典型的な AI アプリケーションに関わっています。含まれる業界にはインターネット、Eコマース、自動運転、セキュリティ業界、オンラインエンターテイメント、医療・生物などがあります。

推論シナリオでは、BladeDISC と TensorRT などのメーカーが提供する推論最適化ツールは良好な技術的補完性を形成しています。その主な差別化利点には次のものが含まれます：

*動的シェイプビジネスのための完全な動的シェイプセマンティクスサポート
*非標準モデル上のコンパイラに基づく技術パスに基づくモデル汎化のパフォーマンス利点
*プラグインの形でより柔軟なデプロイモード選択、フロントエンドフレームワークの透明性の利点をサポート

新しいハードウェアサポートに関しては、一般的な状況は、比較的深い蓄積を持つ Nvidia などのトップメーカーを除いて、ROCM を含む他の GPGPU ハードウェアが一般的です。ハードウェア指標は既に非常に競争力がありますが、メーカーは AI ソフトウェアスタック上の蓄積に制限されており、ハードウェアコンピューティング能力を十分に活用できないという一般的な問題があり、これがハードウェアアプリケーションの実装を困難にしています。前述のように、コンパイラに基づく技術パスは自然にハードウェアバックエンドに対してある程度の汎化能力を持ち、ハードウェアメーカーの技術的準備と比較的強い補完性を形成します。BladeDISC は現在、GPGPU と汎用 CPU アーキテクチャで比較的成熟した準備を持っています。GPGPU を例にとると、Nvidia GPU 上の技術スタックのほとんどは、Haiguang DCU や AMD GPU などの類似アーキテクチャを持つハードウェアに移行できます。BladeDISC の強力なハードウェア汎化能力とハードウェア自体の強力な汎用性を組み合わせることで、新しいハードウェア適応のパフォーマンスと使いやすさの問題を解決します。

第 7 章：オープンソースエコロジー - ビジョンと未来

私たちがオープンソースエコシステムを構築することを決定した主な理由は、次のような考慮からです：

BladeDISC は Alibaba Cloud コンピューティングプラットフォームチームのビジネスニーズから生まれました。開発プロセスで、MLIR/MHLO/IREE および他のコミュニティの仲間との議論と交流は、私たちに良い入力と参考を提供してくれました。ビジネスニーズのイテレーションと共に徐々に改善していく一方で、コミュニティにオープンソース化することも望んでいます。現在、AI コンパイラ分野のほとんどのプロジェクトは実験的なプロジェクトがほとんどで、より実用的な製品は少なく、異なる技術スタック間の作業は比較的断片化した状況にあります。私たち自身の経験と理解をコミュニティに還元したいと考えています。ディープラーニングコンパイラの開発者と AI システムの実務者とのより多くの、より良い交流と共同構築を行い、この業界に私たちの技術力を貢献したいと考えています。

実際のビジネスシナリオでより多くのユーザーフィードバックを受け取り、継続的な改善とイテレーションを支援し、後続の作業への入力提供を望んでいます。

将来的には、2 か月単位で定期的にリリースバージョンをリリースする予定です。BladeDISC の最近のロードマップは次のとおりです：

*継続的な堅牢性とパフォーマンスの改善
*x86 バックエンドは計算集約型オペレーターのサポートを補完し、エンドツーエンドの完全なオープンソース x86 バックエンドサポート
*GPGPU 上のスティッチングに基づく大きな粒度の自動コード生成
*AMD ROCm GPU バックエンドサポート
*PyTorch トレーニングシナリオのサポート

さらに、中長期的には、次の探求方向に継続的に投資し、さまざまな次元からのフィードバック、改善提案、技術議論を歓迎します。同時に、オープンソースコミュニティ構築に興味のある同僚の参加を歓迎し、共同構築を楽しみにしています。

*より多くの新しいハードウェアアーキテクチャのサポートと適応、および新しいハードウェアアーキテクチャ下でのソフトウェアとハードウェアの協力方法論の沈殿
*動的シェイプセマンティクス下の計算集約型オペレーターの自動コード生成とグローバルレイアウト最適化の探求
*スパースサブグラフの最適化探求
*動的シェイプセマンティクス下のランタイムスケジューリング戦略、メモリ/ビデオメモリ最適化などの探求
*モデル圧縮とコンパイル最適化の組み合わせの技術的探求
*グラフニューラルネットワークなど、より多くの AI ジョブタイプのサポートと最適化