Bakit Bumagal ang Self-Hosted LLM sa 5 User

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

Humihinto sa pag-usad ang isang self-hosted LLM kapag umabot sa 5 ang sabay-sabay na user dahil paisa-isa pa ring bumubuo ng reply ang server, kaya nakapila ang apat na iba pa. Malinaw ang default sa dokumentasyon 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 kanilang turno.

Bihirang mas malaking server ang solusyon. Kailangan ng serving engine na kayang iproseso ang maraming request sa iisang forward pass ng model, kasama ang sapat na ekstrang memory para hawakan ang conversation ng lahat habang ginagawa ito. Mahalaga ang dalawang bahaging ito, at ang ikalawa ang aktuwal na nagtatakda ng maximum capacity 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. Dumadaan sa model nang magkakasabay ang lahat ng token ng prompt, kaya isang malaking matrix multiply ang prefill at limitado ito ng arithmetic throughput. Pagkatapos, isinusulat ng decode ang sagot nang tig-iisang token. Kailangang basahin muli mula sa memory ang buong weights ng model para sa bawat token, habang napakaliit ng arithmetic na ginagawa para sa isang token. Limitado 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, 5 GB ng weights ang binabasa para sa bawat token, kaya karamihan ng arithmetic units ay walang ginagawa. Magdagdag ng pangalawang request, at isang beses lamang babasahin ng engine ang parehong 5 GB, pagkatapos ay magko-compute ito ng dalawang token mula rito. Halos walang karagdagang oras ang kailangan para sa pangalawang user. Nawawala ang benepisyong ito kapag mahigpit na isa-isang sini-serve ang mga request.

Dalawang numero ang naglalarawan sa nararanasan ng user. Ang TTFT (time to first token) ay ang queue wait kasama ang prefill. Ang ITL (inter-token latency) ay ang pagitan ng mga streamed token, at itinatakda ito ng decode. Karaniwang mabagal ang server dahil mabagal ang isa sa dalawang ito, at magkaiba ang solusyon sa bawat isa. Mahalagang tukuyin muna kung alin ang inaayos mo bago magbago ng anumang setting; ang magkahiwalay na pagsukat sa prefill at decode ang paraan para malaman ito.

Static batching: naghihintay ang lahat sa pinakamabagal na tugon

Ang static batching ang pinakasimpleng bersyon. Ito ang makukuha mo kapag ikaw mismo ang nagpapangkat ng mga request sa application code. Kinokolekta ng engine ang N request, sabay-sabay na pinapatakbo ang mga ito, at pinananatiling occupied ang bawat slot hanggang matapos ang pinakamahabang generation sa grupo.

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

Dalawang gastos ang resulta. Patuloy na gumagamit ng mga slot ang mga natapos nang sequence kahit wala na silang kapaki-pakinabang na computation, kaya bumababa ang effective throughput habang nagkakaiba ang haba ng output; malaki ang pagkakaiba ng haba ng output sa chat. Ang request na dumating isang step matapos mabuo ang batch ay naghihintay na maubos muna ang buong batch bago pa man magsimula ang prefill. Dahil dito, ang TTFT nito ay nakadepende sa essay ng ibang user.

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

Nagso-schedule ang continuous batching sa antas ng isang decoding step. Pagkatapos ng bawat step, inaalis ng scheduler ang mga sequence na katatapos lang maglabas ng stop token, saka tinatanggap ang mga naghihintay na request sa mga bakanteng slot. Kapag natapos ang isang reply sa step 40, nababakante ang slot nito sa step 40, hindi sa pagtatapos ng batch.

Hindi ito kakaiba. Idodokumento ng llama-server ang -cb, --cont-batching bilang “kung ie-enable ang continuous batching (tinatawag ding dynamic batching) (default: enabled),” at nakabatay ang vLLM sa ideyang ito. Nagseserbisyo rin ang Ollama ng mga parallel request. Nililimitahan lang ng default ang bilang sa isa. Kaya maraming tao ang nag-aakalang hindi kayang magpatakbo ng concurrency ng kanilang hardware, kahit configuration nila ang nagtakdang huwag itong gawin.

