De markt voor taalmodellen is het afgelopen jaar zo drastisch veranderd dat de oude aanpak — kies één frontier-model en laat het alles doen — niet meer werkt. Vandaag beschikt u over open-weight modellen met een contextlengte van een miljoen tokens, cloud-API's met prijzen die de nul naderen, lokale deployments op één server en tientallen miljarden-parameter MoE-architecturen die kleiner zijn dan ze lijken. Tegelijkertijd geldt: een model kiezen zonder raamwerk is een loterij — niet vanwege de kwaliteit van de modellen, maar omdat de meeste beslissingen worden genomen zonder een heldere probleemstelling.
Dit artikel biedt een concreet beslissingsraamwerk. Vier dimensies — taak, infrastructuur, prijs en privacy — elk met een reeks filters die de kandidatenlijst terugbrengen tot twee of drie serieuze opties. De cijfers zijn afkomstig uit geverifieerde bronnen; waar cijfers onduidelijk zijn, zeggen we dat gewoon.
Stap 1 — Bepaal wat het model doet (en wat niet)
Voordat u een model kiest, moet u weten welk type taak het moet oplossen. Taalmodellen zijn niet op alle gebieden even sterk, en een model dat uitblinkt in rekenen kan verliezen bij lange documenten.
Drie basiscategorieën van taken:
- Extractie en classificatie: Gegevens uit scans halen, tickets labelen, samenvatten. Kleinere modellen volstaan. Latency en throughput zijn kritischer dan ruwe intelligentie.
- Generatie en redeneren: Rapporten schrijven, contracten analyseren, coderen, plannen. Hier telt benchmarkkwaliteit — geef de voorkeur aan frontier- of sterke open-weight modellen uit de Llama-, Qwen- of Mistral-familie.
- Lange context: Uitgebreide documentatie, bedrijfsarchieven, verslagen samenvatten. Hier verschillen modellen sterk — niet alle modellen beheersen retrieval in het midden van megabytes even goed, ook al bestaat het contextvenster nominaal.
Zodra u het taaktype kent, weet u ook waarop u moet letten bij benchmarks: MMLU, HumanEval en GSM8K voor algemeen redeneren en code; IFEval voor het volgen van instructies; RULER of needle-in-a-haystack-tests voor lange context. Lees benchmarks echter voorzichtig — ze meten specifieke omstandigheden, niet de productierealiteit. Meer hierover in het artikel Hoe lees je LLM-benchmarks.
Stap 2 — Open-weight vs cloud-API: dit is de echte beslissingsas
Niet "welk model", maar "waar draait het". Deze beslissing bepaalt 80 % van de overige parameters.
Cloud-API (Anthropic, OpenAI, Google, Mistral, DeepSeek)
Voordelen: - Nul infrastructuuroverhead — u betaalt per token, niet voor GPU's - Hoogste prestaties in alle categorieën (frontier-modellen leiden de benchmarks) - Contextvensters zonder beperking van eigen VRAM - SLA en beschikbaarheid worden door de provider geregeld
Beperkingen: - Uw data en prompts verlaten uw infrastructuur - Prijzen zijn variabel; bij grote volumes kunnen de maandelijkse kosten vijfcijferig zijn - Gereguleerde sectoren (gezondheidszorg, recht, financiën) hebben strikte beperkingen op data-egress
Indicatieve prijzen in 2026: frontier-modellen (Claude Opus, GPT-5.x) liggen in de orde van $3–25 per miljoen invoertokens afhankelijk van de tier. DeepSeek en vergelijkbare modellen uit Chinese families zijn via API doorgaans 10–30 keer goedkoper dan de Amerikaanse frontier. De prijzen zijn het afgelopen jaar aanzienlijk gedaald, waardoor oude berekeningen niet meer kloppen.
On-prem / lokale deployment (open-weight modellen)
Voordelen: - Data verlaat het netwerk niet — de enige weg voor GDPR-gevoelige of vertrouwelijke omgevingen - Voorspelbare kosten (hardware + energie) na de initiële investering - Volledige controle over het model, prompt-logs en versies
Beperkingen:
- Eenmalige GPU-investering en IT-overhead
- Slechtere prestaties dan frontier-cloudmodellen (het verschil verkleint, maar bestaat)
- U hebt een serving-laag nodig — vLLM, SGLang of Ollama (sluit Ollama uit voor productie-serving, meer hieronder)
Als u deze beslissing systematisch wilt aanpakken, lees dan de uitgebreidere analyse in Lokale LLM vs cloud. Voor gereguleerde sectoren gelden aanvullende voorwaarden — on-prem eliminatie van data-egress is op zich niet voldoende voor compliance zonder auditlogs en gecontroleerde toegangen, wat behandeld wordt in On-prem LLM voor gereguleerde sectoren.
Stap 3 — Modelgrootte: groter is niet altijd beter
De open-weight markt in 2026 staat vol MoE-architecturen (Mixture of Experts). Wat dit in de praktijk betekent: een model met de naam "400B parameters" kan bij één inference-aanvraag slechts ~17 miljard parameters activeren. Parameteraantal en actieve parameters zijn twee verschillende getallen.
Praktische gevolgen voor de keuze:
- MoE-modellen (bijv. Llama 4 Maverick, Qwen 3.x MoE-varianten, Mixtral, DeepSeek V3): Minder compute bij inference, maar u moet het volledige model op disk en in VRAM laden. Grote MoE-modellen hebben honderden miljarden parameters, waarvan bij elke token slechts een fractie actief is — toch hebben ze VRAM nodig voor het volledige model. Een naïeve blik op "geactiveerde parameters" onderschat dus de hardwarevereisten.
- Dense modellen (Gemma 3, Phi-4, oudere Llama 3.x): Rechttoegeïsere deployment; parameteraantal ≈ compute. Phi-4 of kleinere Gemma 3-modellen zijn uitstekend voor edge-deployments en embedded toepassingen.
Indicatieve VRAM-behoefte (zonder KV-cache) voor gangbare groottes:
- 7–9B model: Q4_K_M formaat ≈ 5–7 GB VRAM; FP16 ≈ 16–19 GB
- 13B model: Q4_K_M ≈ 8 GB; FP16 ≈ 26 GB
- 70B model: Q4_K_M ≈ 35–40 GB; FP16 ≈ 140–168 GB
Kwantisatie (GGUF Q4_K_M, AWQ 4-bit) is niet automatisch slecht — op de meeste benchmarks blijft het binnen 5–8 % van de FP16-kwaliteit. Significante degradatie treedt pas op bij Q2 en lager. Meer over technieken en hun verschillen in Kwantisatie LLM (GGUF, AWQ, GPTQ).
Voor de meeste B2B use-cases geldt: een goed fijnafgestemd 13B-model overtreft een generiek 70B-model op een smalle domein. Voordat u beslist over de grootte, is het de moeite waard te overwegen of er voldoende data beschikbaar is voor fine-tuning — dat komt aan bod in RAG vs fine-tuning.
Stap 4 — Latency en throughput: wie is uw gebruiker?
Twee volledig verschillende profielen met verschillende eisen:
Interactieve (user-facing) chat of copilot: Latency is kritisch. De eerste token moet binnen 1–2 seconden arriveren. Hier is TTFT (Time to First Token) relevant. Een kleiner model dat snel antwoordt, is beter dan een groot model dat laat reageert.
Batchverwerking: Throughput is kritisch. Het gaat om tokens per seconde over de hele batch. Hier loont een groter model ondanks hogere latency per aanvraag, omdat u tienduizenden documenten tegelijk verwerkt.
Voor serving-infrastructuur: vLLM is de productiekeuze voor de meeste NVIDIA-deployments — PagedAttention reduceert KV-cache-fragmentatie dramatisch (van typisch 60–80 % verspilling naar minder dan 4 %) en continuous batching verhoogt de throughput 2–3 keer ten opzichte van statisch batchen. SGLang is sterker bij prefix-zware workloads (RAG, agents, multi-turn) — benchmarks tonen ~29 % hogere throughput op een H100 en ~23 % snellere TTFT ten opzichte van vLLM.
Ollama is geschikt voor één developer op een desktop, niet voor productie-multi-user deployments. Bij meerdere parallelle gebruikers is de doorvoer aanzienlijk lager dan bij vLLM.
Stap 5 — Kosten: waar u werkelijk betaalt
De cloudmarkt voor LLM-API's is wat betreft prijzen vandaag aanzienlijk gunstiger dan een jaar geleden. Maar er zijn nog steeds valkuilen.
Contextvenster ≠ goedkopere oplossing. Een context van 1M tokens betekent niet dat u er altijd een miljoen tokens in stuurt — u betaalt voor elke token die u verstuurt. KV-cache groeit lineair met de sequentielengte. Een 70B-model bij 128K context heeft bijvoorbeeld ~40 GB KV-cache alleen al; voor vier parallelle aanvragen bij 128K is dat ~160 GB bovenop het model zelf. Een contextvenster is een capaciteit, geen constante.
Prompt caching is een belangrijk instrument om kosten te verlagen bij herhalende systeemprompts. Indicatief: bij een goede workload bespaart u 50–70 % op de kosten van invoertokens. Maar cache-schrijftokens zijn op sommige platforms 1,25–2 keer duurder dan gewone tokens — de besparing treedt pas op bij herhaald lezen van hetzelfde prefix. Workloads met unieke lange prompts hebben geen voordeel van caching. Meer in Prompt caching en kosten.
Routing (een goedkoop model aanroepen voor eenvoudige vragen, een duur model alleen voor complexe) kan bij goed gekalibreerde instellingen 95 % van de kwaliteit behouden tegen een fractie van de kosten. Onderzoek van Berkeley toonde aan dat bij een goede router 75–90 % van de aanroepen naar het kleinere model gaat. Dit is eenvoudig te implementeren, maar vereist baseline-evals — zonder meting weet u niet waar de grens ligt.
Stap 6 — Licenties en gebruiksvoorwaarden
Dit wordt verwaarloosd totdat het een probleem wordt.
Open-weight modellen zijn niet automatisch vrij te gebruiken voor elk doel:
- Llama 4 (Meta): Meta custom-licentie. Beperking bij deployments met meer dan 700 miljoen maandelijkse actieve gebruikers. Voor de meeste B2B-bedrijfsdeployments is de beperking niet relevant, maar lees haar door.
- Qwen 3.x: Apache 2.0 — commercieel gebruik, aanpassing, distributie zonder vergoeding. Mistral: kleinere modellen (bijv. Mistral Small) zijn Apache 2.0, grotere (Mistral Large) hebben een eigen Mistral-licentie — controleer deze voor het specifieke model.
- DeepSeek V3: MIT-licentie — maximale vrijheid inclusief fine-tuning en verdere distributie.
- Gemma 3 (Google): eigen Gemma-licentie — staat commercieel gebruik toe, maar is geen door OSI goedgekeurde open-source licentie. Lees de voorwaarden zorgvuldig.
- Phi-4 (Microsoft): MIT.
Voor closed-weight cloud-API's (Claude, GPT-5.x, Gemini) worden de voorwaarden bepaald door de SLA en terms of service — let op het beleid voor dataretentie en opt-out voor trainingsdata.
Gereguleerde sectoren dienen vóór de eerste productieaanroep een DPA (Data Processing Agreement) te hebben ondertekend.
Stap 7 — Contextvenster: wanneer helpt 1M en wanneer niet
Vrijwel elk vlaggenschipmodel in 2026 heeft een contextvenster van minimaal 128K tokens. Llama 4 Scout heeft er zelfs 10M. Claude (hogere tiers), Gemini 2.5 en Llama 4 Maverick bieden 1M; DeepSeek V3 heeft 128K.
De vraag is niet "welk model heeft de grootste context", maar "heb ik dat nodig?".
Onderzoek toont aan dat modellen met toenemende context "context rot" vertonen — de nauwkeurigheid van retrieval daalt wanneer relevante inhoud omringd is door veel irrelevante tekst. Dit geldt met name bij multi-hop vragen waarbij informatie uit verschillende delen van het document gecombineerd moet worden.
Praktische vuistregel: als uw use-case lange documenten omvat (contracten, technische handleidingen, archieven) maar de vragen gericht van aard zijn, is RAG economischer en nauwkeuriger dan het hele document direct in de context laden. Lange context heeft pas zin wanneer het model het document echt in zijn geheel moet lezen — het genereren van een samenvatting van een rapport van 200 pagina's, het analyseren van een codebase.
Praktische beslissingsboom
Dit proces brengt het veld in de praktijk terug naar twee of drie kandidaten:
- 1.Mogen data uw netwerk verlaten? → Nee: open-weight + lokale serving. Ja: ga verder.
- 2.Is throughput of latency kritisch en is het verbruik groot? → Ja: overweeg lokale serving. Nee: cloud-API.
- 3.Wat is de taak? → Eenvoudige extractie/classificatie: kleiner model (7–13B of goedkope API). Complex redeneren: frontier of sterk 70B+.
- 4.Heeft u een specifiek domein met voldoende data? → Overweeg fine-tuning van een kleiner model vóór de aanschaf van een groter.
- 5.Wat is de licentie? → Filter op Apache 2.0 / MIT voor productie-commerciële deployments zonder juridische overhead.
Veelgestelde vragen
Welk open-weight model is vandaag het beste?
Er is geen universeel antwoord. In 2026 staan bij verschillende benchmarks modellen als Llama 4 Maverick, Qwen 3.x, DeepSeek en Mistral Large aan de top — afhankelijk van de taak. Voor code en redeneren zijn modellen uit de Qwen-familie sterk, voor lange context blinkt Llama 4 Scout uit (contextvenster van 10M). Test altijd op uw eigen data, niet alleen op publieke benchmarks.
Is DeepSeek betrouwbaar voor Europese deployments?
DeepSeek biedt open gewichten met een MIT-licentie — u kunt het model downloaden en lokaal draaien, zonder enige aanroep naar Chinese servers. Vanuit GDPR-perspectief is een lokale DeepSeek-deployment even "schoon" als Llama of Mistral. De cloud-API-versie via DeepSeek-servers is een andere kwestie — hier gelden dezelfde data-egress-overwegingen als bij Amerikaanse providers.
Wat is MoE en moet ik daar rekening mee houden bij de keuze?
MoE (Mixture of Experts) is een architectuur waarbij het model bij elke token slechts een deel van de parameters activeert. Praktisch gevolg: lagere compute bij inference, maar een grotere totale VRAM-footprint. Als u lokaal deployt, moet u het volledige model in het geheugen laden, ook al wordt bij elke token maar een fractie gebruikt. Voor cloud-API's interesseert dit detail u niet — u betaalt voor actieve parameters.
Loont fine-tuning in plaats van een groter model?
In veel gevallen wel — maar alleen als u voldoende kwalitatieve data heeft en een duidelijk afgebakend domein. Een goed fijnafgestemd 13B-model kan een generiek 70B-model overtreffen op een smalle industriële taak. Als u onvoldoende data heeft (voor SFT heeft u in de orde van duizenden kwalitatieve voorbeelden nodig), schaadt fine-tuning eerder dan dat het helpt. Over de afweging tussen RAG en fine-tuning schrijven we in RAG vs fine-tuning.
Hoe weet ik of ik de juiste keuze heb gemaakt?
De juiste keuze wordt geverifieerd met evaluaties op uw eigen data en use-cases — niet alleen door het vergelijken van benchmarks. Definieer 50–100 testcases met verwachte uitvoer, draai ze op de kandidaten en vergelijk. Dit proces beschrijven we uitgebreid in Hoe meet je de kwaliteit van een LLM-applicatie.
*Bij MP Industrial Solutions helpen we bedrijven het modelkeuzeproces gestructureerd te doorlopen — van het in kaart brengen van use-cases via het testen van kandidaten tot de productie-deployment op eigen infrastructuur. Als u met deze beslissing worstelt en dure doodlopende wegen wilt vermijden, spreken we graag met u.*