Wie wir unsere Text-zu-Sprache-API kostenlos gemacht haben: Das Inference Engineering hinter S2.1 Pro

TL;DR

• Fish Audio S2.1 Pro ist jetzt als kostenlose Text-to-Speech-API verfügbar: 83 Sprachen, kein hartes Nutzungslimit, Modell-String s2.1-pro-free. Der kostenlose Zugang ist für einen ersten Zeitraum verfügbar; wir werden etwaige Änderungen mit Vorankündigung mitteilen. Weitere Informationen finden Sie hier.
• Die End-to-End-Inference-Optimierung hat den Ressourcenbedarf pro GPU-Anfrage um das 4-Fache gesenkt: Dieselbe Arbeitslast, die zuvor vier H200-GPUs erforderte, läuft nun auf einer einzigen.
• Hauptelemente: Eigene CUDA-Kernel (2,1–4,3-mal schneller als cuBLAS bei Decode-Shapes), Continuous Batching (52-fache Durchsatzskalierung c=1→64), GPU-Auslastung von ~50 % auf ~90 %+ gesteigert.
• Derselbe Stack betreibt unsere Voice-Cloning-API — identische Modellgewichte, identische Infrastruktur, inklusive kostenloser Stufe. S2.1 Pro basiert auf Fish Speech, unserem Open-Weight-Basismodell.
• Die Kern-Kernel-Bibliothek fish-scales-ops ist Open Source.

Erfahren Sie, warum Entwickler von anderen Plattformen wechseln → Kostenlos starten

Juli 2026 | Fish Audio hat den Inference-Stack neu aufgebaut und S2.1 Pro für jeden Entwickler kostenlos gemacht

Der wahre Grund, warum Sprach-KI Geld kostet

Die Inference von Sprach-KI hat ein strukturelles Problem, das Preislisten nicht erklären: Autoregressives Decoding ist von Natur aus feindlich gegenüber der GPU-Auslastung.

Jeder TTS-API-Aufruf löst eine Decoding-Schleife aus, die Audio-Token Schritt für Schritt generiert. Jeder Schritt ist eine kleine Matrizenmultiplikation — in der Praxis M ≤ 128 — gefolgt von einem Lesevorgang aus dem KV-Cache für diese Sequenz. Die CUDA-Kerne bleiben meist ungenutzt, während das Speichersubsystem aufholt. Bei einer 30.000 $ teuren H200 bezahlen Sie für Rechenleistung, die in Speicher-Wartezeiten (Stalls) verpufft.

Bei niedriger Gleichzeitigkeit verschlimmert sich dies. Eine Decoding-Schleife für eine einzelne Anfrage belegt die GPU in Bursts von 10–20 μs, getrennt durch Scheduling-Overhead. Die GPU-Auslastung eines naiv betriebenen TTS-Endpunkts bei c=1 kann unter 10 % liegen. Die Hardware ist da, aber die Arbeit füllt sie nicht aus.

Die Antwort der Branche bestand darin, die Kosten über eine Preisgestaltung pro Zeichen an die Entwickler weiterzugeben. Unsere Antwort war, das Auslastungsproblem auf der Infrastrukturebene zu lösen. Wenn eine einzige GPU die Arbeit leisten kann, für die zuvor vier nötig waren, wird die Ökonomie einer kostenlosen Stufe rentabel.

Hier ist, was dafür erforderlich war.

End-to-End-Optimierung: Der komplette Stack

Keine einzelne Änderung führt zu einer 4-fachen Effizienzsteigerung. Die Gewinne resultierten aus der gleichzeitigen Optimierung jeder Ebene, wobei sich die Effekte gegenseitig verstärkten:

• Eigene CUDA-Kernel — Eliminierung von Rechenabfall pro Token
• FP8-Quantisierung — Halbierung des Drucks auf die Speicherbandbreite
• Continuous Batching — Auslastung der GPU über konkurrierende Anfragen hinweg
• GPU-Scheduling — Eliminierung von Leerlaufkapazitäten zwischen Workloads
• Eigenes Netzwerk und Storage — Entfernung von Cloud-Infrastruktur-Aufschlägen

Jede Ebene wird im Folgenden beschrieben. Die Durchsatz- und Kostenzahlen am Ende sind das Ergebnis all dieser Maßnahmen zusammen.

