> Bron: https://neuralex.nl/blog/docker-of-native > Docker maakt een AI-dienst makkelijker reproduceerbaar en te herstellen; native draaien kan hardwaretoegang vereenvoudigen. Lees hoe je kiest op basis van beheer, herstel, updates en de eisen van je hardware. [Terug naar kennisbank](/blog) Infrastructuur ·6 oktober 2026 ·5 min lezen # Docker of native: waar draai je een kritieke AI-dienst? Docker maakt een AI-dienst makkelijker reproduceerbaar en te herstellen; native draaien kan hardwaretoegang vereenvoudigen. Lees hoe je kiest op basis van beheer, herstel, updates en de eisen van je hardware. ## Docker of native: begin bij herstel Docker is vaak een goede keuze voor een kritieke AI-dienst als je waarde hecht aan herhaalbare deployments, afgeschermde componenten en updates die je kunt terugdraaien. Native draaien kan beter passen wanneer je directe toegang tot hardware nodig hebt, bijvoorbeeld tot een GPU of unified memory, of wanneer containers extra technische complexiteit toevoegen. Voor een kritieke dienst is de doorslaggevende vraag niet welke aanpak in theorie sneller is. Het gaat erom of je de hele opzet kunt reproduceren, bewaken en herstellen wanneer een machine, update of afhankelijkheid problemen geeft. Een dienst is kritiek als uitval werk stillegt, herstel ingewikkeld is of onderdelen afhankelijk zijn van elkaar. De gevolgen bepalen hoeveel aandacht je aan testen, documentatie en herstel besteedt. ## Wat containers je opleveren en kosten Een container bundelt een applicatie met veel van haar benodigde software. Daardoor kun je dezelfde configuratie op verschillende geschikte machines uitrollen en wijzigingen in een afgebakende omgeving testen. Dat helpt als je bijvoorbeeld een modelserver, een API en ondersteunende diensten afzonderlijk wilt beheren. Je kunt componenten bovendien onafhankelijk bijwerken en, als de vorige image beschikbaar is en de gegevens en configuratie passen, terugzetten naar een eerdere versie. Die herhaalbaarheid komt niet vanzelf. Een image moet zorgvuldig worden opgebouwd en bijgehouden; anders herhaal je ook verouderde software of een bekende kwetsbaarheid. Docker voegt daarnaast een laag toe die je moet begrijpen en bewaken. Netwerkverbindingen, volumes, bestandstoegang en rechten kunnen anders werken dan op de host. Als gegevens alleen in een vluchtige container of verkeerd ingestelde opslag staan, kan een herstart informatie kosten. Hardwaredoorgifte vraagt extra aandacht. Een container kan een GPU gebruiken als het hostbesturingssysteem, de benodigde stuurprogramma’s en de containerconfiguratie goed op elkaar aansluiten. Problemen in die keten kunnen lastig te lokaliseren zijn. Test daarom de volledige route op de machine waarop de dienst echt draait. Controleer ook of de container voldoende toegang heeft voor de taak, maar niet meer rechten krijgt dan nodig. ## Native draaien: eenvoud met beheerwerk Een applicatie rechtstreeks op het besturingssysteem installeren kan een laag wegnemen tussen de dienst en de hardware. Dat kan nuttig zijn voor toepassingen die nauw leunen op GPU-toegang of unified memory. Ook kan een native installatie makkelijker te begrijpen zijn wanneer één machine en een klein aantal componenten worden beheerd. Minder lagen kunnen het onderzoek naar een storing eenvoudiger maken. Native betekent echter niet automatisch eenvoudiger in beheer. Bibliotheken, stuurprogramma’s, omgevingsvariabelen en systeempakketten worden op de host geïnstalleerd. Na verloop van tijd kan onduidelijk worden welke combinatie nodig is of welke handmatige wijziging een storing veroorzaakte. Een nieuwe machine opnieuw inrichten kan dan meer werk vragen dan verwacht. Documenteer daarom installatie en configuratie, en leg vast hoe je de dienst opnieuw opbouwt. Prestaties zijn evenmin op basis van de installatiemethode alleen te voorspellen. De uitkomst hangt af van de applicatie, hardware, stuurprogramma’s, configuratie en werklast. Vergelijk beide opties met dezelfde representatieve taken als prestaties een belangrijke keuze bepalen. Zie [hardware voor lokale AI](/blog/hardware-voor-lokale-ai) en de vergelijking van [modelservers](/blog/ollama-vllm-of-llamacpp) voor factoren die daarbij meespelen. ## Updates, logging en geheimen Welke aanpak je ook kiest, stel een updatebeleid op. Leg vast welke onderdelen zijn geïnstalleerd, waar de gebruikte versies vandaan komen en hoe je een wijziging test voordat die de kritieke dienst bereikt. Bij containers betekent dit onder meer dat je images en hun afhankelijkheden vastzet en bewust bijwerkt, in plaats van bij iedere start ongemerkt de nieuwste varianten op te halen. Bij native installaties moet je dezelfde discipline toepassen op pakketten, bibliotheken en stuurprogramma’s. Een rollback werkt alleen als je weet wat je terugzet. De applicatieversie, configuratie, modelbestanden en gegevens kunnen onderling afhankelijk zijn. Een nieuwere gegevensstructuur is bijvoorbeeld mogelijk niet bruikbaar met een oudere applicatie. Noteer dus welke onderdelen samen horen en test terugzetten met een realistische herstelprocedure. Bekijk ook [wat je naast data van een AI-systeem bewaart](/blog/backups-voor-ai-systemen). Maak logging en monitoring onderdeel van de inrichting. Leg genoeg vast om fouten te onderzoeken, zoals startproblemen, mislukte verzoeken, resourceproblemen en wijzigingen aan de dienst. Houd rekening met gevoelige gegevens: log niet onnodig prompts, documenten of geheimen. Gebruik monitoring om te zien of de dienst beschikbaar is en of belangrijke onderdelen reageren. Stel meldingen zo in dat iemand ze kan opvolgen. Bewaar configuratie en geheimen buiten de containerimage en buiten bronbestanden. Denk aan toegangssleutels, wachtwoorden, endpoints en paden naar modelbestanden. Beperk wie die gegevens kan lezen en geef de dienst alleen de rechten die zij nodig heeft. Zo voorkom je dat een geheim ongemerkt in een image, back-up of log terechtkomt. ## Herstel is pas betrouwbaar als je het test Back-ups helpen alleen als je ermee kunt herstellen. Bepaal welke gegevens, configuratie en modelbestanden onmisbaar zijn en welke onderdelen opnieuw opgebouwd kunnen worden. Documenteer waar back-ups staan, hoe je toegang krijgt en welke stappen nodig zijn om de dienst weer beschikbaar te maken. Een containerimage bewaren kan nuttig zijn, maar vervangt geen back-up van blijvende gegevens of configuratie. Oefen het herstel op een geïsoleerde omgeving of een vervangende machine. Controleer of de dienst start, verbinding maakt met haar afhankelijkheden en het verwachte werk aankan. Zo ontdek je ontbrekende geheimen, opslaginstellingen of handmatige stappen voordat er een echte storing is. Hoe vaak je dit doet, hangt af van hoe snel herstel nodig is en hoe vaak de omgeving verandert. Bij een on-prem-opstelling spelen bovendien de beschikbare hardware en het onderhoud ervan mee; zie [wanneer on-prem AI de moeite waard is](/blog/on-prem-ai-wanneer-de-moeite). ## Hybride kiezen en beslissen Je hoeft niet elke component op dezelfde manier te draaien. Een modelserver kan native staan voor directe toegang tot hardware, terwijl een API, dashboard, database of taakplanner in containers draait. Zo’n hybride opzet kan goed werken, maar vraagt heldere grenzen: beschrijf hoe onderdelen elkaar bereiken, waar bestanden staan en wat er gebeurt als één component uitvalt. Zorg ook dat je het geheel als één dienst kunt herstellen. Loop deze beslislijst door voordat je kiest: - **Herstel:** Kun je de installatie en configuratie opnieuw opbouwen en heb je herstel getest? - **Hardware:** Heeft de dienst directe toegang nodig tot een GPU, unified memory of andere hostfuncties? - **Beheer:** Kun je afhankelijkheden, updates en rechten in containers goed genoeg beheren? - **Bewaking:** Kun je storingen herkennen en genoeg informatie verzamelen om ze te onderzoeken? - **Gegevens:** Staan blijvende gegevens, configuratie en geheimen op de juiste plek en in je herstelplan? - **Verandering:** Kun je updates testen, versies vastzetten en zo nodig terugdraaien? Kies Docker wanneer reproduceerbare uitrol en afgebakend beheer de belangrijkste voordelen zijn en je de extra laag goed kunt onderhouden. Kies native wanneer directe hardwaretoegang of een eenvoudigere hostopzet doorslaggevend is en je handmatig beheer kunt documenteren. Bij twijfel kan een hybride ontwerp passend zijn. De beste keuze is de opzet die jouw team kan uitleggen, controleren en herstellen. Infrastructuur ## Twijfel je tussen containers en native draaien? We kijken met je mee naar herstel, updates en hardware — praktisch en zonder verzonnen claims. Benieuwd wat dat voor jouw AI-dienst betekent? [Stel je vraag](/contact) [Lees over back-ups voor AI-systemen](/blog/backups-voor-ai-systemen) --- Volledige (opgemaakte) versie: https://neuralex.nl/blog/docker-of-native