LLM serveren in productie: vLLM vs SGLang vs Ollama

Een bedrijf zet een lokaal model op via Ollama, schrijft een interne chatbot, het team is enthousiast. Drie maanden later komen er meer gebruikers bij, de wachtrij groeit, de responstijd stijgt van twee seconden naar vijftien. Iemand zegt: "we kopen een krachtigere GPU." Gedaan. De responstijd daalt naar acht seconden. Het probleem is niet de hardware — het probleem is de serving stack, die niet ontworpen was voor productiebelastingen.

Dit is een scenario dat we regelmatig tegenkomen. Niet omdat teams iets doms doen — Ollama is een uitstekend hulpmiddel voor waarvoor het ontworpen is. Het probleem ontstaat wanneer een ontwikkeltool in productie belandt zonder dat iemand de vraag stelt: "wat verwachten we eigenlijk van een serving stack?" Dit artikel biedt beslissingscriteria in plaats van een algehele aanbeveling — want de juiste keuze hangt af van de belasting, het team en de infrastructuur.

Waarom de serving stack er meer toe doet dan het lijkt

Een serving framework is niet zomaar een "wrapper om een model heen." Het is een orchestrator die beslist hoe parallelle verzoeken worden gebatched, hoe de KV-cache wordt beheerd en hoe geheugen wordt toegewezen bij meerdere gelijktijdige verzoeken.

Klassieke statische batching wacht totdat een batch gevuld is en stuurt dan alle requests tegelijk — het model draait, de resultaten worden teruggegeven, er wordt gewacht op de volgende batch. Dat is eenvoudig, maar de efficiëntie daalt wanneer korte en lange requests door elkaar lopen. Continuous batching (geïmplementeerd in vLLM, SGLang en TGI) lost dit anders op: elke gegenereerde token is een kans om een nieuw verzoek dat zojuist is binnengekomen aan de batch toe te voegen. Het resultaat is 2–3× hogere throughput zonder hardware-aanpassing.

Een andere kritische dimensie is het beheer van de KV-cache — tussenresultaten van de attention-mechanismen die worden opgeslagen voor elk token in de context. Een naïeve implementatie reserveert geheugen voor de maximaal mogelijke contextlengte vooraf, ook als de meeste verzoeken veel korter zijn. PagedAttention (vLLM) lost dit op door de KV-cache te pagineren zoals een OS RAM pagineert — zonder voorafgaande reservering, met dynamische toewijzing. Het resultaat is een dramatische afname van fragmentatie: van doorgaans 60–80 % verspilling naar minder dan 4 %.

Deze verschillen komen in een productieomgeving met tientallen gelijktijdige verzoeken veel sterker tot uiting dan eenvoudige benchmarks op één enkel verzoek laten zien.

vLLM: throughput als primaire prioriteit

vLLM is de de facto standaard voor productie-LLM-serving wanneer maximale throughput op NVIDIA GPU de primaire prioriteit is. Ontwikkeld aan UC Berkeley, beschikt over het breedste integratie-ecosysteem en wordt actief doorontwikkeld.

Belangrijkste technische eigenschappen:

• PagedAttention — KV-cachebeheer via virtuele pagina's, vermindert geheugen­fragmentatie drastisch en maakt hogere parallelisatie mogelijk
• Continuous batching — dynamisch requests toevoegen aan de huidige batch zonder te wachten
• OpenAI-compatibele API — migratie van cloud-API naar self-hosted is doorgaans een kwestie van URL en API-sleutel aanpassen
• Ondersteuning voor NVIDIA, AMD (ROCm), Google TPU, Intel Gaudi
• Ingebouwde ondersteuning voor GPTQ-, AWQ-, FP8- en NVFP4-kwantisatie
• XGrammar-backend voor gestructureerde uitvoer (JSON mode) met een overhead van minder dan 40 µs per token

Wanneer vLLM duidelijk wint:

Wanneer u een API-eindpunt beheert dat door meerdere gebruikers of processen tegelijk wordt aangesproken — een interne bedrijfschatbot, een RAG-backend met hoger volume, een API-server voor een productieapplicatie. Als u benchmarkt op single-request latentie, is het verschil met de concurrentie kleiner. Maar bij 8, 16 of 32 gelijktijdige verzoeken wordt het onderscheid duidelijk zichtbaar.

Op Blackwell GPU met NVFP4-kwantisatie laten benchmarks tot ~16× hogere throughput zien ten opzichte van Ollama op dezelfde hardware — een verschil dat de economie van het hele project verandert.

Beperkingen:

