Jinsi ya kuendesha Qwen 27B kwenye VPS kwa kutumia Ollama

Je, unaweza kuendesha Qwen 3.8 27B kwenye VPS isiyo na GPU?

Ili kuendesha Qwen 3.8 27B kwenye VPS, kwanza unahitaji tag ya model inayopatikana, na kufikia tarehe 4 Agosti 2026 maktaba ya Ollama haina ingizo lolote la qwen3.8. Tag ya 27B iliyotolewa iliyo karibu zaidi ni qwen3.6:27b: vigezo bilioni 27.8, quantisation ya Q4_K_M, leseni ya Apache 2.0. Kila amri na kila namba hapa chini inatumia tag hiyo kwenye Ollama v0.32.5, iliyochapishwa tarehe 27 Julai 2026.

Jibu fupi ni ndiyo kwenye VPS yenye 32 GB ya RAM au zaidi, lakini kwa kasi ndogo. Model ya 27B yenye msongamano wa Q4 inahitaji takriban 17 GB ya RAM kwa ajili ya uzito (weights) pekee, kabla ya token yoyote ya muktadha (context) kuhifadhiwa. Hii inaondoa kabisa mipango ya 8 GB na 16 GB. Kwenye VPS ya kawaida ya DDR4 yenye chaneli mbili, ukomo ni takriban 3 token kwa sekunde, kasi ambayo ni ndogo kuliko watu wengi wanavyosoma.

Namba 3.8 inatoka wapi? Inaelekea inatokana na idadi ya vigezo. Ukurasa wa Ollama kwa ajili ya qwen3.6:27b unaonyesha vigezo 27.8B, na 27.8 ni rahisi kukumbukwa baadaye kama 3.8. Kuna pia qwen3.5:27b, ambayo ni build ileile ya Q4_K_M kutoka toleo lililopita. Angalia orodha ya sasa kabla ya kunakili amri yoyote, kwenye ukurasa wa tag ya Ollama qwen3.6. Ikiwa qwen3.8 halisi itatolewa baadaye, hesabu hizi bado zitatumika, kwa sababu zinategemea idadi ya vigezo na bits kwa kila uzito badala ya namba ya toleo.

Ni tag ipi ya Ollama ya kupakua, na jinsi ya kuikagua

Kupakua tag ambayo haipo kunatoa ujumbe wa kosa ulio wazi, kwa hivyo ni rahisi kutatua hili kwenye seva yenyewe.

ollama pull qwen3.8:27b
# Error: pull model manifest: file does not exist

ollama pull qwen3.6:27b
ollama show qwen3.6:27b

ollama show huchapisha usanifu (architecture), idadi ya vigezo (parameter count), urefu wa muktadha (context length) na quantisation kwa ajili ya tag uliyo nayo. Ikiwa mstari wa vigezo unasomeka 27.8B na mstari wa quantisation unasomeka Q4_K_M, basi unayo toleo ambalo mwongozo huu umeandaliwa kulingana nalo. Maktaba hiyo pia ina qwen3.6:27b-q8_0 na qwen3.6:27b-bf16 kwa uzito (weights) uleule katika usahihi wa juu zaidi, pamoja na seti ya tag za 35b-a3b ambazo ni mifano ya MoE (mixture of experts) na hufanya kazi kwa njia tofauti sana kwenye CPU. Maelezo zaidi kuhusu hayo yapo hapa chini.

Idadi ya vigezo mara baiti kwa kila uzito

[
  {
    "label": "Q4_K_M",
    "size_gb": 17,
    "bits_per_weight": 4.89,
    "notes": "published tag qwen3.6:27b"
  },
  {
    "label": "Q5_K_M",
    "size_gb": 19.8,
    "bits_per_weight": 5.7,
    "notes": "computed, no library tag exists"
  },
  {
    "label": "NVFP4",
    "size_gb": 20,
    "bits_per_weight": 5.76,
    "notes": "published tag 27b-nvfp4"
  },
  {
    "label": "Q8_0",
    "size_gb": 30,
    "bits_per_weight": 8.63,
    "notes": "published tag 27b-q8_0"
  },
  {
    "label": "BF16",
    "size_gb": 56,
    "bits_per_weight": 16.1,
    "notes": "published tag 27b-bf16"
  }
]

