Kvark Sparkle 1.0 27B, MLX AWQ 4/6-bit

An unofficial MLX build of Egzakta/Kvark-Sparkle-1.0-27B for Apple silicon. It is not made or endorsed by Egzakta. The weights are Kvark's, quantised with AWQ to mixed 4/6-bit, with its MTP head included. No training, merging or abliteration was done, so Kvark's own safety behaviour is unchanged.

The other builds:

Base Egzakta/Kvark-Sparkle-1.0-27B @ bb41d9af, BF16 (a post-train of Qwen/Qwen3.8-27B)
Weights 17.9 GB (16.68 GiB) at 4.45 bits per weight, AWQ affine with group size 64. 456 modules are 4-bit. 42 are 6-bit: the embeddings, lm_head, and half of the v_proj and down_proj modules, as in mlx-vlm's mixed_4_6 rule. The 7 MTP projections are 8-bit
Vision tower Kvark's, unquantised BF16
MTP head 1 layer, inline in model-mtp.safetensors (see MTPLX and mlx-lm)
Context 262,144 tokens (config)
Architecture Qwen3_5ForConditionalGeneration, 64 layers, hidden size 5,120

Speed

The weights aren't changed for speed. There are two sources: speculative decoding, and Kvark's shorter reasoning.

Decode speed. These are single requests of one greedy 400-token coding prompt on a Mac Studio (M5 Ultra), using oMLX with the Splash engine, int8 KV cache, and z-lab's DFlash2 drafter (z-lab/Qwen3.8-27B-DFlash2). Both rows come from the same session:

Build Decode Time to first token
This model 192.9 tok/s 0.105 s
Qwen3.8-27B at the same 4/6 recipeยน 191.1 tok/s 0.104 s

DFlash2 was trained on stock Qwen3.8, and it still fits Kvark's weights: the decode speed is the same. Without a drafter, the model decodes at ordinary 4-bit speed.

Thinking tokens. This is where Kvark is faster. Counted with thinking on, on the same questions for both builds:

Qwen3.8 at the same recipeยน This model
LiveCodeBench, 40 questions: mean tokens per answer (limit 16,384) 5,952 4,480
LiveCodeBench: answers cut off at the limit 9 6
LiveCodeBench: elapsed time for the eval 824 s 552 s
MMLU-Pro, 100 questions: mean tokens per answer (limit 8,192) 2,010 1,253
MMLU-Pro: answers cut off at the limit 13 6
MMLU-Pro: elapsed time for the eval 600 s 377 s

On the questions both got right, Kvark used about half the tokens: 2,771 โ†’ 1,383 on LiveCodeBench (25 questions) and 871 โ†’ 448 on MMLU-Pro (75). That matches the 34โ€“67% saving Egzakta's card claims. Both evals finished about a third sooner.

ยน The comparison build is OrcaRouter's uncensored Qwen3.8-27B (via npario's MLX conversion), made with this same 4/6 AWQ recipe. It was the reference at hand. Stock Qwen3.8 at this recipe wasn't measured, but the abliteration moves that model only slightly (KL 0.0048 against stock).

Accuracy

The same quick evals, with thinking on:

Qwen3.8 at the same recipeยน This model
LiveCodeBench, 40 questions 0.70 0.80
MMLU-Pro, 100 questions 0.77 0.82

These samples are too small to call Kvark better. Only a few questions went one way and not the other: 3 against 7 on LiveCodeBench (exact McNemar p = 0.34) and 2 against 7 on MMLU-Pro (p = 0.18). What the data supports is "at least as good, with far fewer tokens". Neither eval had any errors.

Against the 8-bit. Teacher-forced on the 8-bit's own coding continuations, this build agrees on the top-1 token 0.959 of the time, with mean KL 0.018.

Refusals. It refuses 103 of 104 harmful prompts and 4 of 104 harmless ones, decoded greedily with thinking off and scored with Heretic's refusal markers.

How it was made

  1. Quantisation. AWQ with text calibration, starting from Egzakta's BF16, using mlx-vlm's mixed_4_6 predicate with group size 64. The vision tower is left unquantised.
  2. MTP head. Kvark's card says the head is the base model's, unchanged. It is taken from the BF16 checkpoint, its norms are offset by +1.0 to match MLX's convention, and the 7 projections are quantised to 8-bit g64.
  3. Checks.
    • The bit widths are as declared, the vision tower is unquantised, and all 29 MTP tensors are present.
    • The tokenizer and chat template match Kvark's.
    • Every norm matches an independent Qwen3.8 MLX build to within 0.0004. The 32 norms that AWQ folds its scales into are skipped.

Usage

With mlx-vlm (tested with 0.7.9):

pip install -U mlx-vlm
python -m mlx_vlm.generate --model cloudcommander/Kvark-Sparkle-27B-MLX-AWQ-4.5bit \
  --max-tokens 2048 --enable-thinking --prompt "Explain how a hash table handles collisions."

The chat template thinks by default. To turn thinking off through an OpenAI-compatible server, send "chat_template_kwargs": {"enable_thinking": false}.

With oMLX, put the folder in a model directory. The speeds above used the Splash engine with z-lab/Qwen3.8-27B-DFlash2 as the draft model, set in oMLX's per-model settings.

MTPLX and mlx-lm

The MTP head is stored inline as mtp.* tensors. mlx-lm's qwen3_5 loader takes those as the sign of a raw HF checkpoint and adds +1.0 to every norm, which this build already has, and the output turns to garbage. This was seen with MTPLX, which loads through mlx-lm. Plain mlx-lm loading should break the same way, but was not tested. For MTPLX, move the head into a sidecar file; the 8-bit card has the details.

Not tested

  • Vision. The tower is Kvark's and unquantised, but nothing visual was evaluated.
  • Full benchmarks. Only the quick evals above have been run.
  • Long-context behaviour, languages other than English.

Licence and credits

Apache-2.0, as is every model in its lineage. LICENSE and Egzakta's NOTICE are included unchanged. The only change to Egzakta's weights is the quantisation described above.

  • Qwen Team, Alibaba Group: Qwen3.8-27B, the base model.
  • Egzakta / KVARK: Kvark Sparkle 1.0, the post-train these weights are.
  • z-lab: the DFlash2 drafter used for the speed figures. It is not included here.
  • p-e-w's Heretic: the refusal markers used for scoring.

Egzakta's card gives this citation for Kvark:

@misc{kvarksparkle2026,
  title  = {KVARK Sparkle 1.0},
  author = {Egzakta AI Lab},
  year   = {2026},
  url    = {https://huggingface.co/Egzakta/Kvark-Sparkle-1.0-27B}
}
Downloads last month
20
Safetensors
Model size
28B params
Tensor type
U32
ยท
BF16
ยท
MLX
Hardware compatibility
Log In to add your hardware

4-bit

Inference Providers NEW
This model isn't deployed by any Inference Provider. ๐Ÿ™‹ Ask for provider support

Model tree for cloudcommander/Kvark-Sparkle-27B-MLX-AWQ-4.5bit

Base model

Qwen/Qwen3.8-27B
Quantized
(8)
this model