デベロッパー

スケーラブルな AI はストレージから: モデルアーティファクト戦略ガイド

2025年9月4日

https://storage.googleapis.com/gweb-cloudblog-publish/images/hero_-_cloud_storage.max-2500x2500.png

Karl Weinmeister

Head of Cloud Product DevRel

※この投稿は米国時間 2025 年 8 月 15 日に、Google Cloud blog に投稿されたものの抄訳です。

大規模モデルのアーティファクトの管理は、MLOps における一般的なボトルネックです。モデルをコンテナイメージにベイク（組み込んで固定化）すると、デプロイが遅く、モノリシックになります。また、起動時にモデルをダウンロードする方式では、大きな遅延が発生します。このガイドでは、改善策としてモデルをコードから切り離す方法を見ていきます。具体的には、Cloud Storage でモデルをホストし、GKE と Cloud Run から効率的にアクセスします。よりアジャイルでスケーラブルな ML サービングプラットフォームを構築できるよう、従来のメソッドから高パフォーマンスの Cloud Storage FUSE CSI ドライバまでのさまざまな読み込み戦略を比較します。

アーティファクトの最適化

アーティファクトを最適化するには、Cloud Storage で一元的に管理し、量子化とキャッシュウォーミングを行うことをおすすめします。

Cloud Storage で一元化

スケーラブルな ML サービングアーキテクチャを実現するための最も重要なステップは、モデルアーティファクトを、アプリケーションコードとは独立した独自のライフサイクルを持つものとして扱うことです。これを行う最善の方法は、すべてのモデルアセット（.safetensors、.gguf、.pkl、.joblib ファイルなど）の、バージョン管理が適用された安全な唯一の信頼できる情報源として Cloud Storage を使用することです。

このアーキテクチャパターンは、ファイルを保存するうえで便利なだけではありません。推論が行われるコンピューティングプレーンとは論理的に分離された、一本化されたモデルプレーンを実現します。モデルプレーンは Cloud Storage でホストされ、ML アセットのガバナンス（バージョニング、ストレージの耐久性確保、アクセス制御）を処理します。

コンピューティングプレーン（GKE、Cloud Run、Vertex AI、ローカル開発マシンなど）は、モデルを GPU メモリに読み込んで推論リクエストを処理する実行部分を担当します。この分離により、戦略的な柔軟性が大きく高まります。Cloud Storage バケット内のバージョニングされた同じモデルアーティファクトを、GKE クラスタ（高スループットのバッチ予測ジョブ用）、Cloud Run サービス（バースト性の高いリアルタイム推論用）、フルマネージドの Vertex AI エンドポイント（使いやすさを重視）などで利用でき、基盤となるアセットを複製する必要がありません。このストレージ方法により、モデルの乱立が抑えられ、組織全体が監査可能な単一のソースを使って作業できます。

https://storage.googleapis.com/gweb-cloudblog-publish/images/model_plane.max-500x500.png

このアーキテクチャを効果的に実装するには、アーティファクトの整理に対する系統立てられたアプローチが必要です。ベストプラクティスでは、堅牢な MLOps ワークフローを可能にする Cloud Storage バケット構造の採用が推奨されています。これには、モデル名とバージョンを含めた明確な命名規則（たとえば、gs://my-model-artifacts/gemma-2b/v1.0/ という名前のバケット）を使用することや、異なる環境（開発、ステージング、本番環境など）に別々のプレフィックスやバケットを使用することが含まれます。

このアプローチでは、Identity and Access Management（IAM）ポリシーを使用してアクセス制御を厳密に管理する必要があります。たとえば、本番環境へのデプロイ用の CI / CD サービスアカウントは、本番環境モデルのバケットへの読み取りアクセス権のみを持ち、データサイエンティストは、開発またはテスト用のバケットへの書き込みアクセス権のみを持つようにします。また、開発イメージの本番環境パイプラインへの昇格には自動テストを必須にします。

