In het vorige artikel ging het over evalueren voordat je AI-infrastructuur koopt. Dat is geen losse stap vóór modelkeuze. Het vormt de basis onder die keuze. Zonder eigen testset kies je al snel het model met de bekendste naam, de hoogste benchmarkscore of de mooiste demo.
Dat is riskant. Een model kan indrukwekkend zijn in algemene benchmarks en toch slecht passen bij Nederlandse supportvragen, juridische documenten, tenantisolatie, structured output of je latency-eisen. Bij private inference komt daar nog iets bij: je kiest niet alleen een model, maar ook de manier waarop dat model draait.
Modelkeuze gaat daarom over meer dan parameters. Je kiest een combinatie van modeltype, licentie, contextlengte, quantization, runtime-instellingen, performance en beheer. Het beste model is meestal niet het grootste model. Het is het kleinste model dat je eigen evaluatie haalt, met voorwaarden die bij je organisatie passen.
Begin bij de taak, niet bij de modelnaam
De vraag is niet: welk model is het beste? De vraag is: welk gedrag heb je nodig?
Een classificatiemodel voor tickets heeft andere eisen dan een documentassistent voor contracten. Een interne zoekfunctie met RAG heeft andere zwakke plekken dan een code-assistent. Een SaaS-feature voor klanten moet anders worden getest dan een interne samenvatter voor medewerkers.
Begin daarom met een korte beschrijving van de workload:
- Wat moet het systeem doen: classificeren, samenvatten, zoeken, beantwoorden, extraheren, code schrijven of documenten verwerken?
- Welke data raakt het: publiek, intern, vertrouwelijk of gereguleerd?
- Is de toepassing realtime of mag het in batch?
- Moet de output creatief zijn of juist voorspelbaar?
- Wat is een harde fout: onjuiste bron, datalek, verkeerde JSON, te hoge latency of te hoge kosten?
Pas daarna wordt modelkeuze concreet. Een kleiner model kan prima zijn voor routing, extractie of een afgebakende RAG-flow. Voor complexe redeneertaken, code, multimodale input of lastige domeintaal kan een groter of gespecialiseerder model nodig zijn. Dat weet je pas na meten.
Open weights, commercieel model of hybride
Private inference betekent niet altijd dat je de modelgewichten zelf bezit of op eigen hardware draait. Er zijn meerdere routes.
Met open weights kun je een model zelf draaien op dedicated hardware, private cloud of een afgeschermde omgeving. Dat geeft veel controle over runtime, logging, netwerk, updates en kostenstructuur. Daar staat beheer tegenover: patching, security, monitoring, incidentrespons, licentiecontrole en evaluaties.
Een commercieel model kan ook in een private deployment worden gebruikt, bijvoorbeeld via een private endpoint, VPC of VNet en duidelijke contractuele afspraken over data. Je beheert dan niet de gewichten, maar wel de toegang, netwerkgrenzen en dataverwerking binnen de gekozen cloudomgeving.
Voor veel organisaties is hybride het meest logisch. Gevoelige of voorspelbare workloads draaien private. Zwaardere of minder gevoelige taken kunnen via een beheerd model lopen, zolang dataflow, logging en contracten kloppen.
Gebruik daarbij precieze taal. Noem een model niet automatisch open source omdat de gewichten beschikbaar zijn. Controleer of het om Apache 2.0, MIT, een community license, een custom model license of een commerciële dienst gaat. Voor SaaS-bedrijven zijn voorwaarden rond hosted services, distributie en afgeleide modellen geen detail.
Kies het kleinste model dat je evaluatie haalt
Grotere modellen kunnen meer, maar ze kosten ook meer. Ze vragen meer geheugen, hebben vaker hogere latency en beperken hoeveel gebruikers je tegelijk kunt bedienen. Bij self-hosting betekent dat direct meer GPU-capaciteit of strengere grenzen aan context en batchgrootte.
Een praktische aanpak is om niet meteen het grootste model te kiezen. Test een klein en een middelgroot model op dezelfde evaluatieset. Kijk waar het kleinere model faalt en of het grotere model die fouten echt oplost. Als het verschil vooral in algemene formulering zit, maar niet in taakscore, latency of betrouwbaarheid, is groter niet automatisch beter.
Voor een supportflow kan een kleiner instructmodel met goede retrieval beter werken dan een groot model met te veel irrelevante context. Voor juridische extractie kan juist een hogere precisie of groter model nodig zijn. Voor code kan een gespecialiseerd model beter passen dan een algemeen chatmodel.
De eval harness uit het vorige artikel hoort hier de doorslag te geven. Niet de modelnaam.
Context window is geen geheugen
Een groot contextvenster klinkt aantrekkelijk. 32K, 128K of meer geeft ruimte voor lange documenten, uitgebreide instructies en veel voorbeelden. Toch is context geen gratis geheugen.
Meer context betekent meer tokens. Dat verhoogt kosten en latency. Bij self-hosted inference groeit ook de KV-cache mee met het aantal tokens, batches en gelijktijdige requests. Een model dat technisch 128K context aankan, kan daardoor alsnog onpraktisch zijn voor een realtime SaaS-feature met veel gebruikers.
Gebruik lange context daarom bewust. Stop niet alles in de prompt omdat het past. Voor de meeste bedrijfsapplicaties is betere contextselectie belangrijker dan meer context. Denk aan goede chunking, metadatafilters, autorisatie per document, retrieval en reranking.
Een groot contextvenster is een buffer, geen architectuur.
Test Nederlands en domeintaal apart
Veel model cards noemen meertaligheid. Dat is nuttig, maar niet genoeg voor Nederlandse B2B-toepassingen.
Test met echte Nederlandse voorbeelden: supporttickets, e-mails, contractpassages, kennisbankartikelen, productspecificaties en branchespecifieke termen. Let niet alleen op grammatica. Beoordeel ook toon, jargon, Engelse leenwoorden, brongebruik en foutgedrag.
Bij RAG geldt hetzelfde voor embeddings en rerankers. Een sterk generatiemodel helpt niet als de juiste Nederlandse passages niet boven komen. Als de retrieval faalt, gaat het antwoord alsnog de verkeerde kant op.
Test daarom drie dingen apart:
- haalt het embeddingmodel de juiste documenten op?
- zet de reranker de beste passages bovenaan?
- geeft het generatiemodel een correct en bruikbaar antwoord?
Base, instruct, embeddings en rerankers
Een base model is niet simpelweg een chatbot zonder systeemtekst. Base models zijn vooral bedoeld als startpunt voor verdere training, onderzoek of specialisatie. Voor eindgebruikersapplicaties wil je meestal een instruct- of chatmodel, omdat dat getraind is om opdrachten te volgen en gesprekspatronen te hanteren.
Voor RAG is de generator maar één onderdeel van de keten. Je kiest ook een embeddingmodel en soms een reranker. Die drie hoeven niet van dezelfde leverancier te komen.
Een reranker kan in sommige gevallen meer opleveren dan een groter generatiemodel. Als het probleem is dat de verkeerde passages worden opgehaald, lost een groter LLM dat niet netjes op. Dan moet de zoeklaag beter.
Quantization: kleiner draaien, opnieuw meten
Quantization verlaagt de precisie waarin modelgewichten of cachedata worden opgeslagen. Daardoor past een model in minder RAM of VRAM en kan de throughput verbeteren. Maar quantization is geen gratis compressie.
Er zijn verschillende families, elk met een eigen inzetgebied:
- BF16 of FP16 als kwaliteitsbaseline, als je hardware dat aankan.
- GGUF met Q4, Q5, Q6 of Q8 voor llama.cpp, Ollama en lokale of hybride deployments.
- AWQ of GPTQ voor 4-bit GPU-serving wanneer VRAM knelt.
- FP8 op moderne datacenter-GPU's met passende runtime.
- Quantized KV-cache bij lange context en veel gelijktijdige requests.
Q4 kan genoeg zijn voor een eenvoudige assistent, maar te grof voor juridische extractie, code, tool-calling of Nederlandse domeintekst. Q5 of Q6 kan een betere balans zijn als kwaliteit belangrijker is dan maximale besparing. FP8 kan interessant zijn in datacenteromgevingen, maar is hardware- en runtime-afhankelijk.
De praktische aanpak: gebruik BF16 of FP16 als meetlat als dat kan. Test daarna de quantized varianten op dezelfde evaluatieset. Meet niet alleen geheugen en tokens per seconde, maar ook taakscore, hallucinations, structured output, brongebruik, taal en safety.
Let ook op calibration. AWQ, GPTQ, FP8 en importance matrices werken beter als de calibrationdata lijkt op de echte workload. Gebruik dus geen willekeurige Engelstalige voorbeelden als je productie draait op Nederlandse klantvragen of contractteksten.
Parameters bepalen gedrag
Zelfs met hetzelfde model en dezelfde quantization kan de toepassing anders aanvoelen door parameters.
Temperature, top-p en top-k bepalen hoeveel variatie het model mag gebruiken. Voor classificatie, extractie, JSON-output en RAG-antwoorden wil je meestal lage randomness. Voor creatieve tekst mag meer variatie nuttig zijn, maar dan accepteer je ook minder reproduceerbaarheid.
Max tokens bepaalt hoeveel het model mag antwoorden. Dat is tegelijk een kosten- en latencyknop. Lange antwoorden zijn niet alleen duurder, ze houden ook capaciteit langer bezet.
Structured output verdient aparte aandacht. Voor integraties met databases, CRM, ticketsystemen of workflows is “geef alleen JSON terug” niet stevig genoeg. Gebruik JSON Schema of constrained decoding waar mogelijk. Dat scheelt parse-errors, retries en herstelcode.
Bij self-hosting komen daar runtimekeuzes bij: contextlengte, KV-cache, prefix caching, continuous batching, batchgrootte, tensor parallelism en runtimeversie. Die bepalen hoeveel gebruikers tegelijk bediend kunnen worden en hoe stabiel p95 en p99 latency blijven.
Reproduceerbaarheid is ook geen absolute garantie. Een seed helpt, maar hardware, backendversie, scheduling en online batching kunnen verschillen veroorzaken. Pin daarom modelversie, parameters, prompttemplate, runtime en hardwareprofiel in je evaluatieresultaten.
Een praktisch keuzeproces
Een goed keuzeproces hoeft niet groot te zijn. Het moet vooral herhaalbaar zijn.
- Beschrijf de workload, dataklasse en foutgrenzen.
- Bepaal of je open weights, commercieel model of hybride route wilt testen.
- Controleer licentie, hosted-service voorwaarden en dataverwerking.
- Test een klein en een middelgroot instructmodel op je eigen evaluatieset.
- Test Nederlands, domeintaal, RAG-retrieval en structured output apart.
- Draai een baseline en een of meer quantized varianten.
- Zet parameters per use case vast, niet als globale default.
- Meet latency, throughput, kosten en foutgedrag onder echte belasting.
- Leg model, quant, runtime, parameters en evalversie vast.
Zo wordt modelkeuze minder gevoelig voor hype. Je kunt uitleggen waarom een model is gekozen, wanneer het moet worden herzien en welke signalen op een regressie wijzen.
Conclusie
Private inference begint niet met de vraag welk model het populairst is. Het begint met je workload, data-eisen en acceptatiecriteria.
Als je die helder hebt, kun je modelgrootte, licentie, context, quantization en parameters vergelijken. Dan wordt modelkeuze een onderbouwde infrastructuurbeslissing in plaats van een gok op basis van demo's.
Wil je private inference serieus inzetten? cloud.nl kan helpen om workload, data-eisen, modelkeuze en infrastructuur samen te brengen, zodat je niet begint bij hardware kopen maar bij een keuze die technisch en operationeel klopt.