Fomula hii ni ya mstari mmoja. Baiti za uzito = vigezo * biti kwa kila uzito / 8. Kwa kiwango safi cha biti 4, vigezo bilioni 27.8 vitakuwa 13.9 GB. Lebo ya Q4_K_M iliyosafirishwa ni 17 GB, ambayo inafanya kazi kwa 4.89 biti kwa kila uzito katika matumizi.

Pengo hilo si kosa. Miundo ya K-quant haihifadhi kila tensor kwa upana wa kawaida. Tensor zinazopoteza ubora zaidi chini ya mgandamizo huwekwa kwenye biti 5 au 6, na tabaka za token embedding na output kwa kawaida huachwa kwenye Q6_K au Q8_0. Jina la muundo ni wastani, na wastani huo hufika karibu 4.9. Athari hiyo hiyo huonekana upande mwingine wa kipimo: 56 GB kwa BF16 ni 16.1 biti kwa kila uzito badala ya 16 kamili, kwa sababu faili pia hubeba metadata na jedwali la embedding la usahihi kamili.

Q5_K_M haina lebo iliyochapishwa kwa modeli hii, kwa hivyo safu ya 19.8 GB imehesabiwa kwa biti 5.7 za kawaida kwa kila uzito kwa muundo huo badala ya kupimwa. Q8_0 karibu inazidisha mara mbili Q4 hadi 30 GB. Kwenye mashine ya CPU pekee, ongezeko hilo mara mbili hugharimu mara mbili ya trafiki ya kumbukumbu kwa kila token, kwa hivyo pia inakaribia kupunguza nusu ya token zako kwa sekunde. Q4_K_M ndiyo chaguo-msingi sahihi hapa kwa sababu hiyo pekee.

Gharama ya KV cache kadiri muktadha unavyokua

Uzito (weights) ni gharama isiyobadilika. KV cache (key and value cache, hali ya attention ambayo modeli huihifadhi kwa kila token iliyokwishaiona) hukua kwa mstari mnyoofu kulingana na urefu wa muktadha, na hapa ndipo watu wengi wanapokwisha na RAM.

[
  {
    "label": "4k tokens",
    "kv_f16_gb": 1,
    "kv_q8_gb": 0.5
  },
  {
    "label": "8k tokens",
    "kv_f16_gb": 2,
    "kv_q8_gb": 1
  },
  {
    "label": "16k tokens",
    "kv_f16_gb": 4,
    "kv_q8_gb": 2
  },
  {
    "label": "32k tokens",
    "kv_f16_gb": 8,
    "kv_q8_gb": 4
  },
  {
    "label": "64k tokens",
    "kv_f16_gb": 16,
    "kv_q8_gb": 8
  },
  {
    "label": "128k tokens",
    "kv_f16_gb": 32,
    "kv_q8_gb": 16
  }
]

Takwimu hizo huchukulia umbo ambalo Qwen imetumia katika modeli zake za hivi karibuni za aina hii: tabaka 64, vichwa 8 vya key/value chini ya GQA (grouped-query attention), na ukubwa wa kichwa wa 128. Hii inafikia 256 KiB kwa kila token katika f16, hivyo 8 GB kwa token 32k na 32 GB kwa 128k. Usitegemee hesabu zangu badala ya mashine yako mwenyewe. Pakia modeli na usome safu ya SIZE ya ollama ps, ambayo huripoti uzito pamoja na cache na overhead kama takwimu moja.

