Sprachmemos lokal transkribieren (in Windows oder MacOS)

English translation: 🇬🇧 Transcribing voice memos in 2026 (on Windows & Mac)

Wie man Sprachaufnahmen zuverässig lokal in Text umwandelt – ohne Cloud, ohne Konten, ohne aufwändige Einrichtung.

Empfehlung

Zur Transkription gelegentlicher Sprachmemos unter Windows empfehle ich Buzz – allerdings nur in einem klar begrenzten Arbeitsablauf:

1. Sprachmemo mit Windows Sound Recorder oder einer anderen Aufnahme-App vollständig aufnehmen.
2. Aufnahme beenden.
3. Die fertige Audiodatei per Drag-and-drop in Buzz ziehen.
4. Sprache und Modellauswahl bestätigen.
5. Transkription startet und liegt dann als Textdatei neben der Audiodatei.

Download:

• https://sourceforge.net/projects/buzz-captions/files/

Windows-Nutzer nehmen die “Windows-X64”-Datei:

Gibt’s auch für Mac.

Obacht: Von der in Buzz eingebauten Live-Aufnahme und der automatischen Ordnerüberwachung würde ich derzeit abraten. Beide Funktionen haben konzeptionelle Probleme, die ich auch nur begrenzt für lösbar halte. Details dazu weiter unten.

Buzz ist vielleicht nicht die ultimative Komplettlösung. Als einfache grafische Oberfläche für die lokale Transkription fertiger Audiodateien ist es aber sehr brauchbar – vor allem durch die kinderleichte Bedienung und geringe Anzahl an Setup-Schritten.

Doch nun erstmal zum Grundsätzlichen:

Spracherkennung ist doch nicht neu, oder?

Doch. Spracherkennung ist erst jetzt weitgehend fehlerfrei möglich – die Lösung ist ein Nebenprodukt der allgemeinen LLM-Revolution.

Frühere, deterministische Methoden waren extrem fehleranfällig, vor allem bei Fremdwörtern, Fachbegriffen, unstrukturierter Sprechweise, im Dialekt, und überhaupt. Diese historischen Methoden sind jetzt dank LLMs vollständig obsolet.

Seit der Veröffentlichung von Whisper (2023) ist jetzt alles anders. Spracherkennung ist zuverlässig geworden: Audio rein, Text raus.

Wir wollen unsere Audioaufnahmen allerdings nicht auf fremden Servern verarbeiten – schließlich geht es oftmals um persönliche, vertrauliche oder geschäftliche Inhalte, die nicht ins Internet gehören.

In diesem Artikel geht es deshalb ausschließlich um lokale Transkription:

Die Audiodatei bleibt auf dem eigenen Rechner. Das Spracherkennungsmodell wird einmal heruntergeladen und anschließend lokal ausgeführt.

Grundlage: Whisper

Whisper ist ein von OpenAI veröffentlichtes Modell zur automatischen Spracherkennung. Es erkennt das gesprochene Wort, kann verschiedene Sprachen nahtlos voneinander unterscheiden und beherrscht auch Grammatik und Satzzeichen fehlerfrei. Die Software und die veröffentlichten Modellgewichte stehen unter einer Open-Source-Lizenz und können daher vollständig kostenlos und lokal verwendet werden.

Whisper ist dabei nicht ein einzelnes Programm. Es ist zunächst nur ein Spracherkennungsmodell – quasi eine Library, die von verschiedenen Programmen und integriert und genutzt werden kann.

Das Modell gibt es in unterschiedlichen Ausführungen wie etwa:

• Whisper Tiny, Base, Small, Medium und Large
• Whisper Large-v2 und Large-v3
• Whisper Large-v3-Turbo
• Faster-Whisper
• Distil-Whisper
• Whisper.cpp

Die verschiedenen Modelle unterscheiden sich hinsichtlich Dateigröße, Belastung des Arbeitsspeichers, Rechenzeit, Multilingualität und Fehlertoleranz. Sofern einem die Auswahl angeboten wird, würde ich tendenziell immer “Large” bzw. “Large Turbo” empfehlen.

