Kailangan Mo Ba ng VPS na May GPU?

Kailangan mo ba ng VPS na may GPU, o sapat na ang CPU?

Binabago ng VPS na may GPU ang 2 bagay sa pagpapatakbo ng sarili mong model: kung gaano kabilis lumalabas ang mga token, at kung gaano kalaking model ang kasya sa memory. Wala na itong ibang binabago. Kung ang workload mo ay isang quantized 7B hanggang 27B chat model na sumasagot sa isang tao bawat pagkakataon, isang embedding job na mababa ang volume, o speech transcription gamit ang Whisper small, sapat na para sa trabaho ang ordinaryong CPU VPS na may sapat na RAM. Magsimula sa CPU, sukatin ang numerong nakakaabala sa iyo, saka mag-upgrade.

Ang dahilan ay memory bandwidth. Kapag bumubuo ng isang token ang language model, binabasa nito mula sa memory ang lahat ng weight na kailangan nito. Ang 8B model na na-quantize sa 4 bits ay humigit-kumulang 4.7 GB sa disk at halos ganoon din kalaki sa memory, kaya ang pagbuo ng isang token ay nangangahulugang paglilipat ng humigit-kumulang 4.7 GB. Hatiin ang memory bandwidth ng machine sa numerong iyon at makukuha mo ang maximum na tokens per second. Ipinapaliwanag ng simpleng dibisyong iyon ang halos lahat ng benchmark na mababasa mo.

Ano talaga ang naibibigay ng GPU

Bandwidth. Ang server DDR5 sa modernong host ay nakakapaglipat ng sampu-sampung gigabytes bawat segundo. Ang GPU memory (VRAM, video RAM) ay nakakapaglipat ng daan-daan hanggang mahigit isang libo. Ang ratio na ito ang speedup, at malaki ito.

Capacity na may bilis. Kayang i-load ng CPU box na may 64 GB RAM ang 70B model sa 4 bits. Tatakbo ito sa bilis na mas malapit sa pagbabasa kaysa pakikipag-chat. Makakatulong lamang ang GPU kung kasya ang model sa VRAM, dahil kapag napunta ang ilang layer sa system RAM, ang mabagal na path na ang muling gagamitin.

Batch throughput. Ito ang bahaging madalas minamaliit ng mga tao. Kapag para sa isang user lamang bumubuo ng output ang GPU, malaking bahagi ng compute nito ang idle dahil naghihintay ito sa memory. Kapag sabay-sabay na nagsilbi ng 20 request, ang parehong pagbasa ng weights ay nagagamit para sa lahat ng 20. Tataas nang ilang ulit ang aggregate tokens per second, habang bahagya lamang babagal ang bilis para sa bawat user. Hindi ito nagagawa ng CPU. Sa CPU box, karaniwang hinahati ng dalawang concurrent user ang bilis ng isa’t isa. Kung gumagawa ka ng API na ginagamit ng maraming client, batching ang pangunahing dahilan para gumamit ng GPU, higit pa sa raw single-stream speed.

Pagproseso ng prompt. Ang pagbasa ng mahabang prompt ay compute-bound, hindi memory-bound, at dito pinakamalaki ang lamang ng GPU. Ang 30,000-token context na inaabot ng isang minuto para iproseso ng CPU ay ilang segundo lamang sa GPU. Palagi itong mapapansin sa mga retrieval setup na nagsasama ng mga dokumento sa bawat request.

Tinatayang mga numero, at kung paano basahin ang mga ito

Naglalaman ang block sa ibaba ng karaniwang nailalathalang single-stream figures para sa isang 8B model na may 4-bit quantization, mula noong July 2026. Tinatayang gabay lamang ang mga ito batay sa order of magnitude, hindi pangako. Maaapektuhan ang mga ito ng iyong quantization, context length, at inference engine.

