NVIDIA、AIモデル配信基盤「ModelExpress」を発表

データ転送には必ずコストがかかります。モデルのチェックポイントが数百ギガバイト、あるいはテラバイト規模に成長するにつれ、そのコストは急速に膨らみます。さらに深刻なのは、クラスター内でこれらのモデル重み（ウェイト）を移動させる作業が極めて頻繁に行われている点です。

具体的には、コールドスタート時にリモートストレージから GPU メモリへ重みを引き出す必要がありますし、オートスケーリングやローリングアップデートでは新しいレプリカに重みを配置する必要があります。また、RL（強化学習）によるポストトレーニングでも、更新された重みを一貫してトレーナーからロールアウトワーカーへ転送し続ける必要があります。

これらは異なるワークフローに見えますが、本質的には同じ「コスト」を課しています。つまり、有用な作業を開始する前に、重みを移動させるために費やされる時間です。

ModelExpress: モデル重みのライフサイクルを加速する

NVIDIA ModelExpress（MX）は、シンプルな考え方をベースに構築されています。モデルを読み込む前に、「互換性のある重みのコピーがすでにどこにあるか」を確認することです。各レプリカを独立したコールドスタートとして扱うのではなく、MX は利用可能な最速のソースと転送経路を選択します。

サービングピア（接続先）が GPU 内に互換性の高い重みを保持している場合、MX は NVIDIA Inference Xfer Library (NIXL) を介して P2P RDMA で直接 GPU から GPU へ転送を行います。これにより、オブジェクトストレージやローカルディスク、ホストメモリへの冗長なアクセスを回避できます。

もし利用可能なピアが存在しない場合、MX はサポートされている最速の経路からブートストラップします。具体的には、ディスクに書き留めることなく、あるいはローカルファイルを直接 GPU メモリへ読み込むことなしに、オブジェクトストアからストリーミング転送を行います。

MX は、DeepSeek-V4 Pro の重み付けデータと JIT カーネルキャッシュのアーティファクトを、稼働中のレプリカから新規のレプリカへ 10 秒未満で転送します。これにより、起動までの総時間を従来の 8 分から 1 分 44 秒に短縮しました。

残りの記事では、MX が GPU メモリへのデータ転送経路をどのように選択するか、特に稼働中のレプリカからの P2P RDMA を最優先し、冗長なダウンロードやコピーを排除する仕組みについて解説します。さらに、このアプローチがカーネルキャッシュの再利用や RL（強化学習）による重み付けデータの更新配布にも応用されている点も紹介します。

リモートストレージから GPU メモリまで、すべての工程を加速する

新しいワーカーが重み付けデータを入手できるのは、以下の 3 か所のいずれかです。

1. リモートストレージ（Hugging Face や S3 など）
2. ローカルストレージ
3. モデルを既に稼働させている他のワーカー

最初のワーカーの場合、まだピアとなるワーカーが存在しないため、ストレージからブートストラップする必要があります。MX はオブジェクトストレージからのチェックポイントストリーミングや、高速なローカルストレージからの読み込みに対応しており、いずれの経路でも不要なコピーを排除します。

一度目のワーカーが稼働を開始すると、最適なデータソースは切り替わります。その重み付けデータはすでに GPU メモリ上に配置され、前処理も完了しているため、互換性のある次のワーカーからは P2P RDMA を経由して直接読み込むのが理想的です。MX はこの切り替えを自動で行います。つまり、ストレージからのブートストラップを一度行えば、その後は GPU から GPU へスケールアウトし、互換性のあるピアが利用できない場合のみストレージにフォールバックします。

最初のワーカーの起動：ストレージからのブートストラップ

リモートオブジェクトストレージから GPU へ：ローカルディスクの回避

チェックポイントがクラウドバケットに保存されており、キャッシュ用のディスク層を別途用意・管理したくない場合、MX は Model Streamer を活用して、再利用可能な CPU 用一時バッファを経由し、safetensors ファイルを直接 GPU に転送します。これにより、チェックポイントはローカルディスクに書き込まれることがなく、中間的なダウンロードや再読み込み、ストレージボリュームの増設といった手間が不要になります。

