Reine C-basierte, CPU-only-Inferenzimplementierung des Spracherkennungsmodells Mistral Voxtral Realtime 4B

• Mistral Voxtral Realtime 4B: eine nur in C implementierte Inferenz-Pipeline, als eigenständige Ausführung ohne jegliche externe Abhängigkeiten
• Unterstützt Metal-GPU-Beschleunigung (MPS) und BLAS-Backends (OpenBLAS/Accelerate) und verarbeitet über eine Streaming-API Spracheingaben in Echtzeit sowie Token-Ausgaben
• Speicherabgebildete BF16-Gewichte, ein Encoder auf Basis eines Sliding Window und ein Rolling KV Cache halten den Speicherverbrauch auch bei langen Audioeingaben konstant
• Unterstützt verschiedene Audioeingaben über Mikrofon, stdin-Pipe und ffmpeg-Konvertierung; bietet Anzeige alternativer Tokens und die Latenzsteuerungsoption -I
• Veröffentlicht unter der MIT-Lizenz und erreicht auf einem Apple M3 Max etwa das 2,5-Fache der Echtzeitgeschwindigkeit, was eine schlanke lokale Spracherkennung ermöglicht

---

Überblick über Voxtral.c

• Eine reine C-basierte Inferenz-Engine für das Voxtral Realtime 4B-Modell von Mistral AI, ohne Abhängigkeiten außer der C-Standardbibliothek
  • Das MPS-Backend bietet schnelle Inferenz, BLAS (OpenBLAS/Accelerate) läuft in CPU-basierten Umgebungen
  • Vollständige lokale Inferenz auch ohne Python-Runtime, CUDA oder vLLM
• Mit der Datei python_simple_implementation.py wird zusätzlich eine einfache Python-Referenzimplementierung bereitgestellt
  • Benötigt nur PyTorch, safetensors, soundfile und soxr

Hauptfunktionen

• Zero dependencies: Ausführung nur mit C, ohne externe Bibliotheken
• Metal-GPU-Beschleunigung: wird auf Apple Silicon automatisch aktiviert, mit Fusion von GPU-Operationen und gebatchter Attention-Verarbeitung
• Streaming-Ausgabe: erzeugte Tokens werden sofort auf stdout ausgegeben
• Streaming C API: Audio wird fortlaufend eingespeist, Token-Strings werden in Echtzeit empfangen
• Speicherabgebildete Gewichte: safetensors-Dateien werden direkt per mmap geladen und sind sofort nutzbar
• Unterstützung für Mikrofoneingabe (macOS): inklusive automatischer Stilleerkennung
• Chunked Encoder: verarbeitet Audio in überlappenden Chunks und hält den Speicherverbrauch konstant
• Rolling KV Cache: automatische Cache-Komprimierung mit Sliding Window über 8192 Positionen, wodurch Audio beliebiger Länge verarbeitet werden kann

Verwendung

• Grundlegende Befehle
  • ./voxtral -d voxtral-model -i audio.wav : dateibasierte Spracherkennung
  • ./voxtral -d voxtral-model --from-mic : Echtzeit-Erkennung über Mikrofon (macOS)
  • Eingaben in verschiedenen Audioformaten sind über eine ffmpeg-Pipe möglich
• Anzeige alternativer Tokens
  • Mit der Option --alt <cutoff> können zusätzlich ähnlich klingende Kandidaten angezeigt werden
  • Je höher der Wert cutoff, desto mehr Kandidaten werden angezeigt
• Latenzsteuerung (Option -I)
  • Legt das Aufrufintervall des Encoders in Sekunden fest
  • Niedrige Werte (z. B. 0,5 Sekunden) bedeuten geringe Latenz, aber höhere GPU-Last / hohe Werte (z. B. 5 Sekunden) ermöglichen effizientere Verarbeitung
  • Standard ist 2,0 Sekunden; für Echtzeit-Streaming werden 1,0 bis 2,0 Sekunden empfohlen

Struktur der C API

• Bietet eine Streaming-API auf Basis von vox_stream_t
  • feed() : Audio einspeisen
  • get() : Tokens empfangen
  • finish() : verbleibendes Audio verarbeiten
  • flush() : Puffer zwangsweise verarbeiten
