NVIDIA Dynamo、共有HBMウェイトでスタンバイエンジンを事前ウォームアップし、フェイルオーバーを283秒から7.3秒に短縮

NVIDIAは、オープンソースの推論フレームワークDynamoに実験的なShadow Engine Failoverを追加し、「推論プロセスが停止した一方で、GPUとノードは正常」という障害におけるサービス性能低下の時間を短縮した。従来のコールドスタートでは、CUDA contextとともにHBM上のウェイトも解放されるため、代替プロセスはモデルの再ロード、KV cacheの割り当て、自動チューニング、CUDA Graphのキャプチャをやり直す必要がある。大規模モデルでは、これに数分かかる場合がある。

新しい設計では、各GPUの隣でGPU Memory Service（GMS）を稼働させ、独立したsidecarが物理メモリページを保持する。メインエンジンと事前初期化済みのshadow engineは、CUDA Virtual Memory Management APIを通じて同一の読み取り専用ウェイトをそれぞれの仮想アドレスにマッピングするため、スタンバイプロセスはウェイト一式を複製する必要がない。ShadowはCUDA context、NCCL／NIXL communicator、CUDA Graphを事前に作成し、アイドル時には物理KV cacheを解放する。メインプロセスが終了すると、カーネルがPOSIX `flock`を解放し、スタンバイがロックを取得してウェイトを再マッピングし、KV cacheを作成したうえでルーターに登録する。

NVIDIAは、2台のB200ノードにNVFP4で量子化したGLM-5.2をデプロイした。各ノードでは8-way tensor parallel、最大200K context、FP8 KV cacheを使用し、その後`SIGKILL`で一方のworkerを終了させた。2番目のworkerがコールドスタートで復旧するまでには283秒かかったのに対し、shadow経路では7.3秒だった。障害発生後のp50 time to first tokenは、それぞれ23,815ミリ秒と1,311ミリ秒だった。ただし、これはNVIDIAが独自に設計した単一の合成ワークロードであり、同一ノード上のプロセス障害のみを比較した結果である。

現時点で、エンジニアリングチームはこれを本番環境向けではない評価用機能として扱う必要がある。ドキュメントではKubernetes 1.34、DRA v1、NVIDIA GPU DRA driverが要件とされ、主要バックエンドはvLLMである。ハードウェア障害、ノード障害、マルチノード障害については、引き続き通常の再スケジューリングに頼る必要がある。また、切り替え後のKV cacheは空であり、既存のprefixを再利用することはできない。次の重要なマイルストーンは、KV cacheを安全に引き継げるか、そしてSGLang、TensorRT-LLM、異なるモデルtopologyでも同様の効果を再現できるかどうかだ。