[
  {
    "label": "8 vCPU, DDR4",
    "mem_bandwidth_gbs": 40,
    "tokens_per_sec": 6
  },
  {
    "label": "16 vCPU, DDR5",
    "mem_bandwidth_gbs": 75,
    "tokens_per_sec": 11
  },
  {
    "label": "24GB GPU",
    "mem_bandwidth_gbs": 300,
    "tokens_per_sec": 50
  },
  {
    "label": "40GB data-centre GPU",
    "mem_bandwidth_gbs": 1555,
    "tokens_per_sec": 130
  }
]

Ipinapakita ng row para sa 24 GB GPU ang 50 tokens per second, kumpara sa 11 para sa isang DDR5 CPU box. Tinatayang limang beses ito, na tumutugma sa ratio ng bandwidth at hindi sa anumang pagkakaiba sa raw compute. Sa aktuwal, mas mababa rin ang throughput kaysa sa bandwidth na hinati sa model size, dahil nagdaragdag ng trabaho ang attention habang lumalaki ang context, na hindi isinasaalang-alang ng simpleng paghahating iyon.

Bilang paghahambing, nagbabasa ang isang tao ng humigit-kumulang 5 hanggang 10 salita bawat segundo. Anumang nasa 15 tokens per second o higit pa ay nararamdaman nang parang normal na pagta-type para sa isang reader. Kaya maraming CPU-only setup ang sapat na sa aktuwal na paggamit.

Bago bumili, tantiyahin ang kinakailangang VRAM

Ang laki ng model file ang panimulang halaga lamang, hindi ang kabuuang kinakailangan. Maglaan para sa weights, KV cache (key-value cache, ang per-token memory na pinananatili ng attention), at humigit-kumulang 1 GB para sa overhead.

Praktikal na tuntunin hanggang Hulyo 2026: kunin ang laki ng model file sa gigabytes at magdagdag ng 20 porsiyento para sa karaniwang 8k hanggang 16k na context. Ang 4.7 GB na 8B model ay nangangailangan ng humigit-kumulang 6 GB na VRAM. Ang 27B model na nasa 4 bits ay nasa 16 GB at nangangailangan ng humigit-kumulang 20 GB. Ang 70B na nasa 4 bits ay nasa 40 GB at nangangailangan ng 48 GB na card, o dalawang mas maliit na card. Gumagana pa rin ang parehong kalkulasyon sa mas malalaking model, at ipinapakita ng kalkulasyon ng VRAM para sa 2.8 trilyong parameter na model gaya ng Kimi K3 kung kailan hindi na pagpili ng card ang pangunahing tanong.

Hindi akma ang tuntuning ito sa mahahabang context. Lumalaki nang linear ang KV cache batay sa haba ng context, at sa 128k tokens maaari nitong malampasan mismo ang weights. Kung plano mong gumamit ng mahahabang context, unahin ang pagtantya sa cache at tingnan kung anong mga opsyon para sa cache quantization ang iniaalok ng iyong engine.

Suriin kung ano talaga ang mayroon ang machine

Sa isang GPU instance, tiyaking nakikita ng driver ang card bago gawin ang iba pa.

nvidia-smi

Dapat magpakita ang output ng table na naglilista ng pangalan ng GPU, bersyon ng driver, at memory na ginagamit kumpara sa kabuuang memory. Ibig sabihin ng NVIDIA-SMI has failed because it couldn't communicate with the NVIDIA driver ay nawawala ang driver, o hindi na-rebuild ang kernel module matapos ang kernel upgrade. Sa stock Ubuntu image, karaniwang ang solusyon ay sudo apt install -y ubuntu-drivers-common && sudo ubuntu-drivers install, pagkatapos ay mag-reboot para ma-load ang bagong module.

Para sa mga container, hindi sapat ang driver lamang. Kailangan ng Docker ang NVIDIA Container Toolkit para maipasa ang device sa container.

