Kwa nini LLM yako hupungua kasi kwa watumiaji 5?

Kwa nini LLM inayojiendesha yenyewe hupungua 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 mpangilio chaguo-msingi: OLLAMA_NUM_PARALLEL ni "idadi ya juu zaidi ya maombi sambamba ambayo kila modeli itachakata kwa wakati mmoja, chaguo-msingi ni 1." Hakuna kilichoharibika. Watu wanne kati ya watano wako kwenye foleni wakisubiri zamu yao.

Ukarabati wake mara chache huhitaji seva kubwa zaidi. Unahitaji injini ya kuhudumia (serving engine) inayopitisha maombi mengi kupitia modeli katika hatua moja ya mbele (forward pass), pamoja na kumbukumbu ya kutosha ya ziada ili 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 mara moja na kujenga attention cache kwa ajili yake. Kila token ya prompt hupitia kwenye model kwa pamoja, kwa hivyo prefill ni matrix multiply kubwa moja, na ina kikomo cha arithmetic throughput. Decode kisha huandika jibu token moja kwa wakati mmoja. 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 uzito kwa kila token na kuacha sehemu kubwa ya vitengo vya hesabu bila kazi. Ongeza ombi la pili na injini husoma 5 GB ileile mara moja, kisha huhesabu token mbili kutoka humo. Mtumiaji wa pili hugharimu karibu muda wowote wa ziada. Kuhudumia maombi kwa kufuatana moja baada ya nyingine hupoteza faida hiyo.

Namba mbili huelezea kile mtumiaji anachohisi. 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 marekebisho yake si sawa.

Static batching inamlazimisha kila mtu kusubiri jibu la polepole zaidi

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

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

Gharama mbili hujitokeza. Mfuatano (sequences) uliomalizika huendelea kuchukua nafasi ambazo hazifanyi kazi yoyote muhimu, hivyo throughput bora hupungua kadiri urefu wa matokeo unavyotofautiana, na urefu wa matokeo ya chat hutofautiana sana. Ombi linalofika hatua moja baada ya batch kuundwa husubiri batch nzima imalize kabla halijaanza 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 (sequences) ambao umetoa token ya kusimama (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 inaelezea -cb, --cont-batching kama "kama kuwezesha continuous batching (inayojulikana pia kama 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, wakati 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 huhamia kwenye mashine yako. Ukubwa wake hauhami, 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 wanaopokea data hawatapata token yoyote wakati huo. Kwenye prompt ndefu, hii husababisha kusimama kwa muda kunakoonekana katika kila dirisha lililo wazi. Hii ndiyo hali ya kukwama (stutter) ambayo watu huirejelea wanaposema seva hupata hitilafu kila 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 kwa sababu kuna prefill chache zinazochelewesha decode", wakati thamani kubwa "hufanikisha muda bora wa kupata token ya kwanza (TTFT) kwa sababu 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 wanakisubiri. 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 kila mazungumzo yanayoendelea huacha key vector na value vector katika kila safu ya model. Hiyo ndiyo KV cache (key/value cache), na ndiyo inayoiwezesha mchakato wa decode kuepuka kukokotoa upya prompt nzima kwa kila token mpya. Ukubwa wake kwa kila token hupangwa na umbo la model: 2 (key moja, value moja) mara idadi ya safu, mara idadi ya key/value heads, mara ukubwa wa head, mara idadi ya bytes kwa kila value. Soma namba hizo kutoka kwenye config.json ya model.

Fanya hesabu hiyo mara moja na kikomo hakitakuwa siri tena. Model ya kawaida ya 8B yenye safu 36, key/value heads 8 na ukubwa wa head 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. Mazungumzo matano yanahitaji takriban 6 GB, juu ya uzito wa model (weights), na hiyo ndiyo jibu halisi la idadi ya watumiaji wanaoweza kutoshea.

Concurrency huongeza context, na zana husema hivyo waziwazi. FAQ ya Ollama: "Parallel request processing kwa model fulani husababisha kuongezeka kwa ukubwa wa context kulingana na idadi ya maombi yanayofanyika kwa wakati mmoja. Kwa mfano, context ya 2K yenye maombi 4 ya wakati mmoja itasababisha context ya 8K na matumizi ya ziada ya kumbukumbu." RAM inayohitajika huongezeka kulingana na OLLAMA_NUM_PARALLEL mara OLLAMA_CONTEXT_LENGTH. Katika llama-server, context unayoomba kwa kutumia -c hugawanywa katika slots za -np, kwa hivyo kuongeza idadi ya slots pekee hupunguza kile kila ombi linaweza kuhifadhi. Soma context ya kila slot kutoka kwenye log ya kuanza (startup log) badala ya kukisia.

vLLM hutenga kumbukumbu mapema (preallocate). --gpu-memory-utilization (default 0.92) ni "sehemu ya kumbukumbu ya GPU itakayotumiwa na model executor". Chochote 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 default ya preemption ni RECOMPUTE, kwa hivyo ombi lililoondolewa hutupa cache yake na kufanya prefill tena linaporuhusiwa kurudi. Kazi hiyo hufanyika mara mbili. Nyaraka zinaonya kuwa "preemption na recomputation vinaweza kuathiri vibaya latency ya mwisho hadi mwisho", na mstari huu wa log ndio ufafanuzi bora zaidi wa 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. Hii haionekani kabisa 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 inashiriki idadi ndogo ya vCPU na bandwidth sawa ya RAM, 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. Ikiwa OLLAMA_NUM_PARALLEL ni 1, watu wanne husubiri yeyote aliyeomba jibu refu, na kila mmoja wao huona kasi ya kawaida pindi zamu yake inapofika. Ongeza idadi ya parallel na tatizo hubadilika sura: nafasi tano zenye 8K context kila moja inamaanisha cache ya 40K ya kutafuta. Ikiwa haitoshei kwenye VRAM, injini huhamishia layers kwenye RAM ya mfumo, na ikiwa haitoshei kwenye RAM, seva huanza kufanya swapping na kasi ya token kwa sekunde huanguka kabisa.

Watumiaji ishirini. Binadamu ishirini kwenye UI ya chat kwa kawaida hawatoi maombi ishirini kwa wakati mmoja, na hili ndilo jambo muhimu zaidi kulielewa kabla ya kununua vifaa. Mtu husoma jibu na kufikiria kwa sekunde 20 hadi 60 kati ya zamu, hivyo sehemu kubwa ya session yao huwa imetulia (idle). Mawakala ishirini, au kazi ishirini za kufupisha nyaraka, ni mitiririko ishirini halisi isiyo na muda wowote wa kutulia. Hiyo inahitaji mashine ya aina nyingine.

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

Bainisha maombi yanayochakatwa (requests in flight) kabla ya kupanga ukubwa wa rasilimali. Hesabu yake ni ya kawaida: maombi yanayochakatwa ni sawa na idadi ya watumiaji, mara 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) kwanza, ukijumuisha prefill na decode. 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 mara muktadha (context) wa kila ombi lazima iwe ndani ya cache tokens ulizonazo.
4. Weka foleni (queue) ikiwa fupi ili overflow ifeli haraka na kwa uwazi.

