LLM Lokal di VPS 4 GB: Hitung RAM Sebelum Unduh Model

Sebelum mengunduh model apa pun, hitung dulu: berkas model harus lebih kecil daripada RAM yang benar-benar tersedia, bukan RAM total yang tertulis di spesifikasi VPS. Pada host uji artikel ini, Ubuntu 24.04.5 LTS dengan kernel 6.8.0-147 melaporkan RAM total 3.915 MB, tetapi yang tersedia hanya 2.168 MB, dengan swap 6.143 MB yang sudah terpakai 1.859 MB. Artinya model 7 miliar parameter pada kuantisasi 8 bit yang berukuran sekitar 7 GB tidak akan muat, sementara model 3 miliar parameter pada kuantisasi 4 bit masih punya peluang.

TL;DR

• Ukuran model kira-kira sama dengan jumlah parameter dikali bit per bobot dibagi 8.
• RAM total bukan patokan; pakai kolom available dari free -m, di host ini 2.168 MB dari 3.915 MB.
• Swap 6.143 MB tidak menyelamatkan model yang terlalu besar, hanya memperlambat dan menambah tekanan memori.
• Model 7B kuantisasi 8 bit butuh sekitar 7 GB dan tidak realistis di mesin 4 GB.
• Ukur tekanan memori dengan /proc/pressure/memory sebelum menyalahkan modelnya.

Berapa RAM yang sebenarnya dibutuhkan sebuah model?

Perkiraan kasarnya adalah jumlah parameter dikali bit per bobot, lalu dibagi delapan untuk mendapat satuan byte. Model 7 miliar parameter pada 8 bit per bobot menghasilkan 7 GB berkas, sedangkan pada 4 bit per bobot turun menjadi sekitar 3,5 GB. Angka itu belum termasuk KV cache untuk konteks dan memori proses inference, yang pada model besar bisa menambah ratusan MB sampai beberapa GB tergantung panjang konteks yang dipakai.

Karena itu cara paling jujur adalah membaca ukuran berkas GGUF yang akan diunduh, bukan mengandalkan nama kuantisasinya. llama.cpp menyediakan alat kuantisasi yang menghasilkan berkas dengan ukuran berbeda per level, dan angka bit per bobot yang tertulis di dokumentasi adalah perkiraan agregat, bukan angka pasti per tensor. Selalu cocokkan dengan ukuran berkas nyata sebelum menyimpulkan model itu muat.

Model	Kuantisasi	Bit per bobot	Perkiraan ukuran	Muat di available 2.168 MB?
3B	4 bit	4,5	sekitar 1,7 GB	berpeluang, sisa tipis untuk KV cache
3B	8 bit	8	sekitar 3,0 GB	tidak
7B	4 bit	4,5	sekitar 3,9 GB	tidak, melebihi RAM
7B	8 bit	8	sekitar 7,0 GB	tidak
1B	4 bit	4,5	sekitar 0,6 GB	ya, dengan ruang untuk konteks

Hitungan di tabel memakai rumus sederhana jumlah parameter dikali bit per bobot dibagi 8, dan sengaja dibulatkan ke atas. Angka ini bukan hasil pengukuran model tertentu, melainkan batas bawah yang berguna untuk menyaring pilihan sebelum menghabiskan waktu mengunduh berkas berukuran gigabyte.

Kenapa RAM total di spesifikasi VPS menyesatkan?

Karena sistem operasi, layanan, dan cache sudah memakai sebagian besar RAM sebelum model dijalankan. Pada host ini, dari 3.915 MB total, hanya 2.168 MB yang tersedia, sementara 1.747 MB sudah dipakai proses berjalan dan 2.287 MB dipakai sebagai buff/cache yang bisa diklaim kembali bila perlu. Selisih antara total dan available itulah ruang nyata yang bisa dipakai model tanpa memicu tekanan memori.

Untuk mesin yang juga menjalankan web server, database, dan agen otomasi, angka available bisa turun drastis pada jam sibuk. Menjalankan model inference di mesin yang sama dengan layanan produksi berarti model harus diberi batas memori eksplisit, misalnya lewat cgroup atau opsi pembatas memori pada runtime container. Tanpa batas, model akan berebut halaman memori dengan layanan lain dan keduanya menjadi lambat.

