Transcribe.cpp: Plattformübergreifende lokale Spracherkennungsbibliothek

• transcribe.cpp ist eine auf ggml basierende Bibliothek, die entwickelt wurde, um mehrere moderne Spracherkennungsmodelle einfach in Mac-, Windows- und Linux-Apps einzubetten und per GPU zu beschleunigen
• 16 ASR-Familien und mehr als 60 Modelle laufen auf Vulkan, Metal, CUDA und TinyBLAS; sowohl Streaming- als auch Batch-Transkription werden unterstützt
• Alle Modelle wurden numerisch mit den Referenzimplementierungen verglichen und mit Tausenden von Äußerungen per WER-Tests geprüft; die Validierungsergebnisse sind im Repository und auf Hugging Face veröffentlicht
• Bestehende .bin-Dateien für whisper.cpp können ausgeführt werden und lassen sich für die meisten Einsatzzwecke bei ähnlicher Leistung ersetzen; außerdem gibt es offizielle Bindings für Python, JavaScript/TypeScript, Rust und ObjC/Swift
• Selbst auf einem stromsparenden RK3566 kann schneller als in Echtzeit transkribiert werden, sodass sich lokales ASR auf verschiedensten Geräten bereitstellen lässt, ohne Sprache in die Cloud zu senden

---

Einschränkungen bei plattformübergreifender ASR-Bereitstellung

• Die bestehenden Optionen für plattformübergreifende ASR-Inferenz waren faktisch auf whisper.cpp und ONNX beschränkt
  • Für Apple-Geräte ließe sich MLX ergänzen, doch dann müssten zwei Engines unterstützt und Modelle für jede Engine portiert werden
  • ONNX war nützlich, um Modelle schnell zu Handy hinzuzufügen, aber bei rein CPU-basierter Ausführung ließ sich die Leistung nur schwer voll ausschöpfen
• Bei einigen Bibliotheken mit Unterstützung für mehrere Modelle waren Autorenschaft, Testniveau und Wartungspläne unklar
  • Es war schwer zu erkennen, ob es Bindings für echte Desktop- und Mobile-Apps gibt, ob sie über Demo-Code hinausgehen, Benchmarks vorhanden sind oder sie schneller als ONNX sind
• Auf Basis der Erfahrung mit der plattformübergreifenden Bereitstellung von Spracheingabe in Handy wurde eine Engine benötigt, die folgende Bedingungen erfüllt
  • Dateien müssen heruntergeladen und sofort für Inferenz nutzbar sein
  • Die Inferenzqualität muss sich als gleichwertig zur Referenzimplementierung validieren lassen
  • Für maximale Leistung muss die Ausführung auf der GPU erfolgen
  • Sie muss sich ohne große PyTorch-Bibliotheken leicht in Handy einbetten lassen
  • Sie muss auf Mac, Windows und Linux laufen
• ggml wurde wegen seiner starken Community und des praktischen Deployment-Modells als Grundlage gewählt, um diese Anforderungen umzusetzen

Unterstützte Modelle und Beschleunigung

• transcribe.cpp zielt auf schnelle, präzise Inferenz und breite Modellunterstützung
  • 16 ASR-Familien und mehr als 60 Modelle werden unterstützt; weitere Modelle sollen folgen
  • Die meisten aktuellen öffentlich verfügbaren Transkriptionsmodelle werden unterstützt, einige fehlen jedoch noch
  • Sowohl Streaming-Transkription als auch Batch-Transkription werden angeboten
• Alle unterstützten Modelle können mit den folgenden Beschleunigungs-Backends ausgeführt werden
  • Vulkan
  • Metal
  • CUDA
  • TinyBLAS
• Modellspezifische Benchmarks wurden unter Fedora mit Ryzen-4750U-CPU und Vulkan sowie auf einem M4 Max durchgeführt
• Vulkan-Support gilt als Mindestvoraussetzung für die Bereitstellung lokaler Inferenzanwendungen

Referenzimplementierung und Genauigkeitsvalidierung

