VPS GPU atau CPU: Kapan Anda Benar-Benar Membutuhkannya?

Apakah Anda memerlukan VPS dengan GPU, atau CPU sudah cukup?

VPS dengan GPU mengubah dua hal saat Anda menjalankan model sendiri: kecepatan token dihasilkan dan ukuran model yang dapat dimuat sepenuhnya ke memori. GPU tidak mengubah hal lainnya. Jika beban kerja Anda adalah model chat 7B hingga 27B terkuantisasi yang menjawab satu orang setiap kali, tugas embedding dengan volume rendah, atau transkripsi suara dengan Whisper small, VPS CPU biasa dengan RAM yang memadai sudah dapat menjalankan tugas tersebut. Mulailah dengan CPU, ukur angka yang menjadi kendala, lalu tingkatkan kapasitas jika diperlukan.

Penyebabnya adalah bandwidth memori. Saat model bahasa menghasilkan satu token, model membaca semua bobot yang diperlukan dari memori. Model 8B yang dikuantisasi hingga 4 bit berukuran sekitar 4.7 GB di disk dan ukurannya di memori kurang lebih sama. Jadi, untuk menghasilkan satu token, sistem harus memindahkan sekitar 4.7 GB. Bagilah bandwidth memori mesin dengan angka tersebut untuk mendapatkan batas atas token per detik. Pembagian sederhana itu menjelaskan hampir semua benchmark yang akan Anda baca.

Keunggulan GPU yang sebenarnya

Bandwidth. DDR5 server pada host modern memindahkan puluhan gigabyte per detik. Memori GPU (VRAM, video RAM) memindahkan ratusan hingga lebih dari seribu gigabyte per detik. Rasio inilah yang menentukan peningkatan kecepatan, dan nilainya besar.

Kapasitas dengan kecepatan. Mesin CPU dengan RAM 64 GB dapat memuat model 70B pada 4 bit. Model tersebut tetap berjalan, tetapi kecepatannya lebih mendekati membaca daripada bercakap-cakap. GPU hanya membantu jika model tersebut dapat dimuat di VRAM. Begitu beberapa layer melimpah ke RAM sistem, jalur lambat kembali digunakan.

Throughput batch. Bagian ini sering diremehkan. GPU yang menghasilkan keluaran untuk satu pengguna membiarkan sebagian besar komputasinya menganggur karena GPU menunggu pembacaan memori. Layani 20 permintaan sekaligus, maka pembacaan bobot yang sama melayani seluruh 20 permintaan. Jumlah token per detik secara agregat meningkat beberapa kali lipat, sementara kecepatan per pengguna hanya sedikit menurun. CPU tidak bekerja seperti ini. Dua pengguna bersamaan pada mesin CPU kira-kira akan membagi dua kecepatan masing-masing. Jika Anda membangun API yang dipanggil banyak klien, batching adalah alasan utama memilih GPU, bahkan lebih penting daripada kecepatan single-stream mentah.

Pemrosesan prompt. Membaca prompt panjang bergantung pada komputasi, bukan memori. Di sinilah GPU memiliki keunggulan terbesar. Konteks 30,000 token yang diproses CPU selama satu menit dapat diproses GPU dalam beberapa detik. Konfigurasi retrieval yang memasukkan dokumen ke setiap permintaan akan terus merasakan perbedaan ini.

Perkiraan kasar dan cara membacanya

Blok di bawah ini memuat angka single-stream yang umumnya dipublikasikan untuk model 8B pada kuantisasi 4-bit, per Juli 2026. Angka ini hanya panduan berdasarkan orde besaran, bukan jaminan. Kuantisasi, panjang konteks, dan mesin inferensi yang Anda gunakan dapat 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 per detik, dibandingkan dengan 11 pada sistem CPU DDR5. Angka tersebut kira-kira lima kali lebih tinggi. Perbedaan ini sesuai dengan rasio bandwidth, bukan perbedaan dalam kemampuan komputasi mentah. Throughput aktual juga lebih rendah daripada bandwidth dibagi ukuran model. Hal ini terjadi karena attention pada konteks yang terus bertambah menambah beban kerja yang tidak diperhitungkan dalam pembagian sederhana tersebut.

Sebagai perbandingan, seseorang membaca sekitar 5 hingga 10 kata per detik. Kecepatan 15 token per detik atau lebih sudah terasa seperti pengetikan normal bagi satu pembaca. Karena itu, banyak konfigurasi yang hanya menggunakan CPU ternyata sudah memadai.

Menentukan kebutuhan VRAM sebelum membeli

