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 di memori. Selain itu, tidak ada yang berubah. Jika beban kerja Anda adalah model chat 7B hingga 27B terkuantisasi yang menjawab satu orang setiap kali, pekerjaan embedding bervolume rendah, atau transkripsi suara dengan Whisper small, VPS CPU biasa dengan RAM yang cukup sudah dapat menjalankan semuanya. Mulailah dengan CPU, ukur hal yang paling mengganggu, lalu tingkatkan sesuai kebutuhan.

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

Apa manfaat GPU sebenarnya

Bandwidth. Server DDR5 pada host modern memproses puluhan gigabita per detik. Memori GPU (VRAM, video RAM) memproses ratusan hingga lebih dari seribu gigabita per detik. Rasio tersebut menentukan speedup, dan nilainya besar.

Kapasitas dengan kecepatan. Komputer berbasis 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 dapat dimuat dalam VRAM, karena begitu beberapa layer meluber ke RAM sistem, jalur lambat kembali menjadi faktor pembatas.

Throughput batch. Ini adalah bagian yang sering diremehkan. GPU yang menghasilkan output untuk satu pengguna membiarkan sebagian besar komputasinya menganggur karena GPU sedang menunggu memori. Layani 20 request sekaligus, dan pembacaan weight yang sama dapat digunakan untuk seluruh 20 request. Token per detik secara agregat meningkat beberapa kali lipat, sedangkan kecepatan per pengguna hanya sedikit menurun. Mesin inferensi CPU seperti llama.cpp juga mendukung batching, dengan peningkatan yang bergantung pada hardware dan workload. Jika Anda membangun API yang dipanggil banyak klien, batching adalah alasan utama menggunakan GPU, lebih daripada kecepatan single-stream mentah.

Pemrosesan prompt. Membaca prompt panjang lebih dibatasi oleh komputasi daripada memori, dan di sinilah GPU unggul dengan margin terbesar. Context 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 mengalami perbedaan ini.

Perkiraan kasar dan cara membacanya

Throughput aktual juga berada di bawah hasil pembagian bandwidth dengan ukuran model, karena mekanisme attention pada context yang terus bertambah menambah beban kerja yang tidak diperhitungkan oleh pembagian sederhana tersebut.

Sebagai perbandingan, kecepatan membaca dalam hati oleh orang dewasa dalam bahasa Inggris rata-rata sekitar 4.0 hingga 4.3 kata per detik: 238 kata per menit untuk nonfiksi dan 260 untuk fiksi. Kecepatan 15 token per detik atau lebih sudah terasa seperti kecepatan mengetik normal bagi satu pembaca. Karena itu, banyak setup yang hanya menggunakan CPU sebenarnya sudah memadai.

Menentukan ukuran VRAM sebelum membeli

Ukuran file model adalah batas minimum, bukan kebutuhan total. Alokasikan ruang untuk weight, KV cache (key-value cache, yaitu memori per token yang dipertahankan oleh attention), serta sekitar 1 GB overhead.

Hitung kebutuhan cache secara khusus, bukan dengan menambahkan persentase tetap, karena kuantisasi weight tidak mengkuantisasi cache. Untuk setiap token, model dengan full attention menyimpan key dan value untuk setiap layer dan setiap KV head, dengan ukuran 2 byte per angka dalam FP16, yang merupakan jenis cache default Ollama. Metadata model Ollama, yang diperiksa pada 2026-10-27, mencantumkan 32 layer dan 8 KV head dengan 128 dimensi untuk Llama 3.1 8B. Hasilnya adalah 128 KiB per token: sekitar 1.07 GB pada context 8k dan 2.15 GB pada 16k. Jadi, model 8B berukuran 4.9 GB memerlukan sekitar 7 GB VRAM pada 8k dan sekitar 8 GB pada 16k. Model 27B pada 4 bit berukuran sekitar 17 GB (Gemma 3 27B di library Ollama). Metadata Gemma 3 mencantumkan sliding window 1,024 token, sehingga sebagian besar cache-nya tidak terus bertambah. Karena itu, siapkan 20 GB atau lebih. Model 70B pada 4 bit berukuran sekitar 43 GB (Llama 3.3 70B). Dengan 80 layer, cache FP16-nya menambah sekitar 2.7 GB pada 8k dan 5.4 GB pada 16k. Jadi, model tersebut memerlukan kartu 48 GB dengan sisa yang sangat sedikit, 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 bukan lagi persoalan utama.