Bagaimana mengukur tekanan memori dengan benar?

Baca /proc/pressure/memory, karena berkas itu melaporkan persentase waktu ketika setidaknya satu tugas tertahan menunggu memori. Pada host ini nilai some adalah avg10=1,09 persen, avg60=1,35 persen, dan avg300=0,39 persen, yang berarti tekanan ringan namun nyata. Kernel mendokumentasikan format dan arti setiap kolom di halaman Pressure Stall Information.

Nilai some berarti ada minimal satu tugas yang tertahan, sedangkan full berarti semua tugas yang bisa berjalan ikut tertahan. Pada mesin dengan swap aktif, nilai full yang naik terus hampir selalu berarti thrashing: sistem menghabiskan waktu memindahkan halaman antara RAM dan disk, bukan menjalankan komputasi. Itu tanda paling jelas bahwa model yang dipilih terlalu besar, dan menambah swap bukan solusi karena swap berada di disk yang jauh lebih lambat daripada RAM.

Kapan sebaiknya menyerah dan memakai API saja?

Menyerah adalah pilihan rasional ketika ukuran model terbaik yang muat terlalu kecil untuk tugasnya, atau ketika latensi jadi lebih penting daripada privasi. Pada mesin 4 GB dengan available 2.168 MB, model yang muat hanya kelas 1B sampai 3B pada kuantisasi agresif, dan kualitasnya untuk tugas penalaran panjang biasanya tertinggal jauh dari model yang dilayani lewat API. Menjalankan model kecil di mesin sendiri masuk akal untuk klasifikasi, ekstraksi terstruktur, atau penyaringan awal, bukan untuk penulisan panjang.

Sebaliknya, model lokal tetap unggul ketika data tidak boleh keluar dari server, ketika biaya per permintaan harus nol, atau ketika koneksi internet tidak stabil. Untuk kasus seperti itu, kuantisasi 4 bit pada model 3B adalah kompromi yang paling realistis di kelas mesin ini.

Langkah apa yang harus dilakukan sebelum mengunduh?

Urutannya: ukur RAM tersedia, baca tekanan memori, hitung ukuran model, baru unduh. Empat perintah berikut cukup untuk tiga langkah pertama, dan semuanya hanya membaca berkas sistem tanpa mengubah apa pun.

free -m
cat /proc/pressure/memory
nproc
df -h /srv

Setelah model berjalan, pantau ulang free -m dan /proc/pressure/memory selama beberapa menit. Kalau nilai swap used naik terus dan PSI full melonjak, hentikan prosesnya sebelum sistem mulai membunuh proses lain lewat OOM killer. Mekanisme manajemen memori kernel, termasuk kapan halaman diambil dari cache dan kapan proses dibunuh, dijelaskan di dokumentasi manajemen memori kernel.

Bagaimana membatasi memori proses model agar tidak memicu OOM killer?

Beri batas memori eksplisit pada prosesnya, jangan mengandalkan kernel untuk mengambil keputusan sendiri. Pada sistem dengan cgroup versi 2, batas bisa dipasang lewat systemd-run dengan opsi MemoryMax, sehingga proses yang melewati batas akan ditangani pada level unit dan bukan dengan membunuh layanan lain di mesin yang sama. Pada host uji ini, dengan available hanya 2.168 MB, batas sekitar 1.500 MB menyisakan ruang untuk web server dan agen otomasi tetap hidup.

systemd-run --scope -p MemoryMax=1500M -p MemorySwapMax=512M   ./llama-cli -m model-q4.gguf -c 2048

Selain batas memori, panjang konteks adalah faktor kedua yang paling sering dilupakan. KV cache tumbuh mengikuti panjang konteks dan ukuran model, jadi menurunkan nilai -c dari 8192 ke 2048 bisa menghemat memori dalam jumlah yang berarti pada mesin kecil. Kalau model tetap gagal dimuat, turunkan konteks lebih dulu sebelum mengganti kuantisasi, karena perubahan konteks lebih murah dan mudah dibalik.

