Kwa nini LLM yako hupunguza kasi kwa watumiaji 5?

Kwa nini LLM inayojiendesha yenyewe hupunguza kasi watumiaji wanapoongezeka?

LLM inayojiendesha yenyewe hukwama ikiwa na watumiaji 5 kwa wakati mmoja kwa sababu seva bado inazalisha jibu moja kwa wakati mmoja, na wengine wanne wanasubiri kwenye foleni. Nyaraka za Ollama ziko wazi kuhusu thamani ya msingi: OLLAMA_NUM_PARALLEL ni "idadi ya juu zaidi ya maombi sambamba ambayo kila modeli itachakata kwa wakati mmoja, thamani ya msingi ni 1." Hakuna kilichoharibika. Watu wanne kati ya watano wako kwenye foleni wakisubiri zamu yao.

Urekebishaji wake mara chache huhitaji seva kubwa zaidi. Unahitaji injini ya kuhudumia (serving engine) inayoweza kusukuma maombi mengi kupitia modeli katika hatua moja ya forward pass, pamoja na kumbukumbu ya kutosha ya kuhifadhi mazungumzo ya kila mtu wakati inafanya kazi hiyo. Sehemu zote mbili ni muhimu, na ya pili ndiyo inayoweka kikomo cha uwezo wako.

Awamu mbili ambazo kila ombi hupitia

Prefill husoma prompt nzima kwa wakati mmoja na kujenga attention cache yake. Kila token ya prompt hupitia kwenye model kwa pamoja, kwa hivyo prefill ni matrix multiply moja kubwa, na kikomo chake ni arithmetic throughput. Decode kisha huandika jibu token moja kwa wakati. Kila token inahitaji uzito (weights) kamili wa model usomwe kutoka kwenye kumbukumbu tena, wakati hesabu inayofanyika kwenye token hiyo moja ni ndogo sana. Decode ina kikomo cha memory bandwidth.

Asymmetry hiyo ndiyo sababu kuu inayofanya batching kufanya kazi. Decoding kwa mtumiaji mmoja husoma, tuseme, 5 GB ya weights kwa kila token na kuacha sehemu kubwa ya vitengo vya hesabu (arithmetic units) bila kazi. Ukiongeza ombi la pili, injini husoma 5 GB ileile mara moja, kisha huhesabu token mbili kutoka hapo. Mtumiaji wa pili hatumii muda wowote wa ziada. Kuhudumia maombi moja baada ya jingine kwa ukali hupoteza faida hiyo.

Namba mbili hufafanua kile mtumiaji anachokiona. TTFT (time to first token) ni muda wa kusubiri kwenye foleni pamoja na prefill. ITL (inter-token latency) ni pengo kati ya token zinazotiririshwa, na huwekwa na decode. Seva ya polepole kwa kawaida huwa na tatizo katika mojawapo ya haya, na masuluhisho yake si sawa. Ni muhimu kubaini ni ipi unayopambana nayo kabla ya kubadilisha mpangilio wowote, na kupima prefill na decode kando ndiyo njia ya kujua.

Static batching huwafanya wote kusubiri jibu la polepole zaidi

Static batching ni mbinu ya msingi, na ndiyo unayopata unapojipangia maombi mwenyewe kwenye msimbo wa programu. Injini hukusanya maombi N, huyaendesha pamoja, na kushikilia kila nafasi hadi kizazi kirefu zaidi kwenye kundi hilo kikamilike.

Mtumiaji mmoja anayeomba muhtasari wa token 1,200 huweka majibu manne ya mstari mmoja yakiwa yamefungwa kwenye batch, kwa sababu batch haitoi nafasi yoyote hadi mwanachama wake wa polepole zaidi amalize.

Gharama mbili hujitokeza. Mfuatano uliokamilika huendelea kuchukua nafasi ambazo hazifanyi hesabu yoyote muhimu, kwa hivyo throughput halisi hupungua kadiri urefu wa matokeo unavyotofautiana, na urefu wa matokeo ya gumzo hutofautiana sana. Ombi linalowasili hatua moja baada ya batch kuundwa husubiri batch nzima imalizike kabla hata ya kuanza prefill, jambo linalomaanisha kuwa TTFT yake huamuliwa na insha ya mtu mwingine.

