# Perf mesurée SM8750/V79 — MAJ 27/05 (fork ql=qualcomm/llama.cpp), batterie pleine device froid
Decode optimum = **t4 / fa1 / KV f16** (PAS t8 : contention ; PAS KV q8_0 : déquant coûteux). **Prefill = CPU** (le HTP sort du charabia, cf ci-dessous).

| Modèle | prefill CPU (t4) | prefill HTP (débit) | decode CPU (t4+fa, KV f16) | RAM |
|---|--:|--:|--:|--:|
| **q35-lmq4** (Qwen3.5-4B, embeds Q4) | **14** | 189 *(sortie CASSÉE)* | **10.9** | 2.4 |
| Qwen3.5-4B-Q4_0 (embeds Q6_K) | ~14 | 98 *(cassé)* | 10.8 | 2.4 |
| Qwen3-4B dense | ~14 | crash 0x2e | 11.7 | 2.2 |
| Qwen3.5-9B | — | — | ~4-5 | 5.0 |

Notes :
- **PREFILL HTP = CASSÉ (27/05, vérifié 3×).** Débit réel (126-189 t/s) mais **état/logits corrompus →
  sortie charabia** (harness dual-ctx, device HTP0 explicite, et `llama-cli -dev HTP0` → anglais cassé sur
  prompt FR). Preuve = c'est le prefill, pas le transfert : decode CPU depuis état prefillé-CPU = FR cohérent,
  depuis état prefillé-HTP = charabia. Les anciens « 189/98/285 » = débit jamais validé en sortie, **inutilisables**.
  Dense sur HTP **crashe** (V79 0x2e). → **prefill obligatoirement CPU.** Le KV transfer (Path A) marche
  (CPU→CPU cohérent), prêt si le prefill HTP devient un jour correct (bug backend frontière).
- **KV f16 ≫ q8_0 au decode** : q35-lmq4 f16=10.9 vs q8_0=6.5 (−40%, idem à d=512). → JNI `type_k/v=F16`.
- **GDN-compute n'est PAS le goulot prefill** (débit) : serial f32 / fp16 / WY = même pp512. Piste kernel GDN close.
- NPU≈CPU au decode (GEMV M=1 latency-bound). RAM = GGUF mmap + ~3.3 GB ION/session.

Leviers MORTS (mesurés) : spec-decode net-négatif ; ngram idem ; IQ4_NL = mêmes octets ;
**quant sous-Q4 = decode CPU plus lent** (Q3_K_M −20%) ; **KV q8_0 = decode −40%** ; kernel GDN (chunkwise/HMX/fp16) = 0 sur prefill.