Berapa RAM VPS untuk Coding Agent?

Berapa RAM yang dibutuhkan VPS untuk coding agent?

Mulai dengan RAM sebesar 4 GB dan 2 vCPU untuk satu coding agent yang selalu aktif dan bekerja dalam sebuah repositori. Gunakan RAM sebesar 8 GB dan 4 vCPU segera setelah language server atau build Docker ikut berjalan dalam sesi tersebut. Untuk sebagian besar repositori, kondisi ini terjadi sejak hari pertama. Proses agent itu sendiri berukuran kecil. Komponen yang paling banyak menggunakan sumber daya adalah toolchain yang dijalankan agent untuk Anda.

[
  {
    "plan": "Minimum viable",
    "ram_gb": 4,
    "vcpu": 2,
    "disk_gb": 50
  },
  {
    "plan": "Comfortable",
    "ram_gb": 8,
    "vcpu": 4,
    "disk_gb": 100
  },
  {
    "plan": "Team, 4 sessions",
    "ram_gb": 16,
    "vcpu": 8,
    "disk_gb": 200
  }
]

Setiap baris di atas mengasumsikan bahwa model berjalan di tempat lain, diakses melalui API melalui jaringan. Asumsi ini menentukan seluruh pertanyaan sizing, jadi pastikan hal tersebut terlebih dahulu.

Apakah Anda menjalankan agent atau model?

Coding agent yang memanggil model cloud adalah klien jaringan dengan shell yang terpasang. Agent mengirim file dan rencana ke API, menunggu respons, lalu mengedit file dan menjalankan perintah secara lokal. Saat menunggu, agent hampir tidak menggunakan CPU. Memori yang digunakannya hanya ratusan megabyte. Karena itu, mesin yang tepat adalah server dengan CPU sederhana.

Menjalankan model sendiri adalah produk yang berbeda dan memerlukan hardware yang berbeda. Weights tetap berada di memori selama server aktif. Model dengan 7 miliar parameter yang di-quantise ke 4 bit memerlukan sekitar 5 GB hanya untuk weights, belum termasuk key/value cache yang bertambah sesuai panjang context. Jika hanya menggunakan CPU, shared vCPU menghasilkan beberapa token per detik. Satu tugas agent dapat menghasilkan ribuan token. Akibatnya, pekerjaan yang selesai dalam waktu kurang dari satu menit melalui API dapat memerlukan hampir satu jam jika dijalankan secara lokal. Jika itu yang Anda inginkan, tentukan kapasitas berdasarkan VRAM (memori video pada GPU) dan baca apa yang sebenarnya disediakan VPS dengan GPU alih-alih halaman ini.

Semua bagian di bawah ini mengasumsikan penggunaan model cloud.

Yang sebenarnya menggunakan memori

[
  {
    "label": "Agent CLI process, idle",
    "typical_mb": 250,
    "peak_mb": 600
  },
  {
    "label": "TypeScript language server",
    "typical_mb": 700,
    "peak_mb": 2000
  },
  {
    "label": "rust-analyzer, large workspace",
    "typical_mb": 1200,
    "peak_mb": 4000
  },
  {
    "label": "Headless Chrome, one tab",
    "typical_mb": 350,
    "peak_mb": 900
  },
  {
    "label": "Node test run, 4 workers",
    "typical_mb": 1600,
    "peak_mb": 3000
  },
  {
    "label": "Docker image build",
    "typical_mb": 800,
    "peak_mb": 2500
  }
]

Angka tersebut adalah angka publikasi yang umum untuk proyek berukuran menengah. Gunakan sebagai gambaran, bukan sebagai jaminan untuk kode Anda.

Bagan tersebut memuat 6 baris, dan agent adalah komponen yang paling hemat. Saat idle, penggunaan memorinya sekitar 250 MB karena hanya menyimpan percakapan dan cache file kecil. Language server TypeScript mencapai sekitar 2000 MB saat melakukan indexing karena membangun type graph untuk setiap file yang dapat dijangkau dari tsconfig.json, lalu menyimpan graph tersebut di memori agar dapat menjawab permintaan berikutnya dengan cepat. rust-analyzer pada workspace besar umumnya melewati 4000 MB karena alasan yang sama, untuk setiap crate di workspace.

