DGX Spark上のvLLM：アーキテクチャ、構成、ローカル評価

vLLMはNVIDIA DGX Spark上で高速かつ効率的なローカル推論を実現し、ラップトップ規模の開発とデータセンターのGPUサービスとのギャップを埋めます。OpenAI互換APIと高度なメモリ、バッチング、テレメトリ制御を組み合わせることで、vLLMは開発者がDGX Sparkの独自ハードウェアアーキテクチャ上で大規模NVFP4モデルをローカルに実行できるようにします。

DGX Sparkのアーキテクチャとメモリモデル

NVIDIA DGX SparkはGB10 Grace Blackwell SoCを中心に構築されており、CPUとGPUの統合メモリプールを利用しています。このアーキテクチャは、推論ワークロードの構成と実行方法に大きな影響を与えます。

統合メモリとモデル容量

共有されたCPU/GPUメモリプールにより、固定された専用GPUメモリプールでは不可能だった大規模なNVFP4モデルをロードできます。これにより、モデルのアーキテクチャとランタイム設定に応じて、単一のSpark上で最大2000億パラメータのモデルを実行することが実用的になります。vLLMは --gpu-memory-utilization、--max-model-len、--max-num-seqs といったフラグと、ページングされたKVキャッシュを組み合わせて、モデルサイズ、コンテキスト長、同時実行性のバランスを取ります。

ハードウェア固有の検証

DGX Spark上でのデプロイは、sm_121 ターゲット向けに検証されたvLLMビルド、コンテナイメージタグ、ランタイム設定を使用しなければなりません。大規模GPUシステムから移植した構成は、パフォーマンスベンチマークではなく、カーネルサポートのエンジニアリングチェックリストとして扱うべきです。

NVFP4 MoE最適化

DGX SparkはNVFP4 Mixture-of-Experts（MoE）サービングに特に適しています。NVFP4はメモリ圧迫を軽減し、プレフィル動作を改善します。約100億〜150億のアクティブパラメータを持つMoEモデルは、アクティブパラメータが少ないことでシステムのメモリ帯域幅上のデコード性能が最適化されるため、非常に適合します。

ローカルサービング向けvLLMの機能

ページングKVキャッシュと連続バッチング

チャットワークロードにおける静的バッチングの非効率を回避するため、vLLMは連続バッチングを用いて各デコードステップでリクエストの受け入れと除去を行います。ページングKVキャッシュと組み合わせることで、DGX Sparkは過度なメモリ断片化なしに複数のインフライトリクエストをサポートできます。120B NVFP4 MoEモデルでのテストでは、単一ユーザーでKVキャッシュ使用率は通常5％未満、小規模バッチデモトラフィックでも30％未満に抑えられました。

OpenAI互換ストリーミング

Spark上のvLLMエンドポイントはOpenAI互換API（例：http://localhost:8000/v1）を使用しており、既存のクライアントコードを再利用できます。stream=true の使用はローカルでの応答性に不可欠で、トークンが到着次第レンダリングすることで、チャット、コーディング、エージェントワークフローにおける知覚遅延を最小化します。

Prometheusによる可観測性

vLLMのPrometheusエンドポイント（/metrics）により、開発者はローカルアプライアンスの状態を監視できます。DGX Sparkにおける主要な指標は以下です：

• KVキャッシュ使用率 (vllm:kv_cache_usage_perc)
• プロンプトおよび生成トークンカウンタ
• TTFT（最初のトークンまでの時間）とトークン間レイテンシヒストグラム

ランタイム構成とデプロイ

DGX Sparkでの成功するデプロイには、ランタイムフラグをシステムの統合メモリプロファイルおよび特定のモデルレシピに合わせる必要があります。

モデル選択の指針

モデルの選択はパフォーマンスの主要なレバーです。100〜130BのMoE NVFP4モデルで、10〜15Bのアクティブパラメータを持つものが、Sparkのメモリ容量とデコード速度に最も効率的に適合します。

重要な vllm serve フラグ

• --gpu-memory-utilization：OS、コンテナランタイム、KVキャッシュの増大のために統合メモリプールに余裕を残すよう調整する必要があります。
• --max-model-len 131072：最大プロンプトおよび生成長を設定します。vLLMは各リクエストごとに全長を予約するのではなく、アクティブコンテキストに基づいてスケジューリングします。
• --max-num-seqs 4：同時デコードストリーム数を抑えて、トークンごとの帯域幅負荷がTTFTを急上昇させるのを防ぎます。
• 自動プレフィックスキャッシュ：vLLM V1でデフォルト有効になっており、オープニングプロンプトを共有するリクエスト間でKVブロックを再利用します。長いシステムプロンプトに対して非常に有益です。

JIT事前ウォーミングとロード

コールドスタートのレイテンシは重要な要素です。起動後の最初のリクエストでInductorとFlashInferのJITコード生成がトリガーされ、Nemotron-3-Superでは約25秒かかります。開発者は起動時に小さな「ping」リクエストを送ってカーネルをウォームアップすべきです。また、初回の重みロードには10〜15分かかりますが、fastsafetensors や InstantTensor といったパスを検討すれば時間短縮が可能です。

ローカル評価結果：Nemotron-3-Super

Nemotron-3-Super-120B-A12B-NVFP4 モデルを単一のDGX Sparkで評価した結果、さまざまなシナリオでデコードスループットが 22.7〜23.7 トークン/秒 の範囲で一貫していることが示されました。

シナリオ	プロンプトトークン	生成トークン	TTFT	総レイテンシ	プレフィルトークン/秒	デコードトークン/秒
典型的なジャッジ呼び出し	58	2	0.42 s	~0.53 s	140	~23
中程度のプロンプト、短い生成	1,834	32	1.12 s	1.12 s	1,636	23.7
長いプロンプト、短い生成	7,234	32	3.85 s	~5.26 s	1,877	22.7
中程度のプロンプト、長い生成	1,834	108	1.12 s	~5.74 s	1,639	23.4
長いプロンプト、長い生成	7,234	124	3.84 s	~9.26 s	1,884	22.9

主なパフォーマンス洞察

• プレフィルスケーリング：プロンプトが大きくなるにつれてプレフィルスループットが増加し、140 からほぼ 1,900 トークン/秒に達します。オーバーヘッドがより多くのトークンに分散されるためです。
• デコードの安定性：デコードスループットはプロンプト長に関係なく安定しており、アクティブパラメータ数とFP4カーネルパスによって決まります。
• TTFT：プロンプトサイズが4倍になると、最初のトークンまでの時間は約3倍になります。

運用サマリー

DGX Spark上でvLLMを最適化するには、開発者は100〜130BのMoE NVFP4モデルを優先し、sm_121 用に検証された公式vLLMイメージを使用し、統合メモリプールに合わせて --gpu-memory-utilization を調整すべきです。JITの事前ウォーミングと /metrics エンドポイントの活用により、予測可能でインタラクティブなローカル推論体験が保証されます。