# NIXL（NVIDIA Inference Xfer Library） NVIDIA が開発した [[LLM推論]] 向けのデータ転送ライブラリ。正式名称は NVIDIA Inference Xfer Library。GitHub: https://github.com/ai-dynamo/nixl NVIDIA Dynamo 推論基盤の構成要素として位置づけられており、[[vLLM]] などの推論フレームワークが KV Cache をノード間・ノード内で効率的に転送するために利用する。 ## アーキテクチャ NB API / SB API / バックエンドプラグインの3層で構成される。 ``` 推論フレームワーク（vLLM 等） ↓ North-Bound API（NB API） ← ユーザー向け高レベルインターフェース ↓ South-Bound API（SB API） ← バックエンドプラグイン向け低レベルインターフェース ↓ Backend Plugin（UCX / GDS / OBJ / MoonCake / HF3FS） ``` 推論フレームワーク側は「このバッファを転送したい」という意図のみを NB API に伝えれば、NIXL がバックエンドを自動選択して最短経路で転送を実行する。フレームワーク側はバックエンドの実装詳細を意識しなくてよい。 PyTorch Conference 2025 の LMCache + NIXL 資料では、NIXL の中核を Transfer Agent として描き、その内部に Memory Section と Metadata Handler を置く。上位 API は「メモリ種別 + `(addr, len, devID)` のリスト」、cross-node / cross-memory のバッファリストプリミティブ、再投稿可能な Transfer Handle、非同期 `create/post/check` を提供し、READ/WRITE 操作と任意通知を扱う。(Source: [[@2025__PyTorchConference__Scaling KV Caches for LLMs - How LMCache + NIXL Handle Network and Storage Heterogeneity]]) ## バックエンドプラグイン デフォルトで5種のバックエンドプラグインを持つ: | バックエンド | 対応メモリ種別 | 概要 | |---|---|---| | [[UCX]] | DRAM、VRAM | UCX ベースの汎用転送（デフォルト） | | [[GPUDirect Storage]] | DRAM、VRAM、FILE | GPUDirect Storage を利用 | | OBJ | DRAM、OBJ | S3 API 互換ストレージとの連携 | | MoonCake | DRAM、VRAM | MoonCake との連携 | | HF3FS | DRAM、FILE | DeepSeek の 3FS との連携 | UCX バックエンドが最も汎用的で、DRAM・VRAM の双方に対応し GPUDirect RDMA も扱う。 ## 動作フロー 1. NIXL Agent 初期化（バックエンドプラグインの設定を含む） 2. メモリー登録処理（転送に使用するバッファを NIXL に登録） 3. Agent 間のメタデータ交換（転送元・転送先の情報を共有） 4. データ転送処理（READ または WRITE 操作） 同資料の UCX 例では、開始ノードと対象ノードがそれぞれ agent と UCX backend を作り、GPU HBM バッファを登録する。対象ノードはローカルメタデータと受信バッファリストを開始ノードへ渡し、開始ノードは 2 つのバッファリストから NIXL Xfer request を作って非同期に投稿する。複数 request は back-to-back に投稿可能で、完了待ちと再投稿を繰り返せる。(Source: [[@2025__PyTorchConference__Scaling KV Caches for LLMs - How LMCache + NIXL Handle Network and Storage Heterogeneity]]) ## メモリ登録とストレージ NIXL への登録はゼロコピー転送のためのアクセス登録であり、登録記述子は `mem_type`、`addr`、`len`、`devID`、`info` を持つ。資料では DRAM、VRAM、BLK、FILE、OBJ が例示され、FILE は `fd` とパス/アクセスモード、OBJ は key と bucket ID を `info` に持てる。これにより HBM、ホストメモリ、ローカル SSD、ネットワークストレージを多段キャッシュとして扱う。(Source: [[@2025__PyTorchConference__Scaling KV Caches for LLMs - How LMCache + NIXL Handle Network and Storage Heterogeneity]]) ## ベンチマーク結果 [[SAKURA internet Inc]] の [[高火力 PHY]] チームが H100 HGX 2台（各8 GPU / 8 NIC、400 Gbps RoCEv2）で実施したベンチマークでは、NIXL + UCX を正しく構成した場合に以下を確認: - **ノード内 GPU 間（NVLink）**: 400 GB/s 付近を達成（NVLink 4.0 の理論値と一致） - **ノード間 GPU 間（400 Gbps NIC）**: 50 GB/s 付近で物理リンク帯域上限に律速 **結論**: KV Cache 転送のボトルネックはソフトウェア層ではなく物理リンクの帯域に収束する。 ## NCCLとの役割分担(disaggregated inference) 『AI Systems Performance Engineering』第4章([[@2025__OReilly__AI Systems Performance Engineering - Chapter 4 Tuning Distributed Networking Communication]])は、NIXLをNCCLの代替ではなく補完と位置づける。NCCLは学習で使われる同期的な many-to-many collective(all-reduce等)を担い、NIXLは推論で頻出する非同期の one-to-one/one-to-few 転送(KV cache移動等)を担う。NIXLはGPUDirect RDMAとIBGDA(InfiniBand GPUDirect Async)を活用してCPUを介さずGPU間転送を行い、NVLink・NVSwitch・InfiniBand/RoCE・PCIe・NVMeの中から最速経路を自動選択する。内部トランスポートには[[UCX]]を用いる。 **disaggregated inference(prefill/decode分離)**: transformer推論はcompute-boundなprefill(プロンプトからKV cache生成)とmemory-throughput-boundなdecode(KV cacheを使ったトークン生成)に分離できる。vLLM・SGLang・[[NVIDIA Dynamo]]・TensorRT-LLMはこの分離をサポートし、prefillクラスタで生成したKV cacheをNIXLでdecodeクラスタへ転送する。NVIDIA Dynamoでの実測では、680BパラメータLLM・72GPU Blackwell NVL72ラック構成でNIXL利用により最大30倍の推論スループット向上が報告されている。(Source: [[@2025__OReilly__AI Systems Performance Engineering - Chapter 4 Tuning Distributed Networking Communication]]) ## Prefill-Decode分離クラスタでの詳細動作(第17章) 『AI Systems Performance Engineering』第17章は、NIXL利用時の運用ディテールを補足する。Decodeワーカーはメモリ領域を登録し、Prefillワーカーがそこへ直接RDMA書き込みできるようにする。メモリ登録メタデータ(NIXL記述子)は起動時または初回接触時に交換され、以降のPrefillリクエストは短いIDのみを送ればよい(フルアドレス構造は不要)。Prefill/Decodeが異なるテンソル並列レイアウトを使う場合は、NIXL読み込み直後にレイアウト変換カーネルを受信側に挿入してKVブロックをDecode側の期待レイアウトへ整合させる。この変換はネットワーク転送時間に比べレイテンシ上無視できるとされる。事前登録済みピアメモリと大きなpinnedウィンドウサイズを使うことで、再登録のチャーンを最小化できる。ゼロコピー転送のオーバーラップはNsight Systemsのタイムラインで検証可能。(Source: [[@2025__OReilly__AI Systems Performance Engineering - Chapter 17 Scaling Disaggregated Prefill and Decode for Inference]]) ## KVBM のストレージバックエンド層としての利用 [[NVIDIA Dynamo]] の [[KVBM (KV Block Manager)]] は、3層アーキテクチャの最下層に NIXL を配置する。KVBM ロジック層が管理する KV ブロックの割り当て・生存周期・エビクションポリシーの決定に対し、NIXL 層は P2P GPU 転送・RDMA/NVLink リモート共有・動的ブロック登録とメタデータ交換・ストレージバックエンド(GPU HBM/Host DRAM/Remote DRAM/Local SSD/ファイルシステム/オブジェクトストア/クラウドストレージ)へのプラグインインターフェースという「実際のデータ移動」を担う。KVBM は vLLM・TensorRT-LLM に対応するが SGLang は非対応で、SGLang は独自の階層キャッシュ HiCache を NIXL と直接連携させる別経路を取る。(Source: [[@2026__NVIDIADynamoDocs__KVBM (KV Block Manager) 概要]]) ## 関連 - [[@2026__NVIDIADynamoDocs__KVBM (KV Block Manager) 概要]] — [[KVBM (KV Block Manager)]] の3層アーキテクチャ最下層としての NIXL の役割 - [[@2025__OReilly__AI Systems Performance Engineering - Chapter 17 Scaling Disaggregated Prefill and Decode for Inference]] — メモリ登録メタデータ交換、レイアウト変換カーネル、事前登録ピアメモリの運用ディテール - [[@2025__OReilly__AI Systems Performance Engineering - Chapter 4 Tuning Distributed Networking Communication]] — NCCLとの役割分担、disaggregated inference(prefill/decode分離)でのKV cache転送アーキテクチャ - [[@2025__さくらのナレッジ__分散推論基盤の基礎技術]] — NIXL の構造とベンチマーク結果の詳細 - [[@2025__PyTorchConference__Scaling KV Caches for LLMs - How LMCache + NIXL Handle Network and Storage Heterogeneity]] — LMCache と NIXL の統合、Memory Section、Metadata Handler、UCX/GDS/OBJ 例 - [[UCX]] — NIXL のデフォルトバックエンド - [[GPUDirect Storage]] — NIXL のストレージ直結バックエンド。フェーズ意識的な性能特性(粗粒度転送で優位・細粒度推論 I/O で劣後)は [[GPUストレージIOデータパス]] を参照 - [[LLM推論]] — NIXL が対象とするユースケース（KV Cache転送） - [[vLLM]] — NIXL を利用する代表的な推論フレームワーク