Zum Inhalt springen
// Audio & Musik 14 Min. Lesezeit

SGLang Omni unterstützt Fish Audio Drama 3 in INT4: Speicherbedarf, Architektur und Enterprise-Serving im Überblick

Mindverse News

KI-gestützt erstellt 5 Quellen Originalmeldung: x.com Arbeitsweise

KI-generierte Illustration: SGLang Omni unterstützt Fish Audio Drama 3 in INT4: Speicherbedarf, Architektur und Enterprise-Serving im Überblick
KI-generierte Illustration

Das Wichtigste in Kürze

  • Das Inferenz-Framework SGLang Omni unterstützt ab sofort offiziell eine INT4-quantisierte Version des Text-to-Speech-Modells Fish Audio Drama 3, wodurch der Speicherbedarf für die Modellgewichte der Engine von 37,0 GB auf 20,8 GB sinkt [1].
  • Laut Angaben aus dem SGLang-Entwicklerumfeld bleibt die Qualität beim Voice-Cloning in der internen Seed-TTS-EN-Evaluierung trotz der INT4-Komprimierung auf einem vergleichbaren Niveau wie beim Ausgangsmodell [1].
  • Technisch basiert Drama 3 auf einem Mixture-of-Experts-Backbone mit 35 Milliarden Gesamtparametern (3 Milliarden aktiv pro Token), hybrider Attention und einem kausalen Codebook-MTP-Audiodecoder mit zehn Codebooks [2, 4].
  • Für die Audioproduktion führt das Modell Funktionen wie wortgenaues Infilling, mehrstufige Regieanweisungen über vorherige Takes sowie die Steuerung von bis zu 16 Sprechern innerhalb eines einzigen Skripts ein [2, 5].
  • Herstellerseitige Benchmarks auf einer NVIDIA H200 weisen für einzelne Streams eine mediane Time to First Audio (TTFA) von 88,9 Millisekunden aus; die Auslagerung des Vocoders auf eine zweite GPU steigert den Durchsatz bei 256 parallelen Streams um rund 72 Prozent [2, 3, 4].
  • Während die Modellgewichte öffentlich auf Hugging Face zugänglich sind, unterliegen sie der speziellen Fish Audio Community License und erfordern für volle Kernel-Beschleunigung zwingend NVIDIA-Hopper-Hardware mit Compute Capability 9.0 [2, 4, 5].
// Inhalt · 8 Abschnitte
  1. INT4-Quantisierung senkt Speicherhürde für Fish Audio Drama 3
  2. Architektur im Detail: 35B-A3B Mixture-of-Experts und Codebook-MTP
  3. Funktionsumfang für die Audioproduktion: Wortgenaues Infilling und Regie-Iterationen
  4. Speicherökonomie: Warum auch 20,8 GB in der Praxis Rechenzentrums-GPUs erfordern
  5. API-Integration, Prompt-Grenzwerte und Risiken bei Non-Streaming-Anfragen
  6. Skalierung und SPG-Topologie: Leistungsdaten auf NVIDIA H200
  7. Low-Level-Optimierungen: CUDA-Graphen, Triton-Kernels und Hopper-Bindung
  8. Lizenzierung, API-Kosten und strategische Einordnung für B2B-Entscheider
  9. Quellen

INT4-Quantisierung senkt Speicherhürde für Fish Audio Drama 3

Kurz nach der Bereitstellung der offenen Modellgewichte von Fish Audio Drama 3 und der unmittelbaren Day-0-Integration in das Serving-Framework SGLang Omni folgt eine wesentliche Optimierung für den Infrastrukturbetrieb [1, 3, 4]. Wie aus einer Mitteilung des SGLang-Entwicklers mit dem Handle GenAI_is_real hervorgeht, unterstützt SGLang Omni ab sofort offiziell einen INT4-quantisierten Checkpoint von Drama 3, der in Zusammenarbeit mit dem Community-Akteur _akhaliq (AK) bereitgestellt wurde [1]. Durch diese Quantisierung reduziert sich der Grafikspeicherbedarf allein für die Modellgewichte der TTS-Engine von ursprünglich 37,0 Gigabyte auf 20,8 Gigabyte [1].

