AI models zipi unaweza kujiendeshea mwenyewe (self-host)?

Ni nini huamua ni AI models zipi unaweza kujiendeshea mwenyewe (self-host)

Ni nini unaweza kujiendeshea mwenyewe huamuliwa na namba moja: RAM iliyopo kwenye seva yako. Familia ya model na framework inayotumika si muhimu sana ikilinganishwa na kama weights za model hiyo zinaingia kwenye kumbukumbu na kubakiza nafasi ya ziada. Chapisho hili linaelezea hesabu za kufanya hivyo. Kusakinisha runtime ni kazi tofauti, ambayo imeelezewa katika mwongozo wa kuendesha Ollama kwenye VPS.

Gharama mbili huamua jibu. Weights ni gharama isiyobadilika, inayowekwa na idadi ya parameters na quantisation. Context window ni gharama ya uendeshaji, na ndiyo ambayo watu husahau hadi pale model iliyofanya kazi jana inapokataa kupakia leo.

Hesabu ya ukubwa: biti kwa kila parameter

Faili la model lina uzito (weights) pekee. Kila uzito huhifadhiwa kwa idadi fulani ya biti. Quantisation inamaanisha kuhifadhi uzito huo kwa biti chache kuliko usahihi uliotumika wakati wa mafunzo, jambo linalopunguza usahihi kidogo lakini huokoa kumbukumbu nyingi. Ukubwa hutokana moja kwa moja na hili:

weights in GB = (parameters in billions x bits per weight) / 8

Models hutolewa kwa biti 16, ambazo ni 2 GB kwa kila bilioni moja ya parameters. Hii ndiyo sababu karibu hakuna mtu anayeendesha model kwa usahihi wa awali kwenye VPS. Hizi ndizo quantisations utakazokutana nazo, pamoja na wastani wa biti kwa kila uzito:

• Q8_0 huhifadhi takriban biti 8.5 kwa kila uzito, hivyo ni takriban 1.1 GB kwa kila bilioni ya parameters.
• Q6_K huhifadhi takriban biti 6.6, hivyo ni takriban 0.83 GB kwa kila bilioni.
• Q5_K_M huhifadhi takriban biti 5.7, hivyo ni takriban 0.71 GB kwa kila bilioni.
• Q4_K_M huhifadhi takriban biti 4.8, hivyo ni takriban 0.6 GB kwa kila bilioni.

Tumia 0.6 GB kwa kila bilioni ya parameters kama namba yako ya msingi. Q4_K_M ndiyo chaguo bora la kawaida kwenye seva yenye kumbukumbu ndogo: upotevu wa ubora ukilinganisha na biti 8 ni mdogo katika kazi nyingi, na faili huwa na ukubwa wa karibu nusu. Chini ya biti 4, upotevu wa ubora huongezeka haraka, kwa hivyo model ya 70B iliyoshinikizwa hadi biti 2 kwa kawaida hutoa majibu mabaya zaidi kuliko model ya 32B ya biti 4 kutoka kizazi kimoja. Kumbukumbu ikiwa ndogo, punguza ukubwa wa model kabla ya kushuka chini ya biti 4.

[
  {
    "label": "3B",
    "weights_gb": 1.8,
    "kv_8k_gb": 0.9,
    "kv_128k_gb": 14
  },
  {
    "label": "8B",
    "weights_gb": 4.8,
    "kv_8k_gb": 1,
    "kv_128k_gb": 16
  },
  {
    "label": "14B",
    "weights_gb": 8.4,
    "kv_8k_gb": 1.5,
    "kv_128k_gb": 24
  },
  {
    "label": "32B",
    "weights_gb": 19.2,
    "kv_8k_gb": 2,
    "kv_128k_gb": 32
  },
  {
    "label": "70B",
    "weights_gb": 42,
    "kv_8k_gb": 2.5,
    "kv_128k_gb": 40
  }
]

Safu ya uzito hapo juu inatumia kanuni ya 0.6 GB kwa kila bilioni. Faili halisi za GGUF huwa na ukubwa unaokaribia hapo kwa asilimia chache, kwa sababu tabaka za embedding na output huhifadhiwa kwa usahihi wa juu zaidi kuliko sehemu nyingine. Model ya 3B yenye biti 4 ni takriban 1.8 GB. Model ya 8B ni 4.8 GB. Model ya 32B ni 19.2 GB, na model ya 70B ni 42 GB.

