VPS dengan GPU: 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 ke memori. GPU tidak mengubah hal lainnya. Jika beban kerja Anda adalah model chat 7B hingga 27B terkuantisasi yang menjawab satu orang pada satu waktu, pekerjaan embedding dengan volume rendah, atau transkripsi suara menggunakan Whisper small, VPS CPU biasa dengan RAM yang memadai sudah cukup. Mulailah dengan CPU, ukur angka yang paling mengganggu Anda, lalu tingkatkan sumber daya jika diperlukan.

Penyebabnya adalah bandwidth memori. Saat model bahasa menghasilkan satu token, model membaca semua bobot yang diperlukan dari memori. Model 8B yang dikuantisasi ke 4 bit berukuran sekitar 4.7 GB di disk dan kurang lebih sama di memori. Artinya, pembuatan satu token memerlukan pemindahan sekitar 4.7 GB data. Bagi bandwidth memori mesin dengan angka tersebut, dan Anda mendapatkan batas atas token per detik. Pembagian tunggal ini menjelaskan hampir semua benchmark yang akan Anda baca.

Yang Sebenarnya Anda Dapatkan dari GPU

Bandwidth. Server DDR5 pada host modern dapat memindahkan puluhan gigabyte per detik. Memori GPU (VRAM, video RAM) dapat memindahkan ratusan hingga lebih dari seribu gigabyte per detik. Perbandingan 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 dapat berjalan, tetapi kecepatannya lebih mendekati membaca daripada bercakap-cakap. GPU hanya membantu jika model tersebut muat di VRAM, karena begitu layer meluber ke RAM sistem, jalur lambat kembali digunakan.

Throughput batch. Bagian ini sering diremehkan. GPU yang menghasilkan output untuk satu pengguna menyisakan sebagian besar kapasitas komputasinya dalam keadaan idle karena sedang menunggu memori. Layani 20 request sekaligus, dan pembacaan bobot yang sama dapat digunakan untuk semua 20 request. Total token per detik meningkat beberapa kali lipat, sedangkan kecepatan per pengguna hanya sedikit menurun. CPU tidak bekerja seperti ini. Dua pengguna yang berjalan secara bersamaan pada mesin CPU kira-kira akan membagi kecepatan satu sama lain. Jika Anda membangun API yang digunakan banyak klien, batching adalah alasan utama memilih GPU, bahkan lebih penting daripada kecepatan satu aliran secara mentah.

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

Angka perkiraan dan cara membacanya

Blok di bawah ini berisi angka performa single-stream yang umum dipublikasikan untuk model 8B dengan kuantisasi 4-bit, per Juli 2026. Angka tersebut hanya menjadi panduan berdasarkan orde besaran, bukan jaminan. Kuantisasi, panjang konteks, dan inference engine 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 komputer CPU DDR5. Itu kira-kira lima kali lebih cepat. Perbandingan ini mengikuti rasio bandwidth, bukan perbedaan komputasi mentah. Throughput aktual juga berada di bawah hasil pembagian bandwidth dengan ukuran model karena attention pada konteks yang terus bertambah menambah beban kerja yang tidak diperhitungkan oleh 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 setup yang hanya menggunakan CPU ternyata sudah cukup baik.

Menentukan kapasitas VRAM sebelum membeli

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

Aturan praktis per Juli 2026: ambil ukuran file model dalam gigabita, lalu tambahkan 20 persen untuk context 8k hingga 16k yang umum. Model 8B berukuran 4.7 GB memerlukan sekitar 6 GB VRAM. Model 27B pada 4 bit berukuran sekitar 16 GB dan memerlukan kurang lebih 20 GB. Model 70B pada 4 bit berukuran sekitar 40 GB dan memerlukan kartu 48 GB, atau dua kartu yang lebih kecil. Perhitungan yang sama tetap berlaku jauh di atas ukuran tersebut, dan perhitungan VRAM untuk model 2.8 triliun parameter seperti Kimi K3 menunjukkan kapan pemilihan kartu tidak lagi menjadi persoalan utama.

Context yang panjang membuat aturan ini tidak berlaku. KV cache bertambah secara linear terhadap panjang context, dan pada 128k token ukurannya dapat melebihi bobot model itu sendiri. Jika Anda berencana menggunakan context yang panjang, tentukan kapasitas berdasarkan cache terlebih dahulu dan periksa dukungan engine Anda terhadap kuantisasi cache.

Periksa kondisi aktual mesin

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

nvidia-smi

