Berapa RAM VPS diperlukan untuk ejen pengekodan?

Berapakah jumlah RAM yang diperlukan oleh VPS ejen pengekodan?

Mulakan dengan 4 GB RAM dan 2 vCPU untuk satu ejen pengekodan yang sentiasa aktif bekerja di dalam repositori. Beralih kepada 8 GB dan 4 vCPU sebaik sahaja pelayan bahasa (language server) atau binaan Docker menyertai sesi tersebut, yang mana bagi kebanyakan repositori, ia berlaku pada hari pertama. Proses ejen itu sendiri adalah kecil, jadi apa yang memenuhi kapasiti pelayan adalah rantaian alat (toolchain) yang dijalankan oleh ejen bagi pihak 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 mengandaikan model tersebut berjalan di tempat lain, di sebalik API yang anda panggil melalui rangkaian. Andaian itu menentukan keseluruhan persoalan saiz, jadi selesaikan perkara tersebut terlebih dahulu.

Adakah anda menjalankan ejen, atau menjalankan model?

Ejen pengekodan yang memanggil model awan ialah klien rangkaian dengan shell yang dilampirkan. Ia menghantar fail dan pelan ke API, menunggu balasan, kemudian menyunting fail dan menjalankan arahan secara setempat. Semasa menunggu, ia hampir tidak menggunakan CPU. Memorinya sendiri diukur dalam ratusan megabait, itulah sebabnya kotak CPU sederhana adalah mesin yang tepat.

Menjalankan model sendiri adalah produk berbeza pada perkakasan berbeza. Wajaran (weights) kekal dalam memori selagi pelayan dihidupkan. Model 7 bilion parameter yang dikuantisasi kepada 4 bit memerlukan kira-kira 5 GB untuk wajaran sahaja, sebelum mengambil kira cache kunci/nilai yang berkembang mengikut panjang konteks. Pada CPU sahaja, vCPU kongsi hanya menghasilkan beberapa token sesaat, dan satu tugasan ejen boleh mengeluarkan beribu-ribu token, jadi kerja yang mengambil masa kurang seminit melalui API akan mengambil masa hampir sejam secara setempat. Jika itu yang anda mahukan, tentukan saiz untuk VRAM (memori video pada GPU) dan baca apa yang sebenarnya diberikan oleh VPS dengan GPU sebagai ganti halaman ini.

Segala perkara di bawah mengandaikan kes model awan.

Apakah 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-angka tersebut merupakan angka terbitan lazim bagi projek bersaiz sederhana. Anggap ia sebagai gambaran umum, bukan janji tentang kod anda.

Carta tersebut mengandungi 6 baris dan ejen tersebut adalah yang paling murah. Ia berada pada sekitar 250 MB semasa melahu, kerana ia hanya mengekalkan perbualan dan cache fail kecil tanpa melakukan apa-apa lagi. Pelayan bahasa TypeScript mencapai kira-kira 2000 MB semasa ia melakukan pengindeksan, kerana ia membina graf jenis bagi setiap fail yang boleh dicapai daripada tsconfig.json anda dan kemudian menyimpan graf tersebut dalam memori untuk menjawab permintaan seterusnya dengan pantas. rust-analyzer pada ruang kerja yang besar biasanya melepasi 4000 MB atas sebab yang sama, merentasi setiap crate dalam ruang kerja tersebut.

Headless Chrome memakan kira-kira 350 MB untuk pelayar ditambah satu tab, dan setiap tab tambahan merupakan satu proses sistem pengendalian yang lain. Ujian Node yang dijalankan dengan empat pekerja bermakna empat proses Node, jadi ia memuncak hampir kepada 3000 MB. Binaan imej Docker memuncak hampir kepada 2500 MB, kerana binaan tersebut menjalankan pengkompil projek anda sendiri di dalam bekas sementara daemon menulis lapisan.

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 lajur available bagi free -h, bukan lajur free. Linux membelanjakan setiap halaman terluang untuk cache cakera, jadi free adalah kecil pada kotak yang sihat sepenuhnya dan tidak memberikan sebarang maklumat. available ialah jumlah yang boleh diperoleh oleh proses baharu.

Tiga konfigurasi yang berfungsi

Minimum yang boleh digunakan: 4 GB RAM, 2 vCPU, 50 GB disk. Satu sesi ejen, satu repositori, satu pelayan bahasa, dan binaan yang anda sanggup tunggu. Tahap ini berfungsi, namun ia akan berdepan dengan out-of-memory killer apabila ujian berskala besar bertindih dengan pelayan bahasa pengindeksan. Tambahkan swap dan hadkan pekerja binaan anda.

