Kodlama Ajanı VPS İçin İdeal RAM ve CPU Miktarı

Bir kodlama ajanı VPS'i ne kadar RAM'e ihtiyaç duyar?

Tek bir repository üzerinde sürekli çalışan bir kodlama ajanı için 4 GB RAM ve 2 vCPU ile başlayın. Bir dil sunucusu veya Docker build işlemi oturuma dahil olduğu anda (ki çoğu repository için bu ilk günden gerçekleşir) 8 GB RAM ve 4 vCPU seviyesine geçin. Ajan sürecinin kendisi küçüktür; sunucuyu dolduran şey, ajanın sizin adınıza çalıştırdığı araç zinciridir.

[
  {
    "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
  }
]

Yukarıdaki her satır, modelin başka bir yerde, ağ üzerinden çağrılan bir API arkasında çalıştığını varsayar. Bu varsayım, boyutlandırma sorusunun tamamını belirler; bu yüzden önce bu konuyu netleştirin.

Ajanı mı çalıştırıyorsunuz, yoksa modeli mi?

Bulut tabanlı bir modeli çağıran kodlama ajanı, kabuk erişimine sahip bir ağ istemcisidir. Dosyaları ve bir planı API'ye gönderir, yanıtı bekler, ardından dosyaları düzenleyip komutları yerel olarak çalıştırır. Bekleme süresince neredeyse hiç CPU kullanmaz. Kendi bellek kullanımı yüzlerce megabayt seviyesindedir; bu nedenle mütevazı bir CPU kutusu doğru makinedir.

Modeli kendi başınıza çalıştırmak, farklı donanım gerektiren farklı bir üründür. Ağırlıklar, sunucu açık kaldığı sürece bellekte tutulur. 4 bit kuantize edilmiş 7 milyar parametreli bir model, bağlam uzunluğuyla birlikte büyüyen anahtar/değer (key/value) önbelleği hariç, yalnızca ağırlıklar için yaklaşık 5 GB alana ihtiyaç duyar. Yalnızca CPU üzerinde, paylaşımlı bir vCPU saniyede birkaç token üretir; bir ajan görevi ise binlerce token üretebilir. Bu nedenle, bir API üzerinden bir dakikadan kısa süren bir işlem, yerel olarak neredeyse bir saat sürer. Eğer istediğiniz buysa, VRAM (GPU üzerindeki video belleği) kapasitesine göre boyutlandırma yapın ve bu sayfa yerine GPU'lu bir VPS'in size gerçekte ne sunduğunu okuyun.

Aşağıdaki her şey, bulut modeli senaryosunu temel alır.

Belleği gerçekte ne kullanıyor

[
  {
    "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
  }
]

Bunlar, orta ölçekli projeler için yayınlanmış tipik değerlerdir. Bunları kodunuz için bir taahhüt değil, bir genel görünüm olarak değerlendirin.

Tablo 6 satır içerir ve aracı (agent) en düşük maliyetli olanıdır. Boştayken yaklaşık 250 MB civarında seyreder; çünkü sadece bir konuşmayı ve küçük bir dosya önbelleğini tutar, başka bir şey yapmaz. Bir TypeScript dil sunucusu, indeksleme yaparken yaklaşık 2000 MB değerine ulaşır; çünkü tsconfig.json dosyanızdan erişilebilen her dosya için bir tür grafiği oluşturur ve bir sonraki isteğe hızlı yanıt verebilmek için bu grafiği bellekte tutar. rust-analyzer, büyük bir çalışma alanında aynı nedenle genellikle 4000 MB değerini aşar; bu durum çalışma alanındaki her crate için geçerlidir.

Headless Chrome, tarayıcı ve bir sekme için yaklaşık 350 MB tüketir; eklenen her sekme ayrı bir işletim sistemi sürecidir. Dört worker ile çalışan bir Node test süreci dört ayrı Node süreci demektir, bu nedenle 3000 MB civarında zirve yapar. Bir Docker imajı oluşturma işlemi, daemon katmanları yazarken container içinde projenizin kendi derleyicisini çalıştırdığı için 2500 MB civarında zirve yapar.

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

free -h çıktısındaki free sütununa değil, available sütununa bakın. Linux, boşta kalan her sayfayı disk önbelleğine ayırır; bu nedenle tamamen sağlıklı bir sunucuda free değeri düşüktür ve size bir şey ifade etmez. available, yeni bir sürecin gerçekte elde edebileceği miktardır.

Çalışan üç yapılandırma

Minimum uygulanabilir: 4 GB RAM, 2 vCPU, 50 GB disk. Bir agent oturumu, bir depo, bir dil sunucusu ve beklemeyi göze aldığınız derleme süreçleri. Bu seviye çalışır ancak büyük bir test çalışması ile indeksleme yapan dil sunucusu çakıştığında out-of-memory killer ile karşılaşır. Swap alanı ekleyin ve derleme işçilerinizi sınırlayın.