Tabel tersebut 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 belum dibangun ulang setelah pemutakhiran kernel. Pada image Ubuntu standar, solusinya biasanya 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 harus ditampilkan. 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 dan lakukan restart. Di Compose, padanannya adalah entri deploy.resources.reservations.devices yang memiliki driver bernilai nvidia dan daftar kemampuannya berisi gpu. Entri ini dapat dimasukkan ke dalam definisi service biasa yang dibahas di Docker Compose pada VPS.

Ukur sebelum melakukan upgrade

Jalankan model yang benar-benar akan Anda gunakan pada mesin CPU yang sudah tersedia, lalu catat hasilnya. Dengan Ollama untuk menjalankan LLM sendiri pada 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 informasi waktu. eval rate adalah kecepatan pembuatan token per detik. prompt eval rate menunjukkan seberapa cepat mesin membaca input Anda. Kedua angka ini menunjukkan upgrade yang paling bermanfaat: eval rate yang rendah menandakan masalah bandwidth memori, sedangkan prompt eval rate yang rendah pada input panjang menandakan masalah komputasi.

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

ollama ps

Kolom PROCESSOR berisi 100% GPU jika seluruh model dapat dimuat, atau nilai seperti 43%/57% CPU/GPU jika tidak. Pembagian model secara parsial biasanya 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 tersebut dihitung untuk setiap jam instance aktif, bukan berdasarkan jumlah token yang dihasilkan. GPU yang selalu aktif untuk melayani beberapa permintaan per hari merupakan cara paling mahal untuk menjalankan inferensi. Titik impasnya adalah utilisasi: GPU yang sibuk memiliki biaya rendah per token, sedangkan GPU yang menganggur hanya membuang biaya.

Ada tiga pola yang dapat diterapkan. Jalankan pekerjaan bervolume rendah tetapi stabil pada VPS CPU. Kirim permintaan sulit yang hanya sesekali ke API terkelola dan bayar berdasarkan jumlah token. Sewa GPU per jam untuk pekerjaan batch, fine-tuning, atau proses embedding dalam jumlah besar, lalu hapus instance tersebut. Menggabungkan ketiganya merupakan 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.

Hal yang tetap berjalan dengan baik tanpa GPU

Embeddings dalam volume rendah. Model embedding berukuran kecil dapat memproses ratusan dokumen pendek per menit dengan beberapa core CPU. Indeks yang dibuat satu kali tidak perlu diproses dengan cepat.

Whisper small dan base untuk transkripsi. Faster-whisper pada CPU dapat melakukan transkripsi hampir secara real-time untuk model small. Kemampuan ini cukup untuk pipeline yang dijalankan sepanjang malam.

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

Apa pun yang dapat disebut sebagai batch job. Jika tidak ada yang memantau layar, kecepatan waktu nyata hanya menjadi persoalan penjadwalan, bukan persyaratan.

Hal yang benar-benar memerlukan GPU adalah 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 berukuran 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.

Apakah saya dapat menjalankan Ollama tanpa GPU?

Ya. Ollama 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 panjang menjadi kendala utama pada CPU karena membaca konteks sebanyak 30,000 token membutuhkan banyak komputasi dan jauh lebih lama daripada menghasilkan jawaban.

Mengapa GPU saya hampir tidak lebih cepat daripada CPU?

Penyebab yang umum adalah model tidak sepenuhnya muat di VRAM. Akibatnya, beberapa layer berjalan pada CPU dan setiap token harus menunggu bagian yang lebih lambat. Jalankan ollama ps dan periksa apakah kolom PROCESSOR menunjukkan 100% GPU. Jika terdapat pembagian beban, 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 GPU VPS layak digunakan untuk satu pengguna?

Biasanya tidak. Satu orang membaca dengan kecepatan 5 hingga 10 kata per detik, sedangkan server CPU sudah dapat menghasilkan token lebih cepat daripada itu untuk model hingga sekitar 13B. Kasus yang dapat membenarkan biayanya untuk satu pengguna adalah prompt 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 muncul secara berkala, seperti fine-tuning, proses embedding massal, atau pekerjaan transkripsi batch. Jalankan terus-menerus hanya jika GPU selalu sibuk, karena instance GPU ditagihkan berdasarkan waktu aktif, bukan jumlah token yang dihasilkan. Assistant dengan trafik rendah lebih murah dijalankan pada CPU VPS atau menggunakan hosted API dengan pembayaran per token daripada pada GPU yang menganggur.