Bezeichnungen wie Faster-Whisper oder Whisper.cpp stehen dagegen vor allem für unterschiedliche technische Umsetzungen. Whisper.cpp wird etwa für die Beschleunigung auf AMD-Grafikkarten benötigt (via Vulkan), da die “normalen” Modelle nur auf CPU oder NVIDIA-Hardware (via CUDA) funktionieren.

Dazu kommen weitere Modelle von anderen Anbietern, die das von Whisper etablierte Konzept auf ähnliche Weise umsetzen oder weiterentwickelt haben. Dazu zählen:

• NVIDIA Parakeet und Canary
• Qwen3-ASR
• SenseVoice
• Mistral Voxtral
• Microsoft VibeVoice-ASR
• Meta Omnilingual ASR

Diese findet man allerdings eher in Profi-Software oder in Forschung und Entwicklung. Das von mir empfohlene, benutzerfreundliche Buzz bietet “nur” die Whisper-Modelle an – diese scheinen aber auch für den Alltag mehr als zu genügen.

Meine Suchparameter: keep it simple

Gesucht war also eine Anwendung, die folgende Anforderungen erfüllt:

• verständliche Oberfläche für technisch unerfahrene Nutzer,
• vollständig lokale Verarbeitung,
• einfacher Import fertiger Audiodateien,
• verlässliche Ausgabe als normaler Text,
• vernünftige Modellauswahl von klein bis groß,
• Möglichkeit der Nutzung auf reinen CPU-Systemen,
• Beschleunigung über NVIDIA-, AMD- oder Intel-Grafik, soweit vorhanden,
• Fortschrittsanzeigen bei Modell-Downloads und Transkription,
• möglichst wenig zusätzliche Einrichtung.

Gerade die Kombination aus einfacher Bedienung und breiter Modell- und Hardwareunterstützung war zunächst erstaunlich schwer zu finden.

Die eigentliche Spracherkennung ist dabei nicht das Problem. Mit dem richtigen Arbeitsablauf sind die Ergebnisse immer sehr gut – die Zuverlässigkeit auch bei ungenauer, genuschelter oder im Dialekt gesprochener Sprache ist wirklich erstaunlich. Auch ungewöhnliche Markennamen oder die Vermischung von Sprache (etwa Verwendung von Anglizismen im Deutschen) wird souverän erkannt und transkribiert.

Die Probleme drehen sich eher um Einrichtung, Bedienung oder Unklarheiten beim primären Anwendungszweck. Da wir bewusst Open Source-Software nehmen wollen (lokal, kostenlos, kein hidden catch), bewegen wir uns bzgl. der Bedienoberflächen in der Domäne der Hobbyentwickler.

Viele von Whisper abgeleitete Projekte, die man im Netz so findet, fallen in eine dieser Kategorien:

• technisch leistungsfähig, aber nur über die Kommandozeile bedienbar;
• hübsche Oberfläche, aber nur wenige Modelle zur Auswahl;
• umfangreiche Client-/Serverlösungen auf Basis von Docker und WSL (Windows Subsystem for Linux);
• scheinbar kostenlose Anwendungen, die letztlich doch zu einem Cloud-Abo führen soll;
• Echtzeit-Diktierprogramme mit Feature-Wildwuchs und unübersichtlicher Bedienoberfläche.

Meine aktuelle Empfehlung: Buzz

Buzz ist eine quelloffene Desktop-Anwendung, die Audio- und Videodateien lokal transkribiert. Sie unterstützt mehrere Whisper-Backends, TXT-, SRT- und VTT-Ausgabe sowie sowohl NVIDIA-CUDA als auch Vulkan über Whisper.cpp.

Die Oberfläche ist vergleichsweise einfach:

• Datei hineinziehen,
• Sprache auswählen,
• Modell auswählen,
• Transkription starten.

Man muss kein Docker, kein WSL, keinen lokalen Server einrichten. Alles funktioniert sofort nach der Installation. Hier der Einstellungsdialog:

Und ein Demo-Video:

Für mich, der ich lediglich Sprachmemos in Text umwandeln möchte, funktioniert das einwandfrei.

Buzz ist m.E. allerdings nur dann hinreichend zuverlässig, wenn man sich auf die Transkription bereits fertig aufgenommener Dateien beschränkt.

Empfohlener Arbeitsablauf

1. Aufnahme erstellen

Das Sprachmemo zunächst vollständig mit einer separaten Aufnahme-App aufnehmen, zum Beispiel mit Windows Sound Recorder.

2. Fertige Datei importieren

Nach Beendingung der Aufnahme die Audiodatei direkt aus dem Explorer in das Buzz-Fenster ziehen.

3. Sprache festlegen

Die gesprochene Sprache möglichst manuell auswählen, das erhöht vor allem bei kleineren Modellen die Präzision der Transkription. Gelegentliche Fremdworte im Sprachfluss sind dabei kein Problem – die werden korrekt erkannt. Falls gesprochene Sprache in der Aufnahme allerdings durchgehend gemischt werden, dann lieber auf “Detect Language” belassen, also auf Automatik.

4. Modell auswählen

Als Ausgangspunkt würde ich empfehlen:

• Small oder Medium zum Testen, oder wenn die Aufnahme extrem lang und die Präzision weniger wichtig ist;
• Large-v3-Turbo Standard-Empfehlung, insbesondere auf moderat leistungsfähiger Hardware.

Da wir hier keine Echtzeittranskription machen, sondern bereits fertige Aufnahmen für spätere Verwendung transkribieren, kann man das Modell ruhig etwas länger arbeiten lassen und nebenbei etwas anderes machen. Daher würde ich tendenziell immer zu den etwas größeren Modellen raten.

Modelle mit der Endung .en nur für englische Aufnahmen verwenden.

5. Ausgabe prüfen? Kommt drauf an.

Ob man das Transkript noch einmal gegenlesen möchte, kommt auf den Verwendungszweck an:

Will man den Text in irgendeiner Form teilen oder veröffentlichen? Dann genau durchlesen, insbesondere:

• Namen,
• Fachbegriffe,
• Zahlen,
• Abkürzungen,
• fremdsprachige Wörter,
• undeutlich gesprochene Satzenden.

Ist der Text hingegen nur ein Prompt für die nächste LLM-Aktion? Dann ist Präzision weniger wichtig. Das LLM wird Missverständnisse schon selbst aufklären. Fire & forget!

Text oder SRT-Datei?

Für ein gewöhnliches Sprachmemo ist die Ausgabe als Textdatei meist die sinnvollste Wahl. Sie enthält einfach den erkannten Text, ohne Schnörkel oder Metadaten.

Eine SRT-Datei ist dagegen ein Untertitelformat (ähnlich auch: VTT und ASS): Der Text ist in einzelne Abschnitte aufgeteilt und jeder Abschnitt enthält Zeitstempel, die festlegen, wann er in einem Video erscheinen soll. Das ist nützlich, wenn man Filme, Serien, Interviews oder andere audiovisuelle Inhalte untertiteln möchte – dafür würde ich aber wiederrum andere, speziell für Untertitel entwickelte Software empfehlen wie SubtitleEdit.

Denn bei Untertiteln geht es auch sehr um das Timing – welche Sätze gehören zusammen, wie straff sollten die Timings sein um noch möglichst gut lesbar zu bleiben, usw. – das ist ein eigenes Handwerk und eine gewisse Kunst. SubtitleEdit hat dafür unzählige Hilfsfunktionen und verfügt ebenfalls über ein lokal arbeitendes Spracherkennungs-Backend.

Für ein reines Sprachmemo sind Untertitel/Zeitangaben nur unnötiger Ballast. Für meinen Anwendungsfall ist daher die Ausgabe als reine Textdatei (.TXT) der Standard, und dafür genügt Buzz.

Welche Funktionen ich *nicht* empfehle

Nahezu unbrauchbar: Live Recording

