Ile RAM dla agenta programistycznego na VPS?

Ile pamięci RAM wymaga VPS dla agenta programistycznego?

Należy rozpocząć od 4 GB pamięci RAM oraz 2 vCPU dla jednego stale działającego agenta programistycznego pracującego w repozytorium. Należy przejść na 8 GB oraz 4 vCPU, gdy tylko do sesji dołączy serwer językowy lub proces budowania Docker, co w przypadku większości repozytoriów ma miejsce pierwszego dnia. Sam proces agenta jest niewielki, więc zasoby serwera zajmuje przede wszystkim zestaw narzędzi, z których agent korzysta w imieniu użytkownika.

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

Każdy powyższy wiersz zakłada, że model działa w innym miejscu, za interfejsem API wywoływanym przez sieć. To założenie determinuje całą kwestię doboru rozmiaru, dlatego należy je rozstrzygnąć w pierwszej kolejności.

Uruchamiasz agenta czy model?

Agent programistyczny wywołujący model chmurowy jest klientem sieciowym z dołączoną powłoką. Wysyła pliki oraz plan do API, oczekuje na odpowiedź, a następnie edytuje pliki i wykonuje polecenia lokalnie. W czasie oczekiwania zużycie procesora jest niemal zerowe. Pamięć własna agenta mierzona jest w setkach megabajtów, dlatego skromna jednostka CPU jest odpowiednim sprzętem.

Uruchamianie modelu we własnym zakresie to inny produkt na innym sprzęcie. Wagi pozostają w pamięci tak długo, jak długo działa serwer. Model o 7 miliardach parametrów skwantyzowany do 4 bitów wymaga około 5 GB samej pamięci na wagi, nie licząc pamięci podręcznej klucz/wartość, która rośnie wraz z długością kontekstu. W przypadku pracy wyłącznie na CPU, współdzielony vCPU generuje kilka tokenów na sekundę, a jedno zadanie agenta może wygenerować tysiące tokenów. Zatem praca, która przez API zajmuje poniżej minuty, lokalnie zajmuje prawie godzinę. Jeśli tego właśnie oczekujesz, dobierz sprzęt pod kątem VRAM (pamięci wideo na GPU) i przeczytaj co faktycznie oferuje VPS z GPU zamiast tej strony.

Wszystkie poniższe informacje dotyczą przypadku korzystania z modelu chmurowego.

Co faktycznie zużywa pamięć

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

Są to typowe, publikowane wartości dla projektów średniej wielkości. Należy traktować je jako przybliżony model, a nie gwarancję wydajności własnego kodu.

Wykres zawiera 6 wierszy, a agent jest najmniej zasobożernym elementem. W stanie spoczynku zajmuje około 250 MB, ponieważ utrzymuje sesję oraz niewielką pamięć podręczną plików i nic poza tym. Serwer języka TypeScript osiąga około 2000 MB podczas indeksowania, ponieważ buduje graf typów dla każdego pliku dostępnego z poziomu tsconfig.json, a następnie przechowuje ten graf w pamięci, aby szybko odpowiadać na kolejne żądania. rust-analyzer w dużym obszarze roboczym zazwyczaj przekracza 4000 MB z tego samego powodu, obejmując każdy crate w obszarze roboczym.

Headless Chrome zużywa około 350 MB na przeglądarkę oraz jedną kartę, a każda kolejna karta to osobny proces systemu operacyjnego. Uruchomienie testów Node z czterema procesami roboczymi oznacza cztery procesy Node, więc szczytowe zużycie zbliża się do 3000 MB. Budowanie obrazu Docker osiąga szczyt w okolicach 2500 MB, ponieważ proces budowania uruchamia kompilator projektu wewnątrz kontenera, podczas gdy daemon zapisuje warstwy.

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

Należy sprawdzać kolumnę available w free -h, a nie kolumnę free. Linux przeznacza każdą wolną stronę pamięci na cache dyskowy, więc free jest małe w całkowicie sprawnym systemie i nie dostarcza użytecznych informacji. available to ilość pamięci, którą faktycznie może otrzymać nowy proces.

Trzy działające konfiguracje

Minimum niezbędne: 4 GB RAM, 2 vCPU, 50 GB dysku. Jedna sesja agenta, jedno repozytorium, jeden serwer językowy oraz kompilacje, na które użytkownik jest w stanie poczekać. Ten poziom działa, ale przy pierwszym uruchomieniu dużego zestawu testów w połączeniu z indeksującym serwerem językowym wystąpi błąd out-of-memory killer. Należy dodać swap i ograniczyć liczbę procesów budujących.

