クラウドストレージ用の分散アクセラレータとは何ですか? (プレビュー)

クラウド ストレージ用分散アクセラレータ (DACS) は、Azure Blob Storage からのモデル読み込みを加速する、Azure Kubernetes Service (AKS) 上の AI 推論向けの分散型リードスルー キャッシュです。 複数のキャッシュノードにまたがるローカル NVMe ディスクを使用し、頻繁に読み込まれるデータを GPU の計算リソースの近くに保ちます。 DACSは、同じデータを繰り返し読み取るトレーニングワークロードのデータセットロードを加速させることも可能です。 Azure Blob Storage は、モデル ファイルやデータセットの耐久性が高く信頼できる正本として引き続き機能します。

DACS を Azure コンテナー ストレージを通じて有効にし、管理します。このツールは DACS 管理拡張機能をインストールし、AKS 上でそのライフサイクルを管理します。 DACSは永続ボリュームでもStorageClassでも、Azure Blob Storageの代替でもありません。 Kubernetes 永続ボリュームを作成するには、Azure コンテナー ストレージとは何ですか?をご覧ください。

Important

DACSはプレビュー段階です。 プレビュー機能は、サービス レベル アグリーメントなしで提供され、運用環境のワークロードには推奨されません。 一部の機能は制限されたりサポートされていない場合があります。 詳細については、「 Microsoft Azure プレビューの追加使用条件」を参照してください。

クラウドストレージに分散アクセラレータを使うべきタイミング

DACSは、同じモデルデータをAzure Blob Storageから繰り返し読み込む読み込み集約型のAI推論ワークロード向けに設計されています。 作業負荷が以下のいずれかの特徴を持つ場合、DACSを検討してください:

  • 推論ポッドは、リクエストを処理する前に大規模なモデルファイルの準備が整うのを待ちます。
  • GPUノードを追加すると、モデルデータのダウンロードが繰り返されます。
  • ポッドの再起動、ノードの置換、またはローリングアップグレードは同じモデルデータを繰り返し取得します。
  • 複数の推論ワークロードは、Azure Blob Storage に保存されたモデル ファイルのワーキング セットを再利用します。
  • AKSクラスターにはLinuxノードプールがあり、ローカルのNVMeディスクをキャッシュサーバー専用にできます。

トレーニングには、ワーカーがエポックやジョブをまたいでデータセットの一部を再利用する場合は、DACSを検討してください。 キャッシュの利点は、データの再利用、ワーキングセットのサイズ、そして読み込みがコールドキャッシュかウォームキャッシュに遭遇するかに依存します。

DACSは最大100ノードのクラスタをサポートしています。 トレーニング出力やチェックポイントのための永続的な保存は提供しません。 KVキャッシュ、コンテナイメージキャッシュ、汎用共有ファイルアクセス、非Azure Blobオリジンはこのプレビューには含まれていません。

クラウドストレージ向け分散アクセラレータの仕組み

DACS はクラスタ ローカルの NVMe キャッシュ層を追加し、ワークロードがサポートされているクライアント統合を通じてアクセスできるようにします。 クライアントはキャッシュミス時やフォールバック時にAzure Blob Storageを直接読み取ることができます。

AKSワークロードクライアントが分散したNVMeサーバーからのキャッシュヒットを読み取り、キャッシュミスやフォールバック時にBlob Storageを読み込み、キャッシュに格納するアーキテクチャ図。別のマネージドコントローラがキャッシュリソースを照合します。

読み取りパス

  1. アプリケーションは、サポートされたDACS統合を通じてモデル・データ範囲を要求します。
  2. クライアントはキャッシュサーバーを発見し、どのサーバーが要求されたチャンクを所有しているかを判定します。
  3. キャッシュヒット時、クライアントはそのチャンクを所有するキャッシュサーバーのNVMeからチャンクを読み込みます。
  4. キャッシュミス時には、クライアントがAzure Blob Storageからチャンクを読み取り、非同期的にキャッシュを埋めます。 リードはデータの投入が完了する前に完了することがあるため、即時の繰り返しリードでも失敗することがあります。
  5. キャッシュが利用できない場合、クライアントはAzure Blob Storageにフォールバックします。

