Aling AI model ang kaya mong i-self-host?

Ano ang nagtatakda kung aling AI models ang maaari mong i-self-host

Isang numero ang nagtatakda kung aling AI models ang maaari mong i-self-host: ang RAM ng server. Mas hindi mahalaga ang model family at framework kaysa sa kung kasya ang weights sa memory na may sapat pang natitirang espasyo. Ang post na ito ay tungkol sa arithmetic para makalkula iyon. Hiwalay na gawain ang pag-install ng runtime, at saklaw ito ng gabay sa pagpapatakbo ng Ollama sa isang VPS.

Dalawang gastusin ang nagtatakda ng sagot. Ang weights ang fixed cost, na nakabatay sa parameter count at quantisation. Ang context window ang running cost, at ito ang madalas makalimutan hanggang sa tumangging mag-load ngayon ang model na nag-load kahapon.

Ang sizing arithmetic: bits bawat parameter

Halos puro weights ang laman ng model file. Ang bawat weight ay sine-save gamit ang isang partikular na bilang ng bits. Ang quantisation ay pag-save ng mga ito gamit ang mas kaunting bits kaysa sa precision kung saan sila sinanay. Bahagyang bumababa ang accuracy, pero malaki ang natitipid na memory. Direktang sumusunod dito ang laki ng file:

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

Inilalabas ang mga model gamit ang 16 bits, na katumbas ng 2 GB bawat bilyong parameter. Kaya halos walang nagpapatakbo ng release precision sa isang VPS. Ito ang mga quantisation na aktuwal mong makikita, kasama ang totoong average bits bawat weight:

• Q8_0 gumagamit ng humigit-kumulang 8.5 bits bawat weight, kaya nasa 1.1 GB bawat bilyong parameter.
• Q6_K gumagamit ng humigit-kumulang 6.6 bits, kaya nasa 0.83 GB bawat bilyon.
• Q5_K_M gumagamit ng humigit-kumulang 5.7 bits, kaya nasa 0.71 GB bawat bilyon.
• Q4_K_M gumagamit ng humigit-kumulang 4.8 bits, kaya nasa 0.6 GB bawat bilyon.

Gamitin ang 0.6 GB bawat bilyong parameter bilang working number. Ang Q4_K_M ang praktikal na default sa isang memory-bound na box: maliit ang pagkawala ng quality kumpara sa 8 bits para sa karamihan ng task, at halos kalahati ang laki ng file. Sa ibaba ng 4 bits, mabilis lumalaki ang pagkawala ng quality. Kaya karaniwang mas mahina ang sagot ng 70B na isiniksik sa 2 bits kaysa sa 32B na nasa 4 bits mula sa parehong generation. Kapag kapos ang memory, bumaba muna ng size class bago bumaba sa ibaba ng 4 bits.

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

Ang weight column sa itaas ay ang 0.6 GB bawat bilyong parameter na rule na inilapat. Ang aktuwal na GGUF file ay karaniwang nasa loob ng ilang porsiyento nito, dahil pinananatili sa mas mataas na precision ang embedding at output layers kaysa sa natitirang bahagi. Ang 3B model na nasa 4 bits ay humigit-kumulang 1.8 GB. Ang 8B ay 4.8 GB. Ang 32B ay 19.2 GB, at ang 70B ay 42 GB.

Bakit mas malaking RAM ang kailangan ng context length kaysa sa weights

Ang KV cache (key value cache, ang attention state na pinananatili ng model para sa bawat token na kasalukuyang nasa conversation) ang ikalawang malaking gastos sa memory. Inilalaan ito kapag naglo-load ang model, tina-target ang laki nito batay sa context length na hiniling mo, at lumalaki ito nang linear kasabay ng haba ng context.

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

Sa default context ng Ollama, kalahating gigabyte ng cache ang ginagamit ng 8B model na iyon. Sa 8192 token, 1 GB ang ginagamit nito. Sa 128k context na ipinapakita sa model card nito, 16 GB ang ginagamit nito, na mahigit tatlong beses sa laki ng weights. Kabaligtaran naman ang 70B: ang cache nito sa 128k ay 40 GB, mas maliit kaysa sa sarili nitong weights, dahil pinipigilan ng grouped query attention na lumaki nang halos kasingbilis ng parameter count ang gastos bawat token.

Ang default context length ng Ollama ay 4096 token sa server na CPU lamang. Kapag may GPU, pinipili nito ang default batay sa VRAM: 32k sa pagitan ng 24 at 48 GiB, at 256k sa 48 GiB pataas. Itaas ito gamit ang OLLAMA_CONTEXT_LENGTH variable sa server, at pagkatapos ay tingnan kung ano talaga ang nakuha ng tumatakbong model sa column na CONTEXT ng ollama ps. Ipinaliwanag ang memory arithmetic sa likod ng setting na ito sa post tungkol sa num_ctx at context length.