Konforlu: 8 GB RAM, 4 vCPU, 100 GB disk. Bir agent, artı Docker, artı testler için başsız (headless) bir tarayıcı ve bir derleme yoğunluğu için ek kapasite. Çoğu bireysel geliştiricinin tercih etmesi gereken seviye budur. vCPU sayısını ikiye katlamak derleme süresini kabaca yarıya indirir; bu farkı bellek artışından çok daha fazla hissedersiniz.

Ekip: 16 GB RAM, 8 vCPU, 200 GB disk. Her biri kendi checkout ve araç zincirine sahip dört eşzamanlı oturum. En yoğun anı baz alarak boyutlandırma yapın; çünkü dört boşta bekleyen agent neredeyse hiçbir maliyet getirmezken, aynı anda çalışan dört test süreci yukarıdaki en yoğun sütunun dört katı maliyet oluşturur.

Ağustos 2026 itibarıyla, ilk satırdan son satıra geçiş, yıllık VPS faturalandırmasında aylık fiyatın kabaca dört katıdır: en altta tek haneli dolar, en üstte ise onlu dolar seviyeleri. Planlama yapmadan önce güncel listeyi kontrol edin, çünkü bu rakamlar değişebilir. Sunucu nadiren maliyetin büyük kısmını oluşturur. Bir agent'ı günlük olarak kullanan herkes için model API faturası, sunucu faturasını hızla geçer; bu yüzden sunucuyu küçültmeden önce agent'ın harcama limitini belirleyin. Derleme sürecinin kendisi için, bir VPS üzerinde kodlama agent'ı çalıştırma kılavuzu, hesap kurulumunu ve bağlantıyı kestiğinizde oturumu nasıl canlı tutacağınızı açıklar.

RAM tükenmeden disk alanının tükenme nedeni

[
  {
    "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
  }
]

Bu satırları topladığınızda, tek bir kod satırı bile yazmadan 50 GB boyutundaki diskin neredeyse dolduğunu görürsünüz. En büyük tekil öğe, BuildKit her derlemenin tüm ara katmanlarını siz durdurana kadar sakladığı için yaklaşık 20 GB yer kaplayan Docker'dır.

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

docker system df komutu, geri kazanılabilir alanı kategori bazında listeler; bu nedenle komutu temizlik öncesinde ve sonrasında çalıştırın. until=168h filtresi, bir haftadan eski derleme önbelleğini siler ve size zaman kazandırmaya devam edecek olan bu haftanın önbelleğini tutar. docker image prune -a daha agresif davranarak hiçbir container tarafından kullanılmayan tüm imajları kaldırır; bu yüzden bir sonraki derlemede imajların yeniden indirilmesini beklemelisiniz.

Node projelerinde hata daha farklı bir şekilde ortaya çıkar. npm install yüz binlerce küçük dosya oluşturur; bu nedenle df -h komutu hala boş gigabaytlar olduğunu raporlasa bile dosya sistemi inode sınırına ulaşabilir. Bu durumda yazma işlemi, yarı yarıya boş görünen bir diskte No space left on device hatasıyla başarısız olur.

df -h /
df -i /

Eğer IUse% değeri 100 olarak okunuyorsa, artık üzerinde çalışmadığınız dallara ait node_modules dizinlerini silin veya her paket sürümünü tek bir kez depolayıp her projeye hard-link ile bağlayan pnpm aracına geçiş yapın.

Log dosyaları ise sessizce yer kaplar. Sürekli çalışan bir aracı oturum dökümlerini yazar ve systemd günlüğü varsayılan olarak diskte belirli bir paya ulaşana kadar büyür.

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

/etc/systemd/journald.conf dosyasında SystemMaxUse=200M değerini ayarlayın ve bu sınırı kalıcı hale getirmek için sudo systemctl restart systemd-journald komutunu çalıştırın; çünkü tek seferlik bir temizlik yalnızca bugünün alanını geri kazandırır.

Swap: sağladığı avantajlar ve gizledikleri

Swap eklemek faydalıdır; çünkü küçük bir bellek aşımının süreci sonlandırması yerine, işlemin yavaş da olsa devam etmesini sağlar. Swap boyutunu RAM miktarının yarısı kadar, en fazla 4 GB olacak şekilde ayarlayın. Bir derleme sunucusunda bu miktarın üzerine çıkmak için geçerli bir neden yoktur.

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 komutu artık /swapfile değerini belirttiğiniz boyutta listelemelidir. /etc/fstab satırı eklenmediği takdirde, yeniden başlatma sonrasında swap devre dışı kalır ve sunucu sessizce eski davranışına döner. Eğer fallocate komutu Operation not supported yanıtını veriyorsa, sudo dd if=/dev/zero of=/swapfile bs=1M count=4096 ile dosyayı oluşturun ve chmod adımından devam edin.

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

