Sprache lokal auf dem Mac: erkennen, trennen, sprechen

Sprachnachrichten abschreiben, Gespräche nach Sprechern ordnen, Texte vorlesen lassen, auch mit einer geklonten Stimme: das alles läuft hier lokal auf einem Mac, ohne Cloud. Dieser Artikel sammelt die Messungen und Erfahrungen eines Tages mit mehreren Sprachmodellen. Zu dem Tag gehört auch ein Absturz, bei dem ein kleines Modell mit 1,8 GB Gewichten über 100 GB Speicher belegte.

Das Wichtigste in Kürze

• Whisper Large V3 bleibt für deutschen Text die beste Wahl: etwa 7-fache Echtzeit, 6,1 GB Spitze. In 8 Bit war es auf derselben Aufnahme gleich gut (4 von 2782 Wörtern anders), bei 1,3 GB weniger Speicher.
• Whisper Large V3 Turbo ist 1,7-mal schneller, verhört sich aber deutlich öfter, vor allem bei Namen und ganzen Wendungen.
• MOSS-Transcribe-Diarize 0.9B hört und trennt Sprecher in einem Durchgang, liegt beim deutschen Text aber klar hinter Whisper.
• Mehr als jeder Modellwechsel brachte der Ablauf: Fachwörter als Hinweis, Schnitte nur in Sprechpausen, Zusammenfügen an Satzenden.
• Der Absturz kam von torch auf der Grafik des Macs in float32 mit 7 Minuten Ton am Stück. Über MLX in bfloat16 und in Abschnitten von 30 Sekunden braucht dasselbe Modell 3,9 GB. Länger müssen die Abschnitte nicht sein.
• MLX brachte hier Speicher und eine harte Grenze im Prozess. Genauer wird ein Modell dadurch nicht.

Der Absturz und seine Ursache

Der Anlass für die Messungen war ein Fehlschlag. MOSS-Transcribe-Diarize sollte als neuer Hördienst eine Sprachnachricht von 7 Minuten abschreiben, und zwar am Stück. Der Dienst lief über torch auf der Grafik (Gerät mps) in float32, so wie die Beispiele der Herkunft es für alles außer cuda vorsehen. Angemeldet war er mit 6 GB. Etwa zehn Minuten nach dem Start belegte er mindestens 99,6 GB, die Speicheraufzeichnung hielt eine Spitze von 133,5 GB fest, und der Mac stürzte ab. Nach dem Neustart fuhr die Dienstverwaltung den Dienst sofort wieder hoch, weil er als “soll laufen” eingetragen war.

Nachgerechnet braucht das Modell für 7 Minuten Ton in float32 höchstens etwa 8 bis 10 GB: 3,6 GB Gewichte, dazu ein linear wachsender KV-Cache und kurzzeitig die Aufmerksamkeit über die ganze Eingabe. Den Rest hat nicht das Modell belegt. Die wahrscheinliche Ursache, aus Code und Dokumentation hergeleitet, aber nicht nachgemessen:

• Bei jedem der bis zu 5040 Ausgabeschritte legt torch für jede der 28 Schichten neue, jeweils etwas größere Tensoren an (Anhängen an den KV-Cache, dazu eine Kopie von K und V auf 16 Köpfe, weil die gruppierte Aufmerksamkeit auf mps erst ab torch 2.13 direkt geht). Die alten Puffer passen für die nächste Anfrage nicht mehr.
• Die Speicherverwaltung von torch auf mps gibt solche Puffer erst zurück, wenn der Prozess mehr als das 1,4-fache der empfohlenen Arbeitsmenge belegt, die harte Grenze liegt beim 1,7-fachen (Umgebungsvariablen für mps). Die empfohlene Arbeitsmenge liegt auf diesem Mac bei 96 GiB. Beide Schwellen liegen damit über dem eingebauten Speicher.
• Dazu übersetzt mps jede neue Tensorform in einen eigenen Graphen und hebt ihn auf. Leeren lässt sich das erst ab torch 2.13; gelaufen ist torch 2.8.

Beides wächst mit Schrittzahl mal Länge, also etwa quadratisch mit der Tonlänge. Vom einen Messpunkt hochgerechnet hätten Abschnitte von 120 s etwa 8 GB zusätzlich zu den Gewichten gebraucht, Abschnitte von 60 s etwa 2 GB. Das ist eine Schätzung, keine Messung. Kürzere Abschnitte hätten den Absturz aller Rechnung nach verhindert.

