Waarom vertraagt een zelfgehoste LLM bij meer gebruikers?

Waarom vertraagt een zelfgehoste LLM wanneer er meer gebruikers bijkomen?

Een zelfgehoste LLM loopt vast bij 5 gelijktijdige gebruikers omdat de server nog steeds één antwoord tegelijk genereert, terwijl de andere vier in een wachtrij staan. De documentatie van Ollama is duidelijk over de standaardinstelling: OLLAMA_NUM_PARALLEL is "het maximale aantal parallelle verzoeken dat elk model tegelijkertijd verwerkt, standaard 1." Er is niets defect. Vier van uw vijf gebruikers wachten op hun beurt.

De oplossing is zelden een krachtigere server. Het is een serving engine die meerdere verzoeken in één forward pass door het model stuurt, gecombineerd met voldoende extra geheugen om alle conversaties vast te houden tijdens dit proces. Beide onderdelen zijn van belang, waarbij het tweede onderdeel daadwerkelijk uw limiet bepaalt.

De twee fasen die elk verzoek doorloopt

Prefill leest de volledige prompt in één keer en bouwt de attention cache op. Elke prompt-token doorloopt het model tegelijkertijd; prefill is daarom één grote matrixvermenigvuldiging die wordt beperkt door de rekenkracht (arithmetic throughput). Decode schrijft vervolgens het antwoord token voor token. Voor elke token moeten de volledige gewichten van het model opnieuw uit het geheugen worden gelezen, terwijl de rekenkundige bewerkingen voor die ene token minimaal zijn. Decode wordt beperkt door de geheugenbandbreedte.

Deze asymmetrie is de reden waarom batching werkt. Bij het decoderen voor één gebruiker wordt bijvoorbeeld 5 GB aan gewichten per token gelezen, terwijl het grootste deel van de rekenunits onbenut blijft. Voeg een tweede verzoek toe en de engine leest dezelfde 5 GB één keer, om vervolgens twee tokens te berekenen. De tweede gebruiker kost vrijwel geen extra tijd. Het strikt na elkaar afhandelen van verzoeken maakt dit voordeel ongedaan.

Twee getallen bepalen de gebruikerservaring. TTFT (time to first token) is de wachtrijtijd plus de prefill-tijd. ITL (inter-token latency) is de pauze tussen gestreamde tokens en wordt bepaald door de decode-fase. Een trage server is meestal traag in een van deze twee, en de oplossingen verschillen. Het is zinvol om vast te stellen met welk probleem u te maken heeft voordat u instellingen wijzigt, en het afzonderlijk meten van prefill en decode is de manier om daarachter te komen.

Statische batching dwingt iedereen te wachten op het traagste antwoord

Statische batching is de naïeve methode; dit is wat u krijgt als u verzoeken zelf groepeert in de applicatiecode. De engine verzamelt N verzoeken, voert deze tegelijkertijd uit en houdt elke slot bezet totdat de langste generatie in de groep is voltooid.

Eén gebruiker die om een samenvatting van 1.200 tokens vraagt, houdt vier antwoorden van één regel vast in de batch, omdat de batch geen enkele slot vrijgeeft totdat het traagste lid klaar is.

Dit brengt twee kosten met zich mee. Voltooide sequenties blijven slots bezetten die geen nuttige berekeningen uitvoeren, waardoor de effectieve doorvoer daalt naarmate de uitvoerlengtes variëren, en chat-uitvoerlengtes variëren aanzienlijk. Een verzoek dat één stap nadat de batch is gevormd binnenkomt, moet wachten tot de volledige batch is afgehandeld voordat het zelfs met de prefill kan beginnen. Dit betekent dat de TTFT wordt bepaald door het essay van iemand anders.

Continuous batching accepteert en beëindigt verzoeken per token

Continuous batching plant taken op het niveau van een enkele decoderingsstap. Na elke stap verwijdert de scheduler sequenties die zojuist hun stop-token hebben gegenereerd en voegt vervolgens wachtende verzoeken toe aan de vrijgekomen slots. Een antwoord dat eindigt bij stap 40, maakt het slot vrij bij stap 40 en niet pas aan het einde van een batch.

