Jinsi ya kuendesha Qwen 27B kwenye VPS na 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 nzito ya 27B katika Q4 inahitaji takriban 17 GB ya RAM kwa ajili ya uzito pekee, kabla hata token moja ya muktadha (context) haijahifadhiwa. 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 unaripoti vigezo 27.8B, na 27.8 ni rahisi kukumbukwa baadaye kama 3.8. Pia kuna 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. Tag iliyopo bado inaweza kushindwa kuendeshwa ndani ya mfumo, jambo ambalo huwachanganya watu na GLM 5.2, iliyoorodheshwa kwenye maktaba lakini inayotolewa kutoka wingu la Ollama pekee.

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, idadi ya vigezo (parameter count), urefu wa muktadha (context length) na quantisation kwa 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 kwa ajili yake. Maktaba pia ina qwen3.6:27b-q8_0 na qwen3.6:27b-bf16 kwa uzito uleule katika usahihi wa juu zaidi, pamoja na seti ya tag za 35b-a3b ambazo ni miundo 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. Katika kiwango safi cha biti 4, vigezo bilioni 27.8 vitakuwa na ukubwa wa 13.9 GB. Lebo ya Q4_K_M iliyotolewa ni 17 GB, ambayo inafanya kuwa 4.89 biti kwa kila uzito katika matumizi ya kawaida.

Pengo hilo si kosa. Miundo ya K-quant haihifadhi kila tensor kwa upana wa kawaida. Tensor zinazopoteza ubora zaidi chini ya mgandamizo (compression) 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 huo 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 hilo pia hubeba metadata na jedwali la embedding la usahihi kamili (full-precision).

Q5_K_M haina lebo iliyochapishwa kwa modeli hii, kwa hivyo safu ya 19.8 GB imehesabiwa kwa kutumia 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 huongeza gharama ya trafiki ya kumbukumbu kwa kila token mara mbili, hivyo pia hupunguza kasi ya token kwa sekunde kwa takriban nusu. Q4_K_M ndiyo chaguo sahihi la msingi hapa kwa sababu hiyo pekee. Ikiwa unataka kuzingatia upande wa ubora wa uamuzi huo badala ya upande wa kumbukumbu, ulinganisho wa karibu zaidi wa Q4, Q8 na fp16 unaonyesha mahali ambapo matokeo huanza kushuka ubora.

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 zinachukulia umbo ambalo Qwen imetumia katika modeli zake za hivi karibuni za aina hii: 64 layers, 8 key/value heads chini ya GQA (grouped-query attention), na head dimension ya 128. Hiyo inafika 256 KiB kwa kila token katika f16, hivyo 8 GB katika 32k tokens na 32 GB katika 128k. Usitegemee hesabu zangu badala ya mashine yako mwenyewe. Pakia modeli na usome safu ya SIZE ya ollama ps, ambayo inaripoti 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. Kuijaza katika 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 unalipanua kwa makusudi ukitumia OLLAMA_CONTEXT_LENGTH. Variable hiyo ya seva nzima si kigezo pekee, na kuweka num_ctx kwenye ombi binafsi hukuruhusu kuweka chaguo-msingi la bei nafuu kwa kila kitu kingine wakati kazi moja ndefu inapata dirisha kubwa zaidi. 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 katika 8 bits badala ya 16, ikipunguza 32k tokens kutoka 8 GB hadi 4 GB. Inahitaji flash attention, kwa hiyo weka OLLAMA_FLASH_ATTENTION=1 pia, na uthibitishe kupungua huko katika ollama ps badala ya kudhani kuwa kimetumika. OLLAMA_NUM_PARALLEL=1 ni muhimu vilevile. Ollama inaweza kuhudumia maombi kadhaa kwa wakati mmoja, na kila nafasi hupata sehemu yake ya muktadha, kwa hiyo kuacha parallelism katika chaguo-msingi huzidisha cache uliyopangia kimyakimya. Ikiwa zaidi ya mtu mmoja atatumia mashine hii, uzidishaji huo ndipo matatizo yanapoanzia, na idadi ya watumiaji wa wakati mmoja ambayo modeli inayojiendesha inaweza kuhudumia huamuliwa na nafasi za cache na kina cha foleni muda mrefu kabla ya kuamuliwa na idadi ya cores.

Kiasi 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 token za muktadha (context) zinazotoshea sambamba na uzani (weights), kwa cache ya f16, 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 mpangilio wa muktadha unaoweza kubadilisha hilo. Kuongeza swap hakusaidii pia. Ollama hufanya memory-map ya faili la GGUF, kwa hivyo kurasa za kumbukumbu (resident pages) zikizidi RAM, kernel huanza kuziondoa na kuzisoma upya, na kila token huchota gigabytes kutoka kwenye diski. Mashine hukwama kwenye iowait ya juu na kutoa chini ya token moja kwa sekunde.

