Quick verdict
One DGX Spark runs dense models up to ~70B at Q4 and MoE models up to ~120B total parameters at NVFP4. MoE models are the better fit because only a fraction of their parameters activate per token, giving you higher throughput for the same memory footprint.How the 128GB gets used
DGX Spark does not have discrete VRAM. The Grace CPU and Blackwell GPU share a single 128GB memory pool over a 273 GB/s interconnect. When you load a model, 3 things consume that pool:- Model weights — the largest fixed cost, determined by parameter count and quantization.
- KV cache — grows with context length and concurrent requests. See DGX Spark memory tuning for sizing math.
- System and CUDA overhead — typically 4-8 GB for DGX OS, CUDA runtime, and vLLM’s CUDA graphs.
DeepSeek-V4-Flash-0731 does not fit on 1 Spark. 2 Sparks provide enough aggregate memory to shard its published 162–167 GB weight floor, but published dual-Spark evidence is community-tested and needs 0731 revalidation. Start at 32K–128K context and read DeepSeek V4 Flash local hardware before configuring a cluster.Dense model compatibility
Dense models activate every parameter for every token. That means weight memory and compute scale linearly with parameter count — a 70B dense model needs roughly twice the memory and twice the FLOPs of a 35B dense model. On DGX Spark, dense models work up to 70B at 4-bit quantization, but concurrency is limited by KV cache pressure.Dense model caveats on unified memory
- ChatGPT-OSS-20B on Ollama reports 89% GPU usage but unacceptable latency. Community recommendation: switch to vLLM or SGLang for this model.
- Qwen3.6-27B at NVFP4 is estimated to achieve 40–55 tok/s for a single user, based on similar dense models in the 27–32B range. The wide spread reflects differences in quantization backend and flash attention settings. With ~14–15 GB for weights, you have ample room for long context on a single Spark.
- 70B dense モデルは正常に動作するが、単一のSpark上で利用可能なdenseアーキテクチャの実用的な上限値となっている。重みデータのメモリ消費ではなく、同時リクエストごとのKVキャッシュがボトルネックなのである。
- For dense models above 70B, you need a two-Spark cluster. See One vs two DGX Sparks.
MoEモデルの互換性
MoEモデルはDGX Sparkに最適な選択肢です。すべてのエキスパートの重みがメモリに読み込まれますが、各トークンごとに活性化するのはその一部のみです。そのため、大規模モデルと同等の能力を、小規模モデル並みの計算コストで実現できるのです。Gemma-4-26B-A4B-it fails on DGX Spark because vLLM’s
gpu_memory_utilization parameter is not respected during startup profiling on unified memory (SM121). The system becomes unresponsive. The workaround is to use NVFP4 quantization explicitly, but community reports indicate the fix is still incomplete as of mid-2026. Track vLLM issue #46307 for updates.MoEのパフォーマンスに関する注意点
- Qwen3.5-35B-A3B at NVFP4 achieves 47-50 tok/s sustained for a single user. Time-to-first-token drops from 3 seconds (Ollama) to 0.12 seconds with vLLM.
- Qwen3.6-35B-A3B は、標準の vLLM を使用した場合でも単一ユーザー向けに 47～50 トークン/秒の速度を維持できます。一方、Atlas エンジン（純粋な Rust/CUDA 実装）では最大で約 120 トークン/秒という驚異的な速度を実現し、これは標準の vLLM よりも 2.8x 倍速いことになります。さらに、最大で 1M トークン分のコンテキストも処理可能です。
- Qwen3.5-122B-A10B は、JSON-KIEタスクにおいて約30トークン毎秒の速度を維持し、100%という高いMTP受諾率を実現します。しかし100K件もの同時リクエストが発生すると処理が破綻してしまいます。
- GLM-4.5-Air は、106B個のMoE構成下で 12B個のパラメータが有効化されており、コミュニティからはSpark向けの最適なモデルとして広く評価されています。メモリ使用量の面でも適切なサイズを維持しています。
GLM-4.6 （合計357B個／現在使用中は32B個）は、単体のDGX Sparkには収まりません。
Q4クラスの量子化を行う場合、必要なメモリ量は約178ギガバイトにもなり、これは128ギガバイトという統合メモリプールの容量をはるかに超えてしまいます。128ギガバイトのハードウェアをご利用の場合は、代わりにGLM-4.5-Airをお使いください。各バリエーションの比較詳細については、GLMファミリーをご参照ください。Quantization format comparison on SM121
DGX Sparkに搭載されているブラックウェルGPUはSM121アーキテクチャを採用しています。すべての量子化フォーマットがネイティブでサポートされているわけではありません。コンテキスト長の制限
コンテキスト長はKVキャッシュが消費するメモリ量に直接的な影響を与え、その結果モデル重み用に利用可能なメモリが減少します。DGX Sparkのユニファイドメモリにおいては、KVキャッシュに使われるすべてのバイトは重みやCUDAランタイム、OSが使用するメモリと同じ 128GBのプールから割り当てられます。
FP8形式のKVキャッシュ（
--kv-cache-dtype fp8）を利用すると、品質への影響は2%未満に抑えつつこれらの数値が半減し、実質的に処理可能なコンテキスト量が倍増します。
KVキャッシュのサイズ計算や調整パラメーターについては、DGX Sparkメモリ調整をご参照ください。
DGX Spark上でのKimi K3の利用
Kimi K3 does not fit on any practical DGX Spark cluster. The model’s 2.8T total parameters (~50B active per token through Stable LatentMoE) need about 1.4 TB at the native MXFP4 precision. Eight DGX Sparks pool 1 TB and still fall 376 GB short. NVIDIA documents Spark clusters up to 4 nodes (512 GB), and Moonshot recommends a supernode with 64 or more accelerators for K3. For the full calculation, see the Kimi K3 hardware deep dive. For Spark today, the models that fit are in the tables above — up to ~70B dense at Q4 and ~120B MoE at NVFP4 on a single node. See what to run instead of Kimi K3 for the best pick at each Spark count.Qwen3.8の実現可能性
The Qwen3.8 flagship shipped in August 2026 as Qwen3.8-2.4T-A95B: a Mixture-of-Experts model with 2.4 trillion total parameters and 95B active per token, text-only, released under Qwen’s customqwen3.8-max license. The generation also includes Qwen3.8-27B (released 2026-08-14, Apache-2.0), a dense vision-language model that does fit a single Spark — see the verdict below the cluster math.
量子化レベルごとのメモリ要件
重みのみを対象としたメモリ計算（KVキャッシュ、CUDAグラフ、システムオーバーヘッドを除く）：
Even at the most aggressive quantization, a single DGX Spark cannot run Qwen3.8-2.4T-A95B. This is a multi-node model that requires at least 10 Sparks at Q4 — and realistically 20+ Sparks at FP8 for reasonable KV cache headroom.
マルチノードクラスターのサイズ設定
ランタイムのサポート状況
Qwen社は2.4Tウェイトと共に、vLLM、SGLang、TokenSpeed向けのサービング設定例を公開しています。一方でllama.cpp、Ollama、LM Studioへの対応状況はまだ記載されていません。このモデルが採用するハイブリッド型のGated DeltaNetおよびGated Attentionアーキテクチャのため、GGUF形式でのサービス提供を実現するには専用のカーネル開発が必要となります。The Qwen3.8 that fits one Spark
Qwen3.8-27B is the single-machine member of the generation: a dense27B vision-language model released 2026-08-14 under Apache-2.0. Every official precision fits one Spark — 55.6 GB BF16 outright, and the official 30.9 GB FP8 build leaves roughly 90 GB of the 128 GB pool for KV cache. Serve it through vLLM or SGLang; no GGUF or NVFP4 build exists yet. Full sizing is on the Qwen3.8 model page; tested Spark configurations will be added here once verified.
GLM-5.2の実現可能性
アクティブなパラメータ数でMoEモデルのサイズを判断してはならない
有効なパラメーターはトークンごとの計算量に影響を与えるだけで、常駐する重みの下限値には影響しません。GLM-5.2は合計で753B個のパラメーターを保持しており（Hugging Faceによると 753,329,940,480個が 78層全体に分散し、各トークン処理時に 8個の 256個ある専門家コンポーネントが有効化され、さらに 1個の共有パラメーターも存在します）、したがって重みごとに実際に存在する最小ビット数は正確に 4ビットとなります：
7 GBギガバイトが消費されるため実用には至らない。4台のSparkを512ギガバイト構成にした場合が初めて実用的な余裕を持つ構成となる。FP8精度で運用する場合は重みデータだけで753 GBギガバイトが必要となり、オーバーヘッド分を考慮しても6台のSparkが必要となる。
用途別に推奨されるモデル
モデルを選択したか？ それをコネクターに接続しよう
DGX Sparkのデプロイに向けて、
https://api.tokios.comという認証済みエンドポイントを設定してください。受信用ポートは不要で、所要時間は約5分です。速度とモデルサイズのどちらを優先するかを決める
DGX Sparkにおける根本的なトレードオフは、モデルの能力とスループットの間に存在します：- If speed matters most (coding agents, interactive chat): Pick a 35B MoE model at NVFP4. You get 47-50 tok/s (or 120 tok/s with Atlas), which feels instant.
- 品質を最優先したい場合（複雑な推論や研究用途）：利用可能な中で最も大規模なモデル、つまり Qwen3.5-122B-A10B または GLM-4.5-Air を選択し、25-30 トークン毎秒程度の速度を受け入れるべきです。
- 並列処理が最優先事項である場合（チームでのサービング用途）：35B MoEを利用し続け、FP8 KVキャッシュを活用することで同時接続可能なユーザー数を最大化できます。詳細な計算式については DGX Sparkメモリチューニング をご参照ください。
ご使用のスパークで互換性を確認してください
コミュニティで共有されているベンチマーク結果は参考になりますが、ご使用のDGX OSのバージョンやCUDAドライバー、vLLMのビルド内容によっては挙動が異なる可能性があります。モデルを採用する前に、以下の確認作業を実施してください：-
起動前にメモリを確認する：
-
控えめな設定でモデルを起動する：
-
Increase
max-model-lenincrementally until you hit your target context or memory pressure. -
推論時の監視：
-
ベンチマークスループット:
gpu_memory_utilizationの値を0.05だけ減らしてください。
Tokiosを利用してご自身のモデルを提供しましょう
DGX Spark上でvLLM、Ollama、またはllama.cppを用いてモデルを実行したら、受信ポートを開放することなく、認証機能付きの単一エンドポイント経由でそのモデルを公開できます。TokiosコネクターがSparkから外部へ接続し、https://api.tokios.comという場所にOpenAIおよびAnthropic互換のAPIを提供します。
完全なセットアップ手順については DGX Sparkをプライベートエンドポイントに設定する をご覧ください。または モデルを登録する ページへ進んで、ローカルのアップストリームモデルIDをデプロイ名にマッピングすることも可能です。
DGX Spark上でのvLLMの利用
各モデルサイズに合わせてNVFP4設定を適用し、vLLMを段階的にデプロイする手順。
DGX Sparkのメモリ調整方法
KV cache sizing, batch trade-offs, and tuning parameters for 128GB.
One vs two DGX Sparks
When to scale to a second Spark for distributed inference and models that exceed 1 node.
量子化の概念
どのフォーマットを選ぶべきか判断する前に、NVFP4、AWQ、FP8、そしてGGUFについて理解しておきましょう。