Kazeia
/
Kazeia-engine
3
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
90 Commits 1 Branch 0 Tags 217 MiB
Commit Graph

3 Commits

Author SHA1 Message Date
Richard Loyer 9ef5e11b53 chantier B TTS #6: P3.4+P3.5 = pipeline complet 100% tablette bout-en-bout 
tts_pipeline.cpp : binaire unique qui orchestre TOUT en un seul process :
  input_ids + x_vector (fixtures)
    -> text_projection + lookups + spéciaux (P3.2) -> prefill_embeds [T, 1024]
    -> Talker engine (libllama, M-RoPE IMROPE, Patch 1+2) -> logits + hidden
    -> sampling top_k+temp sur CB0 (le greedy pur tombe dans un attracteur :
       cb0 répété -> decoder produit du silence. temp=0.9 top_k=50 = défauts
       Python, débloquent l'attracteur)
    -> CP runner (cp_inference, recompute bit-exact) -> CB1..15
    -> sum 16 codecs + tts_pad -> next embed (orchestration ggml-side, bit-exact)
    -> codes [N, 16] -> decoder ggml (libqwen3tts-decoder rebuilt vs ql/ggml,
       evite conflit double-ggml) -> WAV PCM 24kHz

Sortie : Bonjour je m'appelle Kazeia, 32 frames -> 2.56s audio audible
(rms=0.040, range [-0.26, 0.29]). 100% tablette : pas de Python, pas de root,
pas de QNN. Stack unifiee ggml.

Bench tablette CPU 6 threads (sweet spot, 8 = contention scheduler) :
  load total       :  1.12 s  (talker f32 + cp + decoder + fixtures)
  Talker prefill   :  0.10 s
  Loop (N=32)      :  8.57 s   talker_decode=1.01 cp=7.55 (talker 31ms/step, cp 236ms/step)
  Decoder          :  5.32 s   (RTF dec 2.00)
  TOTAL            : 14.00 s pour 2.67s audio -> RTF 5.25

Gros leviers perf restants pour RTF<1 (P3.5 itératif, dehors session) :
- KV cache CP : 15 passes/step recompute O(L^2) -> incremental O(L). Estimation
  gain x5-8 sur CP. Tentative cette session = abandonnee (risque casser bit-exact).
- Decoder ggml : histo chraac 0.96 prouve realisable, faut tuner.
- Threads big cores via taskset (Pad3 SD8Elite 8 cores big, scheduler ne route
  pas tjrs au mieux).

Q8_0 CP teste -> perd la precision (76% codes match vs 100% f16) ; sampling et
CP en f16 reste necessaire (confirme observation rapport TTS avril : modeles RVQ
incompatibles avec quantization).

Decoder ggml rebuilte au passage avec ggml engine : kazeia-tts-decoder-ggml/
build-android-engine/ -> libqwen3tts-decoder.a sans conflit symboles. Patch
mineur build-time, pas de modif source decoder.

P3.4 (libkazeia_tts.so JNI assemblage Kotlin) : reporte en session future, le
code de tts_pipeline.cpp est l'implementation reference a wrapper en JNI.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
 2026-05-28 15:25:00 +02:00
Richard Loyer 746bbe77cd chantier B TTS #5: P3.3 = vrai CP runner intégré (bit-exact) 
cp_inference.h/cpp : extrait de cp_runner.cpp standalone (kazeia-tts-decoder-ggml/),
adapté en module réutilisable. Architecture identique (qwen3 5L, GQA 16/8, head_dim
128, RoPE NEOX theta=1e6, q/k-norm AVANT RoPE, recompute T<=16 sans KV cache).
API : cp_load() + cp_predict(hidden[1024], cb0_emb[1024]) -> int32[15] = CB1..CB15.

cp_validate.cpp : reproduit sur tablette les conditions du standalone cp_runner
-> 495/495 codes match (33/33 frames parfaits) vs cp.generate(do_sample=False)
greedy golden, sur les 33 frames du dump 'Bonjour' historique. CP intégré =
bit-exact au standalone, qui est lui-même bit-exact à PyTorch.

tts_orchestrate.cpp mis à jour : si cp_f16.gguf/cp_heads/cp_codec_embs présents
dans <dump_dir>, le CP est ENABLED et remplace le teacher-forcing CB1..15.
Hidden state Talker capturé via llama_get_embeddings_ith(ctx,-1) après chaque
decode_embeds (pas besoin de re-instrumenter le forward Talker).

Mesure sur 'Bonjour je m'appelle Kazeia' (N=26 frames, audio 2.17s) tablette CPU 4t :
  Talker prefill (T=19) : 0.124 s
  Loop (N=26 steps)     : 7.705 s   talker_decode=0.763, cp=6.942
    per-step talker     : 29.3 ms
    per-step CP (15 pass): 267.0 ms
  Total Talker+CP       : 7.829 s -> RTF talker+cp = 3.61

Le CP est le nouveau goulot (267ms × 15 passes/step). Levier P3.5 = KV cache CP
(recompute -> incremental), threads 8, ou Q8_0 du CP.

CB0 match golden = 3/26 = trajectoire stochastique Python diverge rapidement vs
notre greedy ; PAS un bug CP (cp_validate prouve la conformité bit-exact).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
 2026-05-28 15:11:07 +02:00
Richard Loyer 2e0b145b51 chantier B TTS #3: orchestration ggml-side bit-exact + WAV E2E sur tablette 
Le binaire dist/jni/tts_orchestrate.cpp boucle :
  prefill talker (talker_f32.gguf via engine) -> greedy CB0 depuis logits engine
  -> CB1..15 teacher-forces depuis codes_golden (CP non encore integre, mais
     deja valide bit-exact standalone)
  -> next_embed = talker.tok_embd[CB0] + sum_i cp_codec_embs[i-1, CB(i)] + tts_pad
  -> talker.decodeEmbed(next_embed) -> repeat
  -> dump codes_engine [N=26, 16] sur disque

Resultats end-to-end ('Bonjour je m'appelle Kazeia', N=26 frames, ~2.08s audio) :
  pipeline ggml-side sur tablette (talker engine + decoder existant) :
  - codes engine vs codes Python : 7/26 frames divergent (CB0 only) = sampling
    stochastique Python (subtalker_dosample temp=0.9) vs greedy engine. Attendu.
  - next_embed engine vs step_inputs_py: rmse=0 cos=1.000 a chaque step ou
    CB0 matche -> orchestration sum+pad strictement bit-exact.
  - WAV decoder tablet sur codes_golden vs PY_REF : cos=0.999999, rmse=3.9e-5
    (juste du noise int16 quantization, bit-exact pratique).
  - WAV decoder tablet sur codes_engine vs PY_REF : cos=0.999200, rmse=3.8e-3
    -> divergence audio uniquement du sampling, son audible et coherent.
  - WAV tablet vs host (memes codes) : cos=1.000000 -> decoder ggml deterministe.

Le seul ecart restant (cos=0.9992 engine vs PY_REF) est purement strategique
(sampling vs greedy), pas implementation. Engine ggml-side prouve fonctionnel.

Reste pour P3 finition (sessions suivantes) :
- Integrer le vrai CP runner (cp_runner.cpp) -> remplace teacher-forcing CB1..15
- Speaker Encoder x-vector (8.9M params) OU pre-calcul offline
- BPE tokenizer Qwen3-TTS + text_projection -> production prefill_embeds depuis texte FR
- Assemblage final en JNI (libkazeia_tts ?) utilisable depuis l'app Kotlin

Dump tools: /opt/Kazeia/tts_talker_dump/dump_talker.py (step I/O + logits)
            /opt/Kazeia/tts_talker_dump/dump_talker2.py (pad/bos/eos/codes/tables)

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
 2026-05-28 14:25:18 +02:00