Continuous batching hukubali na kuhitimisha maombi kwa kila token

Continuous batching hupanga ratiba katika kiwango cha hatua moja ya decoding. Baada ya kila hatua, scheduler huondoa mfuatano uliotoa token ya kusitisha (stop token), kisha hukubali maombi yanayosubiri kwenye nafasi zilizo wazi. Jibu linalomalizika katika hatua ya 40 huacha nafasi yake katika hatua ya 40, si mwishoni mwa batch.

Hili si jambo geni. llama-server huandika -cb, --cont-batching kama "kama kuwezesha continuous batching (au dynamic batching) (chaguo-msingi: imewezeshwa)", na vLLM imejengwa kwa msingi wa wazo hili. Ollama pia huhudumia maombi sambamba (parallel requests). Chaguo-msingi hupunguza idadi hiyo hadi moja, ndiyo maana watu wengi huhitimisha kuwa maunzi yao hayawezi kufanya concurrency, ilhali usanidi wao ndio uliokataa.

Matokeo yaliyochapishwa ya continuous batching kwa kawaida hupimwa kwenye kadi za datacenter ambazo zina nguvu ya ziada ya kompyuta na makumi ya gigabytes kwa ajili ya cache. Umbo la matokeo hayo huhamishika hadi kwenye mashine yako. Ukubwa wake hauhamishiki, na sehemu ya kumbukumbu hapa chini ndiyo sababu.

Prefill inashindana na decode kwa ajili ya rasilimali za kompyuta

Ombi jipya linapowasili wakati majibu manne yanatiririka, prompt yake lazima ifanyiwe prefill kwanza, na prefill inahitaji nguvu kubwa ya kompyuta. Ikiwa scheduler itatoa hatua ya kipekee kwa prefill hiyo, watumiaji wanne wanaotiririsha data hawapokei token yoyote wakati huo. Kwenye prompt ndefu, hii ni kusita kunakoonekana katika kila dirisha lililofunguliwa. Hii ndiyo hali ya kukwama ambayo watu huirejelea wanaposema seva inasita kila wakati mtu mwingine anapobonyeza kitufe cha kutuma.

Chunked prefill huvunja prompt ndefu katika vipande na kuchanganya kila kipande kwenye hatua moja na decode zinazoendelea. Mwongozo wa tuning wa vLLM unaeleza bayana uwiano huo: bajeti ndogo za chunk "hufanikisha ITL bora zaidi kwa sababu kuna prefill chache zinazochelewesha decode", wakati thamani za juu "hufanikisha muda bora zaidi wa kupata token ya kwanza (TTFT) kwa kuwa unaweza kuchakata token nyingi zaidi za prefill katika batch moja". Unachagua ni uzoefu wa nani wa kulinda: mtu anayesubiri jibu lianze, au watu wanaotazama maandishi yakitiririka.

Urefu wa prompt huamua ukubwa wa athari hii. Prompt ya token 6,000 yenye jibu la token 200 ni kazi ya prefill ya token 6,000 dhidi ya hatua 200 za decode. Mazungumzo yanayotumia retrieval-augmented na system prompts ndefu vyote vinakuingiza katika hali hiyo, hivyo prefill huacha kuwa kiasi kidogo kisicho na maana na kuwa kitu ambacho watumiaji wanasubiri. Prefix caching husaidia wakati sehemu ndefu inajirudia: vLLM hutoa --enable-prefix-caching, ambayo hutumia tena cache kwa ajili ya prefix ya prompt inayoshirikiwa badala ya kuikokotoa upya kwa kila ombi.

Kumbukumbu inayokwisha kwanza ni KV cache

