Mifano ya AI unayoweza kujiendeshea kwenye seva yako

Ni nini huamua ni mifano ipi ya AI unayoweza kujiendeshea (self-host)

Ni nini unachoweza kujiendeshea kama mfano wa AI huamuliwa na namba moja: RAM iliyopo kwenye seva yako. Familia ya mfano na mfumo wa uendeshaji (framework) havina umuhimu mkubwa kuliko uwezo wa uzito (weights) wa mfano huo kutoshea kwenye kumbukumbu huku kukiwa na nafasi iliyobaki. 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. Uzito wa mfano ni gharama isiyobadilika, inayowekwa na idadi ya vigezo (parameter count) na quantisation. Dirisha la muktadha (context window) ni gharama inayobadilika, na ndiyo watu husahau hadi pale mfano uliopakia jana unapokataa kupakia leo.

Hesabu ya ukubwa: biti kwa kila kigezo (parameter)

Faili la modeli linaundwa karibu lote na uzito (weights). 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 wa faili hutokana moja kwa moja na hesabu hiyo:

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

Modeli hutolewa zikiwa na biti 16, ambazo ni 2 GB kwa kila bilioni moja ya vigezo. Hii ndiyo sababu karibu hakuna mtu anayeendesha modeli kwa usahihi wa awali kwenye VPS. Hizi ndizo quantisation utakazokutana nazo mara nyingi, zikiwa na wastani wa biti halisi kwa kila uzito:

• Q8_0 huhifadhi takriban biti 8.5 kwa kila uzito, hivyo ni takriban 1.1 GB kwa kila bilioni ya vigezo.
• 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 vigezo kama namba yako ya msingi ya kufanyia kazi. 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 kwa kasi, hivyo modeli ya 70B iliyoshinikizwa hadi biti 2 kwa kawaida hutoa majibu mabaya zaidi kuliko modeli ya 32B yenye biti 4 kutoka kizazi kimoja. Kumbukumbu inapokuwa finyu, punguza ukubwa wa modeli badala 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 hesabu hiyo kwa asilimia chache, kwa sababu tabaka za embedding na output huhifadhiwa kwa usahihi wa juu zaidi kuliko sehemu nyingine. Modeli ya 3B yenye biti 4 ni takriban 1.8 GB. Modeli ya 8B ni 4.8 GB. Modeli ya 32B ni 19.2 GB, na modeli ya 70B ni 42 GB.

Kwa nini urefu wa muktadha unagharimu RAM nyingi kuliko uzito wa modeli

KV cache (key value cache, hali ya umakini ambayo modeli huihifadhi kwa kila token iliyopo kwenye mazungumzo) ndiyo gharama ya pili. Hutengewa nafasi wakati modeli 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, modeli hiyo ya 8B hutumia nusu gigabyte kwa cache. Katika token 8192 hutumia 1 GB. Katika muktadha wa 128k ambao kadi ya modeli inatangaza, hutumia 16 GB, ambayo ni zaidi ya mara tatu ya uzito wa modeli yenyewe. Modeli ya 70B ni kinyume chake: cache yake katika 128k ni 40 GB, ambayo ni ndogo kuliko uzito wake, kwa sababu grouped query attention huzuia gharama kwa kila token isikue kwa kasi inayokaribia idadi ya vigezo (parameters).

Urefu wa kawaida wa muktadha wa Ollama ni token 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 kuanzia 48 GiB na kuendelea. Iongeze kwa kutumia variable ya OLLAMA_CONTEXT_LENGTH kwenye seva, kisha angalia kile ambacho modeli inayofanya kazi imepata katika safu ya CONTEXT ya ollama ps. Hesabu za kumbukumbu nyuma ya mpangilio huo 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 kadi ya modeli, 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 kinachotumiwa na safu ya UNTIL ikionyesha muda wa kuisha kwa muda huo. Ili kubandika (pin) model moja kwa moja, 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 context ya 8k inashikilia takriban 6 GB kwa muda wote ambao huduma hiyo inaendelea kufanya kazi, kwa hivyo pima ukubwa wa seva kulingana na model pamoja na programu yako, si kulingana na model pekee. Kubandika model kwenye kumbukumbu kunashughulikia uwiano dhidi ya muda wa kusubiri 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 model, jambo linaloacha takriban 3 GB. Hii inatosha kwa model ya 1B hadi 4B katika 4 bits, kwa context ya kawaida ya 4096 token. 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 hizi kama mifano ya ukubwa, si mapendekezo. Majina hubadilika kila baada ya miezi michache lakini hesabu za msingi hazibadiliki.

