Parakeet vs. Apples Speech-API vs. MOSS: Benchmark Runde 2

Das Ergebnis vorweg

NVIDIAs Parakeet TDT v2, ausgeführt als das int8-CoreML-Modell, das eine echte App ausliefern würde, ist die genaueste englische On-Device-Engine, die wir gemessen haben: 2,01 % WER auf LibriSpeech test-clean und 3,40 % auf test-other. Aber das Rennen bei sauberer Sprache ist inzwischen erstaunlich eng. Drei Engines mit völlig unterschiedlichen Architekturen – ein Speech-Transducer von NVIDIA, ein 0,9B-Audiosprachmodell aus dem OpenMOSS-Labor der Fudan-Universität und Apples System-Engine – landeten innerhalb von 0,11 Punkten voneinander. Bei verrauschter Sprache trennen sie sich.

Niedriger ist besser: WER steht für Wortfehlerrate, also den Prozentsatz der Wörter, die eine Engine ersetzt, auslässt oder erfindet. Gleiches Korpus wie in Runde 1: LibriSpeech test-clean (2.620 Äußerungen sauber vorgelesener Sprache) und test-other (2.939 schwierigere, verrauschtere Äußerungen), alle 5.559 vollständig auf demselben Apple M2 Pro (32 GB, macOS 26.5.1) ausgeführt, bewertet mit demselben Normalizer und demselben Bewertungscode.

Warum eine Runde 2

Als wir die erste Runde dieses Benchmarks veröffentlichten, war die häufigste Reaktion – auf Hacker News und in jeder Entwickler-Community, die darüber sprach – irgendeine Variante von: Whisper ist nicht mehr Stand der Technik, testet Parakeet. Berechtigt. Und ein Hacker-News-Kommentator wies uns auf MOSS-Transcribe-Diarize hin, ein wenige Tage zuvor veröffentlichtes Modell, das Transkription und Sprecherdiarisierung gemeinsam in einem Durchgang erledigt.

Diese Runde ergänzt also drei Engines, gemessen an denselben 5.559 Äußerungen mit derselben Bewertungs-Pipeline – wodurch jede Zahl hier direkt mit Runde 1 vergleichbar ist. Wie zuvor lässt sich jedes Rohtranskript unten herunterladen, sodass Sie uns mit Ihrem eigenen Normalizer nachbewerten können, falls Sie mit unserem nicht einverstanden sind.

Parakeet: der neue Genauigkeits-Champion, mit einem Sternchen, das niemand abdruckt

Parakeet TDT 0.6B v2 gewinnt diesen Benchmark. Bei sauberer Sprache beträgt sein Vorsprung vor Apples Engine 0,11 Punkte – ein Fotofinish. Bei verrauschter Sprache ist der Vorsprung real: 3,40 % gegenüber 4,56 %, also etwa 25 % weniger Fehler. Wenn Ihr einziges Kriterium die englische Genauigkeit bei schwierigem Audio ist, ist Parakeet v2 das Stärkste, was Sie heute On-Device auf einem Mac ausführen können.

Hier kommt das Sternchen. NVIDIAs veröffentlichte Zahlen für dieses Modell sind 1,69 % und 3,19 %, gemessen an der Referenz-GPU-Implementierung. Wir haben 2,01 % und 3,40 % gemessen, weil wir das getestet haben, was eine App tatsächlich ausliefern kann: die int8-quantisierte CoreML-Konvertierung (über das quelloffene FluidAudio-Paket, dasselbe, das Inscribe bereits für die Sprecherdiarisierung nutzt). Der Unterschied – rund +0,3 bei sauberer und +0,2 bei verrauschter Sprache – ist der Preis für die Quantisierung plus die CoreML-Portierung. Wir konnten diese Zahl nirgends veröffentlicht finden, und sie ändert die Geschichte: Der Vorsprung des auslieferbaren Parakeet gegenüber Apples eingebauter Engine beträgt nur etwa ein Drittel dessen, was die veröffentlichten Zahlen nahelegen.