Buzz kann direkt über ein Mikrofon aufnehmen und gleichzeitig transkribieren. Damit hatte ich aber in meinen Tests ganz grundsätzliche Probleme:

• Die ersten Wörter können verloren gehen, während das Modell geladen wird.
• Beim Beenden der Aufnahme wird offenbar auch noch nicht verarbeiteter Ton verworfen. Dadurch fehlen am Ende mitunter ganze Sätze.
• Pausen und Hintergrundgeräusche können viel eher Halluzinationen verursachen als bei einer vollständigen Audio-Datei, weil das Modell bei einer Live-Aufnahme viel weniger Kontext hat und quasi ständig im Zugzwang ist.

Praktisch müsste man nach dem letzten gesprochenen Satz schweigend warten, bis die Textausgabe aufgeholt hat, und erst dann auf Stop drücken. Das ist für mich kein sinnvoller Arbeitsablauf. Ähnliche Probleme bestanden auch bei anderen von mir getesteten Programmen mit Live-Funktion.

Ich würde daher “Aufnahme” und “Transkription” immer voneinander trennen. One tool for one job.

Fehleranfällig: Folder Watch

Die Ordnerüberwachung soll Audiodateien automatisch transkribieren, sobald sie in einem bestimmten Verzeichnis erscheinen. Auch diese Funktion würde ich momentan nicht verwenden.

Meine Tests zeigten unter anderem:

• Der Windows Sound Recorder legt seine Datei bereits an, während die Aufnahme noch läuft. Definiert man den entsprechenden Ordner als “Watch Folder”, beginnt Buzz sofort damit, eine unvollständige Aufnahme zu vearbeiten. Andere Aufnahmeprogramme werden evtl. ähnlich agieren.
• Unterordner im Watch-Folder werden rekursiv einbezogen. Definiert man den Speicherort der Transkriptionen als Unterordner des Aufnahmeordners, löst Buzz (welches auch die Audio-Datei in den Ausgabeordner verschiebt) eine wiederholte Verarbeitung und immer tiefer verschachtelte Verzeichnisse aus. In meinen Tests endete dies schließlich in einem Absturz.
• Buzz verwendet keine Hash-Werte, um zwischen Dateien mit identischen Dateinamen zu unterscheiden. Daher ignoriert Buzz neue Aufnahmen im Watch-Folder, wenn sie denselben Dateinamen wie frühere Aufnahmen haben.

Die automatische Ordnerüberwachung klingt komfortabel, benötigt aber dann doch wieder manuelle Schritte, damit man nicht in Probleme läuft. Dann kann man es auch gleich ganz lassen und lieber einfach die Audiodatei selbst in das Buzz-Fenster droppen.

(Ich habe bereits entsprechende Issue-Reports im GitHub von Buzz geöffnet.)

Alternative: TranscriptionSuite

TranscriptionSuite verfolgt einen technisch deutlich aufwändigeren, modulareren Ansatz. Es bindet verschiedene Spracherkennungsmodelle als eigene Docker-Container ein und etabliert somit eine klar getrennte, lokale Server-Client-Struktur.

Für eine einfache interne Standardlösung ist mir der Einstieg momentan jedoch zu aufwendig:

• Docker Desktop und WSL müssen manuell über die PowerShell installiert werden.
• Modelle werden erst beim Serverstart heruntergeladen. Überhaupt kann man Modelle nur verwalten, wenn der Server läuft.

Auch in Bedienung und Funktion gab es Probleme:

• Beim Einfügen einer Datei gibt es keine visuelle Rückmeldung, die anzeigt, dass die Datei erfolgreich hochgeladen wurde. Man muss erst weit nach unten scrollen, um sie in der Batch-Liste zu finden, welche verdächtig weit vom Import-Button entfernt ist.
• Es gibt keine Fortschrittsbalken für Modell-Download und Datei-Verarbeitung.
• Ausgabe als .TXT-Datei funktionierte in meinen Tests nicht – nur Ausgabe als .SRT-Datei, obwohl .TXT explizit ausgewählt wurde.

