26 lines
1.5 KiB
Markdown
26 lines
1.5 KiB
Markdown
# 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.
|