Karaniwang sinusukat ang mga inilathalang resulta ng continuous batching sa mga datacenter card na may ekstrang compute capacity at sampu-sampung gigabyte para sa cache. Nalalapat sa iyong machine ang pattern ng mga resultang ito. Hindi nalalapat ang laki ng mga ito, at ipinaliliwanag ng seksyon tungkol sa memory sa ibaba kung bakit.

Nakikipagkumpitensya ang prefill sa decode para sa parehong compute

Kapag may bagong request habang nagsi-stream ang apat na reply, kailangang isagawa muna ang prefill ng prompt nito, at compute-heavy ang prefill. Kung bibigyan ng scheduler ng sariling 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 nagsasabing nagkakaroon ng hiccup ang server tuwing may ibang nagki-click 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”, samantalang ang mas malalaking value ay “achieve better time to first token (TTFT) as you can process more prefill tokens in a batch”. Pinipili mo kung kaninong experience ang poprotektahan: ang taong naghihintay na magsimula ang reply, o ang mga taong nanonood habang nagse-stream ang text.

Tinutukoy ng haba ng prompt 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 laban sa 200 decode step. Itinutulak ka ng retrieval-augmented chat at mahahabang system prompt sa ganitong sitwasyon, kaya hindi na maliit na rounding error ang prefill at ito na ang hinihintay ng mga user. Nakakatulong ang prefix caching kapag nauulit ang mahabang bahagi: inilalantad ng vLLM ang --enable-prefix-caching, na gumagamit muli ng cache para sa shared prompt prefix sa halip na muling kalkulahin ito para sa bawat request.

Ang unang nauubos na memory ay ang KV cache

Ang bawat token sa bawat aktibong conversation ay nag-iiwan ng key vector at value vector sa bawat layer ng model. Ito ang KV cache (key/value cache), at ito ang dahilan kung bakit hindi na kailangang muling kalkulahin ng decode ang buong prompt para sa bawat bagong token. Nakatakda ng shape ng model ang laki nito kada token: 2 (isang key at isang value), na imu-multiply sa bilang ng mga layer, bilang ng key/value heads, head dimension, at bytes bawat value. Basahin ang mga numerong iyon mula sa config.json ng model.

Kalkulahin ito nang isang beses at hindi na misteryo ang limitasyon. Ang karaniwang 8B model na may 36 layer, 8 key/value head, at head dimension na 128, kapag nasa 16-bit ang cache, ay gumagamit ng 2 36 8 128 2 bytes bawat 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 tunay na sagot sa kung ilang user ang kayang suportahan.

Dahil minumultiply ng concurrency ang context, 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 nag-i-scale batay sa OLLAMA_NUM_PARALLEL na imu-multiply sa OLLAMA_CONTEXT_LENGTH. Sa llama-server, ang context na hinihingi mo gamit ang -c ay hinahati sa -np slot. Kaya kapag itinaas mo ang bilang ng slot nang hindi binabago ang iba, lumiit ang kayang hawakan ng bawat request. Basahin ang context bawat slot mula sa startup log sa halip na mag-assume.

Sa halip, nagpe-preallocate ang vLLM. Ang --gpu-memory-utilization (default na 0.92) ay "ang fraction ng GPU memory na gagamitin para sa model executor." Ang matitirang memory matapos ilaan ang weights ay magiging paged KV pool. Kapag naubusan ng espasyo 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, RECOMPUTE ang default na preemption mode. Kaya kapag na-evict ang isang request, itinatapon ang cache nito at muling nagsasagawa ng prefill kapag tinanggap itong muli. Dalawang beses ginagawa ang prosesong iyon. Nagbabala ang documentation na "maaaring masamang makaapekto sa end-to-end latency ang preemption at recomputation." Ang log line na ito ang pinakamalinaw na paliwanag kung bakit mas matagal na naghintay ang isang malas na user kaysa sa lahat habang 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 sabay-sabay na user

