eaddario/Spark-X2.5-4B-GGUF

Experimental global target bits‑per‑weight quantization of XHToken/Spark-X2.5-4B

Using non-standard (forked) LLaMA C++ release b11529 for quantization.

Original model: XHToken/Spark-X2.5-4B

From the original model creators:

Introduction

We are introducing Spark-X2.5-4B and Spark-X2.5-1.7B, two compact, general-purpose language models designed to make capable AI more practical, efficient, and accessible. The models deliver strong performance across a broad range of everyday tasks—including conversation, writing, translation, reasoning, coding, tool use, and agentic workflows—achieving leading results among open-source models of comparable size. Spark-X2.5 combines an efficiency-oriented architecture with native context windows of up to 1M tokens, and support for more than 200 languages.

Technical Highlights:

• Efficient Architecture and Native 1M-token Context: The models use a hybrid attention architecture that combines one full-attention layer with three sliding-window attention layers. This design substantially reduces the computational overhead typically associated with long-context models while natively supporting a context window of up to 1M tokens.
• Strong Coding and Agent Capabilities: The models are deeply integrated with popular agent harnesses, including Codex, Claude Code, OpenClaw, and Hermes. They deliver state-of-the-art performance among models of comparable size across everyday coding, agentic workflows, reasoning, and instruction-following tasks.
• Broad Hardware and Software Compatibility: The models support a wide range of hardware platforms, including NVIDIA, Huawei, Hygon, HOUMO.AI, etc. It is compatible with leading inference frameworks such as vLLM, SGLang, llama.cpp, MLX, and can be deployed quickly through platforms including Ollama and LM Studio. The models can also be customized using popular fine-tuning frameworks such as LLaMA-Factory. Across multiple hardware platforms, they deliver superior TTFT, TOPT, and overall inference efficiency compared with similarly sized models.
• Advanced Training Algorithms: The models were trained on Huawei Ascend clusters. Large-scale reinforcement learning and post-training techniques such as MOPD significantly enhance its reasoning, coding, agentic, and instruction-following capabilities.

---

⚠️ PLEASE READ THIS BEFORE USING THESE EXPERIMENTAL VERSIONS! ⚠️

An area of personal interest is finding ways to optimize the inference performance of LLMs when deployed in resource-constrained environments like commodity hardware, desktops, laptops, mobiles, edge devices, etc. There are many approaches to accomplish this, including architecture simplification and knowledge distillation, but my focus has been primarily on quantization and pruning.

The method to produce these experimental versions involves using a custom version of llama-imatrix to generate an imatrix that includes tensor statistics, and a custom version of llama-quantize, which computes a per-tensor quantization error, to automatically select the lowest error quantization recipe that achieves a global target bits‑per‑weight (bpw). More details on the implementation and test results here

