Paano Patakbuhin ang Qwen 3.8 27B sa VPS

Maaari mo bang patakbuhin ang Qwen 3.8 27B sa isang VPS na walang GPU?

Para patakbuhin ang Qwen 3.8 27B sa isang VPS, kailangan mo muna ng umiiral na model tag. Noong 4 August 2026, walang qwen3.8 entry ang Ollama library. Ang pinakamalapit na inilabas na 27B tag ay qwen3.6:27b: 27.8 billion parameters, Q4_K_M quantisation, at Apache 2.0 licence. Ginagamit ng bawat command at bawat numero sa ibaba ang tag na iyon sa Ollama v0.32.5, na inilabas noong 27 July 2026.

Ang maikling sagot ay oo, sa VPS na may 32 GB o higit pang RAM, ngunit mabagal. Ang 27B dense model sa Q4 ay nangangailangan ng humigit-kumulang 17 GB ng RAM para sa weights lamang, bago pa ma-store ang kahit isang token ng context. Dahil dito, hindi sapat ang mga plan na may 8 GB at 16 GB. Sa karaniwang two-channel DDR4 VPS, humigit-kumulang 3 tokens per second ang ceiling. Mas mabagal ito kaysa sa bilis ng pagbabasa ng karamihan.

Saan nanggaling ang 3.8? Malamang sa parameter count. Iniulat ng Ollama page para sa qwen3.6:27b ang 27.8B parameters, at madaling maalala kalaunan ang 27.8 bilang 3.8. Mayroon ding qwen3.5:27b, ang parehong Q4_K_M build mula sa nakaraang release. Suriin ang live list bago kumopya ng anumang command sa qwen3.6 tag page ng Ollama. Kung may totoong qwen3.8 na ilabas sa hinaharap, naaangkop pa rin ang arithmetic dito dahil nakabatay ito sa parameter count at bits per weight, hindi sa version number.

Aling Ollama tag ang dapat i-pull, at kung paano ito suriin

Kapag nag-pull ng tag na hindi umiiral, magpapakita ito ng malinaw na error. Kaya mabilis itong ma-verify mismo sa server.

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

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

Ipinapakita ng ollama show ang architecture, bilang ng parameters, haba ng context, at quantisation para sa tag na aktuwal mong mayroon. Kung 27.8B ang nakalagay sa parameter line at Q4_K_M ang nakalagay sa quantisation line, iyon ang build na ginamit sa gabay na ito. Mayroon ding qwen3.6:27b-q8_0 at qwen3.6:27b-bf16 ang library para sa parehong weights na mas mataas ang precision. Mayroon din itong mga 35b-a3b tag na mga MoE (mixture of experts) model at ibang-iba ang behavior sa CPU. Higit pa tungkol sa mga ito sa ibaba.

Bilang ng parameter na pinarami sa bytes bawat weight

[
  {
    "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"
  }
]

Isang linya lang ang formula. Ang bytes ng weights = parameters * bits bawat weight / 8. Sa eksaktong 4 bits, magiging 13.9 GB ang 27.8 billion parameters. Ang inilabas na Q4_K_M tag ay 17 GB, na katumbas sa aktuwal na paggamit ng 4.89 bits bawat weight.

Hindi error ang pagkakaibang iyon. Hindi ini-store ng K-quant formats ang bawat tensor sa nominal na width. Ang mga tensor na pinakamaraming nawawalang quality kapag kino-compress ay pinananatili sa 5 o 6 bits, at karaniwang iniiwan sa Q6_K o Q8_0 ang token embedding at output layers. Average ang tinutukoy ng pangalan ng format, at umaabot ang average sa halos 4.9. Makikita rin ang parehong epekto sa kabilang dulo ng scale: ang 56 GB para sa BF16 ay 16.1 bits bawat weight sa halip na flat na 16, dahil naglalaman din ang file ng metadata at full-precision embedding table.