Kila token katika mazungumzo yanayoendelea huacha key vector na value vector katika kila layer ya model. Hiyo ndiyo KV cache (key/value cache), na ndiyo inayoiwezesha hatua ya decode kuepuka kukokotoa upya prompt nzima kwa kila token mpya. Ukubwa wake kwa kila token huamuliwa na umbo la model: 2 (key moja, value moja) mara idadi ya layers, mara idadi ya key/value heads, mara dimension ya head, mara bytes kwa kila value. Soma namba hizo kutoka kwenye config.json ya model.

Kokotoa mara moja na kikomo hakitakuwa siri tena. Model ya kawaida ya 8B yenye layers 36, key/value heads 8 na head dimension ya 128, ikihifadhi cache katika 16-bit, hutumia 2 36 8 128 2 bytes kwa kila token. Hiyo ni 147,456 bytes, takriban 144 KiB. Kwa hivyo, mazungumzo ya token 8,192 yanahitaji takriban 1.2 GB ya cache. Matano kati ya hayo yanahitaji takriban 6 GB, juu ya uzito wa model (weights), na hiyo ndiyo jibu halisi la ni watumiaji wangapi wanaotoshea.

Concurrency huzidisha context, na zana husema hivyo waziwazi. FAQ ya Ollama: "Uchakataji wa maombi sambamba (parallel) kwa model fulani husababisha kuongezeka kwa ukubwa wa context kulingana na idadi ya maombi hayo. Kwa mfano, context ya 2K yenye maombi 4 sambamba itasababisha context ya 8K na mgao wa ziada wa kumbukumbu." RAM inayohitajika huongezeka kwa OLLAMA_NUM_PARALLEL kuzidishwa na OLLAMA_CONTEXT_LENGTH. Katika llama-server, context unayoomba kwa -c hugawanywa katika slots za -np, kwa hivyo kuongeza idadi ya slots pekee hupunguza kile kila ombi linaweza kushikilia. Soma context ya kila slot kutoka kwenye log ya kuanzisha (startup log) badala ya kukisia.

vLLM hutenga kumbukumbu mapema (preallocate). --gpu-memory-utilization (default 0.92) ni "sehemu ya kumbukumbu ya GPU itakayotumiwa na executor ya model". Kile kinachobaki baada ya weights huwa paged KV pool, na wakati pool hiyo inapopungua, scheduler huondoa ombi (evict) badala ya kulifanya lishindwe:

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.

Katika engine ya V1 ya vLLM, hali ya kawaida ya preemption ni RECOMPUTE, kwa hivyo ombi lililoondolewa hutupa cache yake na kufanya prefill tena linaporuhusiwa kurudi. Kazi hiyo hufanyika mara mbili. Nyaraka zinaonya kwamba "preemption na recomputation vinaweza kuathiri vibaya latency ya mwisho hadi mwisho", na mstari huu wa log ndio maelezo bora zaidi ya kwa nini mtumiaji mmoja mwenye bahati mbaya alingoja muda mrefu zaidi kuliko wengine wote wakati wastani wako ulionekana kuwa mzuri. Weka disable_log_stats=False ili kurekodi idadi ya jumla, au soma counter ya preemption kutoka kwenye Prometheus metrics ambazo vLLM hutoa.

Mabadiliko yanayotokea kwa watumiaji 2, 5 na 20 kwa wakati mmoja

Watumiaji wawili. Karibu haionekani kwenye GPU yenye cache ya ziada, kwa sababu mtiririko wa pili wa decode huambatana na wa kwanza kwa muda mfupi sana wa ziada. Kwenye VPS inayotumia CPU pekee yenye 4 hadi 8 GB ya RAM, hii si bure: mitiririko yote miwili hushiriki vCPU chache zilezile na bandwidth ileile ya RAM, kwa hivyo kila mtumiaji huona takriban nusu ya token kwa sekunde, na mahitaji ya cache huongezeka maradufu dhidi ya bajeti ndogo zaidi.