Die Oberfläche und die zugrundeliegende Architektur von TranscriptionSuite sind sehr ordentlich, aber Benutzerführung und Arbeitsabläufe benötigen noch Feinschliff. Daher bleibt meine Empfehlung auf absehbare Zeit erstmal bei Buzz, welches sich einfacher und konsistenter bedienen lässt.

(Habe hier ebenfalls Issues eingereicht: TranscriptionSuite auf GitHub)

Sprachmemos als Rohmaterial für weitere Arbeit

Eine Transkription ist für mich meistens kein Endprodukt, sondern nur ein Zwischenschritt. Ein Sprachmemo dient mir oftmals als Brain Dump, aus dem später eine Zusammenfassung, ein Protokoll, eine Arbeitsanweisung, ein Artikelentwurf oder ein ausführlicher Prompt entsteht. Ich schreibe bereits relativ schnell, kann aber trotzdem wesentlich schneller sprechen als tippen. Beim freien Sprechen entstehen außerdem oft andere Gedanken als beim Schreiben: Zusammenhänge werden spontaner formuliert, Irrtümer fallen sofort auf, und gerade bei Müdigkeit ist es oft leichter, einen Gedanken auszusprechen, als ihn sauber in Textform zu bringen.

Das ist besonders bei der Arbeit mit LLMs und agentischen Systemen hilfreich. Je genauer eine Aufgabe beschrieben ist und je mehr relevanter Kontext mitgeliefert wird, desto besser das Ergebnis ohne ständige Nachkorrekturen.

Sprachmemos erhöhen gewissermaßen die Bandbreite der Mensch-Maschine-Kommunikation: In derselben Zeit lassen sich mehr Gedanken, Beispiele und Hintergrundinformationen (Bits pro Sekunde) aus dem eigenen Kopf in eine nutzbare Form bringen.

Dasselbe gilt natürlich auch für die Kommunikation mit anderen Menschen: Lieber mal zum Telefon greifen…

Welches LLM anschließend verwendet wird und ob die Weiterverarbeitung lokal oder über einen Cloud-Dienst erfolgt, ist nicht Gegenstand dieses Artikels.

Warum erst Aufnahme, dann Transkription?

Viele LLM-Webdienste und -Programme bieten einen eigenen Mikrofon-Button. Das sind dann keine Live-Transkripte – diese Funktionen warten ebenfalls ab, bis die Aufnahme beendet ist, bevor sie mit der Transkription beginnen.

Trotzdem halte ich es für sinnvoller, Aufnahme und Verarbeitung voneinander zu trennen:

• ein Werkzeug für die Aufnahme,
• ein anderes für die Transkription
• und gegebenenfalls ein drittes für die Weiterverarbeitung.

One tool for each job.

Der wichtigste Grund ist die Zuverlässigkeit. Gerade bei längeren Aufnahmen kann es durchaus vorkommen, dass Webanwendungen abbrechen, Sitzungen auslaufen, Uploads fehlschlagen oder die Verarbeitung ohne brauchbares Ergebnis endet. Das Internet… es ist kompliziert.

Es gibt kaum etwas Ärgerlicheres, als ewig lang ins Mikrofon zu sprechen und anschließend festzustellen, dass nichts passiert. Keine Aufnahme, kein Transkript – nur ein sich ewig drehender Kreisel. Deshalb möchte ich nach jeder Aufnahme zunächst eine normale Audiodatei auf der Festplatte haben. Es gilt das gesprochene Wort (und es liegt als Waveform-Datei lokal ab).

Schlägt später im zweiten Schritt die Transkription fehl (Falsches Modell oder falsche Sprache gewählt? RAM übervoll? Stromausfall?), dann habe ich immer noch meine Originalaufnahme und kann diese einem erneuten Transkriptionsversuch unterziehen.