vLLM kent een steilere leercurve. Configuratie voor productie-deployment vereist begrip van parameters als --tensor-parallel-size, --max-model-len, --gpu-memory-utilization. Voor een team zonder LLM-infrastructuurervaring is de initiële setup niet triviaal. Voor puur CPU-gebruik of consumentenhardware zonder NVIDIA GPU is het ecosysteem minder sterk.

SGLang: complexe workloads en gestructureerde uitvoer

SGLang (Structured Generation Language) is in een onderzoeksomgeving ontstaan met de focus op een andere klasse problemen: multi-turn gesprekken, agentische workloads met lange prefixen en gestructureerde uitvoer (JSON-schema's, grammatica's).

De sleutelinnovatie is RadixAttention — een LRU-cache van KV-waarden georganiseerd in een radixboom. Wanneer meerdere verzoeken hetzelfde prefix delen (bijvoorbeeld hetzelfde systeemprompt of dezelfde documentcontext), berekent SGLang dit prefix eenmalig en deelt het over de verzoeken. In agentic RAG-scenario's, waarbij elk verzoek begint met dezelfde lange documentcontext, kan dit een enorm verschil maken.

Waar SGLang vLLM overtreft:

Op prefix-heavy workloads laten benchmarks ~29 % hogere throughput op H100 zien en ~23 % lagere TTFT (Time to First Token) — 79 ms versus 103 ms. Dit zijn geen verwaarloosbare cijfers bij interactieve applicaties waarbij TTFT de gepercipieerde snelheid direct beïnvloedt.

