Kazeia-engine

Commit Graph

Author	SHA1	Message	Date
Richard Loyer	d6acf378d5	POC streaming TTFB ÷4-6 (KZTTS_STREAM_CHUNK=K) Concept validé : decoder appelé incrementalement sur codes accumulés tous les K frames. Premier appel donne TTFB rapide. TtsSynthesizeResult ajoute ttfb_s + n_chunks. tts_engine_synthesize détecte KZTTS_STREAM_CHUNK > 0 et appelle decoder.forward(codes_so_far) tous les K codes, accumule la portion nouvelle dans wav_stream. Mesure Pad3 phrase 'Bonjour Kazeia' (33 frames) : baseline : TTFB 6.80s, RTF 2.47 KZTTS_STREAM_CHUNK=8 : TTFB 1.90s (-72%), 5 chunks, total RTF 8.67 (×3.5 cost) KZTTS_STREAM_CHUNK=4 : TTFB 1.13s (-83%), 9 chunks, total RTF 13.82 (×5.6 cost) Limitations connues du POC : 1. Total time explose : recompute decoder sur N_so_far à chaque chunk = somme des coûts O(N_chunks × N_avg) au lieu de O(N_total). 2. WAV pas bit-exact vs baseline : decoder.forward(K) ne match pas le prefix de decoder.forward(N). Probable conv_transpose_1d qui regarde au-delà du strict causal kernel/stride. À comparer à l'oreille. POC opt-in (KZTTS_STREAM_CHUNK=0 par défaut = path baseline intact). Pour rendre utilisable en prod (sessions suivantes) : - Refactor decoder avec state KV cache (pre_transformer en KV cache style comme cp_forward_cached_step + BigVGAN avec context buffer ~5 frames input) - Threading 2-thread : generator (talker+CP) en parallèle de decoder - Cible : TTFB ~500ms, total time ≈ baseline + overhead minimal Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-29 22:56:14 +02:00
Richard Loyer	930f3c8c1f	chantier B TTS #11 : libkazeia_tts.so + Kotlin wrapper, JNI validé bout-en-bout Refactor: tts_engine.{h,cpp} = API publique de l'engine TTS (load une fois, synthesize N fois, free). État load-once dans struct TtsEngine (talker model+ctx, CPState, Decoder, KzTextTokenizer, fixtures + embeds spéciaux + role_proj pré-calculé). KV cache talker reset via llama_memory_clear au début de chaque synthesize -> appels indépendants. tts_pipeline.cpp devient un thin CLI dessus (refonte sans changement de sortie : WAV md5 identique au pré-refactor sur 'Bonjour je m'appelle Kazeia'). JNI bridge: kazeia_tts_jni.cpp expose 3 fonctions : Java_com_kazeia_tts_TtsJni_nativeLoad / Synthesize / Free Signatures alignées avec TtsEngine.kt (companion loadLibrary 'kazeia_tts'). Build: build_kazeia_tts.sh -> b-jni/libkazeia_tts.so (~900 KB). Test_engine_2calls (sans JNI) : 3 synth sur même instance, KV reset OK, 2 appels identiques -> WAV md5 identique, appel 3 différent -> codes différents. Test_jni_tts (harness JNI sans VM Java) : dlopen libkazeia_tts.so, JNIEnv mock minimal (GetStringUTFChars/Release + NewIntArray/SetIntArrayRegion), appels load + 2 synth + free. WAV md5 identiques aux runs directs. exit=0. Empreinte tablette mesurée: ~3.5 GB par instance (talker f32 1.6 GB + CP f16 mixte 250 MB + decoder 325 MB + vocab Qwen3 vocab_only 50 MB + fixtures text_embed/tp_* 1.2 GB). Une instance par process. RTF stable autour de 3.0 (CPU 6t), inchangé vs avant refonte. Reste sur la liste initiale : tuning sampling (itératif à l'oreille). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-28 21:54:21 +02:00

Author

SHA1

Message

Date

Richard Loyer

