Bakit Bumababagal ang Self-Hosted LLM sa 5 User

Bakit bumabagal ang self-hosted LLM kapag dumarami ang user?

Humihinto ang self-hosted LLM kapag 5 ang sabay-sabay na user dahil paisa-isang reply pa rin ang ginagawa ng server, kaya nakapila ang iba pang apat. Malinaw ang default sa documentation ng Ollama: ang OLLAMA_NUM_PARALLEL ay “the maximum number of parallel requests each model will process at the same time, default 1.” Walang sira. Apat sa limang user ang naghihintay ng turn.

Bihirang mas malaking server ang solusyon. Kailangan ng serving engine na kayang ipadaan ang maraming request sa model sa iisang forward pass, kasama ang sapat na ekstrang memory para mapanatili ang conversation ng lahat habang ginagawa ito. Mahalaga ang dalawang bahaging ito, at ang ikalawa ang aktuwal na nagtatakda ng limitasyon mo.

Ang dalawang phase na dinaraanan ng bawat request

Binabasa ng prefill ang buong prompt nang sabay-sabay at binubuo ang attention cache para rito. Dumaraan nang magkakasabay sa model ang lahat ng token ng prompt. Kaya ang prefill ay isang malaking matrix multiply, at nalilimitahan ito ng arithmetic throughput. Pagkatapos, isinusulat ng decode ang sagot nang isang token bawat pagkakataon. Kailangang basahin muli mula sa memory ang buong weights ng model para sa bawat token, samantalang napakaliit ng arithmetic na ginagawa para sa iisang token. Nalilimitahan ang decode ng memory bandwidth.

Ang asymmetry na ito ang pangunahing dahilan kung bakit gumagana ang batching. Sa pag-decode para sa isang user, halimbawa, nagbabasa ito ng 5 GB ng weights bawat token at nananatiling idle ang karamihan sa arithmetic units. Kapag nagdagdag ng pangalawang request, isang beses lamang binabasa ng engine ang parehong 5 GB, saka nito kinakalkula ang dalawang token. Halos walang dagdag na oras ang kailangan para sa pangalawang user. Nawawala ang benepisyong ito kapag mahigpit na isa-isang sine-serve ang mga request.

Dalawang numero ang naglalarawan sa nararanasan ng user. Ang TTFT (time to first token) ay ang pinagsamang queue wait at prefill. Ang ITL (inter-token latency) ay ang pagitan ng mga streamed token, at itinatakda ito ng decode. Karaniwang mabagal ang server dahil mabagal ito sa isa sa dalawang ito, at magkaiba ang kailangang pag-aayos para sa bawat isa.

Static batching: naghihintay ang lahat sa pinakamabagal na response

Ang static batching ang pinakasimpleng bersyon. Ito ang makukuha kapag ikaw mismo ang naggugrupo ng mga request sa application code. Kumokolekta ang engine ng N request, pinapatakbo ang mga ito nang sabay, at pinananatiling okupado ang bawat slot hanggang matapos ang pinakamahabang generation sa grupo.

Kapag may isang user na humihingi ng 1,200-token na summary, nananatiling naka-lock sa batch ang apat na one-line na sagot, dahil walang slot na nire-release ang batch hanggang matapos ang pinakamabagal nitong member.

Dalawang gastos ang resulta nito. Patuloy na gumagamit ng slots ang mga sequence na tapos na kahit wala na silang kapaki-pakinabang na computation, kaya bumababa ang effective throughput habang nag-iiba ang haba ng output. Malaki ang pagkakaiba ng haba ng output sa chat. Ang request na dumarating isang step pagkatapos mabuo ang batch ay naghihintay na ma-drain ang buong batch bago pa man magsimula ang prefill nito. Dahil dito, ang TTFT nito ay nakadepende sa essay ng ibang user.

Tumatanggap at nag-aalis ang continuous batching ng mga request sa bawat token

Ang continuous batching ay nagse-schedule sa antas ng isang decoding step. Pagkatapos ng bawat step, inaalis ng scheduler ang mga sequence na kakalabas lang ng stop token, saka tinatanggap ang mga naghihintay na request sa mga bakanteng slot. Ang reply na nagtatapos sa step 40 ay nagpapalaya ng slot sa step 40, hindi sa pagtatapos ng batch.

