Richard Loyer
|
19ac123afa
|
TU sampler tuning : top_p 1.0->0.95 + rep_penalty 1.05->1.10 nouveaux défauts
Validation à l'écoute (panel A/B 4 combos sur 'Bonsoir, comment tu te sens
ce soir ?'). Verdict utilisateur : combinaison TOPP_0.95_REPP_1.10 sonne le
moins robotique.
Analyse complémentaire TU.2 (dump codes via KZTTS_DUMP_CODES=path) sur 4
phrases panel a confirmé :
- code 690 CB0 = attracteur silence (5.9% du panel, doublé systématiquement
en début de phrase, jusqu'à 4 répétitions consécutives mesurées)
- rep_penalty 1.05 trop doux pour casser ces 690 690
- rep_penalty 1.10 plus nucleus 0.95 -> top_p coupe la queue improbable
+ rep défavorise les codes récents -> moins de pause robotique
Nouveaux défauts (tts_engine.h TtsSynthesizeCfg + tts_pipeline env defaults
+ TtsEngine.kt TtsSampling) :
cp_top_p = 0.95f (était 1.0)
cp_rep_penalty = 1.10f (était 1.05)
talker_top_p = 0.95f (était 1.0)
talker_rep_penalty = 1.10f (était 1.05)
cp_temp, top_k, talker_temp/top_k inchangés (0.9, 50).
Mesure panel 4 phrases avec nouveaux défauts + decoder chraac subproc :
'Bonjour Kazeia' : N=29 RTF 2.19
'Bonsoir, comment tu te sens ce soir ?' : N=48 RTF 2.21
'Je rumine la nuit.' : N=34 RTF 2.21
'Comment puis-je t'aider aujourd'hui ?' : N=29 RTF 2.27
RTF stable ~2.2. Compression légère sur phrases courtes (29 vs 33 baseline),
expansion sur phrases interrogatives ('Bonsoir' N=48 vs 41). Cohérent
avec top_p resserré qui choisit des codes plus pertinents.
KZTTS_DUMP_CODES=path ajouté dans tts_engine pour analyse future
(int32 binaire [N,16] time-major).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
2026-05-31 11:18:25 +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 |