Voor gestructureerde decodering (JSON mode, grammatica's) is SGLang sneller: geconstrainde decodering verloopt ~3× sneller dan bij oudere implementaties, doordat grammatica-compilatie efficiënter verloopt.

Typische use cases waar SGLang uitblinkt:

• Multi-turn agentische workloads waarbij elke ronde een lang historieprefix deelt
• Batch-inferentie over een groot documentcorpus met hetzelfde systeemprompt
• Applicaties met intensieve JSON-uitvoer (extractie van gestructureerde data, classificatie)
• RAG-pipelines waarbij hetzelfde document meerdere keren per sessie wordt bevraagd

Beperkingen:

SGLang heeft een iets kleiner ecosysteem dan vLLM en een kleinere community, wat merkbaar is in de snelheid waarmee randgevallen worden opgelost en in de beschikbaarheid van documentatie. Voor standaard inference-workloads zonder prefixoptimalisaties is het verschil met vLLM kleiner en hangt de keuze eerder af van de voorkeur van het team.

Ollama: developer experience op de eerste plaats

Ollama is een andere categorie hulpmiddel. Het is geen productie-serving framework — het is een ontwikkelaarsdesktoptool die één ding uitstekend doet: een lokaal model in vijf minuten draaien, zonder configuratie, op willekeurige hardware inclusief Mac, Linux en Windows.

Onder de motorkap draait llama.cpp, geoptimaliseerd voor CPU-inferentie en efficiënt werken met GGUF-gekwantiseerde modellen. Voor single-user experimenteren en ontwikkeling is dit de perfecte stack.

Waar Ollama zinvol is:

• Ontwikkelaarsdesktop — lokale experimenten, prototyping, modellen testen
• Single-user interne tools met lage belasting (één à twee gelijktijdige gebruikers)
• Teams zonder DevOps-ervaring die snel iets werkends nodig hebben
• Mac- of Windows-omgevingen waar vLLM/SGLang geen native GPU-ondersteuning bieden (of beperkt)
• On-device deployment op ontwikkelaarslatops

Waarom Ollama niet volstaat voor productie:

llama.cpp, dat onder Ollama draait, is niet ontworpen voor gelijktijdige verzoeken. Wanneer er 8 parallelle requests binnenkomen, wordt de wachtrij serieel verwerkt — zonder continuous batching. Benchmarks laten consistent zien dat vLLM op dezelfde hardware bij 8 gelijktijdige verzoeken ~2,3× sneller is. Bij 16 verzoeken is het verschil nog groter.

Dit is geen bug in Ollama — het is het gevolg van ontwerpkeuzes die eenvoud en compatibiliteit boven throughput stellen. Voor de ontwikkelaarsdesktop is dat de juiste afweging. Voor een productie-eindpunt met tientallen gebruikers is het een probleem.

Beslissen op basis van belasting en team

In plaats van een algehele aanbeveling bieden we een beslissingsmatrix:

Klein team (2–5 personen), beginnen met lokale LLM, experimenteren: Begin met Ollama. U leert werken met modellen zonder infrastructuurlast. Wanneer u tegen de prestatiegrens aanloopt (en dat zult u), zal duidelijk zijn waarom migratie nodig is.

Productie-API-eindpunt met meerdere gelijktijdige gebruikers, NVIDIA GPU: vLLM is de standaardkeuze. Breedste ecosysteem, beste documentatie, OpenAI-compatibele API. Als het team geen LLM-infrastructuurervaring heeft, reken erop dat de setup dagen kost, niet uren.

Agentische applicaties, RAG met lange herhalende prefixen, intensieve JSON-uitvoer: Overweeg SGLang — RadixAttention bespaart u GPU-geheugen en latentie bij prefix-heavy workloads. Voor teams die vLLM al hebben uitgerold en het goed werkt, is er geen reden om te migreren voor een marginale verbetering. SGLang is relevant wanneer u weet dat uw workload prefix-heavy is.

NVIDIA Blackwell (GB200/B200), maximale prestaties: vLLM of TensorRT-LLM — beide zijn geoptimaliseerd voor NVFP4-kwantisatie op Blackwell GPU. TensorRT-LLM haalt hogere piekprestaties, maar brengt aanzienlijk hogere setup- en operationele complexiteit met zich mee.

Gereguleerde omgeving, air-gapped netwerk, geen cloudafhankelijkheden: Alle drie draaien volledig offline. Voor productie-deployment in een gereguleerde omgeving bevelen we vLLM aan vanwege het ecosysteem en de auditeer­baarheid. Meer over de specifics van gereguleerde deployments in het artikel On-prem LLM voor gereguleerde sectoren.

Wat een serving stack niet is: onderscheid van kwantisatie en GPU-sizing

Wanneer bedrijven beginnen met "hoe zetten we een LLM in productie?", lopen drie onderwerpen regelmatig door elkaar: serving stack, kwantisatie en GPU-sizing. Het zijn afzonderlijke beslissingen met verschillende prioriteit.

Kwantisatie is een beslissing over de numerieke precisie van de modelgewichten (FP16 vs Q8 vs Q4 vs GPTQ/AWQ). Het beïnvloedt de modelgrootte in geheugen en de inferentiesnelheid bij aanvaardbaar kwaliteitsverlies. Q4_K_M zit binnen ~5–8 % van FP16 op de meeste benchmarks — een verschil dat bij de meeste productie-use-cases niet waarneembaar is. Kwantisatie staat los van de keuze voor de serving stack: u kunt een gekwantiseerd model zowel via vLLM als via Ollama draaien. Meer over de formaten in het artikel Kwantisatie van LLM (GGUF, AWQ, GPTQ).

GPU-sizing is een beslissing over hoeveel VRAM (en hoeveel GPU's) u nodig heeft voor een gegeven model en belasting. Dit is een afzonderlijke berekening: VRAM voor modelgewichten + KV-cache voor het verwachte aantal gelijktijdige verzoeken × contextlengte. Een slechte serving stack op de juiste hardware presteert nog altijd slecht; de juiste serving stack op onderbemeten hardware evenmin. Meer over concrete VRAM-berekeningen in het artikel Welke GPU voor LLM-inferentie.

De volgorde van beslissingen in de praktijk: eerst het model (omvang, capaciteiten), dan kwantisatie (vermindert geheugenvereisten), dan GPU-sizing (hoeveel VRAM nodig), ten slotte de serving stack (hoe de belasting wordt afgehandeld). Veel teams doen dit in omgekeerde volgorde en vragen zich vervolgens af waarom optimalisatie niet helpt.

KV-cache en lange context: de verborgen geheugenbelasting

Een getal dat bij het vergelijken van serving stacks onderschat wordt: de KV-cache groeit lineair met de contextlengte. Voor een 70B-model bij 128K context kan de KV-cache alleen al zo'n 40 GB innemen — bovenop de modelgewichten. Voor vier parallelle verzoeken met een dergelijke context is dat ~160 GB extra.

Moderne modellen met Grouped Query Attention (GQA) verminderen deze last drastisch ten opzichte van klassieke multi-head attention — de meeste actuele modellen (Llama 4, Qwen 3, Mistral Large) beschikken over GQA. Een verdere optimalisatie is KV-cache kwantisatie naar INT8/FP8, waarmee de omvang wordt gehalveerd met minimaal kwaliteitsverlies.

Voor workloads met lange context — zoals de verwerking van lange industriële documenten of meerdere gespreksronden in technische ondersteuning — is dit getal doorslaggevend bij de GPU-configuratiebeslissing. vLLM beheert de KV-cache via PagedAttention dynamisch en efficiënter dan naïeve implementaties; SGLang deelt via RadixAttention bovendien de KV-cache voor herhalende prefixen.

Praktische consequentie: "1M token context window" klinkt indrukwekkend voor een klant. In de praktijk vereist elk verzoek met 1M tokens tientallen gigabytes aan KV-cache. Voor de meeste productie-use-cases is RAG economisch voordeliger dan het hele document in de context laden — ook als het model technisch lange context ondersteunt.

Monitoring en observability in productie

Welke serving stack u ook kiest, een productie-deployment zonder monitoring is vliegen op de tast. Drie metreken om vanaf dag één bij te houden:

TTFT (Time to First Token) — hoe lang het duurt voordat het model het eerste token produceert. Heeft direct invloed op de gepercipieerde snelheid bij interactieve applicaties. Voor conversationele UI's is TTFT onder 300–500 ms de grens waarbij de gebruiker de respons als "direct" ervaart.

Throughput (tokens/seconde) — globaal en per verzoek. Belangrijk voor batch-workloads en bij capaciteitsplanning.

Wachtrijdiepte en wachtrijlatentie — wanneer de wachtrij groeit, is dat een signaal voor ofwel horizontale schaling, ofwel herziening van de batching-configuratie. Een groeiende wachtrij bij stabiele TTFT duidt erop dat het probleem capaciteit is, niet serving-efficiëntie.

Zowel vLLM als SGLang exporteren native Prometheus-metreken — een Grafana-dashboard is een kwestie van een uur werk. Voor teams die ook de kostenkant willen optimaliseren, is LLM-routing een interessante aanpak: eenvoudige verzoeken doorsturen naar een kleiner, goedkoper model en complexe naar een groter. Hierover meer in het artikel LLM routing en cascading.

Veelgestelde vragen

Kan ik Ollama in productie gebruiken als ik slechts één à twee gelijktijdige gebruikers heb?

Ja, voor echt lage belasting — één team, een handvol mensen, lage requestfrequentie — werkt Ollama in productie. Het probleem ontstaat bij groei. Wanneer de belasting verdubbelt en Ollama het niet bijhoudt, is migratie naar vLLM geen triviale stap: ander configuratiemodel, ander procesbeheer, andere deploymentpatronen. Als u verwacht dat de belasting zal groeien, loont het om de serving stack meteen goed op te zetten.

Is vLLM of SGLang beter voor RAG-applicaties?

Dat hangt af van de concrete RAG-architectuur. Als elk verzoek begint met hetzelfde systeemprompt met weinig variatie en korte documenten per verzoek wisselen, zijn vLLM en SGLang vergelijkbaar. Als de architectuur een lange documentcontext over meerdere verzoeken binnen één sessie deelt (bijvoorbeeld analyse van een lang handboek met meerdere vragen), kan RadixAttention in SGLang aanzienlijk geheugen en latentie besparen. Voor meer over RAG-architecturen, zie Agentic RAG.

Hoe verschilt vLLM van TensorRT-LLM?

TensorRT-LLM van NVIDIA behaalt hogere piekprestaties op NVIDIA-hardware (met name Blackwell) dankzij fused kernels en NVFP4-kwantisatie. De prijs is aanzienlijk hogere complexiteit: modellen moeten vóór deployment worden gecompileerd, de pipeline is minder flexibel, de setup duurt langer. vLLM is in de meeste productiescenario's de pragmatischer keuze — u krijgt 80–90 % van de TensorRT-LLM-prestaties voor een fractie van de operationele complexiteit. TensorRT-LLM is zinvol bij extreme throughput-vereisten of wanneer u optimaliseert voor een specifiek model op specifieke hardware.

Werken deze frameworks ook met gekwantiseerde modellen?

Ja, alle drie ondersteunen gekwantiseerde modellen. vLLM en SGLang verwerken native AWQ- en GPTQ-formaten en beschikken over FP8/NVFP4-ondersteuning voor Blackwell GPU. Ollama werkt primair met het GGUF-formaat (llama.cpp). Voor productie-deployment op NVIDIA GPU is AWQ of GPTQ doorgaans voordeliger dan GGUF, omdat geoptimaliseerde CUDA-kernels worden benut. Voor cross-platform- of CPU-deployment is GGUF praktischer.

Hoe snel kan ik migreren van Ollama naar vLLM?

Als uw applicatie communiceert via een OpenAI-compatibele REST API (wat het geval is bij de meeste Ollama-deployments), is migratie naar vLLM vanuit de applicatiecode slechts een aanpassing van de basis-URL en de API-sleutel. Het zwaardere werk zit aan de infrastructuurkant: deployment, monitoring, capaciteitsconfiguratie. Voor een team dat dit voor het eerst doet, rekent u op één à twee dagen werk voor een werkende productie-deployment.

*Bij MP Industrial Solutions helpen we bedrijven bij het ontwerpen en implementeren van LLM-infrastructuur die aansluit bij de werkelijke belasting en het team — niet alleen bij een demo. Als u overweegt welke serving stack geschikt is voor uw use case, of als Ollama onder belasting begint te kreunen, beoordelen we dat graag samen met u.*