Geschützt hat nichts. Die Dienstverwaltung maß den Speicher sogar richtig, nutzte den angemeldeten Wert aber nur zur Planung. Eine Grenze, die eingreift, gab es nicht. Die Herkunft des Modells verweist für den Mac übrigens selbst auf mlx-audio, wo MOSS-Transcribe-Diarize über MLX läuft. Eine kurze Recherche vor dem ersten Lauf hätte das gezeigt.

Aufbau der Messung

• Gerät: MacBook Pro mit M4 Max und 128 GB gemeinsamem Speicher, macOS 15. Kein anderes großes Modell geladen; Hintergrundarbeit wie Einbettungen wartet, solange gehört wird.
• Ablauf: Eine eigene Transkriptions-App schickt Höraufträge an eine Leitstelle, die KI-Aufträge verteilt. Jedes Modell läuft als eigener Dienst unter einer Dienstverwaltung am Mac. Neu hören erzeugt je Modell eine eigene Fassung derselben Aufnahme; eine Vergleichsansicht zeigt zwei Fassungen nebeneinander und markiert, wo sie sich uneinig sind.
• Aufnahme 1: deutsche Sprachnachricht von 17:58 min, ein Sprecher, Alltagssprache mit vielen Fachwörtern aus der KI- und Heimnetzwelt. Für die Reihe zur Abschnittslänge zwei Ausschnitte von je rund 4 min (0:31 bis 4:29 und 4:29 bis 8:31), die Grenzen jeweils in einer Sprechpause.
• Aufnahme 2: deutsches Gespräch von 40:37 min mit zwei Personen, für die Sprechertrennung.
• Speicher: physischer Fußabdruck des ganzen Dienstes (phys_footprint, samt Grafikspeicher), nicht der residente Speicher. Abgetastet alle 0,5 s.
• Tempo: Rechenzeit des Hördienstes, als Vielfaches der Echtzeit und als Minuten Rechenzeit je Stunde Ton.
• Qualität: Eine von Hand berichtigte Abschrift gab es nicht. Verglichen wurde darum mit einer Mehrheit: alle Fassungen Wort für Wort ausgerichtet, je Stelle gilt, was die Mehrheit schreibt. Das Ergebnis heißt hier Abweichung, nicht Wortfehlerrate.

Die Modelle:

Die Sprechpausen findet Silero VAD. Für alle Hördienste gelten dieselben Regeln zum Schneiden:

Schnitt         nur in Sprechpausen (Pausen ab 500 ms, 100 ms Polster), nie an fester Zeit;
                gesucht wird die längste Pause im letzten Drittel vor der Obergrenze
Whisper         Fenster bis 28 s; jedes Fenster bekommt einen Stilsatz und die Fachwörter als Hinweis,
                ohne Bezug auf den Text des vorigen Fensters
MOSS            Abschnitte bis 30 s (geprüft bis 240 s); jeder beginnt mit dem letzten Beitrag des vorigen
                als Vorlauf; weitere Sprecher ordnet ein Stimmabdruck (ECAPA) zu
Zusammenfügen   ein Beitrag ohne Satzende wird mit dem folgenden verbunden
                (gleicher Sprecher, Pause bis 2 s, höchstens 40 s)
Speicher        harte Grenze je Dienst, Sprachmodelle höchstens 20 GB

Die ersten Läufe von Whisper in 8 Bit und Turbo liefen neben Tests und dem Start eines Dienstes. Mit 563 s und 177 s waren sie deutlich verfälscht. Die Tabellen nennen die Wiederholungen auf ruhigem Rechner.

Ergebnisse

Spracherkennung: Tempo und Speicher

Aufnahme 1, die ganzen 17:58 min, alle Modelle im selben Ablauf:

MOSS lief in Abschnitten von 30 s, seine Rechenzeit enthält 6 s Laden. “Je Stunde Ton” ist die Rechenzeit für eine Stunde Aufnahme.

8 Bit spart bei Whisper Speicher, aber kaum Zeit. Turbo ist das einzige Modell, das deutlich schneller ist. Alle bleiben weit unter der Grenze von 20 GB.

Spracherkennung: Qualität

Abweichung jeder Fassung, Wort für Wort gegen eine Mehrheit gezählt:

Die Whisper-Mehrheit besteht aus den drei Whisper-Fassungen, die Mehrheit dreier Modelle aus Whisper Large V3 in 16 Bit, Turbo und MOSS. Jedes Modell hat in seiner eigenen Mehrheit einen Heimvorteil; die Zahlen taugen zum Ordnen, nicht als Fehlerrate.

