KubeDL が CNCF Sandbox に参加し、AI 業界のクラウドネイティブ化を加速

2021 年 6 月 23 日、Cloud Native Computing Foundation (CNCF) は、グローバル TOC 投票を通じて KubeDL が CNCF Sandbox プロジェクトとして承認されたことを発表しました。 KubeDL は Alibaba のオープンソース Kubernetes ベースの AI ワークロード管理フレームワークであり、「 Kubernetes - Deep -Learning」の略称です。 Alibaba のシナリオに基づいて、大規模な機械学習ジョブのスケジューリングと管理の経験をコミュニティにフィードバックしたいと考えています。

プロジェクトアドレス: http://kubedl.io

プロジェクト紹介

TensorFlow、PyTorch、XGBoostなどの主流AIフレームワークの継続的な成熟と、GPU/TPUに代表されるさまざまなAI異種コンピューティングチップの爆発的な出現により、人工知能は急速に「大規模産業化」の段階に入りつつあります。アルゴリズムエンジニアがニューラルネットワーク構造の最初の層を設計する時点から、実際のアプリケーションシナリオ向けのサービスの最終的な開始に至るまで、AIアルゴリズムの研究開発に加えて、データの収集とクリーニング、分散トレーニングエンジン、リソースのスケジュールとオーケストレーション、モデル管理、推論サービスのチューニング、可観測性など、インフラストラクチャレベルでの多くのシステムサポートも必要です。以下の典型的な図に示すように、多くのシステムコンポーネントのコラボレーションにより、完全な機械学習パイプラインが形成されます。

同時に、Kubernetes に代表されるクラウドネイティブ テクノロジーも急成長しています。優れた抽象化と強力なスケーラビリティにより、アプリケーション層と IaaS (Infrastructure as a Service) 層のインフラストラクチャが完全に分離されます。アプリケーションは、基盤となるインフラストラクチャの複雑さを気にすることなく、「クラウド」パラダイムでオンデマンドでリソースを使用できるため、生産性が向上し、独自の分野でのイノベーションに集中できます。

Kubernetes の登場により、クラウド リソースを効率的に配信する方法という問題は解決されましたが、本質的に非常に複雑な AI などのワークロードに対して、適切なネイティブ サポートを提供することはまだできません。業界では、さまざまなフレームワークの普遍性を維持しながらそれらの違いを統合し、同時に AI ワークロードのランタイムを中心に一連の完全な周辺エコシステムとツールを構築する方法について、依然として絶えず模索と実験が行われています。実際には、Kubernetes エコシステムで AI ワークロードを実行すると、次のような課題に直面することがわかりました。

機械学習フレームワークは数多く存在し、それぞれ最適化の方向性や適用可能なシナリオが異なりますが、分散トレーニングジョブのライフサイクル管理には多くの共通点があり、いくつかの高度な機能（ネットワークモード、イメージコードの分離、メタデータの永続性、キャッシュの高速化など）に対する要求も同じです。演算子は、フレームワーク ロードの種類ごとに個別に実装されます。独立したプロセスは状態を共有できず、グローバルな視点がないため、グローバルなジョブレベルのスケジューリングとキューのメカニズムを実装することが困難になります。さらに、関数の抽象化と再利用には役立たず、コード レベルでの作業の重複が発生します。
ネイティブ Kubernetes は、オフライン タスクの多様なスケジュール要件を満たすことができません。 Kubernetes Pod スケジューリング モデルは、マイクロサービスなどの長時間実行されるワークロードに自然に適しています。ただし、コミュニティでは、オフライン タスクの高スループット、ギャング スケジューリング (All-Or-Nothing)、Elastic Capacity などのさまざまなスケジューリング要件を満たすために、さまざまなスケジューリング ソリューションを開発してきました。機械学習における分散トレーニング ジョブのスケジューリング シナリオで非常に一般的な Gang Scheduling を例にとると、コミュニティには現在、さまざまなインタラクション プロトコルを提供する YuniKorn、Volcano、Coscheduling などのスケジューラ実装があります。対応するスケジューリング プロトコルを有効にするには、プラグイン メソッドが必要です。同時に、ビジネス固有の属性に基づいて異なるロール間の起動依存関係を持つ PS/worker などの DAG オーケストレーション要件をコントローラーに実装する必要があります。
分散トレーニングの結果はモデルとして出力され、Alibaba Cloud OSS/NAS などの分散ファイルシステムに保存されることがよくあります。しかし、業界では、トレーニング ジョブの観点からモデルを管理し、コンテナ イメージなどの AI サービス用の「不変のインフラストラクチャ」を作成し、シンプルで明確なバージョン管理とトレーサビリティを実装する方法に関するベスト プラクティスがまだ不足しています。同時に、「トレーニング」と「推論」の 2 つの段階は比較的独立しています。アルゴリズム科学者の観点から見ると、「トレーニング->モデル->推論」の機械学習パイプラインには不連続性がなく、両者の中間生成物である「モデル」は単に「過去と未来をつなぐ」役割を果たすことができます。
分散トレーニングは素晴らしい効果を発揮しますが、推論サービスの仕様を構成するのは繊細な作業です。ビデオ メモリ、CPU コアの数、BatchSize、スレッドの数などの変数は、推論サービスの品質に影響を与える可能性があります。リソース レベルのみに基づいた容量の見積もりでは、TensorFlow などの一部のエンジンがビデオ メモリを事前に占有するため、ビジネスの実際のリソース要件を反映できません。理論的には、サービス品質とリソース効率の間には最適なバランスポイントがありますが、それは暗闇の中の幽霊のようなものです。存在は分かっていますが、それを理解するのは難しいです。 GPU 仮想化テクノロジが成熟するにつれて、このバランス ポイントの価値はますます顕著になります。仕様が向上すると、単一の GPU カードの展開密度が大幅に向上し、コストを大幅に節約できます。
推論サービス自体は、特別な長期実行マイクロサービス形式です。基本的なデプロイメントに加えて、次のようなさまざまな推論シナリオに対応するインスタンスとトラフィックの管理戦略もいくつか欠けています。

