darioooooo0o/Spark-X2.5-1.7B-GGUF

Spark-X2.5-1.7B Community Quants (imatrix GGUF)


Requests, questions or suggestions? Message me on X: https://x.com/imdariotoo

Community GGUF quantizations of XHToken/Spark-X2.5-1.7B, a 1.7B hybrid-attention (3:1 sliding-window:full) model with native 1M context. Quantized with an importance matrix, targeting fully GPU-resident inference from 4GB cards up.

Unlike larger models in this family, the 1.7B is small enough that no lossy layer-mixes are needed: even a 4GB card fits Q80 at 128K context or Q6K at 256K. Card tiering is done with context length instead of precision cuts.

Why no layer-aware mixes (unlike the 4B)

The 4B quants needed layer-aware mixes at 8GB/4GB because the VRAM budget forced FFN tensors below Q4. The 1.7B has 28 layers with only 7 full-attention layers (2 KV heads x 256 dim), so its KV cache is ~4.0 KB/token at q4_0 - a third of the 4B's. The budget never forces sub-Q4 weights, and the 4B experiments showed mixes only help when forced. So these are clean uniform quants.

Available quants

Context figures assume q40 KV cache, ~1.0 GB CUDA/compute overhead, one slot, `-ngl 99`, flash attention on. The 1M native context actually fits on an 8GB card: Q80 weights (1.8 GB) + 1M-token q4_0 KV (4.2 GB) + overhead = ~7 GB.

Measured quality (perplexity, calibration corpus, 512 ctx, CUDA, RTX 3060 12GB)

IQ4XS measures slightly better than Q4K_M despite being smaller - it is the best pick under 1 GB.

Measured speed (RTX 3060 12GB, llama.cpp XHToken fork, p512/n128, -ngl 99, -fa on, f16 KV, 3 reps)

Roughly 3.5x the decode throughput of the 4B quants on the same card.

Tool-calling verification (safetensors on vLLM 0.28 + Spark-plugin)

The base safetensors was verified for agentic use before quantization: simple tool calls, complex nested/array schemas, multi-turn tool-result loops, 3 parallel tool calls in a single response, and Hermes-style schemas with enums - all passed with clean finish_reason: tool_calls and valid JSON arguments. Decode 81.5 tok/s at 32K ctx on vLLM.

Serve with vLLM (requires XHToken/Spark-plugin) or the XHToken/llama.cpp fork for these GGUFs (the spark2_5 architecture is not in upstream llama.cpp).

Quantization method

1. 1.Importance matrix computed with llama-imatrix on 200 chunks of an 8 MB calibration corpus (system documentation, Python sources, technical prose), from the BF16 GGUF.
2. 2.Uniform quants: Q8_0 / Q6_K / Q4_K_M / IQ4_XS passes with --imatrix.
3. 3.Each variant validated with llama-perplexity on the same corpus, sequentially on one RTX 3060 12GB.

Recommended launch (llama.cpp)

llama-server \
  -m Spark-X2.5-1.7B-Q4_K_M.gguf \
  --chat-template-file chat_template.jinja \
  -c 262144 -ngl 99 -fa auto \
  -ctk q4_0 -ctv q4_0 \
  --temp 1.0 --top-p 0.95 --top-k -1 \
  --jinja --reasoning-format deepseek

Sampling per the model card: temperature 1.0, topp 0.95, topk -1. Thinking mode on by default; <tool_call>/<arg_key>/<arg_value> tool-call format handled by llama.cpp's auto parser.

Known model limitation: reasoning loops on open-ended prompts

This is a model-level behavior, not a quantization artifact - it reproduces identically on unquantized BF16 with f16 KV cache. On vague open-ended comparative questions (e.g. "from 10 euros, which currency would today give me the most paper notes in their smallest denomination"), the model can enter an unbounded reasoning loop: it generates thinking tokens until the generation limit with empty visible content. Observed across Q4KM + q40 KV, Q80 + f16 KV, Q6_K + f16 KV, BF16, temp 1.0 and 0.6, with and without tools.

Mitigations:

• —set a server-side reasoning budget: --reasoning-budget 2000
• —use agent timeouts / stall detection for unattended runs
• —rephrasing prompts to be more concrete reduces (but does not eliminate) the risk
• —simple factual, math, and tool-concrete prompts are unaffected

Agentic tool-use reliability (HermesBench 6-task subset, Q4KM, RTX 3060 12GB, 64K+ ctx)

Run through a real Hermes Agent harness: file/terminal, memory, todo, codeexecution, sessionsearch, and cronjob tool classes, graded on task correctness AND use of the required tool classes.

• —All tasks: raw_task_score = 1.0 (correct work), zero false-dones, zero timeouts
• —Tool classes exercised: searchfiles, readfile, writefile, terminal, memory (+honcho), todo, sessionsearch, cronjob, execute_code
• —Median task wall: ~21s; slowest 61s (memory task with 11 tool calls)

Known model limitation (documented below) applies mainly to open-ended research-style prompts; tool-concrete tasks like these complete reliably.

License

Apache 2.0, matching the base model. Quantizations are derivative works of XHToken/Spark-X2.5-1.7B.