Hindi ito kakaiba. Idinedokumento ng llama-server ang -cb, --cont-batching bilang “kung dapat i-enable ang continuous batching (tinatawag ding dynamic batching) (default: enabled),” at nakabatay ang vLLM sa ideyang ito. Nagseserve rin ang Ollama ng mga parallel request. Nililimitahan lang ng default ang bilang sa isa. Dahil dito, maraming tao ang nag-aakalang hindi kayang magpatakbo ng concurrency ng kanilang hardware, kahit configuration nila ang nagtakdang hindi ito payagan.

Karaniwang sinusukat ang mga published result para sa continuous batching sa mga datacenter card na may ekstrang compute capacity at sampu-sampung gigabytes para sa cache. Nalilipat sa iyong box ang pattern ng mga resultang ito. Hindi nalilipat ang laki ng mga ito, at ipinaliliwanag ng seksyon tungkol sa memory sa ibaba kung bakit.

Ang prefill ay nakikipag-agawan sa decode para sa parehong compute

Kapag may bagong request habang nagsi-stream ang apat na reply, kailangang i-prefill muna ang prompt nito, at compute-heavy ang prefill. Kung bibigyan ng scheduler ng sarili nitong step ang prefill na iyon, walang matatanggap na token ang apat na user na nagsi-stream habang isinasagawa ito. Sa mahabang prompt, kapansin-pansing pause ito sa bawat bukas na window. Ito ang stutter na tinutukoy ng mga tao kapag sinasabing nagkakaroon ng hiccup ang server tuwing may ibang pumipindot sa send.

Hinahati ng chunked prefill ang mahabang prompt sa mga bahagi at isinasama ang bawat bahagi sa parehong step ng mga decode na tumatakbo. Direktang inilalarawan ng tuning guide ng vLLM ang tradeoff: ang mas maliliit na chunk budget ay “achieve better ITL because there are fewer prefills slowing down decodes”, habang ang mas malalaking value ay “achieve better time to first token (TTFT) as you can process more prefill tokens in a batch”. Pumipili ka kung kaninong experience ang poprotektahan: ang taong naghihintay na magsimula ang reply, o ang mga taong nanonood habang nagso-stream ang text.

Ang haba ng prompt ang tumutukoy kung gaano kalaki ang epekto nito. Ang 6,000-token na prompt na may 200-token na sagot ay nangangailangan ng 6,000 token ng prefill work kumpara sa 200 decode step. Parehong nagtutulak sa ganitong sitwasyon ang retrieval-augmented chat at mahahabang system prompt. Dahil dito, hindi na maliit na overhead ang prefill; ito na ang hinihintay ng mga user. Nakakatulong ang prefix caching kapag nauulit ang mahabang bahagi: inilalantad ng vLLM ang --enable-prefix-caching, na muling gumagamit ng cache para sa shared prompt prefix sa halip na i-recompute ito sa bawat request.

Ang unang nauubos na memory ay ang KV cache

Bawat token sa bawat aktibong conversation ay nag-iiwan ng key vector at value vector sa bawat layer ng model. Iyon ang KV cache (key/value cache), at ito ang nagbibigay-daan sa decode na hindi muling kalkulahin ang buong prompt para sa bawat bagong token. Fixed ang laki nito kada token batay sa shape ng model: 2 (isang key at isang value) na minumultiply sa bilang ng layers, bilang ng key/value heads, head dimension, at bytes kada value. Kunin ang mga numerong iyon sa config.json ng model.

Kalkulahin ito nang isang beses upang maging malinaw ang limitasyon. Ang karaniwang 8B model na may 36 layers, 8 key/value heads, at head dimension na 128, kung 16-bit ang gamit sa cache, ay nangangailangan ng 2 36 8 128 2 bytes kada token. Katumbas ito ng 147,456 bytes, o humigit-kumulang 144 KiB. Kaya ang isang conversation na may 8,192 token ay nangangailangan ng humigit-kumulang 1.2 GB na cache. Ang lima nito ay nangangailangan ng humigit-kumulang 6 GB, bukod pa sa weights. Iyan ang aktuwal na sagot sa kung ilang user ang kasya.

