AlibabaのBladeDISCディープラーニングコンパイラが正式にオープンソース化

ガイド

ディープラーニングの継続的な発展により、AI モデルの構造は急速に進化しており、基盤となるコンピューティングハードウェアテクノロジが次々と登場しています。大多数の開発者は、複雑で変化するシナリオでコンピューティングパワーを効果的に発揮する方法を考えるだけでなく、コンピューティングフレームワークの継続的な反復にも対処する必要があります。ディープコンパイラは、上記の問題に対処するための広く議論されている技術的方向性となり、ユーザーが上位レベルのモデル開発のみに集中できるようにし、手動によるパフォーマンス最適化の人的開発コストを削減し、ハードウェアパフォーマンススペースをさらに圧迫します。 Alibaba Cloud Machine Learning PAI は、業界でいち早く実際のビジネスアプリケーションに導入された動的シェイプディープラーニングコンパイラーである BladeDISC をオープンソース化しました。この記事では、BladeDISC の設計原理とアプリケーションについて詳しく説明します。

2. BladeDISCとは

BladeDISC は、Alibaba の最新のオープンソース MLIR ベースの動的形状ディープラーニングコンパイラです。

1 主な特徴

複数のフロントエンドフレームワークをサポート: TensorFlow、PyTorch
複数のバックエンドハードウェアのサポート: CUDA、ROCM、x86
動的形状セマンティックコンパイルの完全サポート
推論とトレーニングをサポート
軽量API、ユニバーサル、ユーザーにとって透過的
ホストフレームワークに埋め込まれたプラグインモードと独立したデプロイメントモードをサポート

ディープラーニングコンパイラの背景

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

1 AIとチップの波が共存する - 初期の芽生えから急成長まで

近年、ディープラーニングコンパイラが継続的に注目を集めている理由は、主に以下の理由によるものです。

モデルの一般化に関するフレームワークのパフォーマンス最適化要件

ディープラーニングは今も急速に発展しており、革新的な応用分野が次々と登場しています。複雑で絶えず変化するシナリオでハードウェアの計算能力をいかに効果的に活用するかが、AI アプリケーションチェーン全体の非常に重要な部分となっています。初期のニューラルネットワークの導入では、フレームワークと演算子ライブラリに重点が置かれており、これらは主にディープラーニングフレームワーク、ハードウェアベンダーが提供する演算子ライブラリ、ビジネスチームによる手動の最適化作業によって行われていました。

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

AIフレームワークのハードウェア一般化の要件

表面的には、近年の AI の発展は誰の目にも明らかで活況を呈していますが、その背景にある数十年にわたるハードウェアコンピューティング能力の発展こそが、AI の繁栄の核心的な原動力となっています。トランジスタの小型化に伴う物理的な課題がますます大きくなり、チップの計算能力を高めることがますます困難になり、ムーアの法則は破綻に直面しています。革新的なアーキテクチャを備えたさまざまなDSAチップが人気の波を迎え、従来のx86、ARMなどがさまざまな分野で競争力を強化しています。ハードウェアの繁栄は、AI フレームワークの開発にも新たな課題をもたらしました。

ハードウェアのイノベーションは 1 つの問題であり、実際のビジネスシナリオでハードウェアの計算能力をどのように引き出すかは別の問題です。新しい AI ハードウェアメーカーは、ハードウェアの革新だけでなく、ソフトウェアスタックに多額の人的投資を行うという問題にも直面する必要があります。ハードウェアとの下位互換性をどのように実現するかは、今日のディープラーニングフレームワークの中心的な難しさの 1 つになっており、ハードウェアの互換性はコンパイラによって解決する必要があります。

フロントエンドAIフレームワークの一般化のためのAIシステムプラットフォームの要件

現在主流のディープラーニングフレームワークには、Tensoflow、Pytorch、Keras、JAXなどがあります。各フレームワークにはそれぞれ長所と短所があり、上位レベルのユーザーインターフェースのスタイルも異なりますが、いずれもハードウェアの適応とハードウェアの計算能力を十分に活用するという問題に直面しています。多くの場合、さまざまなチームが独自のモデリングシナリオと使用習慣に基づいてさまざまなフレームワークを選択しますが、クラウドベンダーやプラットフォームプロバイダーのパフォーマンス最適化ツールとハードウェア適応ソリューションでは、さまざまなフロントエンドフレームワーク、さらには将来のフレームワーク進化のニーズも考慮する必要があります。 GoogleはXLAを使用してTensorFlowとJAXの両方をサポートしています。同時に、他のオープンソースコミュニティもTorch_XLAやTorch-MLIRなどのアクセスソリューションを開発しました。これらのアクセスソリューションは、使いやすさと成熟度の点でまだいくつかの問題がありますが、フロントエンドAIフレームワークの一般化に対するAIシステム層のニーズと技術動向を反映しています。

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

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

