CNCF：NetEase GamesがFluidプリフェッチレイヤーでKubernetes上の30秒LLMコールドスタートを達成

CNCF（Cloud Native Computing Foundation）ブログは2026年5月21日、中国最大のゲーム会社の一つであるNetEase Gamesの技術ケーススタディを公開した。NetEaseGamesインフラチームの廖海峰と張翔による記事で、大規模LLMモデルをKubernetesサービングスタックに読み込む時間を壊滅的な42分から30秒未満に短縮した方法を詳しく説明している。

最初に解決しようとした問題は何か？

NetEase Gamesはいくつかの本番ユースケース — ゲーム内AIのNPCダイアログ、コンテンツモデレーション、自動翻訳 — に70Bクラス（Llama 3、Qwenなど）のLLMモデルを使用している。モデルはクラスター内のすべてのノードのメモリに常駐させるには大きすぎ、スケーリングイベントやPod再起動のたびにオンデマンドで読み込む必要がある。

S3互換オブジェクトストレージから直接モデルにアクセスすると、70BモデルをGPUメモリに完全にロードするのに42分かかっていた。これは本番ワークロードには受け入れられない — 各スケーリングイベントが新しいPodに42分の停止を引き起こすことを意味する。

どのような最適化フェーズを経たか？

NetEaseは段階的に最適化を実施した。

フェーズ1 — S3直接アクセス：42分。ベースライン。

フェーズ2 — Fluid分散キャッシュ：14分。P2P転送を通じてクラスター内のノード間でモデルを共有するCNCF Fluidプロジェクトの実装。各Podが直接S3からプルする代わりに、新しいPodはすでにキャッシュしている隣接ノードからモデルを取得できる。

フェーズ3 — ローカルSSDキャッシュ付きFluid：3分。最も頻繁に使用されるモデルのウォームコピーを保持するローカルSSDキャッシングレイヤーの追加。新しいスケーリングイベント時にモデルはすでにローカルキャッシュにあり、ネットワーク転送が不要になる。

フェーズ4 — 事前ウォーミング + 予測スケジューリング：30秒未満。事前ウォーミング戦略 — 履歴負荷パターンに基づいて新しいPodがいつ必要になるかを予測し、Podが実際に必要になる前にモデルをプリロードする。モデルがすでにメモリにあるノードに新しいPodをスケジュールする予測スケジューリングと組み合わせる。

FluidはCNCFプロジェクトとして何か？

FluidはKubernetes向けデータオーケストレーションに特化したCNCFインキュベーションプロジェクトだ。主なユースケースは大規模データセット（LLMウェイト、トレーニングデータセット、科学データなど）へのアクセス高速化だ。Fluidは基盤となるストレージ（S3、GCS、HDFS、NFS）を抽象化し、組み込みのキャッシング、プリフェッチ、スケジューリング統合を備えた統一レイヤーを提供する。

LLMユースケースでは特に：

• Podレベルのアフィニティ — KubernetesスケジューラーがモデルをすでにキャッシュしているノードへのPodのスケジュールを優先できる
• 非同期プリフェッチ — Podが必要とする前にモデルをプリロードできる
• チーム間のキャッシュ共有 — 複数のチームが複数のコピーなしに同じモデルを共有できる

本番LLM推論にとって何を意味するか？

コールドスタートレイテンシはサーバーレスまたは自動スケーリングLLMデプロイメントの重要な問題だ。業界標準（OpenAI、Anthropic）は独自のスタックでサブ秒のコールドスタート時間を達成しているが、これはオープンソースコミュニティが容易に再現できないカスタムインフラの結果だ。

NetEaseのケーススタディは、他の企業がオープンソースコンポーネント（Kubernetes + Fluid + vLLM）を使って追従できる具体的なブループリントを提供する。70BモデルにおいてSeconds30秒未満のコールドスタートは大多数の本番ワークロードには許容可能で、典型的なマイクロサービスのスケーリングイベントに必要な時間と同程度だ。

CNCFにとって、このケーススタディはFluidプロジェクトの本番対応ツールとしての検証だ。他のLLMサービング事業者（Replicate、Together AI、Anyscale）が自社のマルチテナントLLMプラットフォーム向けに同様のFluidベースのアプローチを採用するかどうか注目だ。