Perlukah VPS dengan GPU untuk Model AI?

Adakah anda memerlukan VPS dengan GPU, atau CPU sudah memadai?

VPS dengan GPU mengubah dua perkara apabila anda menjalankan model sendiri: kelajuan penjanaan token dan saiz model yang boleh dimuatkan ke dalam memori. Perkara lain tidak berubah. Jika beban kerja anda melibatkan model sembang 7B hingga 27B yang dikuantisasi untuk menjawab seorang pengguna pada satu masa, tugasan embedding pada volum rendah, atau transkripsi pertuturan menggunakan Whisper small, VPS CPU biasa dengan RAM yang mencukupi sudah memadai. Mulakan dengan CPU, ukur prestasi yang tidak memuaskan, kemudian baru naik taraf.

Sebabnya ialah lebar jalur memori (memory bandwidth). Apabila model bahasa menjana satu token, ia membaca setiap pemberat (weight) yang diperlukan daripada memori. Model 8B yang dikuantisasi kepada 4 bit bersaiz kira-kira 4.7 GB pada cakera dan hampir sama dalam memori, jadi penghasilan satu token bermakna pemindahan data sebanyak kira-kira 4.7 GB. Bahagikan lebar jalur memori mesin dengan angka tersebut dan anda akan mendapat had maksimum token sesaat. Pembahagian tunggal itu menjelaskan hampir setiap penanda aras (benchmark) yang anda baca.

Apa yang sebenarnya anda peroleh daripada GPU

Lebar jalur (Bandwidth). DDR5 pelayan pada hos moden memindahkan puluhan gigabait sesaat. Memori GPU (VRAM, video RAM) memindahkan ratusan hingga lebih seribu gigabait sesaat. Nisbah ini merupakan pecutan yang diperoleh, dan ia sangat besar.

Kapasiti dengan kelajuan. Kotak CPU dengan 64 GB RAM boleh memuatkan model 70B pada 4 bit. Ia akan berjalan, pada kadar yang lebih dekat dengan kelajuan membaca berbanding kelajuan berbual. GPU hanya membantu di sini jika model tersebut dimuatkan ke dalam VRAM, kerana sebaik sahaja lapisan model melimpah ke RAM sistem, laluan perlahan akan kembali menguasai proses tersebut.

Throughput kelompok (Batch throughput). Ini adalah bahagian yang sering dipandang rendah oleh orang ramai. GPU yang menjana respons untuk seorang pengguna membiarkan kebanyakan kuasa komputasinya melahu, kerana ia menunggu memori. Jika anda melayani 20 permintaan serentak, bacaan berat (weight read) yang sama akan melayani kesemua 20 permintaan tersebut. Jumlah token sesaat meningkat berkali ganda manakala kelajuan bagi setiap pengguna hampir tidak berkurang. CPU tidak melakukan perkara ini. Dua pengguna serentak pada kotak CPU akan mengurangkan kelajuan masing-masing kepada separuh. Jika anda membina API yang dipanggil oleh ramai pelanggan, pemprosesan kelompok (batching) adalah alasan utama untuk menggunakan GPU, lebih daripada kelajuan aliran tunggal (single-stream) semata-mata.

Pemprosesan prompt. Membaca prompt yang panjang adalah terikat dengan komputasi (compute-bound), bukan terikat dengan memori, dan di sinilah GPU menang dengan margin yang paling besar. Konteks 30,000 token yang diproses oleh CPU dalam masa seminit hanya mengambil masa beberapa saat pada GPU. Persediaan perolehan (retrieval) yang memasukkan dokumen ke dalam setiap permintaan akan merasai perbezaan ini secara berterusan.

Anggaran kasar dan cara membacanya

Blok di bawah mengandungi angka aliran tunggal yang lazim diterbitkan bagi model 8B pada kuantisasi 4-bit, setakat Julai 2026. Angka ini merupakan panduan magnitud sahaja, bukan jaminan. Kuantisasi, panjang konteks, dan enjin inferens anda akan mengubah angka tersebut.

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

Baris GPU 24 GB menunjukkan 50 token sesaat berbanding 11 bagi kotak CPU DDR5. Ini adalah kira-kira lima kali ganda, yang menjejaki nisbah lebar jalur dan bukannya sebarang perbezaan dalam pengiraan mentah. Daya pemprosesan sebenar juga berada di bawah lebar jalur dibahagikan dengan saiz model, kerana perhatian (attention) ke atas konteks yang semakin berkembang menambah beban kerja yang tidak diambil kira oleh pembahagian mudah tersebut.

Sebagai perbandingan, seseorang membaca pada kadar kira-kira 5 hingga 10 perkataan sesaat. Apa-apa kadar pada atau melebihi 15 token sesaat sudah terasa seperti menaip biasa bagi seorang pembaca. Itulah sebabnya banyak persediaan CPU sahaja sudah memadai secara senyap.

Menentukan saiz VRAM sebelum pembelian