• Ausgehend von der Erfahrung, dass sich die Inferenzgenauigkeit von auf Hugging Face bezogenen .onnx-Modellen nur schwer sicher beurteilen ließ, wurden alle Modelle numerisch gegen die Referenzimplementierung validiert
• Zusätzlich zu numerischen Vergleichen wurden vollständige WER-Prüfungen durchgeführt, um zu bestätigen, dass dieselben Ausgaben wie bei der Referenzimplementierung entstehen
  • Pro Modell wurden Tausende von Äußerungen verarbeitet
  • Die Ergebnisse sind der Referenzimplementierung sehr ähnlich oder identisch
• Die Validierungsdaten sind im transcribe.cpp-Repository sowie auf den einzelnen Modellseiten der Hugging Face-Organisation handy-computer veröffentlicht

whisper.cpp-Kompatibilität

• Damit sich whisper.cpp, das in Handy verwendet wurde, ersetzen lässt, wurde eine nahezu Drop-in-kompatible Ersetzung umgesetzt
• Die mit Handy ausgelieferten .bin-Modelldateien für whisper.cpp lassen sich auch in transcribe.cpp ausführen
• Einige Flags und Funktionen von whisper.cpp werden noch nicht unterstützt
• Für die meisten Einsatzzwecke ist die whisper-Implementierung ausreichend stabil und kann whisper.cpp bei ungefähr ähnlicher Leistung ersetzen

Sprach-Bindings und Wartung

• Die Bibliothek ist in C/C++ geschrieben und bietet offiziell gepflegte Bindings, um lokale Transkription in verschiedene Umgebungen zu bringen
  • Python
  • JavaScript/TypeScript
  • Rust
  • ObjC/Swift
• Beiträge für weitere Sprach-Bindings sind willkommen, allerdings müssen Beitragende die Wartung des jeweiligen Bindings übernehmen
• Die tatsächlichen Anforderungen von Handy sind in das Bibliotheksdesign eingeflossen, und auf Basis der Wartungserfahrung mit Handy soll auch transcribe.cpp weiter gepflegt werden
• Erfahrungen aus der Unterstützung verschiedener ASR-Modelle und realer Einsatzfälle sind eingeflossen, aber es gibt noch nicht abgedeckte Fälle, weshalb externe Beiträge gesucht werden
• Die aktuelle Version ist v0.1.0; da noch Ecken und Kanten vorhanden sind, wird um Issue-Reports gebeten

Lokales ASR bis hin zu stromsparenden Geräten

• Ziel ist es, ASR direkt auf dem Gerät einfacher ausführbar zu machen und damit die Notwendigkeit zu verringern, Sprache an Cloud-Dienste zu senden
• Selbst auf einer leistungsschwachen RK3566-CPU können Modelle schneller als in Echtzeit laufen
• Transkriptionsgeschwindigkeiten oberhalb von Echtzeit mit modernen Modellen sind bei einer Leistungsaufnahme von nur wenigen Watt möglich
• Damit mehr Inferenz lokal verarbeitet werden kann, muss die Bereitstellung und Ausführung einer Inferenz-Engine in Anwendungen einfacher werden
• transcribe.cpp kann das gesamte Problem lokaler Inferenz-Bereitstellung nicht allein lösen, wurde aber als Schritt entwickelt, um die Einstiegshürde für lokales ASR zu senken

Unterstützung hinter dem Projekt

• Mozilla AI, das BiR-Programm und Davide von Mozilla AI unterstützten das Projekt schon in einer frühen Explorationsphase, als es noch keine konkrete Produktform gab
• ggml ist die zentrale Grundlage, die die Bereitstellung lokaler Inferenzanwendungen ermöglicht
• Modal stellte Credits für WER-Tests und CUDA-Validierung bereit
• Blacksmith unterstützte einen Teil der CI/CD zur Prüfung der Release-Artefakte
• Hugging Face stellte der Organisation handy-computer privaten Speicherplatz zur Verfügung, damit Modelle frei hochgeladen werden konnten

