Large MoE models on several DGX Sparks: Kimi K3, DeepSeek V4, GLM-5.3 and MiniMax M3 on 1, 2, 4 and 8 nodes

As of 7 November 2026, the largest open-weight models do not fit a DGX Spark cluster at the precision they ship in: Kimi K3 and K3.1 Pro (2.8T parameters, about 1.5 TB of MXFP4 weights) would need about 16 Sparks by my calculation and Qwen3.8-2.4T in FP8 about 24; only 1- and 2-bit GGUFs bring them inside 8, and I found no such run. DeepSeek-V4-Pro-0813 (about 850 GB) sits right at the limit of 8. The models that do run are one size down: owners report DeepSeek-V4.1-Flash-1017 at 125 tok/s single-stream on 8 Sparks and 132 tok/s on 4 (code, with speculative decoding), and GLM-5.3-Flash in NVFP4 at up to 39 tok/s on 2.

Checked on Hugging Face 7 November 2026: the Kimi, DeepSeek, GLM and MiniMax repos are public and not gated. Parameter counts from the model cards (Kimi, DeepSeek V4-Pro, Qwen, MiniMax) or the Hugging Face size field (GLM-5.3, V4.1-Flash, which Unsloth lists as 748B; Hugging Face shows 763B). Weight sizes are my sums of the per-dtype tensor counts in the Hugging Face API, cross-checked against repo storage and Unsloth's GGUF sizes; Hugging Face counts two parameters per byte for packed 4-bit tensors. Active parameters for GLM-5.3-Flash are from the NVIDIA forum thread title "320B total parameters, 18B active". "Smallest cluster" uses the 105 GB-per-Spark budget explained below.

Which of the newest large models have open weights?

All the families the question usually names: Kimi K3.x, DeepSeek V4.x, GLM-5.x and MiniMax M3.x are downloadable today, plus Qwen3.8-2.4T and Nemotron 3 Ultra. Moonshot's newest repo, Kimi-K3.1-Pro, appeared on 2 November 2026 with the same 2.8T total and 104B active as Kimi K3, swapping its Gated MLA layers for Gated DeepSeek Sparse Attention. Both ship MXFP4 weights trained with quantization-aware training, and Moonshot has published no BF16 or smaller official build.

The licenses differ more than the architectures. DeepSeek V4.x and GLM-5.3-Flash are MIT. The Kimi K3 License requires a separate agreement before you sell model inference to third parties if your revenue exceeds $20 million over 12 months, and a visible "Kimi K3" label above 100 million monthly users or $20 million monthly revenue; internal use is exempt. The MiniMax M3 license asks commercial users to send MiniMax a one-time notice, to show "Built with MiniMax M3", and to get written authorization above $20 million yearly revenue; unlike MiniMax's H3 video model, it excludes no territories. I did not read the GLM-5.3 and Qwen3.8-max license texts. The open-weight license guide compares them in detail.

How do you work out how many Sparks a model needs?

Divide the weight size at the precision you will run by about 105 GB per Spark, and round up to a cluster size your engine can split across. Total parameters set this number; active parameters only set the speed.

Why 105 GB: GPUwerk's models page puts addressable memory at 121.6 GiB (about 130 GB), and owners in the GLM-5.3-Flash thread report 116.5 to 117 GiB free before launch. Leaving room for the KV cache, activations and the OS, the largest weights reported working are about 100 GB per node: 204 GB of GLM-5.3-Flash NVFP4 on 2 Sparks, and 77.7 GB per node of DeepSeek-V4.1-Flash on 4. So 1 Spark holds about 105 GB of weights, 2 about 210, 4 about 420 and 8 about 840.

Worked example, DeepSeek-V4-Pro-0813. The Hugging Face API lists 1,623.5B parameters as packed int8, 24.0B as FP8 and 3.0B as BF16. That is 811.7 + 24.0 + 5.9 = about 842 GB, and Unsloth's 4-bit GGUF is 850 GB. Divided by 105, both come to just over 8 Sparks, before any KV cache. The only other quant Unsloth lists for it is 873 GB. On 8 Sparks this model would run with almost no context; I would not plan on it until a 2- or 3-bit build appears.

Engines split the model across nodes with tensor parallelism (TP=2, 4 or 8), sometimes combined with expert parallelism; that is why 3, 5 or 6 nodes are rare in reports. llama.cpp's RPC mode pools memory but adds little speed, as the two-Spark cluster guide explains. Four or more Sparks need a 200 GbE switch or a switchless ring; cabling and switch choices for 4 and 8 nodes are in the guide to DGX Spark clusters beyond two nodes.

How many Sparks does each model need at each quant?