従来のコンパイラの使命の 1 つは、プログラマーの負担を軽減することです。コンパイラへの入力として使用される高級言語は、多くの場合、ロジックを記述します。プログラマーの利便性のため、高級言語の記述はより抽象的かつ柔軟になります。このロジックがマシン上で効率的に実行できるかどうかは、コンパイラをテストするための重要な指標となることがよくあります。ディープラーニングは近年急速に発展している応用分野であり、そのパフォーマンスの最適化は極めて重要です。また、高レベル記述の柔軟性と抽象性と、基盤となるコンピューティングパフォーマンスの間には矛盾があります。そのため、ディープラーニング専用のコンパイラが登場しています。従来のコンパイラのもう 1 つの重要な使命は、プログラマーが入力した高水準言語を、さまざまなアーキテクチャと命令セットを備えたハードウェアコンピューティングユニットで実行できるようにすることです。これは、ディープラーニングコンパイラにも反映されています。新しいハードウェアデバイスに直面したとき、人間がフレームワークで必要とされるすべての演算子実装を、多数のターゲットハードウェア用に書き直すエネルギーを持っているとは考えにくいです。ディープラーニングコンパイラは、中間層 IR を提供し、最上位フレームワークのモデルフローグラフを中間層表現 IR に変換し、中間層 IR で一般的なレイヤー最適化を実行し、バックエンドで最適化された IR から各ターゲットプラットフォームのマシンコードを汎用的に生成します。

ディープラーニングコンパイラの目標は、一般的なコンパイラと同じように、AI コンピューティングタスクのパフォーマンス最適化とハードウェア適応を完了することです。これにより、ユーザーは上位レベルのモデル開発に集中できるようになり、手動によるパフォーマンス最適化の人的開発コストが削減され、ハードウェアのパフォーマンス空間がさらに圧迫されます。

大規模アプリケーションにおける3つのボトルネック

ディープラーニングコンパイラは、目標や技術アーキテクチャの面で従来のコンパイラと多くの類似点があり、技術面でも優れた可能性を示していますが、現在の実用範囲は従来のコンパイラに比べてまだはるかに遅れています。主な問題点は次のとおりです。

使いやすさ

ディープラーニングコンパイラの本来の目的は、手動でパフォーマンスを最適化し、ハードウェアを適応させる労働コストを簡素化することでした。しかし、現段階では、ディープラーニングコンパイラの大規模な展開と応用の課題は依然として大きく、コンパイラを使いこなすためのハードルは高い。この現象の主な理由は次のとおりです。

フロントエンドフレームワークとのドッキングに関する問題。異なるフレームワークは、ディープラーニングタスクに対する抽象記述や API インターフェースが異なり、セマンティクスやメカニズムにも独自の特徴を持っています。また、コンパイラ入力となるフロントエンドフレームワークの演算子の種類の数はオープンです。すべての演算子が完全にサポートされていることを保証せずに、ユーザーの計算グラフ記述を透過的にサポートする方法は、ディープラーニングコンパイラーをユーザーが簡単に広く使用できるようにする重要な要素の 1 つです。

動的形状問題と動的計算グラフ問題。現在、主流のディープラーニングコンパイラは、主に特定の静的形状入力のコンパイルを完了します。さらに、制御フローセマンティクスを含む動的計算グラフのサポートは限定的であるか、まったくサポートされていません。ただし、AI アプリケーションのシナリオでは、このタイプのタスクが大量に必要になります。現時点では、計算グラフを手動で静的または半静的計算グラフに書き換えるか、コンパイラに適したいくつかのサブグラフを抽出してコンパイラに渡す方法を見つけることしかできません。これにより、ディープラーニングコンパイラを適用する際のエンジニアリングの負担が間違いなく増加します。さらに深刻な問題は、多くのタスクタイプは手動での書き換えによって静的に変更することができず、このような場合にはコンパイラがまったく実用的でないことです。

