VPS GPU atau CPU: Bila Anda Benar-benar Memerlukannya

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

VPS dengan GPU mengubah dua perkara tentang menjalankan model sendiri: kelajuan penjanaan token dan saiz model yang boleh dimuatkan ke dalam memori. Tiada perkara lain yang 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 dengan Whisper small, VPS CPU biasa dengan RAM yang mencukupi sudah memadai. Mulakan dengan CPU, ukur prestasi yang tidak memuaskan, kemudian baru tingkatkan spesifikasi.

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.9 GB pada cakera dan hampir sama dalam memori, jadi menghasilkan satu token bermakna memindahkan kira-kira 4.9 GB data. Bahagikan lebar jalur memori mesin dengan angka tersebut dan anda akan mendapat had maksimum token sesaat. Pembahagian mudah itu menjelaskan hampir setiap penanda aras (benchmark) yang anda akan 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 berbual. GPU hanya membantu di sini jika model tersebut muat di dalam VRAM, kerana sebaik sahaja lapisan (layers) melimpah ke RAM sistem, laluan perlahan akan kembali mengambil alih.

Throughput kelompok (Batch throughput). Ini adalah bahagian yang sering dipandang remeh oleh orang ramai. GPU yang menjana respons untuk seorang pengguna membiarkan kebanyakan 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 berkurangan. Enjin inferens CPU seperti llama.cpp juga menyokong pemprosesan kelompok, dengan peningkatan bergantung pada perkakasan dan beban kerja. Jika anda membina API yang dipanggil oleh ramai pelanggan, pemprosesan kelompok adalah hujah utama untuk menggunakan GPU, lebih daripada kelajuan aliran tunggal (single-stream) semata-mata.

