Comment configurer l'inférence rapide pour les modèles vocaux et multimodaux avec SGLang-Omni

Quiconque a essayé de déployer des modèles vocaux ou multimodaux modernes en production connaît cette difficulté. Servir des LLMs textuels est déjà bien maîtrisé : on choisit vLLM ou SGLang, on configure le batching, et c'est parti. Mais dès que l'audio entre dans le pipeline, tout s'effondre.

Un modèle vocal n'est pas un simple transformeur. D'abord l'encodeur audio, puis un bloc autorégressif (le « thinker »), suivi d'un module de génération de parole (talker), et en sortie un vocodeur qui assemble les tokens audio bruts en audio propre à 48 kHz. Chaque étape a son propre profil de charge, ses besoins en mémoire et ses exigences de latence. Essayer de faire tenir tout cela dans un moteur d'inférence textuelle standard est un moyen infaillible d'obtenir des délais infernaux et une génération audio instable en FPS.

L'équipe SGLang a publié une solution spécialisée pour cette tâche — SGLang-Omni.

Qu'est-ce que SGLang-Omni

Il s'agit d'un runtime pour l'inférence multi-étapes des modèles omni, vocaux et TTS. Le projet gère la partie la plus douloureuse : orchestrer le pipeline de calcul complexe, transférer les données entre les étapes et exposer une API prête à l'emploi, compatible avec la spécification OpenAI.

La fonctionnalité principale repose sur le concept de runtime multi-étapes. Au lieu d'essayer de caser l'ensemble du pipeline dans un processus monolithique, SGLang-Omni sépare la génération en phases isolées :

• prétraitement du flux entrant ;
• traitement par l'encodeur ;
• moteur autorégressif basé sur le kernel SGLang ;
• décodeurs et vocodeurs qui assemblent l'audio final ;
• agrégateurs de résultats.

Chaque étape est servie par son propre scheduler. Par exemple, la génération de texte ou la génération de tokens de contrôle s'exécute sur le scheduler optimisé de SGLang avec support du KV-cache, tandis que le vocodeur fonctionne dans une boucle de streaming légère qui livre immédiatement les chunks audio au client.

Transfert de données sans frais généraux inutiles

Lorsqu'un modèle est réparti sur plusieurs composants, le transfert de tenseurs entre les GPU ou les processus devient souvent le goulot d'étranglement. Si vous routez les données intermédiaires via la RAM CPU classique, la latence pour un dialogue en temps réel devient inacceptable.

Dans SGLang-Omni, la couche de transport est séparée. Le plan de contrôle synchronise les requêtes, tandis que le plan de données transfère via des backends optimisés : mémoire partagée pour les processus locaux, NCCL, NIXL et Mooncake pour le fonctionnement distribué. Cela maintient la surcharge inter-étapes au minimum.

Quels modèles sont pris en charge prêts à l'emploi

L'ensemble des modèles disponibles est impressionnant, d'autant que le dépôt est activement développé. Il inclut déjà des recettes prêtes à l'emploi (cookbooks) pour les architectures populaires :

1. Omni-chat : Qwen3-Omni et Ming-Omni. Acceptent une entrée multimodale (texte, audio), renvoient du texte ou de la parole en streaming.
2. Synthèse vocale (TTS) : Higgs Audio v3, MOSS-TT (y compris la version Local Transformer v1.5 avec audio natif 48 kHz), Fish Speech S2-Pro, Qwen3-TTS, Voxtral TTS, dots.tts et ZONOS2.
3. Génération de musique : MiniMax Music 3, capable d'assembler une piste stéréo 32 kHz à partir d'un texte et d'une description de style.
4. Reconnaissance vocale et diarisation (ASR) : Qwen3-ASR, Fun-ASR, ARK-ASR et MOSS-Transcribe-Diarize, qui peut placer des horodatages et des étiquettes de locuteur au format verbose_json.

Tout cela se déploie avec les endpoints familiers comme /v1/audio/speech, /v1/audio/transcriptions et /v1/chat/completions. Si vous avez déjà écrit un client pour l'API OpenAI, basculer vers votre propre backend sera le plus simple possible.

Démarrage rapide et lancement

Le package est disponible sur PyPI, le plus simple à installer via uv ou pip classique :

Pour la production, le projet dispose de son propre routeur (SGLang-Omni Router). Il gère les vérifications de santé/disponibilité des workers, l'équilibrage de charge entre plusieurs nœuds GPU et le routage des requêtes selon les capacités des instances spécifiques.

En ce qui concerne le matériel, NVIDIA CUDA reste le backend principal. Mais les développeurs ont ajouté la prise en charge expérimentale des GPU Intel (XPU) via PyTorch XPU. Qwen3-ASR, Qwen3-TTS et Qwen3-Omni (avec parallélisme tensoriel pour le bloc de raisonnement) fonctionnent déjà sur les cartes Intel Arc.

Qui trouvera ce projet utile dès maintenant

Si vous construisez un assistant vocal, un traducteur en temps réel, un service de transcription d'appels avec diarisation des locuteurs ou une plateforme de doublage de contenu, vous n'avez plus besoin de réinventer la roue avec FastAPI et des scripts bruts.

Le projet est encore jeune, avec plusieurs centaines d'issues ouvertes dans le dépôt, et la documentation fait parfois référence au code source. Mais il dispose d'une solide équipe LMSYS et de l'écosystème SGLang derrière lui, donc l'architecture est solide. Cela vaut définitivement le coup de l'essayer, surtout si vous avez besoin d'un temps minimal jusqu'au premier token audio dans les dialogues en streaming.