My calculation, weights only, read 7 November 2026. Cluster sizes are rounded up to 1, 2, 4 or 8. A 1-bit GGUF that fits is not a recommendation: the quantization guide explains why quality drops below 4 bits. DeepSeek-V4.1-Flash's Engram memory tables can stay on disk, which is how the 4-node report below fits; the 1-Spark and 2-Spark reports also rely on that or on sub-3-bit weights. Unsloth's own note for V4.1-Flash is 128 GB of RAM for the 1-bit build and 256 GB for 3-bit, which assumes CPU offload rather than a GPU-resident cluster.

What speeds are reported on 2, 4 and 8 Sparks?

For DeepSeek-V4.1-Flash, 54 to 132 tok/s single-stream; for GLM-5.3-Flash, 21 to 64 on one node and up to 39 on two. Every report below comes from an owner on the NVIDIA developer forum, most use speculative decoding, and code prompts accept more drafted tokens than prose, which is why each row has two numbers.

Read 7 November 2026. Speculative decoding is on in most rows; the SparkFlash author says it accounts for almost all of the 4-node single-stream result (about 5.7 tokens per step on code, 3 on prose) and gave no figure with it off. Replies in that thread dispute the engine's attribution and its throughput design. The 4-node DeepSeek-V4-Flash post gives both a server-side and a much lower client-side figure. The 8-node vLLM run capped output at 256 tokens. The two-Spark DeepSeek-V4-Flash and Qwen3.5-397B results are in the two-node guide and the DeepSeek-V4-Flash notes.

What I could not find: any run on Sparks of Kimi K3 or K3.1 Pro, DeepSeek-V4-Pro, the full GLM-5.3, MiniMax M3 or M3.1-Flash, Nemotron 3 Ultra or Qwen3.8-2.4T. I read the first three topic pages of the NVIDIA forum's DGX Spark category and the Kimi K3 discussions on Hugging Face. The one official multi-node entry I found is NVIDIA's VLM NIM support matrix, which lists GLM-5.3-Flash in NVFP4 on two GB10 nodes with 208 GB of disk.

Does adding Sparks make one user faster?

From 2 to 4, yes; from 4 to 8, mostly no, on the evidence so far. Tensor parallelism lets each node read only its share of the active weights per token, so the bandwidth ceiling grows with the node count; each layer then exchanges activations over a 200 Gb/s link, which eats into that.

The reports fit that shape. DeepSeek-V4-Flash went from about 44 tok/s on 2 Sparks to about 70 on 4 (server-side). DeepSeek-V4.1-Flash reached 131.8 tok/s on code with 4 nodes and 125.2 with 8, on different engines, so the eighth node bought concurrency (804.6 tok/s aggregate at 16 requests) rather than single-user speed.

For the models nobody has run yet, a ceiling helps set expectations. Kimi K3 activates 104B parameters per token; at MXFP4, about 0.53 bytes each with scales, that is about 55 GB read per token. Sixteen Sparks read 16 x 273 = 4,368 GB/s in total, so the ceiling is about 79 tok/s before communication costs and before speculative decoding. DeepSeek-V4-Pro's 49B active at its FP4/FP8 mix is roughly 27 GB per token, a ceiling near 80 tok/s on 8 Sparks. Real engines on this hardware land well below such ceilings; these are my estimates, not measurements.

The GGUF route is slower again. Unsloth's 1- and 2-bit builds of Kimi K3 and Qwen3.8-2.4T need its llama.cpp fork, and llama.cpp spreads a model over several machines through RPC, which hands each node whole layers in turn; one user then gets roughly one node's bandwidth. Kimi K3 at UD-IQ2_XXS averages about 0.26 bytes per parameter (711 GB over 2.78T), so 104B active is about 27 GB per token and the single-user ceiling is near 273 / 27 = 10 tok/s, however many Sparks hold the layers.

Can one Spark run these models by streaming from NVMe?