Tarajia takriban 6 hadi 14 token kwa sekunde. Model ndogo kama hizi hufanya kazi mahususi vizuri: uainishaji, uchimbaji wa tag, muhtasari mfupi, na kuandika upya aya kulingana na mtindo wa kampuni. Ni dhaifu katika hoja za hatua nyingi na katika kuandika code inayohusisha faili kadhaa, na hakuna kiasi chochote cha prompting kitakachorekebisha hilo.

Hali ya kufeli katika kiwango hiki ni swap. Ikiwa model haitoshi kwenye RAM, Linux haikatai kuipakia. Badala yake, inahamisha kumbukumbu kwenye diski, na kwa sababu utengenezaji wa token moja husoma kila uzito (weight) mara moja, kasi ya utengenezaji hushuka hadi sekunde kadhaa kwa kila token. Fuatilia free -h na safu za si na so za vmstat 1 wakati model inajibu. Swap in na swap out isiyo sifuri wakati wa utengenezaji inamaanisha kuwa model ni kubwa mno kwa mpango huu.

Nini kinachoweza kuendeshwa kwenye VPS ya 8 hadi 16 GB

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

Kasi ndiyo changamoto. Modeli ya 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 5 hadi 10 tokens kwa sekunde, kwa hiyo 8B kwenye VPS ya CPU huonekana kama kumtazama mtu anayechapa kwa polepole. Hii inafaa kwa kazi za nyuma (background jobs) lakini inachosha kwa mazungumzo ya moja kwa moja (interactive chat). Majaribio ya Qwen 3 ya 8B na makubwa zaidi kwenye VPS yanaonyesha hali halisi ya utendaji wake.

Nini kinaweza kuendeshwa kwenye VPS ya 32 hadi 64 GB

Model ya 32B yenye 4 bits inatumia 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 yenye 4 bits inatumia takriban 42 GB, kwa hivyo inahitaji 64 GB kabla hujaongeza cache yoyote.

Kisha pima kasi kwa uhalisia. Modeli ya 32B kwenye CPU huendesha takribani 0.6 hadi 1.5 tokens kwa sekunde, na modeli ya 70B huendesha 0.2 hadi 0.5. Jibu la tokens 500 kutoka kwa modeli hiyo ya 70B huchukua takribani dakika ishirini. Kwa kasi hiyo, ombi kwa kawaida hukatizwa kabla modeli haijamaliza, kwa sababu timeout ya client au proxy iliyo mbele ya Ollama huanza kufanya kazi kwanza. Hapo ndipo hitilafu ya context deadline exceeded hutokea. Hizi ni zana za batch. Zipe foleni ya nyaraka za kuchakata usiku kucha, na kasi haitakuwa muhimu. Ziweke nyuma ya dirisha la mazungumzo, na kasi itakuwa muhimu sana.

Uelekezaji wa Mixture of experts (MoE) hubadilisha hesabu hii, na ni maelezo moja ya usanifu yanayofaa kujifunza. Model ya MoE hutuma kila token kupitia sehemu ndogo tu ya uzito (weights) wake. Model yenye jumla ya parameters 30B na 3B zinazofanya kazi kwa kila token inahitaji kumbukumbu ya 30B na inazalisha kwa kasi inayokaribia ile ya 3B ya kawaida, kwa sababu kila token inasoma tu wataalamu (experts) wanaofanya kazi. Kwenye mashine ya 32 GB, MoE ya aina hiyo inatumika zaidi kuliko 30B ya kawaida. 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) amilifu kutoka kwenye kumbukumbu mara moja. Hakuna kinachoweza kuepuka 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 na ukubwa wa uzito katika bytes. VPS ndogo ya pamoja kwa uhalisia hutoa 10 hadi 25 GB kwa sekunde kupitia vCPUs zake, kwa hivyo model ya 4.8 GB hufikia ukomo 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 benchmark ya mashine moja. Takwimu yako inategemea kizazi cha kumbukumbu, idadi ya njia (channels) kwenye host, na ni majirani wangapi wanaoshindania rasilimali hiyo. Pima yako mwenyewe, kwa kutumia tag yoyote ya model uliyo nayo tayari:

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 tokens kwa sekunde kwa usahihi inaelezea jinsi ya kupata namba inayostahili 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 kwa 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 unategemea uwezo wa kompyuta (compute bound), kwa hivyo huongezeka kulingana na cores, na hapo ndipo GPU inapopiga hatua kubwa zaidi. Hati ndefu huchukua CPU dakika kusoma na GPU sekunde. Hilo ndilo kizuizi cha kwanza unachokutana nacho unapokuwa unaelekeza coding agent kwenye model unayohost, kwa sababu kila hatua hutuma tena muktadha wa faili na ufafanuzi wa zana kabla ya token moja ya jibu kurudi.

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 modeli ya 7B au 8B kwa bits 4 ikiwa na context fupi.
• 16 GB inatosheleza modeli ya 14B kwa bits 4 ikiwa na context halisi, au 8B kwa bits 8.
• 24 GB inatosheleza modeli ya 32B kwa bits 4 ikiwa na context fupi.
• 48 GB na zaidi inatosheleza modeli ya 70B kwa bits 4 ikiwa na nafasi ya cache na concurrency.