Nach Angaben des Entwicklers erzielt der komprimierte INT4-Checkpoint in der englischsprachigen Evaluierung auf Basis von Seed-TTS EN eine mit dem unkomprimierten Referenzmodell vergleichbare Qualität beim Voice-Cloning [1]. Für Sie als technisch Verantwortliche ist hierbei wichtig einzuordnen, dass es sich bei dieser Qualitätsaussage um eine Angabe der beteiligten Entwickler handelt, für die in der Ankündigung noch keine detaillierten Metriktabellen wie Wortfehlerraten (WER) oder Sprecherähnlichkeitswerte veröffentlicht wurden [1]. Auf der Plattform Hugging Face sind im Modellbaum von Drama 3 inzwischen bereits 15 verschiedene Quantisierungsvarianten sowie ein Fine-Tuning-Modell verzeichnet, während eine Einbindung durch serverlose Drittanbieter (Inference Providers) auf der Plattform derzeit noch aussteht [4].

Parallel zur Veröffentlichung des INT4-Supports kooperiert das Team hinter SGLang Omni eng mit Hugging Face, um den öffentlichen Demonstrationsbereich (Drama 3 Space) grundlegend zu überarbeiten [1]. Dieser erhält nicht nur eine vollständig neu gestaltete Benutzeroberfläche, sondern soll in Kürze im Backend direkt über SGLang Omni auf einer von Hugging Face gesponserten NVIDIA-H200-GPU betrieben werden [1]. Dies unterstreicht die Positionierung von SGLang Omni als primäre Laufzeitumgebung für das Modell, die auch von Fish Audio selbst in der offiziellen Dokumentation ab dem ersten Veröffentlichungstag empfohlen wird [4, 5].

Architektur im Detail: 35B-A3B Mixture-of-Experts und Codebook-MTP

Um nachzuvollziehen, warum ein Text-to-Speech-Modell im Ausgangszustand 37,0 Gigabyte allein für seine Gewichte beansprucht, lohnt ein Blick auf die zugrunde liegende Architektur von Fish Audio Drama 3 [1, 2]. Im Gegensatz zu kompakten Sprachsynthesemodellen setzt Fish Audio bei seinem neuen Flaggschiff auf ein großes Mixture-of-Experts-Design (MoE) im Text-Backbone [2, 5]. Die offizielle Dokumentation und der technische Bericht (arXiv: 2610.18010) beziffern die Modellgröße auf 35 Milliarden Parameter, während die automatisierte Metadaten-Ansicht der Safetensors-Dateien auf Hugging Face leicht gerundet 36 Milliarden Parameter ausweist [2, 4].

Durch das MoE-Routing werden pro verarbeitetem Token lediglich 3 Milliarden Parameter aktiviert (35B-A3B) [2, 5]. Dies hält den Rechenaufwand und die Latenz während der Inferenz auf dem Niveau eines deutlich kleineren 3-Milliarden-Parameter-Modells, erfordert jedoch zwingend, dass sämtliche Expertengewichte im schnellen Grafikspeicher vorgehalten werden [5]. Im Standard-Checkpoint vor der neuen INT4-Quantisierung liegen die MoE-Experten im 8-Bit-Gleitkommaformat FP8 (spezifisch F8_E4M3) vor, während die übrigen Modellgewichte in BF16 gespeichert sind [2, 4].

Ergänzt wird das MoE-Text-Backbone durch spezialisierte Architekturkomponenten, die für lange Dialoge und hohe akustische Detailtreue ausgelegt sind [2, 4]:

  • Hybrider Attention-Mechanismus: Das Text-Backbone kombiniert vollständige (Full) und lineare (Linear) Attention, wird in SGLang Omni jedoch ausschließlich über das Triton-Attention-Backend ausgeführt; der Start mit alternativen Backends wie FlashAttention-3 (fa3) wird vom Server explizit verweigert [2].
  • Codebook-MTP-Audiodecoder: Die akustische Generierung erfolgt über einen Multi-Token-Prediction-Decoder, der zehn separate Codebooks kausal über die gesamte Sequenz hinweg dekodiert [2, 4].
  • Mehrsprecher-Adressierung: Über dedizierte Speaker-Tags von speaker:0 bis speaker:15 lassen sich bis zu 16 unterschiedliche Charaktere innerhalb eines einzigen Eingabetextes getrennt ansteuern [2, 4].
  • Automatisches Chunking: Lange Textpassagen werden vom System selbstständig in Segmente unterteilt und können pro Chunk verzögerungsarm im Streaming-Verfahren ausgegeben werden [2, 4].