Kwa nini urefu wa muktadha unatumia RAM nyingi kuliko uzito wa model

KV cache (key value cache, hali ya attention ambayo model huihifadhi kwa kila token iliyopo kwenye mazungumzo) ndiyo gharama ya pili. Hutengwa wakati model inapopakiwa, ikikadiriwa kulingana na urefu wa muktadha uliouomba, na hukua kwa mstari mnyoofu kulingana na urefu huo.

bytes per token = 2 x layers x kv_heads x head_dim x bytes per element

Katika muktadha wa kawaida wa Ollama, model hiyo ya 8B hutumia nusu gigabyte kwa ajili ya cache. Katika tokens 8192 hutumia 1 GB. Katika muktadha wa 128k ambao maelezo ya model yanatangaza, hutumia 16 GB, ambayo ni zaidi ya mara tatu ya uzito wa model. Model ya 70B ni kinyume chake: cache yake katika 128k ni 40 GB, chini ya uzito wake yenyewe, kwa sababu grouped query attention huzuia gharama kwa kila token isikue kwa kasi inayokaribia idadi ya parameters.

Urefu wa muktadha wa kawaida wa Ollama ni tokens 4096 kwenye seva inayotumia CPU pekee. GPU inapokuwepo, huchagua thamani ya kawaida kutoka VRAM badala yake: 32k kati ya 24 na 48 GiB, na 256k katika 48 GiB na kuendelea. Iongeze kwa kutumia variable ya OLLAMA_CONTEXT_LENGTH kwenye seva, kisha angalia kile ambacho model inayofanya kazi imepata katika safu ya CONTEXT ya ollama ps. Hesabu za kumbukumbu nyuma ya mpangilio huo mmoja zimefafanuliwa katika makala kuhusu num_ctx na urefu wa muktadha.

Kuna njia mbili za kupunguza matumizi ya cache. Omba muktadha unaohitaji badala ya muktadha unaotangazwa kwenye maelezo ya model, kwa kuwa kazi nyingi za gumzo na uandishi wa programu hutoshea ndani ya 8k hadi 32k. Au fanya quantise ya cache yenyewe hadi 8 bits, jambo linaloipunguza kwa nusu, kwa gharama ndogo ya uwezo wa kukumbuka muktadha mrefu.

Mfumo wa resident model unashikilia RAM hiyo hadi kitu kingine kiondoe

Ollama huweka model kwenye kumbukumbu kwa dakika 5 baada ya ombi la mwisho, kisha huiondoa. Mpangilio huo wa awali unafaa kwa kompyuta ya mkononi lakini si sahihi kwa seva, ambapo kila ombi la kwanza baada ya muda wa kutofanya kazi hulazimika kusubiri muda wa kupakia tena.

ollama ps
ollama stop qwen3:4b

ollama ps huorodhesha kilichopo kwenye kumbukumbu, huku safu ya SIZE ikionyesha kiasi cha kumbukumbu kinachoshikiliwa na safu ya UNTIL ikionyesha wakati kitakapoisha muda wake. Ili kubandika (pin) model kabisa, weka OLLAMA_KEEP_ALIVE=-1 kwenye huduma hiyo. Thamani ya 0 huiondoa mara tu kila jibu linapokamilika.

sudo systemctl edit ollama.service

[Service]
Environment="OLLAMA_KEEP_ALIVE=-1"
Environment="OLLAMA_CONTEXT_LENGTH=8192"

sudo systemctl daemon-reload
sudo systemctl restart ollama

Tuma ombi moja, kisha endesha ollama ps tena baada ya dakika kumi. Model hiyo bado imeorodheshwa, na ndilo lengo hasa: inashikilia RAM hiyo bila kujali kama kuna mtu anaitumia au la. Model iliyobandikwa si uwezo wa ziada. Kwenye VPS ya 16 GB, model ya 8B yenye 8k context inashikilia takriban 6 GB kwa muda wote ambao huduma inafanya kazi, kwa hivyo kadiria ukubwa wa seva kulingana na model pamoja na programu yako, si kulingana na model pekee. Kubandika model kwenye kumbukumbu kunashughulikia uwiano kati ya hilo na muda wa kusubiri wakati wa kuanza kwa baridi (cold start latency).