Pemprosesan prompt. Membaca prompt yang panjang adalah terikat dengan pengiraan (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 sentiasa merasai perbezaan ini.

Anggaran kasar dan cara membacanya

Throughput sebenar juga berada di bawah lebar jalur dibahagikan dengan saiz model, kerana perhatian (attention) terhadap konteks yang semakin berkembang menambah beban kerja yang tidak diambil kira oleh pembahagian mudah tersebut.

Sebagai perbandingan, bacaan senyap orang dewasa dalam bahasa Inggeris secara purata adalah sekitar 4.0 hingga 4.3 perkataan sesaat: 238 perkataan seminit untuk bukan fiksyen dan 260 untuk fiksyen. Sebarang kelajuan pada atau melebihi 15 token sesaat sudah terasa seperti kelajuan menaip biasa bagi seorang pembaca. Itulah sebabnya banyak persediaan yang hanya menggunakan CPU sebenarnya sudah memadai.

Menentukan saiz VRAM sebelum membeli

Saiz fail model hanyalah lantai keperluan, bukan jumlah keseluruhan. Bajetkan untuk pemberat, ditambah dengan KV cache (key-value cache, memori setiap token yang disimpan oleh attention), serta kira-kira 1 GB untuk overhead.

Kira cache tersebut dan jangan sekadar menambah peratusan tetap, kerana menguantisasi pemberat tidak menguantisasi cache. Bagi setiap token, model full-attention menyimpan key dan value untuk setiap lapisan dan setiap KV head, pada 2 bait bagi setiap nombor dalam FP16, iaitu jenis cache lalai Ollama. Metadata model Ollama, yang disemak pada 2026-10-27, menunjukkan Llama 3.1 8B mempunyai 32 lapisan dan 8 KV head dengan 128 dimensi, yang menghasilkan 128 KiB bagi setiap token: kira-kira 1.07 GB pada konteks 8k dan 2.15 GB pada 16k. Jadi, model 8B bersaiz 4.9 GB memerlukan kira-kira 7 GB VRAM pada 8k dan kira-kira 8 GB pada 16k. Model 27B pada 4 bit adalah sekitar 17 GB (Gemma 3 27B dalam pustaka Ollama). Metadata Gemma 3 menyenaraikan tetingkap gelongsor (sliding window) 1,024-token, yang menghalang cache daripada berkembang terlalu besar, jadi rancang untuk 20 GB atau lebih. Model 70B pada 4 bit adalah sekitar 43 GB (Llama 3.3 70B). Dengan 80 lapisan, cache FP16 menambah kira-kira 2.7 GB pada 8k dan 5.4 GB pada 16k, jadi ia memerlukan kad 48 GB dengan ruang yang terhad, atau dua kad yang lebih kecil. Aritmetik yang sama terus terpakai jauh melebihi saiz tersebut, dan matematik VRAM untuk model 2.8 trilion parameter seperti Kimi K3 menunjukkan di mana pemilihan kad bukan lagi menjadi persoalan utama.

Konteks yang panjang adalah tempat perkara ini paling penting. Pada model full-attention seperti Llama 3.1, KV cache berkembang secara linear dengan panjang konteks, dan pada 128k token ia boleh melebihi saiz pemberat itu sendiri. Model dengan sliding-window atau chunked attention adalah berbeza: dokumentasi Transformers daripada Hugging Face menamakan Mistral, Gemma 2 dan Llama 4 sebagai contoh di mana cache pada lapisan tersebut berhenti berkembang sebaik sahaja ia mencapai saiz tetingkap atau chunk, jadi jumlah keseluruhannya berkembang dengan lebih perlahan. Jika anda bercadang untuk menggunakan konteks yang panjang, tentukan saiz untuk cache terlebih dahulu dan semak apa yang ditawarkan oleh enjin anda untuk kuantisasi cache. Dalam Ollama, OLLAMA_KV_CACHE_TYPE=q8_0 menggunakan kira-kira separuh memori daripada f16 lalai, dan kuantisasi cache hanya terpakai apabila Flash Attention diaktifkan. Tetapkan panjang konteks secara eksplisit juga. Ollama memilih nilai lalai daripada VRAM: 4k untuk bawah 24 GiB, 32k untuk 24 hingga 48 GiB, dan 256k untuk 48 GiB ke atas. Pada kad 48 GB yang menjalankan model 70B, nilai lalai itu meminta cache yang jauh lebih besar daripada kapasiti kad.

Semak perkakasan sebenar pada mesin

Pada instans GPU, sahkan pemacu dapat mengesan kad tersebut sebelum melakukan perkara 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 NVIDIA-SMI tidak dapat mencapai pemacu; periksa sama ada pemacu telah dipasang dan modul kernelnya telah dimuatkan. Pada imej Ubuntu standard, penyelesaiannya biasanya adalah sudo apt install -y ubuntu-drivers-common && sudo ubuntu-drivers install, kemudian lakukan but semula supaya modul baharu dimuatkan. Bagi mesin pengkomputeran, dokumentasi pelayan Ubuntu mengesyorkan sudo ubuntu-drivers install --gpgpu, yang memilih cawangan pemacu pelayan.

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

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

Kemudian, buktikan 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 Docker tidak dapat mencari pemacu peranti yang sepadan dengan permintaan tersebut; periksa sama ada toolkit telah dipasang, kemudian jalankan semula baris nvidia-ctk dan lakukan mulakan semula. Dalam Compose, perkara yang setara ialah entri deploy.resources.reservations.devices yang mana driver adalah nvidia dan senarai keupayaannya mengandungi gpu, yang dimasukkan ke dalam definisi servis biasa 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 mengenakan caj berdasarkan masa pengkomputeran yang diperuntukkan dan bukannya token, dengan kadar serta caj instans yang dihentikan ditetapkan oleh penyedia. GPU yang sentiasa dihidupkan untuk melayani segelintir permintaan sehari akan menghabiskan sebahagian besar masa berbayarnya dalam keadaan melahu. Titik pulang modal bergantung pada penggunaan: GPU yang sibuk adalah murah bagi setiap token, manakala GPU yang melahu adalah pembaziran sepenuhnya.

Tiga corak jujur yang berkesan. Kekalkan 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, penalaan halus (fine-tuning), atau larian 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 dihidupkan juga terpakai di sini, dengan perbezaan bahawa masa melahu adalah 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 7 GB untuk model 8B terkuantisasi 4-bit pada konteks 8k, dan kira-kira 8 GB pada 16k, dengan cache FP16 lalai Ollama. Berat model adalah sekitar 4.9 GB, cache KV menambah kira-kira 1.07 GB pada 8k atau 2.15 GB pada 16k, dan bakinya adalah sekitar 1 GB untuk overhead. Kad 8 GB boleh memuatkannya pada 8k tetapi agak terhad pada 16k, manakala kad 12 GB memberikan ruang yang selesa untuk konteks yang lebih panjang. Menukar cache kepada q8_0 akan mengurangkan bahagian cache kepada separuh. Jika anda bercadang untuk menjalankan konteks 128k, tentukan saiz cache secara berasingan kerana ia boleh menjadi lebih besar daripada berat model itu sendiri.

Bolehkah saya menjalankan Ollama tanpa GPU?

Boleh. Ollama akan beralih ke CPU secara automatik dan hanya memerlukan RAM yang mencukupi untuk memuatkan model. 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 sesetengah lapisan berjalan pada CPU dan setiap token perlu menunggu bahagian yang perlahan itu. Jalankan ollama ps dan periksa sama ada lajur PROCESSOR memaparkan 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. Bacaan senyap orang dewasa dalam bahasa Inggeris secara purata adalah sekitar 4.0 hingga 4.3 perkataan sesaat, dan token sesaat perlu ditukar kepada perkataan sesaat sebelum membandingkan kotak CPU dengan kelajuan tersebut. Kes yang mewajarkan kos bagi seorang pengguna ialah prompt yang panjang, penjanaan imej, dan fine-tuning. Melayani ramai pengguna serentak adalah hujah terkuat, kerana batching membolehkan satu GPU berkongsi bacaan berat model merentasi permintaan.

Patutkah saya menyewa GPU mengikut jam atau membiarkannya sentiasa berjalan?

Sewa mengikut jam apabila kerja bersifat berkala: fine-tuning, proses embedding pukal, atau tugasan transkripsi kelompok. Biarkan ia sentiasa berjalan hanya apabila kad tersebut sentiasa sibuk, memandangkan pengiraan GPU yang diperuntukkan dibilkan mengikut masa dan bukannya 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.