Model Streamer はマルチスレッド対応のテンソルリーダーを使用し、チェックポイントの断片（シャード）間で並列的に範囲を指定してデータを取得します。テンソルが届き次第、リモートからの読み込みと GPU への配置処理をパイプライン化して実行されます。つまり、既に取得が完了したテンソルは推論エンジンへ渡される一方、後続のテンソルはまだ取得中の状態です。この仕組みにより、ストレージ、ネットワーク、GPU 間のデータ転送経路が常に稼働し続けつつ、ホスト側のメモリ使用量は一定範囲に抑えられます。

テンソル並列処理（tensor-parallel）環境では、参加する各ランクがリモートからの読み込みを分担し、通常は NCCL を介して結果を共有します。これにより、すべてのランクが独立してフルチェックポイントをダウンロードする必要がなくなります。MX はこの分散ストリームを推論エンジンの重みローダーに直接接続し、最初のワーカーを、後続する互換性のあるレプリカ向けの P2P ソースとして機能させる準備を整えます。

クラスターへの取り込み：一度のダウンロードで済ます

クラスターが共有ディスクキャッシュ層（Kubernetes の永続ボリュームなど）を維持している場合、MX はその階層へのデータ転送を一度だけ行うように制御します。例えば、10 個のレプリカが同時に 806 GiB の DeepSeek-V4 Pro モデルを取得しようとした場合、ネットワーク上では同じ ingress バンド幅を巡って競合しながら、合計約 8 TiB の同一データを重複して転送することになります。MX Model Cache Service はこうしたリクエストを統合し、単一の協調されたダウンロードとして処理します。メタデータストアにおけるアトミックな要求によりダウンローダーが選定され、残りのレプリカはその進捗を追跡しながらキャッシュされたコピーを再利用します。結果として、クラスターは外部からのダウンロードコストを一度だけ支払えばよく、すべてのレプリカが同じキャッシュ済みチェックポイントから処理を開始できるようになります。

ローカルストレージから GPU へ：ホストメモリを経由しない転送

システムで GPUDirect Storage (GDS) がサポートされている場合、MX は NIXL のマルチスレッド対応 GDS バックエンドを通じて、チェックポイントファイルを直接ローカルストレージから GPU メモリへ読み込みます。NIXL はバッチ処理されたテンソル読み取りを並列実行し、ホストメモリを経由せず、従来のロードラーが必要とする中間コピーも不要にして直接 GPU メモリに書き込みます。ユーザーが GDS を明示的に有効化する必要はありません。MX がその機能を自動的に検出し、利用できない場合は別の読み込み戦略へ自動切り替えます。

ローカルストレージから GPU へ：ModelStreamer との連携による読み込みパイプライン化

MX は ModelStreamer を通じて、ローカルのチェックポイントも読み込めます。複数の OS スレッドが safetensors を並列に読み込み、設定可能な CPU バッファへ格納します。一方、処理済みのテンソルは GPU へ転送され、その後も並行して読み出しが続きます。

GDS との違いは、この経路ではホストメモリを経由する点です。しかし、ディスク I/O と GPU への配置を重畳させることで OS のページキャッシュの恩恵を受けられ、ストレージから直接 GPU にアクセスできない環境でも、移植性の高い高速パスを提供します。

最初のワーカー以降は、 serving ペアからフェッチする

これが MX の中核機能です。同じモデルを既に処理しているレプリカが一つでも存在すれば、重み（ウェイト）の移動はほぼ完了しています。つまり、それらは GPU メモリ上にあり、後処理も済み、推論エンジン用にレイアウトされた状態なのです。

MX はそのレプリカを生きた重みのソースとして扱います。互換性を確認した後、ソース GPU からターゲット GPU へ直接テンソルを転送します。新しいレプリカが重みをロードすると、すぐにソースプールに参加し、次のレプリカはそこから読み込む対象となります。

成功する転送ごとにプールは拡大し、デプロイメントの規模拡大に合わせて、冷たいロード（コールドロード）の繰り返しではなく、GPU から GPU への扇状展開（ファンアウト）を実現します。

