Anong AI models ang puwedeng i-self-host?

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

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

Dalawang gastos ang nagpapasya sa sagot. Ang weights ang fixed cost na itinatalaga ng 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

Ang model file ay halos puro weights. Ang bawat weight ay sine-store gamit ang partikular na bilang ng bits. Ang quantisation ay pagse-store ng mga ito gamit ang mas kaunting bits kaysa sa precision na ginamit sa training. Kaunti ang kapalit na 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

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

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

Gamitin ang 0.6 GB bawat isang bilyong parameter bilang working number. Ang Q4_K_M ang praktikal na default sa isang box na limitado ang memory: maliit ang quality loss kumpara sa 8 bits sa karamihan ng mga task, at halos kalahati ang laki ng file. Kapag bumaba sa 4 bits, mabilis lumalaki ang loss. Kaya karaniwang mas mahinang sumagot ang isang 70B na isiniksik sa 2 bits kaysa sa isang 32B na nasa 4 bits mula sa parehong generation. Kapag kapos ang memory, bumaba muna ng isang size class bago gumamit ng mas mababa sa 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 resulta ng paglalapat ng 0.6 GB bawat isang bilyong parameter na rule. Karaniwang nasa loob ng ilang porsiyento nito ang aktuwal na GGUF files, dahil sine-store ang embedding at output layers sa mas mataas na precision kaysa sa ibang bahagi. Ang isang 3B model sa 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.

Mas malaki ang RAM na ginagastos ng context length kaysa sa weights

Ang KV cache (key value cache, ang attention state na iniingatan ng model para sa bawat token na kasalukuyang nasa conversation) ang ikalawang gastos. Inilalaan ito kapag nilo-load ang model, at sine-size batay sa context length na hiniling mo. Tuwiran itong lumalaki kasabay ng context length.

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, gumagamit ito ng 1 GB. Sa 128k context na nakasaad sa model card nito, gumagamit ito ng 16 GB. Mas malaki ito nang mahigit tatlong beses kaysa sa 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 per-token cost.

Ang default context length ng Ollama ay 4096 token sa CPU-only server. 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. Pagkatapos, tingnan kung ano talaga ang natanggap ng tumatakbong model sa CONTEXT column ng ollama ps. Ipinaliliwanag nang detalyado sa post tungkol sa num_ctx at context length ang memory arithmetic sa likod ng setting na ito.

May dalawang paraan para mabawasan ang cache. Hingin lamang ang context na kailangan mo, sa halip na ang context na nakasaad 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. Hahatiin nito sa kalahati ang laki nito, kapalit ng kaunting pagbaba sa long-context recall.

Ang resident model ay nananatili sa RAM hanggang sa i-unload ito

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

ollama ps
ollama stop qwen3:4b

Ipinapakita ng ollama ps kung aling mga model ang resident, kasama ang column na SIZE para sa dami ng memory na ginagamit nito at column na UNTIL para sa oras ng expiration nito. Para permanenteng i-pin ang isang model, itakda ang OLLAMA_KEEP_ALIVE=-1 sa service. Ang value na 0 ay nag-u-unload dito agad matapos ang bawat response.

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 sampung minuto. Nasa listahan pa rin ang model, at iyon mismo ang punto: hawak nito ang RAM na iyon gumagamit man nito o hindi. Ang naka-pin na model ay hindi ekstrang capacity. Sa isang 16 GB VPS, ang isang 8B na may 8k context ay gumagamit ng humigit-kumulang 6 GB habang tumatakbo ang service, kaya i-size ang server batay sa model kasama ng application mo, hindi sa model lamang. Tinalakay sa Pag-pin ng model sa memory ang trade-off nito laban sa cold start latency.

Ano ang kayang patakbuhin sa isang 4 GB VPS

Maglaan ng humigit-kumulang 1 GB para sa operating system at model server, kaya mga 3 GB ang matitira. Katumbas ito ng 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 bawat 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 mga 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, at walang prompting na makapaglulutas nito.

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

Ano ang tumatakbo sa 8 hanggang 16 GB VPS

