De verticale SLM-stack: GPU, training en applicatielaag voor domeinspecifieke AI in 2026

Verticale SLM-stack: de GPU-, trainings- en applicatielaag

Op 1 juli 2026 schoof Palantir-CEO Alex Karp aan bij Squawk Box op CNBC en zei iets wat elke enterprise-AI-koper al dacht, maar wat nog niemand met een podium hardop had gezegd: "Er is iets helemaal misgegaan met hoe AI wordt verkocht." Zijn diagnose was precies. Bedrijven betalen voor tokens die geen operationele waarde opleveren. De modelgewichten die op hun eigen data zijn getraind, de echte concurrentie-intelligentie, vloeien terug naar de labs. En het prijsmodel is ontworpen om je afhankelijk te houden, niet capabel.

Karps antwoord is soevereiniteit: houd controle over je rekenkracht, je modelgewichten, je datastack en je voorsprong. Dat is geen filosofisch standpunt. Het is een architectuurbeslissing. En de architectuur waarnaar het wijst, heeft een naam: de verticale SLM-stack.

Dit artikel legt uit hoe die stack eruitziet, hoe je elke laag bouwt en waarom een founder met een specifieke use case een algemeen frontier-model op zijn eigen probleem kan verslaan, voor een fractie van de kosten.

Waarom het tokenmodel aan het afbrokkelen is

De economie van intelligentie huren bij een frontier-lab was logisch in 2023. Modellen voelden magisch, je eigen model bouwen was onbetaalbaar en de benchmarkverschillen tussen grote en kleine modellen waren enorm. Geen van die drie voorwaarden geldt in 2026.

Open-weight-modellen (Llama 3.2, Phi-4-mini, Gemma 3) zijn nu 16x goedkoper per token dan frontier-API's en evenaren of verslaan ze vaak op smalle, goed gedefinieerde taken. Fine-tuninginfrastructuur waarvoor twee jaar geleden een team ML-engineers nodig was, draait nu in een middag op één A100. En de enterprise-wereld is gaan rekenen. De Reddit-threads en Discord-kanalen waar ML-engineers openhartig praten, vertellen hetzelfde verhaal: voor classificatie, extractie, samenvatting, codegeneratie binnen een afgebakende scope en structured output (samen ongeveer 80% van de echte enterprise-AI-workloads) verslaat een gefinetuned 7B-model een 70B-model met prompts tegelijk op nauwkeurigheid, latency en kosten.

De rekensom die gedrag verandert

Frontier-LLM-API

$2–$30 per miljoen tokens

$15,000–$75,000/maand op schaal

Jouw data traint hun model

Latency: 2–8 seconden

Gefinetunede SLM (zelf gehost)

$0.10–$0.50 per miljoen tokens

$150–$800/maand op schaal

Jouw data blijft op jouw infra

Latency: 80–300 ms

Het kostenverschil is niet marginaal. Het is een orde van grootte. En het stapelt zich op naarmate het volume groeit. Een startup die 500,000 API-aanroepen per maand verwerkt, kijkt aan tegen $10,000–$40,000 aan tokenrekeningen, of $300–$600 als hij een gefinetunede SLM zelf host. Van dat verschil betaal je twee engineers.

Wat is een klein taalmodel eigenlijk?

SLM's zijn taalmodellen in het bereik van 1 tot 15 miljard parameters. Dat klinkt als een technisch onderscheid, maar het heeft concrete praktische gevolgen: ze draaien op één GPU (of in sommige configuraties zelfs op een CPU), ze zijn in uren te fine-tunen in plaats van weken, ze passen in edge-omgevingen en on-premises deployments, en ze leveren inferentie in 80–300 ms in plaats van seconden.

De belangrijkste open-weight-SLM's in 2026 zijn:

Phi-4-mini (3.8B, Microsoft): momenteel de benchmarkleider in de 3–4B-klasse. Draait in ~3 GB VRAM, contextvenster van 128K, aan kop op MMLU en wiskundig redeneren. Uitzonderlijk voor gestructureerde redeneertaken met een kleine voetafdruk.
Gemma 3 (2B / 7B, Google): sterke commerciële licentie, geoptimaliseerd voor cloud en edge. Bijzonder geschikt voor documentbegrip en het volgen van instructies over meerdere beurten.
Llama 3.2 (1B / 3B, Meta): ontworpen voor edge-deployment op mobiele en embedded apparaten. Het 1B-model draait op de CPU van een telefoon. Uitstekend voor routering, classificatie en lichte extractie.
Mistral 7B / Mixtral 8x7B: sterk in codegeneratie en het volgen van instructies. De sparse MoE-architectuur van Mixtral geeft het veel meer slagkracht dan het aantal actieve parameters doet vermoeden.