Hii ndiyo sababu muktadha wa 256K kwenye kadi ya modeli ni kichwa cha habari badala ya mpango kazi. Kuijaza kwa f16 kungegharimu 64 GB ya cache juu ya uzito, kwenye mashine ambayo tayari imetumia 17 GB kwa uzito. Ollama haikupi dirisha kamili kwa chaguo-msingi. Inapakia dogo zaidi, na wewe huongeza kwa makusudi ukitumia OLLAMA_CONTEXT_LENGTH. Iongeze kwa hatua na uangalie ollama ps baada ya kila mabadiliko.

Mipangilio miwili hupunguza cache kwa nusu au zaidi. OLLAMA_KV_CACHE_TYPE=q8_0 huhifadhi cache kwa biti 8 badala ya 16, ikipunguza token 32k kutoka 8 GB hadi 4 GB. Inahitaji flash attention, kwa hivyo weka OLLAMA_FLASH_ATTENTION=1 pia, na uthibitishe kupungua huko katika ollama ps badala ya kudhani kuwa imefanya kazi. OLLAMA_NUM_PARALLEL=1 ni muhimu vilevile. Ollama inaweza kuhudumia maombi kadhaa kwa wakati mmoja, na kila nafasi hupata sehemu yake ya muktadha, kwa hivyo kuacha parallelism katika hali ya kawaida huzidisha cache uliyotenga kimyakimya. Ikiwa zaidi ya mtu mmoja atatumia mashine hii, uzidishaji huo ndipo matatizo huanzia, na idadi ya watumiaji wa wakati mmoja ambao modeli inayojiendesha inaweza kuhudumia huamuliwa na nafasi za cache na kina cha foleni muda mrefu kabla ya kuamuliwa na idadi ya core.

Kile kinachotoshea kwenye 8, 16, 32 na 64 GB ya RAM

[
  {
    "label": "8 GB",
    "q4_max_ctx_ktok": 0,
    "q8_max_ctx_ktok": 0,
    "notes": "Weights alone exceed the box. Use a 4b or 8b model."
  },
  {
    "label": "16 GB",
    "q4_max_ctx_ktok": 0,
    "q8_max_ctx_ktok": 0,
    "notes": "17 GB of weights does not fit in 16 GB of RAM."
  },
  {
    "label": "32 GB",
    "q4_max_ctx_ktok": 32,
    "q8_max_ctx_ktok": 0,
    "notes": "Q4 fits with room to spare. Q8 weights do not fit."
  },
  {
    "label": "64 GB",
    "q4_max_ctx_ktok": 128,
    "q8_max_ctx_ktok": 64,
    "notes": "Both fit. Q8 leaves much less room for context."
  }
]

Soma namba hizi mbili kama maelfu ya tokeni za muktadha zinazotoshea pamoja na uzani (weights), kwenye f16 cache, kwenye Linux VPS isiyo na kiolesura cha picha (headless) yenye takriban 1.5 GB iliyobaki kwa ajili ya mfumo wa uendeshaji na nafasi ndogo ya ziada. Sifuri inamaanisha kuwa uzani wenyewe hautoshei, kwa hivyo hakuna kinachotoshea.

8 GB na 16 GB si viwango vya karibu. 17 GB ya uzani haitoshei kwenye 16 GB ya RAM, na hakuna mabadiliko ya mpangilio wa muktadha yatakayosaidia. Kuongeza swap hakusaidii pia. Ollama hufanya memory-map ya faili ya GGUF, kwa hivyo kurasa za kumbukumbu (resident pages) zikizidi RAM, kernel huanza kuziondoa na kuzisoma upya, na kila tokeni huchota gigabytes kutoka kwenye diski. Seva hukwama kwenye iowait ya juu na kutoa chini ya tokeni moja kwa sekunde.

32 GB ndiyo kiwango cha kuanzia. Uzani huchukua 17 GB na unabakiwa na takriban 13 GB, ambayo inatosheleza takriban 32k tokeni za muktadha wa f16 pamoja na nafasi ya ziada. Uzani wa Q8_0 wenye 30 GB hautoshei kabisa kwenye kiwango hiki.