MX のコントロールプレーンは互換性のあるピアの発見、転送メタデータの交換、ソースの準備状況の追跡を担当しますが、重みバイトそのものを扱うことはありません。一方、データプレーンでは MX はデフォルトとして NIXL を転送エンジンとして採用しており、プラグイン可能なバックエンドにより、Infiniband、RoCE、NVLink、EFA といった多様なネットワーク環境で最高性能を発揮します。また、MX は fabric-lib やスタンドアロンの Mooncake などのライブラリが MX と統合できるよう、第一級クラスのトランスポートインターフェースを提供しています。

転送を開始する前に、MX はテンソルレイアウトを決定するモデルとランタイム設定から mx_source_id を計算し、ID が一致するピアのみを対象とします。これらのピアの発見は、Redis、Kubernetes CRD、あるいは k8s-service（サーバーレス）メタデータバックエンドを通じてコントロールプレーンが行います。**

NIXL のメモリ登録オーバーヘッドの最適化

NIXL がテンソルを RDMA 転送する前に、その GPU メモリ領域を登録する必要があります。これはリモートアクセスに使用される Remote Key (rkey) を返す ibv_reg_mr 呼び出しです。大規模モデルには数万個のテンソルが含まれるため、一つずつ登録していくと時間がかかり、予算（許容範囲）を超えてしまう可能性があります。デフォルトでは MX は各テンソルを個別に登録しますが、この登録コストを削減するための 2 つのオプトイン戦略が存在します：

プール登録では、各テンソルではなく基盤となる cudaMalloc の割り当てを 1 回だけ登録するため、一般的なモデルで登録回数を 80〜99% 削減できます。転送のセマンティクスには一切変更がありません。

VMM アリーナ登録はさらに一歩進んでいます。CUDAPluggableAllocator を導入して、ロード時のすべての割り当てを単一の 16 TiB の仮想アドレスアリーナにルーティングします。そしてロード完了時に、使用済みの範囲全体を dmabuf ベースのメモリ領域として一括登録します。これにより、テンソルごとの 1 回ずつだった登録呼び出しが、全体で 1 回に集約されます。各テンソルの記述子は、単一の領域内でのオフセット値を持つだけになります。

図 3 に示すように、DeepSeek-V4-Pro を vLLM エンジン上で TP=8 で実行し、各アプローチの平均 NIXL 登録時間を測定しました。

ランタイムパス選択と安全なフォールバック

起動時、MX は利用可能な機能をプローブし、環境がサポートしないパスは自動的にスキップします。適用可能な最初の戦略は、現在の優先順位に従って実行されます：P2P RDMA → ModelStreamer → GDS → デフォルトローダー（ホストステージングされた POSIX I/O）。いずれのパスも利用できない場合や、モデル状態を変更する前に失敗した場合は、MX は自動的に次のパスへ移行します。重みの書き込みが開始された後に障害が発生した場合でも、モデルを再初期化してから続行するため、部分的に書き込まれた重みが提供されることはありません。

P2P リトライは転送開始前のメタデータ障害時のみ代替ピアを試行し、ネイティブローダーが最終的なフォールバックとして機能します。この能力駆動型の設計により、MX コアはハードウェア・ソフトウェアを問わずプラットフォームに依存せず、サポートされている環境でのみ固有の高速パスが有効化されます。

エンドツーエンドの結果

DeepSeek-V4-Pro を 8xB200 GPU ノード（NVIDIA ConnectX-7 NIC 搭載）で実行し、異なるコールドスタートシナリオにおけるモデル読み込み時間の総計を比較しました。各レプリカは vLLM 0.23.0 を使用し、TP=8、--enable-flashinfer-autotune オプションを有効にしています。以下に Figure 4 を示します。

単なる読み込みではなく、ウォームアップ：コンパイル済みカーネルの継承

重みを GPU メモリに転送することは重要ですが、モデルを読み込んだだけではすぐにサービス提供できる状態ではありません。最初のフォワードパス実行時に、エンジンでは JIT コンパイルとオートチューニング（torch.compile、Triton、DeepGEMM、TileLang など）が行われ、特定のモデル・データ型・量子化設定・GPU に合わせた CUDA グラフがキャプチャされます。DeepSeek-V4 Pro のような大規模モデルの場合、このプロセスには数分を要し、MX による重み読み込みレイテンシの削減が進むと、これが起動コストの主要部分を占めるようになります（以下に Figure 5 を示します）。