Parakeet v3, die mehrsprachige Version, die 25 europäische Sprachen abdeckt, tauscht englische Genauigkeit gegen diese Abdeckung: 2,51 % clean / 4,28 % other. Interessanterweise übertrifft es Apples Engine bei verrauschter Sprache immer noch knapp, während es bei sauberer Sprache verliert, und es schlägt Whisper Small, das mehr Sprachen abdeckt, überall.

MOSS: eine andere Art von Herausforderer

MOSS-Transcribe-Diarize ist kein weiterer Spracherkenner. Es ist ein durchgängiges Audiosprachmodell mit 0,9 Milliarden Parametern, das gleichzeitig transkribiert und diarisiert: Seine Ausgabe ist ein zeitgestempeltes Transkript mit bereits angehängten Sprecher-Labels wie [S01] und [S02], über 50+ Sprachen hinweg, in einem einzigen Durchgang über bis zu 90 Minuten Audio.

Bei der reinen Transkriptionsgenauigkeit landete es bei 2,07 % clean / 4,68 % other. Statistisch nicht von Apples SpeechAnalyzer bei sauberer Sprache zu unterscheiden, bei verrauschter Sprache leicht dahinter und vor jedem Whisper-Modell – und das, während es zugleich eine Aufgabe erledigt, an die sich keine andere Engine in dieser Tabelle heranwagt.

Wir haben die Diarisierung mit einem kontrollierten Test geprüft: sechs Äußerungen von drei verschiedenen LibriSpeech-Sprechern, zusammengefügt zu einer 62-sekündigen Datei, sodass das wahre Transkript und die wahren Sprecherwechsel exakt bekannt sind. MOSS erreichte 1,75 % WER bei den Wörtern und ordnete alle 13 seiner ausgegebenen Segmente dem richtigen Sprecher zu – einschließlich der korrekten Wiedererkennung jedes Sprechers, wenn dieser 30+ Sekunden später zurückkehrte. Das ist ein kleiner, einfacher Test, saubere Sprache ohne Überlappungen, aber es ist der schwierige Teil der Diarisierung, richtig gemacht – dort, wo viele Produktions-Pipelines scheitern. Ein richtiger Benchmark für Besprechungen mit mehreren Sprechern (AMI-Korpus, echte Überlappungen, gemessene DER) folgt in Runde 3.

Der Bug, den wir gefunden haben: MOSS verstummt, wenn Sprache bei null beginnt

Benchmarks finden Bugs. Runde 1 fand einen in unserer eigenen App; diese Runde fand einen darin, wie MOSS mit zugeschnittenem Audio umgeht – und der ist es wert, dokumentiert zu werden, denn jeder, der dieses Modell evaluiert, wird darauf stoßen.

In unserem ersten vollständigen Durchgang lieferte MOSS für 182 der 2.620 sauberen Clips ein völlig leeres Transkript zurück – deterministisch, bei einwandfreiem Audio. Das Muster war nicht leicht zu finden: LibriSpeech-Clips sind eng zugeschnitten, sodass Sprache bei genau t=0 beginnt, und MOSS, trainiert auf lange Aufnahmen, in denen im ersten Moment niemand spricht, reagiert auf manche dieser Clips, indem es sofort sein End-of-Output-Token ausgibt. Am Ende Stille anzuhängen machte es schlimmer: 426 zusätzliche Clips verstummten. Sie am Anfang voranzustellen behob jeden Clip, den wir getestet haben.

Die veröffentlichten Zahlen verwenden ein einheitliches Protokoll: jedem Clip wird eine Sekunde Stille vorangestellt, was keine Wörter hinzufügt und ein Transkript nicht schmeicheln kann, mit einer dokumentierten Wiederholungsleiter (0,5 s, 2 s, 0 s) für Nachzügler. Nur 7 von 5.559 Clips benötigten die Leiter; keiner endete leer. Und um zu überprüfen, dass das Padding die Transkriptionsqualität selbst nicht veränderte: Bei den Clips, die sowohl im naiven als auch im gepaddeten Durchlauf transkribiert wurden, verschob sich die Korpus-WER um 0,05 Punkte. Das Padding behob den Verstummungs-Bug und sonst nichts. Die Rohtranskripte pro Äußerung aus dem gepaddeten Durchlauf sind in den herunterladbaren Daten enthalten.

