Cómo configurar inferencia rápida para modelos de voz y multimodales con SGLang-Omni
Cualquiera que haya intentado implementar modelos modernos de voz o multimodales en producción conoce este dolor. Servir LLMs de texto ya está bien entendido: tomas vLLM o SGLang, configuras el batching, y estás listo. Pero el momento en que el audio entra en el pipeline, todo se desmorona.
Un modelo de voz no es solo un solo transformer. Primero viene el codificador de audio, luego un bloque autorregresivo (el "pensador"), seguido de un módulo de generación de voz (hablador), y en la salida también hay un vocoder que ensambla tokens de audio sin procesar en audio limpio de 48 kHz. Cada etapa tiene su propio perfil de carga de trabajo, requisitos de memoria y demandas de latencia. Intentar meter todo esto en un motor de inferencia de texto estándar es una forma segura de obtener retrasos infernales y FPS de generación de audio inestables.
El equipo de SGLang ha lanzado una solución especializada para esta tarea — SGLang-Omni.
Qué es SGLang-Omni
Este es un runtime para inferencia de múltiples etapas de modelos omni, de voz y TTS. El proyecto maneja la parte más dolorosa: gestionar el pipeline de computación complejo, transferir datos entre etapas y exponer una API lista para usar compatible con la especificación de OpenAI.
La característica principal radica en el concepto de runtime de múltiples etapas. En lugar de intentar meter todo el pipeline en un proceso monolítico, SGLang-Omni separa la generación en fases aisladas:
- preprocesamiento del flujo entrante;
- procesamiento del codificador;
- motor autorregresivo basado en el kernel de SGLang;
- decodificadores y vocoders que ensamblan el audio final;
- agregadores de resultados.
Cada paso es atendido por su propio programador. Por ejemplo, la generación de texto o la generación de tokens de control se ejecutan en el programador optimizado de SGLang con soporte de KV-cache, mientras que el vocoder opera en un bucle de streaming ligero que entrega inmediatamente fragmentos de audio al cliente.
Transferencia de datos sin gastos generales innecesarios
Cuando un modelo se divide en múltiples componentes, la transferencia de tensores entre GPUs o procesos a menudo se convierte en el cuello de botella. Si enruta los datos intermedios a través de RAM CPU regular, la latencia para el diálogo en tiempo real se vuelve inaceptable.
En SGLang-Omni, la capa de transporte está separada. El plano de control sincroniza las solicitudes, mientras que el plano de datos transfiere a través de backends optimizados: memoria compartida para procesos locales, NCCL, NIXL y Mooncake para operación distribuida. Esto mantiene la sobrecarga entre etapas al mínimo.
Qué modelos son compatibles de forma nativa
El conjunto de modelos disponibles es impresionante, especialmente considerando que el repositorio se está desarrollando activamente. Ya incluye recetas listas para usar (cookbooks) para arquitecturas populares:
- Omni-chat: Qwen3-Omni y Ming-Omni. Aceptan entrada multimodal (texto, audio), salida de texto o voz en streaming.
- Síntesis de voz (TTS): Higgs Audio v3, MOSS-TT (incluyendo la versión Local Transformer v1.5 con audio nativo de 48 kHz), Fish Speech S2-Pro, Qwen3-TTS, Voxtral TTS, dots.tts y ZONOS2.
- Generación de música: MiniMax Music 3, capaz de ensamblar una pista estéreo de 32 kHz a partir de texto y descripción de estilo.
- Reconocimiento de voz y diarización (ASR): Qwen3-ASR, Fun-ASR, ARK-ASR y MOSS-Transcribe-Diarize, que puede colocar marcas de tiempo y etiquetas de hablante en formato
verbose_json.
Todo esto se despliega con endpoints familiares como /v1/audio/speech, /v1/audio/transcriptions y /v1/chat/completions. Si ya has escrito un cliente para la API de OpenAI, cambiar a tu propio backend será lo más directo posible.
Inicio rápido y lanzamiento
El paquete está disponible en PyPI, más fácil de instalar a través de uv o pip regular:
Para producción, el proyecto tiene su propio router (SGLang-Omni Router). Maneja verificaciones de salud/disponibilidad de workers, balanceo de carga entre múltiples nodos GPU y enrutamiento de solicitudes según las capacidades de instancias específicas.
En cuanto al hardware, NVIDIA CUDA sigue siendo el backend principal. Pero los desarrolladores han añadido soporte experimental para GPU Intel (XPU) a través de PyTorch XPU. Qwen3-ASR, Qwen3-TTS y Qwen3-Omni (con paralelismo de tensores para el bloque de razonamiento) ya se ejecutan en tarjetas Intel Arc.
Quién encontrará útil este proyecto ahora mismo
Si estás construyendo un asistente de voz, traductor en tiempo real, servicio de transcripción de llamadas con diarización de hablantes, o una plataforma de doblaje de contenido, ya no necesitas reinventar la rueda con FastAPI y scripts sin procesar.
El proyecto todavía es joven, con varios cientos de issues abiertos en el repositorio, y la documentación a veces hace referencia al código fuente. Pero tiene un sólido equipo de LMSYS y el ecosistema de SGLang detrás, por lo que la arquitectura es sólida. Definitivamente vale la pena probarlo, especialmente si necesitas un tiempo mínimo hasta el primer token de audio en diálogos en streaming.
Proyectos relacionados