この繰り返されるウォームアップは回避可能です。モデル、ソフトウェアスタック、GPU アーキテクチャが一致している場合、1 つのレプリカがコンパイルコストを負担し、他のレプリカはその結果として得られたキャッシュを継承できます。

MX のアーティファクト転送 API は、ファイルベースのアーティファクトをパッケージ化し、NIXL の CPU から CPU への RDMA パ経由で登録済みのホストメモリバッファ間で直接転送します。その後、ターゲットエンジンのキャッシュディレクトリに検証してインストールされます。これにより、Kubernetes で共有の ReadWriteMany (RWX) ボリュームが必要なくなる一方で、アーティファクト固有の mx_source_id によって互換性のないレプリカ間での誤った再利用を防ぎます。Redis や Kubernetes のメタデータバックエンドが設定されている場合、MX は標準的なキャッシュ場所を自動的に検出します。

カーネルアーティファクト転送が起動時間をどれだけ短縮できるかを測定するため、同じセットアップでテストを行いました。アーティファクト対応のランでは、Triton/DeepGEMM/TileLang/CuTe DSL/FlashInfer のキャッシュが転送されました。グラフは、プロセス開始から API 利用可能になるまでの主要な起動ステージと、全体の経過時間を比較しています。

ステップごとに重みが変化する場合：RL 事後トレーニング

これまでの議論は、モデルの重みを読み込まれた後は固定されるという前提に基づいていました。しかし、強化学習（RL）におけるポストトレーニングはこの前提を覆します。トレーナーはステップごとにポリシーを更新するため、ロールアウトを生成する推論アクターは、次の生成ラウンドの前にその更新された重みを取得する必要があります。推論の起動時と同様に、重みの移動も RL においてクリティカルパス上に位置しています。ロールアウトワーカーは、トレーナーが持つ分散レイアウト（FSDP/DTensor のシャードや Megatron の TP、PP、EP パーティションなど）から、推論エンジン側のレイアウトへ重みが転送されるのを待機することになります。

ModelExpress（MX）は、以下の 4 つのステージを通じてリフィットを推進します。

• Publish（公開）：各トレーナーランクが、既に所有しているテンソルやシャードを MX に登録します。これには形状、データ型、配置情報、および MX へのパラメータマッピングといったメタデータが含まれます。
• Discover（発見）：ロールアウトワーカーは、MX を介して要求された重みバージョンとその利用可能なソースを検索します。
• Plan（計画）：レシーバー側では、公開された所有情報を自らのターゲットレイアウトにマッピングし、必要なテンソルや範囲を保持するソースを特定します。
• Pull, convert, and load（取得・変換・読み込み）：レシーバーは、これらのソースに対してワンサイドドリード（片方向読み取り）を直接実行します。

MX には、受信側主導のリフィット（再調整）を実現する中核的な構成要素が含まれており、顧客は現在、実際の統合プロセスでそれらの評価を進めています。また、Fireworks/Cursor や Cognition など、最近の RL（強化学習）ランで採用されている手法である、クロスクラスター間の重み転送に用いられる「デルタ重み差分リフィット」の実験も進めています。

Dynamo への貢献とロードマップ

MX は vLLM と SGLang にネイティブ対応しており、Dynamo や llm-d を含むさまざまな推論フレームワークでの運用をサポートしています。

Dynamo のオープンソースコミュニティは、TensorRT-LLM とのより深い統合や、推論機能の拡大に向けて積極的に活動しています。最新のドキュメントを確認し、GitHub の ロードマップ でプロジェクトの方向性を把握した上で、ご自身の環境で利用可能なワークフローを試してみてください。そして、プロジェクトの未来を形作るためのフィードバックを提供していただければ幸いです。

謝辞

ModelExpress はチーム全体での取り組みです。MX チームのメンバー、特に Zhongdongming Dai 氏と Tanushriya Singh 氏のプロジェクトへの核心的な貢献に感謝します。また、プロジェクトの技術的な方向性に関する指導をいただいた Itay Neeman 氏、Anish Maddipoti 氏、Istvan Haller 氏、Omri Kahalon 氏、そして llm-d の統合支援を行っていただいた Red Hat の Will Eaton 氏にも深く御礼申し上げます。