For DGX Spark (GB10) owners: a vLLM alternative to GGUF with the native DSpark speculative head - ~10 tok/s, 256K ctx, tool calling

#22
by wiklif - opened

Great to see 0731 GGUFs here - for anyone running them on a single DGX Spark class box (GB10, 128GB unified memory), I want to share a complementary path I got working and published: serving this model from the original checkpoint through a vLLM-based stack, with things the GGUF route currently cannot use.

https://github.com/lrozewicz/vLLM-Moet-GB10

It builds on vLLM-Moet (2-bit expert planes + an FP4 tier that recovers quality where 2-bit loses it), adapted for unified memory and sm_121. What you get over a plain Q2 GGUF setup:

  • the model's built-in DSpark speculative head (the extra 20B in this checkpoint that llama.cpp does not use): ~9.8 tok/s decode on a single GB10 (k=2; heads-up - the model card's k=7 is actually slower on this hardware, 5.1 tok/s)
  • 256K context served (KV pool ~660K tokens thanks to MLA + the compression ladder)
  • an OpenAI-compatible server with working DSML tool calling (--tool-call-parser=deepseek_v4) and a per-request thinking toggle with split reasoning - drop-in backend for coding agents
  • first boot ~35 min (one-time quantization), later boots ~10 min via a persistent cache

The README documents the unified-memory pitfalls that make this non-obvious on GB10 (pinned host staging blowing past 121 GiB, misleading memory metrics, etc.), each with the measurement behind it.

Not a replacement for GGUF - llama.cpp remains the simpler route - but if you have a Spark and want the speculative head, long context and agent tooling, this is reproducible end to end. Feedback welcome.

Sign up or log in to comment