Dalawang user. Halos hindi ito kapansin-pansin sa GPU na may natitirang cache, dahil kaunti lang ang dagdag na oras kapag sumabay ang ikalawang decode stream sa una. Sa CPU-only VPS na may 4 hanggang 8 GB na RAM, hindi ito libre: parehong stream ang gumagamit sa iilang vCPU at sa 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 mga default, at queue problem muna ito. Kapag ang OLLAMA_NUM_PARALLEL ay 1, apat na tao ang naghihintay sa nag-request 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 limang 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, mag-swap ang box at babagsak ang tokens per second.

Dalawampung user. Karaniwang hindi katumbas ng 20 sabay-sabay na request ang 20 tao sa isang chat UI, at ito ang pinakamahalagang maunawaan bago bumili ng hardware. Nagbabasa ang isang tao ng 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 ang kailangan dito. Ang isang developer na nagpaturo ng coding agent sa sarili niyang Ollama server ay mas malapit sa ikalawang sitwasyon kaysa sa una, dahil patuloy na nagpapadala ng request ang agent habang tumatakbo ang task at wala itong mga reading pause na ginagawa ng tao.

Mga concurrent ba ang iyong mga user, o naka-log in lang?

Tukuyin muna ang mga request na kasalukuyang pinoproseso bago magtakda ng kapasidad. Simple ang kalkulasyon: ang kasalukuyang bilang ng request ay katumbas ng bilang ng user, minultiply sa mga segundong ginugugol sa pag-generate ng bawat turn, at hinati sa mga segundo sa pagitan ng mga turn.

1. Sukatin muna ang bilis ng sarili mong single-stream, para sa prefill at decode. Huwag gumamit ng numerong mula sa card ng iba: sukatin ang tokens per second sa sarili mong box at gamitin ang aktuwal na resulta.
2. Tantiyahin ang duty cycle. Dalawampung chat user, 12 segundo ng generation bawat turn, at isang turn bawat 90 segundo ay nagbibigay ng 20 * 12 / 90, o humigit-kumulang 2.7 request na kasalukuyang pinoproseso.
3. Itakda ang bilang ng slot nang kaunti sa halagang iyon, pagkatapos ay suriin ito batay sa memory: dapat magkasya ang slots na minultiply sa context bawat request sa mga cache token na aktuwal mong mayroon.
4. Panatilihing maikli ang queue upang mabilis at malinaw na mag-fail ang mga request na lumampas sa kapasidad.

Ang available na cache token ay ang libreng memory pagkatapos ilaan ang memory para sa weights, na hinati sa per-token cost mula sa naunang seksyon. Ang 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 magagamit na cache sa default utilisation, na sapat para sa 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 ay kumukuha ng --cache-type-k q8_0). Parehong nagpapataas ng concurrency sa pamamagitan ng isang kapalit, kaya sulit basahin ang tapat na pagsusuri sa trade-off na ito bago gumastos sa hardware: kung kailan mas sulit ang GPU VPS kumpara sa API token.

Kung saan hindi na sapat ang defaults ng Ollama

Itakda ang parallel count sa service unit, dahil hindi makakarating sa daemon na pinamamahalaan 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 makakatulong. Pagkatapos, inililista ng ollama ps ang naka-load na model na mas malaki ang size kaysa sa weights lamang, dahil ang apat na slot na may tig-8,192 token ay nagrereserba ng 32,768 token para sa cache. Kung may PROCESSOR column na nagpapakitang bahagi ng model ay nasa CPU kahit inaasahan mong nasa GPU ang lahat, nangangahulugan itong humingi ka ng mas malaking cache kaysa sa natitirang memory ng card. Bawasan ang isa sa dalawang numero. Karaniwang mas ligtas bawasan ang context, ngunit kapag masyadong maliit ang window, tahimik nitong pinuputol ang mahahabang prompt sa halip na magbalik ng error. Kaya mainam na sadyang sukatin ang num_ctx sa halip na patuloy itong babaan hanggang magkasya ang model.

