Wie viel RAM braucht ein VPS für einen Coding-Agenten?

Wie viel RAM benötigt ein VPS für einen Coding-Agenten?

Starten Sie mit 4 GB RAM und 2 vCPU für einen dauerhaft aktiven Coding-Agenten, der in einem Repository arbeitet. Wechseln Sie zu 8 GB RAM und 4 vCPU, sobald ein Language Server oder ein Docker-Build zur Sitzung hinzukommt. Das ist bei den meisten Repositories bereits am ersten Tag der Fall. Der Agent-Prozess selbst benötigt wenig Speicher. Den Arbeitsspeicher belegen vor allem die Toolchains, die der Agent in Ihrem Auftrag verwendet.

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

Jede Zeile oben setzt voraus, dass das Modell an anderer Stelle läuft und über eine API per Netzwerk angesprochen wird. Diese Annahme bestimmt die gesamte Dimensionierungsfrage. Klären Sie sie daher zuerst.

Läuft bei Ihnen der Agent oder das Modell?

Ein Coding-Agent, der ein Cloud-Modell aufruft, ist ein Netzwerkclient mit angeschlossener Shell. Er sendet Dateien und einen Plan an eine API, wartet auf die Antwort, bearbeitet anschließend lokal Dateien und führt Befehle aus. Während der Wartezeit benötigt er nahezu keine CPU-Leistung. Sein eigener Speicherbedarf liegt bei einigen hundert Megabytes. Deshalb ist eine Maschine mit moderater CPU die richtige Wahl.

Das Modell selbst auszuführen ist ein anderes Produkt auf anderer Hardware. Die Gewichte bleiben im Speicher, solange der Server läuft. Ein Modell mit 7 Milliarden Parametern, das auf 4 Bit quantisiert ist, benötigt allein für die Gewichte ungefähr 5 GB. Hinzu kommt der Key/Value-Cache, der mit der Kontextlänge wächst. Ausschließlich auf der CPU erzeugt eine gemeinsam genutzte vCPU wenige Tokens pro Sekunde. Eine einzelne Agent-Aufgabe kann Tausende Tokens erzeugen. Daher dauert eine Arbeit, die über eine API weniger als eine Minute benötigt, lokal den größten Teil einer Stunde. Wenn Sie genau das möchten, dimensionieren Sie die Maschine nach VRAM (Videospeicher der GPU) und lesen Sie was ein VPS mit einer GPU tatsächlich bietet, statt diese Seite zu verwenden.

Alle folgenden Abschnitte setzen den Betrieb mit einem Cloud-Modell voraus.

Was tatsächlich Arbeitsspeicher verwendet

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

Das sind typische veröffentlichte Werte für mittelgroße Projekte. Betrachten Sie sie als Größenordnung, nicht als Zusage für Ihren Code.

Das Diagramm enthält 6 Zeilen, und der Agent benötigt am wenigsten Speicher. Im Leerlauf liegt er bei etwa 250 MB, weil er eine Unterhaltung und einen kleinen Dateicache vorhält und sonst nichts. Ein TypeScript-Sprachserver erreicht beim Indizieren etwa 2000 MB, weil er für jede über tsconfig.json erreichbare Datei einen Typgraphen aufbaut und diesen anschließend im Arbeitsspeicher hält, um die nächste Anfrage schnell zu beantworten. rust-analyzer überschreitet in einem großen Workspace aus demselben Grund häufig 4000 MB, und zwar für jedes Crate im Workspace.

Headless Chrome benötigt für den Browser und einen Tab etwa 350 MB. Jeder zusätzliche Tab ist ein weiterer Betriebssystemprozess. Ein Node-Testlauf mit vier Workern besteht aus vier Node-Prozessen und erreicht daher einen Spitzenwert von etwa 3000 MB. Ein Docker-Image-Build erreicht etwa 2500 MB, weil der Build den eigenen Compiler des Projekts im Container ausführt, während der Daemon die Layer schreibt.

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

Lesen Sie die Spalte free -h für available, nicht die Spalte free. Linux verwendet jede freie Speicherseite als Plattencache. Deshalb ist free auf einem vollständig gesunden System klein und sagt nichts aus. available zeigt, wie viel Speicher ein neuer Prozess tatsächlich erhalten kann.

Drei funktionierende Konfigurationen

Minimal sinnvoll: 4 GB RAM, 2 vCPU, 50 GB Speicherplatz. Eine Agent-Sitzung, ein Repository, ein Language Server und Builds, deren Abschluss Sie abwarten können. Diese Konfiguration funktioniert, aber der Out-of-Memory-Killer wird aktiv, sobald ein großer Testlauf gleichzeitig mit einem Language Server für die Indizierung läuft. Richten Sie Swap ein und begrenzen Sie die Anzahl der Build-Worker.

