Je, unahitaji VPS yenye GPU au CPU inatosha?

Je, unahitaji VPS yenye GPU, au CPU inatosha?

VPS yenye GPU hubadilisha mambo mawili katika kuendesha model wewe mwenyewe: kasi ya utoaji wa tokens, na ukubwa wa model inayoweza kutoshea kwenye kumbukumbu. Haibadilishi kitu kingine chochote. Ikiwa kazi yako ni kutumia quantized 7B hadi 27B chat model inayojibu mtu mmoja kwa wakati mmoja, kazi ya embedding yenye ujazo mdogo, au transcription ya sauti kwa kutumia Whisper small, VPS ya kawaida ya CPU yenye RAM ya kutosha inafanya kazi hiyo. Anza na CPU, pima namba inayokupa shida, kisha panda daraja.

Sababu ni bandwidth ya kumbukumbu. Wakati language model inatengeneza token moja, inasoma kila uzito (weight) unaohitajika kutoka kwenye kumbukumbu. Model ya 8B iliyofanyiwa quantization hadi bits 4 ina ukubwa wa takriban 4.9 GB kwenye diski na kiasi hicho hicho kwenye kumbukumbu, kwa hiyo kutengeneza token moja inamaanisha kusafirisha takriban 4.9 GB. Gawanya bandwidth ya kumbukumbu ya mashine hiyo kwa namba hiyo na utapata ukomo wa tokens kwa sekunde. Mgawanyo huo mmoja unaelezea karibu kila benchmark utakayosoma.

Faida halisi za kutumia GPU

Bandwidth. Kumbukumbu ya DDR5 kwenye seva ya kisasa huhamisha makumi ya gigabytes kwa sekunde. Kumbukumbu ya GPU (VRAM, video RAM) huhamisha mamia hadi zaidi ya elfu moja. Uwiano huu ndio kasi inayoongezeka, na ni kubwa sana.

Uwezo na kasi. Seva yenye CPU na 64 GB ya RAM inaweza kupakia model ya 70B kwa 4 bits. Itafanya kazi, lakini kwa kasi inayokaribia kasi ya kusoma kuliko ya kupiga gumzo. GPU inasaidia hapa tu ikiwa model inatosha ndani ya VRAM, kwa sababu wakati tabaka (layers) zinapohamia kwenye system RAM, njia ya polepole inachukua hatamu tena.

Batch throughput. Hili ni jambo ambalo watu wengi hulidharau. GPU inayozalisha majibu kwa mtumiaji mmoja huacha sehemu kubwa ya uwezo wake wa kuchakata ikiwa imetulia, kwa sababu inasubiri kumbukumbu. Hudumia maombi 20 kwa wakati mmoja na usomaji mmoja wa uzito (weight) utahudumia yote 20. Jumla ya tokens kwa sekunde huongezeka mara kadhaa huku kasi kwa kila mtumiaji ikishuka kidogo tu. Injini za inference za CPU kama llama.cpp pia huunga mkono batching, huku faida zikitegemea vifaa na mzigo wa kazi. Ikiwa unajenga API inayotumiwa na wateja wengi, batching ndiyo hoja kuu ya kutumia GPU, zaidi ya kasi ya mtiririko mmoja.

Uchakataji wa prompt. Kusoma prompt ndefu kunategemea uwezo wa kuchakata (compute-bound), si kumbukumbu, na hapa ndipo GPU zinaposhinda kwa kiasi kikubwa zaidi. Context ya tokens 30,000 ambayo CPU inachukua dakika nzima kuichakata, inachukua sekunde chache tu kwenye GPU. Mifumo ya utafutaji (retrieval) inayojaza hati kwenye kila ombi huhisi tofauti hii kila wakati.

Namba za makadirio, na jinsi ya kuzisoma

Throughput halisi huwa chini ya bandwidth ikigawanywa kwa ukubwa wa model, kwa sababu attention inayoongezeka kadiri context inavyokua huongeza kazi ambayo mgawanyo rahisi huipuuza.

Kwa kulinganisha, usomaji wa kimya wa watu wazima katika Kiingereza hufikia wastani wa maneno 4.0 hadi 4.3 kwa sekunde: maneno 238 kwa dakika kwa vitabu vya kweli na 260 kwa vitabu vya kubuni. Kasi yoyote ya kuanzia token 15 kwa sekunde na kuendelea tayari inahisi kama kasi ya kawaida ya kuandika kwa msomaji mmoja. Hii ndiyo sababu setups nyingi zinazotumia CPU pekee hufanya kazi vizuri bila matatizo.

Kukadiria VRAM kabla ya kununua