32 GB ndiyo kiwango cha kuanzia. Uzani huchukua 17 GB na unabakiwa na takriban 13 GB, ambayo inatosheleza takriban 32k token 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 token za muktadha, na uzani wa Q8_0 hutoshea pamoja na takriban 64k token 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 kiasi gani?

Kuzalisha token moja kutoka kwenye dense model kunamaanisha kusoma kila uzito (weight) kutoka kwenye kumbukumbu mara moja. Sio baadhi yake. Yote. Kwa hiyo, kikomo cha kasi sio idadi ya core 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 makadirio ya juu, sio vipimo halisi. Pato halisi hufikia takriban asilimia 50 hadi 70 ya takwimu hiyo, kwa sababu latency ya kumbukumbu na prefetching isiyo kamilifu inamaanisha kuwa huwezi kufikia kilele cha kinadharia. VPS yenye chaneli mbili ya DDR4-3200 ina kikomo cha 3 tokens kwa sekunde, kwa hivyo tarajia takriban 2. Mashine yenye chaneli mbili ya DDR5-4800 ina kikomo cha 4.5, kwa hivyo tarajia takriban 3.

Safu za seva kubwa huja na onyo. Jukwaa la EPYC lenye chaneli 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 hivyo kipande cha 8 vCPU hakiji na chaneli 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 core zinapoomba data kwa kasi zaidi kuliko controller ya kumbukumbu inavyoweza kuileta, threads za ziada huongeza mzigo wa scheduling na hakuna kingine. Weka OLLAMA_NUM_THREAD kwenye idadi ya core zako halisi, pima, kisha jaribu nusu ya namba 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 hivyo huongezeka kulingana na idadi ya core. 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 tofauti 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 hivyo trafiki ya kumbukumbu kwa kila token hupungua kwa kiasi kikubwa ingawa faili iliyo kwenye diski ni kubwa. Unabadilisha matumizi ya RAM ili kupata kasi. Chaguo la runtime ni muhimu pia hapa, na Ollama na llama.cpp hutoa vidhibiti tofauti vya tuning ya CPU juu ya code ileile ya msingi 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 hutoa kategoria tofauti ya jibu. Kadi ya watumiaji ya 24 GB ina ukomo wa 59 tokens kwa sekunde kwenye weights hizi. Kadi ya sasa ya data centre hufikia 197. Hilo si pengo unaloweza kuziba kwa kurekebisha idadi ya threads. Kadi hiyo huendesha kumbukumbu yake kwa 1008 GB/s ambapo VPS yako huendesha kwa makumi tu.

Kwa hivyo chora mstari kulingana na mzigo wa kazi badala ya upendeleo. CPU inference ndiyo jibu sahihi wakati kazi ni ya asynchronous na hakuna anayeisubiri: muhtasari wa usiku wa rundo la nyaraka, au kazi ya uainishaji ya usiku inayofanyika 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 model 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 zaidi. Amua kwanza mzunguko wako wa kazi (duty cycle), kisha uipigie 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 kwa usahihi.

Kuna chaguo la tatu ambalo watu husahau. Weka 27B kwenye CPU kwa ajili ya kazi za batch na uweke model ya API inayohudumiwa mbele ya njia ya mwingiliano (interactive path). Hakuna kinachohitaji model 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. Kagua free -g kabla ya kupakua chochote. Ikiwa safu ya total kwenye mstari wa Mem inaonyesha chini ya 32, sitisha hapa na uchague modeli ndogo, kwa sababu kupakua GB 17 ambazo huwezi kuziendesha kutapoteza saa moja na nafasi kubwa ya diski.

Weka chaguzi za runtime kwenye override ya systemd badala ya shell yako. Modeli inaendeshwa 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 kasi yako 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. Muda wa kusubiri (idle timeout) wa kawaida ni dakika tano, ambao ni mfupi kiasi kwamba foleni ya batch yenye mapengo kati ya vitu inalipa gharama hiyo ya kupakia mara kwa mara, na chaguzi za kuweka modeli kwenye kumbukumbu zinashughulikia uwanja wa keep_alive wa kila ombi na kuhakikisha mpangilio huo unadumu baada ya reboot.

Wakati modeli imepakiwa, kagua 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 zenye cache ya 8-bit, tarajia takriban gigabyte moja juu ya weights, ikilinganishwa na 2 GB ikiwa cache itabaki kwenye f16. Safu ya PROCESSOR inapaswa kusoma 100% CPU. Ikiwa inasoma kitu kingine chochote, kuna kitu kimechukua GPU na namba za kasi katika mwongozo huu hazielezei seva yako.