Ukuran file model adalah batas minimum, bukan kebutuhan sebenarnya. Siapkan VRAM untuk bobot model, cache KV (key-value cache, yaitu memori per token yang digunakan mekanisme attention), serta sekitar 1 GB untuk overhead.

Aturan praktis per Juli 2026: gunakan ukuran file model dalam gigabyte, lalu tambahkan 20 persen untuk konteks normal sepanjang 8k hingga 16k. Model 8B berukuran 4.7 GB memerlukan sekitar 6 GB VRAM. Model 27B pada 4 bit berukuran sekitar 16 GB dan memerlukan kira-kira 20 GB. Model 70B pada 4 bit berukuran sekitar 40 GB dan memerlukan kartu 48 GB, atau dua kartu yang lebih kecil.

Konteks panjang membuat aturan ini tidak berlaku. Cache KV bertambah secara linear sesuai panjang konteks, dan pada 128k token ukurannya dapat melebihi bobot model itu sendiri. Jika Anda berencana menggunakan konteks panjang, tentukan kebutuhan berdasarkan cache terlebih dahulu dan periksa opsi kuantisasi cache yang tersedia di engine Anda.

Periksa apa yang benar-benar tersedia di mesin

Pada instance GPU, pastikan driver mengenali kartu tersebut sebelum melakukan hal lain.

nvidia-smi

Tabel harus menampilkan nama GPU, versi driver, serta memori yang digunakan dari total memori. NVIDIA-SMI has failed because it couldn't communicate with the NVIDIA driver berarti driver belum terpasang, atau modul kernel tidak dibangun ulang setelah pemutakhiran kernel. Pada image Ubuntu standar, biasanya solusinya adalah sudo apt install -y ubuntu-drivers-common && sudo ubuntu-drivers install, lalu lakukan reboot agar modul baru dimuat.

Untuk container, driver saja tidak cukup. Docker memerlukan NVIDIA Container Toolkit agar perangkat dapat diteruskan ke 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

Selanjutnya, buktikan bahwa penerusan perangkat berfungsi dari dalam container:

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

Tabel yang sama seharusnya muncul. Baris docker: Error response from daemon: could not select device driver yang menyebutkan kemampuan GPU yang tidak dapat dipenuhi berarti toolkit sudah terpasang, tetapi Docker belum dikonfigurasi ulang atau dimulai ulang. Jalankan kembali baris nvidia-ctk, lalu lakukan restart. Dalam Compose, padanannya adalah entri deploy.resources.reservations.devices yang memiliki driver bernilai nvidia dan daftar kemampuan yang memuat gpu. Entri ini dapat digunakan dalam definisi layanan biasa yang dibahas di Docker Compose pada VPS.

Lakukan pengukuran sebelum meningkatkan kapasitas

Jalankan model yang benar-benar akan Anda gunakan pada mesin CPU yang sudah tersedia, lalu catat hasilnya. Dengan Ollama untuk menghosting LLM sendiri di VPS, Anda hanya perlu satu flag:

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

Output diakhiri dengan waktu pengukuran. eval rate adalah kecepatan pembuatan dalam token per detik. prompt eval rate menunjukkan seberapa cepat mesin membaca input Anda. Kedua angka tersebut menunjukkan peningkatan kapasitas yang paling membantu: eval rate yang rendah menunjukkan masalah bandwidth memori, sedangkan prompt eval rate yang rendah pada input panjang menunjukkan masalah komputasi.

Pada mesin yang memiliki GPU, pastikan model benar-benar dimuat ke GPU:

ollama ps

Kolom PROCESSOR menampilkan 100% GPU jika seluruh model dapat dimuat, atau nilai seperti 43%/57% CPU/GPU jika tidak. Pembagian model secara parsial biasanya menghasilkan kinerja yang lebih buruk dari perkiraan, karena setiap token tetap harus menunggu bagian yang lebih lambat.

Pertanyaan biaya

Instance GPU berbiaya beberapa kali lipat dibandingkan instance CPU yang sebanding. Biaya ditagihkan untuk setiap jam instance aktif, bukan berdasarkan token yang dihasilkannya. GPU yang selalu aktif untuk melayani beberapa permintaan per hari adalah cara paling mahal untuk menjalankan inferensi. Titik impasnya adalah utilisasi: GPU yang sibuk menghasilkan biaya per token yang rendah, sedangkan GPU yang menganggur hanya membuang biaya.