Saiz fail model hanyalah nilai minimum, bukan keperluan sebenar. Peruntukkan memori untuk pemberat (weights), ditambah dengan KV cache (key-value cache, iaitu memori per-token yang disimpan oleh mekanisme attention), serta kira-kira 1 GB untuk overhed.

Satu peraturan praktikal setakat Julai 2026: ambil saiz fail model dalam gigabait dan tambah 20 peratus untuk konteks biasa antara 8k hingga 16k. Model 8B bersaiz 4.7 GB memerlukan kira-kira 6 GB VRAM. Model 27B pada 4-bit adalah sekitar 16 GB dan memerlukan kira-kira 20 GB. Model 70B pada 4-bit adalah sekitar 40 GB dan memerlukan kad 48 GB, atau dua kad yang lebih kecil. Pengiraan yang sama terus berkesan jauh melebihi saiz tersebut, dan matematik VRAM untuk model 2.8 trilion parameter seperti Kimi K3 menunjukkan tahap di mana pemilihan kad bukan lagi menjadi persoalan utama.

Konteks yang panjang melanggar peraturan ini. KV cache berkembang secara linear mengikut panjang konteks, dan pada 128k token, ia boleh melebihi saiz pemberat itu sendiri. Jika anda bercadang untuk menggunakan konteks yang panjang, tentukan saiz untuk cache terlebih dahulu dan semak tawaran enjin anda untuk kuantisasi cache.

Semak perkakasan sebenar pada mesin

Pada instans GPU, pastikan pemacu (driver) mengesan kad tersebut sebelum melakukan apa-apa langkah lain.

nvidia-smi

Anda memerlukan jadual yang menyenaraikan nama GPU, versi pemacu, serta memori yang digunakan berbanding jumlah keseluruhan. NVIDIA-SMI has failed because it couldn't communicate with the NVIDIA driver bermaksud pemacu tiada, atau modul kernel tidak dibina semula selepas naik taraf kernel. Pada imej Ubuntu standard, penyelesaiannya biasanya adalah sudo apt install -y ubuntu-drivers-common && sudo ubuntu-drivers install, kemudian lakukan but semula (reboot) supaya modul baharu dimuatkan.

Bagi kontena, pemacu sahaja tidak mencukupi. Docker memerlukan NVIDIA Container Toolkit untuk membolehkan peranti dilalui (pass-through).

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

Seterusnya, buktikan bahawa passthrough berfungsi dari dalam kontena:

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

Jadual yang sama sepatutnya muncul. Baris docker: Error response from daemon: could not select device driver yang menamakan keupayaan GPU yang tidak dapat dipenuhi bermaksud toolkit telah dipasang tetapi Docker tidak dikonfigurasi semula atau dimulakan semula. Oleh itu, jalankan semula baris nvidia-ctk dan lakukan restart. Dalam Compose, padanannya ialah entri deploy.resources.reservations.devices yang mana driver adalah nvidia dan senarai keupayaannya mengandungi gpu, yang dimasukkan ke dalam definisi servis biasa seperti yang dibincangkan dalam Docker Compose pada VPS.

Ukur sebelum anda menaik taraf

Jalankan model yang anda ingin gunakan pada pelayan CPU sedia ada, kemudian catatkan angka-angkanya. Dengan Ollama self-hosting an LLM on a VPS, proses ini hanya memerlukan satu flag:

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

Output tersebut akan berakhir dengan maklumat masa. eval rate ialah kelajuan penjanaan anda dalam unit token sesaat. prompt eval rate ialah kelajuan mesin membaca input anda. Kedua-dua angka ini memberitahu anda naik taraf mana yang membantu: eval rate yang rendah menunjukkan masalah lebar jalur memori, manakala prompt eval rate yang rendah pada input yang panjang menunjukkan masalah kuasa pengkomputeran.

Pada mesin yang mempunyai GPU, pastikan model tersebut benar-benar dimuatkan ke dalamnya:

ollama ps

Lajur PROCESSOR akan memaparkan 100% GPU apabila semuanya dimuatkan sepenuhnya, atau sesuatu seperti 43%/57% CPU/GPU apabila ia tidak dimuatkan. Pembahagian separa biasanya memberikan prestasi yang lebih buruk daripada jangkaan anda, kerana setiap token masih perlu menunggu bahagian yang perlahan untuk selesai.

Persoalan kos

Instans GPU menelan kos beberapa kali ganda berbanding instans CPU yang setara, dan caj dikenakan bagi setiap jam instans tersebut wujud, bukan berdasarkan jumlah token yang dihasilkan. GPU yang sentiasa dihidupkan untuk melayani segelintir permintaan sehari merupakan cara paling mahal untuk menjalankan inferens. Titik pulang modal bergantung pada penggunaan: GPU yang sibuk adalah murah bagi setiap token, manakala GPU yang melahu adalah pembaziran mutlak.