Headless Chrome menggunakan sekitar 350 MB untuk browser dan satu tab. Setiap tab tambahan merupakan proses sistem operasi lain. Proses pengujian Node dengan empat worker terdiri atas empat proses Node, sehingga penggunaan memorinya mencapai sekitar 3000 MB. Build image Docker mencapai sekitar 2500 MB karena proses build menjalankan compiler milik proyek Anda di dalam container, sementara daemon menulis layer.

sudo apt update && sudo apt install -y time
/usr/bin/time -v -o /tmp/build.rusage npm run build
grep "Maximum resident set size" /tmp/build.rusage

Baca kolom available dari free -h, bukan kolom free. Linux menggunakan setiap halaman kosong untuk disk cache, sehingga free bernilai kecil pada server yang sepenuhnya sehat dan tidak memberi informasi yang berguna. available menunjukkan memori yang sebenarnya dapat diperoleh proses baru.

Tiga konfigurasi yang dapat digunakan

Minimum yang layak: 4 GB RAM, 2 vCPU, 50 GB disk. Satu sesi agent, satu repository, satu language server, serta proses build yang masih dapat Anda tunggu. Tier ini dapat digunakan, tetapi akan mengalami out-of-memory killer saat test run besar berlangsung bersamaan dengan proses indexing language server. Tambahkan swap dan batasi jumlah build worker.

Nyaman: 8 GB RAM, 4 vCPU, 100 GB disk. Satu agent, ditambah Docker dan headless browser untuk pengujian, dengan kapasitas tersisa untuk satu lonjakan beban build. Ini adalah tier yang sebaiknya dipilih sebagian besar developer yang bekerja sendiri. Menggandakan jumlah vCPU juga secara kasar mengurangi separuh waktu tunggu build. Dampak ini lebih sering terasa daripada kekurangan memory.

Tim: 16 GB RAM, 8 vCPU, 200 GB disk. Empat sesi yang berjalan bersamaan, masing-masing dengan checkout dan toolchain sendiri. Tentukan ukuran berdasarkan beban puncak, karena empat agent yang idle hampir tidak membebani server, sedangkan empat test run pada saat yang sama memerlukan biaya empat kali lipat dari kolom puncak di atas.

Per August 2026, perbedaan antara baris pertama dan baris terakhir kira-kira empat kali lipat dari harga bulanan pada penagihan VPS tahunan: beberapa dolar per bulan pada tier terbawah dan puluhan dolar pada tier teratas. Periksa daftar harga terbaru sebelum membuat rencana, karena angka tersebut dapat berubah. Server jarang menjadi komponen yang mahal. Bagi siapa pun yang menjalankan agent setiap hari, tagihan model API akan segera melebihi tagihan server. Karena itu, batasi pengeluaran yang diizinkan untuk agent sebelum Anda memilih server dengan spesifikasi lebih rendah. Untuk proses build itu sendiri, panduan menjalankan coding agent pada VPS menjelaskan penyiapan account dan cara mempertahankan sesi tetap aktif setelah Anda disconnect.

Mengapa ruang disk habis sebelum RAM

[
  {
    "label": "Ubuntu 24.04 base and toolchain",
    "typical_gb": 6
  },
  {
    "label": "One JS monorepo checkout",
    "typical_gb": 3
  },
  {
    "label": "node_modules across 3 branches",
    "typical_gb": 4
  },
  {
    "label": "Docker images and build cache",
    "typical_gb": 20
  },
  {
    "label": "Agent logs and journal, 90 days",
    "typical_gb": 2
  }
]

Jika semua baris tersebut dijumlahkan, disk berukuran 50 GB hampir penuh sebelum Anda menulis satu baris kode pun. Item tunggal terbesar adalah Docker, sekitar 20 GB, karena BuildKit menyimpan setiap layer perantara dari setiap build sampai Anda menghapusnya.

