Je, unahitaji VPS yenye GPU au CPU inatosha?

Je, unahitaji VPS yenye GPU, au CPU inatosha?

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

Sababu ni bandwidth ya kumbukumbu. Wakati modeli ya lugha inazalisha token moja, inasoma kila uzito (weight) inayohitaji kutoka kwenye kumbukumbu. Modeli ya 8B iliyofanyiwa quantization hadi bits 4 ni takriban 4.7 GB kwenye diski na kiasi hicho hicho kwenye kumbukumbu, kwa hivyo kuzalisha token moja kunamaanisha kusafirisha takriban 4.7 GB. Gawanya bandwidth ya kumbukumbu ya mashine kwa namba hiyo na utapata ukomo wa token kwa sekunde. Mgawanyo huo mmoja unaelezea karibu kila benchmark utakayosoma.

Faida halisi unayopata kutoka kwa GPU

Bandwidth. Kumbukumbu ya DDR5 ya seva kwenye host ya kisasa husafirisha makumi ya gigabytes kwa sekunde. Kumbukumbu ya GPU (VRAM, video RAM) husafirisha 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 kusoma badala ya kuzungumza. GPU inasaidia hapa tu ikiwa model inatoshea kwenye VRAM, kwa sababu pindi layers zinapohamia kwenye system RAM, njia ya polepole huanza kutawala tena.

Batch throughput. Hili ni jambo ambalo watu hulidharau. GPU inayozalisha majibu kwa mtumiaji mmoja huacha sehemu kubwa ya uwezo wake wa kompyuta bila kazi, 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. CPU haifanyi hivi. Watumiaji wawili kwa wakati mmoja kwenye CPU hupunguza kasi ya kila mmoja kwa nusu. Ikiwa unajenga API inayotumiwa na wateja wengi, batching ndiyo sababu kuu ya kutumia GPU, zaidi ya kasi ya mtiririko mmoja (single-stream).

Uchakataji wa prompt. Kusoma prompt ndefu hutegemea nguvu ya kompyuta (compute-bound), si kumbukumbu, na hapa ndipo GPU zinaposhinda kwa tofauti kubwa zaidi. Context ya tokens 30,000 ambayo CPU inachukua dakika nzima kuichakata, inachukua sekunde chache tu kwenye GPU. Mifumo ya utafutaji (retrieval) inayoweka hati nyingi kwenye kila ombi huhisi tofauti hii kila wakati.

Nambari za makadirio, na jinsi ya kuzisoma

Kizuizi kilicho hapa chini kinaonyesha takwimu za kawaida zilizochapishwa za mtiririko mmoja (single-stream) kwa ajili ya modeli ya 8B katika quantization ya 4-bit, kufikia Julai 2026. Hizi ni mwongozo wa mpangilio wa ukubwa, si ahadi. Quantization yako, urefu wa muktadha (context length), na injini ya inference vitabadilisha nambari hizi.

[
  {
    "label": "8 vCPU, DDR4",
    "mem_bandwidth_gbs": 40,
    "tokens_per_sec": 6
  },
  {
    "label": "16 vCPU, DDR5",
    "mem_bandwidth_gbs": 75,
    "tokens_per_sec": 11
  },
  {
    "label": "24GB GPU",
    "mem_bandwidth_gbs": 300,
    "tokens_per_sec": 50
  },
  {
    "label": "40GB data-centre GPU",
    "mem_bandwidth_gbs": 1555,
    "tokens_per_sec": 130
  }
]

Safu ya 24 GB GPU inaonyesha 50 tokens kwa sekunde dhidi ya 11 kwa mashine ya CPU inayotumia DDR5. Hiyo ni takriban mara tano, ambayo inafuata uwiano wa bandwidth badala ya tofauti yoyote katika uwezo wa kompyuta (raw compute). Throughput halisi pia huwa chini ya bandwidth ikigawanywa kwa ukubwa wa modeli, kwa sababu attention juu ya muktadha unaokua huongeza kazi ambayo mgawanyo rahisi huipuuza.

