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 Q8_0 at 128K context or Q6_K 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 q4_0 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: Q8_0 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)

IQ4_XS measures slightly better than Q4_K_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. 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. Uniform quants: Q8_0 / Q6_K / Q4_K_M / IQ4_XS passes with --imatrix.
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, top_p 0.95, top_k -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 Q4_K_M + q4_0 KV, Q8_0 + 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, Q4_K_M, RTX 3060 12GB, 64K+ ctx)

Run through a real Hermes Agent harness: file/terminal, memory, todo, code_execution, session_search, 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: search_files, read_file, write_file, terminal, memory (+honcho), todo, session_search, 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.