Dit is geen exotische techniek. llama-server documenteert -cb, --cont-batching als "of continuous batching (ook wel dynamic batching genoemd) moet worden ingeschakeld (standaard: ingeschakeld)", en vLLM is volledig rond dit concept gebouwd. Ollama verwerkt eveneens parallelle verzoeken. De standaardinstelling beperkt het aantal echter tot één; dit is de reden waarom veel gebruikers concluderen dat hun hardware geen concurrency ondersteunt, terwijl hun configuratie dit expliciet blokkeerde.

Gepubliceerde resultaten voor continuous batching worden doorgaans gemeten op datacenter-kaarten die zowel over rekenkracht als over tientallen gigabytes aan cachegeheugen beschikken. De vorm van die resultaten is representatief voor uw systeem. De omvang ervan echter niet, en de sectie over geheugen hieronder legt uit waarom.

Prefill concurreert met decode om dezelfde rekenkracht

Wanneer een nieuw verzoek binnenkomt terwijl er vier antwoorden worden gestreamd, moet de prompt eerst worden geprefilled, en prefill is rekenintensief. Als de scheduler die prefill een eigen stap geeft, ontvangen de vier streamende gebruikers tijdens die stap geen token. Bij een lange prompt is dit een zichtbare pauze in elk open venster. Dit is de hapering die mensen bedoelen wanneer ze zeggen dat de server stottert zodra iemand anders op verzenden drukt.

Chunked prefill breekt een lange prompt op in stukken en mengt elk stuk in dezelfde stap als de actieve decodes. De tuning-handleiding van vLLM stelt de afweging direct vast: kleinere chunk-budgetten "bereiken een betere ITL omdat er minder prefills zijn die de decodes vertragen", terwijl hogere waarden "een betere time to first token (TTFT) bereiken omdat u meer prefill-tokens in een batch kunt verwerken". U kiest wiens ervaring u beschermt: de persoon die wacht tot een antwoord begint, of de mensen die tekst zien streamen.

De lengte van de prompt bepaalt hoe erg dit effect is. Een prompt van 6.000 tokens met een antwoord van 200 tokens betekent 6.000 tokens aan prefill-werk tegenover 200 decode-stappen. Retrieval-augmented chat en lange systeemprompts duwen u beide in dat regime, waardoor prefill geen verwaarloosbare factor meer is, maar het punt waar gebruikers op wachten. Prefix caching helpt wanneer het lange gedeelte zich herhaalt: vLLM stelt --enable-prefix-caching beschikbaar, wat de cache hergebruikt voor een gedeeld prompt-prefix in plaats van deze voor elk verzoek opnieuw te berekenen.

Het geheugen dat als eerste opraakt is de KV cache

Elke token in elke actieve conversatie laat een key-vector en een value-vector achter in elke laag van het model. Dit is de KV cache (key/value cache), en deze zorgt ervoor dat het decoderen niet voor elke nieuwe token de volledige prompt opnieuw hoeft te berekenen. De grootte per token staat vast op basis van de vorm van het model: 2 (één key, één value) maal het aantal lagen, maal het aantal key/value-heads, maal de head-dimensie, maal het aantal bytes per waarde. Lees deze getallen uit de config.json van het model.

Bereken dit één keer en het plafond is geen mysterie meer. Een typisch 8B-model met 36 lagen, 8 key/value-heads en een head-dimensie van 128, waarbij de cache in 16-bit wordt opgeslagen, kost 2 36 8 128 2 bytes per token. Dat is 147.456 bytes, ongeveer 144 KiB. Eén conversatie van 8.192 tokens vereist daarom ongeveer 1,2 GB aan cache. Vijf van dergelijke conversaties vereisen ongeveer 6 GB, bovenop de gewichten, en dat is het werkelijke antwoord op hoeveel gebruikers er passen.

Gelijktijdigheid vermenigvuldigt de context, en de tools geven dit expliciet aan. De FAQ van Ollama: "Parallelle verwerking van verzoeken voor een bepaald model resulteert in een toename van de contextgrootte met het aantal parallelle verzoeken. Een context van 2K met 4 parallelle verzoeken resulteert bijvoorbeeld in een context van 8K en extra geheugentoewijzing." Het vereiste RAM-geheugen schaalt met OLLAMA_NUM_PARALLEL vermenigvuldigd met OLLAMA_CONTEXT_LENGTH. In llama-server wordt de context waar u om vraagt met -c verdeeld over de -np slots, waardoor het verhogen van het aantal slots op zichzelf de capaciteit per verzoek verkleint. Lees de context per slot uit het opstartlogboek in plaats van er zomaar vanuit te gaan.