Nini kinaweza kuendeshwa kwenye VPS ya 4 GB

Tenga takriban 1 GB kwa ajili ya mfumo wa uendeshaji na seva ya modeli, jambo linaloacha takriban 3 GB. Hiyo inatosha kwa modeli ya 1B hadi 4B katika 4 bits, kwa context ya kawaida ya 4096 tokens. Kufikia Agosti 2026, darasa hilo linajumuisha Llama 3.2 ya 3B, Qwen 3 ya 1.7B na 4B, pamoja na matoleo madogo ya Gemma na Phi. Chukulia hayo kama mifano ya ukubwa, si mapendekezo. Majina hubadilika kila baada ya miezi michache lakini hesabu haibadiliki.

Tarajia takriban 6 hadi 14 tokens kwa sekunde. Modeli ndogo kama hizi hufanya kazi mahususi vizuri: uainishaji, uchimbaji wa tag, muhtasari mfupi, na kuandika upya aya kwa mtindo maalum wa kampuni. Ni dhaifu katika hoja za hatua nyingi na katika msimbo unaohusisha faili kadhaa, na hakuna kiasi chochote cha prompting kinachoweza kurekebisha hilo.

Hali ya kushindwa katika kiwango hiki ni swap. Ikiwa modeli haitoshi, Linux haikatai kuipakia. Badala yake, inahamisha kumbukumbu kwenye diski, na kwa sababu kuzalisha token moja husoma kila uzito (weight) mara moja, uzalishaji huporomoka hadi sekunde kadhaa kwa kila token. Fuatilia free -h na safu za si na so za vmstat 1 wakati modeli inajibu. Swap isiyo ya sifuri wakati wa uzalishaji inamaanisha kuwa modeli ni kubwa mno kwa mpango huo.

Nini kinaweza kuendeshwa kwenye VPS ya 8 hadi 16 GB

Hapa ndipo mtindo wa self-hosted unapokuwa na manufaa kwa ujumla. Kwenye 8 GB unaweza kuendesha 7B au 8B kwa bits 4, takriban 4.8 GB ya weights, ikiwa na context ya 8k. Kwenye 16 GB unaweza kuendesha 13B au 14B kwa bits 4, takriban 8.4 GB, au kubaki na 8B kwa bits 8 ikiwa ungependa kutumia kumbukumbu hiyo kwa usahihi zaidi badala ya idadi ya vigezo (parameter count).

Kasi ndiyo changamoto. 8B kwenye CPU huzalisha takriban 3 hadi 7 tokens kwa sekunde, na 14B takriban 1.5 hadi 3.5. Binadamu husoma kwa kasi ya takriban tokens 5 hadi 10 kwa sekunde, kwa hivyo 8B kwenye VPS ya CPU huonekana kama kumtazama mtu anayeandika kwa polepole. Hii inafaa kwa kazi za nyuma (background jobs) lakini inachosha kwa mazungumzo ya moja kwa moja. Majaribio yaliyopimwa ya Qwen 3 katika 8B na ukubwa zaidi kwenye VPS yanaonyesha jinsi inavyokuwa katika utendaji.

Nini kinaweza kuendeshwa kwenye VPS ya 32 hadi 64 GB

Model ya 32B katika bits 4 inachukua takriban 19.2 GB, kwa hivyo inatoshea kwenye mpango wa 32 GB ikiwa na context fupi, na inakaa vizuri kwenye 48 GB au 64 GB. Model ya 70B katika bits 4 inachukua takriban 42 GB, kwa hivyo inahitaji 64 GB kabla ya kuongeza cache yoyote.

Kisha, zingatia kasi yake kwa uhalisia. Model ya 32B kwenye CPU inaendesha kwa takriban 0.6 hadi 1.5 tokens kwa sekunde, na model ya 70B kwa 0.2 hadi 0.5. Jibu la tokens 500 kutoka kwa model hiyo ya 70B huchukua takriban dakika ishirini. Hizi ni zana za batch. Ikiwa utazipa foleni ya nyaraka usiku kucha, kasi haijalishi. Ikiwa utaziweka nyuma ya dirisha la chat, kasi inakuwa na umuhimu mkubwa.