Kwa kulinganisha, mtu husoma takriban maneno 5 hadi 10 kwa sekunde. Kitu chochote kuanzia tokens 15 kwa sekunde na kuendelea tayari huhisi kama kuandika kwa kawaida kwa msomaji mmoja. Hiyo ndiyo sababu usanidi mwingi wa 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 uzito (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.

Kanuni ya kivitendo kufikia Julai 2026: chukua ukubwa wa faili ya model katika gigabytes na ongeza asilimia 20 kwa ajili ya context ya kawaida ya 8k hadi 16k. Model ya 8B yenye ukubwa wa 4.7 GB inahitaji takriban 6 GB ya VRAM. Model ya 27B katika 4 bits ni takriban 16 GB na inahitaji takriban 20 GB. Model ya 70B katika 4 bits ni takriban 40 GB na inahitaji kadi ya 48 GB, au kadi mbili ndogo. Hesabu hiyo hiyo inaendelea kufanya kazi hata zaidi ya hapo, na hesabu ya VRAM kwa ajili ya model ya parameter trilioni 2.8 kama Kimi K3 inaonyesha mahali ambapo kuchagua kadi huacha kuwa swali kabisa.

Context ndefu huvunja kanuni hii. KV cache hukua kwa mstari kulingana na urefu wa context, na katika 128k tokens inaweza kuzidi uzito wa model yenyewe. Ikiwa unapanga kutumia context ndefu, kadiria ukubwa wa cache kwanza na uangalie injini yako inatoa nini kwa ajili ya cache quantization.

Kagua kile mashine ilicho nacho kwa sasa

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

nvidia-smi

Unahitaji 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 driver haipo, au kernel module haikujijenga upya baada ya upgrade ya kernel. Kwenye image ya kawaida ya Ubuntu, suluhisho mara nyingi ni sudo apt install -y ubuntu-drivers-common && sudo ubuntu-drivers install, kisha fanya reboot ili module mpya ipakiwe.

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

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 toolkit imewekwa lakini Docker haikusanidiwa upya au kuanzishwa upya, kwa hivyo endesha tena mstari wa nvidia-ctk na ufanye restart. Katika Compose, kitu kinacholingana na hicho ni ingizo la deploy.resources.reservations.devices ambapo driver yake ni nvidia na orodha ya capabilities ina gpu, ambayo huwekwa kwenye ufafanuzi wa kawaida wa huduma kama ilivyoelezwa 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 zina gharama kubwa mara kadhaa kuliko instance za CPU zinazolingana nazo, na hutoza ada kwa kila saa zinapokuwepo, si kwa idadi ya token zinazozalishwa. GPU inayowaka muda wote ikihudumia maombi machache kwa siku ndiyo njia ghali zaidi ya kuendesha inference. Ufanisi wa gharama hutegemea matumizi: GPU yenye shughuli nyingi ni nafuu kwa kila token, na GPU isiyo na shughuli ni hasara tupu.

Kuna mbinu tatu za kweli zinazofanya kazi. Weka kazi ndogo na 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 batch, 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 inayowaka 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, nahitaji VRAM kiasi gani kwa ajili ya model ya 7B au 8B?

Takriban 6 GB kwa ajili ya model ya 8B iliyofanyiwa 4-bit quantization katika context ya kawaida ya 8k hadi 16k. Uzito wa model ni takriban 4.7 GB, na sehemu iliyobaki ni KV cache pamoja na takriban 1 GB ya ziada kwa ajili ya uendeshaji. Kadi ya 12 GB inatoa nafasi ya kutosha kwa ajili ya context ndefu zaidi. Ikiwa unapanga kutumia context ya 128k, 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, ambayo inakaribia kasi ya kusoma kwa mtumiaji mmoja. Prompt ndefu ndizo changamoto halisi kwenye CPU, kwa sababu kusoma token 30,000 za context kunahitaji nguvu nyingi za kompyuta na huchukua muda mrefu zaidi kuliko kutengeneza jibu.

Kwa nini GPU yangu ina kasi inayokaribia ile ya CPU?

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

Je, GPU VPS inafaa kwa mtumiaji mmoja?

Mara nyingi haifai. Mtu mmoja husoma kwa kasi ya maneno 5 hadi 10 kwa sekunde, na seva ya CPU tayari inazalisha token kwa kasi hiyo kwa model za hadi 13B. 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 kujibu maombi ishirini kwa gharama inayokaribia ile ya kujibu ombi moja.

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 transcription ya kundi. Endesha inayowaka muda wote pale tu kadi inapokuwa na shughuli kila wakati, kwa sababu instance ya GPU inatoza gharama kwa kuwepo kwake badala ya token zinazozalishwa. Msaidizi mwenye trafiki ndogo ni nafuu zaidi kwenye CPU VPS, au kwenye API inayolipwa kwa kila token, kuliko kwenye GPU isiyo na kazi.