• Mit vox_stream_set_alt() kann die Anzahl alternativer Tokens festgelegt werden
• Mit der Funktion vox_transcribe() ist auch Stapelverarbeitung einer einzelnen Datei möglich

Modelldownload und Konfiguration

• Download von rund 8,9 GB Modellgewichten von HuggingFace
  • consolidated.safetensors (BF16-Gewichte)
  • tekken.json (Tokenizer-Vokabular)
  • params.json (Modellkonfiguration)
• Apache-2.0-lizenziertes Modell, MIT-lizenzierter Code

Performance-Benchmarks

• Basierend auf Apple M3 Max (40-Core-GPU, 128 GB RAM)
  • MPS-Backend: Encoder 284 ms, Decoder 23,5 ms/Schritt
  • BLAS-Backend: Encoder etwa 8 Sekunden, Decoder 335 ms/Schritt
• Durchschnittlich 31,6 ms/Schritt bei 60 Sekunden Audio, also rund 2,5-mal schneller als Echtzeit
• Der Decoder führt die gesamte Berechnung pro Token in einem einzigen Metal-Command-Buffer-Aufruf aus

Modellarchitektur

• Streaming-Sprach-zu-Text-Modell mit insgesamt 4 Milliarden Parametern (4B)
  • Audio-Encoder: 32-lagiger causal Transformer, 1280 Dimensionen, 32 Heads, Fenstergröße 750
  • Adapter: Linear(5120→3072) → GELU → Linear(3072→3072)
  • LLM-Decoder: 26-lagiger Transformer (basierend auf Ministral-3), 3072 Dimensionen, GQA (32 Heads/8KV)
• Tekken-Tokenizer, Vokabulargröße 131.072
• Unterstützte Sprachen: Englisch, Spanisch, Französisch, Portugiesisch, Hindi, Deutsch, Niederländisch, Italienisch, Arabisch, Russisch, Chinesisch, Japanisch, Koreanisch

Speicheranforderungen

• Modellgewichte: 8,9 GB (On-Demand-mmap)
• GPU-Cache: etwa 8,4 GB (nach BF16→F16-Konvertierung)
• KV-Cache: maximal 1,8 GB (durch Sliding-Window-Begrenzung)
• Arbeitsbuffer: etwa 200 MB

Build und Plattformen

• macOS Apple Silicon: make mps (am schnellsten)
• macOS Intel / Linux(OpenBLAS) : make blas
• Ubuntu/Debian: sudo apt install libopenblas-dev
• Fedora: sudo dnf install openblas-devel

Lizenz

• Code: MIT
• Modell: Apache-2.0
• Als Open-Source-Projekt kann es von allen modifiziert und weiterverbreitet werden

[GN⁺]

Hacker-News-Kommentare

• Ich nutze STT (Spracherkennung) mit der Open-Source-App Handy in Kombination mit Parakeet V3.
  In Sachen Geschwindigkeit und Genauigkeit habe ich bisher nichts gesehen, das diese Kombination übertrifft. Die Transkription erfolgt nahezu sofort, und der leichte Genauigkeitsverlust ist dank der Fähigkeit der KI, den Kontext zu verstehen, kein Problem.
  Ich habe versucht, die Voxtral-C-Implementierung in Handy zu integrieren, aber auf einem M1 Max MacBook (64 GB) war die Transkription zu langsam. Ich werde noch andere Implementierungen ausprobieren.

  • Handy ist großartig, aber schade ist, dass STT nicht in Echtzeit, sondern als Batch-Verarbeitung arbeitet.