Walang published tag ang Q5_K_M para sa model na ito, kaya kinuwenta ang row na 19.8 GB gamit ang karaniwang 5.7 bits bawat weight para sa format na iyon, sa halip na sukatin. Halos dinodoble ng Q8_0 ang Q4, hanggang 30 GB. Sa CPU-only box, ang pagdodobleng ito ay nagkakahalaga ng dalawang beses na memory traffic bawat token, kaya humigit-kumulang nahahati rin sa dalawa ang tokens per second. Dahil dito pa lang, Q4_K_M na ang tamang default dito.

Gastos ng KV cache habang lumalaki ang context

Fixed cost ang weights. Ang KV cache (key at value cache, o attention state na iniingatan ng model para sa bawat token na nakita na nito) ay lumalaki nang tuwiran kasabay ng haba ng context. Dito kadalasang nauubusan ng RAM ang mga user.

[
  {
    "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
  }
]

Ipinapalagay ng mga numerong ito ang configuration na ginamit ng Qwen sa mga kamakailang dense model nito na kabilang sa ganitong size class: 64 layers, 8 key/value heads gamit ang GQA (grouped-query attention), at head dimension na 128. Katumbas nito ang 256 KiB bawat token sa f16, kaya 8 GB ito sa 32k token at 32 GB sa 128k. Huwag umasa sa arithmetic na ito para sa sarili mong box. I-load ang model at basahin ang SIZE column ng ollama ps. Iniuulat nito bilang isang value ang pinagsamang weights, cache, at overhead.

Ito ang dahilan kung bakit headline lang at hindi aktuwal na plano ang 256K context na nasa model card. Kung pupunuin ito sa f16, mangangailangan ito ng 64 GB na cache bukod pa sa weights, sa machine na gumamit na ng 17 GB para sa weights. Hindi ibinibigay ng Ollama bilang default ang buong window. Mas maliit na window ang nilo-load nito, at ikaw ang sadyang magtataas nito gamit ang OLLAMA_CONTEXT_LENGTH. Itaas ito nang paunti-unti at tingnan ang ollama ps pagkatapos ng bawat pagbabago.

May dalawang setting na kayang magpababa sa cache nang kalahati o higit pa. Ini-store ng OLLAMA_KV_CACHE_TYPE=q8_0 ang cache sa 8 bits sa halip na 16, kaya bumababa ang gamit para sa 32k token mula 8 GB tungo sa 4 GB. Kailangan nito ng flash attention, kaya itakda rin ang OLLAMA_FLASH_ATTENTION=1, at kumpirmahin ang pagbaba sa ollama ps sa halip na ipagpalagay na nailapat ang setting. Mahalaga rin ang OLLAMA_NUM_PARALLEL=1. Kayang mag-serve ng ilang request nang sabay ang Ollama, at may sarili nitong bahagi ng context ang bawat slot. Kaya kapag iniwan sa default ang parallelism, tahimik nitong pinaparami ang cache na isinama mo sa iyong budget. Kung higit sa isang tao ang gagamit ng box na ito, dito nagsisimula ang problema. Ang bilang ng sabay-sabay na user na kayang i-serve ng isang self-hosted model ay nakadepende sa cache slots at queue depth bago pa ito nakadepende sa bilang ng core.

Ano ang kasya sa 8, 16, 32, at 64 GB ng 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."
  }
]

Basahin ang dalawang numero bilang libo-libong token ng context na kasya kasabay ng weights, gamit ang f16 cache, sa isang headless Linux VPS na may humigit-kumulang 1.5 GB na natitira para sa operating system at maliit na dagdag na margin. Ibig sabihin ng zero, hindi kasya ang weights mismo, kaya walang context na kasya.

Hindi magkalapit na kaso ang 8 GB at 16 GB. Hindi kasya ang 17 GB na weights sa 16 GB ng RAM, at walang context setting na makapagbabago rito. Hindi rin ito malulutas ng pagdaragdag ng swap. Mina-memory-map ng Ollama ang GGUF file, kaya kapag lumampas sa RAM ang resident pages, nagsisimulang mag-evict at magbasa muli ang kernel. Bawat token ay kumukuha tuloy ng gigabytes mula sa disk. Nananatili ang server sa mataas na iowait at nakakagawa ng mas mababa sa isang token kada segundo.