Watumiaji watano. Hapa ndipo mipangilio chaguo-msingi inapokoma kutosheleza, na tatizo huanza kama foleni. Kwa OLLAMA_NUM_PARALLEL ikiwa 1, watu wanne husubiri yeyote aliyeomba jibu refu, na kila mmoja wao huona kasi ya kawaida wakati zamu yake inapofika. Ongeza idadi ya parallel na tatizo hubadilika umbo: nafasi tano zenye 8K context kila moja ni 40K ya token cache inayopaswa kupatikana. Ikiwa haitoshei kwenye VRAM, injini huhamisha layers kwenye RAM ya mfumo, na ikiwa haitoshei kwenye RAM, mashine huanza kufanya swapping na token kwa sekunde huporomoka.

Watumiaji ishirini. Watu ishirini kwenye UI ya chat kwa kawaida si maombi ishirini ya wakati mmoja, na hili ndilo jambo muhimu zaidi kulielewa kabla ya kununua vifaa. Mtu husoma jibu na kufikiri kwa sekunde 20 hadi 60 kati ya zamu, kwa hivyo sehemu kubwa ya session yao huwa imetulia. Mawakala ishirini, au kazi ishirini za kufupisha hati, ni mitiririko ishirini halisi bila muda wowote wa kutulia. Hiyo ni mashine ya aina nyingine. Msanidi programu mmoja ambaye ameelekeza wakala wa kuandika msimbo kwenye seva yake ya Ollama yuko karibu zaidi na hali ya pili kuliko ya kwanza, kwa sababu wakala huendelea kutuma maombi mradi kazi inaendelea na haachi mapumziko ya kusoma kama anavyofanya binadamu.

Je, watumiaji wako wanatumia huduma kwa wakati mmoja, au wameingia tu kwenye mfumo?

Bainisha idadi ya maombi yanayochakatwa (requests in flight) kabla ya kupima ukubwa wa mfumo wowote. Hesabu yake ni ya kawaida: maombi yanayochakatwa ni sawa na idadi ya watumiaji, ikizidishwa na sekunde zinazotumika kutengeneza jibu kwa kila zamu, ikigawanywa kwa sekunde kati ya zamu moja na nyingine.

1. Pima kasi yako ya mtiririko mmoja (single-stream speed) kwanza, kwa prefill na decode zote mbili. Usiazime namba kutoka kwenye kadi ya mtu mwingine: pima tokens kwa sekunde kwenye seva yako mwenyewe na utumie matokeo unayopata.
2. Kadiria mzunguko wa kazi (duty cycle). Watumiaji ishirini wa chat, sekunde 12 za utengenezaji kwa kila zamu, zamu moja kila sekunde 90, inatoa 20 * 12 / 90, ambayo ni takriban maombi 2.7 yanayochakatwa kwa wakati mmoja.
3. Weka idadi ya slots juu kidogo ya hapo, kisha uilinganishe na kumbukumbu: idadi ya slots ikizidishwa na muktadha wa kila ombi (per-request context) lazima itoshe ndani ya cache tokens ulizonazo.
4. Weka foleni (queue) ikiwa fupi ili overflow ifeli haraka na kwa njia inayoonekana.

Cache tokens zinazopatikana ni kumbukumbu iliyobaki baada ya kutoa uzito (weights), ikigawanywa kwa gharama ya kila token kutoka sehemu iliyotangulia. Kadi ya 24 GB inayoendesha model ya 8B katika 16-bit hutumia takriban 16 GB kwa uzito na ina takriban 6 GB ya cache inayoweza kutumika kwa matumizi ya kawaida, ambayo ni sawa na mazungumzo matano ya 8K. Ili kutosheleza zaidi, fupisha muktadha wa kila ombi, au hifadhi cache katika 8-bit (llama-server inachukua --cache-type-k q8_0). Zote mbili huongeza uwezo wa kufanya kazi kwa wakati mmoja (concurrency) kwa kutoa kitu kingine, na ni vyema kusoma toleo la kweli la biashara hiyo kabla ya kuwekeza pesa kwenye vifaa: wapi GPU VPS inafikia usawa wa gharama dhidi ya API tokens.

Wakati mipangilio chaguo-msingi ya Ollama haitoshi tena

