Kazeia-engine/dist/MODELS.md

Modèles (external storage prod ; staging /data/local/tmp/kz-engine)

Choisi (26/05) — Speaker

Rôle	GGUF	Taille	Decode	Note
Speaker	q35-lmq4.gguf (Qwen3.5-4B, embeds Q4)	2.38 GB	~10.8	choisi (éval qualité : gagne SAFETY+SUPPORT vs dense)
Alternative rapide	Qwen3-4B-Q4_0 (dense)	2.21 GB	~11.7	+ rapide/simple mais perd le SAFETY ; repli si q35 pose souci
Thinker (cascade option.)	Qwen3Guard-Gen-4B.Q4_K_M	2.5 GB	~11	bullets, si on garde une cascade

9B écarté : decode réel ~4-5 t/s (contention), pas de gain qualité justifiant le coût. MoE 30B/35B = OOM.

q35-lmq4 — c'est quoi / comment le refaire

Variante de Qwen3.5-4B où token_embd/output sont en Q4_0 (au lieu du Q6_K que llama.cpp garde par défaut pour le gros vocab 248k). Gain : −0.2 GB et +5% decode, qualité ≈ Q4_0 (A/B FR identique). Recette (idéalement depuis un GGUF F16 ; --allow-requantize si depuis Q4_0) :

llama-quantize [--allow-requantize] --token-embedding-type q4_0 --output-tensor-type q4_0 \
  <source.gguf> q35-lmq4.gguf Q4_0

Le fichier prêt est sur la tablette (/data/local/tmp/kz-engine/q35-lmq4.gguf) — adb pull pour le récupérer. Hors git (2.38 GB).

Mesuré mort (ne pas refaire) : quant sous-Q4 = decode CPU PLUS lent

Q3_K_M global = 8.3 (−20% vs Q4_0), Q2_K embeds = +3% seulement. Les k-quants ont un déquant CPU qui mange le gain d'octets. Q4_0 simple reste l'optimum decode. (cf PERF.md.) Source GGUF : unsloth/*-GGUF.