Dito nagiging kapaki-pakinabang 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 ang bilis. Ang 8B sa CPU ay nakakagawa ng humigit-kumulang 3 hanggang 7 token bawat segundo, samantalang ang 14B ay humigit-kumulang 1.5 hanggang 3.5. Ang isang tao ay nagbabasa nang nasa 5 hanggang 10 token bawat segundo, kaya parang nanonood ka ng mabagal mag-type kapag 8B ang tumatakbo sa isang CPU VPS. Ayos ito para sa background job, pero nakakapagod para sa interactive chat. Ipinapakita ng Mga nasukat na run ng Qwen 3 sa 8B at mas malalaking modelo sa isang VPS kung ano ang aktuwal na itsura nito.

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 komportable itong tumatakbo sa 48 GB o 64 GB. Ang 70B sa 4 bits ay humigit-kumulang 42 GB, kaya kailangan nito ng 64 GB bago pa maglaan ng memory para sa cache.

Pagkatapos, suriin nang makatotohanan ang speed. Ang 32B na tumatakbo sa CPU ay umaabot sa humigit-kumulang 0.6 hanggang 1.5 tokens bawat segundo, habang ang 70B ay umaabot sa 0.2 hanggang 0.5. Ang 500-token na sagot mula sa 70B na iyon ay tumatagal ng humigit-kumulang 20 minuto. Mga batch tool ang mga ito. Kung papadalhan mo sila ng pila ng mga document magdamag, hindi mahalaga ang speed. Kung ilalagay mo sila sa likod ng chat window, napakahalaga nito.

Binabago ng mixture of experts routing ang kalkulasyong ito, at ito ang isang architectural detail na sulit matutuhan. Ipinapadaan ng MoE model ang bawat token sa maliit na bahagi lamang ng weights nito. Ang model na may 30B total parameters at 3B active parameters bawat token ay nangangailangan ng memory na katumbas ng 30B at bumubuo ng output nang halos kasingbilis ng dense 3B, dahil binabasa lamang ng bawat token ang active experts. Sa 32 GB box, mas magagamit ang ganitong MoE 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 aktuwal?

Kailangang basahin nang isang beses mula sa memory ang bawat aktibong weight para makabuo ng isang token. Walang makakaiwas 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 ayon sa byte. Karaniwang nakapagbibigay 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 umaabot 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 ito ay karaniwang range na iniuulat sa ordinaryong VPS hardware, hindi benchmark ng isang partikular na machine. Nakadepende ang resulta sa memory generation, dami ng channel sa host, at dami ng neighbour na gumagamit nito. Sukatin ang sarili mong resulta gamit ang kahit anong model tag na mayroon ka na:

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

Ang summary na lumalabas pagkatapos ng sagot ay nagtatapos sa linyang eval rate: ... tokens/s. Iyan ang generation speed. Huwag isama ang unang run ng session, dahil kasama sa load duration sa parehong summary ang pagbasa ng weights mula sa disk. Saklaw ng Tamang pagsukat ng tokens bawat segundo kung paano kumuha ng numerong makabuluhang ikumpara.

May dalawang resulta rito na nakakagulat para sa maraming tao. Mabilis na tumitigil ang pakinabang ng pagdaragdag ng vCPU, dahil pag lampas sa humigit-kumulang 8 core, naghihintay na lang ang mga dagdag na core sa memory sa halip na magsagawa ng arithmetic. Sa shared plan naman, maaaring magbalik ng magkakaibang resulta ang parehong command kada oras. Ito ay CPU steal time mula sa maingay na neighbour, hindi maling configuration na ginawa mo.

Iba ang pagbasa sa prompt mo kaysa sa pag-generate ng sagot. Compute-bound ang prompt processing, kaya nakikinabang ito sa mas maraming core. Dito pinakamalaki ang lamang ng GPU. Inaabot ng ilang minuto sa CPU ang pagbasa ng mahabang dokumento, samantalang ilang segundo lang sa GPU.

Ano ang nagbabago kapag nagdagdag ka ng GPU

Hindi nagbabago ang arithmetic; ang pool lang na pinagmumulan nito ang nagbabago. Hard limit ang VRAM, kaya alamin muna kung ano ang kasya bago ka mag-rent:

• Kayang i-hold ng 8 GB na VRAM ang 7B o 8B sa 4 bits na may maikling context.
• Kayang i-hold ng 16 GB ang 14B sa 4 bits na may sapat na context, o 8B sa 8 bits.
• Kayang i-hold ng 24 GB ang 32B sa 4 bits kapag maikli ang context.
• Kayang i-hold ng 48 GB pataas ang 70B sa 4 bits, na may espasyo para sa cache at concurrency.