コンパイルのオーバーヘッドの問題。パフォーマンス最適化ツールとしてのディープラーニングコンパイラは、コンパイルのオーバーヘッドと比較して、それがもたらすパフォーマンスの向上が十分に有利である場合にのみ、真に役立ちます。一部のアプリケーションシナリオでは、コンパイルオーバーヘッドの要件が高くなります。たとえば、完了までに数日かかる通常規模のトレーニングタスクでは、数時間のコンパイルオーバーヘッドを許容できない場合があります。アプリケーションエンジニアにとって、コンパイラを使用するとモデルを迅速にデバッグすることができず、開発と展開の難易度と負担が増加します。

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

堅牢性

現在、主流の AI コンパイラプロジェクトのほとんどはまだ実験的な製品ですが、製品の成熟度は産業グレードのアプリケーションにはほど遠いです。ここでの堅牢性には、入力計算グラフのコンパイルがスムーズに完了できるかどうか、計算結果の正確性、およびパフォーマンスの観点からコアケースでの極端に悪いケースの回避が含まれます。

パフォーマンスの問題

コンパイラ最適化とは、本質的には、手動の最適化方法、または人間が探索するのが難しい最適化方法を一般化および抽象化して、手動の最適化の労働コストを限られたコンパイルオーバーヘッドに置き換えるプロセスです。しかし、方法論をどのように沈殿させ抽象化するかが、チェーン全体の中で最も本質的かつ難しい問題です。ディープラーニングコンパイラーは、パフォーマンスの面で手動による最適化を実際に置き換えるかそれを上回ることができる場合、または人件費を実際に大幅に削減できる場合にのみ、その価値を真に実現できます。

しかし、この目標を達成するのは簡単ではありません。ディープラーニングのタスクは主にテンソルレベルの計算であり、並列タスクの分割方法に高い要求が課せられます。しかし、コンパイルオーバーヘッドの爆発的な増加や階層化後の異なるレベル間の最適化のリンクを回避するために手動の最適化を一般化してコンパイラー技術に組み込む方法など、調査および調査する必要がある未知の点はまだ多くあります。これは、MLIR フレームワークに代表される次世代のディープラーニングコンパイラーが注力して解決する必要がある問題にもなっています。

4. BladeDISCの主な技術的特徴

プロジェクトを立ち上げた当初の目的は、XLA と TVM の現在のバージョンの静的シェイプの制限を解決することでした。社内では DISC (DynamIc Shape Compiler) と名付けられ、動的シェイプセマンティクスを完全にサポートし、実際のビジネスで使用できるディープラーニングコンパイラを作成することを目指していました。

チームが4年前にディープラーニングコンパイラーの開発に着手して以来、動的形状問題は実際のビジネス実装を妨げる深刻な課題の1つとなっていました。当時、XLA を含む主流のディープラーニングフレームワークは、静的シェイプセマンティクスに基づくコンパイラフレームワークでした。一般的な解決策としては、ユーザーに入力形状の指定を要求するか、コンパイラーが実行時にコンパイルするサブグラフの実際の入力形状の組み合わせをキャプチャし、各入力形状の組み合わせに対してコンパイル結果を生成することが挙げられます。

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

コンパイルのオーバーヘッドが大幅に増加します。オフラインコンパイルウォームアッププロセスの導入により、推論タスク展開プロセスの複雑さが大幅に増加し、トレーニング反復速度が不安定になり、全体的なトレーニング時間も最適化されなくなります。
一部のビジネスシナリオでは、形状変更の範囲が無限になる傾向があり、その結果、コンパイルキャッシュが収束できず、ソリューションが利用できなくなります。
ビデオメモリのメモリ使用量が増加します。コンパイルキャッシュによって占有される余分なメモリとビデオメモリは、実際の展開環境でメモリ/ビデオメモリの OOM につながることが多く、実際の業務の実装を直接妨げます。
静的な図形の手動パディングなどの緩和ソリューションはユーザーフレンドリーではなく、アプリケーションの汎用性と透明性が大幅に低下し、反復効率に影響を及ぼします。