Eigene CUDA-Kernel: fish-scales-ops

Warum cuBLAS nicht ausreichte

Die Decode-Shapes beim TTS-Serving (M ≤ 128) sind nicht die Formen, für die cuBLAS, PyTorch-GEMM-Kernel oder sogar torch.compile optimiert sind. Diese Bibliotheken zielen auf Training und Large-Batch-Prefill ab — mit einem M im Tausenderbereich. Bei kleinem M lassen sie Speicherbandbreite ungenutzt und verpassen Fusion-Möglichkeiten, die nur bei Decode-Batch-Größen existieren.

Die spezifische Lücke: Bei einem SwiGLU-MLP-Forward bei M=1 (Decoding einer einzelnen Anfrage) führt cuBLAS scaled_mm drei separate Kernel-Starts aus — Aktivierung, Gate-Multiplikation, Down-Projektion —, wobei Zwischenergebnisse zwischen jedem Schritt in den HBM geschrieben und wieder aus ihm gelesen werden. Bei M=1 ist dieser Round-Trip der Flaschenhals, nicht die Rechenleistung.

Wir haben fish-scales-ops entwickelt, um diese Lücke zu schließen: eine produktionsreife FP8-GEMM- und FlashAttention-Bibliothek für NVIDIA Hopper (H200, sm_90a) und Blackwell (sm_120a) Architekturen, Open Source.

FP8-Quantisierungsstrategie

Wir haben zwei Quantisierungsschemata für verschiedene Hardware-Generationen implementiert:

bsgemm (128×128 Block-Scaled FP8) für H200/Hopper. Block-Skalierung mit einer Granularität von 128×128 bietet eine gute numerische Stabilität ohne das Genauigkeitsrisiko der Per-Tensor-Quantisierung.

mxfp8 (1×32, OCP UE8M0 Format) für Blackwell (RTX 5090, RTX 6000 PRO). Mikroskalierung mit geteilten Exponenten für 32 Elemente — der OCP MX Standard — bietet eine feinere numerische Wiedergabetreue in den Skalen, die für die Generierung von Audio-Token wichtig sind.

Ein nicht offensichtlicher Bug im mxfp8-Pfad erforderte erhebliches Debugging: quantize_blockscale.py materialisierte weight_scale-Tensoren mit .contiguous() für Safetensors-Kompatibilität, aber linear_mxfp8_raw liest Skalen mit K-Major-Stride (1, N). Das Laden eines Row-Major-Contiguous [N, K/128] führte dazu, dass jedes GEMM bei voller Kernel-Geschwindigkeit falsche Logits produzierte — das nachgelagerte Sampling kollabierte in einen Mode-Collapse mit einem einzigen sich wiederholenden semantischen Token. Dies sieht wie ein Problem der Modellqualität aus, ist aber tatsächlich ein Bug im Speicherlayout. Die Lösung war ein Re-Striding in MXFP8LinearMethod.process_weights_after_loading. Nach dem Fix entspricht das Greedy Decoding bei den ersten fünf Audio-Frames exakt den bf16-Tokens.

Kernel-Benchmark-Ergebnisse

Bei Decode-Shapes (M ≤ 128) ergaben interne Benchmarks auf gleichwertiger Hardware — die vollständige Methodik finden Sie im fish-scales-ops-Repo:

• Der MXFP8-Pfad schlägt torch.nn.functional.scaled_mm bei 8 von 10 quadratischen Formen von 1024³ bis 16384³ mit bis zu +21 %
• End-to-End Qwen3-4B SwiGLU MLP Forward: 1,7–6,2-mal schneller als reines cuBLAS scaled_mm bei jedem M von 1 bis 4096
• Gegenüber torch.compile-fused cuBLAS bei Decode-Shapes: 2,1–4,3-mal schneller
• MXFP8 FlashAttention auf sm_120a: 7–19-mal schneller als PyTorch SDPA Decode, 1,2–2,7-mal schneller als FlashInfer BF16