There are two pull requests (#14891 & #15550) to merge these changes back into the core llama.cpp project. This may or may not ever happen so, until then, the modified versions will be available on GitHub.

For testing and comparison, I use models produced by Bartowski (see credits below) and Unsloth (Daniel and Michael Han do some really interesting stuff!) but when they don't provide versions of the required model, tests and comparisons are against standard quantization obtained by simply running llama-quantize with no further optimizations.

All experimental versions were generated using an appropriate imatrix created from datasets available at eaddario/imatrix-calibration. In llama.cpp, an imatrix is a calibration file derived from running representative text through the model and collecting activation statistics. It is used to weight quantization error so that error in more “important” directions (as estimated from activations) is penalized more heavily.

The process to generate these models is roughly as follows:

1. Convert the original model's safetensors to GGUF F16
2. Estimate the Perplexity score for the F16 model (baseline) using the wikitext-2-raw-v1 dataset, and save the logits
3. Generate an imatrix from the most appropriate calibration dataset
4. Quantize the baseline model targeting a bpw average (e.g. llama-quantize --target-bpw 4.5678 --state-file --imatrix imatrix.gguf baseline-model-F16.gguf 12)
5. Calculate Perplexity, KL Divergence, ARC (Easy+Challenge), GPQA-Diamond, HellaSwag, MMLU-Redux, Truthful QA and WinoGrande scores for each quantized model
6. Keep version with the best 𝜌PPL and μKLD scores
7. Repeat until all desired quants are created

Misconceptions about BF16 to F16 Conversion

A common concern when converting BFloat16 (BF16) models to Float16 (F16) is the potential for accuracy loss. Specifically:

• Weight Clipping (Overflow): Clipping, or overflow, is often feared but only occurs if a model's weights exceed the range of ±65,503. This is a relatively rare issue in practice.
• Subnormal Zeroing (Underflow): A more frequent occurrence is underflow, where weights smaller than approximately 5.96x10⁻⁸ are converted to zero.

Crucially, when the F16 model is subsequently used for quantization, the resulting degradation in metrics like Perplexity (PPL) or Kullback–Leibler Divergence (KLD) is minimal. Any variations are typically restricted to the hundreds or thousandths decimal places compared to the BF16 model.

However, considering that weight clipping presents a more substantial risk to model integrity, every BF16 base model undergoes validation prior to the conversion process. Consequently, no models hosted in this repository exhibit performance degradation due to overflow clipping.

While BF16 offers precision benefits, performance remains a key factor.

• Conversion Speed: Tests, such as timing convert_hf_to_gguf.py, show a notable performance difference, with conversion to BF16 being 15–30% slower than to F16.
• Inference Speed: A less pronounced but still present difference (3–6%) is observed during inference. Although native BF support has been introduced by many chip manufacturers, the slower performance may stem from the entire software and hardware stack (firmware, libraries, etc.) not being fully optimized yet.

The choice to prioritize F16 over BF16 is driven by a focus on maximizing performance in specific deployment environments. My primary objective is not large-scale quantization production, a domain where others like Bartowski and Unsloth excel at, but rather optimizing inference performance for resource-constrained environments. Since BF16 support is not yet widespread in areas like mobile, edge, and embedded devices, using F16 ensures broader compatibility and easier optimization for these use cases.

Advantages and disadvantages of the global target bits‑per‑weight quantization process

Advantages

1. Target arbitrary size models

   • When specifying --target-bpw 4.5678 for instance, the algorithm will produce a model (nearly) exactly of that size, which is very useful for maximizing VRAM usage. In a system with 24GB VRAM and a 70B model, standard quants might produce a 16.8GB file (too small, quality left on table) or a 24.1GB file (won't fit). This approach can generate a 23.85GB file to utilize the hardware fully.

2. Data-driven mixed precision often can improve quality at fixed size

   • Instead of using hardcoded heuristics (e.g. make attn_v Q5_K for a 70B model), that may be sub‑optimal for a given architecture or size, the quantization mix is determined by the actual error sensitivity of the specific model's weights. This, in practice, often yields a better quality/size trade-off, especially in aggressive quantization scenarios (1.5 to 3.5 bpw), or for unusual architectures.

   • Please note: llama.cpp’s heuristics have been tuned across many models and are highly optimized; although the target bpw method produces better quality often (>75% based on tests with 130 models from 11 different families), it can also lose in surprising cases.

3. Allows better like-for-like comparisons between models and families

   • Standard llama.cpp quantization uses hardcoded rules like: "use Q4_K_M, except bump some tensors up/down, except fall back if incompatible, except keep some tensors unquantized..." and for that reason, two different models quantized with the same Q4_K_M type can end up with very different bpw (e.g. 4.75 and 4.30).

   • All things being equal, the performance of a model is usually proportional to its overall bpw size; models with a higher bpw tend to perform better than lower bpw models. Since model A has simply been given more bits, it will typically perform better (lower perplexity, better eval scores, etc.) even if the underlying quantization method is identical. That makes comparing the performance not a controlled experiment, because the comparison is between models with different effective compression ratios.

   • --target-bpw tries to address that by making the experiment more controlled: each model gets quantized to land on (approximately) the same global byte budget, so that the models' performance differences are more attributable to architecture/training differences, quantization error behaviour at the same compression ratio, optimizer’s allocation decisions, etc.

Disadvantages

1. Quantization process is significantly slower than standard

   • This approach can take 5x-10x longer as it quantizes a sample of most tensors into 15 different formats, dequantizes them back to floats, computes error diffs, and selects the best size/error option that fits the global bpw budget.

   • However, the --state-file option will save/use the above-mentioned computations so that future quantizations, for the same model, can be generated at normal speed. It also allows to interrupt the computation process and resume it at a later time.

2. The optimization target is only a proxy for the model's performance quality

   • The process minimizes a per-tensor estimated error computed from sampled rows, not actual perplexity or divergence of output distributions (a future version may address this). Since errors interact nonlinearly across layers, there are no guarantees it will select the best possible quantization recipe subject to the bpw size constraint.

3. An imatrix with activations data is required for best results

   • Activation data is required to compute the bias factor (i.e. the systematic error projected onto activation directions). If the imatrix file does not contain activation data, the --target-bpw option will refuse to run.

---

Models

Bits per weight, size, perplexity and KL Divergence scores

Model	BPW	Size (GB)	μPPL	𝜌PPL	μKLD	Same Top-P
Spark-X2.5-4B-F16	16.0007	7.66	30.822397 ±0.290868	100%	N/A	N/A
Spark-X2.5-4B-Q2_K	2.5000	1.20	269.346125 ±2.933830	70.45%	2.855031 ±0.005518	33.013 ±0.120
Spark-X2.5-4B-Q3_K	3.5000	1.68	57.176370 ±0.558481	85.76%	1.202957 ±0.003022	52.055 ±0.127
Spark-X2.5-4B-Q4_K	4.5000	2.15	38.328843 ±0.375702	95.96%	0.337933 ±0.001328	74.457 ±0.111
Spark-X2.5-4B-Q5_K	5.5000	2.63	30.392470 ±0.284714	98.11%	0.148844 ±0.000742	82.640 ±0.096
Spark-X2.5-4B-Q6_K	6.5000	3.11	29.781803 ±0.280794	99.32%	0.050862 ±0.000387	90.101 ±0.076
Spark-X2.5-4B-Q7_K	7.5000	3.59	30.385132 ±0.287316	99.70%	0.020202 ±0.000223	93.684 ±0.062
Spark-X2.5-4B-Q8_0	8.4891	4.06	30.437372 ±0.287594	99.87%	0.006647 ±0.000143	96.560 ±0.046

ARC, GPQA-Diamond, HellaSwag, MMLU-Redux, Truthful QA, and WinoGrande scores

Scores generated using llama-perplexity with 750 tasks per test, and a context size of 1024 tokens.

For the test data used in the generation of these scores, follow the appropriate links: ARC Challenge, Truthful QA, GPQA-Diamond, HellaSwag, MMLU-Redux, WinoGrande

Model	ARC Challenge	GPQA-Diamond	HellaSwag	MMLU-Redux	Truthful QA	WinoGrande	Avg Score
Spark-X2.5-4B-Q2_K	27.6000 ±1.6334	25.2525 ±3.0954	33.07	33.3333 ±1.7225	27.4667 ±1.6309	51.2000 ±1.8264	32.99
Spark-X2.5-4B-Q3_K	29.7333 ±1.6702	23.2323 ±3.0089	48.27	40.4000 ±1.7930	25.0667 ±1.5836	53.0667 ±1.8235	36.63
Spark-X2.5-4B-Q4_K	30.1333 ±1.6766	25.2525 ±3.0954	39.73	65.2000 ±1.7405	25.4667 ±1.5919	56.0000 ±1.8138	40.30
Spark-X2.5-4B-Q5_K	39.7333 ±1.7880	20.7071 ±2.8870	51.87	61.7333 ±1.7759	24.0000 ±1.5605	61.2000 ±1.7805	43.21
Spark-X2.5-4B-Q6_K	42.1333 ±1.8042	21.7172 ±2.9377	49.60	61.2000 ±1.7805	25.6000 ±1.5947	61.7333 ±1.7759	43.66
Spark-X2.5-4B-Q7_K	40.4000 ±1.7930	19.1919 ±2.8058	50.53	62.8000 ±1.7661	24.4000 ±1.5693	60.5333 ±1.7860	42.98
Spark-X2.5-4B-Q8_0	43.0667 ±1.8093	20.2020 ±2.8606	50.00	63.3333 ±1.7608	26.1333 ±1.6054	61.2000 ±1.7805	43.99

Tokens per second benchmarks

Scores generated using llama-bench. Standard (llama-quantize with no optimization) Q4_K_M quantization included for comparison.

model	size	params	backend	threads	test	t/s
Spark-X2.5-4B-Q2_K	1.20 GiB	4.11 B	MTL,BLAS	12	pp512	1613.27 ± 2.65
Spark-X2.5-4B-Q2_K	1.20 GiB	4.11 B	MTL,BLAS	12	tg128	126.33 ± 0.61
Spark-X2.5-4B-Q2_K	1.20 GiB	4.11 B	MTL,BLAS	12	pp1024+tg1024	216.57 ± 14.89
Spark-X2.5-4B-Q3_K	1.68 GiB	4.11 B	MTL,BLAS	12	pp512	1236.48 ± 26.89
Spark-X2.5-4B-Q3_K	1.68 GiB	4.11 B	MTL,BLAS	12	tg128	102.13 ± 1.06
Spark-X2.5-4B-Q3_K	1.68 GiB	4.11 B	MTL,BLAS	12	pp1024+tg1024	182.15 ± 1.09
Spark-X2.5-4B-Q4_K	2.15 GiB	4.11 B	MTL,BLAS	12	pp512	1241.66 ± 30.90
Spark-X2.5-4B-Q4_K	2.15 GiB	4.11 B	MTL,BLAS	12	tg128	93.83 ± 6.63
Spark-X2.5-4B-Q4_K	2.15 GiB	4.11 B	MTL,BLAS	12	pp1024+tg1024	125.72 ± 13.69
Spark-X2.5-4B-Q5_K	2.63 GiB	4.11 B	MTL,BLAS	12	pp512	901.73 ± 61.69
Spark-X2.5-4B-Q5_K	2.63 GiB	4.11 B	MTL,BLAS	12	tg128	61.77 ± 5.33
Spark-X2.5-4B-Q5_K	2.63 GiB	4.11 B	MTL,BLAS	12	pp1024+tg1024	128.55 ± 8.89
Spark-X2.5-4B-Q6_K	3.11 GiB	4.11 B	MTL,BLAS	12	pp512	1333.17 ± 90.42
Spark-X2.5-4B-Q6_K	3.11 GiB	4.11 B	MTL,BLAS	12	tg128	91.74 ± 9.07
Spark-X2.5-4B-Q6_K	3.11 GiB	4.11 B	MTL,BLAS	12	pp1024+tg1024	161.91 ± 1.34
Spark-X2.5-4B-Q7_K	3.59 GiB	4.11 B	MTL,BLAS	12	pp512	1429.16 ± 106.16
Spark-X2.5-4B-Q7_K	3.59 GiB	4.11 B	MTL,BLAS	12	tg128	85.18 ± 6.87
Spark-X2.5-4B-Q7_K	3.59 GiB	4.11 B	MTL,BLAS	12	pp1024+tg1024	151.42 ± 1.05
Spark-X2.5-4B-Q8_0	4.06 GiB	4.11 B	MTL,BLAS	12	pp512	1378.05 ± 20.87
Spark-X2.5-4B-Q8_0	4.06 GiB	4.11 B	MTL,BLAS	12	tg128	82.22 ± 5.11
Spark-X2.5-4B-Q8_0	4.06 GiB	4.11 B	MTL,BLAS	12	pp1024+tg1024	148.73 ± 0.89

Metrics used

Perplexity: one of the key metrics used in NLP evaluation. It measures the quality of a language model by evaluating how well it predicts the next token given a particular sequence of words. A PPL of 1 indicates an exact match between predicted and actual, whereas values greater than one indicate a degree of "surprise" the generated token differs from the expected.

Kullback–Leibler (KL) Divergence: a statistical measure of how much a probability distribution differs from another. When quantizing models (or altering the original tensors in any way for that matter), the closest we can preserve the weights' probability distribution to the original model the better, thus the closest to 0 the better.

AI2 Reasoning Challenge (ARC): a benchmark to evaluate the ability of AI models to answer complex science questions that require logical reasoning beyond pattern matching.

GPQA-Diamond: a challenging dataset of 448 multiple-choice questions written by domain experts in biology, physics, and chemistry.

HellaSwag: the Harder Endings, Longer contexts, and Low-shot Activities for Situations With Adversarial Generations (bit of a mouthful!) is a benchmark designed to test commonsense natural language inference. It requires the model to predict the most likely ending of a sentence.

MMLU: the Massive Multitask Language Understanding evaluates LLMs’ general knowledge and problem-solving abilities across 57 subjects, including elementary mathematics, US history, computer science, and law.

Truthful QA: evaluates how well LLMs generate truthful responses to questions. It identifies whether AI models can avoid generating false or misleading information, particularly in areas where human knowledge is prone to misconceptions.

Winogrande: based on the Winograd Schema Challenge, is a natural language understanding task requiring models to resolve ambiguities in sentences involving pronoun references.

Credits

LLaMa C++ has a large and vibrant community of contributors (~1,600 last time I checked) that actively maintain and extend its functionality, adding new models and architectures almost as fast as they appear. Considering the breakneck speed at which the AI/ML field is advancing, this alone is a remarkable feat!

While I'm grateful to all contributors, I want to recognise three in particular:

• Colin Kealty (Bartowski), for the many contributions and for being one of the best sources of high quality quantized models available on Hugging Face
• Georgi Gerganov for his amazing work with llama.cpp and the ggml/gguf libraries
• Iwan Kawrakow for being one of the key authors behind the many quantization algorithms and the imatrix functionality.