DISCは2020年夏、TensorFlowフロントエンドとNvidia GPUバックエンドのみをサポートする最初のバージョンを完成させ、アリババ社内で正式に実用化されました。長年、動的形状の問題に悩まされてきたいくつかのビジネスシナリオで初めて活用され、期待通りの成果が得られました。つまり、ユーザーが計算グラフ上で特別な処理を行う必要がなく、1 回のコンパイルで動的シェイプセマンティクスが完全にサポートされ、パフォーマンスは静的シェイプコンパイラとほぼ同等になります。主に手動演算子ライブラリに基づく TensorRT などの最適化フレームワークと比較して、コンパイラ自動コード生成に基づく DISC の技術アーキテクチャは、非標準のオープンソースモデルを頻繁に使用する実際のビジネスにおいて、明らかなパフォーマンスと使いやすさの利点を実現しています。

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

5つの主要技術

BladeDISC の全体的なアーキテクチャと Alibaba Cloud 関連製品におけるコンテキスト関係を次の図に示します。

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

MLIR は、2019 年に Google が開始したプロジェクトです。MLIR の中核は、柔軟なマルチレイヤー IR インフラストラクチャとコンパイラユーティリティライブラリであり、LLVM の影響を強く受け、その優れたアイデアの多くを再利用しています。ここで MLIR を選択する主な理由としては、比較的豊富なインフラストラクチャサポート、拡張しやすいモジュール設計アーキテクチャ、MLIR の強力な接着機能などが挙げられます。

2 ダイナミックシェイプのコンパイル

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

レイヤーIR設計

BladeDISC は、さまざまなフロントエンドフレームワークにアクセスするためのコアレイヤー IR として HLO を選択しますが、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プロジェクトを開始する前に、チームは、静的シェイプコンパイラ[3][4]に基づく大規模な演算子の融合と自動コード生成についていくつかの調査を行っていました。基本的な考え方は、GPUハードウェアのメモリアクセスオーバーヘッドの低い共有メモリ、またはCPUのメモリアクセスオーバーヘッドの低いメモリキャッシュの助けを借りて、異なるスケジュールの計算サブグラフを同じカーネルにステッチし、複数の並列ループの組み合わせを実現することです。このコード生成方法は、フュージョンステッチングと呼ばれます。メモリを大量に消費するサブグラフのこの自動コード生成により、従来のループ融合と入出力融合の融合粒度に関する制限が打ち破られます。コード生成の品質を確保しながら、融合の粒度が大幅に向上し、複雑さとコンパイルのオーバーヘッドの急増を回避します。プロセス全体はユーザーに対して完全に透過的であり、スケジュールの説明を手動で指定する必要はありません。

動的シェイプセマンティクスでフュージョンステッチングを実装するには、静的シェイプセマンティクスで実装する場合よりも複雑な処理が必要になります。動的シェイプセマンティクスでシェイプ制約を抽象化すると、この複雑さがある程度簡素化され、全体的なパフォーマンスが手動のオペレーター実装に近づくか、またはそれよりも優れたものになります。

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

AICompiler フレームワークは、さまざまなフロントエンドフレームワークの拡張サポートも念頭に置いて設計されました。 PyTorch 側では、PyTorch 推論ジョブをカバーするために TorchScript を DHLO IR に変換する軽量の Converter が実装されています。 MLIR の比較的完全な IR インフラストラクチャにより、Converter の実装も容易になります。 BladeDISC は、コンパイラと、さまざまなフロントエンドフレームワークに適応するブリッジ側の 2 つの部分で構成されています。ブリッジはさらに、ホストフレームワーク内のレイヤーパスと、プラグインとしてホストフレームワークに接続されるランタイム Op の 2 つの部分に分かれています。この動作モードにより、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 社内および Alibaba Cloud の外部ユーザーによって、さまざまなアプリケーションシナリオで広く使用されています。対象となるモデルの種類には、NLP、機械翻訳、音声 ASR、音声 TTS、画像検出、認識、科学向け AI など、多くの一般的な AI アプリケーションが含まれます。対象となる業界には、インターネット、電子商取引、自動運転、セキュリティ業界、オンラインエンターテイメント、医療および生物学などがあります。

推論シナリオでは、BladeDISC は TensorRT などのベンダーが提供する推論最適化ツールを技術的に補完する優れたツールです。主な差別化された利点は次のとおりです。

