NVIDIA DGX Spark上でvLLMをインストールおよび設定する

vLLM with NVFP4 quantization is the best-performing general-purpose serving path on DGX Spark. It gives you an OpenAI-compatible /v1 endpoint, native SM121 support, and the throughput numbers the community reports — 47-50 tok/s on Qwen3.5-35B-A3B, 15-20 tok/s on 70B dense, and ~30 tok/s on 120B MoE. This page walks you through installation, first launch, and the settings that matter.

Alternative engines. Some community members report better results with SGLang on specific model configurations, and the Atlas engine claims 2.8x over stock vLLM for Qwen3.6-35B-A3B. This page covers stock vLLM because it has the broadest model support and the most documented configuration surface.

前提条件

作業を始める前に、ご使用のDGX Sparkが以下の要件を満たしていることを確認してください。

OS: DGX OS（UbuntuベースのLinux aarch64）
CUDA: 13.0 or later — CUDA 12 libraries fail on SM121
Python: 3.10以降（pipインストール用）またはARM64対応のDocker環境
メモリ： 128 GBの統合型メモリ（すべてのDGX Spark／GB10ユニットにおいて既定値）

CUDAのバージョンを確認するには：

nvcc --version

GPUが正しく認識されているか確認してください。

nvidia-smi

GB10 Blackwell GPUが表示され、そのメモリ容量が 128 GBと報告されていることを確認できます。

DGX Sparkでは CUDA 13.0 のみが利用可能です。SM121アーキテクチャはCUDA 12ライブラリをサポートしていません。もし nvcc --version の表示内容が CUDA 12.xとなっている場合、続行する前にDGX OSのパッケージを更新してください。

vLLMをインストールします。

pipを使ってvLLMをインストールします。

DGX OS上で最も簡単な方法は直接pipインストールを行うことです。vLLMにはGrace CPUでも利用可能なARM64用のパッケージが同梃されています。

pip install vllm

最新のNVFP4やSM121関連の修正内容を含むナイトリービルドが必要な場合は以下の手順に従ってください。

pip install --pre vllm --extra-index-url https://wheels.vllm.ai/nightly

あるいはDockerイメージを取得します。

コンテナベースのデプロイを希望する場合は、ARM64互換のイメージを取得してください。

docker pull vllm/vllm-openai:latest

GPUアクセス権限付きで実行します。

docker run --gpus all -it --rm -p 8000:8000 vllm/vllm-openai:latest

インストールが正しく行われたか確認します。

vLLMが起動し、GPUを正しく検出できることを確認してください。

python -c "import vllm; print(vllm.__version__)"

ここでバージョン番号が出力され、CUDA関連のエラーが出なければデプロイ準備は整ったことになる。

最初のモデルを起動する

まずは 35B サイズのMoEモデルから始めましょう。処理速度が速く、十分にテスト済みで、メモリにも余裕があります。

vllm serve nvidia/Qwen3.5-35B-A3B-NVFP4 \
  --quantization nvfp4 \
  --gpu-memory-utilization 0.90 \
  --max-model-len 32768

これで http://127.0.0.1:8000 上にOpenAI互換のサーバーが起動します。試してみましょう：

curl http://127.0.0.1:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "nvidia/Qwen3.5-35B-A3B-NVFP4",
    "messages": [{"role": "user", "content": "Hello"}],
    "max_tokens": 64
  }'

数秒以内に応答が得られ、最初のトークンが返ってくるまでの時間はおよそ 0.12 秒程度になるはずです。

モデルサイズごとの最適設定

The 3 settings that matter most on DGX Spark are --gpu-memory-utilization, --max-model-len, and --quantization. Here are tested starting points:

モデルサイズ	`gpu_memory_utilization`	`max_model_len`	`quantization`	期待されるトークン生成速度（tok/s）
35B MoE	0.90	32768	`nvfp4`	47-50
70B ディンシィ	0.85	8192	`nvfp4`	15-20
120B MoE	0.85	8192	`nvfp4`	25-30

35B MoEモデル（Qwen3.5-35B-A3B、Qwen3.6-35B-A3B）

vllm serve nvidia/Qwen3.5-35B-A3B-NVFP4 \
  --quantization nvfp4 \
  --gpu-memory-utilization 0.90 \
  --max-model-len 32768

