Spracherkennung auf einem zehn Jahre alten Büro-PC

Der Verein hat drei ausgemusterte Büro-Mini-PCs im eigenen Haus gefunden, statt sie zu kaufen. Über sie stand in unserer eigenen Beschreibung ein Satz, der sich als falsch herausgestellt hat: KI-Modelle darauf zu rechnen sei „ohne Grafikkarte so langsam, dass es keinen Zweck hätte“.

Das haben wir nachgemessen — nicht überschlagen, nicht aus Datenblättern abgeleitet, sondern in 52 Läufen auf der echten Maschine.

Der Aufbau

Der Prüfling ist ein HP EliteDesk 800 G3 Mini von 2017: vier Rechenkerne, 8 GB Arbeitsspeicher, keine Grafikkarte. Ein Gerät, das Firmen unter den Schreibtisch stellen und nach fünf Jahren aussortieren.

Als Material dienen drei Korpora mit geprüften Referenztexten — ohne verlässliche Vorlage lässt sich keine Fehlerrate berechnen:

• Hörbuch — 20 Ausschnitte deutscher Aufnahmen, sauber vorgelesen.
• Parlamentsrede — 20 Redebeiträge aus dem Europäischen Parlament, alle mit von Hand geprüftem Transkript. Mehrere Sprecher, Saalakustik, halbspontane Rede: das dem Vereinsalltag am nächsten liegende Material.
• Telefon — 25 Aufnahmen aus einem Bankdienst-Datensatz, verrauscht und spontan gesprochen. Der schwierige Fall.

Gemessen wurde die Wortfehlerrate: der Anteil an Wörtern, die eingefügt, ausgelassen oder verwechselt wurden.

Ein erster Anlauf war unbrauchbar, und das gehört zum Bericht. Wir hatten Testmaterial mit einer Sprachsynthese erzeugt, um eine bekannte Vorlage zu haben. Die Roboterstimme brachte die Erkennung zum Abbrechen: ein mittelgroßes Modell gab nach 18 % des Textes auf — und wirkte dadurch schneller als es ist, weil es schlicht weniger Arbeit tat. Wer nur auf die Stoppuhr geschaut hätte, wäre mit einer falschen Empfehlung herausgegangen.

Erster Befund: die Laufzeitumgebung schlägt das Modell

Wir hatten erwartet, dass ein besseres oder größeres Modell den Unterschied macht. Der größte Einzelhebel lag woanders.

Dieselben Modellgewichte laufen dreimal schneller, wenn man sie einer anderen Software zum Ausführen gibt. Whisper „turbo“ erreicht unter whisper.cpp 0,65-fache Echtzeit — eine Stunde Aufnahme braucht anderthalb Stunden. Unter CTranslate2 erreicht dasselbe Modell 1,93-fache Echtzeit, bei sogar etwas besserer Genauigkeit. Kein anderes Modell, keine andere Hardware, keine Abstriche — nur ein anderer Motor unter derselben Haube.

Zweiter Befund: der Zuschnitt des Audios zählt genauso viel

Der Effekt zeigte sich erst, als wir das Testmaterial änderten — und er hätte uns beinahe eine falsche Empfehlung untergeschoben.

Solange wir in 15-Sekunden-Schnipseln maßen, brachte keine der üblichen Optimierungen etwas. Sprachpausen überspringen: wirkungslos. Stapelverarbeitung: wirkungslos. Beides zusammen: wirkungslos. Der Grund war nicht das Verfahren, sondern der Prüfstand: In kurzen Schnipseln gibt es keine Pausen zu überspringen und keine Segmente zu bündeln.

Dieselbe Audiomenge am Stück ergab ein anderes Bild. Stapelverarbeitung hebt das Tempo auf 2,97-fache Echtzeit — 54 % mehr Durchsatz, bei unveränderter Genauigkeit. Und der Sprachpausen-Filter senkt die Fehlerrate auf 8,8 %, den besten Wert der ganzen Reihe. Beides zusammen geht nicht: Die Stapelverarbeitung zerlegt das Audio bereits selbst und überschreibt die Einstellung. Man wählt.

Noch deutlicher wird der Zuschnitt bei Parakeet. Dasselbe Modell, dieselbe Aufnahme, nur andere Schnittstellen: Alle 20 Sekunden nach der Uhr geschnitten ergibt 36,1 % Fehler — jeder Schnitt fällt mitten in ein Wort. An Sprechpausen geschnitten ergibt 15,3 %, bei gleichem Tempo. Die Fehlerrate mehr als halbiert, ohne das Modell anzufassen.

Was dabei herauskommt: drei Betriebspunkte

Gegenüber dem naiven Ausgangspunkt ist das der Faktor 4,6 — ohne einen Punkt Genauigkeit zu opfern.