Ukubwa wa faili ya model ndio msingi, si mahitaji kamili. Panga bajeti kwa ajili ya weights, pamoja na KV cache (key-value cache, kumbukumbu ya kila token inayohifadhiwa na attention), na ongeza takriban 1 GB kwa ajili ya matumizi ya ziada ya mfumo.

Hesabu cache badala ya kuongeza asilimia ya jumla, kwa sababu quantization ya weights haifanyi quantization ya cache. Kwa kila token, model ya full-attention huhifadhi key na value kwa kila layer na kila KV head, kwa kutumia baiti 2 kwa kila namba katika FP16, ambayo ndiyo aina ya cache chaguo-msingi ya Ollama. Metadata ya model ya Ollama, iliyokaguliwa tarehe 2026-10-27, inaonyesha Llama 3.1 8B ina layers 32 na KV heads 8 za vipimo 128, ambayo inafanya 128 KiB kwa kila token: takriban 1.07 GB kwa context ya 8k na 2.15 GB kwa 16k. Kwa hivyo, model ya 8B yenye ukubwa wa 4.9 GB inahitaji takriban 7 GB ya VRAM kwa 8k na takriban 8 GB kwa 16k. Model ya 27B katika bits 4 ni takriban 17 GB (Gemma 3 27B katika maktaba ya Ollama). Metadata ya Gemma 3 inaorodhesha sliding window ya token 1,024, ambayo huzuia cache yake kukua sana, kwa hivyo panga 20 GB au zaidi. Model ya 70B katika bits 4 ni takriban 43 GB (Llama 3.3 70B). Ikiwa na layers 80, cache yake ya FP16 huongeza takriban 2.7 GB kwa 8k na 5.4 GB kwa 16k, kwa hivyo inahitaji kadi ya 48 GB ikiwa na nafasi ndogo, au kadi mbili ndogo. Hesabu hiyo hiyo inaendelea kufanya kazi hata zaidi ya hapo, na hesabu ya VRAM kwa model ya vigezo trilioni 2.8 kama Kimi K3 inaonyesha mahali ambapo kuchagua kadi hakuwi swali tena.

Context ndefu ndipo hili linapokuwa muhimu zaidi. Kwenye model za full-attention kama Llama 3.1, KV cache hukua kulingana na urefu wa context, na kwa token 128k inaweza kuzidi uzito wa weights zenyewe. Model zenye sliding-window au chunked attention ni tofauti: Nyaraka za Transformers za Hugging Face zinataja Mistral, Gemma 2 na Llama 4 kama mifano ambapo cache kwenye layers hizo huacha kukua mara tu inapofikia ukubwa wa window au chunk, kwa hivyo jumla yake hukua polepole zaidi. Ikiwa unapanga kutumia context ndefu, kadiria cache kwanza na uangalie injini yako inatoa nini kwa ajili ya cache quantization. Katika Ollama, OLLAMA_KV_CACHE_TYPE=q8_0 hutumia takriban nusu ya kumbukumbu ya f16 chaguo-msingi, na cache quantization hutumika tu wakati Flash Attention imewashwa. Weka urefu wa context wazi pia. Ollama huchagua chaguo-msingi kutoka VRAM: 4k chini ya 24 GiB, 32k kuanzia 24 hadi 48 GiB, na 256k kuanzia 48 GiB na kuendelea. Kwenye kadi ya 48 GB inayoendesha model ya 70B, chaguo-msingi hilo huomba cache nyingi zaidi kuliko kadi inavyoweza kuhimili.

Kagua kile mashine ilicho nacho kwa hakika

Kwenye instance ya GPU, thibitisha kuwa driver inaona kadi hiyo kabla ya kufanya jambo lingine lolote.

nvidia-smi

Unataka jedwali linaloorodhesha jina la GPU, toleo la driver, na kumbukumbu iliyotumika kati ya jumla inayopatikana. NVIDIA-SMI has failed because it couldn't communicate with the NVIDIA driver inamaanisha kuwa NVIDIA-SMI haiwezi kufikia driver; hakikisha kuwa driver imesakinishwa na kernel module yake imepakiwa. Kwenye image ya kawaida ya Ubuntu, suluhisho mara nyingi ni sudo apt install -y ubuntu-drivers-common && sudo ubuntu-drivers install, kisha ufanye reboot ili module mpya ipakiwe. Kwa mashine za compute, nyaraka za server za Ubuntu zinapendekeza sudo ubuntu-drivers install --gpgpu, ambayo huchagua tawi la driver ya server.

Kwa containers, driver pekee haitoshi. Docker inahitaji NVIDIA Container Toolkit ili kupitisha kifaa hicho ndani.