Komfortowe: 8 GB RAM, 4 vCPU, 100 GB dysku. Jeden agent, Docker, przeglądarka w trybie headless do testów oraz zapas mocy na nagły wzrost obciążenia kompilacją. Jest to poziom zalecany dla większości pojedynczych programistów. Podwojenie liczby vCPU skraca czas oczekiwania na kompilację o połowę, co jest odczuwalne znacznie bardziej niż zasoby pamięci.

Zespół: 16 GB RAM, 8 vCPU, 200 GB dysku. Cztery równoległe sesje, każda z własnym checkoutem i własnym łańcuchem narzędzi. Zasoby należy dobrać pod kątem szczytowego obciążenia, ponieważ cztery bezczynne agenty prawie nie generują kosztów, podczas gdy cztery testy uruchomione w tym samym momencie wymagają czterokrotności zasobów z powyższej kolumny.

Według stanu na sierpień 2026, różnica w cenie między pierwszym a ostatnim wariantem wynosi około czterokrotność miesięcznej opłaty przy rocznym rozliczeniu VPS: od kilku dolarów miesięcznie w najniższym wariancie do kilkudziesięciu dolarów w najwyższym. Przed planowaniem należy sprawdzić aktualny cennik, ponieważ wartości te ulegają zmianie. Serwer rzadko stanowi główny koszt. W przypadku codziennego korzystania z agenta, rachunek za API modelu szybko przewyższa koszt serwera, dlatego należy ograniczyć budżet wydatków agenta przed zmniejszeniem rozmiaru instancji. W kwestii samego procesu budowania, instrukcja uruchamiania agenta programistycznego na VPS zawiera informacje o konfiguracji konta oraz utrzymaniu sesji po rozłączeniu.

Dlaczego miejsce na dysku kończy się szybciej niż pamięć 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
  }
]

Po zsumowaniu tych wartości dysk o pojemności 50 GB jest niemal pełny, zanim jeszcze napiszesz pierwszą linię kodu. Największym pojedynczym elementem jest Docker, zajmujący około 20 GB, ponieważ BuildKit przechowuje każdą warstwę pośrednią każdego buildu, dopóki nie zostanie wydane polecenie jej usunięcia.

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

Polecenie docker system df wyświetla ilość miejsca możliwego do odzyskania w podziale na kategorie, więc uruchom je przed i po czyszczeniu. Filtr until=168h usuwa cache budowania starszy niż tydzień, zachowując dane z bieżącego tygodnia, które nadal skracają czas pracy. docker image prune -a działa bardziej radykalnie i usuwa każdy obraz, który nie jest używany przez żaden kontener, więc należy się spodziewać, że kolejny build wymusi ponowne pobranie danych.

Projekty Node zawodzą w bardziej nietypowy sposób. npm install tworzy setki tysięcy małych plików, przez co system plików może wyczerpać pulę inode, podczas gdy df -h nadal raportuje wolne gigabajty. Operacja zapisu kończy się wtedy błędem No space left on device na dysku, który wygląda na w połowie pusty.

df -h /
df -i /

Jeśli IUse% wskazuje wartość 100, usuń katalogi node_modules dla gałęzi, na których już nie pracujesz, lub przejdź na pnpm, który przechowuje każdą wersję pakietu tylko raz i tworzy twarde dowiązania (hard-links) w każdym projekcie.

Logi są problemem, który narasta niezauważenie. Agent działający w trybie ciągłym zapisuje transkrypcje sesji, a journal systemd domyślnie zajmuje znaczną część dysku.

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

Ustaw SystemMaxUse=200M w pliku /etc/systemd/journald.conf i uruchom sudo systemctl restart systemd-journald, aby trwale ograniczyć ten limit, ponieważ jednorazowe czyszczenie odzyskuje miejsce tylko na dzisiaj.

Swap: co daje i co ukrywa

Warto dodać swap, ponieważ zamienia on niewielkie przekroczenie limitu pamięci na spowolnienie pracy zamiast na ubicie procesu. Należy ustawić jego rozmiar na połowę pamięci RAM, maksymalnie do około 4 GB. Na serwerze kompilacyjnym nie ma uzasadnienia dla większych wartości.

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 powinno teraz wyświetlać /swapfile o zadanym rozmiarze. Bez linii /etc/fstab swap zniknie po kolejnym restarcie, a serwer po cichu powróci do poprzedniego zachowania. Jeśli fallocate zwraca Operation not supported, utwórz plik za pomocą sudo dd if=/dev/zero of=/swapfile bs=1M count=4096 i przejdź dalej od chmod.

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

