1.3 KiB
1.3 KiB
Perf mesurée SM8750/V79 — MAJ 26/05 (fork ql=qualcomm/llama.cpp)
Decode optimum = t4 / fa1 (PAS t8 : contention, 3.5-4B chute). Prefill HTP : t8 / b512.
| Modèle | prefill HTP (t8/b512) | prefill CPU (t4) | decode CPU (t4+fa) | RAM |
|---|---|---|---|---|
| Qwen3-4B dense | 285 | ~19 | ~11.7 | 2.2 |
| Qwen3.5-4B (q35-lmq4) | 89.5 | ~18-19 | ~10.8 | 2.4 |
| Qwen3.5-9B | 70 | — | ~4-5 | 5.0 |
Notes (chiffres sains ; reconfirmer hors throttle batterie) :
- GDN-compute n'est PAS le goulot du prefill : serial f32 / fp16 / WY chunkwise donnent le même pp512 (~89.5). Piste kernel GDN close (RAPPORT_RD §7). Decode = plafond BW CPU ~25 GB/s.
- Bridge JNI = CPU-only (ngl0) → prefill ~18-19 (pas 89.5). Le 89.5 est la capacité HTP, non câblée.
- KV q8_0 à revérifier : mesure dégradée a donné decode q8_0 < f16 (déquant KV coûteux à court contexte, comme la quant poids). A/B sur batterie pleine ; si f16 gagne, dropper q8_0 du JNI.
q35-lmq4(embeds Q4) = +5% decode vs Q4_0, qualité ≈.- NPU≈CPU au decode (GEMV M=1 latency-bound, 77 GB/s injoignable). RAM = GGUF mmap + ~3.3 GB ION/session.
Leviers MORTS (mesurés) : spec-decode net-négatif ; ngram idem (vérif GDN coûteuse) ; IQ4_NL = mêmes octets ; quant sous-Q4 = decode CPU plus lent (Q3_K_M −20%) ; kernel GDN (chunkwise/HMX/fp16) = 0 sur prefill.