Komfortabel: 8 GB RAM, 4 vCPU, 100 GB Speicherplatz. Ein Agent, zusätzlich Docker und ein Headless-Browser für Tests, mit Reserven für einen kurzzeitig erhöhten Bedarf beim Build. Diese Konfiguration ist für die meisten Einzelentwickler die richtige Wahl. Eine Verdopplung der vCPU-Anzahl halbiert die Wartezeit beim Build ungefähr. Das spüren Sie deutlich häufiger als einen höheren Speicherbedarf.

Team: 16 GB RAM, 8 vCPU, 200 GB Speicherplatz. Vier gleichzeitige Sitzungen, jeweils mit eigenem Checkout und eigener Toolchain. Planen Sie für die Spitzenlast, weil vier inaktive Agenten kaum Kosten verursachen, während vier gleichzeitig laufende Testdurchläufe das Vierfache des Spitzenwerts aus der obigen Spalte benötigen.

Im August 2026 beträgt der monatliche Preis beim jährlichen VPS-Abrechnungsmodell vom ersten bis zum letzten Eintrag ungefähr das Vierfache: unten ein einstelliger Betrag pro Monat, oben ein Betrag im zweistelligen Bereich. Prüfen Sie vor der Planung das aktuelle Angebot, weil sich diese Preise ändern. Der Server ist nur selten der teuerste Bestandteil. Wenn Sie täglich mit einem Agenten arbeiten, übersteigen die Kosten für die Model API schnell die Serverkosten. Legen Sie deshalb fest, wie viel der Agent ausgeben darf, bevor Sie den Server kleiner dimensionieren. Für den Build selbst behandelt die Anleitung zum Ausführen eines Coding-Agenten auf einem VPS die Einrichtung des Kontos und die Aufrechterhaltung der Sitzung nach dem Trennen der Verbindung.

Warum der Speicherplatz vor dem RAM knapp wird

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

Wenn Sie diese Werte addieren, ist ein Datenträger mit 50 GB fast voll, bevor Sie eine einzige Codezeile geschrieben haben. Der größte Einzelposten ist Docker mit ungefähr 20 GB, weil BuildKit jede temporäre Ebene jedes Builds behält, bis Sie sie löschen.

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

docker system df gibt den freigebbaren Speicherplatz nach Kategorie aus. Führen Sie den Befehl daher vor und nach der Bereinigung aus. Der Filter until=168h löscht Build-Cache, der älter als eine Woche ist, und behält den Cache dieser Woche. Dieser Cache spart weiterhin Zeit. docker image prune -a geht weiter und entfernt jedes Image, das von keinem Container verwendet wird. Rechnen Sie daher damit, dass der nächste Build die Images erneut herunterlädt.

Bei Node-Projekten tritt ein ungewöhnlicheres Problem auf. npm install schreibt Hunderttausende kleine Dateien. Dadurch können dem Dateisystem die Inodes ausgehen, während df -h weiterhin freie Gigabytes meldet. Der Schreibvorgang schlägt dann mit No space left on device fehl, obwohl der Datenträger scheinbar halb leer ist.

df -h /
df -i /

Wenn IUse% den Wert 100 ausgibt, löschen Sie die node_modules-Verzeichnisse von Branches, die Sie nicht mehr verwenden. Alternativ können Sie zu pnpm wechseln. Dabei wird jede Paketversion einmal gespeichert und per Hardlink in jedes Projekt eingebunden.

Logs sind die unauffällige Ursache. Ein dauerhaft aktiver Agent schreibt Sitzungsprotokolle, und das systemd-Journal wächst standardmäßig auf einen beträchtlichen Anteil des Datenträgers an.

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

Setzen Sie SystemMaxUse=200M in /etc/systemd/journald.conf und führen Sie sudo systemctl restart systemd-journald aus, damit diese Obergrenze dauerhaft gilt. Eine einmalige Bereinigung mit vacuum schafft nur vorübergehend Speicherplatz.

Swap: Was sie bringt und was sie verbirgt

Swap ist sinnvoll, weil ein kleiner Speicherüberschuss dadurch langsame Arbeit statt eines beendeten Prozesses verursacht. Dimensionieren Sie sie auf die Hälfte des RAM, höchstens jedoch auf etwa 4 GB. Auf einem Build-Server gibt es kaum einen Grund, darüber hinauszugehen.

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 sollte jetzt /swapfile in der angeforderten Größe auflisten. Ohne die Zeile /etc/fstab ist der Swap nach dem nächsten Reboot nicht mehr verfügbar, und der Server verhält sich wieder wie zuvor. Wenn fallocate mit Operation not supported antwortet, erstellen Sie die Datei mit sudo dd if=/dev/zero of=/swapfile bs=1M count=4096 und fahren Sie ab chmod fort.

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