Funktionsumfang für die Audioproduktion: Wortgenaues Infilling und Regie-Iterationen

Während das Modell im September 2026 zunächst nur als geschlossene Vorschau hinter einer Zugangsbeschränkung angekündigt worden war, markiert die Freigabe der Gewichte den Übergang zu einem lokal betreibbaren Produktionswerkzeug für Hörbücher, Spieledialoge, Lokalisierung und interaktive Sprachagenten [5]. Der zentrale funktionale Unterschied zu herkömmlichen TTS-Systemen besteht darin, dass Drama 3 eine eingesprochene Aufnahme wie ein nachträglich editierbares Dokument behandelt [5].

In der Praxis stützt sich dieser Workflow auf mehrere Steuerungsmechanismen, die über die reine Texteingabe hinausgehen und über das gemeinsame Interface im Repository fish-speech (Kommandozeile, API-Server und Web-UI) bereitgestellt werden [2, 5]:

Lokales Infilling und Bearbeitung als Fortsetzung

Ein häufiges Problem in der kommerziellen Audioproduktion sind nachträgliche Skriptänderungen – etwa wenn sich ein Wochentag, eine Uhrzeit oder ein Zahlenwert ändert [2, 5]. Bei klassischen Modellen führt eine Neugenerierung des gesamten Satzes oft zu veränderten Betonungen, sodass die Aufnahme nicht mehr zum Rest der Szene passt [5]. Drama 3 löst dies über das Prinzip Editing as continuation: Sie übergeben dem Server neben dem neuen Zieltext und der Referenzstimme über das JSON-Feld previous_takes die bisherigen Takes beziehungsweise deren VQ-Tokens als Kontext [2, 4].

In den offiziellen Dokumentationsbeispielen wird etwa in einem Satz das Wort Wednesday durch Thursday ersetzt und in einem zweiten, direkt verketteten Bearbeitungsschritt die Zeitangabe by noon zu by five geändert, wobei beide vorherigen Versionen im Kontext verbleiben [2, 4]. Laut Shijia Liao, Mitgründer und Chief Scientist von Fish Audio (zitiert nach einem Bericht von AlphaSignal), analysiert das Modell bei solchen Einzelwort-Korrekturen das Audiomaterial auf beiden Seiten der Änderungsstelle, um Klangfarbe (Timbre) und Übergänge nahtlos einzufügen [5].

Mehrstufige Regieanweisungen und Tag-Syntax

Neben dem Austausch einzelner Wörter erlaubt Drama 3 sogenannte Multi-Turn Director Revisions [5]. Dabei wird eine bereits generierte Aufnahme nicht verworfen, sondern durch natürlichsprachliche Regieanweisungen – beispielsweise mit der Vorgabe, den Text sanfter und etwas trauriger zu sprechen – unter Beibehaltung des Stimmcharakters iterativ angepasst [5].

Für die direkte Steuerung im Skript unterstützt das Modell sogenannte Point Tags wie [sighs] oder [laughs], die über den Endpunkt /v1/tts exakt an der Textposition eingefügt werden, an der das akustische Ereignis auftreten soll [2, 4]. Darüber hinaus beschreibt die Begleitberichterstattung zum Launch paarweise eingesetzte Tags, die einen Effekt wie Flüstern präzise auf die umschlossenen Wörter begrenzen, sowie eine Auto-Tag-Hilfsfunktion, die Regieanweisungen für noch nicht annotierte Dialoge vorschlägt [5]. Zudem beansprucht Fish Audio in seiner Dokumentation Bestwerte bei sprachübergreifenden Wort- und Zeichenfehlerraten (Cross-Lingual CER/WER) sowie laut Sekundärberichten die Fähigkeit, innerhalb einer Szene fließend zwischen Englisch, Chinesisch, Japanisch und Koreanisch zu wechseln [5]. Unabhängige Vergleichstests zu diesen Qualitätsversprechen sowie zu genannten Benchmarks wie MiniMax Multilingual, Ming-Freeform und Step-Audio-Edit liegen in den vorliegenden Quellen allerdings noch nicht vor [5].