Selesa: 8 GB RAM, 4 vCPU, 100 GB disk. Satu ejen, ditambah Docker, serta pelayar tanpa kepala untuk ujian, dengan ruang tambahan untuk satu lonjakan binaan. Ini adalah tahap yang patut dibeli oleh kebanyakan pembangun individu. Menggandakan bilangan vCPU juga secara kasarnya mengurangkan separuh masa menunggu binaan, dan anda akan merasai perbezaan ini dengan lebih kerap berbanding memori.

Pasukan: 16 GB RAM, 8 vCPU, 200 GB disk. Empat sesi serentak, setiap satu dengan daftar keluar dan rantaian alatnya sendiri. Tetapkan saiz untuk beban puncak, kerana empat ejen yang melahu hampir tidak menelan kos, manakala empat ujian yang dijalankan pada masa yang sama menelan kos empat kali ganda daripada lajur puncak di atas.

Setakat Ogos 2026, langkah daripada baris pertama ke baris terakhir adalah kira-kira empat kali ganda harga bulanan bagi pengebilan VPS tahunan: beberapa dolar sebulan di peringkat bawah, puluhan dolar di peringkat atas. Semak senarai semasa sebelum anda merancang, kerana angka tersebut berubah-ubah. Pelayan jarang menjadi bahagian yang mahal. Bagi sesiapa yang mengendalikan ejen setiap hari, bil API model akan melepasi bil pelayan dengan cepat, jadi hadkan perbelanjaan yang dibenarkan untuk ejen sebelum anda mengecilkan saiz pelayan. Untuk binaan itu sendiri, panduan menjalankan ejen pengekodan pada VPS merangkumi penyediaan akaun dan cara mengekalkan sesi aktif selepas anda terputus sambungan.

Mengapa storan cakera anda 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
  }
]

Jumlahkan baris-baris tersebut dan cakera bersaiz 50 GB hampir penuh sebelum anda menulis sebaris kod pun. Item tunggal terbesar ialah Docker pada sekitar 20 GB, kerana BuildKit menyimpan setiap lapisan perantaraan bagi setiap binaan sehingga anda mengarahkannya untuk berhenti.

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

docker system df memaparkan ruang yang boleh dituntut semula mengikut kategori, jadi jalankannya sebelum dan selepas. Penapis until=168h membuang cache binaan yang lebih lama daripada seminggu dan mengekalkan cache minggu ini, iaitu cache yang masih menjimatkan masa anda. docker image prune -a bertindak lebih jauh dan membuang setiap imej yang tidak digunakan oleh mana-mana kontena, jadi jangkakan binaan seterusnya akan melakukan penarikan (pull) semula.

Projek Node gagal dengan cara yang lebih pelik. npm install menulis ratusan ribu fail kecil, jadi sistem fail boleh kehabisan inode sementara df -h masih melaporkan gigabait yang bebas. Penulisan kemudian gagal dengan ralat No space left on device pada cakera yang kelihatan separuh kosong.

df -h /
df -i /

Jika IUse% membaca 100, padamkan direktori node_modules bagi cawangan yang tidak lagi anda gunakan, atau beralih kepada pnpm, yang menyimpan setiap versi pakej sekali sahaja dan membuat pautan keras (hard-link) ke dalam setiap projek.

Log adalah punca yang tidak disedari. Ejen yang sentiasa aktif menulis transkrip sesi, dan jurnal systemd berkembang sehingga mengambil sebahagian daripada ruang cakera secara lalai.

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

Tetapkan SystemMaxUse=200M dalam /etc/systemd/journald.conf dan jalankan sudo systemctl restart systemd-journald untuk menjadikan had tersebut kekal, kerana pembersihan (vacuum) sekali sahaja hanya mendapatkan semula ruang untuk hari ini.

Swap: kegunaannya dan perkara yang disembunyikannya

Swap wajar ditambah kerana ia menukar lebihan penggunaan memori yang kecil kepada prestasi yang perlahan, bukannya menyebabkan proses mati. Tetapkan saiznya pada separuh daripada RAM, sehingga maksimum kira-kira 4 GB. Tiada sebab untuk menambah lebih daripada itu pada pelayan binaan (build box).

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 kini sepatutnya menyenaraikan /swapfile pada saiz yang anda minta. Tanpa baris /etc/fstab, swap akan hilang selepas but semula dan pelayan akan kembali kepada kelakuan asalnya secara senyap. Jika fallocate memberikan jawapan Operation not supported, bina fail tersebut dengan sudo dd if=/dev/zero of=/swapfile bs=1M count=4096 dan teruskan dari chmod.

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

