Implémentation d’inférence CPU uniquement en pur C pour le modèle de reconnaissance vocale Mistral Voxtral Realtime 4B

• Mistral Voxtral Realtime 4B : un pipeline d’inférence implémenté uniquement en C, avec une architecture autonome sans aucune dépendance externe
• Prend en charge les backends Metal GPU acceleration (MPS) et BLAS (OpenBLAS/Accelerate), et traite l’entrée vocale en temps réel ainsi que la sortie des tokens via une API de streaming
• Grâce à des poids BF16 mappés en mémoire, un encodeur à fenêtre glissante et un rolling KV cache, l’utilisation mémoire reste stable même sur de longues entrées audio
• Prend en charge plusieurs modes d’entrée audio via microphone, pipe stdin et conversion ffmpeg, avec affichage de tokens alternatifs et option de réglage de la latence (-I)
• Publié sous licence MIT, avec des performances d’environ 2,5 fois le temps réel sur Apple M3 Max, rendant possible une reconnaissance vocale locale allégée

---

Présentation de Voxtral.c

• Moteur d’inférence en pur C pour le modèle Voxtral Realtime 4B de Mistral AI, sans dépendance en dehors de la bibliothèque standard C
  • Le backend MPS offre des performances d’inférence rapides, tandis que BLAS (OpenBLAS/Accelerate) fonctionne dans les environnements basés CPU
  • Inférence entièrement locale possible sans runtime Python, CUDA ni vLLM
• Une implémentation de référence Python simple est également fournie via le fichier python_simple_implementation.py
  • Nécessite seulement PyTorch, safetensors, soundfile et soxr

Fonctionnalités principales

• Zero dependencies : exécutable uniquement en C, sans bibliothèque externe
• Accélération GPU Metal : activée automatiquement sur Apple Silicon, avec fusion des opérations GPU et traitement batché de l’attention
• Sortie en streaming : les tokens générés sont immédiatement affichés sur stdout
• API C de streaming : permet d’alimenter l’audio séquentiellement et de recevoir les chaînes de tokens en temps réel
• Poids mappés en mémoire : chargement direct des fichiers safetensors via mmap, immédiatement exploitables
• Prise en charge du microphone (macOS) : avec détection automatique du silence
• Chunked Encoder : traite l’audio en chunks qui se chevauchent afin de maintenir une utilisation mémoire stable
• Rolling KV Cache : compression automatique du cache avec une fenêtre glissante de 8192 positions, permettant de traiter de l’audio de longueur illimitée

Utilisation

• Commandes de base
  • ./voxtral -d voxtral-model -i audio.wav : reconnaissance vocale à partir d’un fichier
  • ./voxtral -d voxtral-model --from-mic : reconnaissance en temps réel depuis le microphone (macOS)
  • Les entrées dans divers formats audio sont possibles via un pipe ffmpeg
• Affichage des tokens alternatifs
  • L’option --alt <cutoff> permet d’afficher aussi des candidats à prononciation similaire
  • Plus la valeur cutoff est élevée, plus le nombre de candidats affichés est important
• Réglage de la latence (option -I)
  • Définit en secondes la fréquence d’appel de l’encodeur
  • Une valeur basse (ex. 0,5 s) réduit la latence mais augmente la charge GPU / une valeur élevée (ex. 5 s) améliore l’efficacité du traitement
  • La valeur par défaut est de 2,0 s ; 1,0 à 2,0 s est recommandé pour le streaming en temps réel

Structure de l’API C

• API de streaming fournie autour de vox_stream_t
  • feed() : entrée audio
  • get() : réception des tokens
  • finish() : traite l’audio restant
  • flush() : force le traitement du buffer
• vox_stream_set_alt() permet de configurer le nombre de tokens alternatifs
• La fonction vox_transcribe() permet aussi de traiter un fichier unique en mode batch

Téléchargement et configuration du modèle

• Téléchargement d’environ 8,9 Go de poids du modèle depuis HuggingFace
  • consolidated.safetensors (poids BF16)
  • tekken.json (vocabulaire du tokenizer)
  • params.json (configuration du modèle)
• Modèle sous licence Apache-2.0, code sous licence MIT

Benchmarks de performance

• Référence : Apple M3 Max (GPU 40 cœurs, 128 Go de RAM)
  • Backend MPS : encodeur 284 ms, décodeur 23,5 ms/étape
  • Backend BLAS : encodeur ~8 s, décodeur 335 ms/étape
• Moyenne de 31,6 ms/étape sur un audio de 60 secondes, soit environ 2,5 fois plus rapide que le temps réel
• Le décodeur exécute l’ensemble des opérations par token via un unique appel à un command buffer Metal

Architecture du modèle

• Modèle streaming voix-vers-texte de 4 milliards de paramètres (4B)
  • Encodeur audio : transformer causal à 32 couches, dimension 1280, 32 têtes, fenêtre 750
  • Adaptateur : Linear(5120→3072) → GELU → Linear(3072→3072)
  • Décodeur LLM : transformer à 26 couches (basé sur Ministral-3), dimension 3072, GQA (32 têtes / 8KV)