Technically yes, at single-digit tok/s. A forum user ran NVIDIA's 404 GB DeepSeek-V4.1-Flash-1017 NVFP4 checkpoint on one 128 GB GB10 by memory-mapping it and keeping hot experts in the page cache; with all 384 experts active it decodes at 2.3 to 2.6 tok/s, and the 14 to 17 tok/s figure from a pruned 144-expert mode is, by the author's own description, a kernel benchmark only (NVIDIA forum, 5 November 2026). Kimi K3 has been run the same way on a 128 GB MacBook Pro at about 1 tok/s, streaming 1.44 TB of 4-bit routed experts from four SSDs (Hugging Face discussion #185). Useful for a demo, not for work.

The aggressive one-node quants carry their own warning. The 2.05 bpw GLM-5.3-Flash thread is full of replies about loops, crashes and corrupt shards, and one reproduction measured 21.2 tok/s against the headline 64. For one Spark, GPUwerk's own GLM-5.3-Flash configuration note describes the 2-bit and 1-bit GGUF trade-off.

Which model should you run on 1, 2, 4 or 8 Sparks?

On one Spark, none of these at full quality; pick from the models that fit 128 GB instead. On two Sparks, GLM-5.3-Flash in NVIDIA's NVFP4 build is my pick: 4-bit weights, an official NIM configuration for exactly this layout, and 27 to 39 tok/s reported. DeepSeek-V4-Flash at its official FP8 is the alternative, at about 44 tok/s. On four Sparks, DeepSeek-V4.1-Flash-1017 with its Engram tables on disk, which owners report at 86 to 132 tok/s. On eight, the same model for many concurrent users, or GLM-5.3 at FP8 if you need the larger model and can accept untested territory. At their shipped precision, Kimi K3, Qwen3.8-2.4T and DeepSeek-V4-Pro are not Spark models in November 2026; their 1- and 2-bit GGUFs fit 8 Sparks but, by the estimate above, around 10 tok/s for one user and at an untested quality cost. They belong on datacenter GPU clusters, and a Kimi K3 deployment thread on Hugging Face puts that model at about 1,750 GB of GPU memory.

Before buying four or eight boxes, rent a cabled pair at $1.79 per hour (see pricing) and check that the two-node version of your model does what you need.

FAQ

Sources

Every figure above is attributed to its source in the sentence or table where it appears. Pages were read on 7 November 2026 unless a date says otherwise.

• moonshotai/Kimi-K3 model card, Hugging Face
• moonshotai/Kimi-K3.1-Pro model card, Hugging Face, 2026-11-05
• Kimi K3 License, Hugging Face (moonshotai)
• Kimi K3 (2.78T) running on a 128 GB MacBook Pro at ~1 tok/s, experts streamed from four SSDs, Hugging Face discussion #185
• Deploy guide & hardware requirements for Kimi-K3, Hugging Face discussion #180
• deepseek-ai/DeepSeek-V4-Pro model card, Hugging Face
• deepseek-ai/DeepSeek-V4-Pro-0813 model card, Hugging Face, 2026-08-13
• unsloth/DeepSeek-V4-Pro-0813-GGUF, Hugging Face
• deepseek-ai/DeepSeek-V4.1-Flash-1017 model card, Hugging Face, 2026-10-17
• unsloth/DeepSeek-V4.1-Flash-1017-GGUF, Hugging Face
• zai-org/GLM-5.3 model card, Hugging Face
• unsloth/Kimi-K3-GGUF, Hugging Face
• unsloth/Qwen3.8-2.4T-A95B-GGUF, Hugging Face
• unsloth/MiniMax-M3-GGUF, Hugging Face
• unsloth/GLM-5.3-GGUF, Hugging Face
• MiniMaxAI/MiniMax-M3.1-Flash model card, Hugging Face, 2026-11-05
• MiniMax M3 license, Hugging Face (MiniMaxAI)
• unsloth/MiniMax-M3.1-Flash-GGUF, Hugging Face
• Qwen/Qwen3.8-2.4T-A95B model card, Hugging Face
• DeepSeek V4.1 Flash on 8x DGX Spark: TP8/EP8 concurrency results, NVIDIA Developer Forums, 2026-11-07
• Native Rust + CUDA engine for DeepSeek-V4.1-Flash on 4x Sparks, NVIDIA Developer Forums, 2026-10-29
• DeepSeek-V4.1-Flash-1017 (EXL3 2.9bpw) on 2x DGX Spark with TensorFold, NVIDIA Developer Forums, 2026-10-18
• Optimizing nvidia/GLM-5.3-Flash-NVFP4 for 2x DGX Spark (forum thread), NVIDIA Developer Forums, 2026-09-12
• 60 tok/s GLM-5.3 Flash on a single DGX Spark, NVIDIA Developer Forums, 2026-09-03
• DeepSeek-V4-Flash official FP8 across DGX Sparks, post 174 (4 nodes, TP=4), NVIDIA Developer Forums, 2026-06-03
• Qwen3.5-397B-A17B-int4-AutoRound - 4 x db10 node - updated results 37 - 94 tok/s, NVIDIA Developer Forums, 2026-03-04
• Running nvidia/DeepSeek-V4.1-Flash-1017-NVFP4 on a single 128 GB GB10, NVIDIA Developer Forums, 2026-11-05
• Support Matrix, NVIDIA NIM for Vision Language Models, NVIDIA Docs, 2026-09-30