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.

Führen Sie den Agenten aus 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 lokal Befehle aus. Während der Wartezeit benötigt er nahezu keine CPU-Zeit. Sein eigener Speicherbedarf liegt im Bereich von mehreren hundert Megabytes. Deshalb ist ein Rechner mit moderater CPU die richtige Maschine.

Das Modell selbst auszuführen ist ein anderes Produkt auf anderer Hardware. Die Gewichte bleiben so lange im Speicher, wie der Server läuft. Ein Modell mit 7 Milliarden Parametern, das auf 4 Bit quantisiert wurde, benötigt für die Gewichte etwa 4 GB Speicher. Llama 2 7B wird als 3.83 GB in Q4_0 und 4.08 GB in Q4_K_M veröffentlicht. Der Herausgeber nennt 6.3 bis 6.6 GB RAM für den Betrieb ohne GPU, wenn der Laufzeit-Overhead berücksichtigt wird. Längere Kontexte benötigen mehr Speicher, weil der Key/Value-Cache mit der Kontextlänge wächst. Bei ausschließlicher CPU-Nutzung erzeugt eine gemeinsam genutzte vCPU wenige Tokens pro Sekunde. Eine einzelne Agentenaufgabe kann Tausende Tokens ausgeben. Eine Arbeit, die über eine API weniger als eine Minute dauert, benötigt lokal daher fast eine Stunde. Wenn Sie genau das möchten, dimensionieren Sie nach VRAM, also dem Videospeicher der GPU, und lesen Sie was ein VPS mit GPU tatsächlich bietet statt dieser Seite.

Alles Folgende setzt den Fall 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
  }
]

Addieren Sie diese Werte. Dann ist ein Datenträger mit 50 GB fast voll, bevor Sie eine Zeile Code geschrieben haben. Das größte einzelne Element ist Docker mit etwa 20 GB. BuildKit behält jede temporäre Schicht jedes Builds, bis Sie die Bereinigung anweisen.

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 davor und danach aus. Der Filter until=168h behält Cache-Einträge, die ein Build in der vergangenen Woche verwendet hat, und löscht den Rest. Maßgeblich ist die letzte Verwendung, nicht das Alter. Eine vor einem Monat erstellte, aber gestern wiederverwendete Schicht bleibt daher erhalten. Genau dieser Cache spart weiterhin Zeit. docker image prune -a geht weiter und entfernt jedes Image, das von keinem Container verwendet wird. Rechnen Sie deshalb 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, an denen Sie nicht mehr arbeiten. 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 laufender Agent schreibt Sitzungsprotokolle. Außerdem wächst das systemd-Journal standardmäßig auf einen beträchtlichen Anteil des Datenträgers.

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 schafft nur den Speicherplatz des aktuellen Tages frei.

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ängen bleibt

Dies ist der am häufigsten falsch diagnostizierte Fehler auf einem kleinen Agentenrechner. Ein Befehl gibt nichts zurück, 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 deshalb weder einen Fehler ausgeben, ein Log leeren noch dem Agenten mitteilen, was passiert ist. Der Agent sieht ein leeres Ergebnis und keine Exit-Meldung.

Der Kernel protokolliert das Ereignis trotzdem:

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 der Prozess beim Beenden belegt hatte. Beachten Sie, welcher Prozess ausgewählt wurde: Der Kernel bewertet Prozesse überwiegend nach ihrem aktuellen Speicherverbrauch. Deshalb beendet er häufig den Language Server oder den Agenten und nicht den Build, der den Rechner über die Grenze gebracht hat. Genau deshalb wirkt das Symptom so, als sei „der Agent kaputt“.

Innerhalb von Docker hinterlässt dasselbe Ereignis einen eindeutiger erkennbaren Hinweis. Der Container wird mit dem 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, statt selbstständig abzustürzen.

Die Lösung besteht darin, dem aufwendigen Befehl eine eigene Obergrenze zu geben. Dann wird der Build beendet und nicht der Agent:

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

Der Build wird nun bei 4 GB beendet und der Agent bleibt aktiv. Aus dem unerklärlichen Hängen wird dadurch ein gewöhnlicher fehlgeschlagener Befehl mit lesbarem Exit-Code. Dafür ist ein systemd User Manager erforderlich. Eine normale SSH-Anmeldung startet ihn automatisch, sodass der Befehl über SSH unverändert funktioniert. loginctl enable-linger $USER wird nur benötigt, damit User Units nach dem Abmelden weiterlaufen. MemoryHigh= begrenzt den Prozess am Schwellenwert, statt ihn zu beenden. Das ist häufig die geeignetere Einstellung für einen Build, der lieber langsam fertig werden soll.

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.