May dalawang paraan para mabawasan muli ang cache. Humiling ng context na kailangan mo sa halip na gamitin ang context na ipinapakita sa model card, dahil karamihan ng chat at coding work ay kasya sa 8k hanggang 32k. O i-quantise ang cache mismo sa 8 bits. Kalahati ang magiging laki nito, kapalit ng kaunting pagbaba sa recall sa mahahabang context.

May resident model na nananatili sa RAM hanggang may mag-unload dito

Pinananatili ng Ollama sa memory ang isang model sa loob ng 5 minuto matapos ang huling request, saka ito inaalis sa memory. Ang default na ito ay angkop sa laptop pero hindi sa server, kung saan muling binabayaran ng unang request pagkatapos ng bawat idle period ang oras ng pag-load.

ollama ps
ollama stop qwen3:4b

Ipinapakita ng ollama ps kung ano ang mga resident model. May column itong SIZE na nagpapakita kung gaano karaming memory ang ginagamit nito, at column na UNTIL na nagpapakita kung kailan ito mag-e-expire. Para permanenteng panatilihin ang isang model sa memory, itakda ang OLLAMA_KEEP_ALIVE=-1 sa service. Aalisin ito sa memory agad matapos ang bawat response kapag ang value ay 0.

sudo systemctl edit ollama.service

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

sudo systemctl daemon-reload
sudo systemctl restart ollama

Magpadala ng isang prompt, pagkatapos ay patakbuhin muli ang ollama ps makalipas ang 10 minuto. Nakalista pa rin ang model, at iyon mismo ang punto: ginagamit nito ang RAM na iyon gumagamit man nito o hindi. Ang pinned model ay hindi ekstrang capacity. Sa isang 16 GB VPS, ang isang 8B na may 8k context ay kumokonsumo ng humigit-kumulang 6 GB habang tumatakbo ang service. Kaya i-size ang server batay sa model at sa application mo, hindi sa model lang. Ipinaliliwanag ng Pagpapanatili ng model sa memory ang trade-off nito kumpara sa cold start latency.

Ano ang maaaring patakbuhin sa 4 GB VPS

Maglaan ng humigit-kumulang 1 GB para sa operating system at model server, kaya mga 3 GB ang matitira. Sapat ito para sa 1B hanggang 4B na model sa 4 bits, gamit ang default na 4096 token context. Noong August 2026, kabilang sa kategoryang ito ang Llama 3.2 na 3B, Qwen 3 na 1.7B at 4B, at ang maliliit na release ng Gemma at Phi. Gamitin ang mga ito bilang mga halimbawa ng laki, hindi bilang mga rekomendasyon. Nagbabago ang mga pangalan ng model kada ilang buwan, pero hindi nagbabago ang arithmetic.

Asahan ang humigit-kumulang 6 hanggang 14 token bawat segundo. Mahusay ang ganitong kaliit na mga model sa limitadong gawain: classification, pagkuha ng tag, maiikling buod, at pag-rewrite ng isang paragraph ayon sa house style. Mahina ang mga ito sa multi-step reasoning at sa code na sumasaklaw sa ilang file. Walang prompting na makapaglulutas sa limitasyong iyon.

Swap ang karaniwang sanhi ng failure sa tier na ito. Kung hindi kasya ang model, hindi ito tatanggihan ng Linux na i-load. Sa halip, inililipat nito sa disk ang bahagi ng memory. Dahil binabasa ang bawat weight nang isang beses sa pag-generate ng isang token, bumabagal ito hanggang maging ilang segundo bawat token. I-monitor ang free -h at ang mga column na si at so ng vmstat 1 habang sumasagot ang model. Kung may non-zero swap in at swap out habang nagge-generate, masyadong malaki ang model para sa plan.

Ano ang tumatakbo sa 8 hanggang 16 GB VPS

Dito nagiging praktikal sa pangkalahatan ang self-hosted model. Sa 8 GB, maaari kang magpatakbo ng 7B o 8B sa 4 bits, na may humigit-kumulang 4.8 GB na weights, gamit ang 8k context. Sa 16 GB, maaari kang magpatakbo ng 13B o 14B sa 4 bits, na may humigit-kumulang 8.4 GB, o panatilihin ang 8B sa 8 bits kung mas nais mong gamitin ang memory para sa precision kaysa sa dami ng parameter.