Modeli isipotoshea, Ollama huigawa: tabaka zingine kwenye GPU, na zingine 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 kawaida. Nusu inayokaa kwenye CPU ndiyo huamua kasi, kwa sababu kila token bado inasubiri tabaka hizo, hivyo modeli yenye robo ya tabaka zake kwenye CPU huenda kwa kasi inayokaribia kasi ya CPU kuliko GPU. Ukiona mgawanyo usiotarajiwa, punguza kwanza urefu wa context. Mara nyingi cache ndiyo inayovuka kikomo.

Concurrency ndiyo sababu nyingine ya kuongeza ukubwa wa rasilimali. Uzito (weights) hushirikiwa kati ya maombi ya wakati mmoja, lakini kila ombi linalofanya kazi linahitaji KV cache yake yenyewe, kwa hivyo watumiaji kumi wanaotumia modeli ya 8B kwa 8k context wanahitaji mara kumi ya 1 GB ya cache juu ya uzito wa modeli. Kuhudumia watumiaji wengi kwa wakati mmoja kutoka kwa modeli moja iliyohifadhiwa mwenyewe inaelezea jinsi kikomo hicho kinavyofikiwa.

Ikiwa kukodisha GPU kuna faida ni swali la kihisabati pia, na inategemea ni token ngapi kwa mwezi unazozalisha kweli. Kiwango cha faida kati ya GPU VPS na API tokens kina namba hizo.

Mambo ambayo huwezi kujiendeshea mwenyewe (self-host)

Kuna vizuizi viwili tofauti hapa, na inasaidia kufahamu ni kipi unachokabiliana nacho.

Kizuizi cha kwanza ni uzani (weights) uliofungwa. Miundo ya kibiashara ya kiwango cha juu haisambazwi, kwa hivyo hakuna faili ya kupakua na hakuna kiasi cha RAM kitakachobadilisha 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.

Kizuizi cha pili ni uzani ulio wazi ambao ni mkubwa mno. Matoleo makubwa zaidi yaliyo wazi ni miundo ya aina ya mixture of experts yenye mabilioni ya vigezo (parameters) kwa jumla. Kanuni hiyo hiyo inatumika kwao: muundo wenye jumla ya vigezo 400B katika bits 4 unahitaji takriban 240 GB kwa ajili ya uzani pekee, kabla ya kuhesabu cache yoyote. Hiyo inahitaji maunzi maalum, na kuikodisha kwa mwezi kunagharimu zaidi ya kile ambacho watu wengi hutumia kwa token za API katika mwaka mmoja. Kinachohitajika ili kujiendeshea muundo wa daraja la Kimi kinaelezea mahitaji halisi. Mgawanyo huo huo unaonekana ndani ya maktaba ya Ollama, ambapo GLM 5.2 imeorodheshwa kama muundo wa wingu pekee na ndugu yake mdogo zaidi ndiye anayepakuka kwenye VPS.

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

Angalia 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) kwa 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, pamoja na KV cache kwa ajili ya urefu wa context yako, na takriban 1 GB kwa ajili ya mfumo wa uendeshaji na seva ya modeli. Katika context ya token 8192, cache huongeza takriban 1 GB, kwa hivyo mpango wa 8 GB unafanya kazi na mpango wa 4 GB hautoshi. Ikiwa unataka context kamili ya 128k inayotangazwa kwenye model card, cache pekee inahitaji 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 inatolewa kutoka kwenye diski, jambo ambalo lina gharama kubwa zaidi kuliko inavyoonekana.

Je, dirisha refu la context 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 inapopaki badala ya wakati mazungumzo yanapokua, kwa hivyo kuomba context ya 128k hutenga kumbukumbu hiyo mara moja, hata kama kila prompt unayotuma ina urefu wa token 200 pekee.

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

Chagua modeli ndogo kwa 4-bit. Ubora hushuka polepole kutoka 8-bit hadi 4-bit na hushuka haraka chini ya 4-bit, kwa hivyo modeli ya 70B iliyoshinikizwa 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 kupuuza maagizo 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 kwa 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 vinaweza kuendesha vizuri modeli nzuri ya 8B hadi 32B kwa kazi moja maalum, 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.