64 GB ni kiwango cha kuridhisha. Q4 huacha nafasi ya takriban 128k tokeni za muktadha, na uzani wa Q8_0 hutoshea pamoja na takriban 64k tokeni nyuma yake. Kabla ya kulipia 64 GB ili kupata Q8, elewa unachonunua: matokeo bora kidogo kwa nusu ya kasi, kwenye mashine ambayo tayari ilikuwa polepole. Q4 yenye muktadha mrefu zaidi ni chaguo bora kwa karibu kila mtu.

Kasi ya CPU inference kwenye VPS ni ipi?

Kuzalisha token moja kutoka kwa dense model kunamaanisha kusoma kila uzito (weight) kutoka kwenye kumbukumbu mara moja. Sio baadhi yake. Ni zote. Kwa hiyo, kikomo cha kasi sio idadi ya cores zako, bali ni bandwidth ya kumbukumbu ikigawanywa na ukubwa wa uzito huo. Katika Q4, hiyo ni 17 GB ya trafiki ya kumbukumbu kwa kila token.

[
  {
    "label": "DDR4-2666, 2 channel",
    "mem_bandwidth_gb_s": 42.6,
    "ceiling_tok_s": 2.5
  },
  {
    "label": "DDR4-3200, 2 channel",
    "mem_bandwidth_gb_s": 51.2,
    "ceiling_tok_s": 3
  },
  {
    "label": "DDR5-4800, 2 channel",
    "mem_bandwidth_gb_s": 76.8,
    "ceiling_tok_s": 4.5
  },
  {
    "label": "DDR4-3200, 8 channel",
    "mem_bandwidth_gb_s": 204.8,
    "ceiling_tok_s": 12
  },
  {
    "label": "DDR5-4800, 12 channel",
    "mem_bandwidth_gb_s": 460.8,
    "ceiling_tok_s": 27.1
  }
]

Hayo ni viwango vya juu kabisa, sio vipimo vya uhalisia. Pato la kweli hufika takriban asilimia 50 hadi 70 ya takwimu hiyo, kwa sababu latency ya kumbukumbu na prefetching isiyo kamilifu inamaanisha huwezi kufikia kilele cha kinadharia. VPS yenye channel mbili ya DDR4-3200 ina kikomo cha 3 tokens kwa sekunde, kwa hiyo tarajia takriban 2. Mashine yenye channel mbili ya DDR5-4800 ina kikomo cha 4.5, kwa hiyo tarajia takriban 3.

Safu za seva kubwa huja na onyo. Jukwaa la EPYC lenye channel kumi na mbili lina 460.8 GB/s na kikomo cha 27.1 tokens kwa sekunde, lakini hukodi EPYC nzima. Bandwidth ya kumbukumbu ni rasilimali ya seva nzima inayoshirikiwa na kila mpangaji kwenye mashine hiyo, kwa hiyo kipande cha 8 vCPU hakiji na channel kumi na mbili za bandwidth ya kipekee. Miongozo inayolenga GPU huruka hili kabisa, na ndiyo sababu mipango miwili ya VPS yenye idadi sawa ya vCPU inaweza kutofautiana kwa mara tatu kwenye model ileile.

vCPU nyingi zaidi huacha kusaidia mapema kwa sababu hiyo hiyo. Mara tu cores zinapoomba data kwa kasi zaidi kuliko controller ya kumbukumbu inavyoweza kutoa, threads za ziada huongeza mzigo wa scheduling na si kingine. Weka OLLAMA_NUM_THREAD kwenye idadi yako ya physical cores, pima, kisha jaribu nusu ya idadi hiyo. Kwenye mipango mingi ya pamoja, mpangilio wa chini ni wa haraka zaidi.