docker system df
docker builder prune --filter until=168h

docker system df menampilkan ruang yang dapat diklaim kembali untuk setiap kategori, jadi jalankan sebelum dan sesudah pembersihan. Filter until=168h menghapus build cache yang berusia lebih dari satu minggu dan mempertahankan cache minggu ini, yaitu cache yang masih menghemat waktu. docker image prune -a melakukan pembersihan lebih jauh dengan menghapus setiap image yang tidak digunakan oleh container mana pun, sehingga build berikutnya harus mengunduhnya kembali.

Project Node gagal dengan cara yang lebih sulit didiagnosis. npm install membuat ratusan ribu file kecil, sehingga filesystem dapat kehabisan inode meskipun df -h masih melaporkan ruang kosong dalam jumlah gigabyte. Penulisan kemudian gagal dengan No space left on device pada disk yang terlihat masih setengah kosong.

df -h /
df -i /

Jika IUse% membaca angka 100, hapus direktori node_modules dari branch yang tidak lagi Anda gunakan, atau beralih ke pnpm, yang menyimpan setiap versi package satu kali lalu membuat hard link ke versi tersebut dari setiap project.

Log adalah penyebab yang sering tidak terlihat. Agent yang selalu aktif menulis transkrip sesi, dan journal systemd secara default terus membesar hingga menggunakan sebagian ruang disk.

sudo journalctl --disk-usage
sudo journalctl --vacuum-size=200M
du -xh --max-depth=1 / 2>/dev/null | sort -h | tail

Atur SystemMaxUse=200M di /etc/systemd/journald.conf, lalu jalankan sudo systemctl restart systemd-journald agar batas tersebut tetap berlaku. Vacuum yang dijalankan satu kali hanya mengembalikan ruang yang tersedia hari ini.

Swap: manfaat dan hal yang disembunyikannya

Swap layak ditambahkan karena dapat mengubah kelebihan penggunaan memori dalam jumlah kecil menjadi proses yang berjalan lambat, bukan proses yang terhenti. Atur ukurannya sebesar setengah RAM, hingga sekitar 4 GB. Pada build box, biasanya tidak ada alasan untuk menambahnya melebihi ukuran tersebut.

sudo fallocate -l 4G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab
swapon --show

swapon --show sekarang seharusnya menampilkan /swapfile dengan ukuran yang Anda minta. Tanpa baris /etc/fstab, swap akan hilang setelah reboot berikutnya dan box akan diam-diam kembali ke perilaku sebelumnya. Jika fallocate menjawab Operation not supported, buat file tersebut dengan sudo dd if=/dev/zero of=/swapfile bs=1M count=4096, lalu lanjutkan dari chmod.

echo 'vm.swappiness = 10' | sudo tee /etc/sysctl.d/99-swappiness.conf
sudo sysctl --system

Nilai swappiness yang rendah memberi tahu kernel untuk merebut kembali cache disk sebelum memindahkan memori program ke disk. Dengan demikian, language server tetap responsif.

Sekarang, perhatikan hal yang disembunyikan swap. Jika sebuah job benar-benar membutuhkan memori lebih besar daripada kapasitas box, kernel akan menghabiskan waktunya untuk memindahkan page antara RAM dan disk, bukan menjalankan build Anda. Tidak ada yang crash. Semua proses berjalan sangat lambat, dan load average meningkat sementara CPU tetap menganggur.

vmstat 1 10

Angka non-zero yang terus muncul pada kolom si dan so berarti terjadi swapping secara terus-menerus. Solusinya adalah mengurangi konkurensi atau menambah RAM, bukan menambah swap. Pada box kecil, sudo apt install -y zram-tools menyediakan swap terkompresi yang disimpan di RAM dan dikonfigurasi dalam /etc/default/zramswap. Mekanisme ini jauh lebih cepat daripada swap file. Namun, mekanisme ini menggunakan RAM untuk menghemat RAM, sehingga membantu untuk page yang jarang digunakan, bukan untuk build yang benar-benar membutuhkan working memory.