Dapat ding suriin muli ang default ng queue. Nagka-queue ang Ollama ng hanggang OLLAMA_MAX_QUEUE request, at “ang default ay 512.” Kapag lumampas dito, nagbabalik ito “ng 503 error na nagsasabing overloaded ang server.” Ang queue na may lalim na 512 sa server na sabay na nagseserve ng apat na request ay pangakong hindi mo matutupad, dahil magti-time out ang client na nasa posisyon 300 bago pa dumating ang turn nito. Nagbabalik ng error ang maikling queue na maaaring i-retry o i-report ng application. Mas mainam ito kaysa sa spinner na hindi kailanman natatapos.

Subukan ito nang aktuwal. Magpadala ng dalawang request nang sabay mula sa dalawang terminal at bantayan ang mga ito. Kung walang inilalabas ang pangalawa hanggang matapos ang una, hindi nagkabisa ang parallel setting.

Kapag nagsisimulang sulit ang isang tunay na serving engine

Nagiging sulit ang dagdag na setup ng vLLM kapag may GPU kang may ekstrang capacity at mahigit sa humigit-kumulang apat na request ang aktuwal na sabay-sabay na pinoproseso. Gumagana ang scheduler nito bawat token, naka-page ang cache nito kaya nagagamit muli ang mga libreng fragment, at ginagamit nito ang ekstrang VRAM para sa concurrency sa halip na manatiling idle. Noong August 2026, dalawang command ang dokumentadong kailangan para sa installation at pag-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."}]
    }'

Kapag may choices array sa reply, ibig sabihin ay gumagana na ang server at naka-load na ang model. Kapag may load, ang dalawang mahalagang knob ay --max-num-seqs, ang “maximum na bilang ng sequence na maaaring iproseso sa isang iteration,” at --max-num-batched-tokens, ang “maximum na bilang ng token na maaaring iproseso sa isang iteration.” Nililimitahan ng una ang concurrency. Ang ikalawa ang chunked prefill budget na inilarawan kanina.

Kung wala pang apat na request na kasalukuyang pinoproseso, o kung walang supported GPU ang server, nagdaragdag ng complexity ang vLLM ngunit kaunti ang naibabalik na pakinabang. Inaasahan nito ang CUDA-class na card at inaangkin nito ang malaking bahagi ng memory sa startup, kaya hindi ito ang tamang trade-off sa isang 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 pagpili, at ipinapakita ng pagpapatakbo ng Qwen 3 8B sa isang VPS kung ano ang kailangan ng isang mid-sized na model bago ka magdagdag ng kahit isang user.

Ang tradeoff na itinatago ng nakaugaliang paliwanag

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

Bawat karagdagang sequence sa isang step ay nagdaragdag ng kaunting trabaho, kaya tumataas ang ITL para sa lahat habang napupuno ang batch. Kumukuha ang prefill ng bagong arrival ng bahagi ng step na magagamit sana ng mga user na nagse-stream. Kapag mataas ang cache pressure, nagpe-preempt ang scheduler. Dahil dito, ibinabalik ang request na bahagyang nabuo na sa simula ng prefill nito.

Tail latency, hindi mga average, ang nakikita sa chat UI. Kapag huminto nang dalawang segundo ang stream sa gitna ng pangungusap, mukhang sira ang serbisyo kahit maganda ang kabuuang oras bago matapos. Sukatin ang p95 TTFT at p95 ITL sa ilalim ng load na inaasahan mo. Ituring ang mean tokens per second bilang capacity number, hindi bilang paglalarawan ng karanasan ng user.

Dito nakabatay ang praktikal na setting. Limitahan ang concurrency nang kaunti sa ibinibigay ng memory, para hindi kailangang mag-preempt ang engine. Mas mainam ang maikli at predictable na queue kaysa sa malalim na batch na patuloy na nagta-thrash. Mas nasisiyahan ang user na maghintay nang apat na segundo at pagkatapos ay makapag-stream nang tuloy-tuloy kaysa sa user na agad nagsisimula pero dalawang beses natitigil.

Mga dapat suriin kapag mabagal