sudo apt-get update && sudo apt-get install -y --no-install-recommends ca-certificates curl gnupg2
curl -fsSL https://nvidia.github.io/libnvidia-container/gpgkey | sudo gpg --dearmor -o /usr/share/keyrings/nvidia-container-toolkit-keyring.gpg
curl -s -L https://nvidia.github.io/libnvidia-container/stable/deb/nvidia-container-toolkit.list | sed 's#deb https://#deb [signed-by=/usr/share/keyrings/nvidia-container-toolkit-keyring.gpg] https://#g' | sudo tee /etc/apt/sources.list.d/nvidia-container-toolkit.list
sudo apt-get update && sudo apt-get install -y nvidia-container-toolkit
sudo nvidia-ctk runtime configure --runtime=docker
sudo systemctl restart docker

Pagkatapos, patunayan mula sa loob ng container na gumagana ang passthrough:

sudo docker run --rm --gpus all ubuntu:24.04 nvidia-smi

Dapat lumitaw ang parehong table. Ang linyang docker: Error response from daemon: could not select device driver, na tumutukoy sa gpu capability na hindi nito matugunan, ay nangangahulugang naka-install ang toolkit ngunit hindi muling na-configure o na-restart ang Docker. Kaya muling patakbuhin ang linyang nvidia-ctk at ang restart. Sa Compose, ang katumbas nito ay isang deploy.resources.reservations.devices entry na ang driver nito ay nvidia at ang capabilities list nito ay naglalaman ng gpu. Maaari itong idagdag sa karaniwang service definitions na saklaw sa Docker Compose sa isang VPS.

Sukatin muna bago mag-upgrade

Patakbuhin ang model na talagang gagamitin mo sa kasalukuyan mong CPU box, at itala ang mga resulta. Sa pagse-self-host ng LLM gamit ang Ollama sa isang VPS, isang flag lang ang kailangan:

ollama run llama3.1:8b --verbose "Summarise the causes of the 1929 crash in 200 words."

Nagtatapos ang output sa mga timing. Ang eval rate ang bilis ng generation mo sa tokens per second. Ang prompt eval rate ang bilis ng machine sa pagbasa ng input mo. Ipinapakita ng dalawang numerong ito kung aling upgrade ang makatutulong: ang mababang eval rate ay problema sa memory bandwidth, habang ang mababang prompt eval rate sa mahahabang input ay problema sa compute.

Sa machine na may GPU, tiyaking dito talaga nailagay ang model:

ollama ps

Ang column na PROCESSOR ay naglalaman ng 100% GPU kapag kasya ang lahat, o ng tulad ng 43%/57% CPU/GPU kapag hindi ito kasya. Karaniwang mas mabagal kaysa inaasahan ang partial split, dahil naghihintay pa rin ang bawat token sa mas mabagal na bahagi.

Ang usapin ng gastos

Mas mahal nang ilang ulit ang GPU instances kaysa sa katumbas na CPU instance, at sinisingil ang mga ito sa bawat oras na umiiral ang instance, hindi batay sa bilang ng token na nagagawa nito. Ang GPU na laging naka-on pero kakaunti lamang ang request bawat araw ang pinakamahal na paraan ng inference. Ang break-even ay nakabatay sa utilisation: mura bawat token ang busy na GPU, habang purong aksaya ang idle na GPU.

Tatlong praktikal na pattern ang gumagana. Panatilihin sa CPU VPS ang tuloy-tuloy pero kaunting workload. Ipadala ang paminsan-minsang mahirap na request sa hosted API at magbayad batay sa token. Mag-rent ng GPU kada oras para sa batch jobs, fine-tuning, o maramihang embedding run, pagkatapos ay i-destroy ito. Karaniwan lang ang pagsasama ng mga paraang ito, at naaangkop din dito ang budgeting discipline na inilalarawan sa Pagkontrol sa gastos ng AI agent sa isang VPS na laging naka-on, ngunit ang kaibahan ay idle time, hindi bilang ng token, ang nagiging tagas ng gastos.

Ano pa rin ang maayos na tumatakbo kahit walang GPU