1) アルゴリズム科学者は通常、2 つ以上の異なるバージョンのモデルインスタンスを同時に展開して A/B テストを実行し、最適なサービス効果を検証します。これには、重みに基づいた洗練されたトラフィック制御が必要です。

2) トラフィック要求レベルと現在の推論サービスのメトリクスに基づいてインスタンスのスケーリングを自動的にトリガーし、リソースコストを最小限に抑えながらサービスの可用性を完全に確保します。

キューブDL

上記の課題に対処するため、Alibaba Cloud Native、Cluster Management、PAI の各チームは、大規模な機械学習ワークロードの管理に関する経験を、分散トレーニング、モデル管理、推論サービスなど、機械学習パイプラインのすべての段階をカバーする汎用ランタイム管理フレームワーク KubeDL に統合し、Kubernetes 上でワークロードを効率的に実行できるようにしました。

1. 分散トレーニング

KubeDL は、主流の機械学習分散トレーニング フレームワーク (TensorFlow/PyTorch/MPI/XGBoost/Mars など) をサポートしています。 Mars は、Alibaba のコンピューティング プラットフォームのオープンソースのテンソルベースの大規模データ コンピューティング フレームワークです。これにより、numpy や pandas などのデータ処理フレームワークの効率を分散的に加速し、Mars ジョブをクラウドネイティブのビッグデータ エコシステムに、よりネイティブな方法で統合できるようになります。

さまざまなトレーニング ジョブのライフサイクル管理の共通部分をユニバーサル ランタイム ライブラリに抽象化し、さまざまな分散トレーニング ジョブ コントローラーで再利用します。同時に、ユーザーはカスタマイズされたワークロード コントローラーを迅速に拡張し、これに基づいて既存の機能を再利用することもできます。宣言型 API と Kubernetes ネットワーク/ストレージ モデルの助けを借りて、KubeDL はコンピューティング リソースの申請/回収、ジョブ ロール間のサービス検出と通信、実行時のフェイルオーバーなどを行うことができます。アルゴリズム モデルの開発者は、トレーニングが依存するジョブ ロールとそれぞれのレプリカ数、コンピューティング リソース/異種リソースの数などを宣言し、タスクを送信するだけで済みます。さらに、トレーニングの効率と体験を向上させるために、トレーニング現場の問題点に対処するための多くの機能も設計しました。