Uchakataji wa prompt hufanya kazi tofauti. Prefill, yaani hatua ya kupitia input yako kabla ya token ya kwanza kuonekana, inategemea uwezo wa kompyuta (compute bound) badala ya bandwidth, kwa hiyo inaongezeka kulingana na idadi ya cores. Athari ya kivitendo ni kusubiri kwa muda mrefu kabla ya pato kuanza kwenye prompt kubwa, ikifuatiwa na kasi ndogo na thabiti iliyotajwa hapo juu. Pima sehemu zote mbili kwa kutumia --verbose, ambayo huchapisha prompt eval rate na eval rate kwa kila ombi.

Ikiwa dense 27B ni polepole sana, angalia tag za qwen3.6:35b-a3b kabla ya kukata tamaa na CPU. Hizo huwasha takriban vigezo (parameters) bilioni 3 kwa kila token badala ya bilioni 27.8 zote, kwa hiyo trafiki ya kumbukumbu kwa kila token hupungua kwa karibu mara kumi ingawa faili iliyo kwenye diski ni kubwa. Unabadilisha matumizi ya RAM ili kupata kasi. Chaguo la runtime ni muhimu hapa pia, na Ollama na llama.cpp hutoa vidhibiti tofauti vya tuning ya CPU juu ya code ileile ya inference.

Wakati wa kukodisha GPU kwa saa badala yake

[
  {
    "label": "L40S, 48 GB",
    "mem_bandwidth_gb_s": 864,
    "ceiling_tok_s": 51
  },
  {
    "label": "RTX 4090, 24 GB",
    "mem_bandwidth_gb_s": 1008,
    "ceiling_tok_s": 59
  },
  {
    "label": "A100, 80 GB",
    "mem_bandwidth_gb_s": 2039,
    "ceiling_tok_s": 120
  },
  {
    "label": "H100 SXM, 80 GB",
    "mem_bandwidth_gb_s": 3350,
    "ceiling_tok_s": 197
  }
]

Mfumo uleule uliotumika kwenye bandwidth ya kumbukumbu ya GPU iliyochapishwa unatoa kategoria tofauti ya jibu. Kadi ya mtumiaji ya 24 GB ina ukomo wa 59 tokens kwa sekunde kwenye uzito huu. Kadi ya sasa ya kituo cha data inafikia 197. Hilo si pengo unaloweza kuziba kwa kurekebisha idadi ya thread. Kadi huendesha kumbukumbu yake kwa 1008 GB/s ambapo VPS yako huendesha kwa makumi.

Kwa hivyo chora mstari kulingana na mzigo wa kazi badala ya upendeleo. Inference ya CPU ndiyo jibu sahihi wakati kazi ni ya asynchronous na hakuna anayesubiri: muhtasari wa rundo la hati wakati wa usiku, au kazi ya uainishaji ya usiku inayofanya kazi wakati umelala. Kodisha GPU wakati mtu anasubiri matokeo, au wakati maombi yanapofika kwa kasi zaidi ya moja kila sekunde 30, kwa sababu sanduku la CPU pekee halina nafasi ya batching na foleni hukua tu.

Ulinganisho wa gharama si dhahiri kama unavyoonekana. VPS ya 64 GB hutoza kila saa ya mwezi iwe modeli imepakiwa au la, wakati instance ya GPU hutoza tu saa unazoiacha ikiwa inafanya kazi. Ikiwa matumizi yako halisi ni saa mbili kwa siku, GPU iliyokodishwa inaweza kuwa ya haraka na ya bei nafuu. Amua kwanza mzunguko wako wa kazi, kisha uipangie bei. Kuchagua VPS yenye GPU inashughulikia mambo ya kuangalia kwenye instance yenyewe, na vLLM inazidi Ollama pindi unapotumikia maombi ya wakati mmoja kwenye GPU kwa sababu inafanya batching ipasavyo.

Kuna chaguo la tatu ambalo watu wanalisahau. Weka 27B kwenye CPU kwa kazi za batch na uweke modeli ya API inayohudumiwa mbele ya njia ya mwingiliano. Hakuna kinachohitaji modeli moja kuhudumia zote mbili.

