# Efficient, VRAM-Constrained xLM Inference on Clients > [!info] Talk metadata > - **会議:** [[MLSys2026]] Day 5 (May 22 / Fri)、Grand Ballroom 1、Industry Track Oral Presentation: Compilers/HW（08:30 PDT 開始、Moderator: Phitchaya Phothilimthana） > - **登壇者:** Aditya Ukarande（NVIDIA） > - **全著者:** Aditya Ukarande¹, Deep Shekhar², Marc Blackstein¹, Ram Rangan²（¹NVIDIA Corporation, Santa Clara, CA, USA、²NVIDIA Graphics Pvt Ltd., Bangalore, India） > - **URL:** https://mlsys.org/virtual/2026/oral/3802 > - **OpenReview:** https://openreview.net/forum?id=VKqQYg6JPb > - **GitHub:** https://github.com/deepshnv/pipeshard-mlsys26-ae > - **関連プロダクト:** NVIDIA IGI SDK（In-Game Inferencing）、Cosmos-Reason1（CR1）VLM、llama.cpp（ブランチ b6097） > - **成果物バッジ:** ACM Artifacts Available v1.1、Artifacts Evaluated Functional v1.1、Results Reproduced v1.1（3 冠） > [!abstract] 概要（論文アブストラクト） > クライアント AI の次の革新を牽引するには、高精度な大規模言語モデル（LLM）と視覚言語モデル（VLM）――総称して xLM――の効率的かつロスレスな推論をクライアントシステム上で実現する急務がある。具体的には (a) インタラクティブ・バッチ双方の動作モード、(b) 高解像度 VLM 推論、(c) 密結合・MoE 双方の LLM、(d) CPU スレッド数・CPU-GPU 相互接続帯域幅・VRAM 予算・実行フェーズ・コンテキスト長といったシステム条件への適応が求められる。近年の CPU-GPU ハイブリッドスケジューリング技術は有望であるが、これらすべてを単一のプロダクトで満たすものは存在しない。本論文では **パイプラインシャーディング** を提案する。ベンチマークプロファイル駆動の新しい CPU-GPU ハイブリッドスケジューリング技術であり、サブレイヤー粒度でのモデル分割、CPU オフロード、パイプライン化コピーコンピュート、VRAM 内の優先度付きテンソル配置を組み合わせ、密結合・MoE 双方の LLM で TTFT と TPS の両方を最適化する。VLM については、パイプラインシャーディングと VLMOpt（ビジョンテンソルの CPU オフロード、ビジョンエンコーダへの FlashAttention 適用、ビジョン・言語モデル間の VRAM 割り当て重複回避の 3 最適化）を組み合わせる。対話的利用では TTFT が最大 6.7 倍、TPS が最大 30 倍高速化し、CR1 推論の VRAM 需要は 10 分の 1 に低減、バッチモードではスループットが最大 8.2 倍向上する。 ## 背景: クライアント xLM 推論の課題 - クライアントシステム（デスクトップ PC・ノート PC）では GPU が PCIe 経由で接続される。GPU の VRAM（1000 GB/s 以上）に対し PCIe Gen5 のピーク帯域幅は片方向 64 GB/s と 5--15 倍遅く、sysRAM は 50--300 GB/s に位置する。**CPU-GPU 間転送はすべてクリティカルパス上**にある。 - クライアント AI を形作る 2 つの要求がある。(1) 強力な xLM（LLM / VLM）を VRAM 大量消費のゲームと同時実行すること、(2) 同一の高精度モデルを異なる SKU で出荷すること。既存手法は「精度・速度・VRAM」のトリレンマのうち 2 つまでしか同時に達成できない。量子化は精度を犠牲にし、CPU 全面オフロードは低速であり、GPU 全面実行は VRAM を要求する。 - バッチサイズ 1・対話的推論（シングルユーザ）が主要ユースケース。人間の読解速度（英語 183 WPM = 約 4--5 TPS）を上回る TPS と、低 TTFT の両方が必要である。GPU はゲーム・クリエイティブアプリ・RTX Broadcast と共有されるため、xLM は限られた VRAM で動作しなければならない。 ## 既存手法との比較 - 論文 Table 1 で TwinPilots・HeteGen・MoE-Lightning・EdgeMoE・APEX・HeadInfer の 6 手法と比較。評価軸は「TTFT 最適化 / バッチサイズ 1 対応 / 密結合 LLM 最適化 / MoE LLM 最適化 / アテンション・FFN の優先度分離 / KV キャッシュシャーディング / VLM 最適化 / クライアント実機評価」の 8 軸。**パイプラインシャーディングは全 8 軸を満たす唯一の手法**である。 - llama.cpp の静的レイヤー分割（`-ngl` パラメータ）は手動チューニングが必要で、VRAM 予算に応じた最適値を反復試行で探さなければならない。本手法はこれを自動化する。 ## 提案手法: パイプラインシャーディング パイプラインシャーディングは 3 フェーズで動作する: **プロファイル**（インストール時）、**プラン**（モデル呼び出しごとに 1 回）、**推論**（毎イテレーション）。 ### プロファイルフェーズ（インストール時） - CPU・GPU の各カーネル（matmul、GQA、MHA、MoE ルーティング、要素演算）を量子化データ型・演算形状・スレッド数の組み合わせでベンチマークする。CPU カーネルは PCIe 競合下でもプロファイルする。 - CPU・GPU 両方のルーフラインモデルを全量子化レベルで構築し、約 170 KB のプロファイルデータベースを生成する。所要時間は約 15 分。 ### プランニングフェーズ（モデル呼び出しごと） - 入力グラフをサブレイヤー粒度で**シャード**に分割する。トークンティア $\mathbb{J} = \{1, 4, 16, 32, 64, 512, 1\text{K}, 2\text{K}, 4\text{K}, 8\text{K}, 16\text{K}\}$ ごとに 3 種のスケジュールプランを生成し、プロファイルベースのコスト推定で最良のプランを選択してルックアップテーブルに格納する。 - **VRAM の優先度付き配置:** アテンション > KV キャッシュ > FFN > 出力の順に VRAM をピン領域とスクラッチ領域に分配する。EdgeMoE に着想を得て、MoE・密結合双方で FFN よりアテンションサブレイヤーを優先する。 - 低トークンティアでは中間テンソルが小さいため、llama.cpp の静的レイヤー分割よりも多くのサブレイヤーを VRAM にピン可能。 ### 3 種のスケジュールプラン 1. **GPU-only:** ピンされていないサブレイヤーをすべて sysRAM から VRAM スクラッチへのダブルバッファリングでストリームし GPU で実行する。コンピュート量が大きく PCIe レイテンシを隠蔽できる高トークンティアで有利。 2. **Static:** サブレイヤーを優先度に基づき GPU と CPU に固定分配する。高優先サブレイヤーは VRAM スクラッチにピンして GPU で実行し、低優先サブレイヤーは sysRAM 常駐で CPU 実行。CPU-GPU 間は中間出力のみ転送するため、重み転送の繰り返しを回避。CPU スレッドが豊富で大テンソル転送が支配的な場合に有利。 3. **Dynamic:** Static の拡張。一部の sysRAM 常駐サブレイヤーを GPU スクラッチへの JIT ストリームで GPU でも実行し、CPU コンピュートと GPU 重みストリーミングをオーバーラップする。CPU スレッドが中程度で帯域幅・コンピュートが均衡する場合に有利。 - プロファイラの有効性検証: nemo8b・qwen30b の 2 モデル、PCIe Gen3/Gen5、スレッド数 1/16、コンテキスト 4K/16K、複数 VRAM 予算にわたる 105 構成で、プランナは 100%（105/105）の構成で最適戦略を選択。個別スケジュールのレイテンシ推定誤差の中央値は約 10% だが、戦略選択の正確性には影響しない。 - 全 105 構成の分布: Static が 72%、Dynamic が 18%、GPU-only が 10%。単一の戦略では全シナリオをカバーできないことが示された。 ### 推論フェーズ - バッチ内の新規トークン総数に基づきルックアップテーブルからスケジュールを選択し、セットアップ・実行する。テーブル参照のみでスケジューリングオーバーヘッドはゼロ。 - コンテキストフェーズのリクエストは大量のトークンを寄与し、デコードフェーズのリクエストは 1 トークンのみ。バッチ内にコンテキスト・デコード双方が混在しても、バッチ全体の新規トークン数で適切なティアを自動選択する。 ## VLMOpt: 高解像度 VLM をクライアントで実現 VLM 推論では言語パートにパイプラインシャーディングを、ビジョンパートに VLMOpt を適用する。VLMOpt は 3 つの最適化からなる。 1. **ビジョンテンソルオフロード:** CLIP / ビジョンエンコーダの重みを sysRAM にピンし、実行時に GPU へストリームする。静的ビジョン重みから VRAM を解放する。 2. **ビジョンエンコーダへのタイル化 FlashAttention 適用:** Qwen2.5-VL 系のビジョンエンコーダは self-attention で $O(N^2)$ の KQ テンソルを生成し、高解像度画像（1440p）では数 GB に達する。llama.cpp の FlashAttention 実装をビジョンエンコーダにも適用し、クエリテンソルをタイル分割して VRAM 使用量を 2 GB 未満に抑える。 3. **ビジョン・言語モデルの VRAM 重複回避:** ビジョンエンコーディング完了後に GPU リソースを解放してから言語コンテキストを初期化する。ピーク VRAM は `max(ビジョン, 言語)` となり、従来の `ビジョン + 言語` の合算を排除する。 - Cosmos-Reason1（CR1）ではネイティブ解像度処理のため、VLMOpt の効果が顕著。vLLM ベースラインの 20 GB 以上のピーク VRAM を 2 GB まで 10 倍削減し、1080p・1440p の高解像度推論をクライアントで初めて実現する。 ## 評価 ### モデルとクライアントシステム **モデル:** | 略称 | モデル名 | ディスクサイズ | |---|---|---| | nemo4b | mistral-nemo-minitron-4b-128k-instruct-f16 | 7.7 GB | | nemo8b | mistral-nemo-minitron-8b-128k-instruct-f16 | 15.7 GB | | vnemo4b | nemotron-vision-4b-instruct-f16 | 8.4 GB | | qwen30b | Qwen3-30B-A3B-Instruct-2507-q4 | 16.4 GB | | qwen235b | Qwen3-235B-A22B-Instruct-2507-q2_k | 77.0 GB | | cr1 | Cosmos-Reason1 | 15.4 GB | **クライアントシステム:** | 名称 | GPU | VRAM | CPU (コア) | RAM | メモリ帯域幅 | PCIe 帯域幅 | |---|---|---|---|---|---|---| | cli1 | RTX 3500 | 12 GB | 16 (Ultra 7) | 64 GB | 119.5 GBps | 13 (16 peak) GBps | | cli2 | RTX 5070 Ti | 16 GB | 8 (Ryzen 7) | 128 GB | 57.6 GBps | 50 (64 peak) GBps | | cli3 | RTX 5090 | 32 GB | 16 (EPYC) | 256 GB | 153.6 GBps | 50 (64 peak) GBps | 全システムは Windows 11 で動作する。ベースラインは llama.cpp b6097 の `-ngl` 手動最適チューニング（*llama-cpp-baseline*）。出力は同一でロスレス比較。 ### シングルユーザ LLM 性能（cli3） - **TTFT 高速化:** 平均 2 倍、最大 6.7 倍。小 VRAM 予算で効果が最も大きい。 - **TPS 高速化:** 平均 3.7 倍、最大 30 倍（qwen235b、64K コンテキスト）。コンテキスト長に伴い KV キャッシュが増大し、本手法の適応的スケジューリングが効く。 - **E2EL 高速化:** 平均 2 倍、最大 4.3 倍。 - qwen235b（ディスク 77 GB）は 2G VRAM で 7.7 TPS（1K コンテキスト）を達成。VRAM フットプリントは **39 分の 1** だがインタラクティブ（5 TPS 超）を維持する。同モデルは 16K コンテキストでも 5.2 TPS を達成。 - 4G VRAM でも大半のモデルが 5 TPS を超え、qwen235b が 16K で 6.7 TPS を記録。これはディスクサイズの 5% の VRAM 予算に相当する。 ### MoE モデルの手動オフロードとの比較（cli3、qwen30b） - llama.cpp の手動 MoE FFN オフロード（`-cmoe`）および KV キャッシュオフロード（`-kvo`）と比較（Figure 3）。パイプラインシャーディングは大半の条件で手動オフロードを上回る。 - 手動オフロードは低 VRAM・小コンテキストで TPS が拮抗するが、TTFT は一貫して劣化する。64K コンテキストでは TPS 高速化が最大 21.8 倍に達する。KV キャッシュの sysRAM 配置により GPU マップドアテンションブロックの性能が著しく低下するため。 ### cli2・cli1 における性能（ピーク VRAM） - cli2（RTX 5070 Ti、16 GB）: qwen30b が 1K コンテキストで 54.9 TPS、qwen235b は OOM（メモリ不足）。nemo8b は 1K で 22.9 TPS。 - cli1（RTX 3500、12 GB）: qwen30b が 1K で 26.1 TPS、qwen235b は OOM。nemo8b は 1K で 10.7 TPS。 - VRAM 予算をピーク容量の半分にしても、16K コンテキストまでの全モデルで 5 TPS 以上を維持する。 ### バッチモード性能（cli3） - バッチ全体のトークン数でトークンティアを選択する設計により、マルチリクエストにも自然に適応する。 - **平均 2.3 倍、最大 8.2 倍**のスループット高速化。qwen30b は 64 ユーザ・1K コンテキスト・16G VRAM で **289 TPS** を達成。 - TPS はバッチサイズ 64 まで概ねスケールする。4K コンテキストでは KV キャッシュが VRAM 予算を超過する地点で TPS が頭打ちになる。 ### ゲームとの同時実行（Cyberpunk 2077） - cli1（1080p）と cli2（4K）で qwen30b と Cyberpunk 2077 を同時実行。VRAM 予算の削減により LLM が使用する VRAM を抑え、ゲームの FPS を維持する。 - 大 VRAM 予算ではゲームアセットが sysRAM に溢れフレームタイムが増大し FPS が低下する。パイプラインシャーディングで LLM を小 VRAM 予算に制限すると、**TPS と FPS の両方がパレート最適な甘い点**に到達する。 ### VLM 性能 **vnemo4b（固定解像度 336x336）:** - cli2・cli3 の双方で E2EL が 1.5--1.78 倍高速化。2G VRAM 予算でもベースラインが OOM となる場面で動作可能。 **Cosmos-Reason1（ネイティブ解像度）:** - vLLM ベースライン（ピーク VRAM 20 GB 以上）に対し、パイプラインシャーディング + VLMOpt で VRAM 需要を 10 分の 1 に削減（20 GB → 2 GB）。 - cli2 で最大 9.0 倍の E2EL 高速化。1080p は cli2 で 14.5G VRAM 予算時に 3.7 秒、cli3 で 14.5G 時に 2.6 秒。ベースライン（vLLM）は 1080p 以上で OOM。 | 画像解像度 | cli2: 4G | cli2: 8G | cli2: 14.5G | cli3: 4G | cli3: 8G | cli3: 14.5G | |---|---|---|---|---|---|---| | 480p | 1.3x | 1.3x | 3.5x | 1.2x | 1.3x | 2.5x | | 720p | OOM | 1.6x | 4.6x | OOM | 1.5x | 3.2x | | 1080p | OOM | OOM | 9.0x | OOM | OOM | 6.7x | | 1440p | OOM | OOM | OOM | OOM | OOM | OOM | ### 感度分析（cli3） - **CPU スレッド数:** 8G VRAM・16K コンテキストで CPU スレッドを 1 から 16 に増やすと、qwen30b の TPS は 10.3 から 24.0 へ向上。ベースラインは大きな変化を示さない。パイプラインシャーディングは CPU スレッドを効果的に活用する。 - **PCIe 世代:** BIOS 設定で PCIe Gen3（16 GBps）から Gen5（64 GBps）へ変更すると、16K コンテキスト・8G VRAM で TTFT 高速化が 1.2 倍から 2.4 倍へほぼ倍増。重みストリーミングの高速化が直接反映される。 ## 設計上の知見（Lessons Learned） 1. **ロスレス推論:** クライアント AI 開発者からの初期フィードバックで、SKU をまたいだ高精度モデルのロスレス推論の重要性が確認され、量子化など非可逆手法ではなくパイプラインシャーディングの方向性を選択した。 2. **競合考慮プロファイリング:** PCIe のみ・CPU のみのプロファイルでは、メモリコントローラの共有競合を見落とし、ハイブリッドスケジュールの精度が低下する。競合下でのプロファイリングにより推定精度が向上した。 3. **トークンティアベースの汎化スケジューラ:** 高トークン数ではコンピュート支配で全処理をアクセラレータに集約し、低トークン数では帯域幅支配で分散処理がよい。トークンティアごとにスケジュールを切り替える設計は、インタラクティブ・バッチ双方を一貫して最適化する。 4. **均質スケジューリング単位:** アテンション-FFN 境界でサブレイヤーを切り出し、算術強度が均質な単位で優先度付きバックエンド割り当てを行うことで、密結合・MoE 双方に有効。 5. **拡張性:** プロファイル・プラン・推論の分離設計により、新カーネル・新スケジュール・新モデルをプラグイン可能。 ## 結論 - パイプラインシャーディングと VLMOpt により、VRAM 制約下のクライアント xLM 推論が実用水準に到達する。llama.cpp への C++ 実装としてオープンソース化され、ACM Artifact Evaluation の 3 バッジを取得した。 - インタラクティブモードで VRAM フットプリント最大 39 倍削減・TPS 最大 30 倍高速化、バッチモードで最大 8.2 倍のスループット向上を実証。CR1 の VRAM 需要を vLLM ベースライン比 10 分の 1 に低減し、クライアントでの高解像度物理 AI を実現する。 - NVIDIA IGI SDK と Cosmos-Reason1 への統合を対象としており、ゲーム開発者・物理 AI 開発者の双方に恩恵をもたらす。