DGX Sparkにおけるメモリチューニングとベンチマーク

DGX Sparkが備える 128GB規模のユニファイドメモリプールは、最大の強みであると同時にチューニングの難点でもあります。個別のGPUの場合はVRAMが固定されシステムRAMとは分離されていますが、Grace CPUとBlackwell GPUは同一のメモリプールを共有します。このためメモリが枯渇すると、適切なメモリ不足エラーが発生する代わりにシステムが応答不能状態になってしまうのです。本ページではメモリがどのように消費されるか、KVキャッシュの適切なサイズ設定法、そしてワークロードに合わせたvLLMパラメーターの調整法を説明します。

How unified memory works on GB10

DGX Spark uses NVIDIA’s GB10 chip, which combines a Grace ARM CPU and a Blackwell GPU on one package. They share 128GB of LPDDR5X memory over a 273 GB/s interconnect. 専用のVRAMは存在しません。vLLMが「GPUメモリ」として割り当てる領域も、DGX OSやCUDAランタイム、その他のアプリケーションが利用する同一の 128GBプール内の一部に過ぎません。つまり以下のような特性が生じます。

gpu_memory_utilizationは全体プールの一部を制御するだけであり、専用のGPUメモリ枠を確保するわけではない。
システムプロセスも同じメモリ領域を争う形になる。DGX OSやバックグラウンドサービス、CUDAコンテキストのオーバーヘッドもモデルが利用可能なメモリ量を減少させる要因となる。
メモリ不足時の強制終了機能が存在しない。プールが枯渇すると、問題のプロセスが強制終了されるのではなくシステム全体がフリーズしてしまう。

現実的なメモリ予算の目安は次の通りです。

割り当て内容	一般的なサイズ
DGX OSおよびシステムサービス	4から6ギガバイト
CUDAランタイムおよびコンテキスト	2から3ギガバイト
vLLM用CUDAグラフ	3から5ギガバイト
モデルおよびKVキャッシュでも利用可能	約115ギガバイト

KV cache overhead on 128GB

KVキャッシュには、アクティブなすべてのシーケンス内の各トークンに対応するキー・値テンソルが保存される。そのサイズは 3 の要素によって増大する。具体的にはコンテキスト長、同時に処理されるシーケンス数、そしてモデルのアーキテクチャ（レイヤー数やKVヘッド数）である。

計算式

特定のコンテキスト長における単一シーケンス用として：

KV cache per sequence = 2 × layers × KV_heads × head_dim × context_length × bytes_per_element

The factor of 2 accounts for both keys and values.

例：さまざまなコンテキスト長における70B型の密なモデル

一般的な70Bモデルで層数が80、KVヘッド数が8、ヘッド次元が128だと仮定すると：

コンテキスト長	KVキャッシュ（FP16形式）	KVキャッシュ（FP8形式）	備考
4K個のトークン	約5.2ギガバイト	約2.6ギガバイト	単一ユーザー利用には十分な容量です
8K トークン	約10.5 GB	約5.2 GB	複数ユーザー利用時の推奨上限値
16K トークン	約21 GB	約10.5 GB	厳しい制限 — 同時に利用可能なのは 1 から 2 人のみ
32K トークン	約42 GB	約21 GB	Single user only on 128GB

FP8形式のKVキャッシュを利用してメモリ使用量を半減させることが可能です。vLLMの起動コマンド内で --kv-cache-dtype fp8 を設定してください。ほとんどのベンチマークにおいて品質への影響は 2% 未満であり、同時に処理可能なシーケンス数やコンテキスト長も実質的に倍増します。

例：35B形式のMoEモデル

MoE models have the same KV cache math as dense models for their total layer count. A 35B MoE model with ~64 layers at the same KV head configuration:

コンテキスト長	KVキャッシュ（FP16形式）	KVキャッシュ（FP8形式）
8K個のトークン	約4.2ギガバイト	約2.1ギガバイト
32K個のトークン	約16.8ギガバイト	約8.4ギガバイト
128K 個のトークン	約67.2 GB	約33.6 GB

At 35B MoE with NVFP4 weights (~18 GB), you can fit 128K context with FP8 KV cache and still have ~65 GB of headroom.

コンテキスト長とバッチサイズのトレードオフ

アクティブな各シーケンスにおけるすべてのコンテキストトークンがKVキャッシュメモリを消費します。全体のKVキャッシュ容量は以下の通りです。

Total KV cache = KV per sequence × max_num_seqs × max_model_len / sequence_length

実際には、DGX Sparkにおけるこのトレードオフは次のようになります。

優先度	利用可能な設定としては	ただしその代償として
長いコンテキスト（32K以上）	1から2までの同時接続ユーザー数	負荷時のスループット
高い同時接続数（10人以上のユーザー）	短いコンテキスト長（4Kから8K程度）	文書全体を扱うタスク
バランスが取れている（5人のユーザー、8K程度のコンテキスト長）	どちらにも適している	どちらかの極端な状況でもない