sudo apt-get update && sudo apt-get install -y --no-install-recommends ca-certificates curl gnupg2
curl -fsSL https://nvidia.github.io/libnvidia-container/gpgkey | sudo gpg --dearmor -o /usr/share/keyrings/nvidia-container-toolkit-keyring.gpg
curl -s -L https://nvidia.github.io/libnvidia-container/stable/deb/nvidia-container-toolkit.list | sed 's#deb https://#deb [signed-by=/usr/share/keyrings/nvidia-container-toolkit-keyring.gpg] https://#g' | sudo tee /etc/apt/sources.list.d/nvidia-container-toolkit.list
sudo apt-get update && sudo apt-get install -y nvidia-container-toolkit
sudo nvidia-ctk runtime configure --runtime=docker
sudo systemctl restart docker

Kisha thibitisha kuwa passthrough inafanya kazi ukiwa ndani ya container:

sudo docker run --rm --gpus all ubuntu:24.04 nvidia-smi

Jedwali lilelile linapaswa kuonekana. Mstari wa docker: Error response from daemon: could not select device driver, unaotaja uwezo wa gpu ambao hauwezi kutimizwa, inamaanisha kuwa Docker haikuweza kupata kifaa cha driver kinacholingana na ombi hilo; hakikisha kuwa toolkit imesakinishwa, kisha endesha tena mstari wa nvidia-ctk na uanzishe upya. Katika Compose, kitu kinacholingana na hicho ni ingizo la deploy.resources.reservations.devices ambapo driver yake ni nvidia na orodha yake ya capabilities ina gpu, ambayo huwekwa kwenye ufafanuzi wa kawaida wa huduma ulioshughulikiwa katika Docker Compose kwenye VPS.

Pima kabla ya kufanya upgrade

Endesha model unayokusudia kuitumia kwenye mashine ya CPU uliyonayo sasa, kisha rekodi takwimu. Ukiwa na Ollama self-hosting an LLM on a VPS, hii inahitaji flag moja tu:

ollama run llama3.1:8b --verbose "Summarise the causes of the 1929 crash in 200 words."

Matokeo huishia na muda uliotumika. eval rate ni kasi yako ya kuzalisha (generation speed) kwa tokens kwa sekunde. prompt eval rate ni kasi ambayo mashine ilisoma input yako. Namba hizo mbili zinakuambia ni upgrade ipi itasaidia: eval rate ya chini ni tatizo la memory-bandwidth, na prompt eval rate ya chini kwenye input ndefu ni tatizo la compute.

Kwenye mashine yenye GPU, hakikisha model imepakiwa kikamilifu kwenye GPU:

ollama ps

Safu ya PROCESSOR huonyesha 100% GPU wakati kila kitu kimeenea, au kitu kama 43%/57% CPU/GPU wakati hakikutosha. Mgawanyo wa sehemu (partial split) mara nyingi ni mbaya zaidi kuliko unavyotarajia, kwa sababu kila token bado inasubiri nusu ile ya polepole.

Swali la gharama

Instance za GPU hutoza ada kulingana na muda wa kompyuta uliotengwa badala ya idadi ya token, huku viwango na ada za instance zilizosimamishwa zikipangwa na mtoa huduma. GPU inayofanya kazi muda wote ikihudumia maombi machache kwa siku hutumia muda wake mwingi wa malipo ikiwa imetulia bila kazi. Ufanisi wa gharama hutegemea matumizi: GPU yenye shughuli nyingi ni nafuu kwa kila token, na ile iliyotulia ni hasara tupu.

Kuna mbinu tatu za kweli zinazofanya kazi. Weka kazi ndogo za mara kwa mara kwenye CPU VPS. Tuma maombi magumu ya mara kwa mara kwenye API inayohudumiwa na ulipe kwa kila token. Kodi GPU kwa saa kwa ajili ya kazi za kundi (batch jobs), fine-tuning, au uendeshaji wa bulk embedding, kisha uifute. Kuchanganya mbinu hizi ni jambo la kawaida, na nidhamu ya bajeti iliyoelezwa katika udhibiti wa gharama za AI agent kwenye VPS inayofanya kazi muda wote inatumika hapa pia, huku tofauti ikiwa ni kwamba muda wa kutofanya kazi ndio chanzo cha upotevu badala ya idadi ya token.

Mambo yanayoendelea vizuri bila GPU

Embeddings kwa ujazo mdogo. Model ndogo ya embedding huchakata mamia ya hati fupi kwa dakika kwa kutumia cores chache za CPU, na index unayojenga mara moja haihitaji kuwa ya haraka.