Njia za kufeli na ujumbe kamili utakaouona

Model inakataa kupakia. Ollama huchapisha mstari unaotaja namba 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 kumbukumbu badala ya kuacha kernel iamue. Punguza urefu wa context, tumia tag ndogo zaidi, au hamia kwenye mpango mkubwa zaidi.

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

Upakuaji (pull) unafeli mara moja. Error: pull model manifest: file does not exist inamaanisha kuwa tag hiyo haipo kwenye maktaba. Kuandika qwen3.8:27b kunazalisha ujumbe huu hasa, na vivyo hivyo kwa kosa lolote la uchapaji kwenye namba ya version. 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 uhaba wa nguvu ya kompyuta. Endesha vmstat 1 wakati wa kuzalisha. Safu ya si au so isiyo sifuri inamaanisha kuwa kernel inafanya swapping, na suluhisho ni context ndogo au kupunguza idadi ya models zilizopakiwa. wa ya juu na thabiti bila shughuli ya swap inamaanisha kuwa weights zilizowekwa kwenye kumbukumbu (memory-mapped) zinasomwa tena kutoka kwenye diski, jambo linaloashiria kuwa hazitoshei kikamilifu.

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

Matumizi sahihi ya 27B inayotumia CPU pekee

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 mazungumzo ya moja kwa moja lakini inafaa kabisa kwa kazi za foleni (queue). Model inayofikiri kabla ya kujibu hufanya hesabu hiyo kuwa mbaya zaidi, kwa sababu token za kufikiri huzalishwa kwa kasi hiyo hiyo ya polepole kama jibu, kwa hivyo kuoanisha kiwango cha juhudi za kufikiri na kazi husika ni mojawapo ya mbinu chache za kufupisha jibu bila kubadili model. Muhtasari wa hati, kuweka tag kwa wingi, kuchimba data kutoka kwenye faili zilizokusanyika, na ukaguzi wa code bila kusimamiwa, vyote vinaweza kuvumilia kasi hii, kwa sababu hakuna kinachosubiri jibu hilo. Usaidizi wa kuandika code uko kwenye mstari huo huo, kwa hivyo kuelekeza wakala wa kuandika code kwenye model unayoiendesha mwenyewe kunaleta faida kwa kazi za nyuma kama ujumbe wa commit na ujenzi wa test, na si kwa mapendekezo ya papo hapo unayoyasubiri.

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

Ili kupima yoyote kati ya hayo unahitaji data halisi iliyopangwa, na API nyingi za umma zinahitaji akaunti kabla hujaweza hata kupima throughput. Endpoint ya demo ya Strasmore (tunaiendesha) inajibu SQL ya kusoma pekee kuhusu miaka 22 ya data ya soko la Marekani bila hitaji la key au kujisajili: GET kwenda https://ai.strasmore.com/api/demo/sql?sql=SELECT ticker, close FROM delayed_stocks_minute_aggs LIMIT 5 inarudisha JSON unayoweza kuingiza moja kwa moja kwenye prompt loop, pamoja na SQL kamili iliyoizalisha, ili model iwe na kitu cha kufupisha ambacho unaweza kukikagua kwa kujitegemea. Vikomo ni safu 500 na sekunde 20 kwa kila ombi, kiasi ambacho ni kikubwa zaidi ya kile ambacho seva ya token mbili kwa sekunde inaweza kutumia. Orodha kamili ya safu wima iko kwenye https://api.strasmore.com/v1/schema.

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 unadhani 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 maombi 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 lililotolewa. 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 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 hiyo imewekwa 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.

Model ya 27B itanipa token ngapi kwa sekunde kwenye CPU?

Gawa bandwidth ya kumbukumbu yako kwa ukubwa wa uzito wa model, kisha chukua asilimia 50 hadi 70 ya matokeo hayo. VPS ya njia mbili (two-channel) ya DDR4-3200 ina ukomo karibu na 3 token kwa sekunde na hutoa takriban 2. Mashine ya njia mbili ya DDR5-4800 ina ukomo karibu na 4.5 na hutoa takriban 3. Mifumo ya seva yenye njia nyingi inaonekana bora zaidi kwenye karatasi, lakini bandwidth ya kumbukumbu inashirikiwa na kila mpangaji (tenant) 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 dhidi ya 17 GB, kwa hivyo inahitaji mpango wa 64 GB na inahamisha karibu mara mbili ya kumbukumbu kwa kila token, jambo ambalo hupunguza token zako kwa sekunde kwa 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 kuwa 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 (duty cycle) ni mdogo au kuna mtu anayesubiri. GPU yenye kumbukumbu ya 24 GB hufikia takriban 59 token kwa sekunde kwa uzito huu, dhidi ya 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.