Ce qu’est réellement whisper.cpp (et ce qu’il n’est pas)
Quand OpenAI a publié Whisper en septembre 2022, l’implémentation de référence était un paquet Python bâti sur PyTorch. Ça marchait, mais ça traînait tout l’arbre de dépendances de PyTorch, environ 2 Go, avait besoin de CUDA pour toute vitesse raisonnable, et était pénible à embarquer dans une app de bureau.
Georgi Gerganov, un ingénieur logiciel bulgare avec un parcours en simulations physiques, a publié whisper.cpp en octobre 2022. Le projet réécrit la boucle d’inférence de Whisper en C++ à l’aide d’une bibliothèque de tenseurs personnalisée appelée GGML. Le résultat est un binaire autonome qui ne lie ni Python, ni PyTorch, ni runtime CUDA par défaut. Il tourne sur un Raspberry Pi 4, un iPhone, un MacBook Air de 2015, ou un Threadripper poussé à fond, et produit les mêmes transcriptions que la référence Python d’OpenAI à l’arrondi près.
whisper.cpp n’est pas un modèle différent. L’architecture du réseau de neurones est identique : un encoder Transformer de 12 ou 24 couches suivi d’un decoder Transformer de 12 ou 24 couches, selon la taille. Ce qui a changé, c’est le format des poids, le runtime qui exécute les multiplications de matrices, et l’absence de Python dans le chemin de déploiement.
L’effet pratique, c’est que toute application qui veut faire tourner Whisper sans accès internet peut lier statiquement whisper.cpp et livrer un exécutable autonome. SnailText le fait pour la dictée hors ligne sur Mac et Windows. MacWhisper le fait. SuperWhisper en mode local le fait. Trois ans après le début du projet, whisper.cpp est assez rapide pour la dictée temps réel sur un téléphone.
whisper.cpp vs openai-whisper - ce sont deux choses différentes
Les gens qui découvrent whisper.cpp arrivent souvent de Python. Ils ont utilisé pip install openai-whisper, lancé whisper audio.mp3 --model base, et ça a marché. Maintenant ils cherchent l’équivalent C++ et se heurtent à la confusion.
La réponse courte : il n’y a pas de pip install whisper.cpp. Les deux projets n’ont aucun rapport dans leur format de livraison.
openai-whisper est l’implémentation de référence Python qu’OpenAI maintient. Elle s’installe via pip, exige PyTorch, et appelle CUDA pour l’accélération GPU. C’est l’implémentation canonique pour le traitement côté serveur et la recherche.
whisper.cpp est une base de code C++ distincte qui fait tourner le même réseau de neurones, écrite de zéro par Georgi Gerganov. Elle se compile depuis les sources et se livre en binaire ou bibliothèque statique. Il n’y a pas de paquet pip. La façon de l’utiliser, c’est soit de le compiler vous-même (git clone https://github.com/ggerganov/whisper.cpp && make), soit d’utiliser une application de bureau qui l’embarque pré-compilé.
Les fichiers de modèle sont aussi différents. openai-whisper télécharge des fichiers .pt (checkpoints PyTorch). whisper.cpp utilise son propre format binaire — les anciens fichiers utilisent l’extension .bin au format GGML (par ex. ggml-base.bin), les plus récents l’extension .gguf. Si vous essayez de charger un fichier PyTorch .pt dans whisper.cpp, ça échoue avec une erreur de non-concordance d’en-tête.
Où obtenir les fichiers de modèle whisper.cpp : ils sont distribués sur Hugging Face dans le dépôt ggerganov/whisper.cpp. La convention de nommage est ggml-<taille>.bin pour les versions quantifiées Q5_1 par défaut :
| Fichier | Modèle | Taille sur disque | Idéal pour |
|---|---|---|---|
ggml-tiny.bin | Whisper Tiny | 77 Mo | Raspberry Pi, embarqué, latence la plus basse |
ggml-base.bin | Whisper Base | 148 Mo | Portables rapides, usage CPU seul |
ggml-small.bin | Whisper Small | 488 Mo | Bon équilibre vitesse et précision |
ggml-medium.bin | Whisper Medium | 1,5 Go | Haute précision sur GPU |
ggml-large-v3.bin | Whisper Large-v3 | 3,1 Go | Meilleure précision, GPU nécessaire |
Si vous construisez une application de bureau qui embarque whisper.cpp, vous fournissez généralement un ou plusieurs de ces fichiers dans votre installeur. SnailText, par exemple, propose une interface de choix de modèle — l’utilisateur sélectionne une taille, l’app télécharge le fichier .bin approprié depuis notre CDN, et le place dans le répertoire de données de l’application.
Si vous construisez un pipeline Python côté serveur, openai-whisper ou faster-whisper (qui utilise CTranslate2) sont plus idiomatiques. whisper.cpp est le bon choix pour les apps de bureau, les systèmes embarqués, et tout ce qui doit livrer un binaire autonome sans Python.
GGML - la bibliothèque de tenseurs qui fait les vrais calculs
GGML est une petite bibliothèque C (environ 30 000 lignes mi-2026) qui gère quatre choses : un format de fichier pour les poids sérialisés du réseau de neurones, une représentation en graphe pour la séquence d’opérations qu’un réseau effectue, un backend d’exécution CPU avec des kernels SIMD réglés à la main, et un ensemble de backends GPU (Metal, CUDA, Vulkan, ROCm, SYCL) qui délèguent les multiplications de matrices aux accélérateurs matériels quand il y en a un de disponible.
Le format de fichier - désormais appelé GGUF depuis août 2023, remplaçant l’ancien format GGML - est un fichier binaire unique qui contient les métadonnées d’architecture du modèle, le vocabulaire, et les tenseurs de poids quantifiés dans une disposition conçue pour l’accès en mémoire mappée. Quand whisper.cpp charge un modèle, il n’alloue pas des gigaoctets de RAM et n’y copie pas les poids. Il appelle mmap (ou l’équivalent Windows) et laisse le système d’exploitation pager les poids en mémoire à mesure que le kernel les touche réellement. Sur un système avec beaucoup de RAM, le fichier finit effectivement entièrement en cache. Sur un système serré, l’OS page les couches froides et garde les chaudes résidentes. Dans les deux cas, GGML n’a pas à gérer ça lui-même.
Le modèle d’exécution est un graphe orienté acyclique. Avant la première inférence, GGML construit un nœud de graphe pour chaque opération de tenseur que Whisper effectue : l’auto-attention multi-têtes, les MLP feed-forward, la cross-attention entre encoder et decoder, le softmax final. Le graphe est compilé une fois. À chaque inférence, GGML parcourt le graphe, dispatchant chaque nœud vers le backend sélectionné. Le dispatch se fait à la granularité d’une opération de tenseur, pas du graphe entier, ce qui veut dire qu’un backend GPU qui ne prend pas en charge une opération exotique peut se rabattre sur le CPU pour cette seule opération sans perdre le reste de l’accélération GPU.
Quantification INT8 et INT4 - comment un modèle de 1,5 Go devient 600 Mo sans s’effondrer
Le modèle Whisper Large, dans sa forme PyTorch FP16 d’origine, fait environ 3 Go sur disque. Whisper Small fait environ 480 Mo. Whisper Tiny environ 75 Mo. Ce sont les chiffres FP16 de la publication d’OpenAI.
GGML stocke ces modèles dans des formats quantifiés. Le format par défaut en production est Q5_1, ce qui veut dire que chaque poids est encodé avec environ 5,5 bits en moyenne au lieu de 16. Le résultat est une réduction d’environ 3-4× de la taille sur disque et une réduction similaire de l’usage RAM. Whisper Large en Q5_1 tient dans 1,2 Go. Whisper Small tient dans environ 250 Mo. C’est ce qui rend réaliste de livrer Whisper dans l’installeur d’une application de bureau.
L’astuce est dans comment les bits sont alloués. La quantification naïve - juste tronquer chaque poids FP16 à sa valeur INT8 la plus proche - détruit la précision. L’architecture transformer est sensible à l’amplitude des poids, et la quantification uniforme produit assez d’erreur par couche pour que, multipliée sur 24 couches, le modèle ne produise que du charabia.
GGML utilise une quantification par blocs avec des facteurs d’échelle par bloc. Les poids sont découpés en petits blocs (typiquement 32 poids par bloc), la valeur absolue maximale de chaque bloc est calculée, et les poids sont mis à l’échelle pour tenir dans le budget de bits disponible. Un petit facteur d’échelle en virgule flottante est stocké à côté de chaque bloc. À la déquantification, les valeurs entières sont remultipliées par l’échelle pour retrouver une approximation du FP16 original. Pour certains formats de quantification, une seconde valeur de décalage par bloc est aussi stockée pour gérer les poids à distribution asymétrique.
Le format Q5_1 utilisé par la plupart des déploiements whisper.cpp de production stocke des entiers de 5 bits par poids, un point-zéro de 4 bits par bloc, et une échelle FP16 par bloc. Les bits par poids effectifs, surcharge comprise, sont d’environ 5,5. À titre de comparaison, Q4_0 est d’environ 4,5 bits par poids et Q8_0 d’environ 8,5 bits par poids.
Le coût de précision est mesurable mais faible. Sur le jeu de test propre LibriSpeech, Whisper Small en FP16 obtient environ 3,4 % de taux d’erreur de mots (selon la publication Whisper originale, Table 2). Le même modèle en Q5_1 obtient environ 3,5-3,7 % selon la compilation. En Q4_0 l’écart se creuse à environ 0,3-0,5 point de pourcentage. Sous Q4 l’écart commence à compter, et sous Q3 vous obtenez une dégradation notable sur la parole accentuée.
Les déploiements de production (SnailText compris) livrent presque toujours Q5_1 par défaut. C’est le format au meilleur compromis taille/précision pour les variantes Whisper compactes à moyennes. Les fichiers de modèle Q5_1 complets pour Whisper Tiny à Large-v3 sont disponibles sur Hugging Face sous ggerganov/whisper.cpp.
Les trois backends GPU, et pourquoi ils existent tous
L’inférence CPU marche sur toutes les machines mais c’est le chemin le plus lent. Un CPU de portable moderne peut faire tourner Whisper Small à environ 1,5-2× le temps réel, ce qui veut dire qu’un enregistrement de 10 secondes se transcrit en environ 5-7 secondes. Pour la dictée, où l’utilisateur s’attend à voir le texte dans la seconde qui suit la fin de la phrase, c’est trop lent.
L’accélération GPU est le chemin vers une latence sous la seconde, et whisper.cpp prend en charge trois backends GPU sérieux.
Metal est l’API GPU d’Apple. Sur tout Mac Apple Silicon (M1 et après) la puce série M a une architecture à mémoire unifiée où le GPU partage la même RAM que le CPU. C’est inhabituel. Sur les systèmes x86 à GPU discret, vous devez copier les données de la RAM système vers la VRAM du GPU avant que le GPU puisse les toucher, et recopier les résultats une fois terminé. Sur Apple Silicon, il n’y a pas de copie. Le GPU et le CPU lisent les mêmes pages mémoire physiques. L’effet pratique, c’est que whisper.cpp adossé à Metal sur un M2 ou M3 transcrit un clip de 10 secondes en environ 0,4-0,8 seconde pour Whisper Small. Le M4 est encore plus rapide. Le backend Metal a été contribué par des ingénieurs Apple et est le plus abouti des trois.
CUDA est l’API GPU de NVIDIA. C’est la plateforme de calcul GPU d’origine, datant de 2007, et elle reste le backend le plus rapide en débit absolu pour les gros modèles sur une carte NVIDIA dédiée. Une RTX 4070 transcrit Whisper Large-v3 bien en dessous du temps réel. L’inconvénient, c’est que CUDA ne tourne que sur du matériel NVIDIA (pas d’AMD, pas d’Intel, pas de graphiques intégrés) et exige que l’utilisateur ait installé le CUDA Toolkit, qui est un téléchargement de plusieurs gigaoctets et un point de friction pour les utilisateurs finaux. whisper.cpp prend en charge CUDA mais ce n’est généralement pas le backend par défaut dans les applications ciblant le grand public.
Vulkan est l’API GPU multi-fournisseur. Elle fonctionne sur NVIDIA, AMD, Intel Arc, les graphiques intégrés AMD, les graphiques intégrés Intel, et les GPU ARM Mali. Le backend Vulkan dans GGML et whisper.cpp est sorti en 2024 et a mûri rapidement en 2025-2026. Sur une carte RTX discrète, Vulkan est à environ 70-90 % de la vitesse de CUDA pour la même charge. Sur du matériel AMD et Intel, où CUDA n’est pas une option, Vulkan est le seul chemin d’accélération significatif. Le backend Vulkan est ce que SnailText livre pour la voix vers texte sous Windows parce qu’il nous permet de produire un binaire unique qui accélère par GPU sur tout portable moderne sans demander à l’utilisateur d’installer des pilotes.
Il y a aussi ROCm (l’équivalent CUDA d’AMD) et SYCL (la pile de calcul d’Intel). Les deux fonctionnent dans whisper.cpp mais ont des bases d’utilisateurs nettement plus petites.
Compiler whisper.cpp sous Windows 11 avec CUDA ou Vulkan
Le README amont couvre le mieux Linux. Voici ce que la compilation Windows demande réellement.
Prérequis pour toute compilation Windows :
- Visual Studio 2022 avec la charge de travail « Développement Desktop en C++ » (fournit MSVC et cmake)
- Git pour Windows
Compilation CUDA (cartes NVIDIA) :
Installez le CUDA Toolkit 12.x depuis le site de NVIDIA — c’est un téléchargement séparé du pilote. Puis :
git clone https://github.com/ggerganov/whisper.cpp
cd whisper.cpp
cmake -B build -DGGML_CUDA=ON
cmake --build build --config ReleaseLe build/bin/Release/whisper.exe résultant utilise CUDA. Vous pouvez vérifier avec --list-backends — il devrait rapporter CUDA dans la sortie.
Compilation Vulkan (AMD, Intel, ou tout GPU sans CUDA) :
Installez le Vulkan SDK et assurez-vous que VULKAN_SDK est défini dans votre environnement. Puis :
cmake -B build -DGGML_VULKAN=ON
cmake --build build --config ReleaseVulkan fonctionne aussi sur NVIDIA — c’est le choix par défaut le plus sûr si vous voulez un binaire unique qui tourne sur tout GPU Windows moderne. Les apps grand public livrent généralement Vulkan plutôt que CUDA pour éviter d’exiger le CUDA Toolkit sur la machine de l’utilisateur final.
Téléchargement du modèle :
Les deux compilations attendent des fichiers de modèle .bin au format GGML depuis le dépôt ggerganov/whisper.cpp sur HuggingFace. Téléchargez ggml-base.bin (148 Mo) pour tester, ggml-large-v3.bin (3,1 Go) pour un maximum de précision.
Comment les chiffres de production se traduisent en expérience utilisateur
Le tableau de benchmarks ci-dessus montre les temps de bout en bout que nous mesurons sur des configurations matérielles grand public courantes. Trois observations méritent d’être signalées.
D’abord, les Mac série M atteignent une latence interactive (moins d’une seconde pour les phrases de dictée courtes) sur tous les modèles sauf Large, même sans GPU discret, grâce à la mémoire unifiée. Ensuite, le backend Vulkan sur une carte NVIDIA moderne est à 25-30 % de CUDA, ce qui est assez proche pour que le confort de ne pas installer CUDA l’emporte pour les apps grand public. Enfin, le CPU seul sur un portable Intel récent est assez rapide pour un usage occasionnel mais pas assez pour sembler instantané.
Streaming - obtenir les transcriptions avant que l’utilisateur ait fini de parler
Les chiffres ci-dessus sont la latence de bout en bout : appuyez sur la touche d’arrêt, attendez le résultat. Il y a un second mode, le streaming, où whisper.cpp transcrit l’audio par morceaux pendant que l’utilisateur parle encore. Le résultat apparaît dans les quelques centaines de millisecondes après que l’utilisateur s’arrête, parce que l’essentiel du travail est déjà fait.
Le streaming demande deux choses. Un modèle de détection d’activité vocale (VAD) qui identifie quand une phrase s’est terminée (la plupart des déploiements de production utilisent Silero VAD, un petit modèle ONNX qui tourne en millisecondes). Et un moyen de fournir les phrases terminées à Whisper à mesure qu’elles arrivent, sans redémarrer le modèle.
whisper.cpp prend en charge les deux. Le schéma standard : ouvrez le flux audio, faites tourner le VAD en continu, accumulez les échantillons jusqu’à ce que le VAD signale que l’utilisateur a fait une pause, puis dispatchez ce morceau vers Whisper tout en continuant d’enregistrer. Chaque morceau se transcrit indépendamment. Quand l’utilisateur appuie sur la touche d’arrêt, seul le dernier morceau partiel doit être transcrit - les morceaux précédents sont déjà faits.
SnailText utilise ce schéma là où le matériel en bénéficie - pour une dictée typique de 30 secondes sur une machine avec GPU, l’utilisateur voit le résultat dans la seconde ou deux qui suivent l’arrêt, parce que l’essentiel de l’inférence s’est fait pendant l’enregistrement lui-même. Le streaming n’est pas gratuit, cependant : il ajoute une surcharge qui paie quand les passes d’inférence individuelles sont peu coûteuses, et paie moins (ou pas du tout) quand elles ne le sont pas. Décider de l’activer pour une configuration donnée est le genre de décision qui demande de la télémétrie de production plutôt qu’une règle empirique.
Le problème de sélection GPU dont personne ne vous parle
Sur un portable avec GPU Intel et NVIDIA, whisper.cpp peut se rabattre silencieusement sur le CPU même quand le GPU dédié est disponible. Le backend Vulkan est merveilleux en théorie : un binaire, n’importe quel GPU, ça marche. En pratique il y a une classe de problème qui n’est dans aucune documentation, et que vous ne rencontrez qu’en livrant à du vrai matériel grand public.
Sur un portable à plusieurs GPU - NVIDIA Optimus, AMD Switchable Graphics, intégré plus dédié - le système d’exploitation les énumère dans un ordre. Les API graphiques les énumèrent dans des ordres différents, parfois en désaccord entre elles et parfois variant selon l’état du pilote. Le backend Vulkan de whisper.cpp adresse un appareil choisi par index entier, et l’entier qui pointe vers la carte discrète dans une API peut pointer vers le GPU intégré dans une autre.
Le symptôme est un repli silencieux sur le CPU. Vous croyez que le GPU est utilisé. L’application rapporte que le GPU est utilisé. Le moniteur système montre zéro activité GPU. L’inférence prend 20 secondes au lieu de 2.
La classe de solution qui tient face à ce genre d’hétérogénéité est empirique plutôt que prédictive : n’essayez pas de deviner quel index d’appareil correspond à un vrai GPU, mesurez-le. Lancez une inférence de test rapide et décidez, selon la performance observée, de garder cet appareil ou de vous rabattre sur le suivant. Le schéma ci-dessous esquisse la forme de la boucle.
Sur les machines à un seul GPU, ça ne fait que confirmer l’évident en une fraction de seconde au démarrage. Sur les portables multi-GPU, ça route l’inférence vers la carte discrète même quand l’énumération système est trompeuse. Il y a plusieurs cas limites qui vous piègent à cette couche - entrées d’énumération dupliquées sur certains GPU intégrés, bizarreries de pilote propres à un fournisseur, iGPU à mémoire partagée qui ont besoin de budgets de latence différents pour éviter les faux négatifs - et chacun de ceux-là demande son propre traitement. La leçon générale, c’est que la sélection GPU sur du matériel Windows grand public est un problème que vous ne pouvez résoudre qu’en observant comment votre build se comporte sur de vraies machines et en ajoutant des chemins pour les cas que la télémétrie fait remonter.
Rien de tout cela n’est dans la doc de whisper.cpp ni dans les issues du dépôt GGML. C’est le genre de travail qui transforme « on prend en charge Vulkan » en quelque chose à quoi un utilisateur non technique n’aura pas à penser.
Catégories de défaillance que vous ne voyez qu’en production
Le probe-and-fallback était un exemple d’une catégorie plus large — des modes de défaillance propres à la production dont la documentation amont ne vous prévient pas. Chacun de ceux-ci nous a demandé de la télémétrie de vrais utilisateurs pour même le remarquer ; nous les listons ici comme catégories plutôt que recettes parce que la bonne solution dans chaque cas dépend de votre pile spécifique, et ce qui a marché pour nous n’est pas le seul chemin valable.
1. Désaccord d’énumération multi-GPU. Couvert ci-dessus. La forme : différentes API graphiques sur la même machine sont en désaccord sur quel index entier pointe vers quel GPU physique. La classe de solution : sondage empirique plutôt que sélection prédictive. La version de ce problème que vous rencontrez dépend de l’OS, de l’état du pilote, et de si la machine a des graphiques hybrides — la classe de solution se généralise.
2. Énumération fantôme du GPU intégré. Sur certaines configurations à GPU intégré, le loader Vulkan expose plusieurs entrées qui pointent toutes vers le même adaptateur physique sous-jacent. Lancer l’inférence contre chacune d’elles à tour de rôle — ce que fait un probe-and-fallback naïf — peut saturer la bande passante de la mémoire partagée d’une façon qui n’est pas seulement lente mais activement déstabilisante. La classe de solution : identifier l’identité de l’adaptateur physique avant d’itérer sur les index, pour qu’une boucle de sondage ne martèle jamais accidentellement le même matériel plusieurs fois.
3. Compilation de shader à froid Vulkan. L’initialisation GPU pour la première fois sur un état de pilote frais peut prendre bien plus longtemps que ce que l’inférence en régime établi suggère. Nous avons vu des temps de compilation de shader à froid s’étirer d’une seconde sur du matériel chaud à des dizaines de secondes sur du matériel froid. La classe de solution : rendre les délais d’expiration adaptatifs selon que le GPU a été utilisé récemment, pas codés en dur à un seul seuil.
4. Pression sur la mémoire GPU en streaming. L’inférence en streaming signifie que plusieurs invocations de Whisper se produisent en succession rapprochée au lieu d’un gros lot. Sur les GPU à VRAM limitée ou partagée (graphiques intégrés, puces NVIDIA mobiles avec TDR activé), des invocations dos à dos peuvent déclencher une récupération au niveau du pilote — l’OS réinitialise le GPU en croyant que l’app a planté. La classe de solution : détecter les contraintes de VRAM d’emblée et soit désactiver le streaming, soit brider le taux d’invocation sur les appareils qui n’y sont pas prêts.
5. Repli silencieux sur le CPU. À travers les quatre cas ci-dessus, le pire mode de défaillance, c’est que whisper.cpp ne loggue rien d’anormal, l’app rapporte le GPU comme actif, le moniteur système est d’accord, et l’inférence prend dix ou vingt fois plus longtemps qu’elle ne devrait. La classe de solution est la même : ne faites pas confiance aux métadonnées sur le fait que vous êtes sur GPU — mesurez la latence sur une vraie charge et décidez selon la mesure.
Le fil conducteur, c’est que l’accélération GPU sur du matériel grand public est un problème que vous ne pouvez pleinement résoudre qu’en déployant à de vrais utilisateurs et en surveillant la télémétrie. Aucune de ces catégories n’apparaît dans un environnement de dev local avec une seule pile graphique bien comprise. Toutes sont apparues dès que nous avons eu quelques milliers d’installations avec des fournisseurs, générations, et versions de pilote différents.
Où télécharger les fichiers de modèle ggml (ggml-tiny.bin, ggml-base.bin, et le reste)
Si vous avez atterri ici en cherchant ggml-tiny.bin pip install, voici la version courte : il n’y a pas de paquet pip. ggml-tiny.bin n’est pas un module Python, c’est un fichier de poids de modèle au format GGML. pip install ne le trouvera jamais parce qu’il ne vit pas sur PyPI. Le fichier vit sur Hugging Face.
La source canonique est le dépôt ggerganov/whisper.cpp sur Hugging Face. Chaque modèle quantifié y est en téléchargement direct :
ggml-tiny.bin— Whisper Tiny, ~77 Mo, le plus rapide, précision la plus basseggml-base.bin— Whisper Base, ~148 Moggml-small.bin— Whisper Small, ~488 Moggml-medium.bin— Whisper Medium, ~1,5 Goggml-large-v3.bin— Whisper Large v3, ~3,1 Go (ou ~1,2 Go en Q5_1)
Vous pouvez en récupérer un en ligne de commande avec le script de téléchargement livré dans le dépôt whisper.cpp (./models/download-ggml-model.sh tiny), ou juste cliquer sur le fichier sur Hugging Face. Une fois que vous avez le .bin, vous passez son chemin au binaire whisper.cpp ou au wrapper que vous utilisez. Il n’y a pas d’étape d’installation pour le modèle lui-même ; c’est un fichier statique vers lequel vous pointez le runtime.
Si votre vrai but n’est pas de câbler whisper.cpp à la main mais de dicter avec un modèle Whisper local, vous pouvez sauter toute la danse télécharger-et-configurer. SnailText regroupe les modèles et le runtime whisper.cpp dans un seul installeur pour Mac et Windows : il choisit un modèle adapté à votre matériel, le télécharge dans l’app au besoin, et le fait tourner hors ligne. Pas de chasse au .bin, pas d’étape de compilation, pas de Python. Téléchargez-le ici si c’est plus proche de ce que vous cherchiez.
Ce que cela signifie pour qui construit sur whisper.cpp aujourd’hui
Si vous évaluez whisper.cpp pour un produit, la capacité de base est solide. La précision du modèle est bonne, les formats de quantification sont bien compris, et le projet est activement maintenu par Gerganov et une communauté open source d’environ 600 contributeurs en 2026.
La complexité est dans la longue traîne. Faire marcher l’accélération GPU de façon fiable sur la diversité du matériel grand public est un projet d’ingénierie à part entière. Le bon comportement de streaming dépend du matériel devant vous. L’ingénierie de prompt (le paramètre initial_prompt) affecte matériellement la précision sur le vocabulaire spécifique à un domaine, et a ses propres subtilités selon la façon dont vous l’utilisez. Le comportement en enregistrement long a des cas limites que les valeurs par défaut ne gèrent pas gracieusement. Les réglages par défaut sont bons mais pas optimaux pour chaque cas d’usage.
Pour une app de dictée de bureau, tout cela est résoluble, et whisper.cpp reste la meilleure fondation sur laquelle le résoudre. Pour un pipeline de transcription côté serveur à l’échelle, vous pourriez regarder faster-whisper (Python, backend CTranslate2) ou l’une des API cloud - le profil opérationnel est différent. Pour les cas d’usage embarqués (Raspberry Pi, mobile, appareils en périphérie), whisper.cpp est dans une catégorie à part.
La raison pour laquelle le projet existe, et la raison pour laquelle SnailText, MacWhisper, SuperWhisper, et bien d’autres construisent dessus, c’est qu’il rend Whisper réellement portable. Le même code C++ tourne sur tous les OS de bureau, tous les OS mobiles modernes, et une large gamme de cibles embarquées. Le modèle lui-même n’est qu’un fichier. Le runtime est une bibliothèque statique. Il n’y a pas de Python, pas de CUDA, pas de service à appeler. Ça, en 2026, reste une combinaison rare.
Si vous préférez utiliser le résultat plutôt que le construire, c’est exactement ce que nous livrons : SnailText fait tourner whisper.cpp en local sur Mac et Windows, choisit un modèle adapté à votre matériel, et reste hors ligne. Téléchargez-le ici — gratuit pour commencer, sans compte.