Whisper small na base kwa ajili ya transcription. Faster-whisper kwenye CPU hufanya transcription karibu na muda halisi kwa model ndogo, jambo ambalo linatosha kwa pipeline inayofanya kazi usiku kucha.

Quantized chat models hadi kufikia 27B, kwa mtumiaji mmoja au wawili. Polepole, lakini inasomeka na inatumika.

Kitu chochote unachoweza kukiita batch job. Ikiwa hakuna anayetazama skrini, kasi ya wall-clock ni maelezo ya upangaji wa kazi badala ya kuwa hitaji la lazima.

Mambo yanayohitaji GPU kikweli: training au fine-tuning zaidi ya adapter ndogo, kuhudumia watumiaji wengi kwa wakati mmoja, kutengeneza picha na video, na hotuba ya muda halisi ambapo latency ndiyo bidhaa yenyewe.

FAQ

Je, ninahitaji VRAM kiasi gani kwa model ya 7B au 8B?

Takriban 7 GB kwa model ya 8B iliyofanyiwa 4-bit quantization katika 8k context, na takriban 8 GB kwa 16k, huku ukizingatia cache ya FP16 ya kawaida ya Ollama. Uzito wa model ni takriban 4.9 GB, KV cache huongeza takriban 1.07 GB kwa 8k au 2.15 GB kwa 16k, na kiasi kilichobaki ni takriban 1 GB kwa ajili ya overhead. Kadi ya 8 GB inaweza kuhimili 8k lakini inakuwa na nafasi finyu kwa 16k, wakati kadi ya 12 GB huacha nafasi ya kutosha kwa context ndefu zaidi. Kubadilisha cache kuwa q8_0 hupunguza sehemu ya cache kwa takriban nusu. Ikiwa unapanga kutumia 128k context, panga ukubwa wa cache kando, kwa sababu inaweza kuwa kubwa kuliko uzito wa model yenyewe.

Je, ninaweza kuendesha Ollama bila GPU?

Ndiyo. Ollama hutumia CPU kiotomatiki na inahitaji tu RAM ya kutosha kuhifadhi model. Tarajia takriban token 5 hadi 12 kwa sekunde kwa model ya 4-bit 8B kulingana na kasi ya kumbukumbu, kasi ambayo inakaribia ile ya kusoma kwa mtumiaji mmoja. Prompt ndefu ndizo changamoto kuu kwenye CPU, kwa sababu kusoma context ya token 30,000 hutegemea nguvu ya kompyuta na huchukua muda mrefu zaidi kuliko kutengeneza jibu.

Kwa nini GPU yangu ina kasi ndogo inayokaribia ile ya CPU?

Sababu ya kawaida ni kwamba model haikutosha kikamilifu kwenye VRAM, hivyo baadhi ya layers huendeshwa kwenye CPU na kila token husubiri nusu ya polepole. Endesha ollama ps na uangalie kama safu ya PROCESSOR inaonyesha 100% GPU. Ikiwa inaonyesha mgawanyo, tumia quantization ndogo au model ndogo zaidi. Sababu nyingine ya kawaida ni benchmark fupi ambapo muda wa kupakia model hutawala kipimo.

Je, GPU VPS inafaa kwa mtumiaji mmoja?

Mara nyingi haifai. Kusoma kimya kimya kwa Kiingereza kwa mtu mzima ni wastani wa maneno 4.0 hadi 4.3 kwa sekunde, na token kwa sekunde lazima zibadilishwe kuwa maneno kwa sekunde kabla ya kulinganisha seva ya CPU na kasi hiyo. Hali zinazohalalisha gharama kwa mtumiaji mmoja ni prompt ndefu, utengenezaji wa picha, na fine-tuning. Kuhudumia watumiaji wengi kwa wakati mmoja ndiyo hoja yenye nguvu zaidi, kwa sababu batching inaruhusu GPU moja kushiriki usomaji wa uzito wa model kati ya maombi mbalimbali.

Je, nikodishe GPU kwa saa au niendeshe moja inayowaka muda wote?

Kodi kwa saa wakati kazi ni ya vipindi: fine-tuning, kazi kubwa ya embedding, au kazi ya batch transcription. Endesha inayowaka muda wote pale tu kadi inapokuwa na shughuli nyingi, kwa sababu kompyuta ya GPU inayotengewa rasilimali hutoza kwa muda badala ya token zinazozalishwa. Msaidizi mwenye trafiki ndogo ni nafuu zaidi kwenye CPU VPS, au kwenye API inayolipishwa kwa kila token, kuliko kwenye GPU isiyo na kazi.