--- title: "Menjalankan LLM di VPS Tanpa GPU, Seberapa Lambat?" description: "LLM bisa jalan di VPS tanpa GPU, tapi kecepatannya dibatasi RAM dan bandwidth memori. Cara menghitung perkiraan, memilih model, dan mengujinya." url: "https://nivelva.com/insight/menjalankan-llm-vps-gpu-lambat" category: "AI \u0026 Otomasi" tags: ["llm","vps","cpu inference","ollama","llama.cpp"] author: "Theresia Candiawan" published: "2026-11-07T14:10:00+07:00" updated: "2026-11-07T14:10:00+07:00" language: "id" publisher: "Nivelva (https://nivelva.com)" --- # Menjalankan LLM di VPS Tanpa GPU, Seberapa Lambat? > **Jawaban singkat:** Model kecil (1 sampai 4 miliar parameter, terkuantisasi) cukup nyaman di VPS tanpa GPU. Model 7 sampai 8 miliar parameter bisa jalan tetapi terasa lambat untuk chat, dan model di atas itu umumnya hanya cocok untuk tugas latar belakang. Kecepatan terutama dibatasi bandwidth memori, bukan jumlah core. Jawaban singkatnya: bisa, dan untuk model kecil kecepatannya masih wajar, tetapi untuk model menengah ke atas kamu harus siap menunggu. Seberapa lambat tergantung tiga hal: ukuran model, tingkat kuantisasi, dan seberapa cepat CPU bisa membaca memori. Kenapa ini penting? Sewa server GPU jauh lebih mahal daripada VPS biasa. Banyak tim ingin mencoba AI lokal untuk menjaga data tetap di server sendiri, dan VPS tanpa GPU adalah titik awal yang paling terjangkau. Mengetahui batasnya sejak awal mencegah kamu membeli spesifikasi yang salah atau menyimpulkan "AI lokal tidak layak" padahal modelnya yang terlalu besar. ## Kenapa CPU lebih lambat dari GPU untuk LLM? Saat menghasilkan setiap token, model harus membaca hampir seluruh bobotnya dari memori. Model 8 miliar parameter yang dikuantisasi ke 4 bit berukuran sekitar 4,5 sampai 5 GB. Artinya, untuk satu token, kurang lebih sebanyak itu data harus mengalir dari RAM ke prosesor. GPU unggul karena memori VRAM-nya punya bandwidth sangat tinggi. RAM server biasa jauh lebih lambat, dan di VPS, bandwidth itu juga dibagi dengan pengguna lain di mesin fisik yang sama. Jadi yang membatasi kecepatan biasanya bukan jumlah vCPU, melainkan seberapa cepat data bisa dibaca dari memori. Hitungan kasarnya begini: **batas atas token per detik ≈ bandwidth memori efektif ÷ ukuran file model**. Kalau VPS kamu efektif bisa membaca 20 GB per detik dan modelnya 5 GB, batas teoretisnya sekitar 4 token per detik. Kenyataannya biasanya lebih rendah. Angka bandwidth ini berbeda antar penyedia dan paket, jadi anggap rumus ini alat perkiraan, lalu ukur sendiri. ## Dua fase yang sama-sama terasa Ada dua tahap saat model menjawab: - **Membaca prompt (prefill).** Model memproses semua teks masukan dulu. Di CPU, tahap ini berat untuk prompt panjang. Kalau kamu menempelkan dokumen beberapa halaman atau memakai RAG dengan konteks besar, jeda sebelum kata pertama muncul bisa terasa lama. - **Menulis jawaban (generate).** Token keluar satu per satu dengan kecepatan yang dibatasi bandwidth memori seperti dijelaskan di atas. Untuk chatbot dengan pertanyaan pendek, fase kedua yang dominan. Untuk ringkasan dokumen, fase pertama sering lebih menyita waktu. ## Model ukuran berapa yang masuk akal? Tabel berikut memakai perkiraan ukuran file model terkuantisasi 4 bit (format GGUF Q4_K_M atau sejenisnya). Ukuran sebenarnya sedikit berbeda antar model. | Ukuran model | Perkiraan file Q4 | RAM VPS minimal yang nyaman | Kesan pemakaian di CPU | |:--|:--|:--|:--| | 1 sampai 2 miliar | sekitar 1 sampai 1,5 GB | 4 GB | Cukup responsif, kualitas terbatas | | 3 sampai 4 miliar | sekitar 2 sampai 2,5 GB | 4 sampai 8 GB | Nyaman untuk tugas ringan | | 7 sampai 8 miliar | sekitar 4,5 sampai 5 GB | 8 sampai 16 GB | Bisa dipakai, terasa lambat untuk chat | | 12 sampai 14 miliar | sekitar 8 sampai 9 GB | 16 GB | Lambat, cocok untuk tugas latar belakang | | 30 miliar ke atas | 18 GB ke atas | 32 GB ke atas | Sangat lambat, jarang layak di VPS | RAM perlu lebih besar dari ukuran file karena ada kebutuhan untuk konteks percakapan (KV cache), sistem operasi, dan aplikasi lain. Konteks yang panjang memakan memori tambahan. Arti kuantisasi Q4, Q5, dan Q8 dibahas di [apa itu kuantisasi model AI](https://nivelva.com/insight/apa-itu-kuantisasi-model-ai-seperti-q4-q8). ## Tugas yang cocok untuk VPS tanpa GPU - Mengklasifikasi atau memberi label pesan masuk, misalnya memilah email ke kategori. - Mengekstrak data terstruktur dari teks pendek seperti nama, nomor pesanan, dan tanggal. - Meringkas dokumen pendek secara terjadwal di malam hari. - Membuat embedding untuk pencarian dokumen (model embedding jauh lebih kecil dari model chat). - Prototipe dan uji coba sebelum memutuskan membeli GPU. Yang kurang cocok: chatbot publik dengan banyak pengguna bersamaan, asisten coding, dan analisis dokumen panjang yang harus cepat. Di CPU, permintaan bersamaan saling berebut bandwidth memori yang sama, jadi setiap pengguna tambahan memperlambat semuanya. ## Bagaimana cara mengukur kecepatannya sendiri? Cara termudah adalah memasang Ollama, lalu menjalankan model dengan opsi verbose: ``` ollama run llama3.2:3b --verbose ``` Setelah setiap jawaban, Ollama menampilkan statistik seperti `prompt eval rate` (kecepatan membaca prompt) dan `eval rate` (kecepatan menulis jawaban) dalam token per detik. Panduan pemasangannya ada di [cara menjalankan LLM dengan Ollama](https://nivelva.com/insight/menjalankan-llm-lokal-ollama). Kalau memakai llama.cpp langsung, tersedia alat `llama-bench` yang mengukur kedua fase itu dengan lebih terkontrol. Perbandingan kedua alat untuk server kecil ada di [llama.cpp atau Ollama](https://nivelva.com/insight/llama-cpp-ollama-server-kecil). Sebagai patokan rasa, kecepatan membaca orang dewasa kira-kira setara beberapa token per detik. Di bawah itu, jawaban terasa merayap. Untuk tugas latar belakang yang tidak ditunggu manusia, kecepatan rendah tidak terlalu masalah. > **Tips:** > > Pastikan model muat penuh di RAM. Kalau sebagian memori model terdorong ke swap di disk, kecepatannya bisa turun drastis sampai tidak terpakai. Sisakan ruang RAM beberapa GB di luar ukuran file model. ## Cara memaksimalkan VPS yang ada 1. **Pilih model sekecil mungkin yang masih memenuhi kebutuhan.** Uji model 3 miliar dulu sebelum naik ke 7 atau 8 miliar. 2. **Pakai kuantisasi 4 bit.** Q8 lebih akurat tetapi file-nya hampir dua kali lipat, berarti hampir dua kali lebih lambat di CPU. 3. **Batasi panjang konteks.** Konteks yang tidak perlu panjang menghemat RAM dan mempercepat tahap prefill. 4. **Atur jumlah thread.** Di VPS, memakai semua vCPU tidak selalu paling cepat. Coba beberapa nilai dan ukur. 5. **Antrekan permintaan.** Untuk otomasi, proses permintaan satu per satu lewat antrean daripada sekaligus. Kalau setelah semua itu kecepatannya tetap tidak memadai, itu tanda kamu butuh GPU atau model lewat API. Berapa VRAM yang dibutuhkan untuk tiap ukuran model dibahas di [kebutuhan VRAM GPU untuk LLM](https://nivelva.com/insight/kebutuhan-vram-gpu-llm). ## Pertanyaan yang sering diajukan ### Apakah menambah vCPU membuat LLM jauh lebih cepat? Tidak selalu. Tambahan core membantu tahap membaca prompt, tetapi kecepatan menulis jawaban lebih dibatasi bandwidth memori. Setelah titik tertentu, menambah core hampir tidak berpengaruh. ### Apakah AVX atau jenis prosesor berpengaruh? Ya. llama.cpp memanfaatkan instruksi CPU modern seperti AVX2 dan AVX-512 bila tersedia. Prosesor generasi lebih baru dengan memori lebih cepat biasanya memberi hasil lebih baik. ### Lebih hemat VPS dengan model lokal atau API? Untuk volume kecil, API model murah sering lebih hemat dan jauh lebih cepat. Model lokal di VPS menarik bila data tidak boleh keluar server, volumenya tinggi untuk tugas sederhana, atau kamu ingin biaya tetap per bulan. ## Sumber - - --- Diterbitkan oleh Nivelva Insight (https://nivelva.com/insight/). Artikel ini: https://nivelva.com/insight/menjalankan-llm-vps-gpu-lambat Kontak Nivelva: WhatsApp https://wa.me/6285111245007, email hello@nivelva.com