Mistrals Voxtral Mini 4B Realtime-Modell in Rust implementiert und im Browser ausgeführt

 (github.com/TrevorS)
4 Punkte von GN⁺ 2026-02-11 | 1 Kommentare | Auf WhatsApp teilen
  • Streaming-Spracherkennung als Rust-basierte Implementierung, die sowohl nativ als auch im Browser ausgeführt werden kann, unter Verwendung des Burn-ML-Frameworks
  • Das Modell basiert auf Mistrals Voxtral Mini 4B Realtime und führt über WASM + WebGPU vollständige clientseitige Inferenz direkt im Browser-Tab aus
  • Das Q4-GGUF-quantisierte Modell (2,5 GB) kann im Browser ausgeführt werden, während das F32-Modell auf SafeTensors-Basis (9 GB) in nativen Umgebungen läuft
  • Zur Lösung von Browser-Beschränkungen (2-GB-Allokation, 4-GB-Adressraum, Einschränkungen beim GPU-Lesen usw.) werden Techniken wie Sharding, zweistufiges Laden und asynchrone Tensor-Verarbeitung eingesetzt
  • Unter der Apache-2.0-Lizenz veröffentlicht, mit einer Live-Demo in HuggingFace Spaces

Überblick über Voxtral Mini 4B Realtime (Rust)

  • Mistrals Voxtral Mini 4B Realtime-Modell vollständig in Rust und dem Burn-ML-Framework implementiert
    • Streaming-Spracherkennung kann lokal und in Browser-Umgebungen ausgeführt werden
    • Die Browser-Version läuft clientseitig mit WASM (WebAssembly) und WebGPU
  • Das Q4-GGUF-quantisierte Modell (ca. 2,5 GB) läuft im Browser, das F32-SafeTensors-Modell (ca. 9 GB) wird in nativen Umgebungen verwendet
  • Live-Demo in HuggingFace Spaces verfügbar

Architektur

  • Eingabe-Audio (16 kHz mono) wird in ein Mel-Spektrogramm umgewandelt und anschließend durch Encoder (32 Schichten) und Decoder (26 Schichten) in Text transformiert
  • Wichtige Verarbeitungsschritte
    • Mel-Spektrogramm → Encoder (32 Schichten, 1280 Dimensionen) → Conv-4x-Downsampling → Adapter (3072 Dimensionen) → Decoder (GQA 32Q/8KV)
  • Es werden zwei Inferenzpfade angeboten
    • F32 (nativ): auf SafeTensors-Basis, mit Burn-Tensor-Operationen
    • Q4 GGUF (nativ + Browser): GGUF-Q4_0-Quantisierung, mit benutzerdefinierten WGSL-Shadern

Technische Lösungen für die Browser-Ausführung

  • Für die Ausführung eines 4B-Modells im Browser werden fünf Einschränkungen gelöst
    1. 2-GB-Allokationslimit → Lesen mehrerer Buffer mit ShardedCursor
    2. 4-GB-Adressraumlimit → zweistufiges Laden (nach dem Parsen Reader freigeben, danach finalisieren)
    3. 1,5-GiB-Embedding-Tabelle → GPU-Q4-Embedding + CPU-Zeilenabfrage
    4. Synchrones GPU-Lesen verboten → Verwendung von into_data_async().await
    5. 256-Workgroup-Limit → Begrenzung der Kernel-Größe per cubecl-wgpu-Patch

Q4-Padding-Korrektur

  • Standardmäßig padet mistral-common Audio mit 32 Stille-Tokens, was jedoch nur die Hälfte der 38 Präfixe des Decoders abdeckt
  • Das Q4_0-quantisierte Modell erzeugt dadurch Fehler bei Eingaben, bei denen Sprache sofort beginnt
  • Zur Behebung wird das Padding auf 76 Tokens (= 38 Decoder-Tokens) erweitert, sodass das gesamte Präfix mit Stille gefüllt wird

Build und Test

  • Build-Optionen
    • Standard: cargo build --release (wgpu + native-tokenizer)
    • Für den Browser: wasm-pack build --target web --features wasm
  • Tests
    • GPU-basierte Unit- und Integrationstests werden unterstützt
    • E2E-Browser-Tests werden mit Playwright + echter GPU-Umgebung durchgeführt
    • In CI werden diese Tests mangels GPU übersprungen