Uelekezaji wa Mixture of experts (MoE) hubadilisha hesabu hii, na ndiyo maelezo ya usanifu ambayo ni muhimu kujifunza. Model ya MoE hutuma kila token kupitia sehemu ndogo tu ya uzito wake (weights). Model yenye jumla ya parameters 30B na 3B zinazofanya kazi kwa kila token inahitaji kumbukumbu ya 30B na inazalisha kasi inayokaribia ile ya model ya 3B, kwa sababu kila token inasoma tu experts walio hai. Kwenye seva ya 32 GB, model ya MoE ya aina hiyo inatumika zaidi kuliko model ya 30B ya kawaida (dense). Kanuni ya kuzingatia: jumla ya parameters huamua kumbukumbu, parameters zinazofanya kazi huamua kasi.

Kasi ya CPU inference ni ipi, kwa kweli?

Kuzalisha token moja kunahitaji kusoma kila uzito (weight) unaotumika kutoka kwenye kumbukumbu mara moja. Hakuna njia ya kukwepa hili, kwa hivyo kasi ya uzalishaji kwenye CPU huamuliwa na bandwidth ya kumbukumbu na si idadi ya cores. Kikomo ni mgawanyo: bandwidth ya kumbukumbu inayoweza kutumika ikigawanywa kwa ukubwa wa uzito katika bytes. VPS ndogo ya pamoja kwa uhalisia hutoa GB 10 hadi 25 kwa sekunde kupitia vCPUs zake, kwa hivyo modeli ya GB 4.8 hufikia upeo wa karibu token 2 hadi 5 kwa sekunde.

[
  {
    "label": "3B",
    "tokens_per_second_low": 6,
    "tokens_per_second_high": 14
  },
  {
    "label": "8B",
    "tokens_per_second_low": 3,
    "tokens_per_second_high": 7
  },
  {
    "label": "14B",
    "tokens_per_second_low": 1.5,
    "tokens_per_second_high": 3.5
  },
  {
    "label": "32B",
    "tokens_per_second_low": 0.6,
    "tokens_per_second_high": 1.5
  },
  {
    "label": "70B",
    "tokens_per_second_low": 0.2,
    "tokens_per_second_high": 0.5
  }
]

Hizo ni safu zinazoripotiwa mara kwa mara kwenye vifaa vya kawaida vya VPS, si kipimo cha mashine moja. Takwimu yako inategemea kizazi cha kumbukumbu, idadi ya njia (channels) kwenye host, na ni majirani wangapi wanaoshindania rasilimali hiyo. Pima kasi yako mwenyewe, ukitumia tag yoyote ya modeli uliyo nayo:

ollama run qwen3:4b --verbose "Write three sentences about disk latency."

Muhtasari unaochapishwa baada ya jibu kuisha huishia na mstari unaosomeka eval rate: ... tokens/s. Hiyo ndiyo kasi yako ya uzalishaji. Puuza jaribio la kwanza la kikao, kwa sababu load duration kwenye muhtasari huo huo inajumuisha kusoma uzito kutoka kwenye diski. Kupima token kwa sekunde kwa usahihi inaelezea jinsi ya kupata namba inayofaa kulinganishwa.

Matokeo mawili huwashangaza watu hapa. Kuongeza vCPUs huacha kusaidia haraka, kwa sababu baada ya takriban cores 8, cores za ziada husubiri kumbukumbu badala ya kufanya hesabu. Na kwenye mpango wa pamoja, amri hiyo hiyo hurejesha namba tofauti saa hadi saa, jambo ambalo ni CPU steal time kutoka kwa jirani mwenye kelele badala ya kitu chochote ulichokisanidi vibaya.

Kusoma prompt yako ni kazi tofauti na kuzalisha jibu. Uchakataji wa prompt hutegemea nguvu ya kompyuta (compute bound), kwa hivyo huongezeka kulingana na cores, na hapo ndipo GPU inapopata faida kubwa zaidi. Hati ndefu huchukua CPU dakika kusoma na GPU sekunde chache.

Mabadiliko yanayotokea unapoongeza GPU

Hesabu haibadiliki, inabadilika tu kulingana na rasilimali inayotumika. VRAM ina kikomo kisichobadilika, kwa hivyo piga hesabu ya kile kinachotoshea kabla ya kukodisha:

• 8 GB ya VRAM inatosheleza model ya 7B au 8B kwa 4 bits ikiwa na context fupi.
• 16 GB inatosheleza model ya 14B kwa 4 bits ikiwa na context halisi, au 8B kwa 8 bits.
• 24 GB inatosheleza model ya 32B kwa 4 bits huku context ikiwa fupi.
• 48 GB na zaidi inatosheleza model ya 70B kwa 4 bits huku kukiwa na nafasi ya cache na concurrency.

Model isipotoshea, Ollama huigawa: tabaka zingine kwenye GPU, na nyingine kwenye CPU. ollama ps huripoti mgawanyo huo kwenye safu yake ya PROCESSOR, kama 78%/22% CPU/GPU. Ichukulie hiyo kama onyo badala ya kipengele cha ziada. Nusu inayoshughulikiwa na CPU ndiyo huamua kasi, kwa sababu kila token bado inasubiri tabaka hizo, hivyo model yenye robo ya tabaka zake kwenye CPU huenda kwa kasi inayokaribia kasi ya CPU kuliko GPU. Ukiona mgawanyo usiotarajiwa, punguza urefu wa context kwanza. Mara nyingi cache ndiyo inayovuka kikomo.

Concurrency ndiyo sababu nyingine ya kuongeza ukubwa wa rasilimali. Weights hushirikiwa kati ya maombi yanayokuja kwa wakati mmoja, lakini kila ombi linalofanya kazi linahitaji KV cache yake yenyewe, kwa hivyo watumiaji kumi wanaotumia model ya 8B kwa 8k context wanahitaji mara kumi ya 1 GB ya cache juu ya weights. Kuhudumia watumiaji wengi kwa wakati mmoja kutoka kwa model moja iliyopo kwenye seva yako inaelezea jinsi kikomo hicho kinavyofikiwa.

Kama GPU inafaa kukodishwa ni swali la kimahesabu pia, na inategemea ni token ngapi kwa mwezi unazozalisha kwa uhalisia. Kiwango cha faida kati ya GPU VPS na API tokens kina namba hizo.

Mambo ambayo huwezi kujiendeshea (self-host)

Kuna vizuizi viwili tofauti hapa, na ni vyema kufahamu kizuizi kipi unachokumbana nacho.

Cha kwanza ni uzani (weights) uliofungwa. Miundo ya kibiashara ya kiwango cha juu haisambazwi, kwa hivyo hakuna faili ya kupakua na hakuna mabadiliko ya RAM yanayoweza kubadilisha hilo. Unaweza kujiendeshea kila kitu kinachozunguka miundo hiyo: kiolesura, safu ya urejeshaji (retrieval layer), mzunguko wa wakala (agent loop), na logi. Muundo wenyewe unabaki kuwa API ya mbali. Kama unaweza kujiendeshea Claude inaelezea hilo kwa kina.

Cha pili ni uzani ulio wazi ambao ni mkubwa mno. Matoleo makubwa zaidi yaliyo wazi ni miundo ya aina ya mixture of experts yenye jumla ya vigezo (parameters) mamia ya mabilioni. Kanuni hiyo hiyo inatumika kwao: muundo wenye jumla ya vigezo 400B katika 4 bits unahitaji takriban 240 GB kwa ajili ya uzani pekee, kabla ya kuongeza cache yoyote. Hiyo inahitaji maunzi maalum, na kukodisha maunzi hayo kwa mwezi kunagharimu zaidi ya kile ambacho watu wengi hutumia kwa token za API kwa mwaka mzima. Kinachohitajika ili kujiendeshea muundo wa daraja la Kimi kinaelezea mahitaji halisi.

Ukweli wa msingi kati ya hayo mawili ni huu: jiendeshee mwenyewe wakati mzigo wa kazi ni thabiti na data haipaswi kutoka kwenye seva yako. Nunua token wakati mzigo wa kazi unabadilika-badilika, au wakati ubora wa majibu ya kiwango cha juu ndicho kitu unachohitaji hasa.

Kagua ulichonacho kabla ya kuchagua

free -h
nproc
lscpu | grep 'Model name'