d6acf378d5

POC streaming TTFB ÷4-6 (KZTTS_STREAM_CHUNK=K)

Concept validé : decoder appelé incrementalement sur codes accumulés tous
les K frames. Premier appel donne TTFB rapide.

TtsSynthesizeResult ajoute ttfb_s + n_chunks. tts_engine_synthesize
détecte KZTTS_STREAM_CHUNK > 0 et appelle decoder.forward(codes_so_far)
tous les K codes, accumule la portion nouvelle dans wav_stream.

Mesure Pad3 phrase 'Bonjour Kazeia' (33 frames) :
  baseline           : TTFB 6.80s, RTF 2.47
  KZTTS_STREAM_CHUNK=8 : TTFB 1.90s (-72%), 5 chunks, total RTF 8.67 (×3.5 cost)
  KZTTS_STREAM_CHUNK=4 : TTFB 1.13s (-83%), 9 chunks, total RTF 13.82 (×5.6 cost)

Limitations connues du POC :
1. Total time explose : recompute decoder sur N_so_far à chaque chunk =
   somme des coûts O(N_chunks × N_avg) au lieu de O(N_total).
2. WAV pas bit-exact vs baseline : decoder.forward(K) ne match pas le
   prefix de decoder.forward(N). Probable conv_transpose_1d qui regarde
   au-delà du strict causal kernel/stride. À comparer à l'oreille.

POC opt-in (KZTTS_STREAM_CHUNK=0 par défaut = path baseline intact).

Pour rendre utilisable en prod (sessions suivantes) :
- Refactor decoder avec state KV cache (pre_transformer en KV cache style
  comme cp_forward_cached_step + BigVGAN avec context buffer ~5 frames input)
- Threading 2-thread : generator (talker+CP) en parallèle de decoder
- Cible : TTFB ~500ms, total time ≈ baseline + overhead minimal

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

2026-05-29 22:56:14 +02:00

Richard Loyer

930f3c8c1f

chantier B TTS #11 : libkazeia_tts.so + Kotlin wrapper, JNI validé bout-en-bout

Refactor: tts_engine.{h,cpp} = API publique de l'engine TTS (load une fois,
synthesize N fois, free). État load-once dans struct TtsEngine (talker
model+ctx, CPState, Decoder, KzTextTokenizer, fixtures + embeds spéciaux
+ role_proj pré-calculé). KV cache talker reset via llama_memory_clear
au début de chaque synthesize -> appels indépendants.

tts_pipeline.cpp devient un thin CLI dessus (refonte sans changement de
sortie : WAV md5 identique au pré-refactor sur 'Bonjour je m'appelle Kazeia').

JNI bridge: kazeia_tts_jni.cpp expose 3 fonctions :
  Java_com_kazeia_tts_TtsJni_nativeLoad / Synthesize / Free
Signatures alignées avec TtsEngine.kt (companion loadLibrary 'kazeia_tts').
Build: build_kazeia_tts.sh -> b-jni/libkazeia_tts.so (~900 KB).

Test_engine_2calls (sans JNI) : 3 synth sur même instance, KV reset OK,
2 appels identiques -> WAV md5 identique, appel 3 différent -> codes
différents.

Test_jni_tts (harness JNI sans VM Java) : dlopen libkazeia_tts.so, JNIEnv
mock minimal (GetStringUTFChars/Release + NewIntArray/SetIntArrayRegion),
appels load + 2 synth + free. WAV md5 identiques aux runs directs. exit=0.

Empreinte tablette mesurée: ~3.5 GB par instance (talker f32 1.6 GB + CP
f16 mixte 250 MB + decoder 325 MB + vocab Qwen3 vocab_only 50 MB + fixtures
text_embed/tp_* 1.2 GB). Une instance par process.

RTF stable autour de 3.0 (CPU 6t), inchangé vs avant refonte.

Reste sur la liste initiale : tuning sampling (itératif à l'oreille).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

2026-05-28 21:54:21 +02:00

2 Commits