For a 70B dense model at NVFP4 (~35 GB weights, ~75 GB remaining for KV cache):

`max_num_seqs`	`max_model_len`	FP16形式のKVキャッシュでも収まるか？	FP8形式のKVキャッシュでも収まるか？
5	4096	はい（約26ギガバイトで収まる）	はい（約13ギガバイトで収まる）
5	8192	タイトな設定（約52ギガバイト）	はい（約26ギガバイト）
10	4096	タイトな設定（約52ギガバイト）	はい（約26ギガバイト）
10	8192	いいえ（約105ギガバイト）	タイトな設定（約52ギガバイト）

実際のベンチマークとNVIDIAの主張との比較

NVIDIAがDGX Sparkについて公表した 82,739 トークン/秒 という数値は、複数ユーザーでのファインチューニング時の総スループットを示したものであり、単一ユーザーでの推論性能を示すものではありません。実際のインタラクティブなサービング時の数値は以下の通りです：

モデル	量子化方式	トークン/秒（単一ユーザー）	トークン/秒（5ユーザー同時利用時）	備考
Qwen3.5-35B-A3B	NVFP4（vLLM）	47-50	測定不可	持続的動作；TTFTは0.12秒
Qwen3.6-35B-A3B	NVFP4（Atlas）	~120	測定不可	2.8x 標準の vLLM エンジンで、最適化済み
Qwen3.5-122B-A10B	NVFP4（vLLM）	~30	測定不可	Breaks under 100K concurrent load
70B個の高密度処理	NVFP4（vLLM）	15-20	最大で約5から10人までのユーザー利用が可能	KVキャッシュの容量によって同時処理数が制限される
Qwen3-32B	Q4_K_M（Ollama）	9-44	測定されていない	設定内容によって性能差が大きく現れる

ここで示されている 82,739トークン/秒という数値は、複数の微調整処理が並行して行われた際の総合的なスループットを表している。単一ユーザー向けの対話型推論は別のワークロードであり、モデル規模やエンジンによって 15から120トークン/秒程度の速度が見込まれる。これでもリアルタイムのチャットやコーディングエージェント利用には十分な速さだ。

メモリ保護機能：システムのフリーズを防ぐ

DGX Sparkにおいて最も重要なチューニングパラメーターは --gpu-memory-utilizationである。この値を高く設定しすぎると復旧不可能なエラーでシステムがフリーズしてしまう。控えめな値に設定すればKVキャッシュの余裕が減少する。

推奨される初期値

モデルのサイズ	`gpu_memory_utilization`	設定理由
≤35B（MoEまたは通常モデル）	0.90	十分な余裕があり、重みファイルのサイズも小さい
70Bの通常モデル	0.85	システムやKVキャッシュのオーバーフロー用に約15GBを確保しておくこと
120BのMoEモデル	0.85	重みファイル単体で約60GBを消費するため、予備容量を残しておく必要がある
どのモデルでも長いコンテキストに対応可能	0.80	大容量のKVキャッシュ用に余分な安全マージンを設ける

DGX Sparkでは絶対にgpu_memory_utilizationを0.90より大きく設定してはいけません。 個別のGPUとは異なり、統合メモリが枯渇するとシステム全体が応答不能になります。復旧には強制電源リセットが必要になります。まずは控えめな値から始め、実際のワークロード下で安定性が確認できてから増やしていくようにしてください。

メモリ使用状況をリアルタイムで監視する

別のターミナルを開き、サービス実行中のメモリ使用量を確認してください：

watch -n 1 "nvidia-smi --query-gpu=memory.used,memory.free,memory.total --format=csv"

もし memory.free の値が 2 から 3 GB未満まで下がると、システムがフリーズする恐れがあります。その場合は max_model_len、max_num_seqs、または gpu_memory_utilization の値を減らしてください。

各パラメーターの調整に関する参考情報

DGX Sparkにおいて最も影響力の大きい vLLM フラグを、影響度の高い順に示します：

パラメーター	制御対象の内容	DGX Sparkでの推奨設定
`--gpu-memory-utilization`	vLLM が利用可能なメモリの割合	0.80-0.90; never above 0.90
`--max-model-len`	最大シーケンス長	8192は70B以降のバージョン用です。32768は35BのMoE用となります。
`--max-num-seqs`	同時に処理可能なシーケンス数の上限	5から10までが適切な値で、70Bの場合はこれより高く設定する必要がある。35BのMoEモデルではさらに高い値が求められる
`--kv-cache-dtype`	KVキャッシュの精度	`fp8`を使用してKVキャッシュのメモリ使用量を半減させる
`--swap-space`	削除されたシーケンス用のCPUスワップ領域（単位：ギガバイト）	0 on DGX Spark — swapping to shared memory hurts
`--quantization`	重みの量子化処理	`nvfp4` is recommended for SM121
`--enable-prefix-caching`	複数のプロンプト間でKVキャッシュを共有する機能	同一のシステムプロンプトが繰り返し使用される場合に有効化する設定