Kapag hindi kasya ang isang model, hinahati ito ng Ollama: may ilang layer sa GPU at ang natitira ay sa CPU. Iniuulat ng ollama ps ang hati sa column nitong PROCESSOR, gaya ng 78%/22% CPU/GPU. Ituring ito bilang babala, hindi bilang feature. Ang bahagi sa CPU ang nagtatakda ng bilis, dahil kailangan pa ring hintayin ng bawat token ang mga layer na iyon. Kaya ang model na may isang-kapat ng mga layer sa CPU ay tatakbo nang mas malapit sa CPU speed kaysa sa GPU speed. Kung may nakikita kang split na hindi mo sinadya, ibaba muna ang context length. Karaniwang cache ang dahilan kung bakit lumampas ito sa limit.

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

Arithmetic question din kung sulit bang mag-rent ng GPU. Nakadepende ito sa aktuwal na dami ng token na ginagawa mo bawat buwan. Nasa Break-even sa pagitan ng GPU VPS at API tokens ang mga numerong iyon.

Mga hindi mo maaaring i-self-host

May dalawang magkaibang limitasyon dito, at makatutulong na malaman kung alin ang nararanasan mo.

Ang una ay closed weights. 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 nasa paligid nito: ang interface, retrieval layer, agent loop, at logs. Ang model mismo ay mananatiling remote API. Tinalakay nang buo sa Kung maaari mong i-self-host ang Claude ang puntong ito.

Ang ikalawa ay mga open weights na napakalaki. Ang pinakamalalaking open release ay mga mixture-of-experts design na may daan-daang bilyong total 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 dito ang specialized hardware, at ang buwanang rental nito ay mas mahal kaysa sa karaniwang ginagastos ng karamihan sa API tokens sa loob ng isang taon. Ipinapaliwanag sa Ano ang kailangan para i-self-host ang isang Kimi-class model ang aktuwal na requirement.

Ito ang tapat na pamantayan sa pagitan ng dalawa: mag-self-host kapag steady ang load at hindi dapat umalis sa server mo ang data. Bumili ng tokens kapag bursty ang load, o kapag ang frontier answer quality ang talagang 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 natitirang memory para makuha ang pinakamalaking bilang ng parameter, sa bilyon, na kaya mong patakbuhin sa 4 bits. Pagkatapos, ibawas ang KV cache para sa context na talagang kailangan mo. Ang matitira ang sagot, at hindi ito naluluma gaya 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 gamit ang 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 na context, nagdaragdag 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 ipinapakita sa model card, ang cache pa lamang ay 16 GB na, kaya 32 GB plan ang kailangan mo.

Bakit mabagal ang model ko kahit maraming vCPU ang VPS?

Dahil memory bandwidth, hindi cores, ang naglilimita sa generation. Sa bawat token, kailangang kunin mula sa RAM ang buong active weight set. Kapag napuno na ng ilang core ang memory channels, 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 malaki ang cost kaysa sa inaasahan.

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

Oo, at linear ang paglaki nito ayon sa dami ng token. Karaniwang gumagamit ang 8B model ng humigit-kumulang 128 KiB na KV cache bawat token. Kaya ang 8192 token ay nangangailangan ng 1 GB, habang ang 131072 token ay nangangailangan ng 16 GB. Inilalaan ang cache kapag nag-load ang model, hindi kapag lumalaki ang conversation. Kaya kapag humingi ka ng 128k context, agad na nire-reserve 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 mas maliit na model sa 4 bits?

Piliin ang mas maliit na model sa 4 bits. Dahan-dahang bumababa ang quality mula 8 bits hanggang 4 bits, ngunit mabilis itong bumababa sa mas mababa sa 4 bits. Kaya karaniwang mas mahina ang mga sagot ng 70B na pinisil sa 2 bits kaysa sa 32B na nasa 4 bits mula sa parehong model generation. Lumalabas ang epekto ng heavy quantisation bilang pag-uulit at hindi pagsunod sa mga instruction, hindi bilang error message. Dahil dito, madali itong mapagkamalang problema sa prompt. Ituring ang 4 bits bilang minimum at baguhin na lamang ang parameter count.

Kaya ko bang mag-self-host ng model na kasinghusay ng malalaking commercial model?

Hindi sa ordinaryong VPS. Umaabot sa daan-daang bilyon ang parameters 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 rin ipinamamahagi ang pinakamalalakas na commercial model. Ang karaniwang hardware ay mahusay para sa 8B hanggang 32B model na ginagamit sa isang partikular na gawain. Sa ganitong sitwasyon, maaaring tumapat ang isang maliit na model na may makitid na saklaw at maayos na prompt sa isang general model. Kung kailangan mo ng frontier quality, ikumpara muna ang presyo ng API sa hardware bago bumili ng alinman sa mga ito.