35B MoEモデルでは重み情報に約18ギガバイトしか使用されず、KVキャッシュ用に十分な領域が確保されます。より長いコンテキストが必要な場合はmax-model-lenの値を引き上げることも可能です。

70B ディンクスモデル

vllm serve <your-70b-model> \
  --quantization nvfp4 \
  --gpu-memory-utilization 0.85 \
  --max-model-len 8192

70B dense models use ~35 GB for weights at NVFP4. Keep max-model-len at 8192 to leave room for KV cache across concurrent requests. Community reports show multi-user concurrency is limited to 5-10 users at this size.

120B MoEモデル（Qwen3.5-122B-A10B、Nemotron-3-Super-120B）

vllm serve <your-120b-moe-model> \
  --quantization nvfp4 \
  --gpu-memory-utilization 0.85 \
  --max-model-len 8192

120B MoEモデルでは重み情報に約60ギガバイトが使用されます。8192というコンテキスト制限によりKVキャッシュの管理も容易になります。単一ユーザーでの推論時には約30トークン毎秒の速度が見込まれます。

メモリ調整の詳細、すなわちKVキャッシュのサイズ設定やバッチサイズの最適化、そして--kv-cache-dtype fp8については DGX Spark メモリ調整をご参照ください。

NVFP4用の設定例

NVFP4はDGX Spark向けに推奨される量子化方式です。SM121上でネイティブに動作し、品質への影響を最小限に抑えつつサイズを75%削減できます。

事前に量子化済みのモデルを利用する

NVIDIAがHugging Face上で公開しているNVFP4用チェックポイントは、nvidia/という接頭辞を付けたものをご使用ください。

vllm serve nvidia/Qwen3.5-35B-A3B-NVFP4 --quantization nvfp4

読み込み時のオンライン量子化処理

事前に量子化済みのチェックポイントが存在しない場合、vLLMはBF16モデルから即座に量子化処理を行うことが可能だ：

vllm serve <model-path> --quantization nvfp4

この方法では読み込みに時間がかかる（モデルをメモリ上で先に量子化する必要があるため）が、vLLMがサポートするどのモデルアーキテクチャにも対応する。

SGLangの利用も検討可能

コミュニティメンバーの中には、特定のDGX Sparkワークロード向けに標準のvLLMよりもSGLangを推奨する者もいる。SGLangは同じCUDA 13.0スタック上で動作し、同じモデルフォーマットを利用する。

python -m sglang.launch_server --model-path <model> --port 8000

特定のモデルにおいてvLLMの既定設定では処理能力が満足できない場合はSGLangの導入を検討してほしい。設定項目は異なるため、DGX Spark専用のフラグについてはSGLangの公式ドキュメントを参照されたい。

ARM64およびSM121環境における注意点

DGX Sparkに搭載されたGrace CPU（ARM64）およびBlackwell GPU（SM121）には、実際に利用する前に把握しておくべきプラットフォーム固有の問題がいくつか存在する。

問題点	現象	対処法
CUDA 12ライブラリ	インポートエラーやカーネル起動失敗	CUDA 13.0のみを使用し、DGX OSも更新すること
NIMコンテナが正常に動作しない	ARM環境においてコンテナが終了するかエラーが発生する 64	NIMコンテナの代わりに直接vLLMを利用すること
エラーメッセージが出ないままメモリ不足が発生する	CUDAメモリ不足エラーが出る代わりにシステムが応答しなくなる	Cap `gpu_memory_utilization` at 0.85-0.90; see memory tuning
Gemma-4 `gpu_memory_utilization`	起動時のプロファイリング処理でパラメータが無視され、システムがフリーズする	Use NVFP4 quantization explicitly; track vLLM #46307

DGX SparkではCUDAメモリ不足エラーが出る代わりにシステムが応答しなくなる。 統合メモリを備えたシステムにおいて、モデルとKVキャッシュの合計サイズが利用可能なメモリを超えると、システムは正常にエラーを返すのではなくフリーズしてしまう。常に慎重な値からgpu_memory_utilizationを設定し（大規模モデルでは0.85程度が適切）、安定性を確認した上で値を増やしていくこと

ご自身の環境でベンチマークを実施すること

起動後、簡易ベンチマークを実行してスループットを確認してください。