vLLM reserveert vooraf geheugen. --gpu-memory-utilization (standaard 0.92) is "de fractie van het GPU-geheugen die moet worden gebruikt voor de model-executor". Wat er overblijft na het laden van de gewichten wordt de paged KV-pool, en wanneer die pool tekortschiet, stoot de scheduler een verzoek af in plaats van het te laten falen:

WARNING 05-09 00:49:33 scheduler.py:1057] Sequence group 0 is preempted by PreemptionMode.RECOMPUTE mode because there is not enough KV cache space.

In de V1-engine van vLLM is de standaard preemption-modus RECOMPUTE, wat betekent dat een afgestoten verzoek zijn cache weggooit en opnieuw prefills uitvoert wanneer het weer wordt toegelaten. Dat werk wordt dus dubbel gedaan. De documentatie waarschuwt dat "preemption en herberekening de end-to-end latentie nadelig kunnen beïnvloeden", en deze logregel is de beste verklaring voor waarom één ongelukkige gebruiker veel langer moest wachten dan de rest, terwijl uw gemiddelde er gezond uitzag. Stel disable_log_stats=False in om het cumulatieve aantal te loggen, of lees de preemption-teller uit de Prometheus-metrics die vLLM beschikbaar stelt.

Wat verandert er bij 2, 5 en 20 gelijktijdige gebruikers

Twee gebruikers. Vrijwel onzichtbaar op een GPU met voldoende cache, omdat de tweede decode-stream met minimale extra tijd meelift op de eerste. Op een VPS met alleen een CPU en 4 tot 8 GB RAM is dit niet gratis: beide streams delen hetzelfde handjevol vCPU's en dezelfde RAM-bandbreedte. Elke gebruiker ziet daardoor ongeveer de helft van het aantal tokens per seconde, en de vraag naar cache verdubbelt terwijl het beschikbare budget veel kleiner is.

Vijf gebruikers. Hier volstaan de standaardinstellingen niet meer en begint het als een wachtrijprobleem. Bij OLLAMA_NUM_PARALLEL op 1 wachten vier mensen op degene die om het lange antwoord vroeg, en zodra hun beurt aanbreekt, ziet ieder van hen een normale snelheid. Verhoog het aantal parallelle taken en het probleem verandert van aard: vijf slots met elk 8K context vereisen 40K aan token-cache. Als dit niet in het VRAM past, verplaatst de engine lagen naar het systeem-RAM. Past het ook daar niet in, dan gaat het systeem swappen en storten de tokens per seconde in.

Twintig gebruikers. Twintig mensen in een chat-UI zijn meestal geen twintig gelijktijdige verzoeken, en dit is het belangrijkste om te begrijpen voordat u hardware aanschaft. Een persoon leest een antwoord en denkt 20 tot 60 seconden na tussen de beurten door, waardoor het grootste deel van de sessie inactief is. Twintig agents, of twintig taken voor het samenvatten van documenten, zijn twintig echte streams zonder enige inactiviteit. Dat vereist een andere machine. Een ontwikkelaar die een coding agent naar zijn eigen Ollama server heeft gewezen zit dichter bij het tweede scenario dan bij het eerste, omdat de agent verzoeken blijft sturen zolang de taak loopt en geen van de leespauzes inlast die een mens wel heeft.

Zijn uw gebruikers gelijktijdig actief, of enkel ingelogd?

Bepaal het aantal gelijktijdige verzoeken voordat u de schaal bepaalt. De berekening is eenvoudig: het aantal gelijktijdige verzoeken is gelijk aan het aantal gebruikers, vermenigvuldigd met het aantal seconden dat nodig is voor het genereren per beurt, gedeeld door het aantal seconden tussen de beurten.

