Baseten transkribiert mit Qwen3-ASR im Batch siebenmal schneller

Batch-Transkription ist ein Durchsatzproblem

Baseten unterscheidet bei Speech-to-Text zwei Workloads. Bei der Echtzeit-Transkription geht es um Latenz, denn ein Sprachagent braucht die Wörter innerhalb weniger hundert Millisekunden zurück. Bei der Batch-Transkription zählt der Durchsatz: Podcast-Netzwerke, Meeting-Notizen-Produkte und Callcenter-Archive verfügen über Stunden an aufgezeichnetem Audio und wollen es möglichst günstig transkribieren. Dafür muss jede GPU so viele Audiostunden wie möglich verarbeiten.

Das Unternehmen gibt an, Qwen3-ASR 1.7B auf seiner Plattform so optimiert zu haben, dass die niedrigsten Kosten pro Audiominute unter allen Transkriptionsanbietern erreicht werden. Qwen3-ASR 1.7B ist das Open-Weight-Spracherkennungsmodell des Qwen-Teams und steht unter der Apache-2.0-Lizenz. Es unterstützt mehr als 30 Sprachen und 22 chinesische Dialekte und liegt auf der Pareto-Grenze des Open ASR Leaderboards von Hugging Face, mit einer durchschnittlichen Wortfehlerrate (WER) von 5,4 %. Auf diesem Leaderboard erreicht es 5,40 % und liegt damit nur 0,07 Punkte hinter NVIDIA Nemotron 3.5 Transcribe 30B-A4B (5,33 %), dem genauesten Modell, das deutlich größer ist.

Vier Optimierungsbereiche

Baseten ging vom OpenAI-kompatiblen Transkriptions-Endpunkt von vLLM aus, der Audio in 30-Sekunden-Fenster zerlegt und diese gebündelt durch das Modell schickt. Anschließend analysierte das Unternehmen jede Phase einer Anfrage unter Last und konzentrierte sich auf vier Bereiche.

• Natives Audio-Decoding: Der Standard-Loader von vLLM nutzt PyAV, das Frame für Frame in Python dekodiert und die Global Interpreter Lock hält, sodass Decoding-Threads nacheinander laufen. Baseten ersetzte ihn durch torchcodec, das die gesamte Datei in einem nativen Aufruf an FFmpeg übergibt. Lange Dateien werden zudem parallel über Zeitbereiche mit kleinen Überlappungen dekodiert. Laut Unternehmen lässt sich eine Stunde Audio in deutlich unter einer Sekunde vorverarbeiten. In den Messungen benötigte der Python-Decoder für eine einminütige Datei allein 76 ms, bei 8 gleichzeitig dekodierten Dateien aber 2.195 ms, während der native Decoder allein 45 ms und bei 8 Dateien 48 ms brauchte.
• KV-Cache-Quantisierung: Die Attention über den KV-Cache beansprucht bei hoher Parallelität den größten Anteil der GPU-Zeit. Speichert man den Cache in FP8, halbiert sich die pro Schritt gelesene Datenmenge, und doppelt so viele Sequenzen passen in den Speicher. Da das Standard-Backend FlashAttention-2 von vLLM auf der RTX PRO 6000 keinen FP8-Cache unterstützt, setzte Baseten FlashInfer-Kernel ein, was die Speicherauslastung des Attention-Kernels von 50 % auf 80 % steigerte. Die Gewichte bleiben in BF16, da die Quantisierung der Gewichte die WER auf den Testdatensätzen des Unternehmens erhöhte.
• Host-to-Device-Synchronisationen: Das Attention-Backend benötigte die Länge jeder Sequenz von der GPU, und der Audio-Encoder las pro Layer die maximale Clip-Länge zurück. In beiden Fällen musste die CPU warten. Baseten hält stattdessen Host-seitige Kopien dieser Werte vor. Die GPU-Auslastung unter Last stieg von 86 % auf 97 %, und die Engine wechselte von CPU-gebunden zu GPU-gebunden.
• Request-Handling: Vier API-Server-Prozesse laufen der Engine voraus, sodass Decoding und die Extraktion der Log-Mel-Features parallel ablaufen. Der Thread-Pool für die Vorverarbeitung in jedem Prozess wurde verdoppelt.

Ergebnisse bei Durchsatz und Latenz

Alle Vergleiche laufen auf einer einzelnen RTX PRO 6000 mit denselben Gewichten. Getestet wurde unverändertes vLLM aus dem Upstream gegen Basetens Implementierung bei 64 gleichzeitigen Anfragen. Vanilla-vLLM erreicht ein Plateau bei etwa dem 380-fachen Echtzeitfaktor (RTF), während der optimierte Stack bei 5-Minuten-Clips das 2.645-Fache und bei stundenlangen Dateien das 3.128-Fache erreicht. Der Vorsprung wächst mit der Clip-Länge, von 4x bei 10-Sekunden-Clips auf 7x bei 5-Minuten-Clips. Vanilla-vLLM konnte Baseten bei Audio über 10 Minuten nicht testen, da solche Dateien nicht in eine einzige Anfrage passen.

Auch die Latenz verbesserte sich. Bei 5-Minuten-Clips sank die Dauer einer einzelnen Anfrage von 5,1 auf 1,5 Sekunden, und bei 64 gleichzeitigen Anfragen fiel der Median von 50 auf 7,3 Sekunden, was Baseten als 6,9-fach niedrigere Latenz beschreibt. Dateien, die Anwender zuvor aufteilen mussten, kommen nun in einer einzigen Anfrage zurück: nach 3,0 Sekunden bei 30 Minuten Audio und nach 4,7 Sekunden bei einer ganzen Stunde.

Was das für Anwender bedeutet

Für Teams, die große Audioarchive verarbeiten, deuten die Zahlen auf niedrigere Kosten pro Stunde und weniger Umwege hin, da lange Aufnahmen vor dem Einreichen nicht mehr aufgeteilt werden müssen. Baseten gibt an, Qwen3-ASR seit dem Start des Modells auf seiner Plattform für die Batch-Transkription bereitzustellen, und dass das Echtzeit-Deployment im Speech-to-Text-Benchmark von Coval die niedrigste WER und die geringste Latenz zeigt. Die Leistungswerte sind eigene Messungen des Unternehmens im Vergleich zu einer unveränderten vLLM-Baseline.