Yang perlu dihindari adalah membiarkan proses berjalan tanpa batas lalu berharap swap menyerap kelebihannya. Pada mesin dengan swap 6.143 MB yang sudah terpakai 1.859 MB, kelebihan permintaan memori akan mendorong halaman aktif ke disk dan membuat seluruh sistem, termasuk layanan yang tidak berhubungan, ikut melambat. Membunuh satu proses model jauh lebih baik daripada membuat semua layanan menunggu disk.

Apakah model kecil masih berguna untuk pekerjaan nyata?

Berguna untuk tugas yang sempit dan berulang: klasifikasi teks, ekstraksi field terstruktur, penyaringan awal sebelum permintaan diteruskan ke model besar, atau penandaan kategori. Model kelas 1B sampai 3B pada kuantisasi 4 bit cukup untuk pekerjaan seperti itu, terutama kalau keluarannya divalidasi dengan skema. Yang tidak realistis adalah memakai model sekecil itu untuk penalaran panjang atau penulisan dokumen berhalaman-halaman.

Satu angka yang sering ditanyakan tetapi tidak bisa dijawab dari artikel ini adalah kecepatan generasi token. Jumlah token per detik bergantung pada model, level kuantisasi, panjang konteks, dan lebar pita memori prosesor, dan angka itu belum diukur pada host ini karena belum ada model yang dijalankan saat pengukuran dilakukan. Klaim kecepatan tanpa pengukuran hanya akan menyesatkan, jadi sebaiknya uji sendiri dengan perintah benchmark yang disediakan runtime, lalu catat hasilnya bersama panjang konteks yang dipakai. Yang bisa dipastikan dari angka memori di atas: kalau modelnya tidak muat, kecepatan tidak lagi relevan karena prosesnya akan gagal dimuat atau terus-menerus bertukar halaman ke disk.

Ada satu pilihan lain yang kadang membantu pada mesin kecil: mengunci halaman memori proses supaya tidak dipindahkan ke swap. Pada runtime yang mendukung opsi tersebut, halaman model ditahan di RAM sehingga tidak pernah berpindah ke disk, dengan konsekuensi proses akan gagal lebih cepat kalau memori tidak cukup. Gagal cepat jauh lebih baik daripada lambat terus-menerus, karena kegagalan yang jelas bisa ditangani dengan mengganti model atau menambah kapasitas, sedangkan thrashing hanya membuat semua orang menunggu tanpa tahu penyebabnya. Apa pun opsinya, keputusan akhir tetap bergantung pada angka available yang terukur saat ini, bukan pada spesifikasi yang tertulis di halaman pembelian VPS.

FAQ

Apakah model 7B bisa jalan di VPS 4 GB?

Tidak dengan kuantisasi yang wajar. Pada 4 bit, model 7B masih berukuran sekitar 3,9 GB, sementara available di host uji hanya 2.168 MB. Memaksakannya akan memicu swap thrashing dan berakhir dengan OOM killer.

Apakah menambah swap menyelesaikan masalah?

Tidak. Swap hanya memberi ruang sementara, bukan kecepatan. Ketika model aktif bekerja, halaman memori terus berpindah ke disk sehingga latensi melonjak; nilai PSI full yang tinggi adalah tandanya.

Kuantisasi mana yang paling aman untuk RAM kecil?

Mulai dari 4 bit, karena ukurannya sekitar setengah dari 8 bit dengan penurunan kualitas yang masih bisa ditoleransi untuk banyak tugas. Verifikasi ukuran berkas GGUF yang sebenarnya sebelum mengunduh, karena angka bit per bobot hanya perkiraan.

Bagaimana memantau tekanan memori saat model berjalan?

Jalankan free -m dan cat /proc/pressure/memory secara berkala, lalu perhatikan kolom swap used dan PSI full. Penjelasan resmi ada di dokumentasi Pressure Stall Information.

Di mana dokumentasi kuantisasi dan runtime model lokal?

Proyek llama.cpp memuat alat kuantisasi dan runtime GGUF, sedangkan penjelasan konsep kuantisasi ada di dokumentasi kuantisasi Hugging Face. Keduanya sumber primer untuk memeriksa detail teknisnya.