Ang 32 GB ang panimulang tier. Kumokonsumo ang weights ng 17 GB, kaya humigit-kumulang 13 GB ang natitira. Sapat ito para sa tinatayang 32k token ng f16 context, kasama ang margin. Hindi kasya sa tier na ito ang Q8_0 weights na 30 GB.

Komportable ang 64 GB. Nag-iiwan ang Q4 ng espasyo para sa humigit-kumulang 128k token ng context, at kasya ang Q8_0 weights na may humigit-kumulang 64k token na natitirang espasyo. Bago magbayad para sa 64 GB para makagamit ng Q8, linawin kung ano ang makukuha mo: bahagyang mas magandang output sa kalahating bilis, sa machine na mabagal na nga. Para sa halos lahat, mas magandang trade-off ang Q4 na may mas mahabang context.

Gaano kabilis ang CPU inference sa isang VPS?

Ang pag-generate ng isang token mula sa isang dense model ay nangangahulugang basahin mula sa memory ang bawat weight nang isang beses. Hindi ilan lamang. Lahat. Kaya ang speed limit ay hindi ang bilang ng core mo, kundi ang memory bandwidth na hinati sa laki ng mga weight. Sa Q4, iyon ay 17 GB na memory traffic bawat 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
  }
]

Mga ceiling ang mga iyon, hindi aktuwal na sukat. Karaniwang nasa 50 hanggang 70 porsiyento ng ipinakitang figure ang aktuwal na output dahil hindi mo naaabot ang theoretical peak dahil sa memory latency at hindi perpektong prefetching. Ang two-channel DDR4-3200 VPS ay may ceiling na 3 tokens bawat segundo, kaya asahan ang humigit-kumulang 2. Ang two-channel DDR5-4800 machine ay may ceiling na 4.5, kaya asahan ang humigit-kumulang 3.

May kasamang babala ang malalaking server row. Ang twelve-channel EPYC platform ay may 460.8 GB/s at ceiling na 27.1 tokens bawat segundo, pero hindi ka umuupa ng buong EPYC. Host-wide resource ang memory bandwidth na pinaghahatian ng bawat tenant sa machine na iyon, kaya ang isang 8 vCPU slice ay walang kasamang labindalawang channel ng eksklusibong bandwidth. Karaniwang hindi ito tinatalakay sa mga guide na nakatuon sa GPU, at ito ang dahilan kung bakit maaaring magkaiba nang tatlong ulit ang bilis ng dalawang VPS plan na magkapareho ang bilang ng vCPU sa parehong model.

Maaga ring tumitigil sa pagtulong ang mas maraming vCPU sa parehong dahilan. Kapag mas mabilis nang humihingi ng data ang mga core kaysa sa kayang ihatid ng memory controller, scheduling overhead lamang ang idinadagdag ng mga karagdagang thread. Itakda ang OLLAMA_NUM_THREAD sa bilang ng iyong physical core, magsukat, at pagkatapos ay subukan ang kalahati ng bilang na iyon. Sa maraming shared plan, mas mabilis ang mas mababang setting.

Iba ang kilos ng prompt processing. Ang prefill, o ang pagdaan sa input bago lumitaw ang unang token, ay compute-bound sa halip na bandwidth-bound, kaya umaangat ang performance nito kasabay ng bilang ng core. Ang praktikal na epekto ay mahabang paghihintay bago magsimula ang output kapag malaki ang prompt, na sinusundan ng mabagal at tuloy-tuloy na rate sa itaas. Sukatin nang magkahiwalay ang dalawang bahaging ito gamit ang --verbose, na nagpi-print ng prompt eval rate at eval rate para sa bawat request.

Kung masyado talagang mabagal ang dense 27B, tingnan muna ang mga qwen3.6:35b-a3b tag bago sumuko sa CPU. Humigit-kumulang 3 bilyong parameter bawat token ang ina-activate ng mga ito sa halip na lahat ng 27.8 bilyon, kaya halos isang order of magnitude ang ibinababa ng memory traffic bawat token kahit mas malaki ang file sa disk. Ipinagpapalit mo ang RAM footprint para sa bilis. Mahalaga rin dito ang runtime choice, at magkaibang CPU tuning control ang inilalantad ng Ollama at llama.cpp sa parehong underlying inference code.

