---

license: apache-2.0

base_model:

• XHToken/Spark-X2.5-1.7B

tags:

• sparkx2_5
• gguf
• quantized
• llama.cpp
• imatrix

pipeline_tag: text-generation

---

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

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.

| 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.