Die praktische Erkenntnis für alle, die MOSS ausliefern: Reale Aufnahmen, die mit einem Atemzug, einem Klicken oder einer halben Sekunde Raumton beginnen, sind sein Idealfall. Eng zugeschnittene Clips sind es nicht.

Methodik – und warum Sie sie überprüfen können

Alles aus der Methodik von Runde 1 gilt weiter: gleiches Korpus, WER auf Korpus-Ebene (Gesamtfehler geteilt durch Gesamtzahl der Referenzwörter, nicht pro Äußerung gemittelt), derselbe Text-Normalizer, der OpenAIs englischen Normalizer nachbildet, Ausfälle als 100 % WER gewertet statt verworfen. Die Testreihe aus Runde 1 reproduzierte OpenAIs veröffentlichte Whisper-WERs auf allen sechs Messungen innerhalb von +0,11 bis +0,42, was die Korpus-Behandlung und Bewertung validiert, durch die all diese Zahlen, alte wie neue, laufen.

Was Runde 2 ergänzt:

• Parakeet lief in derselben XCTest-Testreihe wie jede Engine aus Runde 1, über FluidAudio (fixierte Revision 19600a48), Modelle parakeet-tdt-0.6b-v2/v3-coreml mit dem int8-Encoder – der einzigen Präzision, die das Paket für diese Modelle ausliefert. Frischer Decoder-Zustand pro Äußerung, Aufwärm-Clip von der Messung ausgeschlossen.
• MOSS lief auf derselben Maschine über mlx-audio 0.4.5 (das erste Release, das es unterstützt) auf Apples MLX-Framework, da es ein Python-Modell ohne heutigen Swift-Pfad ist. Um die Bewertung identisch statt nur ungefähr ähnlich zu halten, haben wir unseren Swift-Normalizer und -Scorer in ein eigenständiges Tool kompiliert und MOSS' Rohausgabe mit byteidentischem Code zu jeder anderen Zeile in der Tabelle bewertet.
• Sprecher-Tags und Zeitstempel wurden vor der Bewertung entfernt ([S01], [12.4] und dergleichen von MOSS sind Ausgabe-Rahmung, keine erkannten Wörter). Die rohe getaggte Ausgabe ist im Download für alle erhalten, die die Diarisierung untersuchen möchten.

Die Rohdaten

• summary.json – alle Messungen aus Runde 2 plus Protokolldetails, maschinenlesbar (2 KB)
• raw-transcripts-parakeet-v2.json.gz – alle 5.559 Äußerungen (534 KB)
• raw-transcripts-parakeet-v3.json.gz – alle 5.559 Äußerungen (535 KB)
• raw-transcripts-moss.json.gz – alle 5.559 Äußerungen, einschließlich der getaggten Sprecher-/Zeitstempel-Ausgabe (627 KB)
• Daten aus Runde 1 – Apple SpeechAnalyzer, SFSpeechRecognizer und Whisper

Einschränkungen

• Weiterhin nur Englisch. Parakeet v3 deckt 25 Sprachen ab und MOSS behauptet 50+; wir haben keine davon gemessen. Mehrsprachige Genauigkeit ist ein anderer Benchmark.
• Vorgelesene Hörbuch-Sprache, keine Besprechungen. Besonders MOSS ist für lange Audios mit mehreren Sprechern gebaut, sodass ein Korpus vorgelesener Sprache es womöglich unterschätzt. Der AMI-Besprechungs-Benchmark ist die Fortsetzung.
• Keine Geschwindigkeitstabelle. Alle Engines liefen weit schneller als in Echtzeit (beide Parakeets transkribierten das vollständige 10,5-stündige Korpus in Minuten), aber unsere Zeitmessung erfolgte auf einer Maschine, die andere Arbeit erledigte, weshalb wir keine präzisen Geschwindigkeitsangaben pro Engine veröffentlichen.
• Parakeet ist int8-CoreML. Das ist der Punkt – es ist das, was Apps ausliefern –, aber es bedeutet, dass unsere Zahlen nicht direkt mit GPU-Leaderboard-Einträgen vergleichbar sind, wie es der Abschnitt zur Quantisierungssteuer beziffert.
• MOSS ist heute auf Apple-Plattformen nicht app-tauglich. Python plus MLX funktioniert für Desktop-Pipelines und -Tools; es gibt keinen unterstützten Swift-/CoreML-Pfad, den wir hätten messen können.
• Eine Maschine. M2 Pro, macOS 26.5.1. Die Genauigkeit sollte sich über Apple Silicon hinweg übertragen.