Ein niedriger Swappiness-Wert weist den Kernel an, zunächst den Disk-Cache freizugeben, bevor er den Programmspeicher auf den Datenträger auslagert. Dadurch bleibt ein Language Server reaktionsfähig.

Nun zum Problem, das Swap verbirgt. Wenn ein Job tatsächlich mehr Speicher benötigt, als der Server besitzt, verbringt der Kernel seine Zeit damit, Pages zwischen RAM und Datenträger zu verschieben, statt den Build auszuführen. Nichts stürzt ab. Alles wird langsam, und der Load Average steigt, während die CPU untätig bleibt.

vmstat 1 10

Konstant von null verschiedene Werte in den Spalten si und so bedeuten kontinuierliches Swapping. Die Lösung besteht dann in weniger Parallelität oder mehr RAM, niemals in mehr Swap. Auf einem kleinen Server stellt sudo apt install -y zram-tools komprimierten Swap im RAM bereit, der in /etc/default/zramswap konfiguriert wird. Das ist deutlich schneller als eine Swap-Datei. Dabei wird jedoch RAM verwendet, um RAM zu sparen. Das hilft bei selten verwendeten Pages, aber nicht bei einem Build, der tatsächlich mehr Arbeitsspeicher benötigt.

Warum Ihr Coding-Agent scheinbar hängt

Dies ist der am häufigsten falsch diagnostizierte Fehler auf einem kleinen Agent-Server. Ein Befehl liefert keine Ausgabe, der Agent wartet, und die Sitzung wirkt eingefroren. Der Prozess wurde vom Out-of-Memory-Killer (OOM-Killer) des Kernels beendet. Er erhielt SIGKILL und konnte daher weder einen Fehler ausgeben noch ein Log leeren oder dem Agent mitteilen, was passiert ist. Der Agent sieht ein leeres Ergebnis und keine Exit-Meldung.

Der Kernel protokolliert das Ereignis jedoch:

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

Eine echte Zeile sieht so aus:

[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 gibt an, wie viel Speicher dieser Prozess beim Beenden belegt hatte. Beachten Sie, welcher Prozess ausgewählt wurde: Der Kernel bewertet Prozesse hauptsächlich anhand des verwendeten Speichers. Daher beendet er häufig den Language Server oder den Agent statt des Builds, der den Server über seine Speichergrenze gebracht hat. Genau deshalb wirkt das Problem so, als sei „der Agent ausgefallen“.

Innerhalb von Docker hinterlässt dasselbe Ereignis eine eindeutigere Spur. Der Container wird mit Exit-Code 137 beendet. Das entspricht 128 plus Signal 9.

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

"OOMKilled": true bestätigt, dass der Container sein Speicherlimit erreicht hat und nicht selbst abgestürzt ist.

Die Lösung besteht darin, dem aufwendigen Befehl ein eigenes Limit zu geben. Dadurch wird der Build statt des Agents beendet:

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

Der Build wird nun bei 4 GB beendet, während der Agent weiterläuft. Aus einem schwer erklärbaren Hänger wird dadurch ein normal fehlgeschlagener Befehl mit einem auslesbaren Exit-Code. Dafür ist eine systemd-Benutzersitzung erforderlich. Führen Sie loginctl enable-linger $USER daher auf einem Server aus, den Sie nur über SSH erreichen. MemoryHigh= begrenzt den Prozess am Schwellenwert, statt ihn zu beenden. Für einen Build, der lieber langsam fertig werden soll, ist das häufig die schonendere Einstellung.

Einmal in Compose begrenzen: Speicherlimits

Wenn die Tools des Agenten in Containern ausgeführt werden, legen Sie die Obergrenze in der Compose-Datei fest. Dadurch gilt sie bei jedem Lauf.

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

Docker Compose v2 wendet deploy.resources.limits bei einem einfachen docker compose up an. Der Swarm-Modus ist daher nicht beteiligt. Der ältere Schlüssel mem_limit: 2g funktioniert weiterhin. Der vollständige Leitfaden zu Compose-Speicherlimits behandelt Reservierungen und das Verhalten, wenn ein Container seine Obergrenze erreicht. Wenn Docker noch nicht auf dem Server installiert ist, installieren Sie zuerst Docker auf einem VPS.

Eine Falle kostet viele Anwender einen ganzen Nachmittag. Ein auf 2 GB begrenzter Container liest weiterhin den /proc/meminfo des Hosts und die Anzahl der CPUs des Hosts, weil beides nicht durch Namespaces isoliert wird. Ein Test-Runner, der seine Worker-Anzahl aus der CPU-Anzahl ableitet, startet auf einem Host mit 8 vCPUs acht Worker in einem 2-GB-Container und beendet sich anschließend mit Status 137. Legen Sie die Werte manuell fest:

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

--max-old-space-size wird in MB angegeben und begrenzt den V8-Heap. Setzen Sie den Wert unter das Containerlimit. Dadurch gibt Node einen lesbaren Fehler aus, anstatt einfach zu verschwinden:

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

Diese Meldung ist hilfreich, weil sie das erreichte Limit und den betroffenen Prozess nennt. Der OOM-Killer tut das nie.

Mehrere Agent-Sitzungen auf einem Rechner ausführen

Planen Sie pro Sitzung, nicht pro Person. Zwei Sitzungen im selben Repository bedeuten weiterhin zwei Sprachserver, zwei Sätze Build-Caches im Arbeitsspeicher und zwei Testläufe, wenn beide Agents gleichzeitig ausgelastet sind. Deshalb steigt die Zeile für das Team auf 16 GB.

Legen Sie für jeden Benutzer eine feste Obergrenze fest, damit eine außer Kontrolle geratene Sitzung nicht den gesamten Rechner lahmlegt:

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

Ersetzen Sie 1001 durch die UID, die id -u ausgegeben hat. systemctl show sollte MemoryMax=6442450944 ausgeben, sobald der Benutzer sich angemeldet hat. Sobald alle Prozesse in der Sitzung dieses Benutzers 6 GB überschreiten, beendet der Kernel einen Prozess innerhalb seines Slices. Alle anderen Sitzungen arbeiten weiter. Wenn ein Agent als Dienst und nicht in einem Terminal ausgeführt wird, tragen Sie stattdessen MemoryMax= in seine Unit-Datei ein. Dieses Vorgehen sollten Sie verwenden, wenn Sie einen Agenten als dauerhaft laufenden Dienst selbst hosten.

FAQ

Reichen 2 GB RAM für einen Coding-Agent?

Für den Agent-Prozess: ja. Für die von ihm ausgeführten Aufgaben: selten. Der Agent belegt ungefähr 250 MB, aber ein einzelner TypeScript-Sprachserver kann in einem mittelgroßen Repository 2000 MB erreichen. Das allein zwingt ein System mit 2 GB bereits in den Swap. 2 GB reichen zum Bearbeiten von Konfigurationsdateien und kleinen Skripten. Verwenden Sie 4 GB als Mindestgröße für alles, was kompiliert oder eine Testsuite ausführt.

Benötige ich eine GPU, um einen Coding-Agent auf einem VPS auszuführen?

Nicht, wenn der Agent über eine API ein Cloud-Modell aufruft. Diese Arbeitslast ist netzwerkgebunden. Ein VPS mit normaler CPU ist daher die richtige Wahl. Eine GPU wäre bei deutlich höheren Kosten ungenutzt. Eine GPU benötigen Sie nur, wenn das Modell selbst auf demselben System ausgeführt wird. Dann geht es nicht mehr um RAM, sondern um VRAM und die Modellgröße.

Wie viel Swap sollte ich einem Agent-VPS hinzufügen?

Die Hälfte des RAM, höchstens etwa 4 GB. Swap schützt vor einer kurzfristigen Überschreitung, weil der Kernel inaktive Speicherseiten auf die Festplatte verschieben kann, anstatt einen Prozess zu beenden. Swap erweitert den nutzbaren Speicher nicht. Wenn vmstat 1 in den Spalten si und so dauerhaft Datenverkehr anzeigt, thrash’t das System. Verwenden Sie dann weniger parallele Worker oder einen größeren Tarif.

Warum friert mein Coding-Agent während eines Builds ein?

Der Build wurde mit hoher Wahrscheinlichkeit vom OOM-Killer des Kernels beendet. Dieser sendet SIGKILL. Daher wird nichts ausgegeben, und der Agent wartet auf einer Pipe, die sich nie füllt. Führen Sie sudo dmesg -T | grep -i "killed process" aus und prüfen Sie den Prozessnamen sowie seinen Wert in anon-rss. Begrenzen Sie den Build mit systemd-run --user --scope -p MemoryMax=4G und reduzieren Sie die Anzahl der Worker. Alternativ wechseln Sie in die nächsthöhere RAM-Stufe.