VPS GPU atau CPU: Bila Anda Sebenarnya Memerlukannya

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

VPS dengan GPU mengubah dua perkara tentang menjalankan model sendiri: kelajuan token dijana dan saiz model yang boleh dimuatkan dalam memori. Ia tidak mengubah perkara lain. Jika beban kerja anda ialah model sembang 7B hingga 27B yang dikuantumkan dan menjawab seorang pengguna pada satu masa, tugas pembenaman pada volum rendah, atau transkripsi pertuturan menggunakan Whisper small, VPS CPU biasa dengan RAM yang mencukupi sudah boleh menjalankan tugas tersebut. Mulakan dengan CPU, ukur perkara yang paling mengganggu anda, kemudian tingkatkan sumber jika perlu.

Sebabnya ialah lebar jalur memori. Apabila model bahasa menjana satu token, model tersebut membaca semua pemberat yang diperlukan daripada memori. Model 8B yang dikuantumkan kepada 4 bit berukuran kira-kira 4.7 GB pada cakera dan kira-kira sama dalam memori. Oleh itu, menghasilkan satu token bermakna memindahkan kira-kira 4.7 GB. Bahagikan lebar jalur memori mesin dengan nombor itu untuk mendapatkan had token sesaat. Pembahagian tunggal ini menjelaskan hampir semua penanda aras yang akan anda baca.

Perkara yang sebenarnya diperoleh daripada GPU

Jalur lebar. DDR5 pelayan pada hos moden memindahkan puluhan gigabait sesaat. Memori GPU (VRAM, RAM video) memindahkan ratusan hingga lebih daripada seribu gigabait sesaat. Nisbah inilah peningkatan kelajuan, dan nilainya besar.

Kapasiti dengan kelajuan. Kotak CPU dengan 64 GB RAM boleh memuatkan model 70B pada 4 bit. Model itu boleh dijalankan, tetapi kelajuannya lebih hampir kepada membaca berbanding bersembang. GPU hanya membantu jika model itu muat dalam VRAM, kerana apabila lapisan melimpah ke RAM sistem, laluan perlahan kembali digunakan.

Pendayaan kelompok. Ini bahagian yang sering dipandang rendah. GPU yang menjana output untuk seorang pengguna membiarkan sebahagian besar pengiraannya melahu kerana GPU sedang menunggu memori. Hidangkan 20 permintaan serentak, dan bacaan pemberat yang sama digunakan untuk kesemua 20 permintaan. Kadar token sesaat secara agregat meningkat beberapa kali ganda, manakala kelajuan bagi setiap pengguna hanya menurun sedikit. CPU tidak berfungsi sedemikian. Dua pengguna serentak pada kotak CPU secara kasar membahagikan kelajuan antara satu sama lain. Jika anda membina API yang dipanggil oleh ramai pelanggan, pendayaan kelompok ialah hujah utama untuk menggunakan GPU, lebih penting daripada kelajuan mentah bagi satu aliran.

Pemprosesan prom. Membaca prom yang panjang terikat pada pengiraan, bukan pada memori, dan di sinilah GPU memberikan kelebihan paling besar. Konteks 30,000 token yang mengambil masa seminit untuk diproses oleh CPU hanya mengambil masa beberapa saat pada GPU. Persediaan pengambilan semula yang memasukkan dokumen ke dalam setiap permintaan akan sentiasa mengalami kesan ini.

Angka anggaran dan cara mentafsirkannya

Blok di bawah mengandungi angka lazim yang diterbitkan untuk satu aliran bagi model 8B dengan kuantisasi 4-bit, setakat Julai 2026. Angka ini memberikan panduan mengikut tertib magnitud, bukan jaminan. Kuantisasi, panjang konteks dan enjin inferens anda akan mengubahnya.

