Come configurare l'inferenza rapida per modelli vocali e multimodali con SGLang-Omni
Chiunque abbia provato a distribuire modelli vocali o multimodali moderni in produzione conosce questo problema. Servire LLM testuali è ormai una pratica consolidata: si prende vLLM o SGLang, si configura il batching e si è pronti. Ma nel momento in cui l'audio entra nella pipeline, tutto crolla.
Un modello vocale non è un singolo transformer. Prima c'è l'encoder audio, poi un blocco autoregressivo (il "thinker"), seguito da un modulo di generazione del parlato (talker), e in output c'è anche un vocoder che assembla i token audio grezzi in audio pulito a 48 kHz. Ogni stadio ha il proprio profilo di carico di lavoro, requisiti di memoria e richieste di latenza. Cercare di inserire tutto questo in un motore di inferenza testuale standard è un modo sicuro per ottenere ritardi infernali e FPS di generazione audio instabili.
Il team di SGLang ha rilasciato una soluzione specializzata per questo compito — SGLang-Omni.
Cos'è SGLang-Omni
Si tratta di un runtime per l'inferenza multi-stadio di modelli omni, vocali e TTS. Il progetto gestisce la parte più difficile: coordinare la pipeline di calcolo complessa, trasferire i dati tra gli stadi ed esporre un'API pronta all'uso compatibile con le specifiche OpenAI.
La caratteristica principale risiede nel concetto di runtime multi-stadio. Invece di cercare di racchiudere l'intera pipeline in un processo monolitico, SGLang-Omni separa la generazione in fasi isolate:
- preprocessing del flusso in entrata;
- elaborazione dell'encoder;
- motore autoregressivo basato sul kernel SGLang;
- decoder e vocoder che assembnano l'audio finale;
- aggregatori dei risultati.
Ogni passaggio è gestito dal proprio scheduler. Ad esempio, la generazione di testo o la generazione di token di controllo vengono eseguite sullo scheduler ottimizzato di SGLang con supporto KV-cache, mentre il vocoder opera in un loop di streaming leggero che consegna immediatamente i chunk audio al client.
Trasferimento dei dati senza overhead non necessario
Quando un modello è distribuito su più componenti, il trasferimento di tensori tra GPU o processi spesso diventa il collo di bottiglia. Se si instrada i dati intermedi attraverso la RAM CPU normale, la latenza per il dialogo in tempo reale diventa inaccettabile.
In SGLang-Omni, il layer di trasporto è separato. Il piano di controllo sincronizza le richieste, mentre il piano dati trasferisce attraverso backend ottimizzati: memoria condivisa per processi locali, NCCL, NIXL e Mooncake per il funzionamento distribuito. Questo mantiene l'overhead inter-stadio al minimo.
Quali modelli sono supportati out of the box
L'insieme di modelli disponibili è impressionante, soprattutto considerando che il repository è in fase di sviluppo attivo. Include già ricette pronte all'uso (cookbook) per architetture diffuse:
- Omni-chat: Qwen3-Omni e Ming-Omni. Accettano input multimodale (testo, audio), producono testo o parlato in streaming.
- Sintesi vocale (TTS): Higgs Audio v3, MOSS-TT (incluse la versione Local Transformer v1.5 con audio nativo a 48 kHz), Fish Speech S2-Pro, Qwen3-TTS, Voxtral TTS, dots.tts e ZONOS2.
- Generazione di musica: MiniMax Music 3, capace di assemblare una traccia stereo a 32 kHz da testo e descrizione dello stile.
- Riconoscimento vocale e diarizzazione (ASR): Qwen3-ASR, Fun-ASR, ARK-ASR e MOSS-Transcribe-Diarize, che può inserire timestamp e etichette dei parlanti nel formato
verbose_json.
Tutto questo viene distribuito con endpoint familiari come /v1/audio/speech, /v1/audio/transcriptions e /v1/chat/completions. Se hai già scritto un client per l'API OpenAI, passare al proprio backend sarà il più semplice possibile.
Quick Start e avvio
Il pacchetto è disponibile su PyPI, più facile da installare tramite uv o pip normale pip:
Per la produzione, il progetto ha il proprio router (SGLang-Omni Router). Gestisce i controlli di salute/prontezza dei worker, il load balancing tra più nodi GPU e il routing delle richieste basato sulle capacità di istanze specifiche.
Per quanto riguarda l'hardware, NVIDIA CUDA rimane il backend principale. Ma gli sviluppatori hanno aggiunto il supporto sperimentale per GPU Intel (XPU) tramite PyTorch XPU. Qwen3-ASR, Qwen3-TTS e Qwen3-Omni (con parallelismo tensoriale per il blocco di ragionamento) funzionano già su schede Intel Arc.
Chi troverà questo progetto utile adesso
Se stai costruendo un assistente vocale, un traduttore in tempo reale, un servizio di trascrizione chiamate con diarizzazione del parlante o una piattaforma di doppiaggio di contenuti, non hai più bisogno di reinventare la ruota con FastAPI e script grezzi.
Il progetto è ancora giovane, con diverse centinaia di issue aperte nel repository, e la documentazione a volte fa riferimento al codice sorgente. Ma ha un forte team LMSYS e l'ecosistema SGLang alle spalle, quindi l'architettura è solida. Vale sicuramente la pena provarlo, soprattutto se hai bisogno di un time-to-first-audio-token minimo nei dialoghi in streaming.
Progetti correlati