Abgrenzung zum Vorgängermodell S2-Pro

Wenn Sie in Ihrem Unternehmen abwägen, welches Modell für Ihren Anwendungsfall geeignet ist, liefert der Vergleich mit dem bisherigen Open-Weight-Modell S2-Pro klare Kriterien [5]. S2-Pro verfügt über lediglich 4 Milliarden Parameter, lässt sich auf regulären Consumer-Grafikkarten betreiben und erreicht laut Hersteller auf einer H200-GPU eine Zeit bis zum ersten Audio-Chunk von rund 100 Millisekunden bei einem Real-Time Factor (RTF) von 0,195 [5]. S2-Pro unterstützt ebenfalls Multi-Speaker-Synthese, Voice-Cloning und Inline-Instruktionen, bietet jedoch weder lokales Wort-Infilling noch mehrstufige Regie-Revisionen und weist eine geringere emotionale Ausdrucksstärke auf [5]. Ein weiteres Zwischenmodell, S2.1 Pro aus dem Juli 2026, wurde von Fish Audio ausschließlich über die kostenpflichtige API bereitgestellt [5].

Speicherökonomie: Warum auch 20,8 GB in der Praxis Rechenzentrums-GPUs erfordern

Die Reduktion der Engine-Gewichte von 37,0 GB auf 20,8 GB durch die neue INT4-Quantisierung ist ein erheblicher Effizienzgewinn, bedarf für die Kapazitätsplanung im Unternehmen jedoch einer genauen Einordnung [1, 2]. Wie bereits ein Nutzerkommentar unter der ursprünglichen Ankündigung anmerkt, stellen selbst 20,8 Gigabyte allein für die reinen Modellgewichte für Privatanwender oder kleinere Workstations weiterhin eine hohe Hürde beim Grafikspeicher (VRAM) dar [1].

Für den produktiven Serverbetrieb in SGLang Omni müssen Sie berücksichtigen, dass sich der Gesamtspeicherbedarf auf der GPU aus drei getrennten Pipeline-Stufen zusammensetzt: dem Preprocessing, der eigentlichen TTS-Engine (inklusive KV-Cache und CUDA-Graphen) sowie dem Vocoder [2]. Beim Start des Servers prüft SGLang Omni automatisch, ob die zugewiesenen Speicherbudgets aller Stufen zusammen auf die physische Grafikkarte passen [2].

Besonders speicherintensiv kann das Preprocessing beim Voice-Cloning werden [2]. Standardmäßig reserviert SGLang Omni für die Preprocessing-Stufe über den Konfigurationsparameter total_reserve_bytes exakt 6 GiB Grafikspeicher [2]. Dieses Budget ist darauf ausgelegt, Referenz-Audiodateien bis zur Standardobergrenze von 60 Sekunden zu kodieren [2]. Wenn Sie dieses Zeitlimit für längere Stimmreferenzen über die Einstellung preprocessing.factory.max_reference_audio_seconds beispielsweise auf 90 Sekunden anheben, wächst der Speicherbedarf linear mit der Audiolänge an, sodass in der Dokumentation eine Erhöhung der Reserve auf 9 GiB empfohlen wird [2]. Hinzu kommt der Vocoder, der im Standardbetrieb 10 Prozent des gesamten GPU-Speichers (vocoder.gpu_memory_fraction von 0.10) für sich beansprucht [2].

Als analytische Schlussfolgerung aus diesen belegten Architekturdaten ergibt sich für Ihre Infrastrukturplanung: Während das unkomprimierte Modell mit 37,0 GB Gewichten plus Preprocessing-Reserve (6 GiB), Vocoder-Anteil und KV-Cache auf einer 48-GB-Karte kaum Spielraum für parallele Anfragen ließ, ermöglicht der 20,8-GB-INT4-Checkpoint deutlich größere KV-Caches auf bestehenden Enterprise-Beschleunigern oder den Betrieb bei moderater Parallelität auf kleineren Rechenzentrums-GPUs [1, 2].