Nachtrag: eine echte Stunde ändert die Empfehlung

Alle Zahlen oben stammen von Aufnahmen bis fünf Minuten. Weil sich daraus Stundenangaben nur hochrechnen ließen, haben wir den Test mit 79,6 Minuten zusammenhängendem Audio wiederholt — 300 verschiedene Aufnahmen, 9.044 geprüfte Referenzwörter.

Längere Aufnahmen sind genauer, nicht ungenauer. Wir hatten mit dem Gegenteil gerechnet — mit Abdriften und Aussetzern. Tatsächlich sinkt die Fehlerrate deutlich (6,2 statt 9,5 %), und das Tempo steigt sogar leicht. Der Grund dürfte der längere Zusammenhang sein: Das Modell hält Namen und Schreibweisen über die Aufnahme hinweg konsistent, wo es bei Schnipseln jedes Mal neu raten muss. Eine Stunde Sitzung ist damit in 18,6 Minuten mitgeschrieben.

Der Sprachpausen-Filter fällt als Empfehlung weg. Auf kurzem Material war er die genaueste Wahl; über eine Stunde ist er es nicht mehr (6,4 gegen 6,2 %), braucht mehr Zeit — und 7,5 von 7,8 GB Arbeitsspeicher. Das ist die erste harte Grenze dieser Maschine: Bei einer zweistündigen Sitzung ginge ihr der Speicher aus. Die Stapelverarbeitung kommt mit 5,2 GB aus, Parakeet mit 2,8.

Für den Betrieb heißt das: Stapelverarbeitung ist die richtige Einstellung, und wer sehr lange Aufnahmen hat, nimmt Parakeet — es verarbeitet die Stunde in fünfeinhalb Minuten und ist beim Speicher am genügsamsten, weil es die Aufnahme ohnehin in Segmente zerlegt.

Die sparsamere Kiste ist die bessere

Zum Schluss haben wir dieselbe Messung auf einem der beiden älteren Schwestergeräte wiederholt — Baujahr 2015/16, ein 35-Watt-Prozessor gegen die 65 Watt des jüngeren. Die Erwartung war ein deutlicher Rückstand.

Der ältere Rechner ist 5 % langsamer und verbraucht ein Viertel weniger. Die Genauigkeit ist auf die Nachkommastelle identisch — dasselbe Modell, dieselbe Software. Im Leerlauf ist der Abstand noch deutlicher: 0,2 Watt gegen 3,0.

Damit fällt eine Annahme, die wir nie geprüft hatten: dass für rechenintensive Arbeit das schnellere Gerät zu nehmen sei. Für Aufgaben, die ohnehin im Hintergrund laufen, ist die sparsame Variante die bessere — sie braucht kaum länger und kostet spürbar weniger Strom. Das jüngere Gerät bleibt trotzdem gesetzt, wo es um fremden Code geht: Es ist das einzige der drei ohne offene Prozessorlücke.

Auf dem sitzungsähnlichen Parlamentsmaterial liegen die Fehlerraten bei 6,8 % (Parakeet), 8,9 % (whisper.cpp) und 9,3 % (faster-whisper) — also durchweg besser als beim vorgelesenen Hörbuch. Die Bedenken, echte Rede mit mehreren Sprechern sei zu schwer, haben sich nicht bestätigt.

Was nichts brachte

Der ehrlichere Teil. Neun naheliegende Optimierungen wurden geprüft, keine half:

• Modelle verkleinern (Quantisierung) — üblicherweise der erste Griff. Hier durchgehend ein Verlustgeschäft: Das verkleinerte Whisper-Modell war langsamer als das volle, weil das Entpacken mehr kostet als die kleinere Datenmenge einspart. Bei Parakeet verschlechterte es die Genauigkeit um vier Punkte, ohne Zeit zu sparen.
• Ein größeres Modell — „large-v3“ ist schlechter und langsamer als das kleinere „turbo“.
• Die Suche abkürzen — 3 % schneller, dafür messbar ungenauer.
• Volle statt reduzierter Zahlengenauigkeit — langsamer, nicht genauer.
• Zwei Vorgänge parallel — deutlich langsamer, in beiden geprüften Formen. Damit ist auch die Vermutung widerlegt, das Verfahren nutze die vier Kerne schlecht aus. Es nutzt sie bereits.
• Die eingebaute Grafikeinheit. Die Fachpresse meldete für die jüngste whisper.cpp-Version bis zu zwölffache Beschleunigung durch integrierte Grafik. Auf unserer zehn Jahre alten Grafikeinheit ist es umgekehrt: 0,53-fach gegen 0,65-fach auf dem Hauptprozessor — langsamer. Die Werbezahl stammt von aktueller Grafik mit Matrix-Recheneinheiten, die es hier nicht gibt. Ein Nebeneffekt bleibt nützlich: Der Grafik-Lauf belegt nur ein Viertel eines Kerns statt aller vier.

