Die kürzeste Antwort lautet: Offline-Diktat fühlt sich meist schneller an, weil zwischen „Ich habe aufgehört zu sprechen“ und „Der Text ist da“ weniger Schritte liegen. Cloud-Diktat kann trotzdem die richtige Wahl sein, zahlt aber einen Netzwerk- und Upload-Preis, den lokale Workflows nicht zahlen.
TL;DR
- Beim On-Device-Diktat fällt der Weg über Upload und Verarbeitung auf einem fremden Server weg.
- Cloud-Tools können weiterhin hervorragend sein, wenn du gemeinsame Historie, serverseitige Automatisierung oder aggressive Umschreib-Workflows willst.
- Apples aktuelle Mac-Anleitungen machen deutlich, dass das Verhalten der Diktierfunktion von der Einrichtung abhängt; in den Tastatureinstellungen siehst du, ob allgemeines Text-Diktat auf dem Gerät verarbeitet oder an Siri-Server gesendet wird.
- Auch die Sprachsteuerung funktioniert nach einem einmaligen Download offline.
- Beim täglichen Diktieren auf dem Mac geht es nicht nur um Genauigkeit, sondern um Workflow-Latenz: wie lange du nach jeder Äußerung wartest, den ganzen Tag lang.
- Die Genauigkeit hängt ebenso von der Aufbereitung des Eingangssignals und von deinen Sprechgewohnheiten ab wie von der Modellgröße.
Die Latenzfrage, auf die es wirklich ankommt
Modellqualität und Featurelisten sind die falsche Achse für ein Tool, das du zweihundertmal am Tag auslöst. Die Frage, die vorhersagt, wie sich das Tool anfühlt, ist enger gefasst:
Wie viele Schritte passieren, nachdem ich aufgehört habe zu sprechen?
Woher die Verzögerung kommt
Dieser Abschnitt beschreibt den Mechanismus, keine Messung. Es geht darum, die Schritte zu benennen, damit du weißt, was du auf deinem eigenen Rechner messen solltest, statt welcher Zahl von einer Marketingseite du trauen sollst.
Bei einem On-Device-Workflow sieht der Weg meist so aus:
- Audio lokal aufnehmen,
- Audio-Chunks lokal verarbeiten oder streamen,
- das unfertige Ende abschließen,
- Text einfügen.
Cloud-Diktat fügt dem einen Netzwerkpfad hinzu:
- Audio lokal aufnehmen,
- eine Verbindung öffnen (DNS-Auflösung, TLS-Handshake, manchmal Authentifizierung),
- das Audio hochladen,
- auf die Inferenz auf dem Server warten,
- das Ergebnis herunterladen,
- den Text manchmal durch eine weitere Umschreib- oder Formatierungsebene schicken.
Zwei Eigenschaften dieser zweiten Liste sind wissenswert, weil sie sich unterschiedlich verhalten.
Der Verbindungsaufbau ist pro Anfrage ungefähr konstant. DNS, TLS und Authentifizierung kosten etwa gleich viel, egal ob du zwei Wörter oder zwei Minuten diktiert hast. Bei einer langen Aufnahme verteilen sich diese Kosten, bei einer Fünf-Sekunden-Notiz überhaupt nicht. Je kürzer deine typische Äußerung, desto größer ist also der Anteil der Wartezeit, der nichts mit Spracherkennung zu tun hat. Dauerhafte Verbindungen und Streaming-Protokolle verringern das, weshalb Implementierungsdetails wichtiger sind als das Etikett „Cloud versus lokal“.
Die Übertragungszeit wächst mit der Audiolänge. Die Erkennungsqualität profitiert in der Regel von leicht komprimiertem oder unkomprimiertem Audio, daher ist die Datenmenge einer langen Session nicht klein. Bei einer stabilen Verbindung merkt man das nicht. Im Hotel- oder Café-WLAN ist es die Variable, die sich bewegt.
Lokal heißt nicht sofortige Magie. Auch nach dem Sprechen wird noch gearbeitet. Aber du sparst dir die gesamte Schleife aus Hochladen und Zurückholen und damit den Teil der Verzögerung, der von einem Netzwerk abhängt, das du nicht kontrollierst.
Wie das aussieht, kannst du in der interaktiven Demo selbst sehen, in der du Äußerungslänge und Netzwerkbedingungen variieren kannst: /blog/latency-demo.
Windowing: warum lange Sessions nicht langsamer werden müssen
Eine naive lokale Implementierung wartet, bis du aufhörst, und transkribiert dann die gesamte Aufnahme. Das hat dasselbe Skalierungsproblem wie ein Upload: Eine halbe Stunde Audio bleibt eine halbe Stunde Audio.
Streaming-Implementierungen umgehen das, indem sie schon während des Sprechens in begrenzten Batches dekodieren. Wenn du aufhörst, muss nur noch der letzte unvollständige Batch abgeschlossen werden.
Voice Type arbeitet so, mit einem Batch-Ziel von 29 Sekunden, begrenzt auf einen Bereich von 15 bis 29. Die Batches sind keine Fenster fester Länge: Der Batcher sammelt ganze Sprachbereiche und schneidet an einer Grenze keinen davon in der Mitte durch, sodass eine ankommende Phrase, die das Ziel überschreiten würde, stattdessen den nächsten Batch beginnt. Praktisch heißt das: Die Wartezeit nach dem Aufhören wird durch das Batch-Ziel begrenzt und nicht durch die Länge der Session. Ein zweiminütiges und ein dreißigminütiges Diktat enden mit der gleichen Menge an verbleibender Arbeit.
Das ist eine Eigenschaft der Architektur, kein Benchmark. Wie lange dieser letzte Durchgang tatsächlich dauert, hängt von deinem Mac ab, und es lohnt sich, das auf deinem Gerät zu messen.
Cloud-Diktat: mehr bewegliche Teile, aber manchmal der richtige Kompromiss
Jeder zusätzliche Schritt im Cloud-Pfad kann sich lohnen, wenn das Produkt etwas Wertvolles leistet:
- Team-Historie,
- kontoweite Synchronisierung,
- serverseitige Prompt- oder Vorlagen-Pipelines,
- Meeting- oder Dateiverarbeitung in größerem Maßstab,
- Nachbearbeitung, die grobe gesprochene Eingaben verbessert.
Es geht nicht darum, dass „Cloud schlecht“ ist. Es geht darum, dass die Cloud mehr Stellen hat, die zum Engpass werden können.
Wo Apple einzuordnen ist
Apples eigener Stack steht inzwischen mitten in dieser Diskussion.
Die aktuellen Support-Seiten machen zwei Dinge deutlich:
- allgemeines Text-Diktat kann je nach Einrichtung auf dem Gerät verarbeitet oder an Siri-Server gesendet werden,
- die Sprachsteuerung erfordert einen einmaligen Download und kann danach ohne Internet genutzt werden.
„Mac-Diktat“ ist also keine feste Architektur. Es hängt ab von:
- deiner Hardware,
- deiner Sprache und Region,
- der Funktion, die du nutzt,
- davon, ob du die Diktierfunktion oder die Sprachsteuerung verwendest.
Das ist ein Grund, warum allgemeine Vergleichsartikel schlecht altern: Sie sprechen von „Mac-Diktat“, als wäre es ein einziges, statisches Produkt.
Warum Vielnutzer den Unterschied stärker bemerken als Gelegenheitsnutzer
Wenn du einmal pro Woche einen Absatz diktierst, spielt der Unterschied zwischen lokal und Cloud vielleicht keine große Rolle.
Wenn du dutzende oder hunderte Male am Tag diktierst, summieren sich kleine Verzögerungen:
- Warten auf die Verbindung,
- Warten, bis der Upload abgeschlossen ist,
- Warten auf eine Antwort,
- Warten auf einen zweiten Durchgang, der den Text „poliert“.
Hier gewinnen On-Device-Workflows an Boden. Die absolute Verzögerung ist nicht immer dramatisch. Die Wiederholung macht sie teuer. Verlässlichkeit zählt mehr als der Bestfall: Ein Workflow, der auch bei schlechtem WLAN berechenbar ist, schlägt einen, der bei gutem WLAN schneller und bei schlechtem unbrauchbar ist.
Genauigkeit ist nicht nur ein Modellproblem
Die Modellgröße ist die Zahl, mit der jede Produktseite beginnt, und sie ist nur ein Faktor unter mehreren. In der Praxis wird die Genauigkeit bestimmt von:
- Mikrofonqualität,
- Raumgeräuschen,
- Echo,
- Eingangspegel,
- Sprachsegmentierung,
- Abweichungen im Vokabular,
- und davon, ob der Workflow dich weitermachen lässt, ohne die Konzentration zu brechen.
Deshalb sagt die Aussage „Wir nutzen das größte Modell“ nicht, wie sich die App in Slack, Gmail oder Linear tatsächlich anfühlt.
Das Eingangssignal vor der Erkennung aufbereiten
Sprachmodelle werden mit Audio trainiert, das bestimmte Eigenschaften hat. Je näher dein Eingangssignal an dieser Verteilung liegt, desto weniger muss das Modell raten. Drei Anpassungen leisten das meiste:
- Lautheit normalisieren auf ein einheitliches Ziel, damit Wörter auf ähnlichem Pegel ankommen, ob du dich vorgebeugt oder zurückgelehnt hast.
- Tieffrequentes Dröhnen filtern mit einem leichten Hochpass. Tischklopfen, Klimaanlage und Gebäudegeräusche enthalten Energie, die keine Sprache ist.
- Rauschbewusste Sprachaktivitätserkennung (VAD) nutzen, damit Stille und Hintergrund nicht wie Wörter an den Erkenner gehen.
Voice Type wendet alle drei vor der Erkennung an. Die ausgelieferten Standardwerte für Live-Diktat sind ein Lautheitsziel von minus 16 LUFS und ein Hochpass bei 50 Hz, beide in den Audioeinstellungen der App sichtbar und anpassbar. Der Gedanke dahinter: Das Signal zu verbessern ist ehrlicher, als die Ausgabe zu flicken, denn aufwendige prompt-basierte „Korrekturen“ können ein Transkript selbstsicher wirken lassen, während es sich von dem entfernt, was gesagt wurde.
Weiterführend zu den einzelnen Bausteinen: Sprachaktivitätserkennung und Resampling auf 16 kHz.
Zwei Stufen, in dieser Reihenfolge. Das Lautheitsziel ist nicht eine einzelne Zahl, sondern hängt davon ab, welchen Pfad das Audio genommen hat. Quellen: WhisperState+FileTranscription.swift, WhisperState.swift.
Zeichensetzung und Satzgrenzen
Zeichensetzung bemerkt man nur, wenn sie schiefgeht. Ein fehlender Punkt. Ein doppeltes Leerzeichen. Ein Eigenname, der einen Satz zerreißt.
Das meiste läuft auf die Segmentierung hinaus, weshalb die Aufbereitung des Eingangssignals und deine Sprechgewohnheiten sie direkt beeinflussen. Lautstärkeschwankungen können wie Satzgrenzen gelesen werden. Raumgeräusche verwischen die Pausen, an denen das Modell einen Satz abschließt.
Gewohnheiten, die mit jedem Mikrofon helfen:
- Am Satzende einen Moment länger pausieren. Eine halbe Taktlänge reicht, um ein sauberes Grenzsignal zu geben.
- Zeichen in Aufzählungen aussprechen, wenn es genau sein muss. Bei engen Listen oder Code nimmt das laute Sagen von „comma“ das Raten weg.
- Den Pegel gleichmäßig halten. Sprich lieber näher am Mikrofon als lauter; ein sauberes Signal schlägt ein heißes.
- Eigene Wörter hinzufügen. Produktnamen und Fachbegriffe, die in einem allgemeinen Wörterbuch fehlen, werden nach der Registrierung zu Ankern, was Korrekturen in langen Notizen reduziert.
- Die Rauschunterdrückung sanft halten, falls dein Tool sie anbietet. Aggressives Gating schneidet Konsonanten ab, und abgeschnittene Konsonanten kosten dich mehr als das Rauschen.
Ein schneller Weg, jede Diktier-Einrichtung auf deinem eigenen Rechner zu testen: Lies diese Zeile in ein leeres Dokument, ohne das Wort „period“ zu sagen.
Aeloria and Kyran left Eldmere at dawn. They crossed the Kintara ridge before the fog rolled in. Skystack Nova ships next week.
Sie mischt erfundene Eigennamen mit gewöhnlichem Satzbau, sodass du in einem Durchgang siehst, wie ein Tool mit unbekanntem Vokabular und mit Satzgrenzen umgeht. Führe sie einmal in normalem Abstand und einmal mit dem Mikrofon näher dran durch und vergleiche.
Datenschutz ist ein struktureller Unterschied, kein Feature
Beim On-Device-Diktat verlässt das Audio den Rechner nicht, es gibt also keine Aufbewahrungsrichtlinie zu lesen und keinen Anbieter, dem du die Aufnahme anvertrauen musst. Beim Cloud-Diktat verlässt das Audio den Rechner von vornherein, und die Datenschutzfrage wird zu einer Frage danach, wie ein bestimmter Anbieter damit umgeht.
Voice Type hält das Diktat lokal. Die optionale LLM-Umschreibung ist die Ausnahme, und sie ist Opt-in: Der Text geht direkt von deinem Mac an den Anbieter, dessen Schlüssel du angegeben hast, nicht über unsere Server. Details findest du im Trust Center und in der Datenschutzerklärung.
Wo Voice Type einzuordnen ist
Voice Type ist auf den Fall der wiederholten Nutzung ausgelegt: Hotkey halten, sprechen, loslassen, den Text lokal zurückbekommen, mit dem oben beschriebenen Rolling-Window-Verhalten.
Das ist eine andere Aufgabe als bei Tools, die sich konzentrieren auf:
- Dateitranskription,
- Meeting-Aufzeichnung,
- Umschreiben in der Cloud,
- oder gemeinsame serverseitige Historie.
Wenn du lieber Kategorien statt Slogans vergleichen willst, sind diese Seiten nützlicher:
Wann die Cloud trotzdem gewinnt
Die Cloud passt weiterhin besser, wenn du Folgendes brauchst:
- gemeinsame Transkripte im ganzen Team,
- serverseitige Speicherung und Suche,
- automatische Nachbearbeitung langer diktierter Entwürfe,
- Workflows, die auf Zentralisierung statt auf Datenschutz setzen,
- verwaltete Infrastruktur statt lokaler Rechenleistung.
Die ehrliche Schlussfolgerung lautet nicht „lokal schlägt Cloud“. Sie lautet:
Lokal gewinnt, wenn dein Engpass die Interaktionsgeschwindigkeit ist. Die Cloud gewinnt, wenn dein Engpass Zusammenarbeit, serverseitige Verarbeitung oder ein zentralisierter Workflow ist.
Was solltest du wählen?
Nutze diese Faustregel:
| Wenn dir am wichtigsten ist … | Besser geeignet | | --- | --- | | Schnelles, wiederholtes Diktieren in Mac-Apps | On-Device | | Lokales Datenschutzmodell | On-Device | | Gemeinsame Historie und serverseitige Automatisierung | Cloud | | Datei-Uploads und Transkriptverwaltung | Cloud oder Tools für Dateitranskription | | Sprachsteuerung im Sinne der Bedienungshilfen | Apple Sprachsteuerung |
Praktische nächste Schritte
Wenn du dich noch entscheidest, mach Folgendes:
- Nutze die Apple-Diktierfunktion ein paar Tage mit deinem echten Mikrofon und deinen echten Apps.
- Achte auf die Verzögerung nach kurzen Äußerungen, nicht nur nach langen Aufnahmen.
- Wiederhole denselben Test in einem unzuverlässigen Netzwerk, denn dort trennen sich die beiden Architekturen.
- Wenn das eingebaute Tool reicht, behalte es.
- Wenn du ständig über den Workflow nachdenkst statt über das Schreiben, probiere eine spezialisierte lokale App.
Hier geht es zum lokalen Mac-Weg:
Quellen
- Apple Support: Dictate messages and documents on Mac
- Apple Support: If Dictation on Mac doesn’t work as expected
- Apple Support: Get started with Voice Control on Mac
- OpenAI research: Whisper overview
- Paper: Robust Speech Recognition via Large-Scale Weak Supervision