Suite à l'analyse du dev (commit c9e1983) : le gain mesuré (-80% encoder,
-71% decoder/token) vient des options QNN ExecutionProvider, pas de la
migration C++. Donc le patch s'applique aussi à la prod Kotlin actuelle
sans dégeler la stack STT — 4 lignes Kotlin, réversible.
Livrables Action 1 (séparée de la décision migration) :
- dist/PATCH_QNN_PROD.md : explication + diff Kotlin + chiffres attendus
(prod 820 ms -> ~560 ms = -32 % gratuit) + script bench audio Pierre
- dist/patches/whisper_hybrid_engine_qnn.diff : patch précis sur
WhisperHybridEngine.kt (lignes 101, 109, 134 du fichier prod). Ajoute
htp_performance_mode=burst + htp_arch=79 + enable_htp_fp16_precision=1
+ setOptimizationLevel(ALL_OPT) sur les 3 sites encOpts/decOpts.
- dist/patches/bench_qnn_before_after.kt : harness Android pour mesurer
le gain réel sur audios Pierre. 3 runs/audio, médiane, RTF pondéré.
Compare 2 builds app (avant patch / après patch) sur le même corpus.
Décision migration libkazeia_stt CONDITIONNEE à :
1. Action 1 mesurée sur audio Pierre (gain réel patch QNN seul)
2. A/B accuracy CER/WER lib unifiée vs prod patchée (in-app uniquement,
pas mesurable standalone)
Bénéfice résiduel migration après patch QNN prod : ~110 ms total + 168 MB
RAM + code unifié. Reste valable mais beaucoup moins fort que les chiffres
initiaux. Le dev a raison de séparer les décisions.
Mémoire à mettre à jour : project_stt_qnn_options_win.
dbd4f3d944