動的形状ビジネスのための完全な動的形状セマンティックサポート
非標準モデルにおけるコンパイラベースのテクノロジパスに基づくモデル一般化のパフォーマンス上の利点
より柔軟な展開モードの選択、プラグインの形でフロントエンドフレームワークの透明性の利点をサポート

次の図は、Nvidia T4 ハードウェア上でのいくつかの実際のビジネス例のパフォーマンス向上の数値を示しています。

新しいハードウェアのサポートに関して、現時点での一般的な状況は、比較的蓄積の深いNvidiaなどの大手メーカーを除き、ROCMを含む他のGPGPUハードウェアの一般的な状況は、ハードウェア指標がすでにかなり競争力があるものの、メーカーはAIソフトウェアスタックの蓄積が比較的少ないという制約を受けており、ハードウェアの計算能力を発揮できず、ハードウェアアプリケーションの実装が困難になるという一般的な問題があります。前述のように、コンパイラベースのテクノロジパスは、当然のことながら、ハードウェアバックエンドに対して一定の一般化機能を備えており、ハードウェアメーカーの技術的備蓄を強力に補完します。 BladeDISC の現在の GPGPU および汎用 CPU アーキテクチャの蓄積は比較的成熟しています。 GPGPU を例にとると、Nvidia GPU 上のテクノロジスタックのほとんどは、Hygon DCU や AMD GPU などの同様のアーキテクチャを持つハードウェアに移行できます。 BladeDISC の強力なハードウェア汎用化機能とハードウェア自体の強力な汎用性を組み合わせることで、新しいハードウェアの適応におけるパフォーマンスと可用性の問題を効果的に解決します。

次の図は、Haiguang DCU におけるいくつかの実際のビジネス例のパフォーマンス数値を示しています。

認識モデル	推論	異なるバッチサイズで2.21倍～2.31倍
検出モデル	推論	異なるバッチサイズで1.73倍～2.1倍
検出モデルB	推論	異なるバッチサイズで1.04倍～1.59倍
分子動力学モデル	電車	2.0倍

7つのオープンソースエコシステム - ビジョンと未来

私たちがオープンソースエコシステムを構築することに決めたのは、主に次の理由からです。

BladeDISC は、Alibaba Cloud Computing Platform チームのビジネスニーズから生まれました。開発プロセスでは、MLIR/MHLO/IREE コミュニティの仲間とのディスカッションや交流を通じて、有益な情報や参考資料が得られました。ビジネスニーズの反復で徐々に改善するにつれて、現在、AIコンパイラフィールド全体に実験プロジェクトがあります。この業界。
オープンソースの作業を通じて、実際のビジネスシナリオでより多くのユーザーフィードバックを受け取り、改善と反復を継続し、その後の作業投資の方向への入力を提供したいと考えています。

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

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

さらに、中期的には、次の探索的方向性にエネルギーを投資し続けます。

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

オープンソースアドレス:

https://github.com/alibaba/bladedisc

参考文献

「ディスク：機械学習ワークロード用のダイナミックシェイプコンパイラ」、Kai Zhu、Wenyi Zhao、Zhen Zheng、Tianyou Guo、Pengzhan Zhao、Feiwen Zhu、Junjie Bai、Jun Yang、Xiaoyong Liu、Lansong Diao、Wei Lin Lin Lin Lin
MLIR Developers 'Weekly Conferenceに関するプレゼンテーション：1、2
「Astitch：メモリ集約的なMLトレーニングと現代のSIMTアーキテクチャの推論のための新しい多次元最適化スペースを可能にします」、Zhen Zheng、Xuanda Yang、Pengzhan Zhao、Guoping Long、Kai Zhu、Feiwen Zhu、Wenyi Zhaiプログラミング言語とオペレーティングシステムの建築サポートに関するACM国際会議（ASPLOS）、2022。[表示する]
「フュージョンスタッチ：深い学習ワークロードのメモリ集中的な計算をブースト」、Zhen Zheng、Pengzhan Zhao、Guoping Long、Feiwen Zhu、Kai Zhu、Wenyi Zhao、Lansong Diao、Jun Yang、およびWei Arxiv Preprint

<<: 自動運転車は生後7か月の赤ちゃんよりも賢いのでしょうか?

>>: アルゴリズム | ダブルポインタはリンクリストを破る優れた魔法の武器です