Panga kulingana na safu ya available ya free -h, si safu ya total, kwa sababu total inajumuisha kumbukumbu ambayo mfumo unaitumia tayari. Ondoa takriban 1 GB kwa ajili ya mfumo wa uendeshaji na seva ya modeli. Gawanya kilichobaki kwa 0.6 ili kupata idadi kubwa zaidi ya vigezo (parameters) katika mabilioni unayoweza kuhifadhi kwa bits 4. Kisha ondoa KV cache kwa ajili ya muktadha (context) unaotaka kutumia. Kilichobaki ndicho jibu lako, na tofauti na orodha ya majina ya modeli, hili halipitwi na wakati.

FAQ

Je, ninahitaji RAM kiasi gani ili kuendesha modeli ya 8B?

Takriban 4.8 GB kwa ajili ya uzito (weights) katika 4-bit quantisation, ukijumlisha na KV cache kwa ajili ya urefu wa muktadha (context length), pamoja na takriban 1 GB kwa ajili ya mfumo wa uendeshaji na seva ya modeli. Katika muktadha wa token 8192, cache huongeza takriban 1 GB, kwa hivyo mpango wa 8 GB unafanya kazi na mpango wa 4 GB hautoshi. Ikiwa unataka muktadha kamili wa 128k ambao kadi ya modeli inatangaza, cache pekee ni 16 GB na utahitaji mpango wa 32 GB.

Kwa nini modeli yangu ni polepole ingawa VPS ina vCPU nyingi?

Kwa sababu uzalishaji (generation) unadhibitiwa na bandwidth ya kumbukumbu, si kwa cores. Kila token inahitaji kuvuta seti nzima ya uzito inayotumika kutoka kwenye RAM, kwa hivyo pindi cores chache zinapojaza njia za kumbukumbu, nyingine zote husubiri. Sababu nyingine ya kawaida ni swap. Ikiwa vmstat 1 inaonyesha si na so zisizo sifuri wakati modeli inajibu, uzito hautoshei kwenye RAM na sehemu ya kila token inahudumiwa kutoka kwenye diski, jambo ambalo lina gharama kubwa zaidi kuliko inavyoonekana.

Je, dirisha refu la muktadha linahitaji kumbukumbu zaidi kweli?

Ndiyo, na ukuaji wake ni wa mstari kulingana na idadi ya token. Modeli ya kawaida ya 8B hutumia takriban 128 KiB ya KV cache kwa kila token, kwa hivyo token 8192 hugharimu 1 GB na token 131072 hugharimu 16 GB. Cache hutengwa wakati modeli inapopakiwa badala ya wakati mazungumzo yanapokua, kwa hivyo kuomba muktadha wa 128k hutenga kumbukumbu hiyo mara moja, hata kama kila ombi (prompt) unalotuma lina urefu wa token 200 pekee.

Je, niendeshe modeli kubwa kwa 2-bit au ndogo kwa 4-bit?

Chukua modeli ndogo kwa 4-bit. Ubora hushuka polepole kutoka 8-bit hadi 4-bit na kwa kasi chini ya 4-bit, kwa hivyo modeli ya 70B iliyopunguzwa hadi 2-bit kwa kawaida hutoa majibu mabaya zaidi kuliko modeli ya 32B kwa 4-bit kutoka kizazi kimoja cha modeli. Quantisation nzito huonekana kama kurudia maneno na maagizo yaliyokosekana badala ya ujumbe wa hitilafu, jambo ambalo hufanya iwe rahisi kuilaumu prompt yako. Ichukulie 4-bit kama kiwango cha chini na ubadilishe idadi ya vigezo (parameter count) badala yake.

Je, ninaweza kujihostia modeli yenye uwezo sawa na zile kubwa za kibiashara?

Huwezi kwenye VPS ya kawaida. Modeli zenye nguvu zaidi za open weight zina mabilioni ya vigezo, ambavyo katika 4-bit inamaanisha zaidi ya 200 GB ya RAM kabla ya KV cache yoyote, na modeli zenye nguvu zaidi za kibiashara hazigawiwi kabisa. Vifaa vya kawaida vinafanya vizuri kuendesha modeli nzuri ya 8B hadi 32B kwa kazi moja mahususi, ambapo modeli ndogo iliyoelekezwa vizuri mara nyingi hulingana na ile ya jumla. Ikiwa unahitaji ubora wa hali ya juu, linganisha bei ya API na gharama ya vifaa kabla ya kununua yoyote kati ya hizo.