2026-06-07 — 回閲覧
vLLM 公式 DGX Spark ガイド：なぜ 120B NVFP4 モデルのデコードが約 23 tok/s なのか、そしてそれが帯域幅律速のローカル推論について教えること
2026 年 6 月 1 日、vLLM プロジェクトは NVIDIA の DGX Spark（GB10 Grace Blackwell、sm_121、128 GB 統合メモリ）上で vLLM を実行する公式ガイドを公開した。vllm/vllm-openai:cu130-nightly コンテナから Nemotron-3-Super-120B-A12B-NVFP4 を提供し、デコード 22.7-23.7 tok/s、プリフィル最大約
何がリリースされたか
2026 年 6 月 1 日、vLLM プロジェクトは NVIDIA の DGX Spark 上で vLLM を実行する公式の手順解説を公開した。DGX Spark は、128 GB の統合 LPDDR5X メモリとコンシューマー Blackwell の sm_121 計算能力を備えた、デスクサイド型の GB10 Grace Blackwell 機器である。「起動できた」という大半のフォーラム投稿とは異なり、この記事はテスト済みのデプロイレシピと実際のローカル評価を組み合わせており、シングルボックス推論の経済性をどう考えるかの参考資料としても機能する。
目玉のワークロードは Nemotron-3-Super-120B-A12B-NVFP4 である：総計 120B パラメータ、混合エキスパート（MoE）構成で 1 トークンあたり約 12B がアクティブ、NVFP4 に量子化されている。この組み合わせこそがこの試みの全要点だ。BF16 の 120B 密モデルは到底収まらないが、約 12B のアクティブパラメータを持つ NVFP4 MoE は 128 GB に余裕で収まり、1 トークンあたりその重みのごく一部をストリーミングするだけで済む。
報告された数字
vllm/vllm-openai:cu130-nightly コンテナ（CUDA 13）から、--gpu-memory-utilization 0.85、--max-model-len 131072、--max-num-seqs 4 で提供し、この記事は以下を測定した：
| 指標 | 報告された範囲 |
|---|---|
| デコードスループット | 22.7-23.7 tok/s |
| プリフィルスループット | ~140 tok/s（58-tok プロンプト）から ~1,884 tok/s（7,234-tok プロンプト） |
| 最初のトークンまでの時間 | 0.42 s（短）から ~3.85 s（長） |
| KV キャッシュ使用率 | シングルユーザーで 5% 未満；小バッチで 30% 未満 |
2 点が際立つ。第一に、KV キャッシュ占有率はごくわずかであり、128 GB はほぼ全てコンテキストではなく重みに費やされている。第二に、プリフィルはプロンプト長に応じてスケールするが、デコードは何があっても約 23 tok/s で横ばいである。あの平坦なデコードの線こそが手がかりだ。
なぜデコードは平坦なのか：算力ではなく帯域幅
構造的な教訓はメモリバスにある。GB10 は 256-bit LPDDR5X インターフェース（8,533 MT/s）で 273 GB/s でデータを移動する — H100 の ~3.35 TB/s HBM3 より約 12 倍遅い。自己回帰デコードは 1 トークンあたり一度アクティブな重みを読み込むため、低バッチではテンソルコアはほとんどメモリ待ちで遊んでいる。独立した分解レポートも同じ点を率直に指摘している：273 GB/s では、どれだけ算力を投入しても 35 GB のモデルは理論上約 7.8 tok/s が上限である。
これが、NVFP4 がデータセンターカード上よりもここで重要となる理由でもある。重みを 16 bytes/param（BF16）から約 4.5 bytes/param に削減すると、1 トークンあたりに移動するバイト数が半減し、帯域幅律速のマシンではデコードスループットがほぼ倍増する。エコシステムで出回っているある比較では、同じ Nemotron 3 Super が NVFP4 ビルドで約 38 tok/s であるのに対し、Q4_K_M GGUF では約 19.5 tok/s となっている — 同じモデルで、変数はフォーマットとカーネルパスである。（vLLM 記事自身の ~23 tok/s は、その特定の 131K コンテキスト構成とコンテナを反映しているため、ソース間の数字は完全な比較ではなく方向性のあるものとして扱うこと。）
実務的な位置づけ
この記事は、その適用範囲について爽やかなほど正直だ：DGX Spark は「ローカルのシングルユーザーまたは小バッチ推論の対象として見るのが最良」である。意図的に --max-num-seqs 4 で実行している；並行度をさらに上げるとレイテンシを犠牲にすることになる。なぜなら、すでに算力ではなく帯域幅が枯渇しているからだ。ConnectX ファブリック上のマルチ Spark 構成は言及されているが、この記事では明示的に評価されていない。
統合メモリアーキテクチャは静かな立役者である。CPU と GPU が一つの物理 128 GB プールを共有するため、重みと KV キャッシュは PCIe をまたぐ cudaMemcpy の往復なしに常駐する — HBM と比べて生の帯域幅は失うが、コピーのコストを省ける。これこそが、120B クラスのモデルがデスクトップ上で存在できる理由である。
実務者への注記： 100-130B の NVFP4 MoE 向けにシングルボックスのローカルサーバーを仕様策定するなら、データセンター級のスループットではなく、約 20-40 tok/s のデコードと低い max-num-seqs を前提に期待値を設定すること。実際に実行するコンテナ／CUDA の組み合わせを検証すること（ここでの公式パスは cu130-nightly イメージとモデル固有の推論パーサーである）；異なるコンテキスト、量子化カーネル、または提供スタックの下で公開されたデコード速度はきれいには転用できず、初期の重みロードだけでも 10-15 分かかることがある。
十分に考慮されていない観点： ほぼ全ての DGX Spark ベンチマークの見出しはシングルストリームのデコード数字であり、これは MoE モデルを良く見せる — 1 トークンあたり約 10% のパラメータしか移動しないからだ。この機器が小規模チームにとって使えるかどうかを実際に予測する指標は、現実的な KV フットプリント下での並行デコードである。KV キャッシュ使用率が 5% 未満では、システムは最も弱いリソースをほとんど動かしていない；興味深く（そしてほとんど未公開の）問いは、273 GB/s のバス上でバッチを上げたときのスループット対レイテンシ曲線である。なぜなら、そこがデスクサイドの統合メモリ機器が数名の同時利用者に耐えるか、厳密に一人用のツールへと崩れ落ちるかの分かれ目だからだ。