Düşük bir swappiness değeri, çekirdeğe program belleğini diske taşımadan önce disk önbelleğini geri kazanması talimatını verir; bu da bir dil sunucusunun (language server) yanıt verebilirliğini korur.

Şimdi swap'in gizlediği kısma gelelim. Bir iş, sunucunun sahip olduğundan daha fazla belleğe ihtiyaç duyduğunda, çekirdek derleme işlemini yürütmek yerine zamanını RAM ile disk arasında sayfa taşıyarak harcar. Hiçbir şey çökmez. Her şey sürünerek ilerler ve CPU boşta beklerken yük ortalaması (load average) yükselir.

vmstat 1 10

si ve so sütunlarındaki sabit ve sıfır olmayan değerler, sürekli bir swap kullanımı anlamına gelir. Bu durumda çözüm, eşzamanlılığı azaltmak veya RAM miktarını artırmaktır; kesinlikle daha fazla swap eklemek değildir. Küçük bir sunucuda sudo apt install -y zram-tools, RAM içinde sıkıştırılmış swap alanı sağlar ve /etc/default/zramswap üzerinden yapılandırılır. Bu yöntem bir swap dosyasından çok daha hızlıdır; RAM'den tasarruf etmek için RAM harcar. Bu nedenle soğuk sayfalar (cold pages) için yardımcı olur, ancak gerçek çalışma belleğine ihtiyaç duyan bir derleme işlemine katkı sağlamaz.

Kodlama aracınızın neden donmuş gibi göründüğü

Bu, küçük bir aracı sunucusunda en yanlış teşhis edilen hata türüdür. Bir komut hiçbir çıktı döndürmez, aracı bekler ve oturum donmuş gibi görünür. Süreç, çekirdeğin bellek yetersizliği (OOM) sonlandırıcısı tarafından öldürülmüştür. Süreç SIGKILL sinyali aldığı için bir hata mesajı yazdıramamış, log kaydını temizleyememiş veya aracıya ne olduğunu bildirememiştir. Aracı, boş bir sonuç ve çıkış mesajı görmez.

Çekirdek bu durumu kaydeder:

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

Gerçek bir satır şu şekilde görünür:

