# 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 charabia = 1 op cassée (SSM_CONV conv1d), CORRIGÉ.** Localisé 27/05 : SSM_CONV sur HTP faux
  en multi-token (prefill) pour d_inner=1024/2048 (1536 OK ; bug données/marshalling DSP, HVX+scalaire HTP faux,
  ggml-cpu correct, non localisé). **Fix intégré au backend** `ggml_hexagon_supported_ssm_conv` (n_t>1 → CPU) :
  conv1d prefill sur ggml-cpu (correct, bon marché), reste sur HTP, decode conv HTP (n_t=1). Plus d'OPFILTER.
  Validé : oracle SSM_CONV 18/18, cli -dev HTP0 cohérent, multi-tour cohérent+mémoire. **prefill HTP 110-180 t/s**
  (×8-13 vs CPU 14). Le JNI = option C (prefill HTP→transfert KV→decode CPU). Dense sur HTP crashe (0x2e, distinct).
  TODO bas-ROI : réparer le kernel SSM_CONV HTP multi-token (gate cas multi-token) pour mettre le conv aussi sur HTP.
- **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.
