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
| file | size | BPW | 4GB card | 8GB card | 12GB+ card |
|---|---|---|---|---|---|
Spark-X2.5-1.7B-Q8_0.gguf | 1.7 GB | 8.50 | 128K ctx | 1M ctx | 1M ctx |
Spark-X2.5-1.7B-Q6_K.gguf | 1.4 GB | 6.56 | 256K ctx | 1M ctx | 1M ctx |
Spark-X2.5-1.7B-Q4_K_M.gguf | 1.1 GB | 5.16 | 256K ctx | 1M ctx | 1M ctx |
Spark-X2.5-1.7B-IQ4_XS.gguf | 1.0 GB | 4.74 | 256K+ ctx | 1M ctx | 1M ctx |
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)
| quant | PPL | delta vs Q8_0 |
|---|---|---|
| Q8_0 | 3.854 | - |
| Q6_K | 3.855 | +0.001 (noise) |
| Q4_K_M | 4.093 | +6.2% |
| IQ4_XS | 4.081 | +5.9% |
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)
| quant | prefill tok/s | decode tok/s | TTFT ms |
|---|---|---|---|
| Q8_0 | 7856 | 149.6 | 71.9 |
| Q6_K | 6819 | 166.4 | 81.1 |
| Q4_K_M | 7289 | 206.1 | 75.1 |
| IQ4_XS | 7951 | 207.3 | 69.2 |
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
- Importance matrix computed with
llama-imatrixon 200 chunks of an 8 MB calibration corpus (system documentation, Python sources, technical prose), from the BF16 GGUF. - Uniform quants:
Q8_0/Q6_K/Q4_K_M/IQ4_XSpasses with--imatrix. - Each variant validated with
llama-perplexityon 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.
| result | score | notes |
|---|---|---|
| effective pass | 5/6 | hb2-eval-007 counted as miss: work completed correctly via the execute_code tool, but the grader requires the code_execution toolset name |
- 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.