特定のオブジェクトまたはバケット全体を一般公開する（roles/storage.objectViewer などの IAM ロールを allUsers プリンシパルに割り当てる）こともできますが、使用には注意が必要です。ストレージとガバナンスに対するこのような規律あるアプローチにより、Cloud Storage は単なるファイルリポジトリからスケーラブルで安全な MLOps エコシステムの基盤レイヤへと変貌します。

このスケーラビリティは、大規模なモデルをサービングする際には特に、パフォーマンスを確保するうえで非常に重要です。モデルの読み込みは、バースト性の高い高スループットのワークロードであり、多いときは数千の GPU が、同じモデルの重みをできるだけ速く同時に読み込もうとします。このシナリオでは、レイテンシを抑えながら最大 2.5 TB/秒の帯域幅を実現する Anywhere Cache を常に使用する必要があります。Cloud Storage の SSD ベースのマネージドキャッシュレイヤとして、Anywhere Cache は、データとコンピューティングリソースをお互いの近くに配置します。高速ローカルキャッシュから読み取りリクエストを透過的に処理することで、GKE、Compute Engine、Vertex AI などのゾーン内のあらゆる Cloud Storage クライアントにメリットをもたらし、モデルの読み込み時間を大幅に短縮します。

量子化

量子化とは、モデルの重みの精度を下げるプロセスです（たとえば、32 ビット浮動小数点数から 4 ビット整数に）。ストレージの観点から見ると、モデルの重みのサイズは、そのパラメータと精度（精度 × パラメータ数 = モデルサイズ）の関数です。精度を低くすることで、モデルのストレージフットプリントを大幅に縮小できます。

量子化には、2 つの大きなメリットがあります。

モデルサイズの縮小: 量子化されたモデルはディスク容量を大幅に節約できるため、ダウンロードが速くなりメモリ消費量が減ります。
推論の高速化: 最新の CPU や GPU の多くは、浮動小数点演算よりも整数演算をはるかに高速に実行できます。

最適な結果を得るには、高速な読み込みと効率的な推論のために設計された、GGUF などの最新の量子化対応モデル形式を使用します。

キャッシュウォーミング

多くの LLM において、最もコンピューティングコストが高いのはプロンプトの初期処理です。これに対処するために、モデルのビルドプロセス中に一般的なプロンプトやデータの代表サンプルを前処理し、結果のキャッシュ状態を保存できます。アプリケーションは起動時にこのウォームキャッシュを読み込むため、一般的なリクエストに対する高コストの初期処理をスキップすることが可能になります。vLLM をはじめ、いくつかのサービングフレームワークは、これをサポートする自動プレフィックスキャッシングなどの機能を提供しています。

アーティファクトの読み込み

適切なモデル読み込み戦略の選択は、アーキテクチャに関するきわめて重要な決定です。最も一般的なアプローチは次のとおりです。

Cloud Storage FUSE CSI ドライバ: GKE 上の最新 ML サービングワークロードのほとんどで推奨されるアプローチは、Cloud Storage FUSE CSI ドライバを使用することです。Cloud Storage バケットを Pod のファイルシステムに Volume として直接マウントするため、アプリケーションはローカルファイルのようにモデルを読み込むことができます。この実装により、ほぼ瞬時の Pod の起動が可能になり、モデルがコードから完全に切り離されます。
init コンテナのダウンロード: より柔軟なアプローチは、Kubernetes の init コンテナを使用して、メインアプリケーションの起動前にモデルを Cloud Storage から共有 emptyDir Volume にダウンロードすることです。この実装では、モデルがイメージから切り離されるため、コンテナを再ビルドすることなくモデルを更新できます。ただし、Pod の起動時間が大幅に長くなり、デプロイが複雑になる場合があります。このアプローチは、起動の遅延が許容される中規模モデルに適しています。
同時ダウンロード: init コンテナと同様に、アプリケーション内でモデルを同時ダウンロードできます。このアプローチでは並列化が可能になるため、単純な gsutil cp コマンドよりも高速になる場合があります。その代表的な例が vLLM Run:ai Model Streamer です。vLLM サービングフレームワークを使用する際に有効にできるこの機能は、大きなモデルファイルをチャンクに分割して同時に取得することで、ダウンロードを並列化し、初期読み込みを大幅に高速化します。
イメージにベイクする: 最も簡単な方法は、docker build プロセスの実行中にモデルをコンテナイメージに直接コピーすることです。このアプローチでは、コンテナが自己完結型でポータブルになりますが、非常に大きなイメージが作成されるため、ビルドと転送に時間がかかる場合があります。また、モデルとコードが密結合されているため、モデルを更新するたびにイメージを完全に再ビルドする必要があります。この戦略は、シンプルさが最優先される小規模なモデルや簡単なプロトタイプに最適です。