Sakinisha Ollama na upime uwezo wa seva yako

Hati ya usakinishaji ni ile rasmi, na inaweka huduma ya systemd inayofanya kazi kama mtumiaji maalum wa ollama.

curl -fsSL https://ollama.com/install.sh | sh
ollama --version
free -g

ollama --version inapaswa kuonyesha 0.32.5 au toleo jipya zaidi. Angalia free -g kabla ya kupakua chochote. Ikiwa safu ya total kwenye mstari wa Mem inaonyesha chini ya 32, sitisha hapa na uchague model ndogo zaidi, kwa sababu kupakua GB 17 ambazo huwezi kuziendesha ni kupoteza saa moja na nafasi kubwa ya diski.

Weka chaguzi za runtime kwenye override ya systemd badala ya shell yako. Model huendeshwa ndani ya huduma, kwa hivyo haiwezi kuona mazingira yako ya interactive.

sudo systemctl edit ollama

[Service]
Environment="OLLAMA_CONTEXT_LENGTH=8192"
Environment="OLLAMA_NUM_PARALLEL=1"
Environment="OLLAMA_MAX_LOADED_MODELS=1"
Environment="OLLAMA_FLASH_ATTENTION=1"
Environment="OLLAMA_KV_CACHE_TYPE=q8_0"
Environment="OLLAMA_KEEP_ALIVE=60m"

sudo systemctl restart ollama
ollama pull qwen3.6:27b
ollama run qwen3.6:27b --verbose "Name two Linux distributions."

Matokeo ya --verbose ndiyo kipimo ulichokuwa unakitafuta. eval rate ni idadi ya tokens kwa sekunde wakati wa generation. prompt eval rate ni kasi yako ya prefill. load duration ni muda uliotumika kusoma weights kutoka kwenye diski, ndiyo sababu OLLAMA_KEEP_ALIVE=60m imewekwa: kwenye CPU, kupakia upya 17 GB kutoka kwenye diski katika kila ombi kunagharimu zaidi ya ombi lenyewe.

Wakati model imepakiwa, angalia matumizi ya kumbukumbu kutoka kwenye terminal ya pili.

ollama ps

Safu ya SIZE ni matumizi halisi ya kumbukumbu ikijumuisha KV cache, na inapaswa kuwa karibu na uzito wa weights pamoja na mstari wa urefu wa context yako kwenye chati ya KV. Kwa tokens 8192 na cache ya 8-bit, tarajia takriban gigabyte moja juu ya weights, ikilinganishwa na 2 GB ikiwa cache ingebaki katika f16. Safu ya PROCESSOR inapaswa kuonyesha 100% CPU. Ikiwa inaonyesha kitu kingine chochote, kuna kitu kingine kinachotumia GPU na namba za kasi katika mwongozo huu hazielezei uwezo wa seva yako.

Njia za kufeli na ujumbe kamili utakaouona

Model inakataa kupakia. Ollama huchapisha mstari unaotaja takwimu zote mbili, katika umbo la model requires more system memory (18.6 GiB) than is available (15.2 GiB). Hii ni hali nzuri ya kufeli, kwa sababu Ollama ilikagua kabla ya kutenga rasilimali badala ya kuacha kernel ishughulikie tatizo. Punguza urefu wa context, tumia tag ndogo zaidi, au hamia kwenye mpango mkubwa zaidi.

Mchakato hupotea katikati ya jibu. Mteja haonyeshi chochote cha maana, na journalctl -u ollama -n 50 inaonyesha huduma ikianzishwa upya. Endesha dmesg -T | tail, na mstari unaosomeka Out of memory: Killed process ... (ollama) unamaanisha kuwa OOM killer ya kernel imeifunga. Hilo hutokea wakati ukaguzi wa awali umepita lakini cache ilikua zaidi ya makadirio wakati wa mazungumzo marefu. Punguza urefu wa context.