Minumultiply ng concurrency ang context, at malinaw itong ipinapakita ng mga tool. Ayon sa FAQ ng Ollama: "Ang parallel request processing para sa isang partikular na model ay nagpapalaki sa context size batay sa bilang ng parallel request. Halimbawa, ang 2K context na may 4 parallel request ay magiging 8K context at mangangailangan ng karagdagang memory allocation." Ang kinakailangang RAM ay nagse-scale ayon sa OLLAMA_NUM_PARALLEL na minumultiply sa OLLAMA_CONTEXT_LENGTH. Sa llama-server, hinahati ang context na hinihingi mo gamit ang -c sa mga -np slot. Kaya kapag tinaasan lamang ang bilang ng slot, lumiit ang kayang hawakan ng bawat request. Basahin ang context kada slot mula sa startup log sa halip na ipagpalagay ito.

Sa halip, nagpe-preallocate ang vLLM. Ang --gpu-memory-utilization (default na 0.92) ay "ang fraction ng GPU memory na gagamitin ng model executor." Ang natitirang memory pagkatapos ilaan para sa weights ang nagiging paged KV pool. Kapag kinapos ang pool na ito, ine-evict ng scheduler ang isang request sa halip na i-fail ito:

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.

Sa V1 engine ng vLLM, ang default na preemption mode ay RECOMPUTE. Kaya itinatapon ng evicted request ang cache nito at muling nagpe-prefill kapag muli itong tinanggap ng scheduler. Dalawang beses ginagawa ang prosesong iyon. Nagbababala ang documentation na "maaaring magkaroon ng masamang epekto sa end-to-end latency ang preemption at recomputation." Ang log line na ito ang pinakamalinaw na paliwanag kung bakit mas matagal naghintay ang isang malas na user kaysa sa lahat, kahit mukhang maayos ang average latency. Itakda ang disable_log_stats=False upang i-log ang cumulative count, o basahin ang preemption counter mula sa Prometheus metrics na inilalabas ng vLLM.

Ano ang nagbabago sa 2, 5, at 20 concurrent user

Dalawang user. Halos hindi ito kapansin-pansin sa GPU na may sapat pang cache, dahil kasabay ng unang decode stream ang ikalawang stream at kaunti lang ang nadadagdag na oras. Sa CPU-only VPS na may 4 hanggang 8 GB na RAM, hindi ito libre: parehong gumagamit ang dalawang stream ng iilang vCPU at ng parehong RAM bandwidth. Kaya humigit-kumulang kalahati ng tokens per second ang nakikita ng bawat user, at dumodoble ang cache demand kumpara sa mas maliit na budget.

Limang user. Dito nagsisimulang hindi sapat ang defaults, at queue problem muna ang unang epekto. Kapag OLLAMA_NUM_PARALLEL ay nakatakda sa 1, apat na tao ang naghihintay sa taong humiling ng mahabang sagot, at normal ang speed na nakikita ng bawat isa pagdating ng kanilang turn. Kapag tinaasan ang parallel count, nagbabago ang anyo ng problema: ang 5 slot na may tig-8K context ay nangangailangan ng 40K token cache. Kung hindi ito kasya sa VRAM, nag-o-offload ang engine ng mga layer sa system RAM. Kung hindi rin ito kasya sa RAM, gumagamit ng swap ang machine at bumabagsak ang tokens per second.

Dalawampung user. Karaniwang hindi katumbas ng 20 concurrent request ang 20 tao sa chat UI. Ito ang pinakamahalagang maunawaan bago bumili ng hardware. Binabasa ng isang tao ang sagot at nag-iisip nang 20 hanggang 60 segundo bago ang susunod na turn, kaya idle ang karamihan ng session niya. Ang 20 agent o 20 document summarisation job ay 20 totoong stream na walang idle time. Ibang machine na ang kailangan dito.

Mga concurrent ba ang inyong users, o naka-login lang?