Cloud Storage FUSE による直接アクセス

Cloud Storage FUSE CSI ドライバは、GKE 上の ML ワークロードにとって大きな進歩です。Cloud Storage バケットを Pod のファイルシステムに直接マウントできるため、バケット内のオブジェクトがローカルファイルとして扱われます。この構成は、FUSE マウントを管理するサイドカーコンテナを Pod に挿入することで実現されます。データをコピーする必要がないため、ほぼ瞬時に Pod を起動できます。

Cloud Storage FUSE CSI ドライバは GKE の Standard クラスタと Autopilot クラスタの両方に対応していますが、Autopilot のセキュリティ制約により、通常 FUSE で必要となる SYS_ADMIN 機能を使用できないことに注意してください。CSI ドライバはこの特権アクセスなしでも動作するように設計されていますが、Autopilot にデプロイする際にはきわめて重要な考慮事項となります。

https://storage.googleapis.com/gweb-cloudblog-publish/images/gke_pod.max-600x600.png

パフォーマンスの調整

Cloud Storage FUSE は、そのまま使うだけでもモデルへの便利なアクセスを実現します。しかし、読み取り負荷の高い推論ワークロードでその可能性を最大限に引き出すには、キャッシュとプリフェッチの機能を調整する必要があります。

並列ダウンロード: 非常に大きなモデルファイルの場合、並列ダウンロードを有効にすることで Cloud Storage からローカルファイルキャッシュへの初期の読み込みを高速化できます。これは、ファイルキャッシュが有効になっている場合はデフォルトで有効になります。
メタデータのキャッシュ保存とプリフェッチ: ファイルに初めてアクセスするとき、FUSE はそのメタデータ（サイズや権限など）を Cloud Storage から取得する必要があります。メタデータをメモリに保持するには、stat キャッシュを構成します。このパフォーマンスをさらに向上させるには、メタデータのプリフェッチを有効にして、Volume をマウントする際に事前にディレクトリ内の全ファイルのメタデータを読み込むことができます。メタデータのプリフェッチを有効にするには、mountOptions 構成で metadata-cache:stat-cache-max-size-mb オプションと metadata-cache:ttl-secs オプションを設定します。

詳しくは、Cloud Storage ドキュメントのパフォーマンス調整のベストプラクティスをご覧ください。パフォーマンス調整された FUSE 設定で Cloud Storage バケットをマウントする GKE Deployment マニフェストの例については、サンプル構成 YAML ファイルをご覧ください。

GKE の高度なストレージ

Cloud Storage FUSE を使用すると、モデルアーティファクトに直接かつ便利にアクセスできますが、GKE は、非常に要求の厳しい AI および ML ワークロードの I/O ボトルネックを解消する、特殊な高パフォーマンスストレージソリューションも提供します。それは、Google Cloud Managed Lustre と Hyperdisk ML です。これらは、専用の並列ファイルストレージやブロックストレージを活用することで、高いパフォーマンスと安定性を実現できる代替手段です。

Managed Lustre