Kailan mas mainam umupa ng GPU hour

[
  {
    "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
  }
]

Kapag inilapat ang parehong formula sa naka-publish na GPU memory bandwidth, ibang kategorya ng sagot ang makukuha. Ang isang 24 GB consumer card ay may maximum na 59 tokens bawat segundo para sa mga weight na ito. Umaabot naman ang isang kasalukuyang data centre card sa 197. Hindi ito agwat na malulutas sa pag-tune ng thread count. Tumatakbo ang memory ng card sa 1008 GB/s, samantalang ang VPS mo ay nasa ilang dosenang GB/s lamang.

Kaya itakda ang hangganan batay sa workload, hindi sa preference. Tama ang CPU inference kapag asynchronous ang trabaho at walang naghihintay sa resulta: halimbawa, overnight summarisation ng maraming dokumento o nightly classification job na tumatakbo habang natutulog ka. Umupa ng GPU kapag may taong naghihintay sa output, o kapag mas mabilis sa isang request bawat 30 segundo ang pagdating ng mga request. Walang sapat na batching headroom ang CPU-only box, kaya patuloy lang lalaki ang queue.

Hindi gaanong simple ang cost comparison gaya ng unang tingin. Sisingilin ka sa 64 GB VPS bawat oras ng buong buwan, ginagamit man ang model o hindi, samantalang sisingilin ka sa GPU instance para lamang sa mga oras na pinapatakbo mo ito. Kung dalawang oras bawat araw ang aktuwal mong paggamit, maaaring parehong mas mabilis at mas mura ang rented GPU. Kalkulahin muna ang duty cycle, saka ihambing ang presyo. Saklaw ng Pagpili ng VPS na may GPU ang mga dapat tingnan mismo sa instance, at Nauungusan ng vLLM ang Ollama kapag nagseserbisyo ka ng sabay-sabay na request sa GPU dahil maayos nitong bina-batch ang mga ito.

May pangatlong opsyon na madalas nakalilimutan. Panatilihin ang 27B sa CPU para sa batch work at gumamit ng hosted API model para sa interactive path. Walang nangangailangang iisang model ang magsilbi sa dalawang gamit.

Mag-install ng Ollama at sukatin ang sarili mong machine

Ang install script ang opisyal na script, at nagse-set up ito ng systemd service na tumatakbo bilang dedicated na ollama user.

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

Dapat mag-print ang ollama --version ng 0.32.5 o mas bago. Suriin ang free -g bago ka mag-pull ng anuman. Kung ang column na total sa linya ng Mem ay mas mababa sa 32, huminto rito at pumili ng mas maliit na model, dahil masasayang lang ang isang oras at malaking bahagi ng disk sa pag-pull ng 17 GB na hindi mo naman kayang patakbuhin.

Itakda ang runtime options sa systemd override sa halip na sa shell mo. Sa loob ng service tumatakbo ang model, kaya hindi nito nakikita ang interactive environment mo.

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."

Ang output ng --verbose ang measurement na kailangan mo. Ang eval rate ang tokens per second mo habang nagge-generate. Ang prompt eval rate ang prefill speed mo. Ang load duration ang tagal ng pagbasa sa weights mula sa disk, kaya naka-set ang OLLAMA_KEEP_ALIVE=60m: sa CPU, mas matagal ang pag-reload ng 17 GB mula sa disk sa bawat request kaysa sa mismong request.

Habang naka-load ang model, tingnan ang footprint mula sa pangalawang terminal.

ollama ps