API-Integration, Prompt-Grenzwerte und Risiken bei Non-Streaming-Anfragen

Für die Einbindung in bestehende Softwarelandschaften stellt SGLang Omni nach der Installation über die Paket-Option fishaudio und dem Serverstart per sgl-omni serve auf Port 8000 eine standardisierte HTTP-Schnittstelle bereit [2, 4]. Über den Endpunkt /v1/audio/speech lassen sich einfache Text-to-Speech-Anfragen, Voice-Cloning-Aufrufe mit Referenz-Audio-URLs samt zugehörigem Transkript sowie verzögerungsarme Echtzeit-Streams im unkomprimierten PCM-Format (Parameter response_format mit dem Wert pcm) abwickeln [2, 3].

Im Produktionsbetrieb sollten Ihre Entwicklerteams drei harte technische Grenzwerte und Speichermechanismen beachten, um Laufzeitfehler zu vermeiden [2]:

  • Referenzaudio-Limit (60 Sekunden): Jede übergebene Stimmreferenz wird einzeln geprüft; überschreitet eine Datei die Grenze von 60 Sekunden (sofern nicht manuell erhöht), bricht der Server die Anfrage noch vor der Kodierung mit dem Statuscode HTTP 400 ab [2].
  • Prompt-Längenlimit (8192 Zeilen): Ein interner Prompt umfasst die Template-Tokens, den Eingabetext, die Transkripte der Referenzen sowie jeweils eine Zeile für jeden Codec-Frame des Referenzaudios [2]. Da der Audio-Codec ein 44,1-kHz-Signal in Frames zu je 2048 Samples zerlegt, fallen pro Sekunde Referenzaudio etwa 21,5 Zeilen an [2]. Überschreitet die Gesamtzahl 8192 Zeilen, lehnt der Server die Anfrage ebenfalls mit HTTP 400 ab; der Wert lässt sich über den Parameter tts_engine.factory.max_prompt_rows anpassen, sofern die maximale Kontextlänge der Engine inklusive max_new_tokens nicht überschritten wird [2].
  • Speicherüberlauf (OOM) bei Non-Streaming-Anfragen: Wenn Sie Anfragen ohne aktiviertes Streaming senden, dekodiert der Vocoder das gesamte Audio erst nach Abschluss der Engine-Berechnung in einem Stück und fasst gleichzeitig fertiggestellte Anfragen bis zu einem intern berechneten Frame-Limit zusammen [2]. Da dieses Limit jedoch keinen Speicher berücksichtigt, den der Vocoder-Prozess außerhalb des PyTorch-Allocators belegt, kann es bei vielen parallelen Non-Streaming-Anfragen zu einem Out-of-Memory-Absturz kommen – insbesondere dann, wenn der Speicheranteil der Engine für hohe Parallelität von standardmäßig 0,70 auf 0,85 angehoben wurde [2].

Empfohlene Gegenmaßnahmen gegen Vocoder-Speicherengpässe

Um solche Speicherüberläufe im Produktivbetrieb zuverlässig auszuschließen, nennt die SGLang-Dokumentation drei konkrete Optionen: Entweder stellen Sie sämtliche Client-Anfragen konsequent auf Streaming (Parameter stream auf true) um, Sie belassen den Speicheranteil der Engine auf dem Standardwert von 0,70 auf derselben GPU, oder Sie lagern den Vocoder vollständig auf eine zweite Grafikkarte aus [2].

Skalierung und SPG-Topologie: Leistungsdaten auf NVIDIA H200

Im Hinblick auf den Hochlastbetrieb in großen Sprachplattformen haben Fish Audio und das SGLang-Projekt umfangreiche Leistungsmessungen auf NVIDIA-H200-GPUs veröffentlicht [2, 3, 4]. Wichtig für Ihre Bewertung: Diese Werte entstammen den offiziellen Herstellerdokumentationen und wurden mit dem Standard-Modell im Streaming-Modus auf englischen Seed-TTS-Prompts erhoben (jeweils mit vorab kodierten vq_codes, Temperatur 1,0, top_p 0,9, top_k 30 und maximal 500 neuen Tokens) [2, 4, 5].