Niska wartość swappiness nakazuje jądru odzyskiwanie pamięci podręcznej dysku przed przeniesieniem pamięci programów na dysk, co pozwala zachować responsywność serwera językowego.

Teraz kwestia tego, co swap ukrywa. Gdy zadanie faktycznie wymaga więcej pamięci niż posiada serwer, jądro traci czas na przenoszenie stron między RAM a dyskiem zamiast na kompilację. Nic się nie zawiesza. Wszystko działa skrajnie wolno, a średnie obciążenie systemu rośnie, podczas gdy procesor pozostaje bezczynny.

vmstat 1 10

Stałe, niezerowe wartości w kolumnach si oraz so oznaczają ciągłe korzystanie ze swapu. Rozwiązaniem jest zmniejszenie współbieżności lub zwiększenie ilości pamięci RAM, a nigdy zwiększanie rozmiaru swapu. Na małym serwerze sudo apt install -y zram-tools zapewnia skompresowany swap przechowywany w RAM, konfigurowany w /etc/default/zramswap. Jest on znacznie szybszy niż plik wymiany i zużywa RAM, aby oszczędzać RAM, więc pomaga przy zimnych stronach pamięci, a nie przy kompilacji wymagającej rzeczywistej pamięci operacyjnej.

Dlaczego agent programistyczny sprawia wrażenie zawieszonego

Jest to najczęściej błędnie diagnozowana awaria na małych serwerach z agentami. Polecenie nie zwraca żadnych danych, agent oczekuje, a sesja wygląda na zamrożoną. Proces został zakończony przez mechanizm OOM (Out-Of-Memory) killer jądra systemu. Otrzymał on sygnał SIGKILL, więc nie mógł wyświetlić błędu, zapisać logu ani powiadomić agenta o przyczynie przerwania. Agent otrzymuje pusty wynik i brak komunikatu o zakończeniu.

Jądro systemu rejestruje to zdarzenie:

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

Rzeczywisty wpis wygląda następująco:

