RealtimeVoiceChat - chat vocal IA en temps réel avec une latence d’environ 500 ms

• Système permettant d’avoir en temps réel des conversations vocales naturelles avec une IA à l’aide du micro du navigateur
• Grâce au flux STT → LLM → TTS, la voix de l’utilisateur est convertie en texte, puis la réponse de l’IA est reconvertie en audio pour lecture
• Les composants clés sont un serveur FastAPI, du streaming WebSocket, des modules de traitement vocal basés sur des pods et divers backends LLM
• Un environnement de déploiement basé sur Docker est fourni, et l’utilisation d’un GPU peut encore réduire la latence et améliorer les performances
• Offre un environnement très personnalisable, avec de nombreuses possibilités de réglages avancés comme la détection d’interruption utilisateur, le changement de modèle ou le choix de la voix

---

Chat vocal IA en temps réel

• Ce projet repose sur une architecture client-serveur conçue pour une conversation vocale bidirectionnelle en temps réel
• L’utilisateur parle dans son navigateur, et l’IA renvoie sa réponse sous forme vocale
• La gestion des interruptions, l’affichage de réponses textuelles partielles et le choix parmi plusieurs TTS sont pris en charge

Flux de fonctionnement principal

1. Entrée vocale : capture de la voix de l’utilisateur dans le navigateur
2. Transmission en streaming : envoi des chunks audio vers le backend Python via WebSocket
3. Reconnaissance vocale : RealtimeSTT convertit la voix en texte
4. Traitement LLM : le texte est transmis au LLM pour générer une réponse
5. Conversion vocale : RealtimeTTS transforme le texte de réponse en audio
6. Lecture de la réponse : le son généré est renvoyé en streaming vers le navigateur
7. Détection d’interruption : les prises de parole de l’utilisateur sont détectées et traitées automatiquement

Fonctionnalités principales

• Conversation vocale en temps réel et aperçu partiel de la transcription/réponse
• Streaming basé sur des chunks audio pour une faible latence
• Prise en charge de la détection de silence statique/dynamique (turn detection)
• Divers backends LLM : Ollama par défaut, OpenAI en option
• Prise en charge de plusieurs moteurs TTS : Kokoro, Coqui, Orpheus
• Interface web fournie : UI en Vanilla JS basée sur la Web Audio API
• Déploiement basé sur Docker Compose

Stack technique

• Backend : Python 3.x, FastAPI
• Frontend : HTML, CSS, JavaScript (Web Audio API)
• Communication : WebSockets
• Conteneurisation : Docker, Docker Compose
• Bibliothèques IA/ML :
  • RealtimeSTT, RealtimeTTS, transformers, torch, torchaudio
  • ollama, openai
• Traitement audio : numpy, scipy

Exigences système et recommandations

• Système d’exploitation : utilisation de Docker recommandée sous Linux (avantageux pour l’intégration GPU)
• Python 3.9+, GPU NVIDIA avec CUDA 12.1 ou supérieur recommandés
• NVIDIA Container Toolkit requis en cas d’utilisation de Docker
• Configurer Ollama ou une clé API OpenAI si nécessaire

Installation

Option A : installation via Docker (recommandée)

1. Cloner le dépôt puis exécuter docker compose build
2. Lancer l’application et Ollama avec docker compose up -d
3. Télécharger séparément un modèle Ollama (ex. : docker compose exec ollama ollama pull ...)
4. Arrêt des services : docker compose down
5. Redémarrage : docker compose up -d

Option B : installation manuelle

1. Configurer un venv Python puis installer les dépendances
2. Installer manuellement PyTorch selon la version de CUDA
3. Exécuter server.py pour démarrer le serveur FastAPI

Exécution

• Ouvrir http://localhost:8000 dans le navigateur
• Autoriser l’accès au micro puis cliquer sur "Start"
• Utiliser "Stop" pour arrêter et "Reset" pour réinitialiser la conversation

Guide de modification de configuration

• Changer le moteur/la voix TTS : modifier server.py et audio_module.py
• Changer le modèle/backend LLM : configurer server.py et llm_module.py
• Changer le modèle STT / les critères de silence : transcribe.py, turndetect.py
• Configuration SSL possible : dans server.py, définir l’activation de HTTPS et les certificats

Licence

• Publié sous licence MIT
• Les moteurs externes comme Coqui relèvent de licences distinctes

[nicewook]

La vidéo de démonstration de l’article original est impressionnante.

1. J’espérais pouvoir avoir une conversation naturelle, et à ce niveau cela semble largement répondre à cette attente.
2. Je voulais aussi pouvoir voir le texte en temps réel pendant la conversation, et cet aspect est également très réussi.
3. J’aimerais que l’IA parle après avoir écouté suffisamment sans me couper la parole. Par exemple, quand elle n’est pas certaine, elle pourrait poser des questions comme « Tu as fini de parler ? » ou « Je peux parler maintenant ? », puis commencer sa réponse de cette manière.
4. Ce serait bien aussi qu’il y ait un mécanisme pour encourager à la fois l’IA et la personne à ne pas s’interrompre mutuellement.

[GN⁺]

Avis Hacker News