Auch beim Datenschutz ist die Trennung sinnvoll. Es ist ein Unterschied, ob ein Cloud-Dienst die eigene Stimme als vollständige Audiodatei erhält oder lediglich den bereits lokal erzeugten Text. Ein Transkript mag zwar ebenfalls vertrauliche Inhalte enthalten, aber die Audiodatei enthält zusätzlich Stimme, Sprechweise, und Hintergrundgeräusche, die man vielleicht aus Prinzip nicht in der Cloud haben möchte.

Mein bevorzugter Ablauf lautet daher: lokal aufnehmen, lokal transkribieren und erst danach bewusst entscheiden, ob und wo der Text weiterverarbeitet werden soll.

Die Trennung zwischen Aufnahme und Transkription ermöglicht es mir auch, Audioaufnahmen bequem per Headset ins Handy zu sprechen, dabei ggf. durch die Gegend zu laufen (Körper und Geist in Bewegung halten), und die Datei dann vom Handy auf den Computer zu schieben und dort weiterzuarbeiten.

Jedes Android- und iPhone-Handy hat eine vorinstallierte, lokale Audio-Aufnahme-App. Transfer der Audio-Datei (MP3 oder M4A) zum Computer läuft dann bequem über LocalSend, ebenfalls Open Source (Windows, Linux, Mac, iOS, Android).

Sprechererkennung für Interviews und Meetings

Bei Interviews oder Meetings reicht eine einfache Transkription nicht aus: Das Programm muss zusätzlich erkennen, wer zu welchem Zeitpunkt gesprochen hat, damit einzelne Aussagen nicht aus dem Zusammenhang geraten.

Dieser Vorgang wird als “Speaker diarisation” bezeichnet. Das Ergebnis enthält dann Bezeichnungen wie „Sprecher 1“ und „Sprecher 2“.

Buzz unterstützt diese Sprechertrennung – sie ist allerdings etwas versteckt. Zunächst muss die normale Transkription vollständig abgeschlossen sein. Danach öffnet man das fertige Transkript in der Übersicht per Doppelklick und wählt im Transkriptfenster die Funktion “Identify speakers”.

Die Sprechererkennung läuft dann als zusätzlicher Verarbeitungsschritt und benötigt entsprechend noch einmal Zeit und Rechenleistung. Die Funktion erkennt Sprechabschnitte, gruppiert Stimmen anhand ihrer Merkmale und führt diese Informationen anschließend mit den Zeitstempeln des Transkripts zusammen.

Die Bedienoberfläche von Buzz bietet aktuell noch nicht an, diesen Prozess schon beim ersten Import der Aufnahmedatei mit in Auftrag zu geben.

Technisch basiert diese Funktion auf dem etablierten Open-Source-Projekt Whisper-Diarization, welches wiederum NVIDIA NeMo zur Sprechererkennung verwendet. Diese Pipeline gilt als solide, kann aber bei unstrukturierten Aufnahmen (wenn mehrere Sprecher übereinander sprechen bzw. sich ins Wort fallen) stellenweise durcheinanderkommen. Zitat auf Github-Seite:

Overlapping speakers are yet to be addressed, a possible approach would be to separate the audio file and isolate only one speaker, then feed it into the pipeline but this will need much more computation

Trotz des Namens (NVIDIA NeMo) lässt sich die Funktion auch vollständig auf der CPU ausführen, wenn keine NVIDIA-Grafikkarte vorhanden ist. Weitere Infos zum Thema Hardwarebeschleunigung im nächsten Abschnitt.

Die oben erwähnte, großzügiger ausgestattete Lösung “TranscriptionSuite” setzt für die Sprecher-Erkennung auf eine andere Pipeline namens “PyAnnote Community-1“. Diese neuere Pipeline wurde speziell für schwierige Aufnahmen mit mehreren Sprechern weiterentwickelt und dürfte bei komplexeren Meetings die Zuordnung der Sprecher verbessern. Zur Einrichtung dieser Pipeline in TranscriptionSuite benötigt man ein kostenloses HuggingFace-Konto. Nach der Registrierung erzeugt man dort einen persönlichen Zugriffstoken und hinterlegt ihn einmalig in TranscriptionSuite. Dabei stimmt man gleichzeitig den Nutzungsbedingungen des Community-Projekts zu. Erst danach kann das entsprechende Modell innerhalb von TranscriptionSuite heruntergeladen werden. Die Verarbeitung selbst erfolgt danach weiterhin vollständig lokal.