Fachwörter, wie oft richtig geschrieben in der ganzen Aufnahme (Auswahl):

Typische Fehler

Whisper ohne Hinweis. Im alten Ablauf kippte Whisper Large V3 in langen Strecken in Kleinschrift ohne Satzzeichen und blieb dabei, bis zum nächsten Neuansatz. Fachwörter kamen falsch: Qwen als “Qen”, “QN” und “Gwen”, ComfyUI als “CompuUI”, VAE als “VAIs”, Zigbee als “SIGBI”, Ollama als “Lama”, DynDNS als “dünn DNS”. Beiträge endeten mitten im Satz.

16 Bit gegen 8 Bit. 4 von 2782 Wörtern verschieden, alle harmlos: “krieg” gegen “kriege” (zweimal), ein “das” mehr, und einmal “generieren lässt” gegen “generieren hast”.

Turbo verhört sich bei Eigennamen und ganzen Wendungen. Drei Stellen im Vergleich:

Ganz durchgehend schlechter ist Turbo aber nicht: An einzelnen Stellen schrieb es einen Modellnamen richtig, den eine andere Fassung als “Qen” und “QN” verhörte.

MOSS erfindet an schwer verständlichen Stellen Wörter: “Nutella-Maschinen” statt virtuelle Maschinen, “Rahmen” statt RAM. DynDNS und Zigbee erkannte es nie, und der letzte Satz der Aufnahme fehlt. Dafür schreibt es wörtlich, mit Füllwörtern und Wiederholungen. An der Stelle 0:36 schrieb MOSS “also ich glaube, die sollte es drauf laufen”; das könnte sogar richtiger sein als Whisper, nachgehört ist es nicht.

Wörtlich gegen geglättet. MOSS und Turbo schreiben Füllwörter mit, Whisper Large V3 lässt sie weg. Gegen eine Mehrheit, in der Whisper zweimal vorkommt, zählt das als Abweichung. Ein Teil der Abweichung von MOSS ist darum kein Fehler.

Was der Ablauf ausmacht

Der größte Sprung kam nicht von einem anderen Modell. Derselbe Whisper Large V3 im alten Ablauf (ohne Hinweis, ohne Zusammenfügen) gegen den neuen Ablauf, ganze Aufnahme:

Weil 16 und 8 Bit fast wortgleich sind, kommt der Abstand vom Ablauf. Der Hinweis je Fenster (ein Satz zum Stil und die Fachwörter aus einem eigenen Wörterbuch) verhindert das Kippen in Kleinschrift und bringt die Fachwörter. Das Wörterbuch wächst nur auf Vorschlag: Wer im Transkript ein Wort berichtigt, bekommt das Angebot, es aufzunehmen, nie automatisch.

Sprechertrennung

Aufnahme 2, 40:37 min, zwei Personen. Erwartet: genau zwei Sprecher, Wechsel an der richtigen Stelle. Gehört hat Whisper Large V3 in 16 Bit oder MOSS in Abschnitten von 30 s, getrennt hat pyannote speaker-diarization 3.1.

pyannote fand ohne Vorgabe der Zahl genau zwei Sprecher. Von drei nachgesehenen Wechseln waren zwei plausibel, einer lag mitten im Satz vor dem letzten Wort und ist vermutlich falsch.

Die rechte Spalte sollte eigentlich MOSS allein zeigen. MOSS lieferte aber in einem Stück von 0,4 s keine Sprechermarken, und die App verwarf daraufhin still alle Sprecher von MOSS und fragte pyannote. Darum sind die Wechselstellen beider Läufe gleich. Der Fehler ist im Code behoben, die Messung von MOSS allein und einer Mischung (Text von Whisper, Sprecher von MOSS) steht noch aus.

Was über MOSS als Sprechertrenner feststeht: Es braucht kein Whisper, es hört und trennt in einem Durchgang. Die Sprecherkennungen gelten aber nur innerhalb eines Durchgangs (Fehlerbericht 20). Über Abschnitte hinweg trägt sie hier der doppelt gehörte Vorlauf, dann der Stimmabdruck. Äußerungen unter einer Sekunde tragen keinen brauchbaren Stimmabdruck und erben darum den Sprecher ihres Abschnitts (Fehlerbericht 60). Auf Aufnahme 1 mit einem Sprecher fand MOSS ab 30 s je Abschnitt richtig einen Sprecher; mit 15 s erfand es einen zweiten.