Auch zwei viel beworbene Modelle enttäuschten. Canary-1B, auf öffentlichen Ranglisten als Genauigkeitsführer gehandelt, landete hinter beiden Whisper-Wegen. Und CrisperWhisper, ein eigens für Deutsch nachtrainiertes Modell, lieferte auf den Telefonaufnahmen 85,7 % Wortfehler. Ein Teil des Abstands erklärt sich damit, dass es absichtlich wörtlich transkribiert, samt „äh“ und Wiederholungen, während unsere Vorlagen geglättet sind. Die Größenordnung erklärt das nicht.

Ein Detail, das ohne Nachzählen als schlechte Erkennung durchgegangen wäre: whisper.cpp lieferte auf der langen Aufnahme 25,2 % Fehler. Die Zählung zeigt warum — es gab nur 439 von 524 Wörtern aus. Keine Halluzination, keine Wiederholungsschleife: Es überspringt Passagen. Wer nur die Fehlerrate betrachtet, hält ein Auslassen für ein Verwechseln.

Was das kostet

Der Rechner zieht 3 Watt im Leerlauf und 37 Watt bei der Spracherkennung, gemessen am Prozessor. Eine Stunde Audio zu transkribieren kostet damit rund 11,6 Wattstunden — auf dem sparsameren Schwestergerät sogar nur 8,8, also weniger als eine Stunde Fernsehen.

Der Vergleich mit der KI-Workstation fällt dabei anders aus, als man erwartet, und wir hatten ihn hier zunächst falsch dargestellt. Im Leerlauf ist der Büro-PC klar sparsamer: 3 Watt gegen 16 Watt allein für die Grafikkarte. Pro geleisteter Arbeit dreht sich das Verhältnis um. Die RTX 3090 zieht unter Last gemessene 247 Watt, ist dabei aber 44-mal schneller — und braucht deshalb für eine Stunde Audio nur rund 1,7 Wattstunden gegen 11,6 auf dem Büro-PC. Wer viel zu transkribieren hat, verbraucht auf der Grafikkarte weniger Strom, nicht mehr. Der sparsame kleine Rechner gewinnt nur, solange wenig zu tun ist.

Weil die Maschine im ausgeschalteten Zustand über das Netzwerk oder zu fester Uhrzeit von selbst hochfahren kann — beides haben wir geprüft, beides funktioniert —, ließe sich diese Arbeit in die Stunden legen, in denen die Sonne auf dem Dach mehr liefert, als das Haus verbraucht. Anfang August steht sie ab etwa 7:15 Uhr hoch genug dafür.

Ein Vorbehalt, der über allen Zahlen steht

Alle drei Korpora sind fremd und öffentlich — und das ist mehr als ein Schönheitsfehler. In Parakeets Trainingsdaten steht Multilingual LibriSpeech ausdrücklich drin, also unser Hörbuch-Testmaterial. Mit Europarl-ASR ist dieselbe Quelle vertreten wie bei unserem Parlamentskorpus: andere Aufnahmen, gleiches Haus, gleiche Rednerinnen und Redner. Whispers Trainingsdaten sind überhaupt nicht offengelegt, dort lässt sich nicht einmal prüfen.

Ein Modell, das seine Prüfungsaufgabe schon kennt, schneidet besser ab, als es soll. Die Absolutwerte in diesem Bericht sind deshalb eher zu gut. Die Rangfolge dürfte halten — sie wurde über drei sehr verschiedene Materialarten hinweg bestätigt —, aber wer wissen will, was auf der eigenen Vereinssitzung herauskommt, muss mit eigenem, nie veröffentlichtem Audio nachmessen. Das ist der nächste Schritt.

Was bleibt

Für den Verein ändert sich eine Zuständigkeit: Spracherkennung braucht weder Grafikkarte noch fremden Dienst. Sie läuft auf einem Gerät, das sonst im Schrank verstaubt wäre, schnell genug für den täglichen Betrieb und sparsam genug, um nebenbei zu laufen.

Der übertragbare Teil ist aber der andere. Beide großen Gewinne kamen nicht von einem neueren Modell, sondern davon, dasselbe Modell anders auszuführen und das Audio anders anzuliefern. Wer bei solchen Fragen zuerst nach mehr Hardware oder dem nächsten Modell greift, übersieht leicht den Faktor vier, der schon daliegt. Und beinahe hätten wir ihn selbst übersehen: Auf zu kurzen Testdateien sahen alle wirksamen Hebel wie Nieten aus. Das findet man nur durch Messen — und dadurch, dass man auch die neun Fehlschläge veröffentlicht.