Ongeza idadi ya maombi yanayochakatwa kwa wakati mmoja (parallel count) kupitia unit ya huduma, kwa sababu export ya shell haitafika kwenye daemon inayodhibitiwa na systemd.

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 inapaswa kuonyesha vigezo vitatu ulivyoweka sasa hivi. Ikiwa haionyeshi, basi drop-in haikuhifadhiwa, na hakuna kingine utakachofanya kitakachosaidia. ollama ps kisha huorodhesha modeli iliyopakiwa ikiwa na ukubwa mkubwa kuliko uzito (weights) pekee, kwa sababu nafasi nne za 8,192 tokens huhifadhi 32,768 tokens za cache kando yake. Safu ya PROCESSOR inayoonyesha sehemu ya modeli kwenye CPU wakati ulitarajia yote iwe kwenye GPU inamaanisha uliomba cache nyingi kuliko kile ambacho kadi ilikuwa nacho. Punguza mojawapo ya namba hizo mbili. Kupunguza context kwa kawaida ni njia salama zaidi, lakini dirisha dogo mno litakata prompts ndefu kimya kimya badala ya kutoa error, hivyo ni vyema kupanga num_ctx kwa makusudi badala ya kuipunguza hadi modeli itoshee.

Chaguo-msingi la foleni (queue) linastahili kuangaliwa upya. Ollama hupanga hadi maombi OLLAMA_MAX_QUEUE, na "chaguo-msingi ni 512". Baada ya hapo, hujibu "kwa error ya 503 inayoashiria kuwa seva imezidiwa". Foleni ya 512 kwenye seva inayohudumia wanne kwa wakati mmoja ni ahadi ambayo huwezi kuitekeleza, kwa sababu mteja aliye kwenye nafasi ya 300 atapata timeout muda mrefu kabla ya zamu yake kufika. Foleni fupi hurejesha error ambayo programu yako inaweza kujaribu tena au kutoa taarifa, jambo ambalo ni bora kuliko spinner isiyomalizika.

Ijaribu kikamilifu. Tuma maombi mawili kwa wakati mmoja kutoka kwenye terminal mbili na ufuatilie yote mawili. Ikiwa la pili halitoi matokeo yoyote hadi la kwanza limalize, basi mpangilio wa parallel haukufanya kazi.

Wakati injini ya kuhudumia maombi inapoanza kujilipia

vLLM inastahili usanidi wake wa ziada pale unapokuwa na GPU yenye nafasi ya kutosha na zaidi ya maombi manne yanayochakatwa kwa wakati mmoja. Kipanga-ratiba chake hufanya kazi kwa kila token, cache yake imegawanywa katika kurasa ili vipande vilivyo wazi vitumike tena, na hubadilisha VRAM iliyobaki kuwa uwezo wa kuchakata maombi mengi badala ya kuiacha bila kazi. Kufikia Agosti 2026, usakinishaji na uanzishaji uliothibitishwa ni amri mbili:

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

Jibu lenye array ya choices linamaanisha seva imewaka na model imepakiwa. Chini ya mzigo wa kazi, vitufe viwili muhimu ni --max-num-seqs, "idadi ya juu ya sequences zinazoweza kuchakatwa katika iteration moja", na --max-num-batched-tokens, "idadi ya juu ya tokens zinazoweza kuchakatwa katika iteration moja". Cha kwanza hupunguza uwezo wa kuchakata maombi mengi. Cha pili ni bajeti ya chunked prefill iliyoelezwa awali.

Chini ya maombi manne yanayochakatwa, au kwenye mashine yoyote isiyo na GPU inayotumika, vLLM huongeza ugumu bila faida kubwa. Inatarajia kadi ya daraja la CUDA na huchukua sehemu kubwa ya kumbukumbu wakati wa kuanza, jambo ambalo ni uamuzi mbaya kwenye VPS ya 4 hadi 8 GB. Huko, jibu ni kutumia model ndogo yenye context fupi na foleni unayoimiliki. jinsi Ollama na vLLM zinavyotofautiana kama injini za kuhudumia inashughulikia chaguo hili kikamilifu, na kuendesha Qwen 3 8B kwenye VPS inaonyesha kile ambacho model ya ukubwa wa kati inahitaji kabla hujaongeza hata mtumiaji mmoja wa ziada.