• La raison du développement de RealtimeVoiceChat est que la latence de la plupart des interactions vocales avec l’IA était jugée insatisfaisante. Il s’agit d’un système open source conçu pour des conversations vocales locales en temps réel

  • L’objectif est de se rapprocher d’un rythme de conversation naturel
  • Le système atteint environ 500 ms de latence de réponse grâce au streaming de chunks audio via WebSockets, à RealtimeSTT basé sur Whisper, et à RealtimeTTS prenant en charge des moteurs comme Coqui XTTSv2/Kokoro
  • Cela reste possible même en exécutant des modèles locaux plus volumineux comme 24B Mistral via Ollama
  • Principales caractéristiques : conçu pour les LLMs locaux (principalement Ollama, avec un connecteur OpenAI inclus), interruptions possibles en cours de conversation, détection intelligente des tours de parole pour ne pas couper la réflexion de l’utilisateur, configuration Dockerized pour faciliter la gestion des dépendances
  • Un GPU compatible CUDA est nécessaire pour les performances en raison des modèles STT/TTS
  • L’auteur aimerait avoir des retours sur l’approche, les performances, les optimisations potentielles ou les fonctionnalités indispensables pour une bonne expérience d’IA vocale locale
  • Code : https://github.com/KoljaB/RealtimeVoiceChat

• En tant qu’utilisateur de ce type d’outils, c’est rapide, mais cela ne tolère pas les pauses naturelles dans la parole

  • Dans une conversation, nous faisons des pauses longues ou courtes pour réfléchir ou pour d’autres raisons
  • Avec ces outils, dès qu’on s’arrête, l’IA commence immédiatement à parler
  • J’ai vu il y a quelques semaines sur Twitter une démo où l’IA attendait que la personne ait réellement fini de parler. La durée de la pause n’avait pas d’importance
  • Je ne sais pas à quel point ce problème est complexe. Il faudrait peut-être une autre IA pour analyser l’entrée et décider s’il s’agit d’une pause ou non

• Très impressionnant ! La fonction d’interruption a été le moment "wow" (ce n’est pas nouveau, mais c’est surprenant de voir cela aussi bien implémenté en open source)

  • Question sur la fonction d’interruption : comment sont gérés des sons comme "Mmk", "Yes", "Of course", ou une "toux" ?
  • Au-delà du côté flatteur du chat vocal d’OpenAI, ce que je n’aime pas, c’est que le bruit peut arrêter la réponse de l’IA et qu’il n’y a pas de bon moyen de la relancer
  • Arrêter une réponse rapidement, tout en ne le faisant que pour de bonnes raisons, est un problème difficile

• J’ai fait des recherches sur ce sujet il y a environ un an. J’y ai appris quelques faits intéressants

  • Dans les conversations entre humains, la latence médiane entre deux interlocuteurs est de 0 milliseconde. Autrement dit, environ la moitié du temps, un locuteur interrompt l’autre, ce qui rend la latence négative
  • Les humains ne se soucient pas vraiment de la latence lorsqu’ils parlent avec une IA dont ils savent qu’elle est une IA. Ils supposent qu’elle a besoin de temps pour réfléchir. La plupart des utilisateurs considèrent qu’une latence de 1000 ms est acceptable, et 500 ms comme exceptionnel
  • Tous les assistants vocaux ont une latence minimale d’environ 300 ms. C’est parce qu’ils utilisent tous la détection de silence pour décider quand commencer à répondre, et qu’environ 300 ms de silence sont nécessaires pour distinguer clairement cela d’une pause normale du locuteur
  • Alexa dispose d’un réglage qui augmente ce temps d’attente pour les locuteurs lents
  • Dans cette vidéo de démo, on voit que l’IA ne l’interrompt pas. Cela donne une interaction qui ne ressemble pas à une interaction humaine (sans parler de l’intonation vocale maladroite)
  • Les humains traitent les phrases en temps réel et répondent dès qu’ils sont suffisamment confiants d’avoir entendu assez pour en comprendre le sens

• Excellent. En regardant le code source, je trouve intéressant que l’auteur ait implémenté une stratégie personnalisée de détection des tours de parole au lieu d’utiliser Silero VAD. Je me demande pourquoi ce choix a été fait et quels avantages ont été observés

  • Pour ceux qui s’intéressent à l’état actuel de l’écosystème des agents vocaux, Daily (une entreprise de WebRTC) propose un excellent guide et un framework open source avec de nombreux utilitaires
  • Note : je travaille chez Cartesia, qui sert de nombreux cas d’usage d’agents vocaux. Daily est un ami

• Je commence à penser que les LLMs devraient être ajustés pour produire des réponses plus courtes. On leur envoie une phrase brève, et ils renvoient un long paragraphe de texte

  • C’est parfois un bon texte, mais toutes les phrases en entrée n’ont pas besoin d’une réponse sous forme de mini-essai
  • Très beau projet. Il devrait être possible d’ajuster finement le prompt pour modifier la tendance conversationnelle de l’IA

• Je suis surpris que personne ne l’ait mentionné. Cela interagit comme un humain et m’interrompt dans de nombreuses situations lorsqu’il a suffisamment de contexte. La latence est très faible

  • La première fois que je l’ai utilisé, c’était une expérience assez saisissante

• C’est plutôt bon. Ce serait encore mieux avec une voix SOTA

• Impressionnant ! Je pense que c’est la meilleure qualité de synthèse vocale actuellement disponible en open source

  • L’objectif final serait probablement un modèle wave-to-wave continu, sans aucun token de texte

• J’étais en train de travailler sur quelque chose de similaire quand je suis tombé là-dessus. Excellent travail. J’aime beaucoup la démo