De opkomst van AI betekent niet alleen dat we meer met ChatGPT gaan praten. Men ziet steeds vaker de opkomst van AI-assisted coding en automatisering binnen onze workflows. De kracht hiervan is dat we een stuk intelligentie kunnen toevoegen aan onze applicaties.
Voorbeelden hiervan zijn speech-to-text, bijvoorbeeld voor gesprekken die worden gevoerd met cliënten. Verdere mogelijkheden zijn planningen maken voor hoe de aankomende week eruit gaat zien of grote hoeveelheden informatie omzetten naar leesbare tekst. Met de huidige ontwikkelingen en de snelheid waarop deze plaatsvinden, zullen de mogelijkheden alleen maar toenemen.
Dit betekent eveneens dat onze afhankelijkheid van dergelijke AI-modellen steeds groter wordt. Alle informatie kan niet altijd naar Amerikaans of Chinees gehoste modellen gestuurd worden, bijvoorbeeld als het gaat over persoonsgegevens of vertrouwelijke gesprekken. Gelukkig is hier ook een oplossing voor: zelf opensource modellen draaien.
Waar begint het?
Wat is er nu nodig om een LLM te draaien? We hebben allemaal wel gehoord van de Nvidia-videokaarten die benodigd zijn en hoe Google en OpenAI gehele datacenters neerzetten om deze modellen te kunnen draaien. Er zijn voldoende mogelijkheden om op kleinere schaal te beginnen.
Op de lokale pc is een mogelijk begin te maken met het draaien van Ollama , wat ook wel de Apache van LLM’s genoemd wordt. Dit programma maakt het mogelijk om veel verschillende modellen te draaien. Bezoek de website van Ollama eens en bekijk de beschikbare modellen. Wat er ooit honderd waren, zijn het er nu duizenden.
What’s next? Dit hangt volledig af van wat de toepassing van het model. Denk hierbij aan het bewerken van teksten of uitlezen van afbeeldingen. Moet het model kunnen redeneren, dus in meerdere stappen nadenken? Of moeten embeddings gegenereerd worden, wat vaak wordt gebruikt om slim mee te zoeken? Dan moet de keuze van het model hierop aansluiten.
Elk model reageert weer anders. Daarom is het te adviseren om te beginnen met testen. Probeer eerst modellen uit deze “families”: Llama , Mistral , Gemma , Qwen en DeepSeek . Daarmee is doorgaans een sterke start te maken.
Verwachtingsmanagement
Ondertussen zijn de frontiermodellen van OpenAI, Google en Anthropic niet meer weg te denken. Hoewel opensource modellen steeds dichterbij komen, is een gelijkwaardig niveau vrijwel niet te behalen. Dit komt door de grote hoeveelheid resources waar deze partijen beschikken.
Neem bijvoorbeeld het DeepSeek-R1-model , dat met de volledige 671B parameters ongeveer 1.343GB aan videokaartgeheugen in gebruik neemt. Zeker in de huidige hardwaremarkt een prijzige aangelegenheid.
Gelukkig zijn er in veel usecases niet de allergrootste modellen nodig en kan men met kleinere versies al hele goede resultaten behalen. Met een 8B-model is er ongeveer 4 GB werkgeheugen nodig en met een 32B-model rond de 15 GB. Dit opent nieuwe deuren binnen de beschikbare resources.
Verplaatsen naar productie
Nu is het niet aan te raden om LLM’s op de lokale PC te blijven draaien. Nadat het model lokaal is getest, kan het verplaatst worden de “cloud”. Een krachtige en logische optie is om het binnen Kubernetes te draaien. Hierbij kunnen GPU-workers beschikbaar gemaakt worden en Kubernetes de workload laten schedulen op deze nodes. Hierin zet Shock Media het Managed App Platform in om AI-hosting mogelijk te maken.
Dit is echter niet alles. Stel dat er gebruikgemaakt wordt van een model dat kleiner is dan de volledige GPU. Dan is de ideale situatie dat de GPU opgedeeld wordt in meerdere delen. Dit wordt slicing genoemd. Hierbij is het belangrijk dat het totale aantal modellen dat op één GPU wordt gebruikt, niet over de limiet van het GPU-geheugen heen gaat. Anders gaat de GPU “swappen” en worden modellen telkens uit het geheugen gehaald en opnieuw ingeladen.
Daarnaast is aan te raden om Ollama in productie te vervangen door vLLM. Hiermee kun je specifiekere optimalisaties doen die Ollama vaak zelf automatisch maakt en is er meer controle over hoe het model reageert.
De operationele kant van LLM hosting
Het draaien van modellen in productie brengt weer allerlei nieuwe uitdagingen met zich mee. Bijvoorbeeld: wat is de token-throughput, wat zijn de queue times en hoeveel GPU-geheugen is er in gebruik? Dit brengt weer een hele nieuwe tak van observability aan het licht. Denk hierbij bijvoorbeeld aan het toevoegen van tracing tussen applicatie, vector database, embedding services en inference-API’s.
Ook introduceert het een nieuwe categorie securityproblemen. Prompt injection is daarvan waarschijnlijk de bekendste. Daarbij wordt een model beïnvloed via instructies die verborgen zitten in user input, documenten of externe databronnen. Denk bijvoorbeeld aan content in een PDF, webpagina of knowledge base die door een model wordt geïnterpreteerd als aanvullende instructie.
Wat verandert er wanneer modellen worden geüpdatet?
Modelupdates gedragen zich anders dan reguliere softwarereleases. Een nieuwe modelversie verandert niet alleen functionaliteit, maar ook gedrag, tone of voice en redeneerpatronen.
Veel teams bouwen daarom interne benchmarkdatasets waarmee output tussen modelversies vergeleken kan worden. Daarbij wordt niet alleen gekeken naar correctheid, maar ook naar consistentie, formatting en latency. Canary releases en parallelle evaluaties worden daardoor steeds gebruikelijker binnen grotere AI-platformen.
Tot slot
Het hosten van AI-workloads is zeker een uitdaging. Er worden andere eisen gesteld aan de infrastructuur, die verschillen van reguliere webhosting. Hoe worden de modellen gedraagd? Welk model past bij het doel wat men wil bereiken? En hoe wordt ervoor gezorgd dat de modellen up-to-date blijven binnen de zeer snelle lifecycle van vandaag de dag?
Het biedt zeker ook allerlei nieuwe mogelijkheden. Applicaties kunnen slimmer worden gemaakt; grote delen van herhalende taken automatiseren en mogelijkheden toevoegen die normaal alleen handmatig mogelijk waren.
Tegelijkertijd vervaagt de scheiding tussen applicatieontwikkeling en AI-infrastructuur steeds verder. AI-workloads worden steeds vaker geïntegreerd in bestaande Kubernetes-platformen, CI/CD-pipelines en observability-stacks.
Daarmee verschuift AI-hosting langzaam van experimentele infrastructuur naar een regulier onderdeel van moderne applicatieplatformen.
Heb jij vragen of ben je nou benieuwd naar de mogelijkheden rondom AI-hosting binnen een Managed Kubernetes omgeving? Neem dan contact op via de hosting hotline !
