Kazeia-engine/dist/PERF_ANALYSIS.md

# Analyse perf TTS Kazeia — 28/05 soir

État après les 4 chantiers de la session (RTF 4.99 → 3.07). Mesures sur Pad3,
CPU 4 threads talker / 8 threads decoder, KZTTS_CP_CACHE=1, phrase « Bonjour je m'appelle
Kazeia » → 31 frames audio (2.58s).

## 1. Breakdown précis (mesuré)

| Étape | Temps | %total | Par frame | RTF partiel |
|---|---:|---:|---:|---:|
| Prefill talker | 0.10 s | 1.3% | 3 ms | 0.04 |
| **Talker loop** (decode 31×1 token) | 1.00 s | 12.6% | 33 ms | 0.39 |
| **CP loop** (31× (1 prefill + 14 decode)) | 3.40 s | 43.0% | 110 ms | 1.32 |
| **Decoder** (5 stages) | 3.40 s | 43.0% | — | 1.32 |
| TOTAL | 7.90 s | 100% | | **3.06** |

**Decoder breakdown** (mesuré via `KZTTS_DECODER_PROFILE=1`) :

| Stage | Temps | % decoder |
|---|---:|---:|
| 1. Quantizer (16 embeddings lookup) | 18 ms | 0.5% |
| 2. Pre-conv (k=7) | 16 ms | 0.5% |
| 3. Pre-transformer (8 layers attn) | 30 ms | 0.9% |
| 4. Upsample (2 stages ×4) | 95 ms | 2.8% |
| **5. BigVGAN** (4 blocks + final, total ×480) | **3 240 ms** | **95.3%** |

**Conclusion immédiate** : 86% du pipeline est dans deux blocs (CP loop + BigVGAN).
Toute perf doit attaquer un de ces deux. Le reste est négligeable.

## 2. Pourquoi c'est lent (diagnostic)

### CP : 110 ms/frame, **BW-bound** sur ggml-cpu

15 sub-forwards par frame (1 prefill 2 tokens + 14 decode 1 token via KV cache).
Chaque sub-forward stream ~25 MB de poids f16 par layer × 5 layers = 125 MB.
À 77 GB/s LPDDR5x → 1.6 ms BW pur par sub-forward. **Mesuré 7 ms/sub-forward**, soit
~25% compute et ~75% overhead (ggml_init/free, graph build, alloc work buffers).

Confirmation BW-bound : thread sweep 4 vs 6 vs 8 → CP plat à ±5%. Le compute ne fait
pas la différence, c'est la mémoire qui plafonne.

### BigVGAN : 3.2 s, **compute-bound** sur ggml-cpu NEON

Estimation analytique : ~500 Gops sur le forward complet (conv1d k=7 dilatés +
convtranspose1d avec stride up_rates=[8,5,4,3]). Sur 8 threads NEON 4-wide
~150 GFlops total → ~3.3 s. **Cohérent avec la mesure (3.2 s)** → on est à ~95%
du plafond NEON. Pas de gain à attendre du multi-thread (déjà saturé).

Hot inner ops : `ggml_conv_1d` et `ggml_conv_transpose_1d` qui appellent
mul_mat NEON après im2col. Pas de path HVX/HMX dans ggml-cpu.

### Talker : 33 ms/frame, presque OK

llama.cpp standard decode 1 token. Pas un goulot. La piste HTP prefill talker existe
(`use_htp=true`) mais elle ne gagne que sur le prefill (0.1 s) — la boucle decode
reste CPU. Gain potentiel : <0.05 s. **Pas un levier.**

## 3. Plafonds théoriques par hardware

| Composant | Sur ce qu'on a | Plafond CPU NEON | Plafond HVX V79 | Plafond HMX V79 |
|---|---:|---:|---:|---:|
| CP loop | 3.4 s | ~3.0 s (BW-saturée) | ~1.5 s (×2.2) | ~0.6 s (×5.7) |
| BigVGAN | 3.2 s | ~3.0 s | ~1.7 s (×1.9) | **~0.3 s (×10)** |

**HMX (matmul fp16 tile 32×32) gagne énormément sur BigVGAN** parce que les conv1d
deviennent des im2col + matmul fp16, exactement ce que les tiles HMX font à 1 TFlops
crête par contexte. 4 contextes HMX V79 = ~5 TFlops crête, ~1.5 TFlops réel.

## 4. Leviers triés par ROI (gain × probabilité / effort)

### A. **Streaming pipeline** — gain TTFB, RTF inchangé
- Refactorer pour qu'audio commence à sortir dès que les premières frames du talker
  sont disponibles, plutôt que d'attendre la fin de la phrase.
- Le decoder peut traiter par chunks (causal-ish), mais BigVGAN a un kernel k=7
  → dépendance gauche sur ~3 frames.
- Pipeline talker→CP→decoder en parallèle : temps total ≈ max des trois + overhead
  de chunking → **4-5 s au lieu de 7.9 s pour la même phrase, et TTFB ~500 ms**
  au lieu de ~5 s.
- **Effort** : 1 session de refactor.
- **Risque** : faible. Bit-exact possible.
- **Gain RTF perçu** : massif (du « 5× plus lent que temps réel » au « le son
  commence dans une demi-seconde et continue »).

### B. **CP : ctx ggml réutilisé entre sub-forwards** — réduit overhead
- Actuellement 15× ggml_init/free + 15× graph build par frame.
- Réutiliser un seul ggml_context + ggml_gallocr persistant → graph build une fois,
  re-compute 15 fois.