Tukuyin muna ang mga request na kasalukuyang pinoproseso bago magtakda ng capacity. Karaniwan lang ang computation: ang in-flight requests ay katumbas ng users, minultiply sa mga segundong ginugugol sa pag-generate sa bawat turn, at hinati sa mga segundo sa pagitan ng mga turn.

1. Sukatin muna ang bilis ng sarili mong single stream, kasama ang prefill at decode. Huwag gumamit ng value mula sa GPU ng ibang tao: sukatin ang tokens per second sa sarili mong box at gamitin ang resulta.
2. Tantiyahin ang duty cycle. Kung may 20 chat users, 12 segundo ang generation sa bawat turn, at isang turn bawat 90 segundo, ang computation ay 20 * 12 / 90, o humigit-kumulang 2.7 in-flight requests.
3. Itakda ang slot count nang bahagyang mas mataas dito, pagkatapos ay ikumpara ito sa memory: dapat magkasya ang slots na minultiply sa context bawat request sa cache tokens na aktuwal mong mayroon.
4. Panatilihing maikli ang queue para mabilis at malinaw na mag-fail ang mga request na lalampas sa capacity.

Ang available na cache tokens ay ang free memory pagkatapos ilaan ang memory para sa weights, na hinati sa per-token cost mula sa naunang section. Ang isang 24 GB card na nagpapatakbo ng 8B model sa 16-bit ay gumagamit ng humigit-kumulang 16 GB para sa weights at may tinatayang 6 GB na usable cache sa default utilisation. Katumbas ito ng humigit-kumulang limang 8K conversation. Para magkasya ang mas marami, paikliin ang context bawat request, o i-store ang cache sa 8-bit (llama-server takes --cache-type-k q8_0). Parehong nagpapataas ng concurrency sa pamamagitan ng isang kapalit, kaya sulit basahin ang tapat na paliwanag ng trade-off na ito bago gumastos sa hardware: kung kailan mas sulit ang GPU VPS kaysa API tokens.

Kapag hindi na sapat ang mga default ng Ollama

Taasan ang parallel count sa service unit, dahil hindi makararating sa daemon na mino-manage ng systemd ang shell export.

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

Dapat i-print ng systemctl show ang tatlong variable na kakaset mo lang. Kung hindi, hindi na-save ang drop-in, at walang ibang gagawin ang makaaayos nito. Pagkatapos, inililista ng ollama ps ang naka-load na model na mas malaki kaysa sa weights lamang, dahil ang apat na slot na may tig-8,192 token ay nagrereserba ng 32,768 token na cache bukod sa mga ito. Kung may PROCESSOR column na nagpapakitang bahagi ng model ay nasa CPU kahit inaasahan mong nasa GPU lahat, nangangahulugan itong mas maraming cache ang hiningi mo kaysa sa natitirang capacity ng card. Bawasan ang isa sa dalawang numero.

Kailangang suriin muli ang default na queue. Nagku-queue ang Ollama ng hanggang OLLAMA_MAX_QUEUE request, at “ang default ay 512.” Kapag lumampas dito, tumutugon ito “ng 503 error na nagsasabing overloaded ang server.” Ang queue na may lalim na 512 sa isang box na apat lang ang kayang pagsabay-sabayin ay pangakong hindi mo matutupad, dahil magti-time out ang client na nasa position 300 bago pa dumating ang turn nito. Ang maikling queue ay nagbabalik ng error na maaaring i-retry o i-report ng application, na mas mabuti kaysa sa spinner na hindi kailanman natatapos.

Subukan ito nang aktuwal. Magpadala ng dalawang request sa parehong oras mula sa dalawang terminal at obserbahan ang mga ito. Kung walang output ang pangalawa hanggang matapos ang una, hindi nagkabisa ang parallel setting.

Kapag nagsisimulang sulit ang isang tunay na serving engine

Sulit ang dagdag na setup ng vLLM kapag may GPU kang may natitirang capacity at higit-kumulang apat na request ang aktuwal na sabay-sabay na pinoproseso. Gumagana per token ang scheduler nito, naka-page ang cache nito kaya nagagamit muli ang mga libreng fragment, at ginagamit nito ang sobrang VRAM para sa concurrency sa halip na manatiling idle. As of August 2026, dalawang command ang kailangan para sa documented na installation at launch:

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."}]
    }'