Mambo ya kuzingatia ambayo mara nyingi hayasemwi

Continuous batching huongeza jumla ya throughput, na kwa kawaida huboresha median latency pia, kwa sababu ombi lililopo kwenye foleni huanza kuchakatwa mapema. Hata hivyo, tail latency huathirika vibaya, na upande huu mara nyingi hauzungumziwi.

Kila sequence ya ziada katika hatua moja huongeza kiasi kidogo cha kazi, hivyo ITL huongezeka kwa kila mtu kadiri batch inavyojaa. Prefill ya ombi jipya huchukua sehemu ya muda wa hatua ambayo watumiaji wanaopokea data kwa mtiririko (streaming) wangeitumia. Chini ya shinikizo la cache, scheduler hufanya preemption, jambo ambalo hurudisha ombi lililozalishwa nusu kuanza upya mchakato wake wa prefill.

UI ya chat huonyesha tails, si wastani. Mtiririko wa data unaositisha kwa sekunde mbili katikati ya sentensi huonekana kama umeharibika, hata kama muda wa jumla wa kukamilisha kazi ni mzuri. Pima p95 TTFT na p95 ITL chini ya mzigo unaotarajia, na chukulia wastani wa tokens kwa sekunde kama namba ya uwezo wa mfumo badala ya maelezo ya uzoefu wa mtumiaji.

Usanidi wa kivitendo hutokana na hayo. Punguza concurrency kidogo chini ya kile ambacho kumbukumbu (memory) inaruhusu, ili engine isilazimike kufanya preemption. Foleni fupi inayotabirika ni bora kuliko batch kubwa inayosababisha thrashing, kwa sababu mtumiaji anayesubiri sekunde nne kisha akapokea data kwa mtiririko laini anaridhika zaidi kuliko mtumiaji anayeanza mara moja kisha akakwama mara mbili.

Mambo ya kukagua wakati mfumo ni mzito

Kila mtumiaji ni wa kawaida, lakini kusubiri ni kwingi. Hii ni foleni (queue), si tatizo la kasi. Kagua mpangilio wa parallel kwanza. Model inahudumia kwa usahihi, ombi moja kwa wakati mmoja.

HTTP 503 kutoka kwa Ollama. Foleni imejaa. Aidha seva imefika uwezo wake wa juu, au OLLAMA_MAX_QUEUE imewekwa chini kwa makusudi ili kupunguza mzigo, jambo ambalo ndilo unalotaka lifanyike.

Tokens kwa sekunde hupungua sana chini ya mzigo kwenye seva ya CPU. Endesha vmstat 1 wakati tatizo linatokea. Safu wima za si na so zisizo sifuri humaanisha mashine inafanya swapping, kwa hivyo weights zinasomwa kutoka kwenye diski kwa kila token. Hakuna mabadiliko ya configuration yatakayosaidia hili. Punguza ukubwa wa model au idadi ya slots.

Mtumiaji mmoja kati ya kumi anasubiri muda mrefu zaidi ya wengine. Tafuta preempted kwenye log ya vLLM. Preemption na uhesabuji wake upya ndiyo sababu ya kawaida, na hii humaanisha cache imezidiwa kwa urefu wa context unaoruhusu.

TTFT ni mbaya hata wakati seva haina kazi. Hii ni prefill, si concurrency. Prompt ndefu huchukua muda halisi kabla ya token ya kwanza kuonekana, kwa hivyo angalia ukubwa wa prompt na prefix caching kabla ya kuangalia hardware. Ikiwa kusubiri kwa muda mrefu kunampata mtu wa kwanza tu baada ya kipindi cha utulivu na kila mtu anayefuata yuko sawa, hiyo si prefill hata kidogo bali ni Ollama kuondoa model kwenye kumbukumbu na kusoma weights kutoka kwenye diski tena, jambo ambalo ni vyema kuliondoa kwa kuiweka model kwenye kumbukumbu kati ya maombi.

FAQ