KI-Nutzung im Entwicklungsprozess

• Da es als schwierig eingeschätzt wurde, eine Engine dieser Größenordnung auf ggml-Basis innerhalb weniger Monate allein von Grund auf neu zu schreiben, wurde bei der Entwicklung KI-Unterstützung eingesetzt
• Der Projektvorstellungstext wurde nicht mit KI geschrieben, sondern besteht aus selbst gesprochenen oder eingegebenen Sätzen

[GN⁺]

Meinungen auf Hacker News

• Sieht sehr cool aus. Allerdings habe ich in der Modelldokumentation keine Funktion gefunden, die nicht die Bedeutung einer unbekannten Sprache, sondern die Laute in Internationaler Lautschrift (IPA) transkribiert.
  Für Minderheitensprachen mit weniger als 10.000 Sprechern könnten die Ressourcen, um sprachspezifische Modelle zu trainieren, dauerhaft fehlen. Ein Modell, das Sprache nicht identifiziert, sondern die Sprachsignale selbst in IPA überträgt, wäre für Linguisten, die Minderheitensprachen weltweit erforschen, eine große Hilfe.

  • In tatsächlicher gesprochener Sprache gibt es viele Auslassungen und Verkürzungen; selbst wenn man die Sprache kennt, ist eine phonemische Transkription deutlich schwieriger als eine Worttranskription. Es gibt zwar Modelle wie https://huggingface.co/spaces/KoelLabs/IPA-Transcription-EN, aber die Fehlerrate ist sehr hoch.
  • Die Familie meiner Frau stammt aus Iu Mien, einer Untergruppe der chinesischen Dao- bzw. Yao-Völker. Mien ist eine eigenständige Sprache, aber die meisten Sprecher sind praktisch Analphabeten, und es gibt kaum Lehrmaterialien oder Kurse, was das Lernen schwierig macht.
    Auch schriftliche Quellen sind rar, daher würde ich gern wie in „Project Hail Mary“ selbst ein Übersetzungssystem bauen.
  • Ich kenne kaum Modelle, die diese Funktion unterstützen; derzeit liegt das außerhalb des Umfangs der Library, aber wenn es ein geeignetes Modell gibt, würde ich es gern unterstützen.
  • Es gibt einige Modelle für automatische Phonemerkennung (APR), aber ihre Leistung ist eher mittelmäßig.
  • Solche Modelle müssten vermutlich den Lautumfang kennen, den sie zu hören erwarten, um praktisch brauchbar zu sein. IPA kann sehr viele Laute ausdrücken, einzelne Sprachen verwenden aber nur einen Teil davon.
    Das dunkle und helle l im Englischen (ball/light) sowie aspiriertes p (pin/spin) können in anderen Sprachen Bedeutungen unterscheiden, im Englischen jedoch nicht. Ich frage mich, ob Linguisten zunächst eine möglichst getreue IPA-Transkription erhalten und sie anschließend manuell normalisieren möchten.

• Glückwunsch zum Release. Ich nutze Handy gern auf dem Mac und dem Smartphone; es ist besonders nützlich, wenn die Apple-eigene Spracherkennung wie bei Fachbegriffen bestimmter Domänen danebenliegt.
  Ich frage mich, ob man die Wartungskosten von einer Stiftung finanzieren lassen könnte. Wenn man für ein solches Projekt bezahlt werden wollte, würde mich auch interessieren, welche Organisationen man anspricht und auf welche Weise man Unterstützung anfragt.

  • Als Handy populär wurde, bin ich unbeabsichtigt zu einem Open-Source-Maintainer geworden, und glücklicherweise unterstützen private Spenden und mehrere Sponsoren die Arbeit.
    Ich möchte weiter an Open Source mitarbeiten, daher ist jede Stelle willkommen, die das unterstützt; besonders gut passt es zu Organisationen, die an Open Source glauben und es voranbringen. Für detailliertere Gespräche geht [e-mail].
  • Die betriebssystemeigene Diktierfunktion von iOS muss bei jeder Anfrage das Adressbuch an Apple hochladen, selbst wenn man iCloud nicht nutzt; deshalb bleibt mir nichts anderes übrig, als sie auszuschalten.