Context panjang adalah kondisi yang paling terpengaruh. Pada model dengan full attention seperti Llama 3.1, KV cache bertambah secara linear sesuai panjang context. Pada 128k token, ukurannya dapat melebihi weight model. Model dengan sliding-window attention atau chunked attention berbeda. Dokumentasi Transformers dari Hugging Face menyebut Mistral, Gemma 2, dan Llama 4 sebagai contoh model yang cache-nya pada layer tersebut berhenti bertambah setelah mencapai ukuran window atau chunk. Karena itu, total kebutuhannya bertambah lebih lambat. Jika Anda berencana menggunakan context panjang, tentukan ukuran berdasarkan cache terlebih dahulu dan periksa dukungan engine untuk kuantisasi cache. Di Ollama, OLLAMA_KV_CACHE_TYPE=q8_0 menggunakan sekitar setengah memori dibandingkan f16 default, dan kuantisasi cache hanya berlaku jika Flash Attention diaktifkan. Tetapkan panjang context secara eksplisit. Ollama memilih nilai default berdasarkan VRAM: 4k di bawah 24 GiB, 32k dari 24 hingga 48 GiB, dan 256k pada 48 GiB atau lebih. Pada kartu 48 GB yang menjalankan model 70B, nilai default tersebut meminta cache yang jauh lebih besar daripada kapasitas kartu.

Periksa kondisi aktual mesin

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

nvidia-smi

Tabel tersebut harus menampilkan nama GPU, versi driver, serta penggunaan memori dibandingkan total memori. NVIDIA-SMI has failed because it couldn't communicate with the NVIDIA driver berarti NVIDIA-SMI tidak dapat mengakses driver. Periksa apakah driver sudah terpasang dan modul kernelnya sudah dimuat. Pada image Ubuntu standar, perbaikannya biasanya adalah sudo apt install -y ubuntu-drivers-common && sudo ubuntu-drivers install, lalu reboot agar modul baru dimuat. Untuk mesin komputasi, dokumentasi server Ubuntu merekomendasikan sudo ubuntu-drivers install --gpgpu, yang memilih cabang driver untuk server.

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 muncul. Baris docker: Error response from daemon: could not select device driver yang menyebutkan kemampuan GPU yang tidak dapat dipenuhi berarti Docker tidak menemukan driver perangkat yang sesuai dengan permintaan tersebut. Pastikan toolkit sudah terpasang, lalu jalankan kembali baris nvidia-ctk dan restart. Dalam Compose, padanannya adalah entri deploy.resources.reservations.devices yang memiliki driver bernilai nvidia dan daftar capabilities yang 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 tentang biaya

Instans GPU ditagih berdasarkan waktu komputasi yang disediakan, bukan jumlah token. Tarif dan biaya untuk instans yang dihentikan ditetapkan oleh penyedia. GPU yang selalu aktif untuk melayani beberapa permintaan per hari akan menghabiskan sebagian besar waktu berbayarnya dalam keadaan idle. Titik impasnya adalah tingkat utilisasi: GPU yang sibuk memiliki biaya per token yang rendah, sedangkan GPU yang idle hanya membuang biaya.

Ada tiga pola yang dapat diterapkan secara realistis. Jalankan pekerjaan bervolume rendah dan stabil pada CPU VPS. Kirim permintaan sulit yang hanya sesekali muncul ke API terkelola dan bayar per token. Sewa GPU per jam untuk pekerjaan batch, fine-tuning, atau proses embedding dalam jumlah besar, lalu hapus instans 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, tetapi sumber kebocorannya adalah waktu idle, bukan 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 7 GB untuk model 8B terkuantisasi 4-bit pada konteks 8k, dan sekitar 8 GB pada 16k, dengan cache FP16 default Ollama. Bobotnya sekitar 4.9 GB, cache KV menambahkan sekitar 1.07 GB pada 8k atau 2.15 GB pada 16k, sedangkan sisanya sekitar 1 GB merupakan overhead. GPU 8 GB dapat menanganinya pada 8k, tetapi kapasitasnya terbatas pada 16k. GPU 12 GB menyediakan ruang yang cukup untuk konteks yang lebih panjang. Mengubah cache menjadi q8_0 akan mengurangi penggunaan cache kira-kira setengahnya. Jika Anda berencana menjalankan konteks 128k, alokasikan kapasitas cache secara terpisah karena ukurannya dapat melebihi bobot model.

Apakah saya dapat menjalankan Ollama tanpa GPU?

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

Mengapa GPU saya hampir tidak lebih cepat daripada CPU?

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

Biasanya tidak. Kecepatan membaca senyap untuk orang dewasa dalam bahasa Inggris rata-rata sekitar 4.0 hingga 4.3 kata per detik. Sebelum membandingkan server CPU dengan kecepatan tersebut, token per detik harus dikonversi menjadi kata per detik. Penggunaan 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 berbagi pembacaan bobot untuk beberapa permintaan.

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

Sewa per jam jika beban kerja bersifat sporadis, seperti fine-tuning, pemrosesan embedding dalam jumlah besar, atau pekerjaan transkripsi batch. Jalankan terus-menerus hanya jika GPU tetap sibuk karena biaya komputasi GPU yang disediakan dihitung berdasarkan waktu, bukan jumlah token yang dihasilkan. Assistant dengan trafik rendah lebih murah dijalankan pada CPU VPS atau menggunakan API terkelola dengan pembayaran per token daripada menggunakan GPU yang menganggur.