• Tokenizer Tekken, vocabulaire de 131 072 éléments
• Langues prises en charge : anglais, espagnol, français, portugais, hindi, allemand, néerlandais, italien, arabe, russe, chinois, japonais, coréen

Exigences mémoire

• Poids du modèle : 8,9 Go (mmap à la demande)
• Cache GPU : environ 8,4 Go (après conversion BF16→F16)
• KV cache : jusqu’à 1,8 Go (limité par la fenêtre glissante)
• Buffer de travail : environ 200 Mo

Build et plateformes

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

Licence

• Code : MIT
• Modèle : Apache-2.0
• Disponible en open source, modifiable et redistribuable par tous

[GN⁺]

Commentaires Hacker News

• J’utilise la STT (reconnaissance vocale) avec une combinaison de l’application open source Handy et de Parakeet V3
  Je n’ai encore rien vu qui dépasse cette combinaison en termes de vitesse et de précision. La transcription est presque instantanée, et la légère perte de précision ne pose pas vraiment problème grâce à la capacité de l’IA à comprendre le contexte
  J’ai essayé d’intégrer l’implémentation C de Voxtral dans Handy, mais sur un MacBook M1 Max (64 Go), la transcription était beaucoup trop lente. Je vais aussi tester d’autres implémentations

  • Handy est excellent, mais c’est dommage que la STT ne soit pas en temps réel et fonctionne plutôt par traitement par lots

• Je suis fan des projets voxtral.c et flux2.c de Salvatore
  J’espère qu’ils continueront à être optimisés comme options légères fonctionnant sans dépendances externes. Mais pour l’instant, c’est trop lent pour un usage réel (sur un AMD 7800X3D/Blas)
  Quand j’ai ajouté la fonction Voice Input de llms-py, le support de voxtype.io d’Omarchy offrait la meilleure UX, suivi de Whisper.cpp
  OpenAI Whisper est lent, mais reste une option de transcription locale fiable
  Et l’API Voxtral Transcription de Mistral m’a aussi impressionné par sa vitesse et son prix — à 0,003 $ par minute, c’est très rapide et très bon marché. Je pense que c’est le meilleur choix dans les environnements limités par le CPU ou le disque

  • Le modèle lui-même est excellent, mais trop volumineux pour l’inférence locale. Whisper medium est moins bon en qualité, mais meilleur en termes d’adaptation à l’environnement
    Je vais maintenant tester le nouveau modèle de transcription Qwen 0.6. Si les benchmarks se confirment, il a un fort potentiel pour évoluer vers une chaîne légère prenant en compte l’optimisation CPU seule et même la quantification 8bit
    Comme l’installation doit aussi être possible sur des serveurs loués comme chez Hetzner, je vais essayer des optimisations par ensembles Intel, AMD et ARM
  • J’ai besoin d’un retour visuel avec transcription pendant que je parle. Je me demande si voxtype le prend en charge
    Handy propose apparemment une fonction d’overlay, mais elle ne fonctionne pas sur mon système
  • Je vote pour la combinaison voxtype + modèle Whisper-base. C’est assez rapide et précis

• L’installation a été facile sous Linux, mais contrairement à Whisper.cpp ou Moonshine, la transcription en temps réel ne fonctionne pas encore
  L’option --from-mic n’est prise en charge que sur Mac, donc j’ai essayé de capturer l’audio avec ffmpeg, mais je n’ai pas réussi à connecter l’entrée micro
  Mon système semble ne pas avoir les spécifications suffisantes pour faire tourner le modèle par défaut.
  J’aimerais essayer le modèle voxtral-q4.gguf

  • Après test sous Linux, ce modèle est beaucoup trop lent pour la transcription en temps réel. Il lui a fallu une demi-journée pour traiter un fichier d’entrée de 12 minutes
  • Je voudrais capturer non seulement le micro, mais aussi l’audio du port moniteur, afin de traiter en pipeline la transcription en temps réel de l’audio web
    Comme l’enregistrement fonctionne avec Audacity ou OBS Studio, je pense que le temps réel devrait aussi être possible
  • Il se peut que cela fonctionne en lisant l’audio depuis un fichier avec ffmpeg puis en l’envoyant à voxtral
    Personnellement, j’essaierais probablement dans l’ordre file→ffmpeg→voxtral, puis mic→ffmpeg→file, et enfin mic→ffmpeg→voxtral

• Le titre indique CPU uniquement, mais en réalité, l’accélération GPU est également prise en charge. C’est clairement indiqué dans la description du dépôt

• Ce projet et son implémentation du runtime Rust sont en même temps sur la page principale de HN. La dynamique concurrentielle est intéressante

• Il existe aussi une implémentation de la version MLX → voxmlx

• Le domaine de la reconnaissance vocale (STT) m’intéresse beaucoup
  J’aimerais travailler sur des données mêlant différents accents et du vocabulaire spécialisé, mais je ne sais pas par où commencer pour entraîner un modèle avec le grand volume d’échantillons vocaux que je possède. Je serais preneur de conseils

• Je l’ai essayé sur un MacBook Pro M3 16 Go, ça se charge, mais ça se bloque ou c’est beaucoup trop lent

• Je trouve étrange qu’un travail qui pouvait se faire avec environ 200 Mo il y a 20 ans nécessite maintenant un modèle de 9 Go