Zwei fusionierte Kernel treiben den Großteil des Gewinns voran: Einer fusioniert die Aktivierungsquantisierung + UE8M0-Scale-Pack in einen einzigen Start; der andere fusioniert den SwiGLU-Prolog direkt in die Down-GEMM-Aktivierungsquantisierung, wodurch ein vollständiger BF16-Zwischenschreib- und Lesevorgang eliminiert wird, den PyTorch normalerweise zwischen den beiden Operationen materialisiert.

Batch-Inference-Architektur: Der Abgleich zwischen Latenz und Durchsatz

Continuous Batching für autoregressives TTS

Kernel-Effizienz verbessert die Kosten pro Token. Batching ist das, was die Effizienz pro Token in GPU-Auslastung über den gesamten Anfragestrom umwandelt.

Statisches Batching — bei dem alle Sequenzen auf die gleiche Länge aufgefüllt und als fester Batch ausgeführt werden — verschwendet Rechenleistung für Padding und blockiert neue Anfragen, bis die langsamste Sequenz im Batch fertig ist. Bei TTS mit variablen Ausgabelängen ist der Nachteil bei der Tail-Latency erheblich.

Wir verwenden Continuous Batching, angepasst von sglang: Neue Anfragen werden dem aktiven Decode-Batch hinzugefügt, sobald Plätze frei werden, ohne auf eine Batch-Grenze zu warten. Die GPU-Decoding-Schleife gerät nie wegen einer einzelnen langsamen Anfrage ins Stocken.

DualAR: S2-spezifische Batching-Beschränkungen

Die DualAR-Architektur von S2.1 Pro generiert Audio-Token in zwei Stufen — grobe Codebooks gefolgt von feinen Codebooks —, mit einem gleitenden previous_tokens-Fenster, das jeden Schritt konditioniert. Dies schafft eine Korrektheitsbeschränkung, die Standard-LLM-Batching nicht hat: Der prev_tokens_shift_inplace-Kernel erfordert einen strikten Shape/Dtype-Kontrakt (prev int32 [bs, W, cw], next_tokens int32 [bs, cw]). Jede Shape-Anpassung im Caller — .unsqueeze(), implizite Dtype-Promotion — korrumpiert das Fenster und erzeugt minderwertiges Audio, das kaum von einem Rückgang der Modellqualität zu unterscheiden ist.

Für Voice-Cloning-Workloads ist diese Beschränkung besonders wichtig: Die Sprecherkonditionierung fließt durch denselben Decode-Pfad, und eine Fenster-Korruption äußert sich eher in einer Abdrift der Sprecheridentität bei langen Ausgaben als in offensichtlichen Audio-Artefakten.

Durchsatzergebnisse

H200, bsgemm FP8, Gleichzeitigkeits-Sweep:

Der Durchsatz skaliert um das ~52-Fache von c=1 auf c=64, während die TTFB nur um 36,6 ms steigt — von 73 ms auf 110 ms. Die GPU leistet das 52-Fache der Arbeit für einen Latenznachteil, der in den meisten Produktionsumgebungen nicht wahrnehmbar ist.

Bei c=64 bewältigt eine einzige H200 dauerhaft 8.006 Tok/s. Diese Zahl ist der direkte Mechanismus hinter der kostenlosen Stufe: Mehr Durchsatz pro GPU bedeutet geringere Kosten pro Anfrage.

Dies sind die Zahlen, die hinter jedem kostenlosen API-Aufruf stehen. Jetzt loslegen →

Echtzeit-Modus: Architektonischer Ansatz für Workloads mit niedriger Latenz

Für Sprachagenten und dialogbasierte Anwendungen bieten wir einen separaten Echtzeit-Endpunkt an, der eher auf die Zeit bis zum ersten Audio (TTFA) als auf den Gesamtdurchsatz optimiert ist.

Die zentrale architektonische Entscheidung: Das Prefilling findet beim Öffnen der Verbindung statt, also vollständig außerhalb des latenzkritischen Pfades. Die Uhr für die Streaming-Latenz beginnt mit dem Senden des ersten Audio-Chunks, nicht mit dem Aufbau der Verbindung. Das bedeutet, dass die Prefill-Kosten, die mit der Prompt-Länge skalieren, gar nicht erst im TTFA-Wert auftauchen.