- Si overhead = 5 ms/sub-forward × 15 = 75 ms/frame, on espère gagner 50 ms/frame.
- **Effort** : ~½ session (~80 lignes de refactor dans cp_forward_cached_step).
- **Risque** : faible. Bit-exact attendu (mêmes ops, juste alloc différente).
- **Gain mesuré** : CP 110 ms → ~60 ms espérés = **RTF total ~2.4** au lieu de 3.07.

### C. **Decoder : ctx ggml réutilisé + buffer mem 12GB→raisonnable**
- BigVGAN alloue 12 GB par appel. Probablement minor mais à vérifier.
- Réutilisation entre frames si on chunke (couplé à A).
- **Gain estimé** : 5-15% sur decoder, soit 0.2-0.5 s.
- **Effort** : ½ session.

### D. **BigVGAN sur backend Vulkan (Adreno)** — gain raisonnable
- Adreno 750 + ggml-vulkan : conv1d devient compute shader.
- Probable gain ×3-4 sur BigVGAN si bien câblé (mais ggml-vulkan + conv1d a des
  trous).
- **Effort** : ~2 sessions (build vulkan, test, fix les ops manquantes).
- **Risque** : moyen (état ggml-vulkan + conv1d mal connu).
- **Gain** : BigVGAN 3.2 s → 1 s = RTF total **~2.0**.

### E. **BigVGAN sur HMX V79** — le gros gain frontière
- Porter conv1d + convtranspose1d en kernels HMX via im2col + matmul fp16 tile.
- Existant : ggml-hexagon backend a déjà MUL_MAT HMX (utilisé pour Qwen3.5 prefill).
  Manque : `supported_op` pour CONV_1D doit retourner true + le kernel im2col HVX.
- **Effort** : 1-2 semaines. Probablement bit-exact perdu (fp16 tile) mais audio
  est tolérant.
- **Gain** : BigVGAN 3.2 s → 0.3-0.5 s = RTF total **~1.0**.
- **Risque** : moyen-élevé (kernel HVX bit-exact n'est pas demandé pour l'audio,
  mais artefacts possibles si quant mal calibrée).

### F. **CP sur HMX V79** — symétrique
- Le CP est un transformer dense 5L 1024-dim, exactement le pattern HMX.
- Port le forward CP sur HTP. ggml-hexagon supporte déjà les matmul HMX pour Qwen3.5.
- **Effort** : 1 session (le forward CP est court, ~200 lignes).
- **Gain** : CP 3.4 s → 0.5-1 s = RTF total **~1.5**.
- **Risque** : faible (path déjà battu côté Qwen3.5).
- **Caveat** : les heads CP (15 × 2048 × 1024 = 30M params) restent CPU côté
  dot-product. Coûtent ~30 M ops × 15 steps = 0.5 G ops/frame, ~5 ms/frame. OK.

### G. **B + F combinés** — chemin « ship-ready avec RTF<1.5 »
- CP overhead réduit (B) + CP sur HMX (F) → CP 3.4 s → ~0.3 s.
- Decoder reste CPU 3.2 s, talker 1 s.
- Total ≈ 4.5 s, RTF **1.7**. Pas <1 mais cap à dépasser.

### H. **B + E + F combinés** — RTF <1 ambitieux
- CP overhead + HMX + BigVGAN HMX → CP 0.3 s + BigVGAN 0.4 s + talker 1 s + prefill 0.1 s = 1.8 s.
- **RTF 0.7**. Cible atteinte.
- **Effort total** : 3-4 semaines.

## 5. Recommandation

Plan ordonné par ROI décroissant :

1. **B. CP ctx réutilisé** (½ session, RTF 3.07 → 2.4, bit-exact, faible risque).
2. **A. Streaming pipeline** (1 session, RTF perçu réduit drastiquement, bit-exact).
3. **F. CP forward sur HMX** (1 session, RTF → ~1.5, faible risque, réutilise du
   travail existant).
4. **E. BigVGAN HMX** (2-3 semaines, RTF → ~0.7, risque qualité audio à valider).

Les étapes 1 et 2 sont des gains certains, courts, sans tester de nouveaux kernels.
Elles font la moitié du chemin. L'étape 3 est le prochain saut « propre », l'étape 4
est le sujet R&D qui fait franchir <1.

**Points de bascule** : si l'étape 1+2 donne RTF 2 avec streaming TTFB ~500 ms,
ça peut suffire pour shipper. RTF<1 n'est pas indispensable si l'audio commence
à jouer rapidement et continue plus vite qu'il ne se consomme **après** le démarrage
(= la queue se vide en cours de route).

## 6. Choses à vérifier / chantiers parallèles

- **HTP prefill talker** : n'a pas marché lors du test (hang 90s). Setup `ADSP_LIBRARY_PATH`
  ou env supplémentaire requis. Pas urgent — gain mineur (~0.05 s).
- **Quant heads/codec_embs CP** (Q8/Q4) : 240 MB de f32 dans s.heads+s.codec_embs.
  Pourrait diminuer BW si les heads (CPU dot-product, pas ggml) deviennent bw-bound.
  Mesuré insignifiant (5 ms/frame) → pas un levier.
- **Decoder en f16** : à vérifier si poids déjà f16 ou f32. Si f32, bascule en f16
  peut diviser BW par 2 si BW-bound. Mais BigVGAN est compute-bound (3.2 s ≈
  plafond NEON), donc gain attendu faible.

## Verdict

RTF<1 atteignable mais demande ~3-4 semaines de travail kernel hexagon (étape E ou F+E).

RTF 2 avec TTFB ~500 ms est atteignable en ~2 sessions de refactor (étapes B+A).
Cela suffit pour démo et probablement app, parce que ce qui compte côté UX c'est
le démarrage rapide + le rythme soutenu, pas la latence end-to-end pure.