Tiga corak jujur boleh digunakan. Kekalkan beban kerja volum rendah yang stabil pada VPS CPU. Hantar permintaan sukar yang sekali-sekala ke API yang dihoskan dan bayar mengikut token. Sewa GPU mengikut jam untuk kerja kelompok (batch jobs), fine-tuning, atau proses embedding pukal, kemudian hapuskan instans tersebut. Mencampurkan kaedah ini adalah perkara biasa, dan disiplin belanjawan yang diterangkan dalam kawalan kos ejen AI pada VPS yang sentiasa hidup juga terpakai di sini, dengan perbezaan bahawa masa melahu merupakan punca kebocoran kos dan bukannya jumlah token.

Perkara yang masih berjalan lancar tanpa GPU

Embeddings pada volum rendah. Model embedding kecil memproses ratusan dokumen pendek seminit menggunakan beberapa teras CPU, dan indeks yang dibina sekali sahaja tidak memerlukan kelajuan tinggi.

Whisper versi small dan base untuk transkripsi. Faster-whisper pada CPU melakukan transkripsi hampir masa nyata untuk model kecil, yang mencukupi bagi talian paip (pipeline) yang berjalan sepanjang malam.

Model sembang (chat models) terkuantisasi sehingga kira-kira 27B, untuk seorang atau dua pengguna. Perlahan, boleh dibaca, boleh digunakan.

Apa-apa sahaja yang anda panggil sebagai kerja kelompok (batch job). Jika tiada sesiapa yang melihat skrin, kelajuan jam dinding (wall-clock speed) hanyalah perincian penjadualan dan bukannya satu keperluan.

Perkara yang benar-benar memerlukan GPU: latihan atau penalaan halus (fine-tuning) melebihi penyesuai (adapter) kecil, melayani ramai pengguna serentak, penjanaan imej dan video, serta pertuturan masa nyata di mana kependaman (latency) adalah produk utamanya.

FAQ

Berapakah VRAM yang diperlukan untuk model 7B atau 8B?

Kira-kira 6 GB untuk model 8B terkuantisasi 4-bit pada konteks 8k hingga 16k yang biasa. Berat model adalah sekitar 4.7 GB, dan bakinya adalah cache KV ditambah kira-kira 1 GB untuk overhead. Kad 12 GB memberikan ruang yang selesa untuk konteks yang lebih panjang. Jika anda bercadang untuk menjalankan konteks 128k, tentukan saiz cache secara berasingan kerana ia boleh menjadi lebih besar daripada berat model.

Bolehkah saya menjalankan Ollama tanpa GPU?

Boleh. Ollama akan beralih ke CPU secara automatik dan hanya memerlukan RAM yang mencukupi untuk memuatkan model tersebut. Jangkakan kira-kira 5 hingga 12 token sesaat untuk model 8B 4-bit bergantung pada kelajuan memori, yang hampir dengan kelajuan membaca bagi seorang pengguna. Prompt yang panjang merupakan masalah sebenar pada CPU, kerana membaca 30,000 token konteks adalah terikat dengan pengiraan (compute-bound) dan mengambil masa yang jauh lebih lama daripada menjana jawapan.

Mengapa GPU saya hampir tidak lebih pantas daripada CPU?

Punca biasa ialah model tidak dimuatkan sepenuhnya ke dalam VRAM, jadi beberapa lapisan berjalan pada CPU dan setiap token perlu menunggu bahagian yang perlahan itu. Jalankan ollama ps dan periksa sama ada lajur PROCESSOR menunjukkan 100% GPU. Jika ia menunjukkan pembahagian, gunakan kuantisasi yang lebih kecil atau model yang lebih kecil. Satu lagi punca biasa ialah penanda aras (benchmark) yang singkat di mana masa memuatkan model mendominasi ukuran tersebut.

Adakah GPU VPS berbaloi untuk seorang pengguna?

Biasanya tidak. Seorang individu membaca pada kelajuan 5 hingga 10 perkataan sesaat, dan pelayan CPU sudah mampu menghasilkan token lebih pantas daripada itu untuk model sehingga sekitar 13B. Kes yang mewajarkan kos bagi seorang pengguna ialah prompt yang panjang, penjanaan imej, dan fine-tuning. Melayani ramai pengguna serentak adalah hujah terkuat, kerana pemprosesan kelompok (batching) membolehkan satu GPU menjawab dua puluh permintaan dengan kos yang hampir sama dengan menjawab satu permintaan.

Patutkah saya menyewa GPU mengikut jam atau membiarkannya sentiasa berjalan?

Sewa mengikut jam apabila kerja bersifat berkala: fine-tuning, proses embedding pukal, atau kerja transkripsi kelompok. Biarkan ia sentiasa berjalan hanya apabila kad tersebut sentiasa sibuk, memandangkan instans GPU mengenakan caj kerana kewujudannya dan bukannya berdasarkan token yang dihasilkan. Pembantu dengan trafik rendah adalah lebih murah pada CPU VPS, atau pada API berhos yang dibayar mengikut token, berbanding GPU yang melahu.