決定表：一般的な設定例

利用シナリオ	`gpu_memory_utilization`	`max_model_len`	`max_num_seqs`	`kv_cache_dtype`
35B MoE方式、シングルユーザー向け、長いコンテキスト対応	0.90	32768	1	`auto`
35B MoE方式、5名のユーザー対応、8Kのコンテキスト長	0.90	8192	5	`fp8`
70B 高密度型モデル、シングルユーザー向け	0.85	8192	1	`fp8`
70B 高密度型モデル、5名のユーザー対応	0.85	4096	5	`fp8`
120B MoE方式、シングルユーザー向け	0.85	8192	1	`fp8`

チューニングの手順例

シングルユーザー向けのスループットを最大化する方法

vllm serve nvidia/Qwen3.5-35B-A3B-NVFP4 \
  --quantization nvfp4 \
  --gpu-memory-utilization 0.90 \
  --max-model-len 32768 \
  --max-num-seqs 1 \
  --enable-prefix-caching

Maximize concurrent users for 70B

vllm serve <your-70b-model> \
  --quantization nvfp4 \
  --gpu-memory-utilization 0.85 \
  --max-model-len 4096 \
  --max-num-seqs 10 \
  --kv-cache-dtype fp8

大規模モデル用の最も安全な設定例

vllm serve <your-120b-moe-model> \
  --quantization nvfp4 \
  --gpu-memory-utilization 0.80 \
  --max-model-len 8192 \
  --max-num-seqs 1 \
  --kv-cache-dtype fp8 \
  --swap-space 0

次に行うべき手順

DGX Spark上でのvLLMの利用方法

各モデルサイズごとのインストールおよび起動コマンド一覧

モデルの互換性について

どのモデルが128GBのメモリ容量に対応しており、どのような量子化オプションが利用可能か。

スパークを一つ使用する場合と二つ使用する場合の違い

メモリ調整だけでは不十分で、第二のスパークが必要になるケースについて

KVキャッシュの基本概念について

各種モデルアーキテクチャにおけるKVキャッシュの仕組みに関する詳細な解説

ハードウェアと互換性

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

クライアント接続

比較

DGX Sparkにおけるメモリチューニングとベンチマーク

How unified memory works on GB10

KV cache overhead on 128GB

計算式

例：さまざまなコンテキスト長における70B型の密なモデル

例：35B形式のMoEモデル

コンテキスト長とバッチサイズのトレードオフ

実際のベンチマークとNVIDIAの主張との比較

メモリ保護機能：システムのフリーズを防ぐ

推奨される初期値

メモリ使用状況をリアルタイムで監視する

各パラメーターの調整に関する参考情報

決定表：一般的な設定例

チューニングの手順例

シングルユーザー向けのスループットを最大化する方法

Maximize concurrent users for 70B

大規模モデル用の最も安全な設定例

次に行うべき手順

DGX Spark上でのvLLMの利用方法

モデルの互換性について

スパークを一つ使用する場合と二つ使用する場合の違い

KVキャッシュの基本概念について

​How unified memory works on GB10

​KV cache overhead on 128GB

​計算式

​例：さまざまなコンテキスト長における70B型の密なモデル

​例：35B形式のMoEモデル

​コンテキスト長とバッチサイズのトレードオフ

​実際のベンチマークとNVIDIAの主張との比較

​メモリ保護機能：システムのフリーズを防ぐ

​推奨される初期値

​メモリ使用状況をリアルタイムで監視する

​各パラメーターの調整に関する参考情報

​決定表：一般的な設定例

​チューニングの手順例

​シングルユーザー向けのスループットを最大化する方法

​Maximize concurrent users for 70B

​大規模モデル用の最も安全な設定例

​次に行うべき手順

DGX Spark上でのvLLMの利用方法

モデルの互換性について

スパークを一つ使用する場合と二つ使用する場合の違い

KVキャッシュの基本概念について

How unified memory works on GB10

KV cache overhead on 128GB

計算式

例：さまざまなコンテキスト長における70B型の密なモデル

例：35B形式のMoEモデル

コンテキスト長とバッチサイズのトレードオフ

実際のベンチマークとNVIDIAの主張との比較

メモリ保護機能：システムのフリーズを防ぐ

推奨される初期値

メモリ使用状況をリアルタイムで監視する

各パラメーターの調整に関する参考情報

決定表：一般的な設定例

チューニングの手順例

シングルユーザー向けのスループットを最大化する方法

Maximize concurrent users for 70B

大規模モデル用の最も安全な設定例

次に行うべき手順