Zelfbeheerde AI op ondernemingsniveau
In dit artikel delen we hoe Saphes IT Systems vanaf dag één zelfbeheerde AI op ondernemingsniveau heeft aangepakt. We zijn deze weg ingeslagen om twee redenen: we moesten voldoen aan strikte compliance-eisen, en we wilden volledige controle behouden in plaats van afhankelijk te zijn van één leverancier.
Ons werk is nauw verbonden met intellectueel eigendom en gevoelige klantgegevens. Eigen kennis en assets naar een externe AI-leverancier sturen zonder duidelijke garanties en controle roept een simpele vraag op: wat als we onze IP uiteindelijk voor niets weggeven?
Na meer dan twee jaar praktijkgericht experimenteren onder productieomstandigheden hebben we diepgaande expertise opgebouwd in het ontwerpen en beheren van een competitieve zelfbeheerde AI-stack. Vandaag vertaalt die ervaring zich in een platform dat niet alleen conform en beheersbaar is, maar ook sneller en aanzienlijk kostenefficiënter dan veel alternatieven.
In de volgende secties bekijken we de belangrijkste bouwstenen van een zelfbeheerde AI-opstelling voor ondernemingen:
- Hardware en dimensionering (planning op basis van capaciteit en SLO's)
- Modelstrategie (wat te draaien voor welke taken en hoe de levenscyclus te beheren)
- Softwarestack (inference, orkestratie, RAG, observability)
Hardware en dimensionering
Dimensionering begint met een paar praktische doelstellingen: verwacht aantal gebruikers, piekconcurrentie, aanvaardbare latentie (time-to-first-token en tokens/sec) en de mix van workloads (chat, RAG, batchtaken, embeddings). Van daaruit kun je kiezen:
- Compute: CPU versus GPU, GPU-klasse (consument of datacenter) en VRAM-behoefte bepaald door modelgrootte + contextlengte + batchgrootte. Zie PassMark GPU-benchmarks voor vergelijkingen tussen consumenten- en Pro-kaarten.
- Geheugen en opslag: genoeg RAM voor ondersteunende diensten plus snelle lokale opslag voor modelgewichten en caches; plan voor groei naarmate modellen en contextvensters toenemen.
- Netwerk: netwerk met lage latentie tussen inference en ondersteunende diensten (vector-DB, opslag, observability), en genoeg egress-capaciteit als meerdere apps het model aanroepen.
Voor teams die al servers beheren, lijkt dit op capaciteitsplanning voor elk ander intern platform: definieer SLO's, meet, en schaal vervolgens.
Observaties
Deze observaties komen mogelijk niet overeen met jouw exacte behoeften. We raden sterk aan om je toekomstige gebruik samen met een expert te analyseren in plaats van te gokken. De onderstaande voorbeelden zijn observaties uit de praktijk, maar ze zijn niet precies genoeg om op zichzelf de juiste opstelling te kiezen.
| Bedrijfsgrootte | Gebruikstypes | Hardware-opties | Initiële kost |
|---|---|---|---|
| Klein team (2-20 gebruikers), laag gebruik | Interne chat, ad-hoc Q&A, lage concurrentie | CPU-first (Apple M3 Ultra) of 1× Pro GPU 48GB VRAM (bv. RTX PRO 5000) met 64GB RAM en snelle NVMe | ~2k-5k€ |
| Klein team ingenieurs (2-10 gebruikers), hoog gebruik | Interne chat, ad-hoc Q&A, hoge concurrentie, RAG, codegeneratie, codeaanvulling | 2× Pro GPU 96GB VRAM (RTX PRO 5000) of 4× premium en kostenefficiënte consumenten-GPU (RTX 3090) met 128GB RAM en snelle NVMe | ~5k-15k€ |
| Middelgroot bedrijf (50-200 gebruikers), gemengd gebruik | Interne assistent + departementale RAG (HR, Sales, Support), matige concurrentie, enkele batchtaken | 2× datacenter-GPU 80GB (A100 / H100) of 2× 96GB Pro RTX 6000 GPU's, 256-512GB RAM, 2-4× NVMe (RAID); overweeg een aparte node voor vector-DB/ETL | ~20k€-50k€ |
Veelgestelde vragen
Hoeveel kost elektriciteit om het systeem te draaien?
Dit is verwaarloosbaar in vergelijking met de initiële kost of de kosten per token bij AI-leveranciers. Stel dat je 20% van de tijd 100% van je capaciteit gebruikt met 4 consumenten-GPU's (een intensief gebruik). Dan krijg je een factuur van ongeveer 100€/maand. Bij hetzelfde intensieve gebruik bij AI-leveranciers zou je rond 3k-6k€ per maand zitten.
Hoe kies je het juiste moederbord en wat met PCIe?
Dat hangt af van je behoeften. Sommige professionele moederborden zoals de MZ32-AR0 worden aanbevolen, vooral als je meerdere modellen wilt gebruiken en ze snel wilt laden/lossen (PCIe-versie en lanes per slot, hier PCIe 4 16x). Als je op slechts één of twee modellen vertrouwt, kun je ze geladen houden en een consumentenmoederbord zoals een B550 Eagle gebruiken, wat zeer kostenefficiënt is. In feite is de lanesnelheid, zelfs bij PCIe 3 x1, voldoende en is er geen verschil in inferencesnelheid; alleen het laden van modellen wordt veel langer.
Hoe voorzie je 4 GPU's van stroom? Kan ik meerdere voedingen gebruiken?
Ja. We raden aan om meerdere voedingen te gebruiken als je er geen vindt die aan je eisen voldoet. Een voeding kan worden geactiveerd zonder dat je hem op het werkstation hoeft aan te sluiten.
Welke CPU combineer ik met high-end GPU's?
Geef prioriteit aan PCIe-lanes en geheugenbandbreedte: workstation-/server-CPU's (Threadripper/EPYC/Xeon) passen vaak beter dan consumenten-CPU's wanneer je 2-4+ GPU's draait. Vermijd CPU-bottlenecks voor tokenstreaming en RAG-pipelines.
Welke opslagopstelling werkt het best voor modelgewichten en RAG?
Gebruik snelle NVMe voor modelgewichten en hot caches. Aparte volumes (of aparte nodes) voor de vector-DB en logs. RAID1/10 helpt de beschikbaarheid; plan ook back-ups voor indexen en documenten.
Is consumenten-GPU-hardware betrouwbaar genoeg voor productie?
In de meeste gevallen wel. Maar als je klanten bedient en geen hoger operationeel risico accepteert (geen ECC VRAM, minder voorspelbare thermiek), kies dan datacenter-GPU's, gevalideerde chassis en enterprise-support.
Hoe pakken we koeling, geluid en stroomlimieten aan?
Plan eerst de luchtstroom (van voor naar achter, ventilatoren met hoge statische druk), dimensioner voedingen met marge en stel GPU-stroomlimieten in om prestaties/watt te stabiliseren. Overweeg op kantoren een rack op afstand of stillere workstation-builds (vermijd blowersystemen).
Hebben we hogesnelheidsnetwerk (10/25GbE) nodig?
Niet echt. AI-verkeer is vooral tekst, en tekst is licht, dus dit is zelden de bottleneck.
Kan ik AMD- of Intel-GPU's gebruiken?
Het korte antwoord is ja, maar in de praktijk is het vaak niet de moeite waard. Het probleem is ecosysteemondersteuning (ROCm en Intel oneAPI) in vergelijking met CUDA. Zelfs als je wat bespaart op de initiële kost, zul je waarschijnlijk meer worstelen, en soms kun je een bepaald model of een bepaalde functie simpelweg niet gebruiken.
Modelselectie
Opstellingen voor ondernemingen hebben baat bij een doordacht modelbeleid in plaats van "één model voor alles". In de praktijk raden we aan om een kleine "modelportefeuille" te definiëren:
- Primair assistentmodel (de beste kwaliteit die je kunt draaien binnen je latentie-/SLO-beperkingen)
- Kostenefficiënt model voor taken met hoog volume (classificatie, extractie, routering, concepten)
- Embeddingsmodel voor RAG (en optioneel een reranker als retrievalkwaliteit belangrijk is)
Selectiecriteria die we gebruiken:
- Afstemming op taken: chat versus vertalingen versus gestructureerde extractie versus code; geef niet te veel uit aan een groot model voor eenvoudige classificatie.
- Serveerefficiëntie: de KV-cachegrootte groeit met het contextvenster; context is vaak de echte VRAM-bottleneck.
- Licenties en governance: valideer licentiecompatibiliteit (intern gebruik, klantgericht gebruik, herdistributie) en documenteer goedgekeurde modellen. Controleer Hugging Face's modellicenties vóór deployment.
Onze basisaanbevelingen
De onderstaande tabel is bedoeld als vertrekpunt (de exacte VRAM hangt af van de backend, batchgrootte, context en of je meerdere modellen geladen houdt).
| Model | Kwantisatie | Contextvenster | VRAM-grootte | Gebruik |
|---|---|---|---|---|
| Qwen3.6 35b (a3b) | Q5_K_M | 256k | 50GB | Code, agentische taken, algemene taken |
| Qwen3.6 27b | Q5_K_M | 256k | 50GB | Zelfde als de 35b, nauwkeuriger in benchmarks, maar trager |
| GLM 4.7 flash | Q5_K_M | 198k | 50GB | Code, agentische taken, algemene taken |
| TranslateGemma | Q5_K_M | 128k | 35GB | Vertalingen |
| Qwen2.5 Coder 14b (base) | Q5_K_M | 8k (tot 32k) | 25GB | Codeaanvulling |
| Nomic Embed 0.3b | FP16 | 2k | 1GB | Licht, betrouwbaar en draagbaar embeddingsmodel |
| Qwen3 Embedding 4b | Q8_0 | 40k | 20GB | Zeer nauwkeurig embeddingsmodel, maar zwaar, nuttig als je een groot contextvenster nodig hebt |
| Flux 2 Klein 9b | FP8 | / | 10GB | Goed voor fotorealistische resultaten |
| GLM Image | FP8/FP16 | / | 20GB | Goed voor gewone afbeeldingen, inclusief tekst |
Veelgestelde vragen
Welke doorvoer kun je verwachten?
Elk van onze voorbeelden is zeer praktisch. Een 4× RTX 3090 die Qwen 3.6 35B draait met een contextvenster van 256k op llama.cpp levert bijvoorbeeld 120 tokens/sec voor een enkele gebruiker en 70 tokens/sec voor 3 gelijktijdige verzoeken, wat beter is dan bijvoorbeeld de Claude 4.6 API, zonder enige gebruikslimiet.
Hoe kiezen we het juiste contextvenster?
Vertrek vanuit de productbehoefte, niet vanuit de modelspecificatie. Voor de meeste assistenten op ondernemingsniveau is 8k-16k genoeg als je RAG-pipeline goed is (haal minder op, haal beter op). Vergroot het contextvenster alleen wanneer je echte workflows met lange documenten hebt (contracten, grote technische specificaties, code reviews over meerdere bestanden). Onthoud: een langere context verhoogt het VRAM-gebruik (KV-cache) en verlaagt vaak de doorvoer.
Hoe kiezen we de juiste kwantisatie (FP16 vs 8-bit vs 4-bit)?
Gebruik nooit FP16, behalve voor heel kleine modellen of beeldgeneratie; het is de moeite niet waard. 8-bit is zeer goed voor nauwkeurigheidsgevoelige taken met betere geheugenbesparing. 4-bit is meestal de beste kost/prestatie voor chat en RAG in productie, maar valideer op je eigen evalset (sommige taken zoals strikte extractie of meertalige nuances kunnen verslechteren). Bij Saphes raden we Q5-kwantisatie aan; de balans is perfect voor ons gebruik, en we hebben nooit een verslechterde output bij deze kwantisatie vastgesteld.
Wat beïnvloedt het VRAM-gebruik het meest?
Drie belangrijke factoren: (1) modelgewichten, (2) contextvenster (KV-cache) en (3) batching/concurrentie. Veel teams onderschatten de KV-cache: het verdubbelen van de context kan het VRAM-gebruik aanzienlijk verhogen, vooral bij hogere concurrentie.
Moeten we een groot model draaien of meerdere kleinere?
Geef de voorkeur aan meerdere modellen wanneer je een duidelijke taakscheiding hebt: een sterk assistentmodel voor "moeilijke" verzoeken, en een goedkoper model voor routering, samenvatting, extractie of concepten. Dit verlaagt de kost en verbetert de latentie onder belasting.
Hebben we een reranker nodig voor RAG?
Als je documenten ruis bevatten of lang zijn en retrievalkwaliteit belangrijk is (supportkennisbanken, juridische/technische content), verbetert een reranker vaak de nauwkeurigheid meer dan het vergroten van het contextvenster. Als je corpus klein en schoon is, kun je hem overslaan.
Waarom geen groot model zoals Kimi k2.5?
Zodra je een bepaalde schaal bereikt, hebben extra parameters steeds minder impact op de kwaliteit. Een model zoals Qwen 3.6 is vandaag meer dan genoeg voor complexe agentische taken; je hoeft niet te vertrouwen op "frontier" open-source modellen zoals Deepseek V4. Het prestatieverschil is de moeite niet waard: een kleiner, goed geconfigureerd model is meer dan genoeg, en veel sneller.
Moet ik meerdere modellen gebruiken of een groot flagship-model?
We raden aan om een flagship-model te hebben, altijd geladen op je GPU's, gebruikt voor de meeste taken. Houd wat VRAM vrij voor nuttige kleinere modellen zoals een vertaalspecialist en codeaanvulling; die nemen niet veel VRAM in en zijn heel snel in wat ze doen. Dit helpt ook om gelijktijdige verzoeken van je flagship-model af te leiden.
Softwarestack / tooling
Een typische zelfbeheerde stack is modulair en kan klein beginnen:
Inference
Voor inference zijn er momenteel drie echte uitdagers. Elk biedt een OpenAI-compatibele API, en elk heeft sterke punten en afwegingen:
| Oplossing | Voordelen | Nadelen |
|---|---|---|
| Ollama | Snel op te zetten, gebruiksvriendelijk: een paar commando's en je model draait. | Trager dan de andere oplossingen; laadt/lost modellen vaak als een verzoek niet overeenkomt met wat al geladen is. |
| Llama server (llama.cpp) | Zeer snel en solide voor concurrentie; veel aanpassingsmogelijkheden; brede modelkeuze en formaatondersteuning. | Laadt één model tegelijk; langer om op te zetten dan Ollama. |
| vLLM | Uitstekend voor concurrentie; de juiste keuze voor een flagship-model op schaal; laat veel aanpassing toe. | Trager dan llama.cpp voor enkele verzoeken; langer om op te zetten dan Ollama; minder ondersteunde formaten dan llama.cpp. |
UI / Gateway
Er is één uitblinker: Open WebUI. Open WebUI fungeert als gateway en biedt fijnmazige toegangscontrole. Het komt ook met veel functies, waaronder het proxen van Ollama (als je het gebruikt) en andere verbonden OpenAI-compatibele API's.
Open WebUI kan worden gekoppeld aan ComfyUI voor beeldgeneratie; ze werken goed samen en creëren een GPT-achtige ervaring voor beeldgeneratie.
RAG
Een RAG-systeem (Retrieval-Augmented Generation) is cruciaal voor veel use cases, en hoe meer documenten je bedrijf heeft, hoe belangrijker het wordt. RAG laat je stukken van je documenten opslaan en, in plaats van 300 pagina's in het contextvenster te injecteren voor elke vraag, alleen de relevante delen op te halen samen met metadata (documentnaam, paginareferentie, enz.). Lees meer over RAG-architectuur en best practices.
Voor ontwikkelingsdoeleinden is RAG vaak minder nuttig (bijvoorbeeld: een hele codebase opnieuw embedden voor elke branch is niet realistisch). Daarentegen kan het embedden van gestructureerde documentatie voor een framework of taal zeer nuttig zijn.
Voordat je een RAG-systeem opzet (wat eenvoudig te starten is), is het belangrijkste onderdeel het bepalen van wat in je database moet staan en welke metadata je nodig hebt. Architectuur is belangrijk: die bepaalt of je RAG-systeem in de praktijk bruikbaar zal zijn.
Je kunt ChromaDB of Qdrant op je server draaien. Beide zijn goed; we raden Qdrant aan omdat het snel en goed ontworpen is (deze aanbeveling is persoonlijk).
Code-editors
Voor local-first, AI-ondersteunde ontwikkeling raden we de volgende opstelling aan:
Zed: onze standaardaanbeveling. Het integreert AI native, ondersteunt ACP en andere moderne tooling, en is extreem snel en responsief. Zie Zed's AI-documentatie voor installatiedetails.
VS Code of JetBrains:
- Continue voor codeaanvulling en snelle chat-achtige antwoorden.
- Cline voor meer agentische workflows (taken in meerdere stappen, wijzigingen over de hele repo, tooling-orkestratie).
MCP's
Er zijn volop MCP's op de markt. De juiste zijn simpelweg degene die je nodig hebt. Wat het meest telt, is deployment: MCP's kunnen op meerdere manieren draaien en ondersteunen verschillende verbindingstypes. We raden streamable HTTP-verbindingen aan voor MCP's die met je server moeten verbinden, en het draaien ervan direct op de server.
Een solide set MCP's, of het bouwen van degene die je nodig hebt, kan een game changer zijn. MCP's worden vooral beperkt door verbeelding: je kunt een MCP ontwikkelen om te praten met je e-commerceplatform, CMS, content te maken en op te halen, producten te maken, en nog veel meer. Lees meer over de Model Context Protocol-specificatie en verken het MCP Registry voor door de community gebouwde integraties.
Slotgedachten
Vandaag is het integreren van zelfbeheerde AI in een bedrijf geen moonshot meer: het is concreet en haalbaar. Modellen zijn nu slim en snel genoeg om complexe taken aan te kunnen, een goed geconfigureerd RAG-systeem kan de meeste geautomatiseerde RAG-oplossingen op de markt overtreffen, UI-tools zijn gebruiksvriendelijk geworden, en ROI wordt vaak snel bereikt, doorgaans binnen 6 tot 24 maanden afhankelijk van de complexiteit van je systemen.
Dat gezegd zijnde, zijn er belangrijke overwegingen. De initiële opzet kan ingewikkeld zijn: driverproblemen, tools verbinden, het RAG-systeem configureren en de juiste modellen kiezen. Voor ons is de grootste kost niet de hardware, maar de tijdrovende opzet, terwijl het lopende onderhoud meestal veel eenvoudiger is.