Ang reply na may choices array ay nangangahulugang gumagana na ang server at naka-load na ang model. Kapag may load, ang dalawang setting na mahalaga ay --max-num-seqs, ang “maximum number of sequences to be processed in a single iteration”, at --max-num-batched-tokens, ang “maximum number of tokens that can be processed in a single iteration”. Nililimitahan ng una ang concurrency. Ang ikalawa ang chunked prefill budget na inilarawan kanina.

Kung mas mababa sa humigit-kumulang apat ang sabay-sabay na request, o kung walang supported GPU ang server, nagdadagdag ng complexity ang vLLM pero kaunti ang naibabalik na benepisyo. Inaasahan nito ang CUDA-class card at inaangkin ang malaking bahagi ng memory sa startup, kaya hindi ito ang tamang trade-off para sa 4 hanggang 8 GB VPS. Doon, mas angkop ang mas maliit na model na may mas maikling context at queue na ikaw ang kumokontrol. Sinasaklaw nang buo ng kung paano nagkakaiba ang Ollama at vLLM bilang mga serving engine ang pagpiling ito, at ipinapakita ng pagpapatakbo ng Qwen 3 8B sa isang VPS kung ano ang kailangan ng isang mid-sized model bago ka magdagdag ng kahit isang user.

Ang kompromisong itinatago ng nakasanayang paliwanag

Pinapataas ng continuous batching ang kabuuang throughput, at karaniwan din nitong pinapabuti ang median latency dahil mas maagang nagsisimula ang naka-queue na request. Kabaligtaran ang galaw ng tail latency, pero bihirang mabanggit ang bahaging ito.

Bawat dagdag na sequence sa isang step ay nagdaragdag ng kaunting trabaho, kaya tumataas ang ITL para sa lahat habang napupuno ang batch. Ang prefill ng bagong dumarating na request ay kumukuha ng bahagi ng step na magagamit sana ng mga user na nag-i-stream. Kapag may pressure sa cache, nagpe-preempt ang scheduler, kaya ibinabalik sa simula ng prefill ang request na bahagyang nabuo na.

Mga tail, hindi mga average, ang nakikita sa chat UI. Ang stream na humihinto nang dalawang segundo sa kalagitnaan ng pangungusap ay mukhang sira kahit maganda ang kabuuang oras hanggang makumpleto. Sukatin ang p95 TTFT at p95 ITL sa ilalim ng load na inaasahan mo, at ituring ang mean tokens per second bilang capacity number, hindi bilang paglalarawan ng user experience.

Mula rito nagmumula ang praktikal na setting. Limitahan ang concurrency nang bahagya sa ibaba ng kayang suportahan ng memory, para hindi kailangang mag-preempt ang engine. Mas mainam ang maikli at predictable na queue kaysa sa malalim na batch na paulit-ulit na nagka-thrash, dahil mas magiging maayos para sa user ang maghintay nang apat na segundo at pagkatapos ay makapag-stream nang tuloy-tuloy kaysa magsimulang agad pero dalawang beses ma-stall.

Ano ang dapat suriin kapag mabagal

Normal ang bawat user, pero mahaba ang paghihintay. Queue iyan, hindi problema sa bilis. Suriin muna ang parallel setting. Tama ang pag-serve ng model, isang request bawat pagkakataon.

HTTP 503 mula sa Ollama. Puno ang queue. Maaaring talagang nasa maximum capacity ang machine, o sadyang mababa ang setting ng OLLAMA_MAX_QUEUE upang mag-shed ng load. Iyan ang inaasahang behavior nito.

Bumababagsak ang tokens per second kapag mataas ang load sa CPU box. Patakbuhin ang vmstat 1 habang nangyayari ito. Kapag may nonzero na value sa mga column na si at so, gumagamit ng swap ang machine. Ibig sabihin, binabasa mula sa disk ang weights sa bawat token. Walang configuration change na makakalutas nito. Bawasan ang model size o ang slot count.

Isa sa bawat sampung user ang mas matagal maghintay kaysa sa iba. Hanapin sa vLLM log ang preempted. Karaniwang sanhi ang preemption at ang recompute nito. Ibig sabihin, oversubscribed ang cache para sa context length na pinapayagan mo.

