Lancement de Gemini 3.1 Flash Live — et ce que Nextain préparait
Aujourd'hui, Gemini 3.1 Flash Live a été lancé. Le timing étant étrangement propice, nous avons décidé de dévoiler dès maintenant une technologie que nous préparions, bien qu'elle soit encore incomplète. Naia OS prenait déjà en charge Gemini Live via les comptes Naia et le fournisseur Google, et nous avons immédiatement appliqué Gemini 3.1 Flash Live. Vous pouvez le constater dans la vidéo ci-dessous.
Ces modèles sont en fait appelés S2S, ou modèles Omni, et ils permettent des conversations plus rapides et plus naturelles que les pipelines STT, LLM et TTS traditionnels.
Modèles de conversation vocale en temps réel (S2S, modèle omni) similaires au processus d'apprentissage de la parole humaine
Le mode vocal de GPT-4o, Gemini Live et MiniCPM-o en sont des exemples représentatifs. Ce sont des modèles qui conversent non pas par texte, mais par la voix, en temps réel, et même avec des émotions. En anglais, on les appelle généralement Speech to Speech (S2S) ou Omni Model. Je pensais qu'ils ressemblaient bien plus à des humains que les modèles unidirectionnels existants de STT (modèle de conversion de la voix en texte) ou de TTS (modèle de conversion du texte en voix). La raison pour laquelle les personnes malentendantes ont du mal à apprendre à parler est qu'elles ne peuvent pas entendre leur propre production vocale, ce qui rend l'apprentissage de la parole difficile.
J'ai donc jugé que c'était l'avenir des modèles de conversation vocale et que cela deviendrait la norme. J'ai supprimé les options de configuration individuelles de STT/TTS et les ai intégrées dans un 'modèle de conversation en direct', en ajoutant l'API Gemini Live et gpt-4o-realtime-preview. Cependant, comme les deux API sont payantes, nous avons indiqué 'TTS Only' pour les utilisateurs gratuits et inclus Edge dans la sélection des modèles de conversation. C'est ainsi que la version 0.1.2 est sortie récemment (hier). J'ai intégré l'API Gemini Live avec le compte Naia et effectué des tests réels, et la réactivité de la conversation, en termes de feedback émotionnel et de vitesse de réponse, était très satisfaisante.
Malentendu sur les modèles de conversation vocale en temps réel, que je considérais simplement comme des modèles STT/TTS
Cependant, il y avait là un grand malentendu. J'avais compris l'API Gemini Live comme un modèle intégré STT/TTS de nouvelle génération, mais j'ai découvert plus tard qu'un modèle LLM spécifique, à savoir Gemini 2.5 Flash, y était intégré et qu'il n'était pas possible de changer de LLM.
MiniCPM-o-4.5, un modèle de conversation vocale en temps réel utilisable en local
La raison pour laquelle j'ai réalisé ce malentendu est que Naia vise à prendre en charge des modèles locaux accessibles aux utilisateurs. J'ai découvert cela en cherchant et en appliquant un modèle de conversation vocale en temps réel qui pourrait fonctionner sur une carte graphique de type RTX-3090. Les premiers candidats étaient Moshi, Qwen3-Omni-30b et MiniCPM-o-4.5. Moshi est un pionnier dans ce domaine en open source, mais nous ne l'avons pas choisi car il prend principalement en charge l'anglais/français et sa communauté n'est pas très active. Qwen3-omni-30b offre des performances excellentes et très récentes, mais il était hors de portée pour une seule RTX 3090 avec 24 Go de VRAM et n'était pas encore validé, nous l'avons donc exclu. Finalement, nous avons opté pour MiniCPM-o. Bien qu'il ne prenne pas encore en charge le coréen, nous avons jugé qu'avec un certain investissement, il serait possible d'ajouter des langues via le fine-tuning, et comme il prend en charge l'audio de référence, il serait possible d'implémenter le TTS souhaité par l'utilisateur.
De plus, sa petite taille me faisait penser qu'en le faisant fonctionner avec Qwen3-omni-30b-a3b sur la VRAM restante d'une carte de 24 Go, on pourrait considérablement améliorer les performances du LLM, même sur une RTX-3090. Qwen3-omni est un modèle de conversation vocale en temps réel (modèle Omni) comme mentionné précédemment, mais la raison pour laquelle nous ne l'avons pas adopté est que la sortie vocale était corrompue lors de la quantification, ce qui le rendait inutilisable sur les GPU grand public de 24 Go. Cependant, en tant que LLM, les modèles quantifiés sont réputés pour offrir de bonnes performances.
J'ai donc déployé MiniCPM-o sur un GPU local (RunPod RTX 3090) et l'ai connecté à l'application Naia via un serveur de pont Websocket. Ce que j'ai découvert en cours de route, c'est que le modèle ne 'crachait' pas ce qu'il entendait. Mais le fait crucial que j'ai appris ici est que le modèle Qwen3-8B intégré répondait, et que le modèle omni était entraîné de bout en bout, le rendant non remplaçable. Autrement dit, il serait plus approprié d'appeler MiniCPM-o, Qwen3-8b-omni. Plus précisément, il utiliserait Whisper-medium pour l'écoute, Qwen3-8b pour le 'cerveau', CosyVoice2 pour la synthèse vocale et SigLip2 pour la vision. Ces différents modèles seraient ensuite assemblés et réentraînés avec des données multimodales. En gros, il s'agit de fine-tuning, mais l'échelle des données multimodales est si vaste que les coûts peuvent s'élever à des dizaines, voire des centaines de milliards de wons. Il y a eu beaucoup de discussions récemment en Corée sur la question de savoir si c'était 'from scratch' ou non, et cela semble indiquer que la véritable montagne à gravir n'est pas seulement le 'from scratch'.
(→ Journal d'expérimentation MiniCPM-o)
MiniCPM-o-4.5, le défi du code Claude pour le support de vllm-omni
Cependant, même le Qwen3-8b intégré étant considéré comme équivalent à GPT-4o, je ne pouvais pas l'ignorer. De plus, avec la possibilité de référence vocale et de fine-tuning du LLM, j'ai jugé que c'était un modèle que Nextain, qui vise une IA souveraine, devait absolument poursuivre. J'ai forké vllm et l'ai déployé sur RunPod, mais il nécessitait 48 Go de VRAM. J'ai passé presque deux jours à le faire tourner. Ce n'est que plus tard que j'ai découvert qu'il existait un projet séparé appelé vllm-omni, et que quelqu'un était déjà en train de travailler sur MiniCPM-o-4.5. Nous avons donc commenté que nous soutiendrions les tests l3. (→ vllm-omni #1182) Il n'y a pas encore eu de réponse, et en attendant, nous avons continué nos tentatives en interne basées sur vllm-omni.
Cette fois, nous avons abordé la tâche avec une prudence particulière. Auparavant, j'avais soumis une PR générée par du code Claude à un autre projet open source, avec une analyse IA incomplètement vérifiée, et j'avais été sévèrement critiqué. L'analyse du code était incomplète, les règles de la communauté n'avaient pas été respectées, et j'avais même créé quelque chose en dehors du périmètre du projet, ce qui était tout à fait normal. Cette fois, nous avons donc recueilli le contexte du point de vue de l'upstream du dépôt et avons effectué des révisions contradictoires répétées. Ce n'est qu'alors que nous avons déclaré un 'clean pass', avons vérifié que la conversation fonctionnait en l'attachant à naia-os, et avons créé et révisé la documentation pour la contribution à l'upstream.
Mais RunPod est tombé en panne et aujourd'hui, en essayant de le relancer, cela ne fonctionne toujours pas. Les notes incomplètes que j'avais prises pendant le travail m'ont rattrapé. Impossible de vérifier le runtime, donc impossible de reproduire. J'ai fouillé tous les enregistrements des sessions précédentes pour les retrouver, et j'étais en train de reproduire et de modifier les enregistrements à nouveau, quand j'ai finalement découvert un autre problème critique et j'ai dû tout arrêter. J'avais utilisé un certain modèle parce qu'il était nouveau et ne correspondait pas aux autres modèles de vllm-omni, et tout s'est cassé avec la mise à jour de vllm-omni. L'analyse a révélé un échec du harnais et du contrôle du contexte, ce qui m'a obligé à rédiger un autre rapport intermédiaire. Sur cette base, j'ai de nouveau fait modifier le contexte et le harnais, et j'ai effectué une analyse répétée du code au lieu d'utiliser le coûteux RunPod. ㅜㅜ
https://github.com/nextain/vllm-omni/blob/main/.agents/docs/minicpm-o-midterm-review.md
J'aurais aimé vous montrer une vidéo de MiniCPM-o-4.5 en fonctionnement, en même temps que l'annonce du lancement de Gemini 3.1 Flash Live aujourd'hui. Mais y arriver du premier coup est vraiment difficile. Il est actuellement 3h30 du matin. L'objectif principal de ce travail est la réalisation d'un écosystème open source AI-native, une expérimentation visant à montrer que l'IA peut contribuer correctement à l'open source sans 'ai slop'. La semaine prochaine, j'ai prévu d'emprunter des cartes graphiques, donc je pense que la situation sera un peu plus facile.
Si des travaux supplémentaires sont effectués, je partagerai également si la référence audio ou le fine-tuning du LLM sont possibles.
Références
- Gemini 3.1 Flash Live — Fiche modèle (Google DeepMind)
- Speech-to-Speech Models in 2026: Three Architectural Bets — Comparaison des architectures de modèles vocaux intégrés
- Introducing gpt-realtime — Simon Willison — Analyse du modèle gpt-realtime
- GPT-4o vs. GPT-4.1: All the differences — Différences de rôle entre les modèles
- Résultats d'expérimentation MiniCPM-o (GitHub Issue)
- Refonte de l'interface utilisateur des paramètres (GitHub Issue)
- Conception du pipeline STT/TTS (GitHub Issue)