Auf einer einzelnen NVIDIA H200, auf der standardmäßig alle Stufen auf GPU 0 laufen (wobei die Standardkonfiguration maximal 16 gleichzeitige Anfragen bei 70 Prozent Speicheranteil vorsieht, für die Benchmarks jedoch über tts_engine.gpu_memory_fraction auf 85 Prozent Speicheranteil und über tts_engine.factory.max_running_requests auf bis zu 256 Anfragen erweitert wurde), zeigen sich über vier Testläufe gemittelt folgende Skalierungswerte [2, 4]:

  • Concurrency 1 (Einzelstream): Durchsatz von 166,7 akustischen Frames pro Sekunde, eine mediane Time to First Audio (TTFA p50) von 88,9 ms (p95: 90,8 ms) und ein mittlerer Real-Time Factor (RTF) von 0,131 [2, 4].
  • Concurrency 4: Durchsatz von 467,6 Frames/s, TTFA p50 von 108,2 ms (p95: 156,4 ms) und ein RTF von 0,186 [2, 4].
  • Concurrency 16: Durchsatz von 927,6 Frames/s, TTFA p50 von 210,1 ms (p95: 287,2 ms) und ein RTF von 0,373 – das Audio wird hier noch rund 2,7-mal schneller generiert, als es in Echtzeit abgespielt wird [2, 4].
  • Concurrency 32: Durchsatz von 1.244,7 Frames/s, TTFA p50 von 304,6 ms (p95: 396,1 ms) und ein RTF von 0,551 [2, 4].
  • Concurrency 64: Durchsatz von 1.687,3 Frames/s, TTFA p50 von 450,9 ms (p95: 1.020,1 ms) und ein mittlerer RTF von 0,801, womit auch bei 64 gleichzeitigen Streams die Echtzeitschwelle von 1,0 unterschritten bleibt [2, 4].

Entkopplung des Vocoders bei 128 und 256 parallelen Streams

Bei noch höherer Last von 128 oder 256 gleichzeitigen Streams wird der Vocoder auf einer einzelnen GPU zum Flaschenhals, da er vollständig ausgelastet ist und das erste Audio neuer Streams in seiner Warteschlange blockiert wird [2, 4]. Wenn Engine und Vocoder sich zwingend eine einzige GPU teilen müssen, bietet SGLang Omni zwar die Option mps on zur Nutzung von CUDA Multi-Process Service (MPS) an; dies kann den Gesamtdurchsatz unter hoher Parallelität steigern, verlangsamt unter Umständen jedoch einzelne Streams [2].

Als weitaus leistungsfähiger erweist sich die in SGLang Omni implementierte SPG-Topologie, bei der die Zuweisung von Pipeline-Stufen auf Prozesse und GPUs rein über Startparameter (tts_engine.gpu 0 und vocoder.gpu 1) statt über Modellcode gesteuert wird [2, 3]. In einem Vergleich über jeweils 1.088 Anfragen (gemittelt über sechs Serverstarts) stieg der Durchsatz bei 128 parallelen Streams durch die Auslagerung des Vocoders auf eine zweite H200-GPU von 2.177 auf 3.692 Frames pro Sekunde, während die mediane TTFA von 685 ms auf 401 ms sank [2, 4]. Bei 256 gleichzeitigen Streams kletterte der Durchsatz von 2.422 auf 4.160 Frames pro Sekunde (+72 Prozent), und die mediane TTFA reduzierte sich um 37 Prozent von 3.403 ms auf 2.146 ms (p95 sank von 4.255 ms auf 2.469 ms) [2, 3, 4].

Low-Level-Optimierungen: CUDA-Graphen, Triton-Kernels und Hopper-Bindung