• Viele Speech-to-Text-Systeme erkennen die Äußerung selbst zwar korrekt, unterstützen aber nicht den gewünschten Workflow. Wenn man ein Dokument öffnet und spricht, sollte es an der Cursorposition mit minimaler Latenz kontinuierlich eingeben.
  Ein Ansatz, bei dem nach dem Stoppen der Aufnahme alles auf einmal eingefügt wird, ist nicht nützlich; kontinuierliche Eingabe ist der Kern.

  • Mir lag im Gegenteil die Methode besser, nach Ende der Aufnahme alles auf einmal zu transkribieren. Wenn ich Eingabe in Echtzeit sehe, fällt es schwer, einen Gedanken zu Ende zu führen, weil ich die Transkriptionsfehler überprüfe.
    Es ist nützlicher, zu einem Thema 5–10 Minuten lang alles auszusprechen, was einem durch den Kopf geht, und es danach zu prüfen, ohne den Denkfluss zu unterbrechen.
  • Wenn gewünscht, ließe sich Handy relativ leicht anpassen, um das umzusetzen. Ich plane, es auch als offizielle Funktion der App hinzuzufügen, aber vorher gibt es noch vieles zu erledigen.
  • Englische Wörter lassen sich oft erst durch den umgebenden Kontext festlegen. Zum Beispiel sind there und their allein anhand der Aussprache nicht unterscheidbar.
  • Wie nützlich eine Transkriptionsfunktion ist, hängt von der Nutzungsweise ab. Wenn man während des Diktierens andere Fenster öffnet oder sich Diagramme und Daten ansieht, lassen sich leichter Informationen bereitstellen, die die Äußerung stützen.
    Manche Apps nutzen sogar Inhalte, die man kopiert oder gerade ansieht, als Transkriptionskontext, um die Ergebnisse zu verbessern: https://superwhisper.com/docs/common-issues/context#types-of...
  • Ich habe diesen Ansatz unter https://github.com/electronstudio/low_latency_dictation ausprobiert, aber die Genauigkeit des Echtzeitmodells war gering. Deshalb wird vor dem Festschreiben des Texts ein zweiter Durchlauf mit einem genaueren Modell ausgeführt.

• Ich frage mich, ob man wie bei Whisper.cpp Kontext eingeben kann, um die Genauigkeit stark zu erhöhen.

  • Ja, das geht.

• Das Python-Binding unter den vier vom Maintainer unterstützten Sprach-Bindings befindet sich unter https://github.com/handy-computer/transcribe.cpp/tree/main/b....
  Es gibt noch kein binäres PyPI-Wheel mit Abhängigkeiten; die aktuelle PyPI-Library ruft eine separat installierte Library über ctypes auf, aber offenbar ist ein Release geplant.

  • Ich habe bei PyPI einen PR gestellt, um zusätzlichen Speicherplatz für CUDA-Pakete anzufordern, aber er scheint noch nicht genehmigt zu sein. Ich würde mich über Hilfe freuen, um die Developer Experience (DX) der Bindings zu verbessern.

• Ich habe das genau zum richtigen Zeitpunkt entdeckt. Ich stoße häufig auf Gespräche darüber, Text-to-Speech (TTS) in Prompt-Tools einzubauen, und wollte es selbst ausprobieren.
  Der Kreislauf, aufkommende Gedanken ausführlich auszusprechen, daraus ein Dokument zu machen, es zu bearbeiten und dann an eine AI zu schicken, wirkt reizvoll.

