23 lines
1.6 KiB
Markdown
23 lines
1.6 KiB
Markdown
# 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.
|