Ang SIZE column ang aktuwal na memory footprint kasama ang KV cache, at dapat itong malapit sa kabuuan ng weights at ng row para sa context length mo sa KV chart. Sa 8192 tokens na may 8-bit cache, asahan ang humigit-kumulang isang gigabyte bukod sa weights, kumpara sa 2 GB kung nanatiling f16 ang cache. Dapat magbasa ang PROCESSOR column ng 100% CPU. Kung iba ang nakalagay, may ibang proseso o component na gumamit ng GPU, at hindi inilalarawan ng speed numbers sa guide na ito ang machine mo.

Mga failure mode at ang eksaktong strings na makikita mo

Hindi naglo-load ang model. Nagpi-print ang Ollama ng line na naglalaman ng parehong figure, sa anyong model requires more system memory (18.6 GiB) than is available (15.2 GiB). Mabuting failure ito dahil nagsuri muna ang Ollama bago mag-allocate, sa halip na ipaubaya ito sa kernel. Bawasan ang context length, gumamit ng mas maliit na tag, o lumipat sa mas malaking plan.

Nawawala ang process habang may isinasagawang sagot. Walang kapaki-pakinabang na ipinapakita ang client, at ipinapakita ng journalctl -u ollama -n 50 na nagre-restart ang service. Patakbuhin ang dmesg -T | tail. Kapag may line na Out of memory: Killed process ... (ollama), nangangahulugan itong pinatay ito ng kernel OOM killer. Nangyayari ito kapag pumasa ang pre-load check ngunit lumampas sa estimate ang cache habang mahaba ang conversation. Bawasan ang context length.

Agad na nagfa-fail ang pull. Ibig sabihin ng Error: pull model manifest: file does not exist na wala sa library ang tag. Kapag nag-type ka ng qwen3.8:27b, eksaktong ganito ang lalabas. Ganito rin ang resulta ng typo sa version number. I-confirm ang tag sa library page bago sisihin ang network.

Gumagana ang lahat pero napakabagal. Kung mas mababa sa one token per second sa isang box na may sapat na RAM, malamang paging ang problema at hindi compute. Patakbuhin ang vmstat 1 habang nagge-generate. Ibig sabihin ng non-zero na si o so column na nag-swa-swap ang kernel. Ang solusyon ay mas maikling context o mas kaunting loaded model. Kung mataas at tuloy-tuloy ang wa ngunit walang swap activity, nire-re-read mula sa disk ang memory-mapped weights. Ibig sabihin, hindi talaga kasya ang mga ito.

Umaabot ng 30 seconds ang unang token at bumibilis ang output pagkatapos. Prefill iyon at normal ito. Binabayaran sa bawat request na hindi gumagamit ng cache ang mahabang system prompt. Paikliin muna ang system prompt bago mag-tune ng iba pa.

Para saan talaga ang isang CPU-only na 27B

Itakda ang expectations batay sa mga numero, hindi sa pag-asa. Sa bilis na two hanggang four tokens per second, ang sagot na 500 tokens ay tumatagal ng two hanggang four minutes. Hindi ito praktikal para sa chat, pero maayos itong gumagana para sa queue. Kayang tiisin ng document summarisation, bulk tagging, field extraction mula sa backlog ng files, at unattended code review ang ganitong bilis dahil walang naghihintay sa sagot. Nasa hangganang ito ang coding assistance. Kaya sulit ang pagpapatakbo ng coding agent gamit ang model na naka-host sa iyo para sa mga background job gaya ng commit messages at test scaffolding, pero hindi para sa inline suggestions na hinihintay mong lumabas.

Ang privacy argument ang tunay na dahilan. Tumatakbo ang model sa hardware na nirenta at kinokontrol mo, walang request na lumalabas sa server, at walang per-token bill. Malaki ang halaga nito para sa regulated data kahit three tokens per second lang ang bilis. Timbangin ito nang tapat laban sa alternatibo: ang self-hosting ng frontier-scale model ay nangangailangan ng hardware na isang order of magnitude na mas malaki, at ang 27B sa CPU ang pinakamurang punto sa curve na ito kung saan sulit pa ring basahin ang output.