Uvutaji (pull) unafeli mara moja. Error: pull model manifest: file does not exist inamaanisha kuwa tag hiyo haipo kwenye maktaba. Kuandika qwen3.8:27b hutoa ujumbe huu hasa, na vivyo hivyo kwa kosa lolote la kuandika kwenye namba ya toleo. Thibitisha tag kwenye ukurasa wa maktaba kabla ya kulaumu mtandao wako.

Kila kitu kinafanya kazi lakini ni polepole sana. Chini ya token moja kwa sekunde kwenye mashine yenye RAM ya kutosha inaashiria paging badala ya uwezo wa kompyuta. Endesha vmstat 1 wakati wa kuzalisha. Safu ya si au so isiyo ya sifuri inamaanisha kuwa kernel inafanya swapping, na suluhisho ni kupunguza context au kupunguza idadi ya model zilizopakiwa. wa ya juu na thabiti bila shughuli ya swap inamaanisha kuwa uzito (weights) uliopangwa kwenye kumbukumbu unasomwa upya kutoka kwenye diski, jambo linalomaanisha kuwa hazitoshei kikamilifu.

Token ya kwanza inachukua sekunde 30 kisha kasi ya utoaji inaongezeka. Hiyo ni prefill, na ni kawaida. Prompt ndefu ya mfumo hulipiwa kwa kila ombi linalokosa cache, kwa hivyo fupisha prompt ya mfumo kabla ya kurekebisha kitu kingine chochote.

Matumizi sahihi ya CPU-only 27B

Weka matarajio kulingana na namba badala ya matumaini. Kwa kasi ya token mbili hadi nne kwa sekunde, jibu la token 500 huchukua kati ya dakika mbili na nne. Hii haifai kwa chat lakini inafaa kabisa kwa foleni ya kazi (queue). Muhtasari wa nyaraka, kuweka tag kwa wingi, kuchimba data kutoka kwenye faili zilizokusanyika, na ukaguzi wa msimbo (code review) usiohitaji usimamizi, vyote vinaweza kuvumilia kasi hii kwa sababu hakuna kinachosubiri jibu hilo. Usaidizi wa kuandika msimbo upo kwenye mstari huo huo, kwa hivyo kuelekeza wakala wa msimbo kwenye model unayoiendesha mwenyewe kunaleta faida kwa kazi za nyuma kama ujumbe wa commit na ujenzi wa majaribio (test scaffolding), na si kwa mapendekezo ya papo hapo unayoyasubiri.

Hoja ya faragha ndiyo ya msingi. Model inaendeshwa kwenye vifaa unavyokodisha na kuvidhibiti, hakuna ombi linalotoka nje ya seva, na hakuna malipo kwa kila token. Hii ina thamani kubwa kwa data zinazodhibitiwa kisheria hata kwa kasi ya token tatu kwa sekunde. Pima hili kwa uaminifu dhidi ya njia mbadala: kujiendeshea mwenyewe model ya kiwango cha juu kunahitaji vifaa vingi zaidi kwa mara kumi, na 27B kwenye CPU ndiyo sehemu ya bei nafuu zaidi kwenye mchoro huo ambapo matokeo bado yanafaa kusomwa.

Ikiwa huu ni usakinishaji wako wa kwanza wa Ollama, mwongozo kamili wa kuendesha Ollama kwenye VPS unashughulikia usanidi wa huduma, HTTP API, na sheria za firewall ambazo mwongozo huu unachukulia kuwa tayari unazo. Usifungue port 11434 kwenye Internet. Ollama inatolewa bila uthibitishaji wake wa ndani, kwa hivyo chochote kinachofika kwenye port hiyo kinaweza kutumia model yako na kusoma maelekezo (prompts) yako.

FAQ

Je, kuna model ya Qwen 3.8 27B kwenye Ollama?

