In het vorige artikel ging het over public AI versus private AI: wanneer is een publieke AI-dienst prima, en wanneer wil je meer controle over data en verwerking? Dit artikel gaat over de vervolgvraag. Als je private inference wilt draaien, hoe ziet dat er dan in de praktijk uit?
Private inference is geen los model op een GPU. Het is een beheerde keten met model, inference server, API-laag, identity, netwerkisolatie, RAG of datalaag, logging, monitoring en beheer. Zonder die lagen heb je vooral een technisch experiment. Met die lagen wordt het een omgeving die je kunt gebruiken, uitleggen en beheren.
De belangrijkste vraag is dus niet: welk model is het beste? De eerste vraag is: waar loopt de data, wie mag erbij en wie beheert de keten?
Private inference in één zin
Inference is het gebruiken van een bestaand AI-model om tekst te genereren, documenten te analyseren, informatie te classificeren of vragen te beantwoorden. Private betekent dat die verwerking plaatsvindt binnen een gecontroleerde omgeving, bijvoorbeeld in een private cloud, op dedicated hardware, on-premises of in een soevereine cloudomgeving.
Het gaat dus niet om zelf een foundation model trainen. Het gaat om een bestaand model veilig en beheersbaar aanbieden aan je applicaties, medewerkers of klanten.
Private inference als keten
De controle zit niet alleen in het model, maar vooral in de lagen eromheen.
Model en inference server
Een private inference-omgeving begint meestal met een model artifact en een inference server. Het model artifact bevat onder meer modelgewichten, tokenizer en configuratie. De inference server laadt het model, verwerkt requests, beheert geheugen, plant tokens en biedt een API aan voor applicaties.
Er zijn verschillende manieren om zo'n server te draaien. Denk aan llama.cpp, vLLM, TGI, TensorRT-LLM of Ollama. Dat zijn geen inwisselbare producten met één beste keuze. De juiste keuze hangt af van je workload, modelgrootte, hardware, gewenste API, beheerkennis en eisen aan productiegebruik. Voor dit artikel is vooral belangrijk dat er altijd een serving-laag tussen applicatie en model hoort te zitten.
Veel teams vinden een OpenAI-compatible API praktisch, omdat bestaande applicaties dan minder hoeven te veranderen. Maar OpenAI-compatible betekent alleen dat de API-vorm lijkt op wat ontwikkelaars al kennen. Het zegt niets over privacy, logging, rechten of netwerkbeveiliging. Die moet je zelf ontwerpen.
Hardware is meer dan een GPU kiezen
GPU's kunnen nodig zijn, maar niet elke workload begint daar. Voor kleine modellen, lage volumes of batchtaken kan CPU-inference soms genoeg zijn. Voor interactieve chat, meerdere gebruikers of langere context kom je sneller bij GPU's uit.
"Past het model in VRAM?" is niet genoeg. VRAM wordt niet alleen gebruikt voor modelgewichten. Je hebt ook geheugen nodig voor context, KV-cache, batching, gelijktijdige requests en runtime overhead. Een model dat net past bij één testprompt kan in productie alsnog vastlopen zodra meerdere gebruikers lange documenten meesturen.
Ontwerp daarom ook limieten: maximale contextlengte, maximale outputtokens, wachtrijduur, concurrency per tenant en rate limits per applicatie. Behandel een LLM-server net als een database onder piekbelasting. Liever snel en duidelijk terugkoppelen dat iets te groot is, dan alle gebruikers laten wachten.
Van modelproces naar beheerde API
Laat applicaties niet onbeheerd rechtstreeks tegen een model praten.
Weinig zicht op rechten, limieten, tenants, logging en foutafhandeling.
De API-laag bepaalt wie wat mag, hoeveel verkeer is toegestaan en wat wordt vastgelegd.
Netwerkisolatie en toegang
Private inference is pas private als de route naar het model onder controle staat. Hang een inference endpoint dus niet onnodig publiek aan het internet. Plaats applicaties, inference servers en datalagen in private netwerken. Scheid test, acceptatie en productie. Houd beheerinterfaces apart van applicatieverkeer.
Alleen datalocatie is daarbij niet genoeg. Voor digitale soevereiniteit tellen ook beheer, toegang, logging, jurisdictie, exit-mogelijkheden en incidentrespons. Een model in Nederland draaien helpt weinig als iedere applicatie met dezelfde sleutel alles mag opvragen.
Daarom hoort identity buiten het model. De API-laag moet bepalen welke applicatie welk model mag gebruiken, welke gebruiker bij welke tenant hoort, welke dataklasse verwerkt mag worden en welke limieten gelden. Een system prompt is geen security boundary. Autorisatie hoort buiten het model.
RAG maakt de datalaag centraal
Private inference wordt vaak pas echt nuttig als het model eigen context krijgt. Denk aan interne documenten, tickets, klantdossiers, securitylogs, broncode of productdata. Bij SaaS raakt die datalaag direct aan je SaaS-infrastructuur. Meestal gebeurt dat met RAG: documenten worden opgeslagen, opgeknipt, omgezet naar embeddings en doorzoekbaar gemaakt via een vector database of zoeklaag.
De datalaag is vaak gevoeliger dan het model zelf. Als retrieval rechten negeert, kan een gebruiker via AI documenten zien die hij buiten AI nooit mocht zien. RAG moet daarom permission-aware zijn. Documentrechten, tenantgrenzen en metadatafilters moeten server-side worden afgedwongen, niet als instructie in een prompt.
Let ook op bronvermelding en herleidbaarheid. Bij zakelijke toepassingen wil je vaak kunnen zien welke documenten zijn opgehaald, welke versie daarvan is gebruikt en waarom een antwoord binnen de toegestane context viel.
Logging, monitoring en beheer
Private inference geeft controle, maar alleen als je die controle ook inricht. Monitoring gaat niet alleen over uptime. Meet latency, time to first token, tokens per seconde, queue depth, foutpercentages, throttling, GPU-gebruik en VRAM-gebruik. Koppel die metrics waar mogelijk aan applicatie, tenant en modelversie.
Logging vraagt extra aandacht. Volledige prompts en outputs kunnen persoonsgegevens, klantdata of bedrijfsgeheimen bevatten. Soms is metadata-only logging verstandiger: requestId, userId, tenantId, modelversie, prompt-templateversie, token counts, opgehaalde document-ID's en fouten. Kies bewust wie logs mag lezen en hoe lang je ze bewaart.
Beheer is de rest van het verhaal: patching, modelupdates, versiebeheer, rollback, quota's, evaluatie en incident response. Een modelupdate kan gedrag veranderen. Een prompt template kan per ongeluk te veel context meesturen. Een nieuwe embedding-run kan retrieval beïnvloeden. Leg daarom vast wat draait, waarom het draait en hoe je terug kunt.
Eerste pilot zonder groot platform
Begin klein, maar zet de beheerlagen vanaf dag één goed neer.
Begin klein, ontwerp serieus
Je hoeft niet meteen een volledig AI-platform te bouwen. Begin met één concrete use-case, een beperkte dataklasse en een helder acceptatiecriterium. Kies een model dat goed genoeg is voor die taak, beperk context en output, en meet hoe de omgeving zich gedraagt onder normaal gebruik.
Maar begin niet zonder basisarchitectuur. API, identity, netwerkisolatie, logging en monitoring zijn geen latere toevoegingen. Juist in een pilot leer je welke data door de keten loopt, welke rechten nodig zijn en welke beheerlast realistisch is.
Private inference draaien is daarmee vooral infrastructuurwerk. Het model is belangrijk, maar de waarde zit in de gecontroleerde keten eromheen. Wie die keten goed ontwerpt, kan AI toepassen op plekken waar public AI te weinig grip geeft. De volgende stap is bepalen wanneer private inference geschikt is voor je use case.
AI inzetten met controle over data en beheer? Bekijk hoe cloud.nl kijkt naar AI-infrastructuur en wanneer een private cloud een logische basis is voor private inference.