モデルデータはチャンクに分割され、キャッシュサーバーに分散されます。 コンシステントハッシュリングは、中央集権的なデータパスに依存せずにチャンクをサーバーにマッピングします。 キャッシュサーバーは、選択したAzure仮想マシン(VM)のサイズやクラスタトポロジーに応じて、イーサネットまたはInfiniBand経由でデータ転送が可能です。

マネージド デプロイ

distributedAccelerator 値を指定して Azure CLI を使用し、Azure Container Storage を介して DACS を有効にします。 このステップで、別個の distributedaccelerator 管理拡張をインストールします。 この拡張機能はkube-system にDACSコントローラとNVMeの前提条件DaemonSetを展開し、キャッシュのカスタムリソース定義を登録します。 前提条件: ラベル付きキャッシュノード上のローカル NVMe ディスクを検出、フォーマット、およびマウントすること。 キャッシュ専用のディスクを使いましょう。別途前提チャートをインストールしないでください。 この拡張機能はキャッシュサーバーポッドを自動的に作成しません。

すべてのラベル付きキャッシュノードでマネージド NVMe の前提条件が整っていることを確認した後、サーバー数、容量、リソース制限、対象ノードを定義するキャッシュリソースを作成します。 コントローラーは cache-server ポッドを照合し、クライアント向けにディスカバリー情報を公開します。 コントローラーはリソースを管理します。アプリケーション データ読み取りのためのプロキシではありません。 インストールとキャッシュのプロビジョニングについては クイックスタート をご覧ください。

Note

キャッシュが空のとき、並行クライアントは同じキャッシュにないデータを独立して取得できます。 このプレビューでは、調整されたコールドキャッシュの生成は利用できません。 推論ポッドが始まる前に、プリフェッチを使って選択したモデルデータを事前に取り込んでください。

主な利点

  • ウォームモデルの読み込みを高速化する:頻繁に読み取られるモデルチャンクを、Azure Blob Storageから繰り返し取得するのではなく、ローカルまたはピアのNVMeから提供すること。
  • より速いスケールアウトとリカバリー: 新規または代替ノードは、クラスタ内にすでにキャッシュされているモデルデータを再利用できるようにします。
  • 繰り返しBlob読み込みの削減: アクティブなモデルワーキングセットをキャッシュに保持し、計画されたスケールイベントの前にプリフェッチを使いましょう。
  • レンジベースキャッシュ: すべてのモデルファイルを完全に展開するのではなく、要求されたバイト範囲をカバーするチャンクのみをキャッシュしてください。
  • 柔軟なアプリケーション統合:ネイティブの Python クライアントである BlobFuse2 か、Run:ai Model Streamer を使ってワークロードをキャッシュに接続します。
  • 安全なバックアップ:データがキャッシュされていないかキャッシュが利用できない場合、Azure Blob Storage を永続的な真実のソースとして保持します。

クライアント連携

アプリケーションの変更量は統合によって異なります:

Integration 次の場合に使用します。 アプリケーションの変更
BlobFuse2 through the Azure Blob CSI driver アプリケーションはLinuxのファイルシステムパスを通じてBlobデータを読み込みます。 読み取り専用のBlobFuse2ボリュームを設定し、既存のファイル読み取りコードを保持します。
ネイティブPythonクライアント 明示的な同期または非同期のキャッシュ操作を必要とします。 インポートしてDACSクライアントを呼び出します。
Run:ai モデルストリーマー あなたのアプリケーションはモデルデータを読み込むためにRun:ai Model Streamerを使っています。 モデルロードワークフローのためにDACS統合を設定してください。

ファイルシステムのセットアップおよび標準ストレージの測定結果については、 BlobFuse2を用いたクラウドストレージのための分散アクセラレータの使用を参照してください。 Pythonクライアントの設定や例については、「Pythonクライアントでクラウドストレージに分散アクセラレータを使う」を参照してください。