• Das ist ein enormer Beitrag zur Community, und es ist erstaunlich, dass er von einer einzelnen Person gebaut wurde. Ich hätte am Ende fast eine Ankündigung einer Series-A-Finanzierung erwartet.
  Man kann mit AI schnell minderwertige Ergebnisse ausspucken, aber das zeigt auch, dass man seine Ambitionen erweitern und etwas Strengeres und Langlebigeres als zuvor schaffen kann. Statt Transcribe.cpp direkt in eigene Apps einzubauen, sollten solche Funktionen meiner Meinung nach über das Betriebssystem oder Apps wie Handy überall verfügbar sein.

  • Ja, ich bin der Autor und Maintainer, und die Spenden von Sponsoren und der Handy-Community haben sehr geholfen. Insbesondere Mozilla AI hat die frühe Arbeit unterstützt und mir die Zeit verschafft, aus einem vagen Traum für Handy ein echtes Projekt zu machen und v0.1.0 zu veröffentlichen.
    Eines Tages möchte ich libtranscribe ordentlich ausliefern und es zu etwas wie einer Systembibliothek machen. Die Stabilisierung wird Zeit brauchen, aber ich halte es für möglich.

• Funktioniert deutlich besser als das bisherige transcribe-rs. Ich habe auch meine Offline-Sprach­eingabe-App aktualisiert, damit sie die neue Bibliothek nutzt, und dadurch wurde sie deutlich schneller: https://github.com/notune/android_transcribe_app

• Die Einschätzung ist richtig, dass lokale Inferenz aus mehreren Gründen zunehmen wird und dass Ausführung und Bereitstellung einfacher werden müssen, damit mehr Apps sie nutzen können.
  Dass kein einziges Wort des Textes von einer KI geschrieben wurde, sondern aus Mund oder Fingern stammt, macht das Projekt ebenfalls vertrauenswürdiger und zugänglicher.

  • Da die Werkzeuge, die wir verwenden, unser Denken formen, fällt es mir schwer, dieser Aussage zuzustimmen. Ein Spracherkennungs-LLM ist letztlich auch ein LLM, und Fehler entstehen entsprechend den im Training verankerten Erwartungen; das beeinflusst auch die Wörter, die auf dem Bildschirm erscheinen.
    Wenn man es häufig nutzt, lernt man, welche Wortfolgen korrekt transkribiert werden, und das wird Teil des Denkprozesses. Mit der Zeit verflechten sich LLM und Denken, sodass auch diese Art der KI-Nutzung den endgültigen Satz tatsächlich verändern kann.

• Ich habe Ähnliches erlebt, als ich mich damit beschäftigt habe, lokal einen Transkriptions-API-Server zu betreiben. Am meisten fehlten mir Streaming-Unterstützung und Unterstützung für spezielle Wörter, die bei der Erkennung priorisiert werden sollen; schön, dass es hier Streaming gibt.

  • Seit whisper.cpp erschienen ist, betreibe ich es selbst auf einem 3090-Ti-Server. Selbst wenn inzwischen schnellere und bessere Alternativen erschienen sind, läuft es weiterhin problemlos, die Gewichte sind klein und es ist mehr als schnell genug für das, was ich brauche.
    Wenn man es wie unten auf einem lokalen Homeserver bereitstellt, lässt sich daraus einfach eine lokale Transkriptions-API machen. Die Inferenzparameter muss man etwas anpassen, aber wenn sie einmal festgelegt sind, funktioniert es sehr gut.

    MODEL="/home/user/projects/ggml-org/whisper.cpp/models/ggml-large-v3-turbo.bin"
WHISPER_SERVER_BIN="/home/user/projects/ggml-org/whisper.cpp/build/bin/whisper-server"
"$WHISPER_SERVER_BIN" --model "$MODEL" --language en --host 127.0.0.1 --port 7812

  • Anpassung von Wortgewichten wird wahrscheinlich erst deutlich später unterstützt, aber Streaming ist bereits verfügbar.
    Ich hoffe, dass jemand ein gutes Serverbeispiel zur Codebasis beiträgt und auch bei der Fehlerbehebung hilft – oder mit transcribe.cpp bzw. Bindings einen robusten Server in einer anderen Sprache baut. Wenn er fertig ist, wäre ich auch bereit, ihn direkt im Hauptprojekt zu verlinken.