Kailangan Mo Ba ng VPS na May GPU?

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

May dalawang binabago ang VPS na may GPU kapag ikaw mismo ang nagpapatakbo ng model: ang bilis ng paglabas ng mga token, at kung gaano kalaking model ang kasya sa memory. Wala na itong ibang binabago. Kung ang workload mo ay isang quantized na 7B hanggang 27B chat model na sumasagot sa isang tao kada pagkakataon, embedding job na mababa ang volume, o speech transcription gamit ang Whisper small, sapat na para sa trabaho ang karaniwang CPU VPS na may sapat na RAM. Magsimula sa CPU, sukatin ang numerong nakaaabala sa iyo, at saka mag-upgrade kung kinakailangan.

Memory bandwidth ang dahilan. Kapag bumubuo ng isang token ang isang language model, binabasa nito mula sa memory ang lahat ng weight na kailangan nito. Ang 8B model na naka-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 upang makuha ang pinakamataas na posibleng tokens per second. Ipinapaliwanag ng simpleng dibisyong ito ang halos lahat ng benchmark na mababasa mo.

Ano talaga ang naidudulot ng GPU

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

Capacity na may bilis. Maaaring mag-load ang isang CPU box na may 64 GB RAM ng 70B model sa 4 bits. Tatakbo ito sa bilis na mas malapit sa pagbabasa kaysa sa pakikipag-chat. Makakatulong lamang ang GPU dito kung kasya ang model sa VRAM, dahil kapag nailipat ang mga layer sa system RAM, babalik ang mabagal na path.

Batch throughput. Ito ang bahaging madalas minamaliit. Kapag para sa isang user lang nagge-generate ang GPU, karamihan ng compute nito ay idle dahil naghihintay ito sa memory. Kapag sabay na nagsisilbi sa 20 request, ginagamit ng lahat ng 20 ang parehong weight read. Tataas nang ilang ulit ang aggregate tokens per second, habang bahagya lamang bababa ang bilis ng bawat user. Hindi ito nagagawa ng CPU. Sa CPU box, karaniwang pinaghahatian ng dalawang concurrent user ang kapasidad, kaya halos kalahati ang bilis ng bawat isa. Kung gumagawa ka ng API na tinatawagan ng maraming client, ang 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 nararanasan sa mga retrieval setup na nagsasama ng mga dokumento sa bawat request.

Tinatayang mga numero at kung paano basahin ang mga ito

Nasa block sa ibaba ang karaniwang nailathalang single-stream na mga figure para sa isang 8B model na may 4-bit quantization, noong July 2026. Tinatayang gabay lamang ang mga ito ayon sa order of magnitude, hindi garantiya. Magbabago ang mga ito depende sa iyong quantization, haba ng context, 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 naaayon sa ratio ng bandwidth at hindi sa anumang pagkakaiba sa raw compute. Sa aktuwal na paggamit, mas mababa rin ang throughput kaysa sa bandwidth na hinati sa laki ng model, dahil nagdaragdag ng workload ang attention sa lumalaking context na hindi isinasaalang-alang ng simpleng paghahati.

Bilang paghahambing, nagbabasa ang isang tao ng humigit-kumulang 5 hanggang 10 salita bawat segundo. Kapag umabot sa 15 tokens per second o higit pa, parang normal na pagta-type na ito para sa isang reader. Kaya maraming CPU-only setup ang maayos nang gamitin nang hindi nangangailangan ng karagdagang pag-aayos.

Pagsusukat ng VRAM bago bumili

Ang laki ng model file ang pinakamababang batayan, hindi ang aktuwal na requirement. Maglaan para sa weights, sa 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 ng VRAM. Ang 27B model sa 4 bits ay nasa 16 GB at nangangailangan ng humigit-kumulang 20 GB. Ang 70B sa 4 bits ay nasa 40 GB at nangangailangan ng 48 GB na card, o dalawang mas maliit na card.

Hindi sapat ang tuntuning ito para sa mahahabang context. Lumalaki nang linear ang KV cache ayon sa haba ng context, at sa 128k tokens maaari itong lumampas sa laki mismo ng weights. Kung gagamit ka ng mahahabang context, unahin ang paglalaan ng laki para 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 ang iba pang hakbang.

nvidia-smi