[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, sürecin öldüğü sırada ne kadar bellek kullandığını gösterir. Hangi sürecin seçildiğine dikkat edin: çekirdek puanlamayı büyük ölçüde kullanılan belleğe göre yapar, bu nedenle genellikle derleme sürecini değil, dil sunucusunu veya aracıyı öldürür. Aracının "bozulmuş" gibi görünmesinin nedeni tam olarak budur.

Docker içinde aynı olay daha temiz bir iz bırakır. Konteyner, 128 artı 9 sinyali olan 137 koduyla çıkar.

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

"OOMKilled": true, konteynerin kendi kendine çökmek yerine bellek sınırına ulaştığını doğrular.

Bunun çözümü, maliyetli komuta kendi sınırını belirlemektir; böylece aracı yerine derleme süreci ölür:

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

Derleme süreci artık 4 GB sınırında öldürülür ve aracı hayatta kalır; bu da gizemli bir donma durumunu, okunabilir bir çıkış koduna sahip sıradan bir başarısız komuta dönüştürür. Bu işlem bir systemd kullanıcı oturumu gerektirir, bu nedenle yalnızca SSH üzerinden eriştiğiniz bir sunucuda loginctl enable-linger $USER komutunu çalıştırın. MemoryHigh=, süreci öldürmek yerine eşik değerinde kısıtlar; bu, yavaş da olsa tamamlanmasını tercih edeceğiniz bir derleme işlemi için genellikle daha uygun bir ayardır.

Compose bellek sınırlarını tek seferde belirleyin

Eğer aracın araçları container içerisinde çalışıyorsa, üst sınırı Compose dosyasına ekleyin; böylece her çalıştırmada bu sınır uygulanır.

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

Docker Compose v2, deploy.resources.limits değerini doğrudan docker compose up üzerinde uygular, bu nedenle swarm modu devreye girmez. Daha eski olan mem_limit: 2g anahtarı da çalışmaya devam eder. Compose bellek sınırları için tam kılavuz, kaynak ayırmaları ve bir container üst sınırına ulaştığında ne olacağını açıklar. Eğer sunucuda Docker yüklü değilse, önce bir VPS üzerine Docker kurun.

Bir tuzak, kullanıcıların bir öğleden sonrasını kaybetmesine neden olur. 2 GB ile sınırlandırılmış bir container, host'un /proc/meminfo değerini ve CPU sayısını okumaya devam eder; çünkü bunların hiçbiri namespaced değildir. CPU sayısına göre işçi sayısını belirleyen bir test çalıştırıcısı, 8 vCPU'lu bir host üzerinde 2 GB'lık container içinde 8 işçi başlatır ve ardından 137 hata koduyla kapanır. Sayıları manuel olarak ayarlayın:

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

--max-old-space-size değeri MB cinsindendir ve V8 heap alanını sınırlar. Bu değeri container sınırının altında tutun; böylece Node, aniden kaybolmak yerine okuyabileceğiniz bir hata mesajı verir:

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

Bu mesaj bir hediyedir, çünkü ulaşılan sınırı ve bu sınıra çarpan süreci belirtir. OOM killer bunu asla yapmaz.

Tek bir sunucuda birden fazla aracı oturumu çalıştırma

Kişi bazlı değil, oturum bazlı planlama yapın. Aynı depo üzerinde iki oturum, iki dil sunucusu, bellekte iki ayrı derleme önbelleği ve her iki aracı aynı anda meşgul olursa iki ayrı test çalışması anlamına gelir. Ekip satırının 16 GB değerine sıçramasının nedeni budur.

Kontrolden çıkan bir oturumun tüm sunucuyu çökertmemesi için her kullanıcıya katı bir üst sınır belirleyin:

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

1001 değerini, id -u komutunun çıktı olarak verdiği UID ile değiştirin. Kullanıcı giriş yaptıktan sonra systemctl show komutu MemoryMax=6442450944 çıktısını vermelidir. İlgili kullanıcının oturumundaki her şey 6 GB sınırını aştığında, çekirdek o dilim içindeki bir süreci sonlandırır ve diğer tüm oturumlar çalışmaya devam eder. Terminal yerine servis olarak çalışan bir aracı için, bunun yerine birim dosyasına MemoryMax= ekleyin; bu, bir aracıyı her zaman açık bir servis olarak barındırırken izlenmesi gereken yöntemdir.

FAQ

2 GB RAM bir kodlama ajanı için yeterli mi?

Ajan süreci için evet. Ancak yaptığı işler için genellikle yetersizdir. Ajan yaklaşık 250 MB RAM kullanır, ancak tek bir TypeScript dil sunucusu orta ölçekli bir depoda 2000 MB seviyesine ulaşabilir. Bu durum, 2 GB kapasiteli bir sunucuyu doğrudan swap kullanımına zorlar. 2 GB, yapılandırma dosyalarını düzenlemek ve küçük betikler yazmak için uygundur. Derleme yapan veya test paketi çalıştıran her türlü iş yükü için alt sınır olarak 4 GB RAM tercih edilmelidir.

Bir VPS üzerinde kodlama ajanı çalıştırmak için GPU gerekli mi?

Ajan, bulut tabanlı bir modeli API üzerinden çağırıyorsa gerekli değildir. Bu iş yükü ağa bağımlıdır; dolayısıyla standart bir CPU VPS doğru tercihtir ve GPU, çok daha yüksek maliyetle boşta kalacaktır. GPU'ya yalnızca modelin kendisi aynı sunucuda çalıştırılacaksa ihtiyaç duyulur; bu durumda konu RAM'den VRAM ve model boyutuna evrilir.

Bir ajan VPS'ine ne kadar swap eklemeliyim?

RAM miktarının yarısı kadar, en fazla 4 GB olacak şekilde eklenmelidir. Swap, kısa süreli bellek aşımı durumlarında çekirdeğin süreci sonlandırmak yerine kullanılmayan sayfaları diske taşımasını sağlayarak sizi korur. Kullanılabilir bellek miktarını artırmaz. Eğer vmstat 1 komutu, si ve so sütunlarında sürekli bir hareketlilik gösteriyorsa sunucu "thrashing" durumundadır; bu durumda çözüm, paralel çalışan sayısını azaltmak veya daha üst bir plana geçmektir.

Kodlama ajanım neden derleme sırasında donuyor?

Derleme süreci neredeyse kesinlikle çekirdeğin OOM killer mekanizması tarafından sonlandırılmıştır. Çekirdek SIGKILL sinyali gönderdiği için herhangi bir hata çıktısı yazılmaz ve ajan, asla dolmayacak bir boru (pipe) üzerinde beklemeye devam eder. sudo dmesg -T | grep -i "killed process" komutunu çalıştırın ve süreç adı ile anon-rss değerini kontrol edin. Sorunu çözmek için derleme sürecini systemd-run --user --scope -p MemoryMax=4G ile sınırlayın, çalışan sayısını düşürün veya bir üst RAM katmanına geçiş yapın.