# 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.