Cache tokens zinazopatikana ni kumbukumbu iliyobaki baada ya kupunguza uzito wa modeli (weights), ikigawanywa kwa gharama ya kila token kutoka sehemu iliyotangulia. Kadi ya 24 GB inayoendesha modeli ya 8B katika 16-bit hutumia takriban 16 GB kwa weights na ina takriban 6 GB ya cache inayoweza kutumika kwa utumiaji wa 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 kuhudumia watumiaji wengi kwa kutoa kitu kingine, na ni vyema kusoma ukweli kuhusu biashara hiyo kabla ya kuwekeza pesa kwenye vifaa: wapi GPU VPS inakuwa na faida ikilinganishwa na API tokens.

Wakati mipangilio chaguo-msingi ya Ollama haitoshi

Ongeza idadi ya maombi yanayochakatwa sambamba (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 hivi punde. Ikiwa haionyeshi, basi faili ya 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 hutenga 32,768 tokens za cache kando yake. Safu ya PROCESSOR inayoonyesha sehemu ya modeli kwenye CPU wakati ulitarajia yote yawe kwenye GPU inamaanisha uliomba cache nyingi kuliko kile ambacho kadi ilikuwa nacho. Punguza mojawapo ya namba hizo mbili.

Chaguo-msingi la foleni (queue) linastahili kuangaliwa upya. Ollama hupanga foleni ya hadi OLLAMA_MAX_QUEUE maombi, na "chaguo-msingi ni 512". Baada ya hapo, hujibu "kwa error ya 503 inayoashiria seva imezidiwa". Foleni ya 512 kwenye mashine inayohudumia manne 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 hurudisha error ambayo programu yako inaweza kujaribu tena au kutoa taarifa, jambo ambalo ni bora kuliko spinner isiyoisha.

Ijaribu kikamilifu. Tuma maombi mawili kwa wakati mmoja kutoka kwenye terminal mbili na uyafuatilie 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 inathibitisha gharama ya usanidi wake unapokuwa na GPU yenye nafasi ya ziada na zaidi ya maombi manne yanayoshughulikiwa 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 kushughulikia maombi mengi badala ya kuiacha bila kazi. Kufikia Agosti 2026, usanidi 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 mzunguko mmoja", na --max-num-batched-tokens, "idadi ya juu ya tokens zinazoweza kuchakatwa katika mzunguko mmoja". Cha kwanza huzuia idadi ya maombi ya wakati mmoja. Cha pili ni bajeti ya chunked prefill iliyoelezwa awali.

Chini ya maombi manne yanayoshughulikiwa, au kwenye mashine yoyote isiyo na GPU inayotumika, vLLM huleta utata 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 inaelezea chaguo hili kikamilifu, na kuendesha Qwen 3 8B kwenye VPS inaonyesha mahitaji ya model ya wastani kabla ya kuongeza mtumiaji mmoja wa ziada.

Mambo ya kuzingatia ambayo mara nyingi hupuuzwa

Continuous batching huongeza uwezo wa jumla wa mfumo (throughput), na kwa kawaida huboresha muda wa wastani wa kusubiri (median latency), kwa sababu ombi lililopo kwenye foleni huanza kuchakatwa mapema. Hata hivyo, muda wa kusubiri wa mwisho (tail latency) huathirika vibaya, na upande huu mara nyingi hauzungumziwi.

Kila mlolongo (sequence) wa ziada katika hatua fulani 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 wa streaming wangeitumia. Chini ya shinikizo la cache, scheduler hufanya preemption, jambo linalorudisha ombi lililozalishwa nusu nyuma kwenye hatua ya kuanza ya prefill yake.

Kiolesura cha chat huonyesha hali halisi ya mwisho (tails), si wastani. Stream inayositisha kwa sekunde mbili katikati ya sentensi huonekana kama imevunjika, 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 (capacity) badala ya maelezo ya uzoefu wa mtumiaji.

Mpangilio wa kivitendo unatokana 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 akapata stream laini anafurahia zaidi kuliko mtumiaji anayeanza mara moja lakini akakwama mara mbili.

Nini cha kukagua wakati mfumo ni wa polepole

Kila mtumiaji ni wa kawaida, lakini muda wa kusubiri ni mrefu. Hii ni foleni, 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 imefikia uwezo wake wa juu, au OLLAMA_MAX_QUEUE imewekwa chini kwa makusudi ili kupunguza mzigo, jambo ambalo ndilo unalotaka lifanyike.

Tokens per second inashuka 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 recompute yake ndiyo sababu ya kawaida, na hii humaanisha cache imezidiwa kwa urefu wa context unaoruhusu.

TTFT ni mbaya hata wakati seva haifanyi 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.

FAQ

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

Mara nyingi haipunguzi kasi. Inapanga foleni. Ollama inatolewa ikiwa na OLLAMA_NUM_PARALLEL katika 1, kwa hivyo ombi la pili husubiri hadi la kwanza limalize 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 mara tu 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).

Ni watumiaji wangapi wa wakati mmoja wanaoweza kuhudumiwa na GPU moja ndogo?

Hesabu kumbukumbu, si watumiaji. Kwanza ni uzito (weights), 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 katika 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) kumalizika. 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 usumbufu uonekane wazi 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 kuweka, na inatatua hali ya kawaida ambapo watu wanne hupanga foleni nyuma ya jibu moja refu. Kumbukumbu ndiyo kikomo: maombi ya parallel huzidisha muktadha unaopaswa kushikilia, 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 scheduling ya kila token hutoa matokeo bora kuliko gharama yake.

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

Si kwa sehemu ambayo watumiaji huiona zaidi. Decode husoma model nzima kutoka kwenye kumbukumbu kwa kila token, kwa hivyo inategemea bandwidth ya RAM, na cores za ziada huacha kusaidia mara tu bandwidth inapojaa. Prefill hufanya kazi kulingana na cores, kwa hivyo cores nyingi hupunguza muda wa kupata token ya kwanza kwenye prompts ndefu. Kwenye VPS ya 4 hadi 8 GB, kikwazo kikuu kwa kawaida ni uwezo wa kumbukumbu, na suluhisho bora ni model ndogo au muktadha mfupi badala ya vCPUs zaidi.