Het belangrijkste inzicht is dat geen van deze modellen GPT-5 zal verslaan op een algemene benchmark. Daar gaat het ook niet om. Een 3.8B-model dat is gefinetuned op 50,000 voorbeelden van jouw specifieke taak, verslaat GPT-5 op die taak, en doet dat voor 1/30e van de kosten met 10x lagere latency.

De verticale stack in drie lagen

Een domeinspecifieke AI-capaciteit bouwen die van begin tot eind van jou is, betekent bewuste keuzes maken op drie lagen: rekenkracht, training en applicatie. De meeste founders die het probeerden en faalden, behandelden ze los van elkaar. Dat zijn ze niet. Elke laag begrenst de andere en maakt ze mogelijk.

Laag 1: GPU (rekenkracht)

De GPU-laag is waar de meeste founders te veel investeren of de verkeerde architectuurgok maken. Het goede nieuws is dat de hardware-eisen voor verticaal SLM-werk in 2026 veel lager zijn dan nog maar 18 maanden geleden.

Voor het fine-tunen van een 7B-model met LoRA of QLoRA (de standaardaanpak) heb je één A100 80GB of twee A6000's nodig. Cloudkosten: $2–$4/uur. Een volledige fine-tuningrun op 10,000 voorbeelden duurt 2–6 uur. Totaal: minder dan $25 per trainingsrun. Dat is geen kapitaaluitgave: het is een variabele kostenpost die je betaalt als je hertraint.

Voor inferentie serveert een gekwantiseerd 7B-model (INT4/INT8) 100–500 gelijktijdige verzoeken op één A10G (24GB VRAM, ~$1.50/uur). Op die schaal is zelf hosten binnen 30–60 dagen na deployment bijna altijd goedkoper dan API-aanroepen.

Voor edge- of on-premises-eisen, gebruikelijk in de zorg, de juridische sector en de overheid, draait de 1–3B-klasse op NVIDIA RTX 4090-consumentenkaarten (~$2,000) of Apple Silicon M3 Ultra. Geen cloudafhankelijkheid, geen data die naar buiten gaat, geen compliancerisico.

Keuzegids voor het GPU-niveau

1–3B-model, edge/on-prem: RTX 4090, Apple M3 Ultra, NVIDIA Jetson
7B-model, fine-tunen en serveren in de cloud: A10G (inferentie), A100 (training)
13B-model: 2× A100 of H100 voor training; A100 voor gekwantiseerde inferentie
Batch- / asynchrone workloads: spot-instances verlagen de trainingskosten met 60–70%

Laag 2: training (fine-tuningpipeline)

Dit is de laag die de echte concurrentievoorsprong oplevert. Het basismodel is openbaar. Iedereen kan met Llama of Phi beginnen. Wat ze niet kunnen nabootsen, is je trainingsdata: de domeinspecifieke voorbeelden, randgevallen en outputformaten die je operationele kennis in de modelgewichten vastleggen.

Alex Karp zei het scherp: frontier-labs "stelen de gewichten en de voorsprong" van bedrijven die hun API's gebruiken, omdat elke query en elk correctiesignaal dat je via een cloud-API geeft, direct of indirect bijdraagt aan het verbeteren van hun model. Als je je eigen fine-tuningpipeline bezit, blijft dat signaal van jou.

De standaardworkflow voor fine-tuning:

Stel een taakspecifieke dataset samen. Je hebt 1,000–50,000 hoogwaardige instructie–antwoordparen nodig voor de specifieke taak. Kwaliteit gaat boven kwantiteit. 2,000 door experts gelabelde voorbeelden presteren consequent beter dan 50,000 rommelige. Begin met je bestaande output (eerdere documenten, beslissingen, gestructureerde data), gebruik een frontier-model om goedkoop synthetische trainingsdata te genereren en valideer daarna handmatig een steekproef.
Pas LoRA / QLoRA-fine-tuning toe. Low-Rank Adaptation bevriest de meeste gewichten van het basismodel en traint alleen een kleine set adaptermatrices, meestal 0.1–1% van het totale aantal parameters. Zo fine-tune je een 7B-model op één GPU zonder dat het geheugen opraakt. Tools: de PEFT-library van Hugging Face, Unsloth (2–5x sneller), Axolotl voor complexe pipelines.
Evalueer grondig voordat je shipt. Bouw een achtergehouden evaluatieset van 200–500 voorbeelden met ground-truth-labels. Volg taaknauwkeurigheid, hallucinatiegraad en naleving van het formaat. Een model dat 95% nauwkeurig is op je evaluatieset maar in productie faalt op randgevallen, is slechter dan een model van 90% met bekende faalwijzen.
Zet een ritme voor hertraining op. De waarde van het model groeit als je hertraint op productie-output en correcties. Een maandelijkse of driemaandelijkse hertrainingslus, gevoed met echte gebruiksdata, creëert een voorsprong die met de tijd groter wordt. Dat is de kern van het verticale voordeel: elke cyclus maakt je model beter in jouw specifieke taak, terwijl generieke API's generiek blijven.