• Ich bin ein Fan von Salvatores Projekten voxtral.c und flux2.c.
  Ich hoffe, dass sie als leichtgewichtige Option ohne externe Abhängigkeiten weiter optimiert werden. Derzeit sind sie für den praktischen Einsatz aber noch zu langsam (basierend auf AMD 7800X3D/Blas).
  Als ich die Voice-Input-Funktion zu llms-py hinzugefügt habe, war die Unterstützung für Omarchys voxtype.io in Bezug auf die UX am besten, gefolgt von Whisper.cpp.
  OpenAI Whisper ist langsam, aber immer noch eine stabile lokale Option für Transkription.
  Auch Mistrals Voxtral Transcription API war hinsichtlich Geschwindigkeit und Preis beeindruckend — mit $0.003 pro Minute sehr schnell und günstig. Ich denke, das ist die beste Wahl in Umgebungen mit CPU- oder Festplattenbeschränkungen.

  • Das Modell selbst ist hervorragend, aber für lokale Inferenz zu groß. Whisper medium hat zwar geringere Qualität, ist aber in Bezug auf die Eignung für die Umgebung besser.
    Ich will jetzt das neu erschienene Transkriptionsmodell Qwen 0.6 testen. Wenn die Benchmarks stimmen, hat es großes Potenzial, sich zu einer leichtgewichtigen Kette weiterzuentwickeln, die sogar CPU-only-Optimierung und 8-Bit-Quantisierung berücksichtigt.
    Da es auch in gemieteten Serverumgebungen wie Hetzner installierbar sein muss, werde ich versuchen, nach Intel-, AMD- und ARM-Sets zu optimieren.
  • Ich brauche visuelles Feedback, bei dem die Transkription während des Sprechens gleichzeitig erfolgt. Ich frage mich, ob voxtype das unterstützt.
    Handy soll eine Overlay-Funktion haben, aber auf meinem System funktioniert sie nicht.
  • Ich stimme für die Kombination aus voxtype und dem Whisper-base-Modell. Ziemlich schnell und präzise.

• Unter Linux war die Installation einfach, aber Echtzeit-Transkription wie bei Whisper.cpp oder Moonshine geht noch nicht.
  Die Option --from-mic wird nur auf dem Mac unterstützt, daher habe ich versucht, Audio mit ffmpeg aufzunehmen, aber die Verbindung des Mikrofoneingangs ist fehlgeschlagen.
  Mein System scheint für das Standardmodell nicht leistungsfähig genug zu sein.
  Ich würde gern das voxtral-q4.gguf-Modell ausprobieren.

  • Nach Tests unter Linux ist dieses Modell für Echtzeit-Transkription viel zu langsam. Die Verarbeitung einer 12-minütigen Eingabedatei dauerte einen halben Tag.
  • Ich möchte nicht nur das Mikrofon, sondern auch Audio vom Monitor-Port erfassen und Web-Audio in Echtzeit in eine Transkriptions-Pipeline einspeisen.
    Mit Audacity oder OBS Studio kann ich aufnehmen, also sollte Echtzeit eigentlich auch möglich sein.
  • Wenn man Audio mit ffmpeg aus einer Datei liest und an voxtral weitergibt, könnte es funktionieren.
    Persönlich würde ich wohl in dieser Reihenfolge experimentieren: Datei→ffmpeg→voxtral, dann Mikrofon→ffmpeg→Datei und zuletzt Mikrofon→ffmpeg→voxtral.

• Im Titel steht zwar CPU-only, tatsächlich wird aber auch GPU-Beschleunigung unterstützt. Das steht in der Repository-Beschreibung eindeutig drin.

• Dieses Projekt und die Rust-Runtime-Implementierung stehen gleichzeitig auf der HN-Startseite. Eine interessante Wettbewerbssituation.

• Es gibt auch eine MLX-Version der Implementierung → voxmlx

• Ich interessiere mich sehr für den Bereich Speech-to-Text (STT).
  Ich möchte mit Daten arbeiten, in denen verschiedene Akzente und Fachbegriffe gemischt sind, aber ich weiß nicht, wo ich anfangen soll, wenn ich mit meinen umfangreichen Sprachsample-Daten ein Modell trainieren will. Ich bitte um Rat.

• Ich habe es auf einem 16-GB-M3-MacBook-Pro ausprobiert; es lädt zwar, aber hängt oder ist viel zu langsam.

• Es fühlt sich seltsam an, dass für etwas, das vor 20 Jahren mit etwa 200 MB möglich war, heute ein 9-GB-Modell nötig ist.