Embeddings sa mababang volume. Kayang magproseso ng maliit na embedding model ng daan-daang maiikling dokumento bawat minuto gamit ang ilang CPU core, at hindi kailangang mabilis ang index na isang beses mo lang bubuuin.

Whisper small at base para sa transcription. Sa CPU, ang faster-whisper ay nakakapag-transcribe nang halos real time gamit ang small model. Sapat na ito para sa pipeline na tumatakbo magdamag.

Mga quantized chat model hanggang humigit-kumulang 27B, para sa isa o dalawang user. Mabagal, pero nababasa at nagagamit.

Anumang maituturing mong batch job. Kung walang tumitingin sa screen, detalye lang ng scheduling ang wall-clock speed at hindi ito requirement.

Ang talagang nangangailangan ng GPU ay training o fine-tuning na lampas sa maliit na adapter, pag-serve sa maraming concurrent user, image at video generation, at real-time speech kung latency ang pangunahing requirement.

FAQ

Gaano karaming VRAM ang kailangan ko para sa 7B o 8B na model?

Humigit-kumulang 6 GB para sa 4-bit quantized na 8B model sa karaniwang 8k hanggang 16k na context. Tinatayang 4.7 GB ang weights, at ang natitira ay para sa KV cache at humigit-kumulang 1 GB na overhead. Nag-iiwan ang 12 GB card ng sapat na espasyo para sa mas mahahabang context. Kung plano mong gumamit ng 128k context, hiwalay na maglaan para sa cache dahil maaari itong lumaki nang higit pa sa laki ng weights.

Maaari ko bang patakbuhin ang Ollama nang walang GPU?

Oo. Awtomatikong nagfa-fallback ang Ollama sa CPU at kailangan lamang nito ng sapat na RAM para maglaman ng model. Asahan ang humigit-kumulang 5 hanggang 12 tokens bawat segundo para sa 4-bit na 8B model, depende sa memory speed. Malapit ito sa bilis ng pagbabasa para sa isang user. Ang mahahabang prompt ang pangunahing problema sa CPU dahil compute-bound ang pagbasa ng 30,000 tokens na context at mas matagal ito kaysa sa pag-generate ng reply.

Bakit halos hindi mas mabilis ang GPU ko kaysa sa CPU?

Karaniwang sanhi nito na hindi ganap na nagkasya ang model sa VRAM. Dahil dito, may ilang layer na tumatakbo sa CPU at naghihintay ang bawat token sa mas mabagal na bahagi. Patakbuhin ang ollama ps at tingnan kung ang column na PROCESSOR ay may nakasulat na 100% GPU. Kung may ipinapakitang split, gumamit ng mas maliit na quantization o mas maliit na model. Ang isa pang karaniwang sanhi ay maikling benchmark kung saan nangingibabaw sa sukat ang oras ng pag-load ng model.

Sulit ba ang GPU VPS para sa isang user?

Karaniwan, hindi. Ang isang tao ay nagbabasa ng 5 hanggang 10 salita bawat segundo, at ang CPU box ay nakakagawa na ng mga token nang mas mabilis kaysa rito para sa mga model na hanggang humigit-kumulang 13B. Ang mga sitwasyong maaaring magbigay-katwiran sa gastos para sa isang user ay mahahabang prompt, image generation, at fine-tuning. Ang sabay-sabay na pag-serve sa maraming user ang pinakamalakas na dahilan, dahil sa batching ay makasasagot ang isang GPU sa dalawampung request na halos kapantay ng gastos sa pagsagot sa isang request.

Dapat ba akong mag-rent ng GPU kada oras o patakbuhin ito palagi?

Mag-rent kada oras kapag pabugso-bugso ang workload: fine-tuning, bulk embedding run, o batch transcription job. Patakbuhin lamang ito palagi kapag palaging ginagamit ang card, dahil naniningil ang GPU instance batay sa oras na nakaandar ito, hindi sa dami ng nalilikhang token. Mas mura para sa low-traffic assistant ang CPU VPS o hosted API na per-token ang bayad kaysa sa idle na GPU.