Pouvoir créer des intégrations externes de TTS type « Gradium TTS », « Whisper », etc…
La PR côté Gladys :
La PR côté SDK :
Hello, sur ce sujet je me demandais comment tu voyais le truc pour des modèles locaux (que ce soit vocaux ou textes), sachant que les containers des intégrations externes sont limités en cpu/ram. Il faut que l’utilisateur lance un serveur de tts sur sa machine puis lance une intégration externe qui se connecte dessus ? Donc on ne serait plus sur du 1-click intégration.
Ou est ce qu’on peut faire une exception d’isolation pour ces intégrations là ?
Merci pour la question, elle est légitime, et je pense qu’il faut distinguer deux niveaux.
Les limites que tu cites ne concernent que le conteneur principal de l’intégration, celui qui parle au core via WebSocket. Il est effectivement bridé à 0,5 CPU et 256 Mo, et c’est voulu : une intégration ne doit jamais pouvoir affamer Gladys sur un mini-PC.
Mais le framework prévoit déjà, dans le manifeste, des sous-conteneurs avec leurs propres limites, pensés à l’origine pour le cas Frigate :
memory_mb: de 32 à 4096 Mocpu: de 0,1 à 2 CPUshm_mb: de 64 à 512 Modevices: accèsgpu,coral-usb,coral-pcieouvideo, chaque classe étant accordée (ou refusée) individuellement par l’utilisateur, et révocable à tout moment
Ces valeurs sont affichées sur l’écran d’installation, et c’est l’utilisateur qui accepte en connaissance de cause avant d’installer.
Concrètement, une intégration “Piper TTS” ou “Kokoro TTS” serait donc un conteneur principal léger (le pont avec Gladys) plus un sous-conteneur qui fait tourner le modèle, avec 1 ou 2 Go de RAM et le GPU si l’utilisateur l’accorde. Installation en un clic, pas de serveur à lancer à la main, et aucune exception d’isolation à prévoir : le mécanisme existe déjà.
Pour ce qui dépasse ces bornes (un gros modèle vocal qui veut 8 Go et 4 cœurs), là oui, le modèle assumé est “l’intégration est un client vers un serveur que tu héberges toi-même”. C’est exactement le fonctionnement de l’IA locale aujourd’hui avec Ollama ou un endpoint compatible OpenAI, et je trouve ça cohérent : quelqu’un qui fait tourner ce type de modèle chez lui a le matériel et sait lancer un conteneur. Ça ne s’adresse pas à l’utilisateur lambda.
Et pour le grand public, le chemin reste Gladys Plus : zéro configuration, zéro matériel, et la PR garde le repli automatique sur Gladys Plus si aucun fournisseur local n’est configuré 
D’accord merci, je vais essayer avec le sous container pour un accès simplifié pour l’utilisateur et ensuite on verra pour plus. Il nous suffira alors d’une intégration externe compatible API OpenAI et presque tous les services d’IA seront gérés c’est trop cool 