Ang kapalit nito ay bilis. Ang 8B sa CPU ay nakakabuo ng humigit-kumulang 3 hanggang 7 tokens bawat segundo, samantalang ang 14B ay nakakabuo ng humigit-kumulang 1.5 hanggang 3.5. Ang tao ay nagbabasa ng humigit-kumulang 5 hanggang 10 tokens bawat segundo, kaya ang 8B sa CPU VPS ay parang nanonood ng mabagal na nagta-type. Ayos ito para sa background job, pero nakakapagod para sa interactive chat. Ipinapakita ng Mga aktuwal na run ng Qwen 3 sa 8B at mas malalaki pang model sa VPS kung ano ang hitsura nito sa aktuwal na paggamit.

Ano ang maaaring patakbuhin sa 32 hanggang 64 GB VPS

Ang 32B sa 4 bits ay humigit-kumulang 19.2 GB, kaya kasya ito sa 32 GB plan kapag maikli ang context at may sapat na espasyo sa 48 GB o 64 GB. Ang 70B sa 4 bits ay humigit-kumulang 42 GB, kaya kailangan nito ng 64 GB bago pa isama ang anumang cache.

Pagkatapos, suriin nang tapat ang bilis. Ang 32B na tumatakbo sa CPU ay umaabot sa humigit-kumulang 0.6 hanggang 1.5 tokens bawat segundo, habang ang 70B ay nasa 0.2 hanggang 0.5. Ang 500-token na sagot mula sa 70B ay tumatagal ng humigit-kumulang dalawampung minuto. Sa ganitong bilis, karaniwang napuputol ang request bago matapos ang model dahil nauunang ma-trigger ang timeout ng client o proxy sa harap ng Ollama. Dito nagmumula ang error na context deadline exceeded. Mga tool ito para sa batch processing. Bigyan ang mga ito ng pila ng mga dokumento na ipoproseso magdamag, at hindi mahalaga ang bilis. Ilagay ang mga ito sa likod ng chat window, at magiging napakahalaga nito.

Binabago ng mixture of experts routing ang kalkulasyong ito, at ito ang isang detalye ng architecture na sulit matutuhan. Sa bawat token, maliit na bahagi lamang ng weights nito ang ginagamit ng isang MoE model. Ang model na may 30B na total parameters at 3B na active parameters bawat token ay nangangailangan ng memory na para sa 30B at bumubuo ng output na halos kasingbilis ng dense 3B, dahil active experts lamang ang binabasa ng bawat token. Sa 32 GB box, mas magagamit ang MoE na ganito ang configuration kaysa sa dense 30B. Ang dapat tandaan: ang total parameters ang nagtatakda ng memory, at ang active parameters ang nagtatakda ng speed.

Gaano kabilis ang CPU inference, sa totoo lang?

Para makabuo ng isang token, kailangang basahin nang isang beses mula sa memory ang bawat aktibong weight. Walang nakalalampas dito, kaya ang bilis ng generation sa CPU ay nakabatay sa memory bandwidth, hindi sa dami ng core. Ang pinakamataas na bilis ay makukuha sa paghahati ng usable memory bandwidth sa laki ng weights sa bytes. Karaniwang naghahatid ang isang maliit na shared VPS ng 10 hanggang 25 GB bawat segundo sa lahat ng vCPU nito, kaya ang 4.8 GB na model ay karaniwang umaabot lamang sa humigit-kumulang 2 hanggang 5 token bawat segundo.

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

Ang mga saklaw na ito ay karaniwang naiuulat sa ordinaryong VPS hardware, hindi benchmark ng isang partikular na machine. Nakadepende ang resulta sa memory generation, bilang ng channel sa host, at dami ng neighbour na nakikipagkumpitensya para sa mga resource nito. Sukatin ang sarili mong resulta gamit ang anumang model tag na mayroon ka na:

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

Ang summary na naka-print pagkatapos matapos ang sagot ay nagtatapos sa linyang eval rate: ... tokens/s. Iyon ang generation speed mo. Huwag isama ang unang run ng isang session, dahil kasama sa load duration sa parehong summary ang oras ng pagbasa ng weights mula sa disk. Ipinapaliwanag ng Tamang pagsukat ng tokens bawat segundo kung paano kumuha ng numerong makabuluhan para sa paghahambing.

May 2 resultang nakakagulat para sa maraming tao. Mabilis na nawawalan ng pakinabang ang pagdaragdag ng vCPU, dahil pag lampas sa humigit-kumulang 8 core, naghihintay na lamang ang mga karagdagang core sa memory sa halip na magsagawa ng computation. Sa shared plan naman, magkakaiba ang resultang ibinabalik ng parehong command bawat oras. CPU steal time iyon mula sa maingay na neighbour, hindi problema sa configuration na ikaw ang nagdulot.