トレーニング フレームワークによって、TensorFlow の PS/Chief/Worker や PyTorch の Master/Worker など、職務が異なる場合があります。多くの場合、ロール間には暗黙的な依存関係が存在します。たとえば、ワーカーはマスターが起動した後にのみ正常に計算を開始できます。起動順序が乱れていると、リソースが長時間アイドル状態になるだけでなく、ジョブが直接失敗する可能性もあります。 KubeDL は、DAG (Direct Acyclic Graph) に基づくスケジューリングおよびオーケストレーション制御フローを設計しており、ロール間の起動依存関係の順序を効果的に解決し、柔軟に拡張できます。
大規模モデルのトレーニング時間は、多くの場合、コンピューティング ノード間の通信効率によって制限されます。 RDMA などの高性能ネットワーク テクノロジを適用すると、データ転送速度が大幅に向上しますが、これらのカスタマイズされたネットワークでは、コンピューティング ノードがホストネットワークを使用して相互に通信する必要があることがよくあります。同時に、環境の制限により、サービス モデルに基づくサービス検出メカニズムを提供できない場合もあります。これには、ジョブ管理エンジンがホスト ネットワーク モードでのサービス検出メカニズムをサポートし、各コンピューティング ノードのネットワーク ポート割り当てを処理し、各トレーニング フレームワークの特性と組み合わせて、ノードのフェイルオーバー後のネットワーク接続を処理する必要があります。 KubeDL は、ホスト ネットワーク モードでの高性能分散トレーニングをサポートします。
ギャング スケジューリングは、分散トレーニング ジョブ スケジューリング シナリオで一般的な要件です。単一のトレーニング ジョブを構成するポッドのクラスターは、クラスターの容量が不足しているときにジョブ間のリソース競合によるライブロックを回避するために、同時にスケジュールする必要があることがよくあります。ただし、Kubernetes の強力なスケーラビリティにより、さまざまなスケジューラが YuniKorn、KubeBatch などのさまざまな Gang Scheduling プロトコルを実装することもできます。特定のスケジューラ実装との結合を回避し、さまざまなユーザー環境の違いに適応するために、KubeDL は Gang Scheduling プロトコルをプラグインにしました。対応するプラグインをオンデマンドで有効にすることで、スケジューラと連携してジョブのバッチ スケジューリングを実現できます。
ジョブは 1 回限りですが、実際の運用アプリケーションでは、毎日一定の時間間隔でオフライン テーブルをプルし、データのクリーニングとモデルの再トレーニングを実行するなど、繰り返しのトレーニング/スケジュールされたトレーニングのシナリオに遭遇することがよくあります。 KubeDL は、スケジュールされたトレーニング要求を処理するための別のタイプのワークロード (Cron) を提供し、あらゆるタイプのトレーニング ジョブ (TFJob、PyTorchJob など) をサポートします。ユーザーは、cron タブ形式のスケジュールされたコマンドとジョブ テンプレートを送信し、Cron リソースのステータスでトレーニング ジョブと現在進行中のジョブの履歴を追跡できます。
大量のオフラインジョブメタデータを長期保存する要求（ジョブ CRD が削除されるとメタデータは etcd から破棄されます）に応えて、KubeDL にはメタデータの永続性も組み込まれており、ジョブ/ポッド/イベントなどのリソースオブジェクトの変更をリアルタイムで監視し、対応するデータベーススキーマオブジェクトに変換して、ストレージバックエンドに永続化します。ストレージ バックエンドもプラグインとして設計されています。ユーザーは、独自のオンライン環境に基づいてストレージ プラグインを実装し、展開時に有効にすることができます。 KubeDL では、Job/Pod はデフォルトで MySQL ストレージ プロトコルをサポートし、Alibaba Cloud SLS サービスにイベントを収集します。

同時に、管理および制御スイートである KubeDL-Dashboard も提供しています。ユーザーは、Kubernetes の多数の API を理解したり、さまざまな kubectl コマンドに苦労したりする必要はありません。インターフェースを通じて、シンプルで使いやすい機械学習タスクを開始できます。永続的なメタデータはダッシュボードで直接使用することもできます。ダッシュボードは、シンプルなジョブの送信、ジョブの管理、イベント/ログの表示、クラスター リソースの表示などの機能を提供し、機械学習ユーザーが非常に低い学習しきい値で実験を開始できるようにします。

2. 推論サービス仕様のチューニング

GPU 仮想化とタイムシェアリング多重化テクノロジの開発と成熟により、単一の GPU で複数の推論サービスを同時に実行できるようになり、コストが大幅に削減されました。しかし、推論サービス、特に非圧縮ビデオメモリリソースに適切な GPU リソース仕様を選択する方法が重要な問題になります。一方、頻繁なモデルの反復により、アルゴリズム エンジニアは各モデルのリソース要件を正確に見積もる時間がなくなります。トラフィックの動的な変化により、リソースの評価も不正確になります。そのため、GPU リソースの冗長性をさらに構成する傾向があり、安定性と効率性のどちらかが犠牲になり、無駄が多く発生します。一方、Tensorflow などの機械学習フレームワークはアイドル状態のビデオメモリをすべて占有する傾向があるため、クラスター管理者の観点から、ビデオメモリの過去の使用状況に基づいて推論ビジネスのリソース要件を推定することも非常に不正確です。 KubeDL-Morphling コンポーネントでは、推論サービスの自動仕様チューニングを実装しました。アクティブなストレス テストを通じて、さまざまなリソース構成でのサービスのパフォーマンス プロファイリングを実行し、最終的に最も適切なコンテナー仕様を推奨します。プロファイリング プロセスは非常にインテリジェントです。仕様ポイントの徹底的なサンプリングを回避するために、プロファイリング サンプリング アルゴリズムの内部コア ドライバーとしてベイズ最適化を使用します。フィッティング関数を継続的に改良することで、低いサンプリング レート (<20%) のストレス テスト オーバーヘッドで、ほぼ最適なコンテナー仕様の推奨結果を提供します。