Kwa nini LLM yangu inayojiendesha hupunguza kasi wakati mtu wa pili anaitumia?

Mara nyingi haipunguzi kasi hata kidogo. Inajipanga kwenye foleni. Ollama inatolewa na OLLAMA_NUM_PARALLEL ikiwa 1, kwa hivyo ombi la pili husubiri la kwanza likamilishe kutoa token yake ya mwisho. Tofautisha hali hizi mbili kwa kupima kasi ya mtiririko wa mtumiaji mmoja wakati mwingine anasubiri: ikiwa token kwa sekunde ni ya kawaida pindi zinapoanza, una foleni, na kuongeza idadi ya parallel kutatatua tatizo hilo. Ikiwa mitiririko yote miwili inaenda kwa nusu kasi, unashiriki bandwidth ya kumbukumbu, na huo ni ukomo wa vifaa (hardware).

Watumiaji wangapi wa wakati mmoja wanaweza kuhudumiwa na GPU moja ndogo?

Hesabu kumbukumbu, si watumiaji. Uzito (weights) kwanza, kisha KV cache, ambayo hugharimu mara 2 ya tabaka (layers) mara vichwa vya key/value mara mwelekeo wa kichwa (head dimension) mara baiti, kwa kila token, kwa kila mazungumzo yanayoendelea. Model ya kawaida ya 8B yenye tabaka 36, vichwa 8 vya key/value na mwelekeo wa kichwa 128 hugharimu takriban 144 KiB kwa kila token katika 16-bit, kwa hivyo mazungumzo ya token 8,192 yanahitaji takriban 1.2 GB. Kadi ya 24 GB inayoshikilia model hiyo katika 16-bit ina takriban 6 GB iliyobaki kwa ajili ya cache, ambayo ni takriban mazungumzo matano kwa muktadha kamili, au zaidi ukifupisha muktadha.

Je, continuous batching hufanya jibu la kila mtumiaji kuwa polepole?

Latency ya wastani (median) kwa kawaida huboreka, kwa sababu maombi huacha kusubiri kundi zima (batch) likamilike. Latency ya mwisho (tail latency) huwa mbaya zaidi. Kila mlolongo wa ziada huongeza kazi katika kila hatua ya kusimbua (decoding), prefill ya mtumiaji mpya huiba sehemu ya hatua kutoka kwa watumiaji wanaotiririsha, na ombi lililokatizwa lazima lifanye prefill mara mbili. Pima p95 inter-token latency, si wastani, kwa sababu dirisha la gumzo hufanya kusita kuonekana kwa njia ambayo wastani huficha.

Je, niongeze OLLAMA_NUM_PARALLEL au nihamie vLLM?

Ongeza idadi ya parallel kwanza. Ni bure na inahitaji faili moja tu ya ziada, na inatatua hali ya kawaida ambapo watu wanne hupanga foleni nyuma ya jibu moja refu. Kumbukumbu ndiyo kikomo: maombi ya parallel huzidisha muktadha ambao lazima ushikilie, kwa hivyo angalia tabaka zinazohamia kwenye CPU. Hamia vLLM wakati una GPU yenye VRAM ya ziada na zaidi ya maombi manne yanayoendelea kikamilifu, kwa sababu hiyo ndiyo hatua ambapo paged cache na upangaji wa kila token hurejesha zaidi ya gharama zake.

Je, cores zaidi za CPU zitatatua seva ya LLM ya polepole?

Si kwa sehemu ambayo watumiaji huiona zaidi. Decode husoma model nzima kutoka kwenye kumbukumbu kwa kila token, kwa hivyo inafungwa na bandwidth ya RAM, na cores za ziada huacha kusaidia pindi bandwidth inapojaa. Prefill huongezeka kulingana na cores, kwa hivyo nyingi zaidi hupunguza muda wa kupata token ya kwanza kwenye maombi marefu. Kwenye VPS ya 4 hadi 8 GB, kikwazo kikuu kwa kawaida ni uwezo wa kumbukumbu, na suluhisho la kweli ni model ndogo au muktadha mfupi badala ya vCPU nyingi zaidi.