Normal ang bawat user, pero mahaba ang paghihintay. Queue ito, hindi problema sa bilis. Unang suriin ang parallel setting. Maayos na nagsi-serve ang model, tig-iisang request lang.

HTTP 503 mula sa Ollama. Puno ang queue. Maaaring talagang nasa maximum capacity na ang box, o sadyang mababa ang setting ng OLLAMA_MAX_QUEUE para mag-shed ng load, na siyang inaasahang ginagawa nito.

Bumabagsak ang tokens per second kapag mataas ang load sa CPU box. Patakbuhin ang vmstat 1 habang nangyayari ito. Ibig sabihin ng nonzero na si at so columns ay nagso-swap ang machine, kaya binabasa ang weights mula sa disk sa bawat token. Walang configuration change na makakalutas nito. Bawasan ang model size o ang slot count.

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

Mababa ang TTFT kahit idle ang server. Prefill ito, hindi concurrency. Kumakain ng aktuwal na oras ang mahahabang prompt bago lumabas ang unang token, kaya suriin muna ang prompt size at prefix caching bago ang hardware. Kung ang mahabang paghihintay ay nararanasan lamang ng unang user na bumalik matapos ang tahimik na pagitan at maayos ang mga sumunod, hindi ito prefill. Ollama ang nag-unload ng model at muling nagbabasa ng weights mula sa disk. Mainam itong tiyaking hindi nangyayari sa pamamagitan ng pagpapanatiling naka-load ng model sa pagitan ng mga request.

FAQ

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

Kadalasan, hindi talaga ito bumabagal. Naka-queue ang request. May `OLLAMA_NUM_PARALLEL` ang Ollama na naka-set sa 1, kaya naghihintay ang pangalawang request na maibigay ng una ang huling token nito. Ihiwalay ang dalawang sitwasyon sa pamamagitan ng pagsukat 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 naghahati ang mga ito sa memory bandwidth. Limitasyon ito ng hardware.

Ilang concurrent user ang kayang i-serve ng isang maliit na GPU?

Memory ang bilangin, hindi ang users. Unahin ang weights, kasunod ang KV cache. Ang gastos nito ay 2 times layers times key/value heads times head dimension times bytes, bawat token at bawat active conversation. Ang karaniwang 8B model na may 36 layers, 8 key/value heads, at head dimension na 128 ay gumagamit ng humigit-kumulang 144 KiB bawat token sa 16-bit. Kaya ang conversation na may 8,192 token ay nangangailangan ng tinatayang 1.2 GB. Ang 24 GB card na may hawak sa model na iyon sa 16-bit ay may humigit-kumulang 6 GB na natitira para sa cache. Sapat ito para sa mga limang conversation sa full context, o higit pa kung paiikliin 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 trabaho sa bawat decoding step. Kinukuha ng prefill ng bagong arrival ang bahagi ng isang step mula sa mga user na nagse-stream. Kapag na-preempt ang isang request, kailangan nitong 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 naitatago ng averages.

Dapat ko bang taasan ang OLLAMA_NUM_PARALLEL o lumipat sa vLLM?

Unahin ang pagtaas ng parallel count. Wala itong dagdag na gastos 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 hawakan, kaya bantayan kung may layers na napupunta sa CPU. Lumipat sa vLLM kapag may GPU kang may ekstrang VRAM at higit sa humigit-kumulang apat na request ang tunay na sabay-sabay na tumatakbo. Sa puntong ito, 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 pinakapansin ng users. Sa decode, binabasa ang buong model mula sa memory para sa bawat token, kaya nakadepende ito sa RAM bandwidth. Hindi na nakatutulong ang dagdag na cores kapag saturated na ang bandwidth. Gumaganda naman ang bilis ng prefill kapag mas maraming core, kaya umiikli ang time to first token sa mahahabang prompt. Sa 4 hanggang 8 GB VPS, karaniwang memory capacity ang pangunahing limitasyon. Ang epektibong solusyon ay mas maliit na model o mas maikling context, hindi mas maraming vCPU.