Hugging Face への直接オリジンアクセスはサポートされていません。 クラウドストレージ用の分散アクセラレーターを使う前に、モデルデータをAzure Blob Storageに配置してください。

キャッシュのセマンティクス

クラウドストレージ用の分散アクセラレータをデプロイする前に、以下の挙動を理解してください:

  • 持続性: キャッシュ データは一時的であり、永続性のために複製されることはありません。 キャッシュノードを失うと、そのノードに保存されていたチャンクが削除される可能性があります。欠損データは再びAzure Blob Storageから取得されます。
  • 信頼できる情報源: Azure Blob Storage は引き続き信頼できる情報源です。 DACSをモデルファイルやデータセットの唯一のコピーとして使わないでください。 モデルアップグレードには、不変でバージョン管理された Blob パスを推奨します。
  • エビクション: キャッシュは容量の閾値に達したときにデータを追い出します。 追い出されたデータは必要に応じて再度取得されます。
  • フォールバック:ディスカバリー設定が抜けたり、キャッシュが利用できない場合、クライアントがAzure Blob Storageから直接読み込んでしまうことがあります。 Blob の読み取りが成功したことをキャッシュの証拠として扱うのではなく、クライアントのキャッシュ ヒットとサーバー リクエスト カウンターの増加を検証してください。 DACSリクエストパスの検証を参照してください。
  • ID: ワークロードは Microsoft Entra ID または共有アクセス署名 (SAS) を使って Azure Blob Storage にアクセスします。 ワークロードに必要な最小権限の役割を使いましょう。
  • ネットワーキング: キャッシュトラフィックはAKSネットワーク内に残ります。 キャッシュミスやフォールバックのために、Azure Blobエンドポイントへのアクセスを許可しなければなりません。
  • 信頼境界: 信頼できるクラスター内でDACSを使いましょう。 キャッシュは相互に信頼できないテナントを隔離するわけではありません。

オープンソースプロジェクト

DACSは、Azure AI PlatformとAzure Storageの協力によって開発されたオープンソースプロジェクトです。 プロジェクトはキャッシュ実装を確認、実験し、コミュニティが貢献できるように公開することで、耐久性のあるストレージを置き換えることなく繰り返しのデータ読み取りを減らすことを目的としています。

Azure DACSリポジトリには、キャッシュサーバー、ネイティブのC/C++クライアント、Pythonアダプター、Rustラッパー、Kubernetesチャートとコントローラー、デプロイの例が含まれています。 オープンソースの互換性や設定ガイダンスについてはリポジトリREADMEを参照し、その貢献ガイダンスを使って再現可能な問題、ワークロードの測定、改善点を共有してください。

オープンソースプロジェクトとAzure管理のプレビューは、展開範囲やサポート範囲が異なります。 マネージド AKS エクスペリエンスについては、Azure クイックスタートに従ってください。リポジトリ デプロイ オプションはマネージド リリースの自動サポート機能ではありません。

プレビューのサポートと制限

以下の表は初期プレビュー範囲を要約したものです。

Area プレビュー範囲
Orchestrator AKS
Workload 主に推論モデルの読み込み;トレーニングのための繰り返しデータセット読み取り
起源 Azure Blob Storage
キャッシュメディア Linux キャッシュ ノード上のローカル NVMe
規模 最大100ノード
CPU アーキテクチャ x64とArm64
Network イーサネット; 対応VMサイズでのInfiniBand
ウォームアップ オンデマンド入力とプリフェッチ
コールドリードの協調制御 同時進行のコールド リードは協調制御されていません
Installation Azure CLI で有効になっている個別の DACS 管理拡張機能
Upgrade リリース固有の互換性およびアップグレードのガイダンスが適用されます
Price DACSソフトウェアの料金はかかりません。Azure VM、Blob Storage、ネットワーク料金は引き続き適用されます

他のストレージ オプションを使用するタイミング

ワークロードがDACSの範囲外の機能を必要とする場合は、別のAzureストレージオプションを活用しましょう:

次のステップ