Ob man die zusätzliche Präzision von “PyAnnote Community-1” in TranscriptionSuite braucht, hängt vom Zweck ab. Soll ein Interview mitsamt Sprecherzuordnung veröffentlicht, archiviert oder als verlässliches Wortprotokoll verwendet werden, möchte man möglichst hohe Präzision und sollte das Ergebnis sorgfältig kontrollieren. Soll dagegen ein LLM aus einer internen Besprechung lediglich eine Zusammenfassung, Aufgabenliste oder ein grobes Protokoll erstellen, sind einzelne falsch zugeordnete Sätze oft weniger entscheidend – solange der Inhalt insgesamt erhalten bleibt. Eine daraus erzeugte Zusammenfassung wird man in der Regel ohnehin noch einmal gegenlesen und gegebenenfalls ergänzen.

Grafikkarte für Spracherkennung? Nice to have, muss aber nicht sein.

Moderne Spracherkennung besteht (wie alle LLM-Anwendungen) aus sehr vielen einfachen Rechenoperationen, die gleichzeitig ausgeführt werden können. Genau dafür sind Grafikkarten gebaut: Ursprünglich sollten sie Millionen Bildpunkte parallel berechnen, heute eignen sie sich deshalb auch hervorragend für Large Language Models, vulgär “KI” genannt.

Die Grafikkarte “versteht” dabei weder Sprache noch Ton. Sie beschleunigt lediglich die Mathematik hinter dem Modell. Ein Prozessor kann dieselbe Aufgabe ebenfalls erledigen, arbeitet dabei aber deutlich langsamer, weil er stärker auf wenige komplexe Aufgaben statt auf sehr viele parallele Berechnungen ausgelegt ist. Die Zuverlässigkeit ist aber diesselbe – nur die Ausführungszeit unterscheidet sich.

Besonders verbreitet ist die Beschleunigung über NVIDIA CUDA. Daneben existieren auch Vulkan, DirectML, ROCm und OpenVINO um auch AMD- oder Intel-Grafik einzubeziehen. Was davon tatsächlich funktioniert, hängt immer von der jeweiligen Software, dem verwendeten Modell und dessen technischem Backend ab. Allgemein gilt aber: CPU geht immer, und Beschleunigung über NVIDIA geht ebenfalls auch fast immer, und zwar out-of-the-box.

Wer also eine NVIDIA-Karte im System hat, sollte bei der Transkription mal in den Task Manager gucken, ob die Grafikkarte während der Transkription ausgelastet wird. Screenshot:

Bei mir werden hier während einer Transkription ganze acht von 16 CPU-Threads voll ausgelastet (offenbar unterstützt das Modell kein Hyperthreading bzw. SMT). Eine NVIDIA-GPU ist aktuell nicht verbaut. Wäre sie verbaut, würde man sie hier in der Liste finden und ihre Auslastung beobachten können.

E-Mails und Chatnachrichten direkt mit der Stimme beantworten?

Anhand der hohen Zuverlässigkeit von moderner Spracherkennung könnte man sich fragen, ob man zur Beantwortung von E-Mails oder Chatnachrichten überhaupt noch zur Tastatur greifen muss.

Da sehe ich aber zwei grundsätzliche Probleme:

Bei einer Echtzeit-Transkription soll der Text möglichst zeitgleich zur gesprochenen Sprache auf dem Bildschirm erscheinen. Die Software muss deshalb bereits mit der Verarbeitung beginnen, obwohl der Satz noch gar nicht vollständig gesprochen wurde. Dadurch steht weniger sprachlicher Kontext zur Verfügung als bei der nachträglichen Verarbeitung einer fertigen Aufnahme, was die Fehleranfälligkeit erhöhen kann. Im Grunde müsste man also auf die Echtzeitausgabe vollständig verzichten – sie lenkt nur ab und reduziert die Qualität der Transkription.