Modellvorbereitung und Sharding

  • Wegen des ArrayBuffer-Limits im Browser (unter 512 MB) wird die GGUF-Datei in Shards aufgeteilt 
    split -b 512m models/voxtral-q4.gguf models/voxtral-q4-shards/shard-
  • Entwicklungsserver und E2E-Tests erkennen die Shards automatisch

Lizenz und Ressourcen

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2026-02-11
Hacker-News-Kommentare

  • Falls es jemanden interessiert: @antirez hat eine C-Implementierung von Voxtral Mini 4B veröffentlicht.
    Zu finden unter antirez/voxtral.c.
    Ich habe meine Fork-Version erstellt und füge eine CUDA-Implementierung sowie einige Verbesserungen hinzu.
    Läuft ziemlich gut, erreicht aber noch nicht die Geschwindigkeit des API-Endpunkts von Mistral AI.

    • Ich frage mich, wie man am besten anfängt, Dinge wie solchen Inference-Code oder CUDA-Implementierungen zu lernen.
      Vermutlich sollte ich nicht einfach direkt losschreiben, sondern zuerst passendes Material lesen und lernen. Ein guter Leitfaden wäre hilfreich.
    • Es gibt noch eine weitere Mistral-Implementierung: mistral.rs.
      Ich kenne die Unterschiede nicht genau, aber die Reaktionen der Community scheinen dort besser zu sein.

  • Als ich die Demo ausprobiert habe, musste ich erst auf den Mic-Button drücken, aufnehmen und dann „Stop and transcribe“ wählen, damit ein Ergebnis erscheint.
    Ich frage mich, ob man daraus einen echten Echtzeitmodus machen könnte, bei dem 1–2 Sekunden nach dem Sprechen sofort Untertitel erscheinen.
    Hugging Faces Server-Demo setzt das mit einem GPU-basierten 8,5-GB-Modell um.

    • Bei der aktuellen Geschwindigkeit ist vollständige Echtzeit schwierig.
      Mit einer UI auf Ringpuffer-Basis ließe sich aber etwas Ähnliches umsetzen.
      Ich nutze Whisper in Flutter auf diese Weise und lasse auch GGUF-Inference von llama.cpp in Dart laufen.
      Selbst auf einem M4 Max ist es nicht wirklich Echtzeit, und Whisper läuft auf Geräten ab 2022 mit ONNX fast in Echtzeit.
      Auf Consumer-Hardware ist Inference-Geschwindigkeit meiner Meinung nach wichtiger als eine bessere Genauigkeit (WER).

  • Solche On-Premise-Open-Modelle sind genau die Richtung, die wir wirklich brauchen.
    Sowohl Nutzer als auch Unternehmen bevorzugen so etwas. Mistral scheint das gut getroffen zu haben.

    • Für Mistral könnte das ein Moment wie der Wendepunkt von Red Hat sein.
      Die Ära offener Modelle dürfte jetzt noch spannender werden.

  • Tolle Arbeit. Es wäre schön, wenn das mit handy.computer integriert würde, und ich frage mich, ob Streaming-Support geplant ist.

    • Ich will das nach transcribe-rs portieren, damit es in Handy genutzt werden kann.
      Die erste Version wird Streaming vermutlich noch nicht unterstützen.
    • Ich habe Handy ausprobiert, und es war deutlich leichter und mit aufgeräumterer UI als frühere Lösungen.
      So habe ich ein gutes Tool kennengelernt, und jetzt habe ich wirklich das Gefühl, dass Voxtral-Unterstützung nötig ist.

  • Ich kenne mich mit dem Modell nicht besonders gut aus, habe aber Nvidia Parakeet ausprobiert, und das funktioniert sehr gut.
    Ich frage mich, ob man so ein 9-GB-Modell für Echtzeitnutzung dauerhaft im GPU-Speicher halten muss oder ob man es jedes Mal neu laden kann.

    • Ich nutze auch Parakeet V3, und die Balance aus Geschwindigkeit und Genauigkeit ist hervorragend.
      Kurze Sätze werden fast sofort umgewandelt, längere innerhalb von 1–3 Sekunden.
      Ein kleiner Genauigkeitsverlust ist für Gespräche mit einer KI praktisch bedeutungslos.
      In der Open-Source-App Handy (Link) wird Parakeet V3 verwendet, und die C-Implementierung war deutlich langsamer.
      Bei STT ist Geschwindigkeit der Kern der UX.
    • Ich betreibe einen ollama-Server, und das Laden des Modells geht ziemlich schnell.
      Verzögerungen entstehen, wenn ein neues Modell geladen oder ein großer Kontext ausgetauscht wird.
      Meistens ist das Modell bereits geladen, daher sind tokens per second die entscheidende Variable.
      In komplexeren Setups mit mehreren Agenten wird es durch Kontextwechsel langsamer.
      Das Prompt-Caching von ik_llama beschleunigt solche Situationen.
      Kurz gesagt: Solange man Modell oder Kontext nicht ständig wechselt, ist die Latenz durch das Laden der Gewichte kein großes Problem.

  • Ich bezweifle, dass es effizient ist, wenn ein Browser-Tab ein 2,5-GB-Modell herunterlädt und kurz darauf wieder löscht.
    Auch wenn Internetgeschwindigkeit und Speicherplatz billiger geworden sind, wirkt das verschwenderisch.
    Clientseitige Berechnung ist gut, aber bei Modellen dieser Größe scheint Serverbetrieb sinnvoller.

    • In der aktuellen Browser-Umgebung dürften sich lokale Modelle kaum breit durchsetzen.
      Mit einem Web-API-Standard für LLMs könnte sich das aber ändern.
      Wenn der Browser mit dem bevorzugten Modell des Nutzers kommuniziert und lokale/remote Inference abstrahiert, könnten Modelle zwischen Websites geteilt werden.
    • Neue Technologien stoßen immer auf Beschwerden.
      Wenn 2026 ein lokales Modell mit 2,5 GB schon als Problem gilt, fragt man sich, was dann überhaupt noch als akzeptabel gelten soll.
      Die Entwicklung ging von unmöglich → zentralisiert → lokal, und wenn der Preis dafür 2,5 GB ist, dann ist das durchaus tragbar.

  • Dass es im Browser läuft, ist cool, aber ich möchte nicht in einer Welt leben, in der Websites im Hintergrund 2,5 GB herunterladen.

    • Ich habe Gemini Nano (das in Chrome integrierte KI-Modell) mit serverbasierten Lösungen verglichen.
      Nano wird im lokalen Speicher abgelegt und zwischen Websites geteilt, deshalb muss es nur einmal heruntergeladen werden.
      Bei Mistral scheint das nicht so zu sein.
      Relevante Zahlen sind in diesem Blogpost zusammengefasst.
    • Natürlich möchte ich auch nicht, dass beim Besuch einer Webseite automatisch etwas heruntergeladen wird,
      aber ich halte die Browser-Sandbox für sicherer als die Installation eines Pakets oder das Herunterladen einer ausführbaren Datei.
    • Wir leben bereits in einer Welt, in der selbst für eine statische Landingpage Dutzende MB geladen werden.
      Bald wird man sich auch daran gewöhnen :-)

  • In meiner Umgebung (Firefox, Asahi Linux, M1 Pro) funktioniert es fehlerhaft.
    Ich habe „hello“ gesagt, und etwa eine Minute später wurden wiederholt seltsame Wörter ausgegeben.

  • Einfache Frage: Wie gut sind offene Modelle wie Mistral im Vergleich zu OpenAI oder Anthropic?
    Reicht das schon, um LLM-Funktionen privat auf dem eigenen Rechner zu nutzen,
    oder liegen sie noch deutlich hinter kommerziellen Modellen zurück?

  • Interessantes Projekt, und ich freue mich auch darüber, dass das burn-Framework verwendet wird.
    Allerdings ist beim Ausführen in der neuesten Chromium-Version mein System eingefroren und das OS wurde zwangsweise beendet.
    Direkt nach dem Modelldownload wurde auch die VPN-Verbindung getrennt, obwohl keine Bandbreitenbegrenzung aktiv war, daher weiß ich nicht, warum.