3. モデル管理および推論サービス

モデルはトレーニングの成果であり、コンピューティングとアルゴリズムの組み合わせの凝縮されたエッセンスです。モデルを収集して維持する通常の方法は、クラウド ストレージにモデルをホストし、ファイル システムを整理して統合管理を実現することです。この管理方法は、厳密なプロセス仕様と権限制御に依存しており、システムレベルからのモデル管理の不変性は実現されません。コンテナ イメージの誕生により、RootFS の構築、配布、不変性の問題が解決されました。 KubeDL はこれら 2 つを組み合わせて、イメージベースのモデル管理を実現します。トレーニングが正常に完了すると、ジョブ仕様で指定された ModelVersion によってモデルイメージの構築が自動的にトリガーされます。ユーザーは、ModelVersion.Spec 内のモデルのストレージ パス、ターゲット ミラー レジストリ、その他の基本情報について合意し、各トレーニング出力を対応するミラー リポジトリにプッシュできます。

同時に、イメージはトレーニングの出力と推論サービスの入力として機能し、2 つの段階をうまく接続し、分散トレーニング -> モデルの構築と管理 -> 推論サービスの展開という完全な機械学習パイプラインを実現します。 KubeDL は、推論サービスのデプロイメントとランタイム制御を提供する推論リソース オブジェクトを提供します。完全な推論サービスは、単一または複数の予測子で構成できます。各予測子は、前回のトレーニングによるモデル出力に対応します。モデルは自動的にプルされ、メイン コンテナー ボリュームにマウントされます。異なるモデル バージョンを持つ複数の予測子が共存する場合、割り当てられた重みに従ってトラフィックを分散および制御し、A/B テスト制御実験効果を実現できます。今後は、推論サービス シナリオのバッチ処理、バッチ推論、および AutoScale についてもさらに調査を進めていきます。

パブリッククラウドでの KubeDL 分散トレーニングの実践

PAI-DLC

クラウドコンピューティングが普及し、クラウドネイティブな方法で行われるビジネスが増える中、Alibaba Cloud Computing Platform の PAI 機械学習チームは、ディープラーニング プラットフォーム製品である DLC (Deep Learning Cloud) をリリースしました。 DLC は、Kubernetes を基盤リソース ベース サポートとして採用した新しいクラウド ネイティブ アーキテクチャを採用し、トレーニング部分は KubeDL によって完全に管理されます。これは、ディープラーニング クラウド コンピューティング シナリオにおける KubeDL の大規模な実践です。

DLC は、タオバオ セキュリティ部門や DAMO アカデミーの画像やビデオ、自然言語、音声、マルチモーダル理解、自動運転など、多くの事業部門のディープラーニング コンピューティング ニーズを含む、アリババ グループ内の多数の事業を幅広くサポートしています。 PAIチームは、ディープラーニングを駆使した最先端のビジネスプロダクションにサービスを提供する中で、フレームワークとプラットフォームの構築において多くの経験を積み、兆スケールのパラメータを持つM6モデルのトレーニング、産業グレードのグラフニューラルネットワークシステムGraph-Learn、極限のリソース管理と再利用機能など、コミュニティ（TensorFlow / PyTorchなど）と互換性があり、大規模な業界の実践で実践された際立った特徴を持つフレームワークとプラットフォーム機能を蓄積してきました。

現在、PAI-DLC の機能はパブリック クラウドも完全に取り入れており、開発者や企業にクラウド ネイティブのワンストップ ディープラーニング トレーニング プラットフォーム、柔軟で安定した、使いやすく高性能な機械学習トレーニング環境を提供しています。また、複数のコミュニティと PAI ディープ最適化アルゴリズム フレームワークを完全にサポートし、超大規模分散ディープラーニング タスクの高性能で安定した操作を実現し、開発者や企業のコストを削減し、効率を高めています。

パブリッククラウドのDLCは、アリババグループの機械学習プラットフォームのベストプラクティスの現れとして、製品の詳細、フレームワークの最適化、プラットフォームサービスなどの面でエンジニアリングの実践から貴重な経験を吸収してきました。さらに、DLC製品は設計当初からパブリッククラウドシナリオの独自の属性を十分に考慮し、入札インスタンス、自動フェイルオーバー、弾性スケーリングなどの機能を提供し、顧客のAIコンピューティングコストの削減に努めています。

さらに、DLC は、アルゴリズム エンジニアによるモデリング用の DSW、エンタープライズ AI プロセス全体向けの自動化された AutoML、オンライン推論サービスである EAS など、PAI の他のパブリック クラウド製品とも組み合わせられ、プロセス全体のベンチマーク AI 製品が作成されます。