Ibang gawain ang pagbasa sa prompt kumpara sa pagbuo ng sagot. Compute-bound ang prompt processing, kaya uma-scale ito sa dami ng core. Dito rin pinakamalaki ang lamang ng GPU. Inaabot ng ilang minuto sa CPU ang pagbasa sa isang mahabang dokumento, samantalang ilang segundo lamang sa GPU. Ito ang unang bottleneck na mararanasan mo kapag itinutok ang coding agent sa model na ikaw ang nagho-host, dahil sa bawat turn ay muling ipinapadala ang file context at mga tool definition bago pa bumalik ang kahit isang token ng sagot.

Ano ang nagbabago kapag nagdagdag ka ng GPU

Hindi nagbabago ang arithmetic. Nagbabago lamang ang pool na pinag-aaplayan nito. Hard limit ang VRAM, kaya tukuyin muna kung ano ang kasya bago ka mag-rent:

• Ang 8 GB na VRAM ay kasya para sa 7B o 8B sa 4 bits na may maikling context.
• Ang 16 GB ay kasya para sa 14B sa 4 bits na may aktuwal na context, o 8B sa 8 bits.
• Ang 24 GB ay kasya para sa 32B sa 4 bits kapag maikli ang context.
• Ang 48 GB pataas ay kasya para sa 70B sa 4 bits, na may espasyo para sa cache at concurrency.

Kapag hindi kasya ang isang model, hinahati ito ng Ollama: nasa GPU ang ilang layer, at nasa CPU ang natitira. Iniuulat ng ollama ps ang hatian sa column nitong PROCESSOR, na maaaring lumabas bilang 78%/22% CPU/GPU. Ituring ito bilang babala, hindi bilang feature. Ang CPU half ang nagtatakda ng bilis, dahil naghihintay pa rin ang bawat token sa mga layer na iyon. Kaya ang model na may isang-kapat ng mga layer sa CPU ay mas malapit sa CPU speed kaysa sa GPU speed. Kung may split na hindi mo sinadya, ibaba muna ang context length. Karaniwang ang cache ang dahilan kung bakit lumampas ito sa kapasidad.

Ang concurrency ang isa pang dahilan para pumili ng mas malaking kapasidad. Ibinabahagi ng sabay-sabay na request ang weights, ngunit kailangan ng bawat aktibong request ng sarili nitong KV cache. Kaya ang sampung concurrent user ng 8B sa 8k context ay nangangailangan ng sampung beses na 1 GB na cache, bukod pa sa weights. Ipinapakita ng Paghahatid sa sabay-sabay na user mula sa isang self-hosted model kung saan pumapalo ang limitasyong iyon.

Arithmetic din ang tanong kung sulit bang mag-rent ng GPU. Nakadepende ito sa aktuwal na dami ng token na nagagawa mo bawat buwan. Nasa Pagtukoy sa break-even sa pagitan ng GPU VPS at API token ang mga numerong iyon.

Mga hindi mo maaaring i-self-host

May dalawang magkaibang limitasyon dito. Mahalagang malaman kung alin sa mga ito ang kinakaharap mo.

Ang una ay ang mga closed weight. Hindi ipinamamahagi ang mga frontier commercial model, kaya walang file na mada-download at walang dami ng RAM na makapagbabago nito. Maaari mong i-self-host ang lahat ng nakapaligid sa mga ito: ang interface, retrieval layer, agent loop, at logs. Mananatiling remote API ang mismong model. Tinalakay nang buo sa Kung maaari mong i-self-host ang Claude ang usaping ito.

Ang ikalawa ay ang mga open weight na napakalaki. Ang pinakamalalaking open release ay mga mixture-of-experts design na may daan-daang bilyong kabuuang parameter. Pareho ang tuntunin para sa mga ito: ang 400B total parameter model sa 4 bits ay nangangailangan ng humigit-kumulang 240 GB para sa weights lamang, bago pa isama ang anumang cache. Kailangan nito ng specialist hardware, at ang buwanang renta nito ay mas mahal kaysa sa karaniwang ginagastos ng karamihan sa API tokens sa loob ng isang taon. Ipinapaliwanag sa Mga kailangan para i-self-host ang isang Kimi class model ang aktuwal na requirement. Makikita rin ang parehong paghahati sa library mismo ng Ollama, kung saan cloud model lamang ang GLM 5.2 at ang mas maliit nitong sibling ang aktuwal na mada-download sa isang VPS.

