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), 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.