[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 oznacza ilość pamięci zajmowaną przez proces w momencie jego zakończenia. Należy zwrócić uwagę, który proces został wybrany: jądro ocenia procesy głównie na podstawie użycia pamięci, więc często kończy serwer języka lub agenta, zamiast procesu budowania, który przekroczył limit. Właśnie dlatego objaw jest interpretowany jako "awaria agenta".

Wewnątrz Docker to samo zdarzenie pozostawia bardziej czytelny ślad. Kontener kończy działanie z kodem 137, co stanowi sumę 128 oraz sygnału 9.

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

"OOMKilled": true potwierdza, że kontener osiągnął limit pamięci, zamiast ulec awarii z własnej przyczyny.

Rozwiązaniem jest nałożenie limitu na zasobożerne polecenie, aby to proces budowania został przerwany zamiast agenta:

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

Proces budowania jest teraz przerywany przy 4 GB, a agent pozostaje aktywny. Zmienia to tajemnicze zawieszenie w zwykłe niepowodzenie polecenia z czytelnym kodem wyjścia. Wymaga to sesji użytkownika systemd, więc należy uruchomić loginctl enable-linger $USER na serwerze dostępnym wyłącznie przez SSH. MemoryHigh= ogranicza proces przy osiągnięciu progu zamiast go kończyć, co często jest łagodniejszym ustawieniem dla procesu budowania, który lepiej, aby zakończył się wolniej niż wcale.

Ograniczanie pamięci w Compose

Jeśli narzędzia agenta działają w kontenerach, należy zdefiniować limit w pliku Compose, aby obowiązywał przy każdym uruchomieniu.

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

Docker Compose v2 stosuje deploy.resources.limits w standardowym pliku docker compose up, więc tryb swarm nie jest wymagany. Starszy klucz mem_limit: 2g nadal działa. Pełny przewodnik po limitach pamięci w Compose opisuje rezerwacje oraz zachowanie kontenera po osiągnięciu limitu. Jeśli Docker nie jest jeszcze zainstalowany na serwerze, należy najpierw zainstalować Docker na VPS.

Jedna pułapka często powoduje stratę czasu. Kontener ograniczony do 2 GB nadal odczytuje wartość /proc/meminfo hosta oraz liczbę jego rdzeni CPU, ponieważ parametry te nie są objęte przestrzeniami nazw (namespacing). Narzędzie testowe, które dobiera liczbę procesów roboczych na podstawie liczby CPU, uruchomi osiem procesów wewnątrz kontenera 2 GB na hoście z ośmioma vCPU, co doprowadzi do błędu 137. Wartości te należy ustawić ręcznie:

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

Parametr --max-old-space-size wyrażony jest w MB i ogranicza stertę V8. Należy ustawić go poniżej limitu kontenera, aby Node zgłosił czytelny błąd zamiast nagłego zakończenia działania:

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

Ten komunikat jest użyteczny, ponieważ wskazuje przekroczony limit oraz proces, który go przekroczył. Mechanizm OOM killer nie dostarcza takich informacji.

Uruchamianie kilku sesji agenta na jednej maszynie

Planuj zasoby dla sesji, a nie dla użytkownika. Dwie sesje w tym samym repozytorium oznaczają dwa serwery języka, dwa zestawy pamięci podręcznej kompilacji w pamięci RAM oraz dwa uruchomienia testów, jeśli oba agenty zostaną obciążone w tym samym momencie. Dlatego wiersz zespołu przeskakuje do 16 GB.

Ustaw każdemu użytkownikowi sztywny limit, aby jedna niekontrolowana sesja nie spowodowała awarii całego serwera:

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

Zastąp 1001 identyfikatorem UID, który wyświetliło id -u. Polecenie systemctl show powinno zwrócić MemoryMax=6442450944 po zalogowaniu się użytkownika. Gdy suma procesów w sesji danego użytkownika przekroczy 6 GB, jądro systemu zakończy proces wewnątrz jego slice'a, dzięki czemu pozostałe sesje będą nadal działać. W przypadku agenta działającego jako usługa, a nie w terminalu, umieść MemoryMax= w pliku jednostki (unit file). Jest to zalecany wzorzec postępowania w przypadku samodzielnego hostowania agenta jako usługi działającej w trybie ciągłym.

FAQ

Czy 2 GB pamięci RAM wystarczy dla agenta programistycznego?

Dla samego procesu agenta – tak. Dla zadań, które wykonuje – rzadko. Agent zajmuje zazwyczaj 250 MB, jednak jeden serwer języka TypeScript może osiągnąć 2000 MB w średniej wielkości repozytorium, co w maszynie z 2 GB RAM wymusza korzystanie ze swap. 2 GB wystarcza do edycji plików konfiguracyjnych i małych skryptów. Należy przyjąć 4 GB jako minimum dla każdego zadania wymagającego kompilacji lub uruchomienia zestawu testów.

Czy do uruchomienia agenta programistycznego na VPS potrzebny jest GPU?

Nie, jeśli agent korzysta z modelu chmurowego przez API. To obciążenie zależy od przepustowości sieci, więc standardowy VPS z CPU jest odpowiednim rozwiązaniem, a GPU pozostawałoby bezczynne przy znacznie wyższej cenie. GPU jest potrzebne tylko wtedy, gdy model uruchamiany jest na tej samej maszynie; wtedy problemem staje się nie RAM, lecz VRAM i rozmiar modelu.

Ile pamięci swap należy dodać do VPS z agentem?

Połowę dostępnej pamięci RAM, maksymalnie do około 4 GB. Swap chroni przed krótkotrwałym przekroczeniem limitu, ponieważ jądro może przenieść nieaktywne strony pamięci na dysk zamiast kończyć proces. Nie zwiększa to ilości użytecznej pamięci. Jeśli vmstat 1 wykazuje stały ruch w kolumnach si oraz so, system wpada w thrashing, co oznacza konieczność zmniejszenia liczby równoległych zadań lub przejścia na wyższy plan.

Dlaczego agent programistyczny zawiesza się w trakcie budowania projektu?

Budowanie zostało niemal na pewno przerwane przez mechanizm OOM killer jądra, który wysyła sygnał SIGKILL. W efekcie nic nie jest wypisywane w logach, a agent oczekuje na potok, który nigdy nie zostanie wypełniony. Należy uruchomić sudo dmesg -T | grep -i "killed process" i sprawdzić nazwę procesu oraz jego wartość anon-rss. Problem można rozwiązać poprzez ograniczenie procesu budowania za pomocą systemd-run --user --scope -p MemoryMax=4G i zmniejszenie liczby wątków roboczych lub poprzez zwiększenie ilości pamięci RAM.