Mababa ang TTFT kahit idle ang server. Prefill iyan, hindi concurrency. Kumakain ng aktuwal na oras ang mahahabang prompt bago lumabas ang unang token. Suriin muna ang prompt size at prefix caching bago ang hardware.

FAQ

Bakit bumabagal ang self-hosted LLM ko kapag may pangalawang gumagamit?

Kadalasan, hindi talaga ito bumabagal. Naka-queue ang request. Naka-set sa 1 ang OLLAMA_NUM_PARALLEL ng Ollama, kaya naghihintay ang pangalawang request na ma-emit ng una ang final token nito. Ihiwalay ang dalawang sitwasyon sa pamamagitan ng pag-time sa stream ng isang user habang naghihintay ang isa pa: kung normal ang tokens per second nito kapag nagsimula na, queue ang problema, at maaayos ito sa pagtaas ng parallel count. Kung kalahati ang bilis ng parehong stream, tunay na pinaghahatian ng mga ito ang memory bandwidth, at hardware limit iyon.

Ilang concurrent user ang kayang pagsilbihan ng isang maliit na GPU?

Memory ang bilangin, hindi users. Unahin ang weights, kasunod ang KV cache, na kumokonsumo ng 2 times layers times key/value heads times head dimension times bytes, bawat token, para sa bawat aktibong conversation. Ang karaniwang 8B model na may 36 layers, 8 key/value heads, at head dimension na 128 ay kumokonsumo ng humigit-kumulang 144 KiB bawat token sa 16-bit, kaya ang conversation na may 8,192 token ay nangangailangan ng humigit-kumulang 1.2 GB. Ang 24 GB card na nagho-hold ng model na iyon sa 16-bit ay may natitirang humigit-kumulang 6 GB para sa cache. Sapat iyon para sa mga limang conversation sa full context, o higit pa kung paiikliin mo ang context.

Pinapabagal ba ng continuous batching ang reply ng bawat user?

Karaniwang gumaganda ang median latency dahil hindi na naghihintay ang mga request na matapos ang buong batch. Lumalala naman ang tail latency. Bawat karagdagang sequence ay nagdaragdag ng work sa bawat decoding step. Kumukuha ang prefill ng bagong arrival ng bahagi ng isang step mula sa mga user na nag-i-stream. Ang preempted request ay kailangang mag-prefill nang dalawang beses. Sukatin ang p95 inter-token latency, hindi ang average, dahil kapansin-pansin sa chat window ang mga pause sa paraang natatago ng averages.

Dapat ko bang taasan ang OLLAMA_NUM_PARALLEL o lumipat sa vLLM?

Unahin ang pagtaas ng parallel count. Libre ito at isang drop-in file lang ang kailangan. Inaayos nito ang karaniwang sitwasyon kung saan apat na tao ang naka-queue sa likod ng isang mahabang sagot. Memory ang limitasyon: pinaparami ng parallel requests ang context na kailangan mong i-hold, kaya bantayan kung may layers na nag-spill sa CPU. Lumipat sa vLLM kapag may GPU kang may ekstrang VRAM at tunay na mahigit apat na request ang sabay-sabay na nasa flight. Sa puntong iyon, mas malaki na ang pakinabang ng paged cache at per-token scheduling kaysa sa gastos ng mga ito.

Maaayos ba ng mas maraming CPU core ang mabagal na LLM server?

Hindi para sa bahaging pinakakapansin-pansin ng mga user. Sa decode, binabasa mula sa memory ang buong model para sa bawat token, kaya nalilimitahan ito ng RAM bandwidth. Hindi na nakatutulong ang dagdag na cores kapag saturated na ang bandwidth. Nagso-scale naman ang prefill sa cores, kaya pinaiikli ng mas maraming core ang time to first token para sa mahahabang prompt. Sa 4 to 8 GB VPS, karaniwang memory capacity ang binding constraint. Mas epektibong ayusin ito sa pamamagitan ng mas maliit na model o mas maikling context kaysa sa pagdaragdag ng vCPUs.