python -m vllm.entrypoints.openai.api_server \
  --model nvidia/Qwen3.5-35B-A3B-NVFP4 \
  --quantization nvfp4 \
  --gpu-memory-utilization 0.90 \
  --max-model-len 32768 &

# Wait for the server to start, then:
python -m vllm.benchmarks.benchmark_serving \
  --model nvidia/Qwen3.5-35B-A3B-NVFP4 \
  --num-prompts 10 \
  --request-rate 1

得られた結果を上記の設定表に記載された期待値と比較してください。スループットが著しく低い場合は、CUDA 13.0が有効化されているか、他のプロセスがGPUメモリを消費していないかを確認してください。サービス稼働中はメモリ使用量を常時監視してください。

watch -n 1 nvidia-smi

Tokiosを利用してエンドポイントを公開します。

Spark上のvLLMによりローカルな /v1エンドポイントが利用可能になります。SSHトンネルやポート開放なしでノートパソコンやコーディングエージェント、チームメンバーからアクセスするには、vLLMと並行してTokiosコネクターを実行してください。

Spark上でvLLMを起動します。

上記の手順通りにモデルを起動し、http://127.0.0.1:8000/v1で正しく応答することを確認してください。

コネクターをインストールし、ペアリング処理を行います。

In the Tokios dashboard, open Setup and select Start pairing to get a claim code. On the Spark:

curl -fsSL https://tokios.com/downloads/install/linux | sh -s -- --code TKS-XXXX-XXXX

デプロイ設定を登録します。

On the Models tab, map your vLLM model id to a deployment name. Clients use the deployment name, not the upstream model id.

クライアント設定例については、DGX Spark利用ケースガイドをご参照ください。

モデルの互換性について

どのモデルが128ギガバイトの範囲内に収まり、どの程度のスループットが見込めるかを確認してください。

メモリの最適化

本番環境向けのKVキャッシュのサイズ設定やFP8形式のKVキャッシュ、各種パラメータの調整方法について説明します。

vLLMのリモートアクセス

DGX Spark以外でのvLLMのリモートアクセス手法について解説します。

One vs two Sparks

Scale to 405B models with a second Spark and tensor parallelism.

ハードウェアと互換性

サービングとランタイム接続

クライアント接続

比較

NVIDIA DGX Spark上でvLLMをインストールおよび設定する

前提条件

vLLMをインストールします。

最初のモデルを起動する

モデルサイズごとの最適設定

35B MoEモデル（Qwen3.5-35B-A3B、Qwen3.6-35B-A3B）

70B ディンクスモデル

120B MoEモデル（Qwen3.5-122B-A10B、Nemotron-3-Super-120B）

NVFP4用の設定例

事前に量子化済みのモデルを利用する

読み込み時のオンライン量子化処理

SGLangの利用も検討可能

ARM64およびSM121環境における注意点

ご自身の環境でベンチマークを実施すること

Tokiosを利用してエンドポイントを公開します。

モデルの互換性について

メモリの最適化

vLLMのリモートアクセス

One vs two Sparks

​前提条件

​vLLMをインストールします。

​最初のモデルを起動する

​モデルサイズごとの最適設定

​35B MoEモデル（Qwen3.5-35B-A3B、Qwen3.6-35B-A3B）

​70B ディンクスモデル

​120B MoEモデル（Qwen3.5-122B-A10B、Nemotron-3-Super-120B）

​NVFP4用の設定例

​事前に量子化済みのモデルを利用する

​読み込み時のオンライン量子化処理

​SGLangの利用も検討可能

​ARM64およびSM121環境における注意点

​ご自身の環境でベンチマークを実施すること

​Tokiosを利用してエンドポイントを公開します。

モデルの互換性について

メモリの最適化

vLLMのリモートアクセス

One vs two Sparks

前提条件

vLLMをインストールします。

最初のモデルを起動する

モデルサイズごとの最適設定

35B MoEモデル（Qwen3.5-35B-A3B、Qwen3.6-35B-A3B）

70B ディンクスモデル

120B MoEモデル（Qwen3.5-122B-A10B、Nemotron-3-Super-120B）

NVFP4用の設定例

事前に量子化済みのモデルを利用する

読み込み時のオンライン量子化処理

SGLangの利用も検討可能

ARM64およびSM121環境における注意点

ご自身の環境でベンチマークを実施すること

Tokiosを利用してエンドポイントを公開します。