Laag 3: applicatielaag

De applicatielaag is waar je model aansluit op echte workflows, en waar de meeste productbeslissingen liggen. Deze laag goed krijgen, is wat een werkende demo onderscheidt van een productiesysteem dat gebruikers vertrouwen.

Omdat je SLM bewust smal is, moet de applicatielaag de scope duidelijk bewaken. Een SLM voor klinische documentatie moet geen algemene medische vragen proberen te beantwoorden. Een extractor voor juridische contracten moet geen juridisch advies proberen te geven. De applicatielaag dwingt die grens af, via de opbouw van de prompt, validatie van de output en routeringslogica.

Serving-infrastructuur: vLLM en Ollama zijn in 2026 de twee dominante opensource-inferentieservers. vLLM verzorgt multi-tenant serving met hoge doorvoer dankzij PagedAttention. Ollama is eenvoudiger te beheren en uitstekend voor single-tenant- of developergebruik. Beide ondersteunen gekwantiseerde modellen en OpenAI-compatibele API's, dus bestaande code die OpenAI aanroept, kun je met een wijziging van één regel URL omleiden naar je zelf gehoste SLM.
Afdwingen van structured output: bij domeintaken wil je bijna altijd JSON of structured output. Gebruik grammar-constrained decoding (Outlines, Guidance of de ingebouwde structured output van vLLM) om te garanderen dat het model geldige, schema-conforme output teruggeeft. Dat schakelt de meest voorkomende bron van fouten verderop in de keten uit.
Retrieval-augmentatie: een stack van SLM + RAG is vaak krachtiger dan een groot model alleen. De SLM doet het redeneren en genereren; de retrieval-laag verankert het in actuele, eigen documenten. Dat werkt vooral goed in juridische, financiële en zorgcontexten, waar actualiteit en trouw aan documenten belangrijker zijn dan brede wereldkennis.
Routeringslaag: in productie routeert de slimste architectuur verzoeken met verstand. Eenvoudige taken met veel volume gaan naar de SLM. Complexe, ambigue of zeldzame taken escaleren via een API naar een frontier-model. Een 1B-classifier kan die routeringsbeslissing in minder dan 10 ms nemen. Het resultaat: 70–80% van de verzoeken wordt bediend door je goedkope, snelle SLM en de overige 20–30% wordt geëscaleerd. Je gemiddelde kosten per query dalen met 85–90%, terwijl de kwaliteit hoog blijft.

Verticale use cases waarin deze stack overtuigend wint

De verticale SLM-aanpak is niet in alle gevallen beter dan een frontier-model. Hij is veel beter voor een specifieke soort probleem: taken met veel volume, goed gedefinieerd en datarijk, in een domein met eigen kennis.

Zorg: klinische documentatie

Een 3B-model dat is gefinetuned op klinische notities, ICD-codes en ontslagbrieven presteert consequent beter dan algemene LLM's op documentatietaken. Latency telt in klinische workflows: 100 ms tegenover 3 seconden is het verschil tussen een tool die wordt gebruikt en een die wordt verlaten. Datasoevereiniteit is onder HIPAA niet onderhandelbaar: een zelf gehoste SLM is de enige haalbare optie.

Juridisch: contractextractie en -review

Juridische NLP-taken (clausule-extractie, risicosignalering, het herkennen van verplichtingen) lenen zich bij uitstek voor gefinetunede SLM's. De outputruimte is begrensd: specifieke clausuletypen, ja/nee-risicovlaggen, gestructureerde samenvattingen. Een 7B-model dat is getraind op 5,000 geannoteerde contracten vindt bepalingen die een algemeen model mist, zonder enig risico dat vertrouwelijke documenten de infrastructuur van het kantoor verlaten.

Financiën: transactieclassificatie en anomaliedetectie

Financiële instellingen die miljoenen transacties per dag verwerken, kunnen zich de kosten en de latency van frontier-API's niet veroorloven. Een gefinetuned 1–3B-model handelt transactiecategorisering, het extraheren van fraudesignalen en het ontleden van regelgevingsteksten af met een latency onder 100 ms en volledige controleerbaarheid, een wettelijke eis in de meeste jurisdicties.

Industrie: defectdetectie en onderhoud