Google Cloud Managed Lustre は、特に厳しいパフォーマンス要件に対応するフルマネージドの並列ファイルシステムを提供します。HPC シミュレーションや AI トレーニング、推論ジョブなど、ミリ秒未満の超低レイテンシと大量の IOPS を必要とするワークロード向けに設計されています。POSIX に準拠しているため、既存のアプリケーションやワークフローとの適合性が確保されます。

DDN EXAScaler を活用することで、数ペタバイトにスケールし、最大 1 TB/秒のデータストリーミングを実現できるため、GPU や TPU に大量のデータを供給する必要がある大規模な AI ジョブに最適です。長期保存のアーカイブではなく、高スループットのデータアクセスを目的としています。主なユースケースはトレーニングデータとチェックポイントの永続ストレージですが、数百万の小さなファイルとランダムな読み取りを、非常に低いレイテンシと高いスループットで処理できます。そのため、多数の中間ファイルを読み書きする必要がある複雑な推論パイプラインにおいて強力なツールとなります。

GKE で Managed Lustre を使用するには、まず GKE クラスタで Managed Lustre CSI ドライバを有効にします。次に、ドライバを参照する StorageClass リソースを定義し、PersistentVolumeClaim リクエストを定義して新しい Lustre インスタンスを動的にプロビジョニングするか既存のインスタンスに接続します。最後に、PersistentVolumeClaim を Pod の Volume としてマウントします。これにより、Pod は高スループット、低レイテンシの並列ファイルシステムにアクセスできるようになります。

Hyperdisk ML

Hyperdisk ML は、AI / ML ワークロード、特にモデルの重みなどの静的データの読み込みを高速化するために構築されたネットワークブロックストレージです。オブジェクトストアへのファイルシステムインターフェースを提供する Cloud Storage FUSE とは異なり、Hyperdisk ML は、Cloud Storage からモデルアーティファクトをプリロード（事前読み込み）できる高パフォーマンスのブロックデバイスを提供します。

推論サービング向けの特に優れた機能は、READ_ONLY_MANY アクセスをサポートしていることです。これにより、1 つの Hyperdisk ML の Volume を読み取り専用デバイスとして最大 2,500 個の GKE ノードに同時にアタッチできます。このアーキテクチャでは、すべての Pod がモデルアーティファクトの高パフォーマンスな一元化されたコピーにアクセスでき、重複が発生しません。そのため、より小さい TB サイズの Volume で高スループットを実現するステートレス推論サービスをスケールアウトできます。Hyperdisk ML は読み取り専用であるため、モデルを更新するたびに運用プロセスの変更が必要となることに注意してください。

Hyperdisk ML を統合するには、まず Hyperdisk ML の Volume を作成し、そこに Cloud Storage からモデルアーティファクトを読み込みます。次に、GKE クラスタで StorageClass リソースと PersistentVolumeClaim リクエストを定義して、Pod で Volume を使用できるようにします。最後に、PersistentVolumeClaim を Deployment マニフェストの Volume としてマウントします。

Cloud Run でのアーティファクト配信

Cloud Run も、Cloud Storage バケットをボリュームとしてマウントできるため、ML モデルのサービングに適したプラットフォームです。特に、GPU サポートが追加されたことで適合性が高まりました。Cloud Run サービスの定義で Cloud Storage ボリュームのマウントを直接構成できます。この実装は、Cloud Storage に保存されているモデルにサーバーレスアプリケーションからアクセスするための、シンプルかつ効果的な方法を提供します。

gcloud コマンドラインツールを使用して、Cloud Storage バケットを Cloud Run サービスのボリュームとしてマウントする例を次に示します。

読み込んでいます...

アーティファクトのライフサイクルの自動化

アーティファクトのライフサイクルを自動化するには、スクリプト化された Cloud Run ジョブを含む取り込みパイプラインを構築し、Cloud Storage に直接ストリーミングします。

取り込みパイプラインの構築