[
  {
    "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 komputer CPU DDR5. Nilai itu kira-kira lima kali ganda, selaras dengan nisbah lebar jalur dan bukannya perbezaan dalam kuasa pengiraan mentah. Kelajuan sebenar juga lebih rendah daripada lebar jalur dibahagikan dengan saiz model kerana perhatian terhadap konteks yang semakin panjang menambah kerja yang tidak diambil kira oleh pembahagian mudah itu.

Sebagai perbandingan, seseorang membaca kira-kira 5 hingga 10 perkataan sesaat. Kelajuan 15 token sesaat atau lebih sudah terasa seperti kelajuan menaip biasa bagi seorang pembaca. Sebab itu banyak persediaan yang hanya menggunakan CPU sebenarnya sudah memadai.

Menentukan saiz VRAM sebelum membeli

Saiz fail model ialah had minimum, bukan keperluan sebenar. Peruntukkan memori untuk pemberat, serta cache KV (cache nilai kunci, iaitu memori bagi setiap token yang dikekalkan oleh perhatian), dan kira-kira 1 GB untuk overhed.

Peraturan praktikal setakat July 2026: ambil saiz fail model dalam gigabait dan tambah 20 peratus untuk konteks biasa 8k hingga 16k. Model 8B berukuran 4.7 GB memerlukan kira-kira 6 GB VRAM. Model 27B pada 4 bit berukuran sekitar 16 GB dan memerlukan kira-kira 20 GB. Model 70B pada 4 bit berukuran kira-kira 40 GB dan memerlukan kad 48 GB, atau dua kad yang lebih kecil.

Konteks yang panjang menyebabkan peraturan ini tidak lagi tepat. Cache KV berkembang secara linear mengikut panjang konteks, dan pada 128k token, saiznya boleh melebihi pemberat model itu sendiri. Jika anda merancang untuk menggunakan konteks yang panjang, utamakan saiz cache dan semak pilihan yang disediakan oleh enjin anda untuk pengkuantuman cache.

Semak perkara yang sebenarnya tersedia pada mesin

Pada tika GPU, sahkan pemacu mengesan kad tersebut sebelum melakukan perkara lain.

nvidia-smi

Anda perlu melihat jadual yang menyenaraikan nama GPU, versi pemacu dan memori yang digunakan daripada 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 peningkatan kernel. Pada imej Ubuntu standard, pembaikan biasanya ialah sudo apt install -y ubuntu-drivers-common && sudo ubuntu-drivers install, kemudian mulakan semula sistem supaya modul baharu dimuatkan.

Untuk kontena, pemacu sahaja tidak mencukupi. Docker memerlukan NVIDIA Container Toolkit untuk meneruskan peranti kepada kontena.

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 bahawa penerusan peranti berfungsi dari dalam kontena:

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

Jadual yang sama sepatutnya dipaparkan. 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 pernah dikonfigurasi semula atau dimulakan semula. Oleh itu, jalankan semula baris nvidia-ctk dan arahan mula semula tersebut. Dalam Compose, padanannya ialah entri deploy.resources.reservations.devices yang driver-nya ialah nvidia dan senarai keupayaannya mengandungi gpu. Entri ini boleh dimasukkan ke dalam takrifan perkhidmatan biasa yang diterangkan dalam Docker Compose pada VPS.

Buat pengukuran sebelum menaik taraf

Jalankan model yang benar-benar hendak anda gunakan pada pelayan CPU yang sedia ada, kemudian catatkan angkanya. Dengan Ollama mengehos sendiri LLM pada VPS, anda hanya perlu menggunakan satu flag:

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

Output berakhir dengan pemasaan. eval rate ialah kelajuan penjanaan dalam token sesaat. prompt eval rate ialah kelajuan mesin membaca input anda. Kedua-dua angka ini menunjukkan naik taraf yang paling membantu: eval rate yang rendah menunjukkan masalah lebar jalur memori, manakala prompt eval rate yang rendah bagi input yang panjang menunjukkan masalah pengiraan.

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

ollama ps

Lajur PROCESSOR memaparkan 100% GPU apabila semuanya dimuatkan, atau sesuatu seperti 43%/57% CPU/GPU apabila tidak. Pembahagian separa biasanya lebih perlahan daripada jangkaan kerana setiap token masih perlu menunggu bahagian yang lebih perlahan.

Soal kos

Instans GPU berharga beberapa kali ganda berbanding instans CPU yang setara. Instans ini dicaj bagi setiap jam ia wujud, bukan berdasarkan token yang dihasilkannya. GPU yang sentiasa aktif untuk melayan beberapa permintaan sehari ialah cara paling mahal untuk menjalankan inferens. Titik pulang modal bergantung pada tahap penggunaan: GPU yang sibuk mempunyai kos rendah bagi setiap token, manakala GPU yang melahu hanya membazirkan kos.

Tiga corak penggunaan yang praktikal boleh digunakan. Kekalkan kerja berjumlah rendah tetapi berterusan pada VPS CPU. Hantar permintaan sukar yang jarang berlaku kepada API terhos dan bayar berdasarkan token. Sewa GPU mengikut jam untuk kerja kelompok, penalaan halus, atau proses embedding secara pukal, kemudian musnahkan instans tersebut. Menggabungkan kaedah ini ialah perkara biasa. Disiplin belanjawan yang diterangkan dalam Kawalan kos ejen AI pada VPS yang sentiasa aktif turut terpakai di sini. Bezanya, masa melahu menjadi punca pembaziran, bukan jumlah token.

Perkara yang masih berjalan dengan baik tanpa GPU

Embeddings pada jumlah rendah. Model embedding kecil memproses ratusan dokumen pendek seminit menggunakan beberapa teras CPU. Indeks yang dibina sekali tidak perlu pantas.

Whisper small dan base untuk transkripsi. Faster-whisper pada CPU melakukan transkripsi hampir dalam masa nyata bagi model small. Ini mencukupi untuk saluran pemprosesan yang berjalan semalaman.

Model sembang terkuantum sehingga kira-kira 27B, untuk satu atau dua pengguna. Perlahan, tetapi mudah dibaca dan boleh digunakan.

Apa-apa tugas yang boleh anda anggap sebagai kerja kelompok. Jika tiada sesiapa memantau skrin, masa jam sebenar ialah butiran penjadualan, bukan keperluan.

Perkara yang benar-benar memerlukan GPU: latihan atau penalaan halus yang melebihi adapter kecil, penyediaan perkhidmatan kepada ramai pengguna serentak, penjanaan imej dan video, serta pertuturan masa nyata apabila kependaman ialah keperluan utama produk.

FAQ

Berapa banyak VRAM yang diperlukan untuk model 7B atau 8B?

Kira-kira 6 GB untuk model 8B terkuantisasi 4-bit dengan konteks biasa 8k hingga 16k. Berat model adalah kira-kira 4.7 GB. Selebihnya digunakan oleh cache KV dan kira-kira 1 GB overhed. Kad 12 GB menyediakan ruang yang mencukupi untuk konteks yang lebih panjang. Jika anda merancang untuk menggunakan konteks 128k, tentukan saiz cache secara berasingan kerana cache boleh menjadi lebih besar daripada berat model.

Bolehkah saya menjalankan Ollama tanpa GPU?

Ya. Ollama beralih kepada 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. Kelajuan ini hampir menyamai kadar pembacaan untuk seorang pengguna. Gesaan yang panjang ialah masalah utama pada CPU kerana membaca konteks sebanyak 30,000 token memerlukan banyak pengiraan dan mengambil masa lebih lama daripada menjana jawapan.

Mengapa GPU saya hampir tidak lebih laju daripada CPU?

Punca biasa ialah model tidak dapat dimuatkan sepenuhnya dalam VRAM. Oleh itu, sesetengah lapisan dijalankan pada CPU dan setiap token perlu menunggu bahagian yang lebih perlahan. Jalankan ollama ps dan semak sama ada lajur PROCESSOR memaparkan 100% GPU. Jika terdapat pemisahan, gunakan kuantisasi yang lebih kecil atau model yang lebih kecil. Punca biasa yang lain ialah penanda aras yang singkat, apabila masa memuatkan model mendominasi pengukuran.

Adakah VPS GPU berbaloi untuk seorang pengguna?

Biasanya tidak. Seseorang membaca pada kadar 5 hingga 10 perkataan sesaat, manakala pelayan CPU sudah menjana token dengan lebih pantas daripada kadar itu untuk model sehingga kira-kira 13B. Kes yang boleh mewajarkan kos untuk seorang pengguna ialah gesaan yang panjang, penjanaan imej dan penalaan halus. Menyediakan perkhidmatan kepada ramai pengguna serentak ialah alasan yang lebih kukuh kerana pemprosesan kelompok membolehkan satu GPU menjawab dua puluh permintaan dengan kos yang hampir sama seperti menjawab satu permintaan.

Patutkah saya menyewa GPU mengikut jam atau membiarkannya berjalan sepanjang masa?

Sewa mengikut jam apabila beban kerja berlaku secara berkala, seperti penalaan halus, proses embedding secara pukal atau kerja transkripsi kelompok. Biarkan GPU berjalan sepanjang masa hanya apabila kad tersebut sentiasa digunakan kerana penyedia mengenakan bayaran untuk tempoh instance berjalan, bukan berdasarkan jumlah token yang dihasilkan. Pembantu dengan trafik rendah lebih murah pada VPS CPU atau API terhos yang mengenakan bayaran mengikut token berbanding GPU yang tidak digunakan.