Mengapa coding agent Anda tampak macet

Ini adalah kegagalan yang paling sering salah didiagnosis pada server kecil untuk agent. Sebuah perintah tidak menghasilkan output, agent menunggu, dan sesi tampak membeku. Proses tersebut dihentikan oleh kernel melalui out-of-memory (OOM) killer. Proses menerima SIGKILL, sehingga tidak dapat mencetak error, menulis sisa log, atau memberi tahu agent tentang penyebabnya. Agent hanya melihat hasil kosong tanpa pesan keluar.

Kernel tetap mencatat kejadian tersebut:

sudo dmesg -T | grep -iE "out of memory|killed process"
sudo journalctl -k -b | grep -i oom

Contoh barisnya adalah sebagai berikut:

[Thu Aug  6 11:02:14 2026] Out of memory: Killed process 4711 (node) total-vm:4210880kB, anon-rss:3820104kB, file-rss:0kB, shmem-rss:0kB, UID:1000 pgtables:8236kB oom_score_adj:0

anon-rss adalah jumlah memori yang digunakan proses tersebut saat dihentikan. Perhatikan proses yang dipilih: kernel terutama menilai penggunaan memori, sehingga sering kali menghentikan language server atau agent, bukan build yang menyebabkan server kehabisan memori. Itulah sebabnya gejalanya tampak seperti "agent rusak".

Di dalam Docker, kejadian yang sama menghasilkan indikasi yang lebih jelas. Container keluar dengan kode 137, yaitu 128 ditambah signal 9.

docker ps -a
docker inspect "$(docker ps -lq)" | grep -i oomkilled

"OOMKilled": true mengonfirmasi bahwa container mencapai batas memorinya, bukan berhenti karena crash internal.

Solusinya adalah menetapkan batas penggunaan memori tersendiri untuk perintah yang membutuhkan banyak sumber daya, sehingga build yang dihentikan, bukan agent:

systemd-run --user --scope -p MemoryMax=4G -- npm run build

Build kini dihentikan pada 4 GB dan agent tetap berjalan. Dengan demikian, hang yang sebelumnya membingungkan berubah menjadi kegagalan perintah biasa dengan exit code yang dapat dibaca. Ini memerlukan sesi pengguna systemd, jadi jalankan loginctl enable-linger $USER pada server yang hanya Anda akses melalui SSH. MemoryHigh= membatasi proses saat mencapai ambang tersebut, bukan menghentikannya. Pengaturan ini sering lebih sesuai untuk build yang sebaiknya selesai secara perlahan.

Terapkan sekali dengan batas memori Compose

Jika alat agent berjalan dalam container, tetapkan batasnya di file Compose agar berlaku pada setiap eksekusi.

services:
  agent:
    image: node:22-bookworm
    deploy:
      resources:
        limits:
          memory: 2g
          cpus: "1.5"

Docker Compose v2 menerapkan deploy.resources.limits pada docker compose up biasa, sehingga swarm mode tidak terlibat. Key mem_limit: 2g yang lebih lama masih berfungsi. Panduan lengkap tentang batas memori Compose membahas reservation dan hal yang terjadi saat container mencapai batasnya. Jika Docker belum tersedia di server, instal Docker pada VPS terlebih dahulu.

Satu kesalahan dapat menghabiskan waktu berjam-jam. Container dengan batas 2 GB tetap membaca /proc/meminfo milik host dan jumlah CPU host karena keduanya tidak menggunakan namespace. Test runner yang menentukan jumlah worker berdasarkan jumlah CPU akan menjalankan delapan worker di dalam container 2 GB pada host dengan delapan vCPU, lalu berhenti dengan kode 137. Tetapkan jumlah tersebut secara manual:

npx jest --maxWorkers=2
export NODE_OPTIONS=--max-old-space-size=1536