Kung ito ang unang Ollama install mo, saklaw ng kumpletong walkthrough para patakbuhin ang Ollama sa isang VPS ang service setup, HTTP API, at firewall rules na ipinapalagay ng guide na naihanda mo na. Huwag ilantad sa internet ang port 11434. Walang sariling authentication ang Ollama, kaya magagamit ng anumang makakaabot sa port ang model mo at mababasa ang prompts mo.

FAQ

May Qwen 3.8 27B model ba sa Ollama?

Wala. Noong 4 August 2026, walang qwen3.8 namespace ang Ollama library. Ang mga umiiral na 27B tag ay qwen3.5:27b at qwen3.6:27b, at parehong Q4_K_M build ng isang dense model na may 27.8 billion parameters. Malamang na ang 3.8 sa search term ay ang 27.8B parameter count na naalala bilang version number. Tingnan ang https://ollama.com/library/qwen3.6/tags para sa kasalukuyang listahan, at i-pull ang qwen3.6:27b kung gusto mo ng pinakabagong inilabas na 27B. Mabibigo ang tag na hindi umiiral gamit ang Error: pull model manifest: file does not exist.

Gaano karaming RAM ang kailangan para magpatakbo ng Qwen 27B model sa VPS?

32 GB ang praktikal na minimum para sa Q4_K_M. Ang weights ay 17 GB, nangangailangan ang operating system ng humigit-kumulang 1.5 GB, at nagdadagdag ang KV cache ng tinatayang 1 GB sa bawat 4000 token ng context sa f16. Hindi kayang maglaman ng weights ang 16 GB plan, at hindi nakatutulong ang swap dahil memory-mapped ang file at muli lamang itong binabasa ng kernel mula sa disk sa bawat token. Nagbibigay ang 64 GB ng sapat na puwang para sa mahabang context o para sa Q8_0 weights na 30 GB.

Ilang token bawat segundo ang maibibigay ng 27B model sa CPU?

Hatiin ang memory bandwidth sa laki ng weights, pagkatapos ay kunin ang 50 hanggang 70 porsiyento nito. Ang two-channel DDR4-3200 VPS ay may ceiling na malapit sa 3 token bawat segundo at aktuwal na nagbibigay ng humigit-kumulang 2. Ang two-channel DDR5-4800 box ay may ceiling na malapit sa 4.5 at aktuwal na nagbibigay ng humigit-kumulang 3. Mas maganda sa papel ang mga server platform na may mas maraming channel, pero pinaghahatian ng bawat tenant sa host ang memory bandwidth. Sukatin ang sarili mong resulta gamit ang ollama run qwen3.6:27b --verbose at basahin ang linyang eval rate.

Q4 o Q8 ba ang dapat gamitin sa CPU-only VPS?

Q4_K_M, sa halos lahat ng sitwasyon. Ang Q8_0 ay 30 GB kumpara sa 17 GB, kaya kailangan nito ng 64 GB plan at halos doble ang dami ng memory na inililipat sa bawat token. Dahil dito, humihina nang humigit-kumulang kalahati ang tokens per second. Maliit ang pagkakaiba sa kalidad ng Q4_K_M at Q8_0 sa 27B model para sa karamihan ng task. Mas mabuting gamitin ang RAM para sa mas mahabang context, dahil binabago nito ang mga kayang gawin ng model at hindi lamang ang paraan ng pagbuo nito ng mga pahayag.

Kailan mas mura ang pag-rent ng GPU kaysa sa VPS na may malaking RAM?

Kapag mababa ang duty cycle o may taong naghihintay sa resulta. Ang GPU na may 24 GB memory ay umaabot sa humigit-kumulang 59 token bawat segundo gamit ang mga weights na ito, kumpara sa 2 o 3 sa karaniwang VPS, at oras lamang ng aktuwal na paggamit ang sinisingil. Buong buwan ang singil sa 64 GB VPS kahit naka-load man ang model o hindi. Tantiyaing mabuti kung ilang oras bawat araw ka talaga bumubuo ng mga token. Kung wala pang dalawa o tatlong oras, karaniwang mas mabilis at mas mura ang hourly GPU rental. Para sa tuloy-tuloy ngunit low-priority na batch work, mas matipid ang always-on VPS.