# Synthèse vocale Kokoro sur CPU

Service interne `kokoro-tts:8000`, voix française féminine `ff_siwis`.
Les poids sont embarqués dans l'image ; le modèle est chargé et préchauffé au
démarrage. Aucun GPU n'est demandé. Le manifeste cible le nœud
`bureau.local.pentou.ovh` dans le namespace `localai` (à adapter ailleurs).

Depuis la racine du dépôt :

```sh
oc apply -f tts-service/openshift.yaml
oc start-build kokoro-tts -n localai --from-dir=tts-service --follow
```

Après réussite du build, mettre à jour le Deployment `kokoro-tts`, conteneur
`tts`, avec le digest indiqué par l'ImageStreamTag `kokoro-tts:cpu`, puis vérifier
son rollout. Le manifeste initial utilise le tag `cpu` ; il ne configure pas
de déclencheur automatique pour les builds suivants.

API : POST `/v1/audio/speech`, JSON `input` (1 à 300 caractères), `voice`
(`ff_siwis`), réponse WAV PCM16 mono 24 kHz. GET `/healthz` devient disponible
après préchauffage. Une génération à la fois ; HTTP 429 si occupé.

`check_service.py` peut être exécuté via stdin dans le pod Satoko. Il vérifie
la connectivité, le format WAV, la validation de voix et mesure la génération
de trois phrases sans publier sur Discord.

Mesures sur Ryzen 9 5950X, limite 4 CPU : 1,44 / 2,53 / 2,69 secondes de requête
pour 3,13 / 5,75 / 5,53 secondes d'audio. Elles excluent STT, LLM et Discord.
`requirements-deployed.txt` est l'inventaire de l'image testée ; le Dockerfile
installe PyTorch CPU explicitement puis les dépendances de `requirements.txt`.

La NetworkPolicy autorise seulement les pods `app=satoko-chatbot` du même
namespace à accéder au service. Aucune route publique n'est créée.