Ito ang tapat na hangganan sa pagitan ng dalawa: mag-self-host kapag steady ang load at hindi dapat lumabas sa server mo ang data. Bumili ng tokens kapag bursty ang load, o kapag frontier answer quality ang mismong kailangan mo.

Suriin muna ang mayroon ka bago pumili

free -h
nproc
lscpu | grep 'Model name'

Magplano batay sa column na available ng free -h, hindi sa column na total, dahil kasama sa total ang memory na ginagamit na ng system. Magbawas ng humigit-kumulang 1 GB para sa operating system at model server. Hatiin sa 0.6 ang natitira upang makuha ang pinakamalaking parameter count sa bilyon na kaya mong patakbuhin sa 4 bits. Pagkatapos, ibawas ang KV cache para sa context na aktuwal mong kailangan. Ang matitira ang sagot mo. Hindi ito madaling mawalan ng bisa, hindi tulad ng listahan ng mga pangalan ng model.

FAQ

Ilang RAM ang kailangan para magpatakbo ng 8B model?

Humigit-kumulang 4.8 GB para sa weights sa 4-bit quantisation, dagdag ang KV cache para sa haba ng iyong context, at humigit-kumulang 1 GB para sa operating system at model server. Sa 8192-token context, nagdadagdag ang cache ng humigit-kumulang 1 GB, kaya sapat ang 8 GB plan ngunit hindi sapat ang 4 GB plan. Kung gagamitin mo ang buong 128k context na ina-advertise sa model card, 16 GB ang kailangan ng cache lamang, kaya 32 GB plan ang kailangan mo.

Bakit mabagal ang model ko kahit maraming vCPU ang VPS?

Dahil memory bandwidth, hindi mga core, ang naglilimita sa generation. Sa bawat token, kailangang kunin mula sa RAM ang buong active weight set. Kapag ilang core na ang gumagamit sa memory channels hanggang sa limitasyon, naghihintay na lamang ang iba. Ang isa pang karaniwang sanhi ay swap. Kung ipinapakita ng vmstat 1 ang non-zero na si at so habang sumasagot ang model, hindi kasya sa RAM ang weights. Dahil dito, bahagi ng bawat token ay kinukuha mula sa disk, na mas mabagal kaysa sa inaasahan.

Kailangan ba talaga ng mas maraming memory ang mas mahabang context window?

Oo, at linear ang paglaki nito batay sa bilang ng token. Karaniwang gumagamit ang isang 8B model ng humigit-kumulang 128 KiB na KV cache bawat token. Kaya 1 GB ang kailangan para sa 8192 token, at 16 GB para sa 131072 token. Inilalaan ang cache kapag nilo-load ang model, hindi kapag lumalaki ang conversation. Kaya kapag humingi ka ng 128k context, agad na nirereserba ang memory na iyon kahit 200 token lamang ang haba ng bawat prompt na ipinapadala mo.

Dapat ba akong magpatakbo ng malaking model sa 2 bits o ng mas maliit na model sa 4 bits?

Piliin ang mas maliit na model sa 4 bits. Mabagal ang pagbaba ng quality mula 8 bits hanggang 4 bits, ngunit mabilis ito kapag mas mababa sa 4 bits. Kaya karaniwang mas mahina ang mga sagot ng 70B model na pinisil sa 2 bits kaysa sa 32B model sa 4 bits mula sa parehong model generation. Lumalabas ang epekto ng heavy quantisation bilang pag-uulit at hindi pagsunod sa mga instruction, sa halip na error message. Dahil dito, madaling isipin na prompt ang problema. Ituring ang 4 bits bilang pinakamababang praktikal na setting, at baguhin ang parameter count sa halip.

Maaari ba akong mag-self-host ng model na kasinghusay ng malalaking commercial model?

Hindi sa karaniwang VPS. Umaabot sa daan-daang bilyon ang parameter count ng pinakamalalakas na open-weight model. Sa 4 bits, nangangailangan ang mga ito ng mahigit 200 GB na RAM bago pa idagdag ang KV cache. Hindi naman talaga ipinapamahagi ang pinakamalalakas na commercial model. Ang kayang gawin nang maayos ng karaniwang hardware ay magpatakbo ng mahusay na 8B hanggang 32B model para sa isang partikular na gawain. Para sa isang makitid na gamit at maayos na prompt, madalas na kayang tumapat ng maliit na model sa isang general-purpose model. Kung kailangan mo ng frontier quality, ikumpara muna ang halaga ng API sa hardware bago bumili ng alinman sa mga ito.