Whisper-Modellvergleich für Untertitel: Tiny, Small, Turbo und Large-v3

Das größte Whisper-Modell ist nicht automatisch das beste für Untertitel. large-v3-turbo hat etwa halb so viele Parameter wie large-v3 und läuft rund achtmal schneller, und bei gewöhnlichem Filmmaterial ist der Unterschied in der fertigen Untertiteldatei klein genug, dass die Geschwindigkeit den Ausschlag gibt. Es gibt auch echte Fälle, in denen ein kleineres Modell ein besseres Transkript liefert als ein größeres.

Hier sind die Zahlen, was sie konkret für die Untertitelarbeit bedeuten, und die Fehlerbilder, die ein Modell schlechter aussehen lassen, als es ist.

Die Modelle im Vergleich

Parameter und relative Geschwindigkeit stammen von OpenAIs Whisper-Modellkarte; die Größenangaben sind die tatsächlichen Summen der CTranslate2-Builds, die Sablate herunterlädt, keine gerundeten Schätzwerte.

Die Zeile, die aus dem Muster ausbricht, ist turbo. Es hat mehr Parameter als medium und läuft trotzdem etwa viermal schneller — das sagt die Parameterzahl allein nicht voraus.

Warum turbo die Empfehlung verändert

Turbo ist kein von Grund auf neu trainiertes, kleineres Modell. Es ist large-v3, dessen Decoder von 32 auf 4 Schichten beschnitten und danach zwei weitere Epochen lang auf denselben mehrsprachigen Transkriptionsdaten nachtrainiert wurde. Whisper verbringt den größten Teil seiner Zeit im Decoder, also bringt ein so radikaler Schnitt einen sehr großen Geschwindigkeitsgewinn, während der Encoder — der Teil, der tatsächlich zuhört — unangetastet bleibt.

Zwei Einschränkungen kommen damit — beide von OpenAI dokumentiert, nicht bloß Community-Erfahrung:

• Es wurde ohne Übersetzungsdaten nachtrainiert. Turbo ist ein Transkriptionsmodell. Willst du Whispers Aufgabe „Sprache zu englischer Übersetzung" nutzen, ist turbo das falsche Werkzeug — transkribiere in der Ausgangssprache und übersetze den Text danach, was ohnehin der bessere Workflow ist.
• Manche Sprachen verlieren mehr als andere. Turbo liegt bei den meisten Sprachen auf dem Niveau von large-v2, verliert aber bei Thailändisch und Kantonesisch merklich mehr. Arbeitest du in diesen Sprachen, teste es, bevor du dich festlegst.

Für alles andere ist turbo die vernünftige Standardwahl für Untertitel: fast die Qualität von large bei einer Geschwindigkeit, die eine zweistündige Aufnahme zu einem machbaren Auftrag macht.

Liefert das größte Modell die besten Untertitel?

Nicht immer, und die Ausnahme lohnt sich zu kennen, denn sie wirkt wie ein Bug, wenn man darauf stößt.

Wir haben das an einem 101 Sekunden langen türkischen Clip gemessen, auf einer RTX 3060 Ti mit float16, über den eigenen Transkriptionspfad der App. Danach sortiert, wie viel der Sprache jedes Modell tatsächlich erfasst hat, lag medium vorn. large-v3 ließ Sprache aus, die medium korrekt transkribiert hat — die ersten Worte des Clips und mehrere kurze Zwischenrufe fehlten einfach. Keiner der üblichen Hebel brachte sie zurück: den Sprachaktivitäts-Filter deaktivieren, den No-Speech-Schwellenwert anheben, den Log-Probability-Schwellenwert entfernen, die Temperatur festhalten. Das Entfernen des Log-Probability-Schwellenwerts machte es sogar deutlich schlimmer und kürzte das Transkript von etwa 1.110 Zeichen auf 429.

Wir haben außerdem den oft wiederholten Community-Tipp getestet, large-v2 statt large-v3 zu nutzen. Bei diesem Clip war es das schwächste der Gruppe: Es ließ einen durchgehenden 30-Sekunden-Abschnitt komplett aus, von 28,7 s bis 58,7 s, und produzierte 106 Wörter, wo medium 178 lieferte.

Ein einziger Clip ist kein Benchmark, und dieser hier war kurz, türkisch und im Gesprächston. Nimm die Methode mit, nicht die Rangfolge: transkribiere dieselbe Datei mit zwei Modellen, achte auf das, was fehlt, statt auf das, was falsch geschrieben ist, und wähle das Modell, das alles gehört hat. Auslassungen kosten in Untertiteln weit mehr als Tippfehler, denn ein Zuschauer kann über ein falsches Wort hinweglesen, aber keine Zeile lesen, die gar nicht da ist.

Wenn ein gutes Modell wie ein schlechtes wirkt

Drei Fehlerbilder erzeugen Beschwerden wie „das große Modell ist schlechter", die mit dem Modell selbst nichts zu tun haben.