Hapana. Kufikia tarehe 4 Agosti 2026, maktaba ya Ollama haina namespace ya qwen3.8. Lebo za 27B zilizopo ni qwen3.5:27b na qwen3.6:27b, zote zikiwa ni matoleo ya Q4_K_M ya model yenye vigezo bilioni 27.8. Namba 3.8 katika neno la utafutaji karibu hakika ni idadi ya vigezo 27.8B iliyokumbukwa kama namba ya toleo. Angalia https://ollama.com/library/qwen3.6/tags kwa orodha ya sasa, na fanya pull ya qwen3.6:27b ikiwa unataka toleo jipya zaidi la 27B. Lebo isiyokuwepo inashindwa na kutoa kosa la Error: pull model manifest: file does not exist.

Ninahitaji RAM kiasi gani ili kuendesha model ya Qwen 27B kwenye VPS?

32 GB ndiyo kiwango cha chini kinachofaa kwa Q4_K_M. Uzito wa model (weights) ni 17 GB, mfumo wa uendeshaji unahitaji takriban 1.5 GB, na KV cache huongeza takriban 1 GB kwa kila token 4000 za muktadha (context) katika f16. Mpango wa 16 GB hauwezi kuhifadhi uzito huo hata kidogo, na swap haisaidii kwa sababu faili hupangwa kwenye kumbukumbu (memory-mapped) na kernel huirejesha kutoka kwenye diski katika kila token. 64 GB inakupa nafasi ya muktadha mrefu au kwa ajili ya uzito wa Q8_0 wenye ukubwa wa 30 GB.

Nitapata token ngapi kwa sekunde kwa model ya 27B kwenye CPU?

Gawa bandwidth ya kumbukumbu yako kwa ukubwa wa uzito wa model, kisha chukua asilimia 50 hadi 70 ya matokeo hayo. VPS yenye DDR4-3200 ya njia mbili (two-channel) ina ukomo karibu na 3 token kwa sekunde na hutoa takriban 2. Mashine yenye DDR5-4800 ya njia mbili ina ukomo karibu na 4.5 na hutoa takriban 3. Majukwaa ya seva yenye njia nyingi huonekana bora zaidi kwenye karatasi, lakini bandwidth ya kumbukumbu hushirikishwa na kila mtumiaji kwenye host, kwa hivyo pima yako mwenyewe kwa kutumia ollama run qwen3.6:27b --verbose na usome mstari wa eval rate.

Je, nitumie Q4 au Q8 kwenye VPS ya CPU pekee?

Q4_K_M, katika karibu kila hali. Q8_0 ni 30 GB ikilinganishwa na 17 GB, kwa hivyo inahitaji mpango wa 64 GB na husogeza kumbukumbu karibu mara mbili zaidi kwa kila token, jambo ambalo hupunguza token zako kwa sekunde kwa takriban nusu. Tofauti ya ubora kati ya Q4_K_M na Q8_0 kwenye model ya 27B ni ndogo kwa kazi nyingi. Tumia RAM hiyo kwa muktadha mrefu zaidi, kwa sababu hiyo hubadilisha kile ambacho model inaweza kufanya badala ya jinsi inavyopanga maneno.

Ni lini kukodisha GPU ni nafuu kuliko VPS yenye RAM kubwa?

Wakati mzunguko wako wa kazi ni mdogo au kuna mtu anayesubiri. GPU yenye kumbukumbu ya 24 GB hufikia takriban 59 token kwa sekunde kwa uzito huu, ikilinganishwa na 2 au 3 kwenye VPS ya kawaida, na inatoza malipo kwa saa ambazo inafanya kazi pekee. VPS ya 64 GB inatoza malipo mwezi mzima iwe model imepakiwa au la. Hesabu ni saa ngapi kwa siku unazozalisha token kweli. Chini ya saa mbili au tatu, kukodisha GPU kwa saa mara nyingi hushinda kwa kasi na gharama. Kazi za kundi (batch work) za kipaumbele cha chini zinazoendelea ndipo VPS inayowaka muda wote inaposhinda.