--max-old-space-size menggunakan satuan MB dan membatasi heap V8. Tetapkan nilainya di bawah batas container agar Node menampilkan error yang dapat Anda baca, bukan berhenti tanpa pesan:

FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory

Pesan tersebut membantu karena menyebutkan batas yang tercapai dan proses yang mencapainya. OOM killer tidak pernah memberikan informasi itu.

Menjalankan beberapa sesi agen pada satu mesin

Buat perencanaan per sesi, bukan per pengguna. Dua sesi pada repositori yang sama tetap berarti dua language server, dua set cache build di memori, dan dua proses pengujian jika kedua agen sibuk pada saat yang sama. Karena itu, baris tim naik menjadi 16 GB.

Tetapkan batas maksimum untuk setiap pengguna agar satu sesi yang tidak terkendali tidak menghabiskan seluruh sumber daya mesin:

id -u alice
sudo mkdir -p /etc/systemd/system/user-1001.slice.d
printf '[Slice]\nMemoryMax=6G\n' | sudo tee /etc/systemd/system/user-1001.slice.d/limit.conf
sudo systemctl daemon-reload
systemctl show user-1001.slice -p MemoryMax

Ganti 1001 dengan UID yang ditampilkan oleh id -u. systemctl show seharusnya menampilkan MemoryMax=6442450944 setelah pengguna login. Ketika total penggunaan dalam sesi pengguna tersebut melewati 6 GB, kernel menghentikan proses di dalam slice pengguna itu, sementara semua sesi lain tetap berjalan. Untuk agen yang berjalan sebagai service, bukan di terminal, masukkan MemoryMax= ke dalam file unit-nya. Gunakan pola ini saat Anda menjalankan agen sebagai service yang selalu aktif di server sendiri.

FAQ

Apakah RAM 2 GB cukup untuk coding agent?

Untuk proses agent, ya. Untuk pekerjaan yang dijalankannya, jarang. Agent menggunakan sekitar 250 MB, tetapi satu language server TypeScript dapat mencapai 2000 MB pada repositori berukuran menengah. Kondisi itu saja sudah dapat membuat server 2 GB menggunakan swap. RAM 2 GB cukup untuk mengedit file konfigurasi dan skrip kecil. Gunakan 4 GB sebagai batas minimum untuk apa pun yang melakukan kompilasi atau menjalankan test suite.

Apakah saya memerlukan GPU untuk menjalankan coding agent pada VPS?

Tidak jika agent memanggil model cloud melalui API. Beban kerja tersebut bergantung pada jaringan, sehingga VPS dengan CPU biasa adalah pilihan yang tepat. GPU akan menganggur dengan biaya yang jauh lebih tinggi. Anda hanya memerlukan GPU jika model itu sendiri berjalan pada server yang sama. Dalam kondisi tersebut, pertanyaannya berubah dari RAM menjadi VRAM dan ukuran model.

Berapa banyak swap yang harus saya tambahkan ke VPS untuk agent?

Setengah dari RAM, hingga sekitar 4 GB. Swap melindungi Anda dari lonjakan penggunaan singkat karena kernel dapat memindahkan page yang tidak aktif ke disk, bukan menghentikan proses. Swap tidak menambah memori yang dapat digunakan. Jika vmstat 1 menunjukkan trafik yang terus-menerus pada kolom si dan so, server mengalami thrashing. Solusinya adalah mengurangi jumlah worker paralel atau menggunakan plan yang lebih besar.

Mengapa coding agent saya berhenti di tengah build?

Build tersebut hampir pasti dihentikan oleh OOM killer pada kernel, yang mengirim SIGKILL. Karena itu, tidak ada output yang dicetak dan agent menunggu pada pipe yang tidak pernah terisi. Jalankan sudo dmesg -T | grep -i "killed process", lalu periksa nama proses dan nilai anon-rss. Atasi masalah ini dengan membatasi build menggunakan systemd-run --user --scope -p MemoryMax=4G dan mengurangi jumlah worker, atau beralih ke tier RAM yang satu tingkat lebih tinggi.