1. Gleichstände bei Wort-Zeitstempeln zerstören die Zeilentrennung. Whisper gibt pro-Wort-Zeitstempel aus, und benachbarte Wörter teilen sich häufig exakt eine Grenze — im untersuchten Clip lagen 172 von 177 Wortlücken bei genau 0,000 Sekunden. Eine Trennlogik, die eine lange Untertitelzeile an der größten Lücke aufteilt, findet dann jeden Kandidaten gleich groß, nimmt den ersten und wiederholt das rekursiv — und schält dabei ein Wort nach dem anderen ab. Das Symptom ist ein Transkript, das in Ein-Wort-Untertitel zerfetzt wird, und es wird schlimmer mit dem Modell, das die meisten Wörter liefert. Die Korrektur des Tie-Breaks zugunsten des zeitlichen Mittelpunkts brachte einen Clip von 90 Untertitelzeilen (78 davon einwortig) auf 28 Zeilen mit nur einer einzigen Ein-Wort-Zeile. Das Modell hat sich dabei nie geändert.

2. Das ausgewählte Modell ist nicht das Modell, das tatsächlich lief. Modell-Repositorys werden zwischen Download-Registries und Inferenz-Bibliotheken uneinheitlich benannt. Liegt ein heruntergeladenes Modell auf der Festplatte unter einem Repository-Namen, während der Loader unter einem anderen sucht, entsteht entweder ein stiller Fallback oder ein Fehler, der wie ein Netzwerkproblem aussieht — während 1,6 GB des richtigen Modells längst vorhanden sind.

3. Eine fehlgeschlagene Neu-Transkription lässt das alte Transkript stehen. Schlägt ein erneuter Lauf fehl und die Anwendung setzt den Auftrag zurück, behält dabei aber den angeforderten Modellnamen, siehst du jetzt die Ausgabe des vorherigen Modells, beschriftet als die neue. Jeder Vergleich, der aus diesem Zustand entsteht, ist falsch. Machst du einen Benchmark, prüfe erst, ob sich der Text wirklich geändert hat, bevor du Schlüsse ziehst — identische Ausgabe von zwei verschiedenen Modellen ist ein Warnsignal, kein Befund.

VRAM, Speicherplatz und was dein Rechner stemmen kann

Die Downloadgrößen aus der Tabelle oben sind auch ein guter Anhaltspunkt für den Speicherbedarf während der Transkription. Praktische Richtwerte:

• 4 GB VRAM oder weniger, oder keine dedizierte GPU — small ist der Sweet Spot. tiny eignet sich für Entwürfe und Timing-Checks, nicht für die Auslieferung.
• 6–8 GB VRAM — large-v3-turbo läuft hier locker. Das ist die Konfiguration, mit der die meisten Leute fahren sollten.
• 10 GB VRAM oder mehr — large-v3, wenn das Audio es wirklich braucht: starke Akzente, überlappende Sprecher, schlechte Mikrofone.
• Nur CPU — small für alles, was du heute noch brauchst, turbo, wenn du es einfach laufen lassen kannst.

Die Präzision zählt hier genauso viel wie die Modellgröße. Die CTranslate2-Builds, auf denen Whisper läuft, unterstützen float16 und int8, und eine niedrigere Präzision senkt den Speicherbedarf deutlich — mit einem Qualitätsverlust, der bei int8 gering und bei float16 auf einer GPU meist gar nicht wahrnehmbar ist.

Auf der GPU kannst du mit etwa der fünf- bis zehnfachen Geschwindigkeit gegenüber derselben Maschine auf der CPU rechnen. In Sablate unter Windows wird die NVIDIA-CUDA-Runtime erst beim ersten GPU-Lauf heruntergeladen statt im Installer mitgeliefert, was den Download für alle klein hält, die sie nie nutzen werden.

Welches Modell solltest du wirklich wählen?

Diese letzte Zeile ist die, die die Rechnung verändert. Ist ein Transkript die Grundlage für acht Übersetzungen, ist ein Fehler nicht ein Fehler — es sind acht. Der mehrsprachige Workflow erklärt, warum das Ausgangstranskript das langsame Modell und ein sorgfältiges Korrekturlesen verdient.

In Sablate laufen Fast und Balanced (tiny und small) im kostenlosen Plan; Accurate und Best gehören zu Pro, einer einmaligen Zahlung von $29, die auf der Preisseite im Detail steht. Egal welches Modell du nutzt, das Ergebnis landet im selben Editor und exportiert in dieselben Formate — SRT, VTT und ASS — die Modellwahl entscheidet also darüber, wie viel du danach korrigierst, nicht darüber, was du überhaupt produzieren kannst.

So testest du das an deinem eigenen Filmmaterial

Fünf Minuten Methode schlagen jeden veröffentlichten Benchmark, auch diesen hier:

1. Nimm einen 60 bis 120 Sekunden langen Clip, der repräsentativ ist — dein schlechtestes Mikrofon, deine üblichen Akzente, dein tatsächlicher Raum.
2. Transkribiere ihn mit zwei Kandidaten-Modellen, ohne sonst etwas zu ändern.
3. Vergleiche zuerst auf Auslassungen, danach auf Rechtschreibfehler.
4. Zähle die Ein-Wort-Untertitelzeilen. Ein Haufen davon deutet auf die Segmentierung hin, nicht auf das Modell.
5. Vergleiche erst danach die tatsächlich vergangene Zeit und entscheide, was dir diese Zeit wert ist.

Das Modell, das bei deinem Material alles hört, ist das beste Modell für dich — und das muss nicht das größte sein.