Nilai swappiness yang rendah memberitahu kernel untuk menuntut semula cache cakera sebelum ia menolak memori program ke cakera, yang memastikan pelayan bahasa (language server) kekal responsif.

Sekarang, bahagian yang disembunyikan oleh swap. Apabila sesuatu tugasan benar-benar memerlukan lebih banyak memori daripada yang dimiliki oleh pelayan, kernel akan menghabiskan masanya memindahkan halaman (pages) antara RAM dan cakera dan bukannya menjalankan binaan anda. Tiada apa-apa yang terhenti (crash). Segalanya menjadi sangat perlahan, dan purata beban (load average) meningkat sementara CPU tidak melakukan apa-apa.

vmstat 1 10

Angka bukan sifar yang stabil dalam lajur si dan so bermakna pertukaran (swapping) berlaku secara berterusan. Penyelesaiannya adalah mengurangkan konkurensi atau menambah RAM, dan bukannya menambah swap. Pada pelayan kecil, sudo apt install -y zram-tools menyediakan swap termampat yang disimpan dalam RAM, yang ditala dalam /etc/default/zramswap. Ia jauh lebih pantas daripada fail swap, dan ia menggunakan RAM untuk menjimatkan RAM. Oleh itu, ia membantu dengan halaman sejuk (cold pages) dan bukannya dengan binaan yang memerlukan memori kerja sebenar.

Mengapa ejen pengekodan anda kelihatan tergantung

Ini adalah kegagalan yang paling kerap disalah diagnosis pada kotak ejen kecil. Satu arahan tidak memulangkan apa-apa, ejen menunggu, dan sesi kelihatan beku. Proses tersebut telah ditamatkan oleh OOM (out-of-memory) killer kernel. Ia menerima SIGKILL, jadi ia tidak dapat mencetak ralat, mengosongkan log, atau memberitahu ejen apa yang berlaku. Ejen melihat hasil yang kosong dan tiada mesej keluar.

Kernel memang merekodkannya:

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

Baris sebenar kelihatan seperti ini:

[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 ialah jumlah memori yang dipegang oleh proses itu apabila ia mati. Perhatikan proses mana yang dipilih: kernel memberikan skor berdasarkan memori yang digunakan, jadi ia sering mematikan pelayan bahasa atau ejen dan bukannya binaan (build) yang menyebabkan penggunaan memori melampau. Itulah sebabnya simptom tersebut dibaca sebagai "ejen rosak".

Di dalam Docker, peristiwa yang sama meninggalkan kesan yang lebih jelas. Kontena keluar dengan kod 137, iaitu 128 ditambah isyarat 9.

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

"OOMKilled": true mengesahkan bahawa kontena telah mencapai had memorinya dan bukannya terhempas dengan sendirinya.

Penyelesaiannya adalah dengan memberikan had kepada arahan yang berat, supaya binaan tersebut mati dan bukannya ejen:

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

Binaan kini ditamatkan pada 4 GB dan ejen terus berjalan, yang menukarkan masalah tergantung yang misteri kepada arahan gagal biasa dengan kod keluar yang boleh dibaca. Ini memerlukan sesi pengguna systemd, jadi jalankan loginctl enable-linger $USER pada kotak yang anda akses melalui SSH sahaja. MemoryHigh= mengehadkan proses pada ambang tersebut dan bukannya mematikannya, yang sering menjadi tetapan yang lebih baik untuk binaan yang anda lebih suka disiapkan secara perlahan.

Hadkan penggunaan memori sekali sahaja dengan Compose

Jika alatan ejen dijalankan di dalam kontena, tetapkan had maksimum dalam fail Compose supaya ia terpakai pada setiap pelaksanaan.

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

Docker Compose v2 menggunakan deploy.resources.limits pada docker compose up biasa, jadi mod swarm tidak terlibat. Kunci mem_limit: 2g yang lebih lama masih berfungsi. Panduan lengkap mengenai had memori Compose merangkumi tempahan (reservations) dan perkara yang berlaku apabila kontena mencapai had maksimumnya. Jika Docker belum dipasang pada pelayan, pasang Docker pada VPS terlebih dahulu.

Satu perangkap sering membuang masa pengguna. Kontena yang dihadkan kepada 2 GB masih membaca /proc/meminfo hos dan bilangan CPU hos, kerana kedua-duanya tidak diasingkan melalui namespace. Pelari ujian (test runner) yang memilih bilangan pekerja berdasarkan bilangan CPU akan memulakan lapan pekerja di dalam kontena 2 GB pada hos dengan lapan vCPU, kemudian terhenti pada kod 137. Tetapkan angka tersebut secara manual:

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

--max-old-space-size adalah dalam unit MB dan mengehadkan heap V8. Tetapkan nilainya di bawah had kontena supaya Node mengeluarkan ralat yang boleh dibaca dan bukannya terus hilang:

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

Mesej tersebut sangat berguna kerana ia menyatakan had yang dicapai dan proses yang menyebabkannya. OOM killer tidak pernah memberikan maklumat sedemikian.

Menjalankan beberapa sesi ejen pada satu mesin

Rancang mengikut sesi, bukan mengikut individu. Dua sesi pada repositori yang sama tetap bermaksud dua pelayan bahasa, dua set cache binaan dalam memori, dan dua ujian dijalankan jika kedua-dua ejen sibuk pada saat yang sama. Itulah sebabnya baris pasukan melonjak kepada 16 GB.

Tetapkan had maksimum yang tegas bagi setiap pengguna supaya satu sesi yang tidak terkawal tidak menyebabkan keseluruhan mesin terhenti:

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

Gantikan 1001 dengan UID yang dicetak oleh id -u. systemctl show sepatutnya memaparkan MemoryMax=6442450944 sebaik sahaja pengguna log masuk. Apabila semua proses dalam sesi pengguna tersebut melebihi 6 GB, kernel akan menamatkan proses di dalam slice miliknya dan setiap sesi lain akan terus berfungsi. Bagi ejen yang berjalan sebagai servis dan bukannya di dalam terminal, letakkan MemoryMax= di dalam fail unitnya sebagai ganti, yang merupakan corak untuk diikuti apabila anda mengehos sendiri ejen sebagai servis yang sentiasa aktif.

FAQ

Adakah 2 GB RAM mencukupi untuk ejen pengekodan?

Untuk proses ejen itu sendiri, ya. Untuk kerja yang dilakukannya, jarang sekali. Ejen tersebut menggunakan sekitar 250 MB, tetapi satu language server TypeScript boleh mencecah 2000 MB pada repositori bersaiz sederhana, dan itu sahaja sudah menolak pelayan 2 GB ke dalam swap. 2 GB memadai untuk menyunting fail konfigurasi dan skrip kecil. Gunakan 4 GB sebagai tahap minimum untuk sebarang tugasan yang melibatkan penyusunan (compile) atau menjalankan suite ujian.

Adakah saya memerlukan GPU untuk menjalankan ejen pengekodan pada VPS?

Tidak, jika ejen tersebut memanggil model awan melalui API. Beban kerja itu terikat dengan rangkaian (network-bound), jadi VPS CPU biasa adalah mesin yang tepat dan GPU hanya akan melahu pada harga yang jauh lebih tinggi. Anda hanya memerlukan GPU apabila model itu sendiri dijalankan pada mesin yang sama, dan dalam keadaan itu, persoalannya berubah daripada RAM kepada VRAM dan saiz model.

Berapa banyak swap yang perlu saya tambah pada VPS ejen?

Separuh daripada RAM, sehingga maksimum kira-kira 4 GB. Swap melindungi anda daripada lonjakan penggunaan memori yang singkat, kerana kernel boleh memindahkan halaman (pages) yang tidak aktif ke cakera dan bukannya mematikan proses. Ia tidak menambah memori yang boleh digunakan. Jika vmstat 1 menunjukkan trafik yang stabil dalam lajur si dan so, mesin tersebut mengalami thrashing, dan penyelesaiannya adalah dengan mengurangkan bilangan pekerja selari atau menaik taraf pelan.

Mengapa ejen pengekodan saya terhenti di tengah-tengah proses binaan (build)?

Proses binaan tersebut hampir pasti dimatikan oleh OOM killer kernel, yang menghantar SIGKILL, jadi tiada apa-apa yang dicetak dan ejen menunggu pada paip (pipe) yang tidak pernah penuh. Jalankan sudo dmesg -T | grep -i "killed process" dan lihat nama proses serta nilai anon-rss miliknya. Selesaikan masalah ini dengan mengehadkan binaan menggunakan systemd-run --user --scope -p MemoryMax=4G dan mengurangkan bilangan pekerja, atau dengan beralih ke tier RAM yang lebih tinggi.