Auf Scheduler-Ebene führt ein Ping-Pong-Design Decoding und Prefilling auf separaten Threads ohne Host-Barriere pro Zyklus aus. Die Entfernung dieser Barriere ist die primäre TTFA-Verbesserung bei c≥4: In einer naiven Implementierung serialisiert die hostseitige Synchronisation nach jedem Decode-Schritt die eigentlich konkurrierende Arbeit. Eine Pipelined-Decode-Schleife und Pinned H2D-Speichertransfers adressieren TTFB und Jitter bei hoher Gleichzeitigkeit.

Das vollständige Design und die Aufschlüsselung der Latenz finden Sie in arXiv:2603.08823.

Qualitätsvalidierung: Wie wir sichergestellt haben, dass die Optimierung die Audioqualität nicht beeinträchtigt

Quantisierung und Batching können Qualitätsverluste verursachen, die mit reinen Durchsatz-Benchmarks schwer zu erkennen sind — die GPU läuft zwar mit voller Geschwindigkeit, produziert aber fehlerhafte Ergebnisse.

Wir haben einen solchen Fall während der Entwicklung von mxfp8 entdeckt: Der oben beschriebene Bug im Weight-Layout verursachte einen relativen Logit-Fehler von ~53 %, während die Kernel-Latenz völlig normal war. Der Rückgang zeigte sich nur in der Analyse der Output-Token, nicht in einer Performance-Metrik.

Unsere Validierungs-Pipeline hat zwei Hürden (Gates):

Korrektheits-Gate: Das quantisierte Greedy Decoding muss bei den ersten fünf Audio-Frames für eine feste Referenzeingabe Token für Token mit bf16 übereinstimmen. Ein Token-exakter Abgleich bei den ersten Frames erkennt systematische Logit-Korruption — wenn das quantisierte Modell andere Wahrscheinlichkeitsverteilungen erzeugt, weicht es bei deterministischen Eingaben sofort von bf16 ab.

Performance-Regressions-Gate: Der decode_tps pro Anfrage muss an jedem Gleichzeitigkeits-Punkt innerhalb von 5 % der eingefrorenen Baseline-Werte bleiben. Jede Änderung, die den Durchsatz bei irgendeiner Gleichzeitigkeit — c=1, c=16, c=64 — um mehr als 5 % verschlechtert, erfordert vor dem Merge eine explizite Rechtfertigung. Dieses Gate schützt vor Korrektheits-Fixes, die der Decode-Schleife im Stillen Synchronisationen hinzufügen.

Beide Gates werden bei jeder Änderung am Inference-Stack durchlaufen. Das Ergebnis: Die Modellgewichte von S2.1 Pro Free sind identisch mit der kostenpflichtigen Stufe, und der quantisierte Serving-Pfad wird bei jedem Deployment gegen die unquantisierte Baseline validiert.

Voice Cloning in großem Stil: Warum Inference-Effizienz wichtig ist

Das Voice Cloning von Fish Audio war schon immer kostenlos — und es bleibt nach unserer Einschätzung und dem Feedback der Entwickler das stärkste in seiner Klasse. Sprecherkonsistenz über 83 Sprachen hinweg, natürliche Prosodie und stabile Leistung bei verschiedenen Akzenten sind keine Funktionen, die wir erst einer kostenpflichtigen Stufe hinzugefügt haben. Sie sind der Standard. S2.1 Pro basiert auf Fish Speech S2 Pro, unserem Open-Weight-Basismodell, das Anfang des Jahres veröffentlicht wurde.

Was die Inference-Optimierung ändert, ist die Wirtschaftlichkeit, dieses Versprechen auch bei hoher Skalierung einzuhalten. Voice-Cloning-Workloads verursachen höhere Kosten pro Anfrage als Standard-TTS: Jeder Aufruf muss auf einem Referenz-Sprecher-Embedding konditioniert werden, die Sprecheridentität über variable Ausgabelängen hinweg beibehalten und dies konsistent über Sprachen hinweg tun. Ohne die in diesem Beitrag beschriebenen Effizienzgewinne würde kostenloses Voice Cloning im Produktionsmaßstab eine Subventionierung eines strukturell teuren Workloads erfordern. Mit ihnen ist das nicht nötig.

Drei Optimierungen sind speziell für das Voice Cloning von Bedeutung:

FP8 bewahrt die Sprecherkonditionierung. Die Token-exakte Korrektheitsvalidierung — die Logit-Fehler erkennt — bestätigt direkt, dass die Quantisierung das Sprecher-Embedding-Signal nicht verschlechtert. Die Sprecherkonsistenz in geklonten Ausgaben entspricht der bf16-Baseline.

Continuous Batching verarbeitet gemischte Anfragetypen. In der Produktion mischt sich der Traffic beim Voice Cloning aus referenzkonditionierten und unkonditionierten Anfragen, variierenden Ausgabelängen und verschiedenen Sprachen. Continuous Batching lastet den Decode-Batch unabhängig vom Anfragetyp aus — es gibt keinen Nachteil durch die Heterogenität der Arbeitslast.

52-fache Durchsatzskalierung macht Massengenerierung rentabel. Mit 8.006 Tok/s auf einer einzelnen H200 ist die Generierung großer geklonter Audiobibliotheken — Hörbücher, Spieldialoge, lokalisierte Inhalte in großem Umfang — innerhalb der kostenlosen Stufe wirtschaftlich machbar.

Die kostenlose Stufe enthält Voice Cloning nicht, weil wir uns durch Optimierung dazu „durchgerungen“ haben. Sie ist enthalten, weil das schon immer das Produkt war — und die hier beschriebene Ingenieursarbeit ermöglicht es uns, dieses Versprechen bei steigender Nutzung zu halten. Informationen zur Integration von Voice Cloning in Agent-Workflows finden Sie in unserem Beitrag zu MCP- und Agent-Skills-Unterstützung.

Klonen Sie eine Stimme in weniger als 60 Sekunden → Kostenlos testen

GPU-Infrastruktur: Den Stack selbst besitzen

Hardware und Beschaffung

Unser GPU-Cluster umfasst ca. 500 Karten in mehreren Rechenzentren. Die Multi-DC-Topologie war eine Beschaffungsentscheidung, bevor sie eine der Zuverlässigkeit wurde: Das Angebot und die Preise für GPUs sind volatil, und die Abhängigkeit von einem einzigen Anbieter (Vendor Lock-in) bedeutet, diese Volatilität direkt zu absorbieren. Die Beschaffung von mehreren Anbietern und Standorten sichert gleichzeitig Preisrisiken und Lieferengpässe ab, allerdings auf Kosten der betrieblichen Komplexität.

Für die Inference nutzen wir eine gemischte Flotte. Die H200 SXM5 übernimmt das Serving in der Produktion bei hoher Gleichzeitigkeit, wo der bsgemm-FP8-Gesamtdurchsatz dominiert. Die RTX 5090 und RTX 6000 PRO (sm_120a) bedienen Edge-Endpunkte — bei c=64 erreicht die 5090 mit mxfp8 5.869 Tok/s, was etwa 71 % des H200-bsgemm-Durchsatzes entspricht, bei wesentlich geringeren Hardwarekosten pro Karte.

Der sm_120a-Einsatz erforderte einen nicht offensichtlichen Fix: Die ursprüngliche Obergrenze von cuda_graph_max_bs = 24 für 32-GB-GPUs verursachte einen massiven Durchsatzeinbruch bei hoher Gleichzeitigkeit — c=32 fiel auf ~31 Tok/s pro Anfrage, c=64 auf ~35 Tok/s pro Anfrage. Das Anheben der Obergrenze auf min(max_running_requests, 64) stellte die volle Durchsatzkurve wieder her. Die zugrunde liegende Ursache: Der CUDA-Graph-Capture bei bs=24 ließ die GPU bei den Decode-Batch-Größen, die bei c=32+ tatsächlich auftreten, unterfordert.

GPU-Scheduling: Eliminierung ungenutzter Kapazitäten

Die Basis-GPU-Auslastung in einem reinen Inference-Cluster liegt bei ca. 50 %. Inference-Traffic ist von Natur aus sprunghaft; die GPU liegt in Nebenzeiten, zwischen Trainingsläufen und während der Ladephasen von Datensätzen brach.

