Best qwen finetune tested ever!

#1
by repla73 - opened

This model performed extremely well despite it's weight and even beat some fine-tuned quants of newer qwen3.8-27b on real-world agentic benchmark test (not imaginary numbers and charts, real tests).

So I spent a couple of days tuning ik_llama.cpp for CPU-only inference on a 4-core ARM Neoverse-N1.

Special thanks to Mannix-ITA team!
Results:
The final configuration improved trimmed token generation throughput by roughly:
+10.0 vs the previous MTP2 configuration
+9.0% vs the previous canonical MTP1 setup
Prompt processing stayed essentially unchanged.
The main win came from using an IQ4_KS copy of the output tensor for MTP speculative generation:
-mtprot iq4_ks
--spec-type mtp:n_max=2,p_min=0.0
This does not requantize the whole model. The normal output head remains Q6_K; ik_llama creates a separate ~4-bit MTP-only output head used for speculative token proposals.
Cost: about 259 MiB additional RAM.
***Compile configuration
The best build used Clang 20 with explicit Neoverse-N1 targeting:
-mcpu=neoverse-n1+dotprod+fp16
-O3
-ffast-math
-fno-finite-math-only
-flto
-pipe
Relevant build options:
GGML_NATIVE=OFF
GGML_OPENMP=ON
GGML_IQK_MUL_MAT=ON
GGML_IQK_FLASH_ATTENTION=ON
GGML_IQK_FA_ALL_QUANTS=ON
Explicit CPU targeting mattered more than relying on generic/native build assumptions.
***Best runtime configuration
context: 131072
batch: 2048
ubatch: 512
threads: 4
threads-batch: 4
flash-attn: on
K cache: q8_KV
V cache: q4_0
runtime repack: on
THP: on
reasoning: off
MTP p_min: 0.0
MTP depth: 2
MTP output: iq4_ks
The practical lesson: on ARM CPU inference, the biggest gains did not come from exotic kernel rewrites. They came from matching the build to the CPU, keeping all four physical cores busy, using the IQK path, tuning MTP depth, and reducing the cost of the speculative output projection.
After testing PGO, prefetching, unrolling and several Q4 kernel rewrites, most of them were neutral or slower. The simple runtime configuration above won.

There also seems to be useful memory headroom on CPU-only systems. I’d love to see whether a future MTP design could spend some of that on a stronger predictor/output head and convert the extra memory budget into higher draft acceptance and throughput.

Sign up or log in to comment