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 = 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), RÉCUPÉRABLE. Localisé 27/05 : SSM_CONV sur HTP est faux en multi-token (prefill) pour d_inner=1024/2048 (oracle FAIL ERR~1.3 ; decode n=1 OK ; bug backend hexagon, pas le calcul — HVX ET scalaire HTP échouent, ggml-cpu correct). Fix immédiat = GGML_HEXAGON_OPFILTER=SSM_CONV (route conv sur CPU, reste sur HTP) → prefill HTP 181 t/s + sortie cohérente (« Je comprends que cette rumination… »), ×13 vs CPU 14. 3 configs : A CPU-only (14/10.9, livrée), B mono-ctx HTP+OPFILTER (181/6.4), C dual-ctx prefill-HTP/decode-CPU (181/10.9, +2.3GB). cf HANDOFF.md décision 2. Dense sur HTP crashe (0x2e). TODO: corriger SSM_CONV HTP (gate test-backend-ops -o SSM_CONV = 45/45) → supprime l'OPFILTER.
• 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.