Wir betreiben zwei parallele Scheduling-Systeme — Kubernetes für die Inference, Slurm für das Training — mit einem gemeinsamen Prinzip: Jobs zur Datenbereinigung und -vorverarbeitung laufen als elastische Füllarbeit mit der niedrigsten Priorität in beiden Clustern. Bereinigungsjobs belegen freie GPU-Kapazität immer dann, wenn sie nicht für Inference oder Training benötigt wird. Sie sind checkpointfähig und sofort unterbrechbar, sodass sie ohne Korrektheitsverlust verschwinden, sobald echte Arbeit ansteht.

Priorisierung: Inference > Bereinigung im K8s-Cluster; Training > Bereinigung in Slurm. Der Autoscaler auf der Inference-Seite nutzt Echtzeit-Signale — keine zeitbasierten Heuristiken —, sodass Bereinigungsjobs sofort verdrängt werden, sobald die Last steigt.

Das Ergebnis: Eine Steigerung der GPU-Auslastung von ~50 % auf ~90 %+. Auf Clusterebene halbiert dieses Delta grob die effektiven Kosten pro Inference-Anfrage — das Hardware-Budget ist fest, aber es werden doppelt so viele Anfragen damit bedient.

Netzwerkinfrastruktur

Wir betreiben unser eigenes Netzwerk: direkte ISP-Bandbreitenbeschaffung, ASN, 300 Gbit/s Konnektivität und Cloudflare-Peering. Das hat zwei Auswirkungen speziell auf TTS-Kosten.

Der Egress-Traffic im TTS-Maßstab ist nicht unerheblich. Die Egress-Preise von Cloud-Anbietern sind strukturell auf hohe Margen ausgelegt; der Besitz der Netzwerkhaut entfernt diesen Aufschlag vollständig.

Latenz ist der zweite Grund. Jede Millisekunde eines Netzwerk-Round-Trips macht sich in der vom Nutzer wahrgenommenen TTFB bemerkbar. Durch das Cloudflare-Peering liegen die Fish Audio-Endpunkte nah an den Nutzern, die über das Cloudflare-Netzwerk geroutet werden — ein beträchtlicher Teil des globalen API-Traffics. Das Multi-DC-Deployment sorgt dafür, dass die meisten Anfragen einen nahen Inference-Knoten erreichen, ohne das gesamte öffentliche Internet zu durchqueren.

Storage: Abgestufte Architektur

Trainingsdaten, Modell-Checkpoints und Inference-Cache haben unterschiedliche Zugriffsmuster und Kostenanforderungen. Wir nutzen eine dreistufige Architektur:

• Hot (NVMe Flash): Aktive Trainingsdaten, Modellgewichte für das Serving
• Warm (Gemischt Flash/HDD): Aktuelle Checkpoints, vorverarbeitete Datensätze
• Cold (Selbst gehosteter Ceph HDD-Cluster): Historische Trainingsdaten, Langzeitspeicherung

Die Cold-Stufe hat Objektspeicher von Drittanbietern für Massendaten ersetzt. Eine lokale Cache-Ebene vor dem Cold Storage sorgt dafür, dass wiederholte Lesevorgänge — wie sie in Trainings-Pipelines üblich sind — über NVMe statt über langsame Festplatten bedient werden.

Das Ergebnis: Was der Stack leistet

Über alle Ebenen hinweg:

• Eigene FP8-Kernel: 2,1–4,3-mal schneller als Standard-cuBLAS bei Decode-Shapes
• Continuous Batching: 52-fache Durchsatzskalierung von c=1 auf c=64, nur 37 ms Latenzzunahme
• GPU-Scheduling: Auslastung ~50 % → ~90 %+, was die Kosten pro Anfrage etwa halbiert
• Eigene Infrastruktur: Cloud-Aufschläge für Compute, Netzwerk und Storage wurden eliminiert

Kombiniert führt dies dazu, dass dasselbe Anfragevolumen, das zuvor vier H200-GPUs erforderte, nun auf einer einzigen läuft. Die 4-fache Effizienzsteigerung macht die kostenlose Stufe wirtschaftlich rentabel — nicht durch Subventionen, sondern durch eine strukturelle Kostensenkung. Der Zeitraum des kostenlosen Zugangs spiegelt wider, dass die Unit Economics funktionieren; aktuelle Verfügbarkeiten finden Sie unter Preise.

Wie der Inference-Stack von Fish Audio im Vergleich abschneidet

