Kvark Sparkle 1.0 27B

At a glance

Kvark Sparkle 1.0 27B is Egzakta AI Lab's open-weight fine-tune of Qwen3.8-27B, trained to reason in fewer tokens. The architecture is unchanged. Egzakta reports roughly the base model's accuracy with much shorter thinking: median answer time fell from 28.1 s to 13.7 s on one H200 in its own vLLM test. It takes text and images and returns text.

Good fit

Teams that already run Qwen3.8-27B, or plan to self-host a model of that size, and want faster reasoning answers on math, science and coding questions without moving to a larger model. It loads with the same vLLM, llama.cpp and Transformers setups as the base model and uses the same reasoning and tool-call parsers, so swapping it in should take little work.

Consider something else when

Skip it if you don't want to run a 27B model yourself, or if image understanding is your main need, because the vision encoder is the unchanged base model's and only the language side was trained. If every point of accuracy on competition math matters more to you than speed, the base model is the safer choice: in Egzakta's own tables Sparkle scored slightly lower on AIME, IFEval and MMLU-Pro.

Start here

Try the hosted demo on Hugging Face Spaces, which runs the Q4_K_M GGUF build. To run it locally, use llama-server -hf Egzakta/Kvark-Sparkle-1.0-27B-GGUF:Q4_K_M -c 65536 --jinja. On a vLLM GPU server, serve the FP8 repository with the MTP speculative config from the card and call it through any OpenAI-compatible client. For hard problems, allow up to 65,536 output tokens.

Cost and requirements

As of 2026-11-02, the weights are free under Apache 2.0, inherited from Qwen3.8-27B, and commercial use is allowed with no revenue cap. Downloads are about 52 GB for BF16, 29 GB for FP8 (meant for vLLM) and 15.3 to 29 GB for the GGUF quantizations used with llama.cpp. The native context is 262,144 tokens, but the KV cache takes 64 KiB per token in BF16 (32 KiB in FP8), so long contexts need a lot of extra memory.

Limits to know

The publisher ran every benchmark, often on subsets: 50 LiveCodeBench problems and 980 MMLU-Pro items. Context was tested only up to 64k tokens. Thinking is on by default and can still use thousands of tokens per answer, and some hard items hit the 64k cap. No vision benchmarks are reported. The model card lists English as the only language.

Related work

• Alibaba (Qwen, the base model family) (context)

Still unclear

• How well does tool calling work? The vLLM quickstart turns on a tool-call parser, but no tool-use results are published.
• Did image understanding change after the language-only fine-tune and weight merge?
• How much accuracy do the lower GGUF quantizations, such as Q4_K_M, lose compared with the FP8 weights used in the benchmarks?