Hinzu kommt, dass gesprochene Sprache anders funktioniert als geschriebene. Beim freien Sprechen entstehen Denkpausen, Wiederholungen, abgebrochene Satzanfänge, Verzögerungslaute wie „ähm“, nachträgliche Korrekturen und gedankliche Umwege. Ein möglichst wortgetreues Transkript bildet all das zunächst nur ab. Damit daraus eine Nachricht entsteht, die wie eine bewusst formulierte persönliche Antwort klingt, muss der Text anschließend geglättet, gekürzt und teilweise neu strukturiert werden. Macht man das dann alles manuell, spart man keine Zeit – dann hätte man den Satz auch einfach gleich selbst schreiben können.

Buzz und ähnliche Programme mit “Live”-Funktion (etwa das kostenpflichtige SpeechPulse) können dafür ein zusätzliches LLM zur Nachbearbeitung einbinden. Solch ein “General Purpose”-LLM unterscheidet sich hinsichtlich seiner Trainingsdaten massiv von einem Transkriptionsmodell wie “Whisper”. Um es mal stark zu vereinfachen: Transkriptionsmodellen hören einfach nur zu, “General Purpose”-LLMs hingegen “denken mit” und setzen Inhalte mit Arbeitsaufträgen, vorhandenen Tools und mit dem über das Training vermittelten Allgemeinwissen in Zusammenhang. Solche LLMs sind entsprechend auch deutlich größer und brauchen mehr Rechenleistung und Arbeitsspeicher. Der Komplexität sind da keine Grenzen gesetzt.

Wenn man also Mails und Chatnachrichten “hands free” beantworten möchte, ohne sich beim Sprechen stark einzuschränken oder auf “geschriebene Sprechweise” konzentrieren zu müssen, braucht man diesen zusätzlichen, redaktionellen Arbeitsschritt: das LLM entscheidet, welche Wiederholungen entfernt, welche Sätze verbunden und welche Formulierungen geschliffen werden. Das kann funktionieren, birgt aber auch das Risiko, dass Nuancen in der Aussage und die Wahrung des persönlichen Stils darunter leiden.

Somit braucht das LLM eigentlich noch mehr Kontext: worum geht es in der Mail? Wie ist die Stimmungslage? Welche grammatikalischen und typographischen Gewohnheiten sollen angewendet werden? Möchte man in der Lage sein, den Output noch einmal mit einer zweiten Sprachnachricht zu ergänzen – erneut ohne Hand an die Tastatur anzulegen? Die benötigte Komplexität und Integration wird dann schnell zu einem Fass ohne Boden.

Das ist aber durchaus ein spannendes und lösbares Thema, aber es sprengt ein wenig den Rahmen dieses Artikels. Man wird dafür auch stärkere Hardware brauchen (mit dedizierter Grafikkarte), damit das alles einigermaßen verzögerungsfrei abläuft. Ich werde mich diesem Thema zu einem späteren Zeitpunkt einmal widmen.

Abschließende Worte

Buzz ist meine Empfehlung, wenn man sich auf den elementarsten, zuverlässigsten Anwendungsfall konzentriert:

Sprachmemo extern aufnehmen, Aufnahme beenden, fertige Datei per Drag-and-drop in Buzz ziehen und lokal als Text transkribieren.

In diesem Rahmen ist Buzz einfach, nachvollziehbar und auch auf einfachen Rechnern ohne Hardwarebeschleunigung gut nutzbar. Die Live-Aufnahme und Ordnerüberwachung würde ich hingegen links liegen lassen – zu fehleranfällig.

Technisch umfangreichere Lösungen bieten mehr Modelle und Funktionen, verlangen dafür aber auch mehr Einrichtungszeit und Vorwissen.

Ich werde diesen Artikel nach Möglichkeit aktualisieren, sobald es substanzielle Updates in meinem eigenen Workflow gibt

Letztes Update: Juli 2026