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 = 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.