Schnelle Inferenz für Sprach- und multimodale Modelle mit SGLang-Omni einrichten

Jeder, der versucht hat, moderne Sprach- oder multimodale Modelle in der Produktion einzusetzen, kennt diesen Schmerz. Das Serving von Text-LLMs ist bereits gut verstanden: Man greift zu vLLM oder SGLang, konfiguriert Batching und kann loslegen. Sobald jedoch Audio in die Pipeline kommt, bricht alles zusammen.

Ein Sprachmodell ist nicht nur ein einzelner Transformer. Zuerst kommt der Audio-Encoder, dann ein autoregressiver Block (der „Denker"), gefolgt von einem Sprachgenerierungsmodul (Talker), und am Ausgang gibt es auch einen Vocoder, der rohe Audio-Tokens zu sauberen 48 kHz zusammenfügt. Jede Stufe hat ihr eigenes Workload-Profil, ihre eigenen Speicheranforderungen und Latenzanforderungen. Zu versuchen, dies in eine Standard-Text-Inferenz-Engine zu quetschen, ist ein sicherer Weg zu höllischen Verzögerungen und instabiler Audio-Generierungs-FPS.

Das SGLang-Team hat eine spezialisierte Lösung für diese Aufgabe veröffentlicht — SGLang-Omni.

Was ist SGLang-Omni

Dies ist eine Runtime für mehrstufige Inferenz von Omni-, Sprach- und TTS-Modellen. Das Projekt bewältigt den schmerzhaftesten Teil: die Verwaltung der komplexen Berechnungspipeline, die Übertragung von Daten zwischen Stufen und die Bereitstellung einer gebrauchsfertigen API, die mit der OpenAI-Spezifikation kompatibel ist.

Das Hauptmerkmal liegt im Konzept der mehrstufigen Runtime. Anstatt zu versuchen, die gesamte Pipeline in einen monolithischen Prozess zu packen, trennt SGLang-Omni die Generierung in isolierte Phasen:

• Vorverarbeitung des eingehenden Streams;
• Encoder-Verarbeitung;
• autoregressive Engine basierend auf dem SGLang-Kernel;
• Decoder und Vocoder, die das endgültige Audio zusammenfügen;
• Ergebnis-Aggregatoren.

Jeder Schritt wird von seinem eigenen Scheduler bedient. Zum Beispiel läuft die Textgenerierung oder die Generierung von Kontroll-Tokens auf SGLangs optimiertem Scheduler mit KV-Cache-Unterstützung, während der Vocoder in einer leichtgewichtigen Streaming-Schleife arbeitet, die Audio-Chunks sofort an den Client liefert.

Datentransfer ohne unnötigen Overhead

Wenn ein Modell auf mehrere Komponenten aufgeteilt ist, wird der Tensor-Transfer zwischen GPUs oder Prozessen oft zum Flaschenhals. Wenn Sie Zwischendaten durch regulären CPU-RAM leiten, wird die Latenz für Echtzeit-Dialoge inakzeptabel.

In SGLang-Omni ist die Transportebene ausgelagert. Die Kontrollebene synchronisiert Anfragen, während die Datenebene durch optimierte Backends überträgt: Shared Memory für lokale Prozesse, NCCL, NIXL und Mooncake für den verteilten Betrieb. Dies hält den Overhead zwischen den Stufen minimal.

Welche Modelle werden standardmäßig unterstützt

Die Auswahl an verfügbaren Modellen ist beeindruckend, besonders angesichts dessen, dass das Repository aktiv weiterentwickelt wird. Es enthält bereits fertige Rezepte (Cookbooks) für beliebte Architekturen:

1. Omni-Chat: Qwen3-Omni und Ming-Omni. Akzeptieren multimodale Eingaben (Text, Audio), geben Text oder Streaming-Sprache aus.
2. Sprachsynthese (TTS): Higgs Audio v3, MOSS-TT (einschließlich der Local Transformer v1.5 Version mit nativen 48 kHz Audio), Fish Speech S2-Pro, Qwen3-TTS, Voxtral TTS, dots.tts und ZONOS2.
3. Musikgenerierung: MiniMax Music 3, das in der Lage ist, einen 32 kHz Stereo-Track aus Text und Stilbeschreibung zusammenzustellen.
4. Spracherkennung und Diarisierung (ASR): Qwen3-ASR, Fun-ASR, ARK-ASR und MOSS-Transcribe-Diarize, das Zeitstempel und Sprecher-Labels im verbose_json-Format platzieren kann.

All dies wird mit vertrauten Endpunkten wie /v1/audio/speech, /v1/audio/transcriptions und /v1/chat/completions bereitgestellt. Wenn Sie bereits einen Client für die OpenAI-API geschrieben haben, wird der Wechsel zu Ihrem eigenen Backend so unkompliziert wie möglich sein.

Schnellstart und Start

Das Paket ist auf PyPI verfügbar, am einfachsten zu installieren über uv oder reguläres pip:

Für die Produktion hat das Projekt seinen eigenen Router (SGLang-Omni Router). Er übernimmt Worker-Gesundheits-/Bereitschaftsprüfungen, Load Balancing über mehrere GPU-Knoten und Request-Routing basierend auf den Fähigkeiten spezifischer Instanzen.

Was die Hardware betrifft, bleibt NVIDIA CUDA das primäre Backend. Aber die Entwickler haben experimentelle Intel GPU (XPU)-Unterstützung über PyTorch XPU hinzugefügt. Qwen3-ASR, Qwen3-TTS und Qwen3-Omni (mit Tensor-Parallelität für den Reasoning-Block) laufen bereits auf Intel Arc-Karten.

Wem dieses Projekt gerade jetzt nützen wird

Wenn Sie einen Sprachassistenten, einen Echtzeit-Übersetzer, einen Call-Transkriptionsdienst mit Sprecherdiarisierung oder eine Content-Dubbing-Plattform aufbauen, müssen Sie das Rad nicht mehr neu erfinden mit FastAPI und rohen Skripten.

Das Projekt ist noch jung, mit mehreren hundert offenen Issues im Repository, und die Dokumentation verweist manchmal auf den Quellcode. Aber es hat ein starkes LMSYS-Team und das SGLang-Ökosystem dahinter, also ist die Architektur solide. Es lohnt sich auf jeden Fall, es auszuprobieren, besonders wenn Sie minimale Time-to-First-Audio-Token in Streaming-Dialogen benötigen.