Damit die genannten Latenzwerte von unter 90 Millisekunden überhaupt erreicht werden können, nutzt SGLang Omni unter der Haube eine Reihe tiefgreifender Compiler- und Kernel-Optimierungen, die standardmäßig aktiviert sind [2]. Wenn Sie das System auf eigener Hardware evaluieren, ist insbesondere die strikte Hardware-Abhängigkeit einiger dieser Funktionen entscheidend [2].

Zwei zentrale Beschleunigungsmechanismen – das sogenannte Triton Sampling (das die Haupt-Tokens und Codes jedes Frames über Triton-Kernels statt über den Standard-PyTorch-Sampler zieht) sowie die Fused Codebook Tower Layers (verschmolzene Triton-Kernels für bis zu 16 Zeilen im Decode- und First-Frame-Schritt) – sind ausschließlich auf NVIDIA-Hopper-Architekturen validiert [2]. Sie werden vom Server nur dann aktiviert, wenn eine GPU mit exakt Compute Capability 9.0 erkannt wird [2]. Auf sämtlichen anderen GPU-Generationen (das Dokumentationsbeispiel zeigt etwa ein Log für sm_120 als nicht getestete GPU) schaltet SGLang Omni diese Pfade automatisch ab und fällt auf den regulären PyTorch-Sampler beziehungsweise den Standard-Modulpfad zurück [2].

Darüber hinaus bringen diese Low-Level-Optimierungen spezifische Eigenschaften für die Reproduzierbarkeit und das Systemverhalten mit sich [2]:

  • Numerische Abweichungen durch Kernel-Fusion: Da die verschmolzenen Triton-Kernels im Codebook-Tower Additionen in einer anderen Reihenfolge ausführen als PyTorch, können die Ausgaben in den letzten Bits abweichen, was zu unterschiedlichen gesampelten Audio-Frames führen kann [2]. Auch beim Triton Sampling kann das Runden an der Grenze von top_p dazu führen, dass selbst bei identischem Zufalls-Seed andere Tokens gewählt werden als mit dem PyTorch-Sampler [2]. Für strikt deterministische Inferenz müssen Sie auf die Standardpfade zurückgreifen [2].
  • Dreistufige CUDA-Graphen: SGLang Omni nutzt im Standardbetrieb Decode-CUDA-Graphen, unterbrechbare Prefill-CUDA-Graphen (Breakable Prefill CUDA Graph für Batches bis 2048 Tokens über Backbone und Codebook-Tower hinweg) sowie First-Frame-CUDA-Graphen für Prefills von bis zu 16 Anfragen [2]. Zudem setzt der Vocoder eigene Window-CUDA-Graphen für Batch-Größe 1 und eine FP16-Dekodierung ein [2]. Diese Graphen verkürzen die Zeit bis zum ersten Audio erheblich, verlängern jedoch die Startzeit des Servers und belegen zusätzlichen Grafikspeicher [2].
  • Prefill-Decode-Intervall: Über den Standardwert prefill_decode_interval von 4 stellt der Scheduler sicher, dass nach einem rechenintensiven Prefill neue Prefill-Anfragen für die nächsten vier Scheduling-Runden warten müssen, damit bereits laufende Audio-Streams ohne Aussetzer weiter dekodiert werden können [2].

Lizenzierung, API-Kosten und strategische Einordnung für B2B-Entscheider

Abseits der technischen Leistungsdaten sollten Sie vor einer produktiven Integration von Fish Audio Drama 3 die rechtlichen und kaufmännischen Rahmenbedingungen genau prüfen [4, 5]. Obwohl die Modellgewichte offen auf Hugging Face zum Download bereitstehen, stehen weder der Quellcode noch die Gewichte unter einer klassischen Open-Source-Lizenz wie MIT oder Apache 2.0 [4, 5]. Stattdessen unterliegt Drama 3 der proprietären Fish Audio Community License (während das ältere S2-Pro unter der Fish Audio Research License veröffentlicht wurde) [4, 5]. Für kommerzielle Unternehmensanwendungen ist daher eine vorherige Prüfung der spezifischen Lizenzbestimmungen unerlässlich [5].

