Wat whisper.cpp echt is (en wat niet)
Toen OpenAI Whisper uitbracht in september 2022, was de referentie-implementatie een Python-pakket gebouwd op PyTorch. Het werkte, maar het droeg de volledige PyTorch-afhankelijkheidsboom van ongeveer 2 GB, had CUDA nodig voor enige redelijke snelheid, en was lastig te leveren in een desktopapp.
Georgi Gerganov, een Bulgaarse software-ingenieur met een achtergrond in fysicasimulaties, bracht whisper.cpp uit in oktober 2022. Het project herschrijft de Whisper-inferentielus in C++ met een aangepaste tensorbibliotheek genaamd GGML. Het resultaat is een op zichzelf staande binary die standaard geen Python, geen PyTorch, geen CUDA-runtime linkt. Het draait op een Raspberry Pi 4, een iPhone, een MacBook Air uit 2015, of een tot het uiterste gedreven Threadripper, en produceert dezelfde transcripten als OpenAI’s Python-referentie tot op afrondingsfouten na.
whisper.cpp is geen ander model. De neuralenetwerk-architectuur is identiek: een encoder-Transformer van 12 of 24 lagen gevolgd door een decoder-Transformer van 12 of 24 lagen, afhankelijk van de grootte. Wat veranderde is het formaat van de gewichten, de runtime die de matrixvermenigvuldigingen uitvoert, en de afwezigheid van Python in het implementatiepad.
Het praktische effect is dat elke applicatie die Whisper zonder internettoegang wil draaien whisper.cpp statisch kan linken en een op zichzelf staand uitvoerbaar bestand kan leveren. SnailText doet dit voor offline dicteren op Mac en Windows. MacWhisper doet dit. SuperWhisper in lokale modus doet dit. Drie jaar na de start van het project is whisper.cpp snel genoeg voor realtime dicteren op een telefoon.
whisper.cpp vs openai-whisper - het zijn twee verschillende dingen
Mensen die nieuw zijn met whisper.cpp komen vaak vanuit Python. Ze hebben pip install openai-whisper gebruikt, whisper audio.mp3 --model base gedraaid, en het werkte. Nu proberen ze de C++-tegenhanger te vinden en lopen ze tegen verwarring aan.
Het korte antwoord: er is geen pip install whisper.cpp. De twee projecten hebben niets met elkaar te maken in hun leveringsformaat.
openai-whisper is de Python-referentie-implementatie die OpenAI onderhoudt. Het installeert via pip, vereist PyTorch, en roept CUDA aan voor GPU-versnelling. Het is de canonieke implementatie voor serverzijdige verwerking en onderzoek.
whisper.cpp is een aparte C++-codebase die hetzelfde neurale netwerk draait, vanaf nul geschreven door Georgi Gerganov. Het wordt vanuit de bron gecompileerd en geleverd als binary of statische bibliotheek. Er is geen pip-pakket. De manier waarop je het gebruikt is ofwel het zelf compileren (git clone https://github.com/ggerganov/whisper.cpp && make), ofwel een desktopapplicatie gebruiken die het voorgecompileerd meelevert.
De modelbestanden zijn ook verschillend. openai-whisper downloadt .pt-bestanden (PyTorch-checkpoints). whisper.cpp gebruikt zijn eigen binaire formaat — oudere bestanden gebruiken de .bin-extensie met het GGML-formaat (bijv. ggml-base.bin), nieuwere de .gguf-extensie. Als je een PyTorch .pt-bestand in whisper.cpp probeert te laden, faalt het met een header-mismatch-fout.
Waar je de whisper.cpp-modelbestanden vandaan haalt: ze worden gedistribueerd op Hugging Face onder de ggerganov/whisper.cpp-repository. De naamgevingsconventie is ggml-<grootte>.bin voor de standaard Q5_1-gekwantiseerde versies:
| Bestand | Model | Grootte op schijf | Goed voor |
|---|---|---|---|
ggml-tiny.bin | Whisper Tiny | 77 MB | Raspberry Pi, embedded, laagste latency |
ggml-base.bin | Whisper Base | 148 MB | Snelle laptops, alleen-CPU-gebruik |
ggml-small.bin | Whisper Small | 488 MB | Goede balans van snelheid en nauwkeurigheid |
ggml-medium.bin | Whisper Medium | 1,5 GB | Hoge nauwkeurigheid op GPU |
ggml-large-v3.bin | Whisper Large-v3 | 3,1 GB | Beste nauwkeurigheid, GPU nodig |
Als je een desktopapplicatie bouwt die whisper.cpp meelevert, bundel je doorgaans een of meer van deze bestanden als onderdeel van je installer. SnailText, bijvoorbeeld, biedt een model-kiesinterface — de gebruiker selecteert een grootte, de app downloadt het juiste .bin-bestand van onze CDN, en plaatst het in de applicatiedatamap.
Als je een serverzijdige Python-pijplijn bouwt, zijn openai-whisper of faster-whisper (dat CTranslate2 gebruikt) idiomatischer. whisper.cpp is de juiste keuze voor desktopapps, embedded systemen, en alles dat een op zichzelf staande binary zonder Python moet leveren.
GGML - de tensorbibliotheek die de eigenlijke wiskunde doet
GGML is een kleine C-bibliotheek (ongeveer 30.000 regels halverwege 2026) die vier dingen regelt: een bestandsformaat voor geserialiseerde neuralenetwerk-gewichten, een grafiekrepresentatie voor de reeks bewerkingen die een netwerk uitvoert, een CPU-uitvoeringsbackend met handmatig afgestelde SIMD-kernels, en een set GPU-backends (Metal, CUDA, Vulkan, ROCm, SYCL) die de matrixvermenigvuldigingen delegeren aan hardwareversnellers wanneer er een beschikbaar is.
Het bestandsformaat - nu GGUF genoemd sinds augustus 2023, ter vervanging van het oudere GGML-formaat - is één binair bestand dat de architectuurmetadata, het vocabulaire, en de gekwantiseerde gewichtstensoren van het model bevat in een indeling ontworpen voor geheugen-gemapte toegang. Wanneer whisper.cpp een model laadt, alloceert het geen gigabytes RAM en kopieert het de gewichten niet in. Het roept mmap aan (of het Windows-equivalent) en laat het besturingssysteem gewichten in het geheugen pagen zodra de kernel ze echt aanraakt. Op een systeem met veel RAM belandt het bestand effectief volledig in de cache. Op een krap systeem pagert het OS koude lagen uit en houdt het hete residents. Hoe dan ook hoeft GGML dat niet zelf te beheren.
Het uitvoeringsmodel is een gerichte acyclische grafiek. Vóór de eerste inferentie bouwt GGML een grafiekknooppunt voor elke tensorbewerking die Whisper uitvoert: de multi-head self-attention, de feed-forward MLP’s, de cross-attention tussen encoder en decoder, de finale softmax. De grafiek wordt één keer gecompileerd. Bij elke inferentie loopt GGML door de grafiek en dispatched het elk knooppunt naar de geselecteerde backend. De dispatch gebeurt op de granulariteit van een tensorbewerking, niet de hele grafiek, wat betekent dat een GPU-backend die een exotische bewerking niet ondersteunt kan terugvallen op CPU voor alleen die bewerking zonder de rest van de GPU-versnelling te verliezen.
INT8- en INT4-kwantisering - hoe een model van 1,5 GB 600 MB wordt zonder uit elkaar te vallen
Het Whisper Large-model, in zijn originele FP16 PyTorch-vorm, is ruwweg 3 GB op schijf. Whisper Small is rond 480 MB. Whisper Tiny is rond 75 MB. Dit zijn de FP16-cijfers uit OpenAI’s release.
GGML slaat deze modellen op in gekwantiseerde formaten. De standaard voor productiegebruik is Q5_1, wat betekent dat elk gewicht met ongeveer 5,5 bits gemiddeld wordt gecodeerd in plaats van 16. Het resultaat is een ruwweg 3-4x reductie in schijfgrootte en een vergelijkbare reductie in RAM-gebruik. Whisper Large in Q5_1 past in 1,2 GB. Whisper Small past in ruwweg 250 MB. Dit is wat het realistisch maakt om Whisper te leveren als onderdeel van een desktopapplicatie-installer.
De truc zit in hoe de bits worden toegewezen. Naïeve kwantisering - gewoon elk FP16-gewicht afkappen naar zijn dichtstbijzijnde INT8-waarde - vernietigt de nauwkeurigheid. De transformer-architectuur is gevoelig voor gewichtsomvang, en uniforme kwantisering produceert genoeg fout per laag zodat, vermenigvuldigd over 24 lagen, het model gewoon onzin produceert.
GGML gebruikt blokgewijze kwantisering met schaalfactoren per blok. De gewichten worden opgesplitst in kleine blokken (typisch 32 gewichten per blok), de maximale absolute waarde van elk blok wordt berekend, en de gewichten worden geschaald om in het beschikbare bitbudget te passen. Een kleine drijvende-komma-schaalfactor wordt naast elk blok opgeslagen. Bij dekwantisering worden de gehele waarden terugvermenigvuldigd met de schaal om een benadering van het originele FP16 te herstellen. Voor sommige kwantisatieformaten wordt ook een tweede offsetwaarde per blok opgeslagen om gewichten met asymmetrische distributies te verwerken.
Het Q5_1-formaat dat de meeste productie-whisper.cpp-implementaties gebruiken slaat 5-bits gehele getallen per gewicht op, een 4-bits nulpunt per blok, en een FP16-schaal per blok. De effectieve bits-per-gewicht inclusief alle overhead is ongeveer 5,5. Ter vergelijking: Q4_0 is rond 4,5 bits per gewicht en Q8_0 rond 8,5 bits per gewicht.
De nauwkeurigheidskost is meetbaar maar klein. Op de LibriSpeech-testset voor schone spraak scoort Whisper Small in FP16 ongeveer 3,4% woordfoutpercentage (volgens het originele Whisper-paper, Tabel 2). Hetzelfde model in Q5_1 scoort ongeveer 3,5-3,7% afhankelijk van de build. In Q4_0 verbreedt de kloof tot ongeveer 0,3-0,5 procentpunt. Onder Q4 begint de kloof uit te maken, en onder Q3 krijg je merkbare achteruitgang op spraak met accent.
Productie-implementaties (SnailText inbegrepen) leveren bijna altijd standaard Q5_1. Het is het formaat met de beste afweging tussen grootte en nauwkeurigheid voor compacte-tot-middelgrote Whisper-varianten. De volledige Q5_1-modelbestanden voor Whisper Tiny tot Large-v3 zijn beschikbaar op Hugging Face onder ggerganov/whisper.cpp.
De drie GPU-backends, en waarom ze allemaal bestaan
CPU-inferentie werkt op elke machine maar is het traagste pad. Een moderne laptop-CPU kan Whisper Small draaien op ruwweg 1,5-2x realtime, wat betekent dat een opname van 10 seconden in ongeveer 5-7 seconden transcribeert. Voor dicteren, waar de gebruiker verwacht de tekst binnen een seconde na het afronden van de zin te zien, is dat te traag.
GPU-versnelling is het pad naar sub-seconde latency, en whisper.cpp ondersteunt drie serieuze GPU-backends.
Metal is Apple’s GPU-API. Op elke Mac met Apple Silicon (M1 en later) heeft de M-serie-chip een unified-memory-architectuur waar de GPU hetzelfde RAM deelt als de CPU. Dit is ongebruikelijk. Op x86-systemen met aparte GPU’s moet je data van systeem-RAM naar GPU-VRAM kopiëren voordat de GPU die kan aanraken, en de resultaten terugkopiëren als hij klaar is. Op Apple Silicon is er geen kopie. De GPU en CPU lezen dezelfde fysieke geheugenpagina’s. Het praktische effect is dat door Metal ondersteunde whisper.cpp op een M2 of M3 een clip van 10 seconden in ongeveer 0,4-0,8 seconden transcribeert voor Whisper Small. M4 is opnieuw sneller. De Metal-backend werd bijgedragen door Apple-ingenieurs en is de meest verzorgde van de drie.
CUDA is NVIDIA’s GPU-API. Het is het originele GPU-computeplatform, daterend uit 2007, en blijft de snelste backend qua absolute doorvoer voor grote modellen op een toegewijde NVIDIA-kaart. Een RTX 4070 transcribeert Whisper Large-v3 ruim onder realtime. Het nadeel is dat CUDA alleen op NVIDIA-hardware draait (geen AMD, geen Intel, geen geïntegreerde graphics) en vereist dat de gebruiker de CUDA Toolkit heeft geïnstalleerd, een download van meerdere gigabytes en een wrijvingspunt voor eindgebruikers. whisper.cpp ondersteunt CUDA maar het is doorgaans niet de standaard-backend in applicaties gericht op consumenten.
Vulkan is de cross-vendor GPU-API. Het werkt op NVIDIA, AMD, Intel Arc, geïntegreerde AMD-graphics, geïntegreerde Intel-graphics, en ARM Mali-GPU’s. De Vulkan-backend in GGML en whisper.cpp kwam uit in 2024 en rijpte snel door 2025-2026. Op een aparte RTX-kaart is Vulkan ruwweg 70-90% van de snelheid van CUDA voor dezelfde werklast. Op AMD- en Intel-hardware, waar CUDA geen optie is, is Vulkan het enige betekenisvolle pad naar versnelling. De Vulkan-backend is wat SnailText levert voor spraak naar tekst op Windows omdat het ons één binary laat produceren die GPU-versnelt op elke moderne laptop zonder de gebruiker te vragen drivers te installeren.
Er is ook ROCm (AMD’s CUDA-equivalent) en SYCL (Intels compute-stack). Beide werken in whisper.cpp maar hebben betekenisvol kleinere gebruikersbestanden.
whisper.cpp bouwen op Windows 11 met CUDA of Vulkan
De upstream README dekt Linux het duidelijkst. Dit is wat de Windows-build echt vereist.
Vereisten voor elke Windows-build:
- Visual Studio 2022 met de “Desktop development with C++“-workload (levert MSVC en cmake)
- Git voor Windows
CUDA-build (NVIDIA-kaarten):
Installeer de CUDA Toolkit 12.x van NVIDIA’s site — het is een aparte download van de driver. Dan:
git clone https://github.com/ggerganov/whisper.cpp
cd whisper.cpp
cmake -B build -DGGML_CUDA=ON
cmake --build build --config ReleaseDe resulterende build/bin/Release/whisper.exe gebruikt CUDA. Je kunt het verifiëren met --list-backends — het zou CUDA in de uitvoer moeten rapporteren.
Vulkan-build (AMD, Intel, of elke GPU zonder CUDA):
Installeer de Vulkan SDK en zorg dat VULKAN_SDK in je omgeving is ingesteld. Dan:
cmake -B build -DGGML_VULKAN=ON
cmake --build build --config ReleaseVulkan werkt ook op NVIDIA — het is de veiligere standaard als je één binary wilt die op elke moderne Windows-GPU draait. Consumentenapps leveren doorgaans Vulkan in plaats van CUDA om te vermijden dat de CUDA Toolkit op de machine van de eindgebruiker vereist is.
Modeldownload:
Beide builds verwachten .bin-modelbestanden in GGML-formaat van de ggerganov/whisper.cpp-repo op HuggingFace. Download ggml-base.bin (148 MB) om te testen, ggml-large-v3.bin (3,1 GB) voor maximale nauwkeurigheid.
Hoe de productiecijfers zich vertalen naar gebruikerservaring
De benchmarktabel hierboven toont de end-to-end-tijden die we meten op gangbare consumentenhardware-configuraties. Drie observaties zijn het benoemen waard.
Ten eerste, M-serie-Macs halen interactieve latency (onder een seconde voor korte dicteerzinnen) op elk model behalve Large, zelfs zonder aparte GPU, dankzij unified memory. Ten tweede, de Vulkan-backend op een moderne NVIDIA-kaart zit binnen 25-30% van CUDA, wat dicht genoeg is dat het gemak van geen CUDA-installatie wint voor consumentenapps. Ten derde, alleen-CPU op een recente Intel-laptop is snel genoeg voor incidenteel gebruik maar niet snel genoeg om direct aan te voelen.
Streaming - transcripten krijgen voordat de gebruiker klaar is met praten
De cijfers hierboven zijn end-to-end-latency: druk op de stoptoets, wacht op het resultaat. Er is een tweede modus, streaming, waar whisper.cpp de audio in stukken transcribeert terwijl de gebruiker nog praat. Het resultaat verschijnt binnen een paar honderd milliseconden nadat de gebruiker stopt, omdat het grootste deel van het werk al gedaan is.
Streaming vereist twee dingen. Een spraakactiviteitsdetectie-model (VAD) dat identificeert wanneer een zin is geëindigd (de meeste productie-implementaties gebruiken Silero VAD, een klein ONNX-model dat in milliseconden draait). En een manier om voltooide zinnen aan Whisper te voeren zodra ze gebeuren, zonder het model te herstarten.
whisper.cpp ondersteunt beide. Het standaardpatroon is: open de audiostroom, draai VAD continu, verzamel samples totdat VAD meldt dat de gebruiker heeft gepauzeerd, dispatch dan dat stuk naar Whisper terwijl je blijft opnemen. Elk stuk transcribeert onafhankelijk. Wanneer de gebruiker op de stoptoets drukt, hoeft alleen het laatste gedeeltelijke stuk getranscribeerd te worden - de eerdere stukken zijn al klaar.
SnailText gebruikt dit patroon waar de hardware er baat bij heeft - voor een typisch dictaat van 30 seconden op machines met GPU ziet de gebruiker het resultaat binnen een seconde of twee na het stoppen, omdat het grootste deel van de inferentie tijdens de opname zelf gebeurde. Streaming is echter niet gratis: het voegt overhead toe die zich terugverdient wanneer individuele inferentierondes goedkoop zijn, en minder (of niet) wanneer dat niet zo is. Of je het inschakelt voor een gegeven configuratie is het soort beslissing dat productietelemetrie vereist in plaats van een vuistregel.
Het GPU-selectieprobleem waar niemand je voor waarschuwt
Op een laptop met zowel Intel- als NVIDIA-GPU’s kan whisper.cpp stilletjes terugvallen op CPU zelfs wanneer de toegewijde GPU beschikbaar is. De Vulkan-backend is prachtig in theorie: één binary, elke GPU, werkt gewoon. In de praktijk is er een klasse probleem die in geen enkele documentatie staat, en die je alleen tegenkomt door te leveren aan echte consumentenhardware.
Op een laptop met meerdere GPU’s - NVIDIA Optimus, AMD Switchable Graphics, geïntegreerd plus toegewijd - somt het besturingssysteem ze op in één volgorde. De grafische API’s sommen ze op in verschillende volgordes, soms in onenigheid met elkaar en soms verschuivend afhankelijk van de driverstaat. De Vulkan-backend van whisper.cpp adresseert een gekozen apparaat via een geheeltallige index, en het gehele getal dat naar de aparte kaart wijst in de ene API kan naar de geïntegreerde GPU wijzen in een andere.
Het symptoom is een stille terugval op CPU. Je denkt dat de GPU wordt gebruikt. De applicatie rapporteert dat de GPU wordt gebruikt. De systeemmonitor toont nul GPU-activiteit. Inferentie kost 20 seconden in plaats van 2.
De klasse oplossing die standhoudt over dit soort heterogeniteit is empirisch in plaats van voorspellend: probeer niet te raden welke apparaatindex overeenkomt met een echte GPU, meet het. Draai een snelle test-inferentie en beslis op basis van de waargenomen prestaties of je dat apparaat houdt of terugvalt op het volgende. Het diagram hieronder schetst de vorm van de lus.
Op machines met één GPU bevestigt dit gewoon het voor de hand liggende in een fractie van een seconde bij het opstarten. Op multi-GPU-laptops routet het de inferentie naar de aparte kaart zelfs wanneer de systeemopsomming misleidend is. Er zijn verscheidene randgevallen die je in deze laag beetnemen - dubbele opsomming-invoeren op sommige geïntegreerde GPU’s, vendorspecifieke driver-eigenaardigheden, gedeelde-geheugen-iGPU’s die andere latencybudgetten nodig hebben om valse negatieven te vermijden - en elk daarvan heeft zijn eigen behandeling nodig. De algemene les is dat GPU-selectie op consumenten-Windows-hardware een probleem is dat je alleen kunt oplossen door te kijken hoe je build zich gedraagt op echte machines en paden toe te voegen voor de gevallen die telemetrie naar boven haalt.
Niets hiervan staat in de whisper.cpp-docs of de GGML-repo-issues. Het is het soort werk dat “we ondersteunen Vulkan” verandert in iets waar een niet-technische gebruiker niet over hoeft na te denken.
Faalcategorieën die je alleen in productie ziet
Probe-and-fallback was één voorbeeld van een bredere categorie — productie-specifieke faalmodi waar de upstream-documentatie je niet voor waarschuwt. Elk van deze kostte ons telemetrie van echte gebruikers om zelfs op te merken; we noemen ze hier als categorieën in plaats van recepten omdat de juiste oplossing in elk geval van je specifieke stack afhangt, en wat voor ons werkte is niet het enige geldige pad.
1. Multi-GPU-opsommingsonenigheid. Hierboven behandeld. De vorm: verschillende grafische API’s op dezelfde machine zijn het oneens over welke geheeltallige index naar welke fysieke GPU wijst. De klasse oplossing: empirisch sonderen in plaats van voorspellende selectie. De versie van dit probleem die je tegenkomt hangt af van welk OS, welke driverstaat, en of de machine hybride graphics heeft — de klasse oplossing generaliseert.
2. Fantoom-opsomming van geïntegreerde GPU. Op sommige geïntegreerde-GPU-configuraties toont de Vulkan-loader meerdere invoeren die allemaal naar dezelfde onderliggende fysieke adapter wijzen. Inferentie tegen elk daarvan om beurten draaien — wat een naïeve probe-and-fallback doet — kan de gedeelde-geheugenbandbreedte verzadigen op manieren die niet alleen traag maar actief destabiliserend zijn. De klasse oplossing: identificeer de fysieke adapter-identiteit voordat je door indexen itereert, zodat een sondeerlus nooit per ongeluk dezelfde hardware meerdere keren bestookt.
3. Vulkan koude-shader-compilatie. Eerste-keer-GPU-initialisatie op een verse driverstaat kan veel langer duren dan de steady-state-inferentie suggereert. We hebben koude-shader-compileertijden zien oprekken van één seconde op warme hardware tot tientallen seconden op koude hardware. De klasse oplossing: maak time-outs adaptief aan of de GPU recent is gebruikt, niet hard-gecodeerd op één drempel.
4. GPU-geheugendruk onder streaming. Streaming-inferentie betekent dat meerdere Whisper-aanroepen in snelle opeenvolging gebeuren in plaats van één grote batch. Op GPU’s met beperkte of gedeelde VRAM (geïntegreerde graphics, mobiele NVIDIA-chips met TDR ingeschakeld) kunnen rug-aan-rug-aanroepen driver-niveau-herstel triggeren — het OS reset de GPU denkend dat de app is vastgelopen. De klasse oplossing: detecteer VRAM-beperkingen vooraf en schakel ofwel streaming uit ofwel throttle de aanroepsnelheid op apparaten die er niet klaar voor zijn.
5. Stille terugval op CPU. Over alle vier bovenstaande, de ergste faalmodus is dat whisper.cpp niets fout logt, de app de GPU als actief rapporteert, de systeemmonitor het eens is, en de inferentie tien of twintig keer langer duurt dan zou moeten. De klasse oplossing is dezelfde: vertrouw geen metadata over of je op GPU zit — meet de latency op een echte werklast en beslis op basis van de meting.
De rode draad is dat GPU-versnelling op consumentenhardware een probleem is dat je alleen volledig kunt oplossen door te leveren aan echte gebruikers en de telemetrie te bekijken. Geen van deze categorieën duikt op in een lokale-dev-omgeving met één goed begrepen grafische stack. Ze doken allemaal op op het moment dat we een paar duizend installaties hadden met verschillende vendors, generaties, en driverversies.
Waar je de ggml-modelbestanden downloadt (ggml-tiny.bin, ggml-base.bin, en de rest)
Als je hier belandde bij het zoeken naar ggml-tiny.bin pip install, hier is de korte versie: er is geen pip-pakket. ggml-tiny.bin is geen Python-module, het is een modelgewichtsbestand in het GGML-formaat. pip install zal het nooit vinden omdat het niet op PyPI staat. Het bestand staat op Hugging Face.
De canonieke bron is de ggerganov/whisper.cpp-repository op Hugging Face. Elk gekwantiseerd model staat er als directe download:
ggml-tiny.bin— Whisper Tiny, ~77 MB, snelst, laagste nauwkeurigheidggml-base.bin— Whisper Base, ~148 MBggml-small.bin— Whisper Small, ~488 MBggml-medium.bin— Whisper Medium, ~1,5 GBggml-large-v3.bin— Whisper Large v3, ~3,1 GB (of ~1,2 GB in Q5_1)
Je kunt er een van de commandoregel halen met het downloadscript dat in de whisper.cpp-repo meekomt (./models/download-ggml-model.sh tiny), of gewoon op het bestand op Hugging Face klikken. Zodra je de .bin hebt, geef je het pad ervan door aan de whisper.cpp-binary of aan welke wrapper je ook gebruikt. Er is geen installatiestap voor het model zelf; het is een statisch bestand waar je de runtime naartoe wijst.
Als je eigenlijke doel niet is whisper.cpp met de hand te bekabelen maar om te dicteren met een lokaal Whisper-model, kun je de hele download-en-configureer-dans overslaan. SnailText bundelt de modellen en de whisper.cpp-runtime in één installer voor Mac en Windows: het kiest een model dat bij je hardware past, downloadt het in de app indien nodig, en draait het offline. Geen .bin-jacht, geen buildstap, geen Python. Download het hier als dat dichter bij is wat je zocht.
Wat dit betekent voor wie vandaag op whisper.cpp bouwt
Als je whisper.cpp evalueert voor een product, is de kerncapaciteit solide. De modelnauwkeurigheid is goed, de kwantisatieformaten zijn goed begrepen, en het project wordt actief onderhouden door Gerganov en een open-source-gemeenschap van ongeveer 600 bijdragers in 2026.
De complexiteit zit in de lange staart. GPU-versnelling betrouwbaar laten werken over de diversiteit van consumentenhardware is een eigen engineeringproject. Het juiste streaminggedrag hangt af van de hardware voor je. Prompt-engineering (de initial_prompt-parameter) beïnvloedt materieel de nauwkeurigheid op domeinspecifiek vocabulaire, en heeft zijn eigen subtiliteiten afhankelijk van hoe je het gebruikt. Gedrag bij lange opnames heeft randgevallen die de standaardinstellingen niet gracieus verwerken. De standaardinstellingen zijn goed maar niet optimaal voor elk gebruik.
Voor een desktopdicteerapp is dat alles oplosbaar, en whisper.cpp blijft de beste fundering om het op op te lossen. Voor een serverzijdige transcriptiepijplijn op schaal zou je kunnen kijken naar faster-whisper (Python, CTranslate2-backend) of een van de cloud-API’s - het operationele profiel is anders. Voor embedded gebruik (Raspberry Pi, mobiel, edge-apparaten) zit whisper.cpp in een categorie van één.
De reden dat het project bestaat, en de reden dat SnailText, MacWhisper, SuperWhisper, en vele anderen erop bouwen, is dat het Whisper echt draagbaar maakt. Dezelfde C++-code draait op elk desktop-OS, elk modern mobiel OS, en een breed scala aan embedded doelen. Het model zelf is gewoon een bestand. De runtime is een statische bibliotheek. Er is geen Python, geen CUDA, geen dienst om aan te roepen. Dat is, in 2026, nog steeds een zeldzame combinatie.
Als je liever het resultaat gebruikt dan het bouwt, is dat precies wat wij leveren: SnailText draait whisper.cpp lokaal op Mac en Windows, kiest een model dat bij je hardware past, en blijft offline. Download het hier — gratis om te beginnen, geen account.