1. Meet eerst uw eigen snelheid voor een enkele stream, inclusief prefill en decode. Neem geen getallen over van andermans kaart: meet tokens per seconde op uw eigen systeem en gebruik het resultaat dat u krijgt.
2. Schat de duty cycle. Twintig chatgebruikers, 12 seconden generatietijd per beurt, één beurt per 90 seconden, geeft 20 * 12 / 90, wat neerkomt op ongeveer 2,7 gelijktijdige verzoeken.
3. Stel het aantal slots iets hoger in dan dat getal en controleer dit vervolgens tegen het geheugen: het aantal slots vermenigvuldigd met de context per verzoek moet passen binnen de cache-tokens waarover u daadwerkelijk beschikt.
4. Houd de wachtrij kort, zodat een overflow snel en zichtbaar faalt.

Het aantal beschikbare cache-tokens is het vrije geheugen na het laden van de gewichten, gedeeld door de kosten per token uit de bovenstaande sectie. Een 24 GB kaart die een 8B model in 16-bit draait, verbruikt ongeveer 16 GB aan gewichten en heeft bij standaardgebruik ongeveer 6 GB aan bruikbare cache, wat neerkomt op ongeveer vijf 8K-conversaties. Om meer te kunnen opslaan, verkort u de context per verzoek of slaat u de cache op in 8-bit (llama-server gebruikt --cache-type-k q8_0). Beide opties vergroten de gelijktijdigheid ten koste van iets anders. Het is raadzaam om de eerlijke weergave van die afweging te lezen voordat u investeert in hardware: wanneer een GPU VPS rendabeler is dan API-tokens.

Waar de standaardinstellingen van Ollama tekortschieten

Verhoog het aantal parallelle verzoeken via de service-unit, aangezien een shell-export niet wordt doorgegeven aan een door systemd beheerde daemon.

sudo systemctl edit ollama.service

[Service]
Environment="OLLAMA_NUM_PARALLEL=4"
Environment="OLLAMA_CONTEXT_LENGTH=8192"
Environment="OLLAMA_MAX_QUEUE=64"

sudo systemctl daemon-reload
sudo systemctl restart ollama
systemctl show ollama --property=Environment
ollama ps

systemctl show hoort de drie variabelen die u zojuist heeft ingesteld weer te geven. Als dit niet het geval is, is het drop-in-bestand niet opgeslagen en heeft verdere actie geen zin. ollama ps toont vervolgens het geladen model met een grootte die groter is dan alleen de gewichten, omdat vier slots van 8.192 tokens naast de gewichten ook 32.768 tokens aan cache reserveren. Een PROCESSOR-kolom die aangeeft dat een deel van het model op de CPU staat terwijl u verwachtte dat alles op de GPU zou staan, betekent dat u om meer cache heeft gevraagd dan de kaart beschikbaar had. Verlaag een van de twee getallen. Het verkleinen van de context is meestal de veiligste optie, maar een venster dat te klein is, kapt lange prompts stilletjes af in plaats van een foutmelding te geven. Daarom is het de moeite waard om num_ctx bewust te dimensioneren in plaats van deze simpelweg te verlagen totdat het model past.

De standaardinstelling voor de wachtrij verdient extra aandacht. Ollama plaatst maximaal OLLAMA_MAX_QUEUE verzoeken in de wachtrij, en "de standaardwaarde is 512". Daarboven reageert het "met een 503-foutmelding die aangeeft dat de server overbelast is". Een wachtrij van 512 op een systeem dat er vier tegelijk verwerkt, is een belofte die u niet kunt waarmaken, omdat de client op positie 300 al lang een time-out krijgt voordat deze aan de beurt is. Een korte wachtrij geeft een foutmelding terug waarop uw applicatie kan reageren met een nieuwe poging of een melding, wat beter is dan een laadindicator die nooit verdwijnt.

Test het in de praktijk. Verstuur twee verzoeken op hetzelfde moment vanuit twee terminals en observeer beide. Als de tweede pas resultaat geeft nadat de eerste is voltooid, is de instelling voor parallelle verwerking niet actief geworden.

Wanneer een echte serving engine zichzelf terugverdient

vLLM is de extra configuratie waard wanneer u een GPU met reservecapaciteit heeft en er meer dan ongeveer vier verzoeken tegelijkertijd in behandeling zijn. De scheduler werkt per token, het cachegeheugen is gepagineerd zodat vrije fragmenten worden hergebruikt, en het zet onbenut VRAM om in gelijktijdigheid in plaats van dit ongebruikt te laten. Sinds augustus 2026 zijn de gedocumenteerde installatie en start twee commando's:

uv pip install vllm --torch-backend=auto
vllm serve Qwen/Qwen2.5-1.5B-Instruct

curl http://localhost:8000/v1/chat/completions \
    -H "Content-Type: application/json" \
    -d '{
        "model": "Qwen/Qwen2.5-1.5B-Instruct",
        "messages": [{"role": "user", "content": "Say hello."}]
    }'

Een antwoord met een choices-array betekent dat de server actief is en het model is geladen. Onder belasting zijn de twee instellingen die ertoe doen --max-num-seqs, het "maximum aantal sequenties dat in één iteratie wordt verwerkt", en --max-num-batched-tokens, het "maximum aantal tokens dat in één iteratie kan worden verwerkt". De eerste begrenst de gelijktijdigheid. De tweede is het budget voor chunked prefill zoals eerder beschreven.

Bij minder dan ongeveer vier actieve verzoeken, of op elk systeem zonder ondersteunde GPU, kost vLLM complexiteit zonder veel op te leveren. Het vereist een kaart van CUDA-klasse en claimt het grootste deel van het geheugen bij het opstarten; dit is een ongunstige afweging op een VPS met 4 tot 8 GB RAM. In dat geval is een kleiner model met een kortere context en een wachtrij die u zelf beheert de juiste oplossing. hoe Ollama en vLLM verschillen als serving engines behandelt deze keuze volledig, en Qwen 3 8B draaien op een VPS laat zien wat een middelgroot model vereist voordat u ook maar één extra gebruiker toevoegt.

De afweging die de folklore verhult

Continuous batching verhoogt de totale doorvoer en verbetert doorgaans ook de mediane latentie, omdat een verzoek in de wachtrij eerder wordt verwerkt. De staartlatentie (tail latency) beweegt echter in de tegenovergestelde richting, en die helft wordt zelden benoemd.

Elke extra sequentie in een stap voegt een kleine hoeveelheid werk toe, waardoor de ITL voor iedereen stijgt naarmate de batch zich vult. De prefill van een nieuwe aanvraag neemt een deel van een stap in beslag die anders voor de streamende gebruikers beschikbaar was geweest. Bij cache-druk voert de scheduler preemption uit, waardoor een half gegenereerd verzoek teruggaat naar het begin van de prefill.

Een chat-UI toont staarten, geen gemiddelden. Een stream die halverwege een zin twee seconden pauzeert, oogt defect, zelfs als de totale tijd tot voltooiing goed is. Meet de p95 TTFT en p95 ITL onder de belasting die u verwacht, en beschouw het gemiddelde aantal tokens per seconde als een capaciteitsgetal in plaats van een beschrijving van de gebruikerservaring.

De praktische instelling volgt hieruit. Beperk de concurrency tot net onder wat het geheugen toelaat, zodat de engine nooit hoeft te preempten. Een korte, voorspelbare wachtrij is beter dan een diepe batch die voor thrashing zorgt, omdat een gebruiker die vier seconden wacht en daarna vloeiend streamt, tevredener is dan een gebruiker die direct begint en twee keer stottert.

Wat te controleren bij traagheid

Elke gebruiker is normaal, maar het wachten duurt lang. Dit is een wachtrijprobleem, geen snelheidsprobleem. Controleer eerst de instelling voor parallellisatie. Het model functioneert correct en verwerkt één verzoek tegelijk.

HTTP 503 vanuit Ollama. De wachtrij is vol. Of de server zit daadwerkelijk op de maximale capaciteit, of OLLAMA_MAX_QUEUE is bewust laag ingesteld om de belasting te beperken; dit is het gewenste gedrag.

Tokens per seconde storten in onder belasting op een CPU-server. Voer vmstat 1 uit terwijl dit gebeurt. Waarden die niet nul zijn in de kolommen si en so betekenen dat de machine aan het swappen is. Hierdoor worden de gewichten bij elk token vanaf de schijf gelezen. Geen enkele configuratiewijziging lost dit op. Verklein het model of verminder het aantal slots.

Eén op de tien gebruikers wacht aanzienlijk langer dan de rest. Zoek in het vLLM-logboek naar preempted. Preemption en de bijbehorende herberekening zijn de gebruikelijke oorzaak; dit betekent dat de cache overbelast is voor de toegestane contextlengte.