Infrastrukturdaten basierend auf öffentlich zugänglicher Dokumentation, GitHub-Repos und Engineering-Blogs mit Stand Juni 2026.

Das Muster ist konsistent: Fish Audio ist der einzige große TTS-Anbieter, der seine Inference-Architektur öffentlich dokumentiert, seine Kernel-Bibliothek als Open Source bereitgestellt und konkrete Durchsatzzahlen veröffentlicht hat. „Nicht offengelegt“ ist keine Kritik — es ist eine Feststellung darüber, was verifizierbar ist. Für eine unabhängige Bewertung der Sprachqualität verschiedener Anbieter lesen Sie unseren blinden TTS-Anbieter-Vergleich.

Was ist Open Source

fish-scales-ops ist ab sofort verfügbar: FP8-GEMM und FlashAttention für Hopper und Blackwell, produktionsreif und sicher für CUDA Graph-Capture.

Wenn Sie Inference-Infrastrukturen für autoregressive Modelle auf H200 oder RTX 5090/6000 PRO aufbauen, ist die Performance-Lücke bei Decode-Shapes im Vergleich zu Standardbibliotheken real — und diese Kernel sind dazu da, sie zu schließen.

Inhalt der Bibliothek:

• FP8 GEMM: bsgemm (1×128 act × 128×128 wgt) für Hopper; MXFP8 1×32 (OCP UE8M0) für Blackwell
• MXFP8 FlashAttention für sm_120a: zusammenhängendes Prefill, Paged-Prefill (Extend), Paged-Decode mit nativen GQA über Stride-0 K/V-Broadcast
• Durchgängig sicher für CUDA Graph-Capture

Was kommt als Nächstes

B300-Unterstützung steht auf der Roadmap. Native FP8-Tensor-Kerne und NVLink 5-Bandbreite auf Blackwell werden die Durchsatzkurve weiter nach oben verschieben.

Die Inference-Optimierung geht weiter. Eingefrorene Benchmark-Zahlen sind eine Hürde für Regressionen, kein endgültiges Ziel. Jeder Gleichzeitigkeits-Punkt ist ein Wert, den es zu übertreffen gilt.

Weitere Teile des Serving-Stacks sind Kandidaten für Open-Sourcing, sobald sie sich stabilisieren — die sglang_lite-Modifikationen, die DualAR-spezifische Batching-Logik und das sm_120a CUDA-Graph-Handling. Die Infrastruktur, die die kostenlose Stufe nachhaltig macht, ist dieselbe Infrastruktur, auf der die Community aufbauen soll.

Erste Schritte mit der kostenlosen TTS-API

Modell-String: s2.1-pro-free. Nur eine Änderung im Header gegenüber bestehenden Fish Audio API-Aufrufen.

python

import httpx

body = {
    "text": "Hello, world!",
    "reference_id": "your_model_id",
    "format": "mp3",
}

with httpx.Client() as client:
    res = client.post(
        "https://api.fish.audio/v1/tts",
        headers={
            "Authorization": "Bearer <YOUR_API_KEY>",
            "Content-Type": "application/json",
            "model": "s2.1-pro-free",
        },
        json=body,
    )

res.raise_for_status()

with open("output.mp3", "wb") as f:
    f.write(res.content)

JavaScript

import { writeFile } from "fs/promises";

const body = {
  text: "Hello, world!",
  reference_id: "your_model_id",
  format: "mp3",
};

const res = await fetch("https://api.fish.audio/v1/tts", {
  method: "POST",
  headers: {
    Authorization: "Bearer <YOUR_API_KEY>",
    "Content-Type": "application/json",
    model: "s2.1-pro-free",
  },
  body: JSON.stringify(body),
});

if (!res.ok) {
  throw new Error(`TTS request failed: ${res.status} ${await res.text()}`);
}

const buffer = Buffer.from(await res.arrayBuffer());
await writeFile("output.mp3", buffer);

83 Sprachen. Keine harten Nutzungslimits. Keine Kreditkarte. Voice Cloning inklusive.

Jede andere State-of-the-Art TTS-API berechnet Gebühren ab dem ersten Token. S2.1 Pro nicht.

Klonen Sie eine Stimme in weniger als 60 Sekunden →

Vollständige API-Dokumentation →