DeepSeek V4 lokaal draaien: slim of tijdlek?
Local AI begint niet bij de GPU
De vraag “kan ik DeepSeek V4 lokaal draaien?” is logisch. Maar voor een bedrijf is het niet de eerste vraag. De betere vraag is: welk proces wil ik betrouwbaar laten draaien, wat mag het kosten en wie beheert het als de stack breekt?
De video van Digital Spaceport laat precies dat spanningsveld zien. Day-zero testen, vLLM-gedoe, wachten op quants of GGUF, en kijkers die blij zijn dat iemand anders eerst door de muur loopt. Dat is geen hobbydetail. Dat is praktijkbewijs.
“Kan het draaien?” is te smal
Een model lokaal starten is één ding. Het stabiel gebruiken in een workflow is iets anders. Zeker bij nieuwe modellen is de eerste week vaak rommelig: tooling loopt achter, quantized builds verschijnen later en documentatie verandert snel.
| Vraag | Hobbytest | Productiekeuze |
|---|---|---|
| Model starten | Krijg ik output? | Is latency voorspelbaar genoeg? |
| Hardware | Past het in VRAM? | Wat kost beheer per maand? |
| Quantization | Welke build werkt vandaag? | Welke build durf ik te ondersteunen? |
| Fallback | Ik probeer iets anders. | Workflow blijft gecontroleerd draaien. |
Daarom moet je lokale AI niet vergelijken met een API op “prijs per prompt” alleen. Je vergelijkt twee exploitatiemodellen. Bij een API betaal je provider-marge. Bij local AI betaal je beheerlast.
Wanneer local AI wél logisch wordt
Local AI kan heel logisch zijn. Vooral als data niet naar een externe API mag, als volumes voorspelbaar hoog zijn, of als je controle over kosten en latency belangrijker vindt dan de nieuwste frontier-output.
- Je verwerkt veel gevoelige interne data.
- Je hebt stabiele, herhaalbare taken met hoge volumes.
- Je kunt beheer en monitoring serieus organiseren.
- Je accepteert dat modelupdates werk veroorzaken.
- Je hebt een fallback als de lokale stack faalt.
De verborgen kosten van zelf hosten
Hardware is zichtbaar. Tijd is verraderlijker. Eén weekend stoeien met builds voelt gratis, tot je het naast klantwerk legt. Voor een ondernemer telt niet alleen wat de GPU kost, maar ook wat je team niet doet terwijl het systeem “bijna werkt”.
| Kostenpost | Wordt vaak vergeten | Waarom het telt |
|---|---|---|
| Setup-tijd | Drivers, builds, containers | Geen directe klantwaarde. |
| Monitoring | Latency, errors, queue | Nodig voor productiebetrouwbaarheid. |
| Updates | Nieuwe quants, breaking changes | Kan workflows onverwacht raken. |
| Fallback | Tweede model of API-route | Voorkomt stilstand. |
Dat maakt hosted API’s niet automatisch beter. Het maakt ze eenvoudiger te begroten. En soms is voorspelbaarheid precies wat je nodig hebt.
Local AI wordt snel een identiteitsding. Je bent vóór zelf hosten of vóór API’s. Dat is precies de verkeerde discussie. De juiste vraag is zakelijker: welk deel van je proces verdient eigen infrastructuur, en welk deel koop je beter in omdat beheer daar geen concurrentievoordeel oplevert?
Bij een marketingbureau, dealerholding of advieskantoor zit de waarde meestal niet in het compileren van inference-stacks. De waarde zit in betere leadopvolging, snellere dossiervorming, betere content en minder handwerk. Als local AI dat versnelt, prima. Als het vooral weekenden opeet, is het een dure hobby met RGB-verlichting.
Dat betekent niet dat API’s heilig zijn. Ook daar heb je vendor-risk, rate limits, datavragen en kosten. Maar een API verplaatst een deel van de beheerlast. Local AI haalt die last naar binnen. Soms is dat precies de bedoeling. Soms niet.
Mijn vuistregel: host lokaal waar controle aantoonbaar waarde oplevert. Gebruik een API waar snelheid, onderhoud en modelkwaliteit zwaarder wegen. En bouw je prompts, evaluaties en outputformaten zo dat je later niet opnieuw hoeft te beginnen.
Een simpele beslisboom voor B2B-teams
Begin niet bij DeepSeek, Qwen, Gemini of Claude. Begin bij de workflow. Is de taak gevoelig? Is het volume hoog? Is latency zichtbaar voor klanten? Is falen duur? Pas daarna kies je local, API of hybride.
- Beschrijf de workflow in één zin.
- Bepaal of data extern verwerkt mag worden.
- Schat volume, pieken en foutkosten.
- Test één local model en één API-model op dezelfde taak.
- Kies pas daarna de infrastructuurroute.
Dat klinkt minder stoer dan “we draaien alles zelf”. Maar het is wel hoe je voorkomt dat je AI-strategie verandert in een technische hobby. Koers. Brandpunt. Schalen. In die volgorde.
Voor veel teams is hybride uiteindelijk het meest logisch. Je draait gevoelige of voorspelbare taken lokaal, maar houdt een API achter de hand voor pieken, complexe prompts of momenten waarop je lokale stack niet stabiel genoeg is. Dat klinkt minder ideologisch, maar wel praktischer. Je koopt flexibiliteit waar nodig en controle waar het waarde heeft.
Leg die keuze vast voordat je gaat bouwen. Niet in een dik document, maar in een korte beslisnotitie: taak, data, volume, gewenste latency, foutkosten, beheerder en fallback. Als die velden leeg blijven, is de kans groot dat je vooral technologie aan het verzamelen bent. En technologie verzamelen is geen strategie. Het is een hobby met facturen.
En vergeet de menselijke kant niet. Iemand moet eigenaar zijn van de stack. Niet “IT”, niet “marketing”, maar een naam. Die persoon hoeft niet alles zelf te doen, maar bewaakt wel updates, kosten, incidenten en de vraag of local AI nog steeds de beste route is. Zonder eigenaar wordt local AI langzaam een black box in je eigen kantoor. Dat is ironisch genoeg precies het probleem dat veel teams met externe API’s wilden vermijden.
Kortom: reken beheer mee voordat je de eerste kaart koopt. Altijd.