Ada tiga pola yang dapat digunakan. Jalankan pekerjaan bervolume rendah tetapi stabil pada VPS CPU. Kirim permintaan sulit yang jarang terjadi ke API terkelola dan bayar berdasarkan token. Sewa GPU per jam untuk pekerjaan batch, fine-tuning, atau proses embedding dalam jumlah besar, lalu hapus instance tersebut. Menggabungkan pola-pola ini adalah hal yang wajar. Disiplin penganggaran yang dijelaskan dalam pengendalian biaya agen AI pada VPS yang selalu aktif juga berlaku di sini. Perbedaannya, kebocoran biaya berasal dari waktu menganggur, bukan dari jumlah token.

Apa yang masih berjalan baik tanpa GPU

Embedding dengan volume rendah. Model embedding kecil memproses ratusan dokumen pendek per menit menggunakan beberapa core CPU. Indeks yang Anda buat satu kali tidak harus diproses dengan cepat.

Whisper small dan base untuk transkripsi. Faster-whisper pada CPU melakukan transkripsi hampir secara real-time dengan model small. Ini cukup untuk pipeline yang berjalan semalaman.

Model chat terkuantisasi hingga sekitar 27B, untuk satu atau dua pengguna. Lambat, mudah dibaca, dan tetap dapat digunakan.

Apa pun yang dapat Anda sebut sebagai batch job. Jika tidak ada yang memantau layar, kecepatan waktu berjalan hanya merupakan detail penjadwalan, bukan persyaratan.

Yang benar-benar memerlukan GPU: training atau fine-tuning di luar adapter kecil, melayani banyak pengguna secara bersamaan, pembuatan gambar dan video, serta speech real-time ketika latensi merupakan bagian utama dari produk.

FAQ

Berapa VRAM yang saya perlukan untuk model 7B atau 8B?

Sekitar 6 GB untuk model 8B terkuantisasi 4-bit dengan konteks normal 8k hingga 16k. Bobotnya sekitar 4.7 GB, sedangkan sisanya digunakan oleh cache KV dan overhead sekitar 1 GB. Kartu 12 GB menyediakan ruang yang cukup untuk konteks yang lebih panjang. Jika Anda berencana menggunakan konteks 128k, alokasikan kapasitas cache secara terpisah karena ukurannya dapat melebihi ukuran bobot.

Dapatkah saya menjalankan Ollama tanpa GPU?

Ya. Ollama secara otomatis beralih ke CPU dan hanya memerlukan RAM yang cukup untuk memuat model. Untuk model 8B 4-bit, perkirakan sekitar 5 hingga 12 token per detik, bergantung pada kecepatan memori. Kecepatan ini mendekati kecepatan membaca untuk satu pengguna. Prompt yang panjang menjadi kendala utama pada CPU karena pemrosesan konteks sepanjang 30,000 token terikat oleh kemampuan komputasi dan memerlukan waktu jauh lebih lama daripada pembuatan respons.

Mengapa GPU saya hanya sedikit lebih cepat daripada CPU?

Penyebab yang umum adalah model tidak sepenuhnya muat di VRAM. Akibatnya, sebagian layer berjalan di CPU dan setiap token harus menunggu bagian yang lebih lambat. Jalankan ollama ps dan periksa apakah kolom PROCESSOR berisi 100% GPU. Jika terdapat pembagian, gunakan kuantisasi yang lebih kecil atau model yang lebih kecil. Penyebab umum lainnya adalah benchmark yang terlalu singkat, sehingga waktu pemuatan model mendominasi pengukuran.

Apakah VPS GPU layak digunakan untuk satu pengguna?

Biasanya tidak. Satu orang membaca 5 hingga 10 kata per detik, sedangkan server CPU sudah menghasilkan token lebih cepat daripada itu untuk model hingga sekitar 13B. Kondisi yang dapat membenarkan biayanya untuk satu pengguna adalah prompt yang panjang, pembuatan gambar, dan fine-tuning. Melayani banyak pengguna secara bersamaan merupakan alasan terkuat karena batching memungkinkan satu GPU menjawab dua puluh permintaan dengan biaya yang hampir sama seperti menjawab satu permintaan.

Sebaiknya saya menyewa GPU per jam atau menjalankannya terus-menerus?

Sewa per jam jika beban kerja bersifat tidak tetap, seperti fine-tuning, proses embedding dalam jumlah besar, atau tugas transkripsi batch. Jalankan terus-menerus hanya jika GPU selalu digunakan secara aktif karena instans GPU ditagihkan berdasarkan durasi penggunaan, bukan jumlah token yang dihasilkan. Asisten dengan lalu lintas rendah lebih murah dijalankan pada VPS CPU atau menggunakan API terkelola dengan pembayaran per token daripada menggunakan GPU yang menganggur.