TTFT is slecht, zelfs als de server inactief is. Dit is prefill, geen gelijktijdigheid. Lange prompts kosten daadwerkelijke tijd voordat het eerste token verschijnt. Kijk daarom naar de promptgrootte en prefix caching voordat u naar de hardware kijkt. Als de lange wachttijd alleen optreedt bij de eerste persoon na een rustige periode en alle volgende gebruikers geen problemen ervaren, is dit geen prefill. In dat geval ontlaadt Ollama het model en leest het de gewichten opnieuw vanaf de schijf. Dit is uit te sluiten door het model in het geheugen te houden tussen verzoeken.

FAQ

Waarom wordt mijn zelfgehoste LLM trager wanneer een tweede persoon deze gebruikt?

Meestal wordt deze niet trager, maar komt de aanvraag in een wachtrij. Ollama wordt geleverd met OLLAMA_NUM_PARALLEL ingesteld op 1, waardoor de tweede aanvraag wacht tot de eerste het laatste token heeft gegenereerd. U onderscheidt beide situaties door de stream van één gebruiker te timen terwijl een ander wacht: als het aantal tokens per seconde normaal is zodra de stream start, is er sprake van een wachtrij en lost het verhogen van het parallelle aantal dit op. Als beide streams op halve snelheid draaien, deelt u daadwerkelijk de geheugenbandbreedte en is dit een hardwarebeperking.

Hoeveel gelijktijdige gebruikers kan één kleine GPU bedienen?

Kijk naar het geheugen, niet naar het aantal gebruikers. Eerst de gewichten, daarna de KV-cache. Deze kost 2 keer het aantal lagen keer het aantal key/value-heads keer de head-dimensie keer het aantal bytes, per token, per actieve conversatie. Een typisch 8B-model met 36 lagen, 8 key/value-heads en een head-dimensie van 128 kost ongeveer 144 KiB per token in 16-bit. Een conversatie van 8,192 tokens vereist dus ongeveer 1.2 GB. Een kaart van 24 GB die dat model in 16-bit vasthoudt, heeft ongeveer 6 GB over voor de cache; dat is voldoende voor ongeveer vijf conversaties met volledige context, of meer als u de context inkort.

Maakt continuous batching het antwoord voor elke gebruiker trager?

De mediane latentie verbetert meestal, omdat aanvragen niet langer hoeven te wachten tot een hele batch is voltooid. De tail-latentie verslechtert echter. Elke extra sequentie voegt werk toe aan elke decodeerstap, de prefill van een nieuwe aanvraag neemt een deel van de tijd in beslag van de gebruikers die al streamen, en een onderbroken aanvraag moet twee keer prefillen. Meet de p95 inter-token latentie in plaats van het gemiddelde, omdat pauzes in een chatvenster opvallen op een manier die gemiddelden maskeren.

Moet ik OLLAMA_NUM_PARALLEL verhogen of overstappen op vLLM?

Verhoog eerst het parallelle aantal. Dit is kosteloos, vereist slechts één drop-in bestand en lost het veelvoorkomende scenario op waarbij vier mensen in de wachtrij staan achter één lang antwoord. Het geheugen is de beperkende factor: parallelle aanvragen vermenigvuldigen de context die u moet vasthouden, dus let op of lagen naar de CPU worden verplaatst. Stap over op vLLM wanneer u een GPU met vrije VRAM heeft en meer dan ongeveer vier aanvragen daadwerkelijk tegelijkertijd verwerkt; dat is het punt waarop paged cache en per-token scheduling meer opleveren dan ze kosten.

Zorgen meer CPU-cores voor een snellere LLM-server?

Niet voor het deel dat gebruikers het meest opmerken. Bij het decoderen wordt voor elk token het volledige model uit het geheugen gelezen, waardoor het proces gebonden is aan de RAM-bandbreedte. Extra cores helpen niet meer zodra de bandbreedte verzadigd is. Prefill schaalt wel met cores, dus meer cores verkorten de tijd tot het eerste token bij lange prompts. Op een VPS met 4 tot 8 GB is de beperkende factor meestal de geheugencapaciteit; de effectieve oplossing is dan een kleiner model of een kortere context in plaats van meer vCPU's.