Function Compute:GPU インスタンスでのモデルストレージのベストプラクティス

背景情報

関数のストレージタイプの詳細については、「関数のストレージタイプを選択する」をご参照ください。GPU インスタンスのモデルを保存するには、次の 2 つのタイプが適しています。

• File Storage NAS

• Object Storage Service (OSS)

GPU インスタンス関数はカスタムコンテナイメージを使用してサービスをデプロイするため、モデルファイルをコンテナイメージに直接配置することもできます。

各方法には独自のシナリオと技術的特徴があります。ストレージ方法を選択する際には、特定の要件、実行環境、およびチームのワークフローを考慮して、効率とコストのバランスを取る必要があります。

コンテナイメージを使用したモデルの配布

最も簡単な方法の 1 つは、トレーニング済みのモデルと関連するアプリケーションコードをコンテナイメージにまとめてパッケージ化することです。モデルファイルはコンテナイメージとともに配布されます。

利点と欠点

利点:

• 利便性: イメージを作成した後、追加の構成なしで直接推論を実行できます。

• 一貫性: これにより、すべての環境でモデルのバージョンが一貫していることが保証されます。これにより、環境間のバージョンの不一致によって引き起こされる問題を防ぐことができます。

欠点:

• イメージサイズ: 特に大規模なモデルの場合、イメージが非常に大きくなる可能性があります。

• 時間のかかる更新: モデルを更新するたびにイメージを再構築して配布する必要があり、これは時間のかかるプロセスになる可能性があります。

説明

関数インスタンスのコールドスタート速度を向上させるために、プラットフォームはコンテナイメージを前処理します。イメージが大きすぎると、プラットフォームのイメージサイズ制限を超える可能性があります。また、イメージの高速化と前処理に必要な時間も増加する可能性があります。

• プラットフォームのイメージサイズ制限の詳細については、「GPU イメージのサイズ制限は何ですか?」をご参照ください。

• イメージの前処理と関数のステータスの詳細については、「カスタムイメージの関数のステータスと呼び出し」をご参照ください。

シナリオ

• モデルサイズが比較的小さい場合、たとえば数百メガバイトなど。

• モデルの変更が頻繁でない場合。この場合、モデルをコンテナイメージにパッケージ化できます。

モデルファイルが大きい、頻繁に更新される、またはコンテナイメージがプラットフォームのサイズ制限を超える原因となる場合は、モデルをイメージから分離する必要があります。

File Storage NAS へのモデルの保存

Function Compute では、NAS ファイルシステムを関数インスタンスの指定されたディレクトリにマウントできます。その後、アプリケーションは NAS マウントポイントディレクトリにアクセスしてモデルファイルをロードできます。

利点と欠点

利点:

• NAS は、より完全で成熟した POSIX ファイルインターフェイスを提供するため、FUSE ファイルシステムよりも優れたアプリケーション互換性を提供します。

• 容量: NAS はペタバイト規模のストレージ容量を提供できます。

欠点:

• VPC への依存: 関数が NAS マウントポイントにアクセスするには、VPC アクセスを構成する必要があります。これには、複数のクラウド製品にまたがる権限の構成が必要です。さらに、関数インスタンスがコールドスタートすると、プラットフォームがインスタンスの VPC アクセスを確立するのに数秒かかります。

• 限定的なコンテンツ管理: NAS ファイルシステムは使用前にマウントする必要があります。この方法では、モデルファイルを NAS インスタンスに配布するためのビジネスワークフローを確立する必要があります。

• アクティブ/アクティブまたはマルチアベイラビリティゾーン (AZ) デプロイメントはサポートされていません。詳細については、「NAS のよくある質問」をご参照ください。

説明

多くのコンテナが同時に起動してモデルをロードするシナリオでは、NAS の帯域幅のボトルネックに容易に達します。これにより、インスタンスの起動時間が長くなり、タイムアウトによる起動失敗を引き起こすことさえあります。たとえば、スケジュールされた Horizontal Pod Autoscaler (HPA) がバッチで GPU スナップショットを作成したり、トラフィックの急増によって多くの弾性 GPU インスタンスが作成されたりする場合です。

• コンソールで NAS パフォーマンスモニタリング (読み取りスループット) を表示できます。

• 特定の NAS ファイルシステムの読み取りおよび書き込みスループットは、容量を増やすことで向上させることができます。

NAS を使用してモデルファイルを保存する場合は、パフォーマンス最適化 NAS ファイルシステムを使用することをお勧めします。これは、このタイプの NAS が約 600 MB/s の高い初期読み取り帯域幅を提供するためです。詳細については、「汎用型 NAS ファイルシステム」をご参照ください。

