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

• 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

• Apache-2.0-Lizenz
• Browser-Demo in HuggingFace Spaces verfügbar: TrevorJS/voxtral-mini-realtime