Dapat magpakita ang table ng pangalan ng GPU, bersyon ng driver, at memory na ginagamit mula sa kabuuang memory. Ibig sabihin ng NVIDIA-SMI has failed because it couldn't communicate with the NVIDIA driver ay wala ang driver, o hindi na-build muli ang kernel module pagkatapos ng 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 upang ma-load ang bagong module.

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

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 na gumagana ang passthrough mula sa loob ng isang container:

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 kailanman na-reconfigure o na-restart ang Docker, kaya patakbuhin muli ang linyang nvidia-ctk at ang restart. Sa Compose, ang katumbas nito ay isang deploy.resources.reservations.devices entry na ang driver ay nvidia at ang capabilities list nito ay naglalaman ng gpu. Isinasama ito 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 Ollama self-hosting ng isang LLM 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 pag-generate, sa tokens per second. Ang prompt eval rate ang bilis ng pagbasa ng machine sa input mo. Ipinapakita ng dalawang numerong ito kung aling upgrade ang makatutulong: ang mababang eval rate ay problema sa memory bandwidth, at 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

Binabasa ng column na PROCESSOR ang 100% GPU kapag kasya ang lahat, o ang isang value na gaya 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 sa gastos

Ang mga GPU instance ay ilang beses na mas mahal kaysa sa katumbas na CPU instance. Sinisingil ang mga ito sa bawat oras na aktibo ang mga ito, hindi batay sa dami ng token na nalilikha. Ang GPU na laging naka-on para sa iilang request bawat araw ang pinakamahal na paraan ng pagpapatakbo ng inference. Ang break-even ay nakabatay sa utilisation: mura ang busy na GPU sa bawat token, ngunit purong aksaya ang idle na GPU.

May tatlong praktikal na pattern. Panatilihin sa CPU VPS ang tuloy-tuloy ngunit kaunting workload. Ipadala ang paminsan-minsang mahirap na request sa isang hosted API at magbayad bawat token. Mag-rent ng GPU kada oras para sa batch job, fine-tuning, o maramihang embedding run, pagkatapos ay i-destroy ito. Karaniwan ang paghahalo ng mga paraang ito. Nalalapat din dito ang disiplina sa pagbabadyet na inilalarawan sa kontrol sa gastos ng AI agent sa isang VPS na laging naka-on, ngunit ang kaibahan ay idle time, hindi bilang ng token, ang pinagmumulan ng pagtagas sa gastos.

Ano pa ang maayos na gumagana nang walang GPU

Mga embedding na mababa ang volume. Ang isang maliit na embedding model ay nagpoproseso ng daan-daang maiikling dokumento bawat minuto gamit ang ilang CPU core, at hindi kailangang mabilis ang index na isang beses mo lang binuo.

Whisper small at base para sa transcription. Ang faster-whisper sa CPU ay nagta-transcribe nang halos real time para sa small model. Sapat ito para sa pipeline na tumatakbo magdamag.

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

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

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

FAQ

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

Humigit-kumulang 6 GB para sa 4-bit quantized na 8B na modelo 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. Nagbibigay ang 12 GB na card ng sapat na espasyo para sa mas mahahabang context. Kung plano mong gumamit ng 128k na context, magkahiwalay na maglaan para sa cache, dahil maaari itong lumaki nang higit sa laki ng weights.

Maaari ko bang patakbuhin ang Ollama nang walang GPU?

Oo. Awtomatikong gumagamit ang Ollama ng CPU at kailangan lamang ng sapat na RAM para maglaman ng modelo. Asahan ang humigit-kumulang 5 hanggang 12 token bawat segundo para sa 4-bit na 8B na modelo, depende sa bilis ng memory, na halos katumbas ng bilis ng pagbabasa para sa isang user. Ang mahahabang prompt ang pangunahing problema sa CPU, dahil compute-bound ang pagbasa ng 30,000 token na context at mas matagal ito kaysa sa pagbuo ng tugon.

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

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

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 modelong hanggang humigit-kumulang 13B. Ang mga sitwasyong nagbibigay-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 nagbibigay-daan ang batching sa isang GPU na sumagot sa dalawampung request sa halos kaparehong halaga ng pagsagot sa isang request.

Dapat ba akong umarkila ng GPU kada oras o patuloy itong patakbuhin?

Umupa kada oras kapag pabugso-bugso ang trabaho: fine-tuning, maramihang embedding run, o batch transcription job. Patuloy lamang itong patakbuhin kapag palaging abala ang card, dahil naniningil ang GPU instance para sa oras na umiiral ito, hindi para sa mga token na nagagawa. Mas mura ang low-traffic assistant sa CPU VPS, o sa hosted API na sinisingil kada token, kaysa sa idle na GPU.