Ongestructureerde data uit onderhoudslogs, sensormetingen en kwaliteitsrapporten is buitengewoon waardevol en volledig eigen. Een gefinetunede SLM die je specifieke machines, faalwijzen en onderdeelnummers begrijpt, presteert beter dan welk algemeen model ook, en kan on-premises op de fabrieksvloer worden uitgerold.

SaaS-producten: domeinspecifieke features

Bouw je verticale SaaS, voor vastgoed, HR, logistiek of onderwijs, dan creëert een gefinetunede SLM in je product een voorsprong in features. Je AI-feature begrijpt de taxonomie van je domein, de datapatronen van je klanten en je outputformaten op een manier die geen concurrent met een generieke API kan nabootsen zonder jouw trainingsdata.

AI-soevereiniteit is geen ideologie, maar architectuur

Het negenpuntenmanifest van Palantir over AI-soevereiniteit, gepubliceerd een dag voor Karps interview op CNBC, leest als een provocatie. Het is in feite een architectuurdocument. Het kernargument is praktisch: "tokenmaxxing", het verdienmodel dat per token rekent voor algemene intelligentie, beloont de verkeerde dingen. Het beloont wegwerpscripts boven robuuste systemen, afhankelijkheid boven capaciteit, en de omvang van het verbruik boven de kwaliteit van de uitkomst.

Het partnerschap tussen Palantir en Nvidia dat dezelfde week werd aangekondigd, is de commerciële uitdrukking van die stelling: een "soeverein AI-besturingssysteem" dat instellingen als gebundeld product de controle geeft over hun rekenkracht, modellen en datastack. Of je het nu van Palantir koopt of zelf bouwt, de richting is dezelfde: bezit de stack.

Voor founders is de implicatie eenvoudig. Is de AI-capaciteit van je product een aanroep naar een externe API, dan heb je geen slotgracht. Elke concurrent kan dezelfde aanroep doen. Is je capaciteit een gefinetuned model, getraind op eigen data en draaiend op infrastructuur die je zelf beheert, dan is dat een echt concurrentievoordeel, dat bij elke hertrainingscyclus groeit en moeilijker na te bootsen wordt naarmate je het langer laat draaien.

Wanneer de verticale stack de verkeerde keuze is

De verticale SLM-stack is niet altijd de juiste. Hij vraagt een investering vooraf in datacuratie, trainingsinfrastructuur en operationele discipline die niet elk team kan opbrengen. Drie situaties waarin je bij de API moet blijven:

Je zoekt nog naar product-market fit. Verandert je taakdefinitie nog van week tot week, dan is fine-tunen verspilde moeite. Bouw met een API tot de taak stabiel en goed begrepen is. Bouw daarna de SLM.
Je hebt nog niet genoeg gelabelde data. Fine-tunen op minder dan 500 voorbeelden levert meestal instabiele modellen op. Kun je geen 1,000+ hoogwaardige voorbeelden verzamelen of genereren, gebruik dan few-shot prompting met een frontier-model en investeer parallel in dataverzameling.
Je taak vraagt echt om brede wereldkennis. Onderzoekssynthese, open creatief werk en taken die een gevarieerde context uit de echte wereld moeten samenbrengen, blijven grote frontier-modellen bevoordelen. De SLM-aanpak blinkt uit in diepte, niet in breedte.

Waar je begint

Het praktische startpunt voor de meeste founders is een pilot-fine-tune op één taak met veel volume, een taak die je precies kunt meten en met duidelijke succescriteria. Kies een taak waarvoor je nu $3,000–$10,000/maand aan API-kosten betaalt. Reken het door voor een gefinetunede 7B-SLM. De businesscase is meestal al na de eerste berekening duidelijk.

De drie vragen om te checken of je klaar bent voor een verticale SLM

1. Heb je één goed gedefinieerde taak die met veel volume draait (10,000+ queries per maand)?
2. Heb je 2,000+ gelabelde voorbeelden van die taak, of kun je die genereren?
3. Zijn datasoevereiniteit, latency of kosten belangrijk genoeg om 2–4 weken engineering te rechtvaardigen?

Heb je alle drie met ja beantwoord, dan ben je klaar om de eerste laag van je verticale stack te bouwen. De rest volgt daaruit.

Karps kernpunt, dat er iets helemaal is misgegaan met hoe AI wordt verkocht, is minder een kritiek op OpenAI en Anthropic dan een observatie over een markt op een kantelpunt. De infrastructuur om verticaal te bouwen is nu toegankelijk. De open-weight-modellen zijn goed genoeg. De economie is overtuigend. Het enige wat overblijft, is de beslissing om iets te bouwen dat van jou is in plaats van iets te huren waarvan je afhankelijk bent.