Skip to main content
Liquid AIWebGPUbrowser AI

Liquid AI intègre l'IA audio directement dans le navigateur

Liquid AI a présenté une démo WebGPU exécutant l'ASR et le TTS directement dans le navigateur avec le modèle LFM2.5-Audio-1.5B via ONNX Runtime Web. C'est un signal clé pour les entreprises : l'intégration de l'IA se déplace vers le client, réduisant la latence, les coûts de serveur et les risques de confidentialité.

Contexte Technique

Je me suis plongé dans la documentation de Liquid AI non pas pour la belle démo, mais parce que de telles choses impactent directement l'AI automation côté client. Et il y a beaucoup à explorer ici : l'ASR, le TTS et même les interleaved conversations tournent entièrement dans le navigateur, sans inférence serveur.

Leur stack est très pragmatique : WebGPU, ONNX Runtime Web et un modèle quantifié LFM2.5-Audio-1.5B, préalablement converti en ONNX. La mise en place se fait sans magie : un dépôt cookbook, npm install, npm run dev. La compatibilité est annoncée pour Chrome et Edge 113+.

C'est là que je me suis arrêté et que je me suis dit : d'accord, ce n'est plus un jouet de laboratoire. Lorsque l'audio reste sur l'appareil, le round-trip réseau disparaît, emportant avec lui une partie de la latence et des questions inutiles sur la confidentialité. Pour les scénarios où l'artificial intelligence integration se heurte à des risques juridiques et à l'UX, c'est un argument très fort.

Mais il ne faut pas se faire d'illusions. "Fonctionne dans le navigateur" ne signifie pas "tourne à la perfection pour tout le monde". La vitesse réelle dépendra des pilotes, de l'implémentation de WebGPU, de la bande passante mémoire, de la taille du cache du modèle et de l'endroit exact où le temps est dépensé : le prétraitement, la génération de tokens ou le post-traitement audio.

Dans sa documentation, Liquid met l'accent sur le fait même de l'exécution locale, plutôt que sur de beaux tableaux de benchmarks. Et c'est de bonne guerre : en pratique, un score abstrait m'importe moins que la possibilité de transférer l'ensemble du pipeline vocal au client et de ne pas maintenir un serveur GPU pour chaque réplique.

Ce que cela change pour les entreprises et l'automatisation

Le premier gain est évident : l'architecture devient moins chère. Si une partie des tâches vocales se déplace vers le navigateur, vous pouvez réduire la charge du serveur et construire des AI solutions for business sans payer constamment pour l'inférence de chaque requête audio.

Le second point est plus subtil : la confidentialité cesse d'être une simple diapositive juridique dans une présentation. Pour les assistants internes, les formulaires vocaux, les portails de services et la médecine, le traitement audio local peut grandement simplifier l'AI implementation.

Les perdants ici seront les vieux ordinateurs portables, les GPU faibles et les équipes qui pensent qu'il suffit de "brancher le modèle". En réalité, il faut assembler soigneusement l'architecture de l'IA : mise en cache, graceful fallback vers le CPU ou le serveur, contrôle de la mémoire et UX au premier lancement.

Chez Nahornyi AI Lab, nous résolvons précisément ces tâches concrètes pour nos clients : nous ne nous contentons pas d'insérer l'IA à la mode, nous construisons un circuit fonctionnel adapté aux contraintes du produit, du matériel et de la conformité. Si votre scénario vocal se heurte à des problèmes de latence, de coût ou de confidentialité, décortiquons votre processus et voyons où l'AI solution development fonctionnera réellement, et où il vaut mieux ne pas se leurrer avec l'effet démo.

Dans le contexte du fonctionnement autonome des modèles, nous avons déjà examiné Rust LocalGPT, un outil permettant d'exécuter un assistant IA localement sans dépendre d'API tierces. De telles solutions, tout comme l'inférence basée sur WebGPU, démontrent clairement la tendance actuelle à rapprocher les calculs de l'utilisateur final.

Partager cet article