Abschnittslänge bei MOSS

Nach dem Umbau auf MLX in bfloat16 und Abschnitte an Sprechpausen: Wie lang sollen die Abschnitte sein? Gestartet wurde mit 15 s, die nächste Länge kam erst, wenn die vorige sauber lief und der Speicher höchstens linear wuchs. Ausschnitt 1 von Aufnahme 1, Rechenzeit nur das Modell:

Die Qualität dazu als Abweichung gegen die Mehrheit der drei Whisper-Fassungen, mit Gegenprobe auf Ausschnitt 2:

Der Speicher bleibt fast flach, von 3,6 auf 4,4 GB bei sechzehnfacher Länge. Der freie Anteil des Systems fiel in keinem Lauf unter 82 %, ausgelagert wurde nichts. Was auf Ausschnitt 1 nach einem Gewinn bei 240 s aussah, kehrt sich auf Ausschnitt 2 um. Ab 30 s wird die Abschrift also nicht messbar besser.

Eine Falle an den Nähten: Im ersten Zusammenführen kamen bei 15 s ganze Sätze doppelt vor. MOSS beginnt den Vorlauf oft mitten im Satz oder zieht ihn mit dem ersten neuen Satz zu einem Beitrag zusammen; ein Schnitt allein nach Zeitmarken reicht dann nicht. Erst ein Textabgleich an der Naht (der wiederholte Anfang fällt weg) brachte die Abweichung bei 15 s von 19,7 auf 16,2 %.

Sprachausgabe und Stimmklon mit Qwen3-TTS

Für die Sprachausgabe laufen zwei Fassungen von Qwen3-TTS als eigene Dienste, beide über MLX. Systematisch gemessen wurden sie noch nicht; die Zahlen stammen aus der laufenden Speicheraufzeichnung (die letzten 30 Arbeitsspitzen je Dienst).

Erfahrungen aus dem Betrieb:

• Angemeldet und Wirklichkeit gingen auseinander. Die Dienste waren mit 3 und 6 GB angemeldet, gebraucht haben sie bis 7,5 und 11,75 GB. Die Anmeldungen stehen jetzt bei 8 und 12 GB, die Grenze für den Stimmklon bei 20 GB.
• 8 Bit für den Stimmklon liegt bereit und würde geschätzt rund 1,7 GB Gewichte sparen. Umgestellt wird nur, wenn ein Blindvergleich keinen hörbaren Unterschied zeigt. Speicher ist kein Grund, Klangähnlichkeit zu opfern.
• Lange Texte gehen in Teilen bis 7500 Zeichen an den Sprechdienst und kommen als Strom zurück. In einer Probe begann das Vorlesen einer Karte nach 4,7 s mit dem ersten Satz; das ist ein Einzelwert.
• Stimmen sind Auswahl, nicht Freitext. Der Sprechdienst bietet neun fertige Stimmen. Geklonte Stimmen echter Personen stehen nur Apps zur Wahl, denen sie einzeln freigegeben sind. Eine feste Vorgabestimme im Code gibt es nicht; leer heißt Vorgabe des Sprechdienstes.

MLX gegen PyTorch auf dem Mac

Fast alle Sprachdienste laufen hier über MLX. Nur pyannote und ECAPA bleiben auf torch: Beide brauchen wenig Speicher, und für pyannote gibt es nur die Segmentierung als MLX-Port, laut Modellkarte mit 88,6 % Übereinstimmung zum Original, also nicht gleichwertig.

Was MLX bringt:

• Speicher, der sich verhält. Die Umsetzung in mlx-audio lässt den Cache in Blöcken wachsen und rechnet die Eingabe in Stücken von 4096 Token; MLX selbst lässt sich im Prozess hart begrenzen. Von den 3,9 GB Spitze entfallen 2,3 bis 2,7 GB auf MLX selbst, der Rest auf den Dienst drumherum.
• Den Weg, den die Herkunft für den Mac vorsieht. Für MOSS-Transcribe-Diarize nennt das Team mlx-audio als Mac-Weg.

Was MLX nicht bringt:

• Genauigkeit. MLX rechnet dieselben Gewichte. MOSS über MLX in bfloat16 liegt beim deutschen Text weiter klar hinter Whisper. Die Unterschiede in der Qualität kommen vom Modell und vom Ablauf.
• Einen belegten Tempogewinn. Am selben Modell gibt es keinen Vergleich: Der Lauf mit torch stürzte ab, bevor er ein Ergebnis hatte.