Was wir damit machen

Dieser Benchmark hat Whisper aus unserer App verabschiedet. Seit Inscribe 1.8.9 sind die Whisper-Modelle verschwunden und NVIDIA Parakeet TDT v3 ist die herunterladbare Engine, denn v3 schlägt das Whisper-Small-Modell, das es ersetzt, in jeder Messung hier (2,51/4,28 vs. 3,74/7,95) bei ähnlicher Downloadgröße und deckt dabei 25 europäische Sprachen ab. Auto bevorzugt weiterhin Apples SpeechAnalyzer, wo dieser die Sprache unterstützt, und das mag unter einer Tabelle, in der Apple auf Platz drei sitzt, seltsam wirken – hier also die Begründung: Bei sauberem Englisch liegen die Top drei innerhalb von 0,11 Punkten, also etwa ein anders gehörtes Wort pro Tausend, und SpeechAnalyzer kostet die Nutzer null Megabyte gegenüber Parakeets Halb-Gigabyte-Download. Wo die System-Engine nicht helfen kann, kann Parakeet es jetzt. Parakeets wahre Stärke – verrauschtes Audio – ist genau das, was der Besprechungs-Benchmark in Runde 3 sauber messen wird, und wenn der Abstand dort bestehen bleibt, könnte sich die Voreinstellung erneut ändern. Genau dafür sind diese Benchmarks da.

MOSS haben wir uns entschieden nicht zu übernehmen, zumindest vorerst nicht, und die Begründung ist es wert, gezeigt zu werden, weil es dieselbe Kosten-Nutzen-Abwägung ist, vor der jeder steht, der eine Transkriptions-App ausliefert. Bei der Transkriptionsgenauigkeit ist MOSS gleichauf mit der System-Engine, sodass der gesamte Fall für MOSS auf der Diarisierung ruht. Was es kosten würde: ein 1,7-GB-Modell-Download, etwa 2,7 GB Arbeitsspeicher bei der Inferenz (auf einem Mac machbar, auf einem iPhone unwirtlich) und eine Laufzeitumgebung, die wir heute nicht ausliefern können, da MOSS über Python und MLX läuft, ohne Swift- oder CoreML-Pfad. Es kann außerdem nicht live transkribieren: MOSS benötigt die vollständige Aufnahme, bevor es überhaupt etwas produziert (sein Streaming-Modus streamt Ausgabetext, keine Audioeingabe), sodass Live-Untertitel ohnehin auf einer separaten Engine bleiben würden und MOSS immer nur die Hälfte nach der Aufnahme in der Pipeline ersetzen könnte. Was wir bekämen: eine Sprecherzuordnung, die unsere kontrollierte Probe schlug – gemessen gegen eine aktuelle Pipeline (System-Transkription plus ein dediziertes ~35-MB-Diarisierungsmodell), deren Genauigkeit bei echten Besprechungen wir ebenfalls nicht gebenchmarkt haben. Dreieinhalb Gigabyte Download-plus-Speicher für eine unquantifizierte Verbesserung zu zahlen ist keine Entscheidung, es ist eine Wette. Runde 3 ist also die Entscheidung: beide Systeme auf dem AMI-Besprechungs-Korpus, echte Überlappungen, gemessene DER. Wenn MOSS dramatisch gewinnt, prüfen wir es neu und sagen es hier. Wenn es knapp gewinnt, behält die 35-MB-Pipeline ihren Job.

Weiterführende Artikel

• Runde 1: Apples neue Speech-API vs. Whisper
• Die besten Offline-Transkriptions-Apps
• Private Transkriptions-Apps