Kazeia-engine/dist/PERF.md

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 HTP : ngl99 / t8 / b512.

Modèle	prefill HTP	prefill CPU (t4)	decode CPU (t4+fa, KV f16)	RAM
Qwen3-4B dense	98	~14	11.7	2.2
q35-lmq4 (Qwen3.5-4B, embeds Q4)	189	14	10.9	2.4
Qwen3.5-4B-Q4_0 (embeds Q6_K)	98	~14	10.8	2.4
Qwen3.5-9B	70	—	~4-5	5.0

Notes :

• KV f16 ≫ q8_0 au decode : q35-lmq4 f16=10.9 vs q8_0=6.5 (−40%, idem à d=512). Le déquant KV en flash-attn coûte plus que le BW épargné. → JNI en type_k/v=F16. q8_0 seulement si OOM KV long.
• q35-lmq4 prefill HTP = 189 ≈ 2× le Q4_0 (98) : ses embeds/output Q4 restent sur NPU, alors que le Q6_K par défaut retombe sur CPU (une partie du « mur prefill » était ce fallback lm_head, pas le GDN).
• GDN-compute n'est PAS le goulot prefill : serial f32 / fp16 / WY chunkwise = même pp512. Piste kernel GDN close (RAPPORT_RD §7). Decode = plafond BW CPU ~25 GB/s.
• Bridge JNI = CPU-only (ngl0) → prefill 14 (pas 189). Le 189 = capacité HTP, non câblée (ping-pong ngl99).
• 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 ; 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.