Die Speicherzahlen der Tabelle trennen außerdem nicht sauber: Zwischen den beiden Läufen änderten sich Laufzeit, Datentyp und Länge je Durchgang auf einmal. Nach der Hochrechnung oben wäre auch torch in kurzen Abschnitten weit unter 100 GB geblieben. Der Gewinn ist die Kombination.

Grenzen und offene Fragen

• Keine von Hand berichtigte Referenz. Die Abweichung ist keine Wortfehlerrate. Strittige Stellen gibt es 13 im ersten Ausschnitt und 67 in der ganzen Aufnahme 1; nachgehört sind sie nicht alle.
• Eine Aufnahme mit einem Sprecher für die Erkennung. Ob 8 Bit auch auf anderen Aufnahmen gleichauf liegt, ist offen; die Vorgabe bleibt darum Whisper Large V3 in 16 Bit.
• Füllwörter. Ob wörtlich oder geglättet richtig ist, hängt vom Zweck ab. Die Mehrheit bevorzugt hier die geglättete Form.
• Sprechertrennung mit MOSS auf einem Gespräch mit mehreren Personen ist noch nicht gemessen, ebenso die Mischung aus Whisper-Text und MOSS-Sprechern.
• Qwen3-TTS ist nur im Betrieb beobachtet, nicht unter festen Bedingungen gemessen.
• Deutsch bei MOSS. Veröffentlichte Messwerte für Deutsch gibt es nicht; laut Team gehört Deutsch zu den Sprachen mit den meisten Trainingsdaten (Fehlerbericht 8).
• Vorlauf. Ein Abschnitt hört samt Vorlauf bis zu 10 s mehr als seine Obergrenze. Für den Speicher spielt das keine Rolle, in der Tabelle steht die Obergrenze.

Erkenntnis

Für deutschen Text ist Whisper Large V3 die sichere Wahl, 8 Bit ist eine ernsthafte Option mit 1,3 GB weniger Speicher, Turbo lohnt sich nur, wenn Tempo wichtiger ist als Namen. MOSS-Transcribe-Diarize ist interessant, weil es Sprecher im selben Durchgang trennt, schreibt Deutsch aber spürbar schlechter. Für Gespräche bleibt bis zur Messung von MOSS allein Whisper mit pyannote der erprobte Weg.

Drei Lehren aus dem Absturz, die für jedes neue Modell gelten:

1. Erst recherchieren, dann kurz messen. Welche Fassung sieht die Herkunft für den Mac vor, welchen Datentyp, wie lang darf ein Durchgang sein? Danach ein Lauf von 15 s unter Aufsicht (hier: 3,1 GB samt Laden), dann stufenweise länger, mit festen Abbruchregeln.
2. Abschnitte an Sprechpausen. Nie an fester Zeit schneiden, sondern in der längsten Pause vor der Obergrenze. Das hält den Speicher flach und die Sätze ganz. Bei MOSS reichen 30 s; länger wird es nicht besser.
3. Eine harte Speichergrenze je Dienst. Eine Wache misst jede Sekunde, beendet einen Dienst über seiner Grenze sofort und sperrt ihn, auch über einen Neustart hinweg; ein abgebrochener Auftrag startet nicht von selbst neu. Sprachmodelle dürfen hier höchstens 20 GB belegen. Dazu die Grenze im Prozess (MLX: mx.set_memory_limit, torch auf mps: PYTORCH_MPS_HIGH_WATERMARK_RATIO und PYTORCH_MPS_LOW_WATERMARK_RATIO). Ein Gegentest mit einem absichtlich wachsenden Testdienst zeigt, ob das greift: Die alte Fassung ließ ihn weiterlaufen, die neue beendete ihn bei 0,7 GB über einer Grenze von 0,5 GB.

Und für Messungen selbst: auf ruhigem Rechner messen, und keine stillen Rückfälle. Ein Ersatzweg, der ohne Meldung einspringt, hat hier den Lauf mit MOSS allein entwertet.

Der größte Gewinn kam nicht vom Modell, sondern vom Ablauf: Fachwörter als Hinweis, Schnitte nur in Sprechpausen und eine harte Speichergrenze je Dienst. Damit wird aus einem Modell, das am Stück über 100 GB belegte, ein Dienst mit 4 GB.