シナリオ

Function Compute で弾性 GPU インスタンスを使用する場合、高速な起動パフォーマンスが求められます。

Object Storage Service (OSS) へのモデルの保存

Function Compute では、OSS バケットを関数インスタンスの指定されたディレクトリにマウントできます。アプリケーションは、OSS マウントポイントから直接モデルをロードできます。

利点

• 帯域幅: OSS は NAS よりも帯域幅制限が高くなっています。これにより、関数インスタンス間の帯域幅の競合が発生しにくくなります。詳細については、「制限」をご参照ください。また、OSS アクセラレータを有効にして、より高いスループットを得ることもできます。

• 複数の管理方法:

  • コンソールや API などのアクセスチャネルを提供します。

  • さまざまなローカルで利用可能なオブジェクトストレージ管理ツールを提供します。詳細については、「開発者ツール」をご参照ください。

  • OSS の クロスリージョンレプリケーション機能を使用して、モデルの同期と管理を行うことができます。

• シンプルな構成: NAS ファイルシステムと比較して、OSS バケットを関数インスタンスにマウントするのに VPC 接続は必要ありません。構成後すぐに使用できます。

• コスト: 容量とスループットのみを比較した場合、OSS は一般的に NAS よりもコスト効率が高くなります。

説明

OSS マウントは、Filesystem in Userspace (FUSE) ユーザーモードファイルシステムメカニズムを使用します。アプリケーションが OSS マウントポイント上のファイルにアクセスすると、プラットフォームはアクセスリクエストを OSS API 呼び出しに変換してデータにアクセスします。したがって、OSS マウントには次の特徴があります。

• ユーザーモードで実行され、CPU、メモリ、一時ストレージなど、関数インスタンスのリソースクォータを消費します。したがって、この方法は、大規模な仕様の GPU インスタンスに最適です。

• データアクセスには OSS API を使用します。そのスループットとレイテンシは OSS API サービスによって制限されます。このため、モデルのロードシナリオで一般的な、少数の大きなファイルへのアクセスに適しています。多数の小さなファイルへのアクセスには適していません。

• OSS マウントは、ランダムな読み取り/書き込みよりもシーケンシャルな読み取り/書き込みに適しています。大きなファイルをロードする場合、シーケンシャルな読み取りはファイルシステムのプリフェッチメカニズムを最大限に活用して、より良いネットワークスループットとより低いロードレイテンシを実現できます。

  • たとえば、safetensors ファイルでは、シーケンシャルな読み取りに最適化されたバージョンを使用すると、OSS マウントポイントからモデルファイルをロードする時間が大幅に短縮されます。詳細については、「load_file: load tensors ordered by their offsets」をご参照ください。

  • アプリケーションの I/O パターンを調整できない場合は、ロードする前にファイルを一度シーケンシャルに読み取ることができます。これにより、コンテンツがシステムの PageCache にプリフェッチされます。その後、アプリケーションは PageCache からファイルをロードします。

シナリオ

• 多くのインスタンスが並行してモデルをロードします。これには、インスタンス間の帯域幅の競合を避けるために、より高いストレージスループットが必要です。

• ローカル冗長ストレージまたはマルチリージョンデプロイメントが必要です。

• モデルのロードシナリオで一般的な、シーケンシャルな読み取り I/O パターンで少数の大きなファイルにアクセスする場合。

比較のまとめ

この比較に基づき、さまざまな使用パターン、同時コンテナ起動ボリューム、およびモデル管理のニーズを考慮して、Function Compute (FC) GPU インスタンスにモデルを保存するための推奨プラクティスを以下に示します。

• ファイルシステム API との高い互換性が必要な場合、またはアプリケーションがランダム読み取りを使用し、メモリ PageCache にアクセスするように変更できない場合は、パフォーマンス最適化 NAS ファイルシステムを使用します。

• 多くの GPU コンテナが同時に起動するシナリオでは、OSS アクセラレータを使用して、NAS の単一ポイントの帯域幅ボトルネックを回避します。

• マルチリージョンデプロイメントシナリオでは、OSS と OSS アクセラレータを使用して、モデル管理とクロスリージョン同期の複雑さを軽減します。

テストデータ

以下の 2 つのテストでは、さまざまなシナリオでファイルをロードするのにかかる時間を比較することで、さまざまなストレージメディア間のパフォーマンスの違いを分析します。ロード時間が短いほど、ストレージのパフォーマンスが優れていることを示します。