Falls Sie den Eigenbetrieb auf kostspieliger H200-Hardware trotz der neuen INT4-Quantisierung vermeiden und stattdessen auf den gehosteten Dienst zurückgreifen möchten, steht das Modell unter dem API-Endpunkt drama-3-preview bereit [5]. Zum Preismodell zitiert das Fachportal explainx.ai einen Bericht von AlphaSignal, wonach der API-Zugriff mit 15 US-Dollar pro 1 Million UTF-8-Bytes berechnet wird – weist jedoch ausdrücklich darauf hin, dass dieser Preis aus einer einzelnen Sekundärquelle stammt und noch nicht unabhängig bestätigt wurde (ebenso wie die Eigenangaben des Unternehmens zu einer Seed-Finanzierungsrunde über 52 Millionen US-Dollar im Juli 2026 und mehr als 15 Millionen Nutzern) [5].

Für Ihre eigene Evaluierung empfiehlt es sich daher, den nun verfügbaren INT4-Checkpoint in SGLang Omni direkt gegen Ihre realen Produktionsskripte zu testen [1, 5]. Prüfen Sie dabei insbesondere, ob die Stimmkonsistenz über längere Dialoge von zehn Minuten oder mehr erhalten bleibt, wie präzise das Infilling bei kritischen Entitäten wie Datumsangaben und Zahlen funktioniert und wie sich das Verhältnis aus GPU-Infrastrukturkosten pro Audiominute im Vergleich zur gehosteten API darstellt [5]. Nicht zuletzt erfordert das leistungsfähige Voice-Cloning bereits ab wenigen Sekunden Referenzmaterial (im offiziellen Beispiel genügt ein 3,9 Sekunden kurzer Clip) klare interne Compliance-Richtlinien zur schriftlichen Einwilligung von Sprechern sowie zur Kennzeichnung synthetisch erzeugter Sprachaufnahmen [2, 5].

Quellen

  1. [1] RT by @_akhaliq: More good news for Fish Audio Drama 3! 🎉 Thanks to @_akhaliq for the INT4 quantization and his incredible support, SGLang Omni now officially supports Drama 3 INT4! The quantized checkpoint reduces engine weight memory from 37.0 GB to 20.8 GB, with comparable voice-cloning quality in our Seed-TTS EN evaluation. Making powerful speech models more accessible and affordable to serve is exactly what we love working on. We've also been working closely with the @huggingface team to e — https://x.com/GenAI_is_real/status/2110476147712782745 (abgerufen am 2026-10-14)
  2. [2] Fish Audio Drama 3 — SGLang — https://sgl-project.github.io/sglang-omni/cookbook/fishaudio_drama3.html (abgerufen am 2026-10-14)
  3. [3] SGLang - X — https://x.com/sgl_project/status/2110043396563927270/photo/1 (abgerufen am 2026-10-14)
  4. [4] fishaudio/drama-3 · Hugging Face — https://huggingface.co/fishaudio/drama-3 (abgerufen am 2026-10-14)
  5. [5] Fish Audio Drama 3 Open Weights: 35B MoE, Word Edits | explainx.ai Blog | explainx.ai — https://explainx.ai/blog/fish-audio-drama-3-open-weights-35b-a3b-word-level-editing-how-to-run-2026 (abgerufen am 2026-10-14)

//Nächster Artikel

Audio & Musik

Qobuz kennzeichnet KI-generierte Musik und begrenzt ihre Sichtbarkeit

Qobuz verschärft die Regeln für synthetische Musik: Mit einem neuen „AI-Tag“ kennzeichnet die Plattform KI-Titel, schließt sie aus redaktionellen Playlists aus und sperrt Vergütungen bei manipulierten Streams. So soll mehr Transparenz und Fairness im Musikstreaming geschaffen werden.

// Artikel teilen

Bei Google bevorzugen

Mehr zu Sprach-, Audio- & Musik-KI

Alle Audio & Musik-News

// Dranbleiben

Mindverse News folgen

Neue Meldungen erhalten Sie über unseren RSS-Feed oder auf LinkedIn.

Recherchieren Sie KI-News wie diese selbst — mit Mindverse Studio.

7 Tage kostenlos testen — ohne Kreditkarte, mit 200 Credits. Für Fragen zur Umsetzung buchen Sie eine persönliche Demo.