本番環境では、モデルを取り込むための自動化された繰り返し可能なプロセスが必要であり、これは Cloud Run ジョブを使用して構築できます。このパイプラインの中核となるのは、コンテナ化されたスクリプトを実行する Cloud Run ジョブです。このジョブは、手動でトリガーすることもスケジュールに基づいてトリガーすることもでき、Hugging Face から Cloud Storage バケットにモデルを転送するための堅牢なサーバーレスパイプラインが実現します。

Cloud Storage に直接ストリーミング

モデルは、直接ストリーミングできます。Cloud Storage にアップロードする前に、モデル全体を Cloud Run ジョブのローカルディスクにダウンロードする必要はありません。この目的に最適なのが obstore ライブラリです。Hugging Face リポジトリと Cloud Storage バケットをオブジェクトストアとして扱い、それらの間でデータを非同期的にストリーミングできます。ローカルディスクの使用量を最小限に抑えてネットワークスループットを最大限に高めるため、非常に大規模なモデルの場合には特に、きわめて効率的です。

下記の例は、obstore ライブラリを使用して Hugging Face から Cloud Storage にファイルをストリーミングする際のコアロジックを示す、簡略化された Python スニペットです。

lang-py

読み込んでいます...

import os
import asyncio
from urllib.parse import urlparse
from huggingface_hub import hf_hub_url
import obstore as obs
from obstore.store import GCSStore, HTTPStore

async def stream_file_to_gcs(file_name, hf_repo_id, gcs_bucket_name, gcs_path_prefix):
   """Streams a file from a Hugging Face repo directly to Cloud Storage."""
   
   # 1. ソース（Hugging Face）と宛先（Cloud Storage）のストアを構成する
   http_store = HTTPStore.from_url("https://huggingface.co")
   gcs_store = GCSStore(bucket=gcs_bucket_name)

# 2. ファイルの完全なダウンロード URL を取得する
   full_download_url = hf_hub_url(repo_id=hf_repo_id, filename=file_name)
   download_path = urlparse(full_download_url).path
   
   # 3. Cloud Storage の転送先パスを定義する
   gcs_destination_path = os.path.join(gcs_path_prefix, file_name)

# 4. Hugging Face からダウンロード ストリームを取得する
   streaming_response = await obs.get_async(http_store, download_path)

# 5. ファイルを Cloud Storage にストリーミングする
   await obs.put_async(gcs_store, gcs_destination_path, streaming_response)

print(f"Successfully streamed '{file_name}' to Cloud Storage.")

# 使用例:
# asyncio.run(stream_file_to_gcs("model.safetensors", "google/gemma-2b", "my-gcs-bucket", "gemma-2b-model/"))

まとめ

モデルのアーティファクトをコンテナイメージから一元化された Cloud Storage バケットに移動することで、柔軟性とアジリティが大幅に向上します。この分離アプローチにより、CI / CD パイプラインが簡素化され、デプロイが加速し、コードとモデルを個別に管理できるようになります。

GKE 上の非常に要求の厳しい ML ワークロードの場合、Cloud Storage FUSE CSI ドライバが優れた選択肢です。時間のかかるコピー手順なしで、高パフォーマンスな直接のモデルアクセスを実現します。さらに高いパフォーマンスが必要な場合は、Managed Lustre または Hyperdisk ML の使用をご検討ください。これらのオプションを自動取り込みパイプラインやビルド時のベストプラクティスと組み合わせることで、真に堅牢でスケーラブルな、将来にわたって使用できる ML サービングプラットフォームを Google Cloud 上に構築できます。

成熟した MLOps プラットフォームへの道のりは、反復的なプロセスです。アーティファクト中心の設計という確固たる基盤から始めることで、強力かつスケーラブルであるだけでなく、絶えず変化する ML の状況に適応できるシステムを構築できます。お客様がご存知のモデルアーティファクトの管理に関するヒントも、ぜひ LinkedIn、X、Bluesky で共有してください。

-Cloud プロダクト DevRel 担当責任者 Karl Weinmeister

投稿先