5 tests systématiques sur les hypothèses non-explorées :
A. USE_HMX=0 vs USE_HMX=1 sur sched CP :
- HVX 20% plus rapide que HMX à batch=1 (tile 32×32 sous-utilisé)
- Mais aucun ne bat baseline CPU (110 ms/frame)
- HVX et HMX bit-exact entre eux ; les deux divergent de CPU (codes
différents -> trajectoire talker diverge -> N=64 vs 33).
B. op_offload=true vs false : false -16% sur CP HMX (placement strict
moins coûteux). Quick win retenu (env KZTTS_CP_OFFLOAD).
C. Profile fin (KZTTS_CP_PROFILE=1) par sub-step :
- sched_reset+alloc : 0.1 ms (négligeable !)
- tensor_set/get : 0.0 ms (opt_hostbuf=1 = ION partagé)
- compute : 6-11 ms (95 % du temps !)
-> L'overhead sched n'est PAS le problème. Le compute HTP
lui-même est plus lent que CPU pour batch=1. Hypothèse #1
(sched_reserve + ctx persistant) INVALIDÉE.
D. Talker option C (use_htp=true, GGML_HEXAGON_GDN_PREFILL=1) :
- Prefill : 87 ms -> 185 ms (+112%)
- Talker per-frame : 32 ms -> 81 ms (+154%)
-> Pour un petit modèle (0.6B), l'overhead routing HTP par token
dépasse le gain compute. Le pattern option C documenté
marche pour Qwen3.5-4B, PAS pour Qwen3-TTS-Talker.
VERDICT GLOBAL : le HTP est non-rentable sur TOUS nos workloads TTS.
- BigVGAN : bloqué (nrows > 1024)
- CP : régresse (batch=1)
- Talker : régresse (trop petit pour amortir routing)
CLAUDE.md le notait partiellement ('CPU NEON bat HVX 3.4× sur M=1') mais
on n'avait pas tiré la conséquence globale : notre TTS n'a pas de
workload HTP-friendly.
LEVIERS RESTANTS (sans HTP) :
1. Streaming pipeline (1 session) : RTF inchangé mais TTFB 5s->500ms
2. Réduction overhead CP CPU (½ session) : ctx réutilisé entre sub-forwards
3. Decoder optim NEON conv1d : R&D long
4. Quantization Q8/Q4 CP : compromis qualité
Code committé reste opt-in (KZTTS_CP_HTP, KZTTS_DECODER_HTP) et neutre
au runtime. Le path par défaut RTF=3.0 est intact.
Détails complets dans dist/PERF_INFRA_TESTS.md.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
101d1cd7ed