Wie viel RAM braucht ein einfacher VPS?

Für einen einzelnen Bot, eine kleine API oder eine statische Seite reicht 1 GB – oft mit Luft. 2 GB sind der bequeme Standard, sobald eine Datenbank oder Docker dazukommt. Unter 1 GB fangen moderne Paketmanager und Sprach-Runtimes an zu leiden.

Wie viel RAM brauche ich für ein LLM auf einem VPS?

Etwa die Modellgröße bei ihrer Quantisierung plus ein, zwei Gigabyte für den Kontext. Ein 7–8B-Modell in 4 Bit braucht rund 5–6 GB, ein 14B-Modell etwa 10 GB, 32B um die 20 GB und 70B etwa 40–45 GB. Genau dafür gibt es 64-GB-Server: Ein 70B-Modell passt hinein, mit Platz für den Rest deines Stacks.

Ist Swap ein Ersatz für RAM?

Nein. Swap ist ein Sicherheitsnetz für kurze Spitzen – er verhindert, dass ein Build oder ein Backup gekillt wird. Wenn eine Anwendung den ganzen Tag im Swap lebt, wird alles langsam; das ist das Signal für einen größeren Tarif.

Wie sehe ich, wie viel RAM mein Server wirklich nutzt?

Führ 'free -h' aus und schau auf die Spalte 'available', nicht 'free' – Linux nutzt freien Speicher als Festplatten-Cache und gibt ihn bei Bedarf zurück. 'ps aux --sort=-rss | head' zeigt die größten Prozesse, 'docker stats --no-stream' den Verbrauch pro Container.

Wann lohnt sich ein VPS mit 64 GB?

Wenn eine einzelne große Sache im Speicher liegen muss: ein lokales Modell mit 32–70B, ein großer Vektorindex für RAG oder eine Agentenflotte mit eigenen Runtimes. Für Websites, Bots und die meisten APIs ist es rausgeworfenes Geld.

Wie viel RAM braucht ein VPS? Echte Zahlen je Aufgabe

Die meisten raten beim RAM. Entweder kaufen sie viel zu viel „für alle Fälle“, oder sie lernen den OOM-Killer um drei Uhr nachts kennen. Dabei ist Speicher eines der am leichtesten zu dimensionierenden Dinge, denn Workloads sind vorhersagbar, sobald man die groben Zahlen kennt. Hier sind sie – vom 1-GB-Server für einen Bot bis zu den 64-GB-Servern, nach denen Leute suchen, wenn sie ein großes Modell lokal betreiben wollen.

Grobe Zahlen je Aufgabe

Das sind reale Werte im Dauerbetrieb für ein typisches Setup, keine Mindestangaben aus der Doku.

Aufgabe	Tatsächlicher RAM-Bedarf	Passender Tarif
Telegram-/Discord-Bot (Python, Node.js)	100–300 MB	Nano 1 GB
Statische Seite + Caddy/Nginx	50–150 MB	Nano 1 GB
WordPress + MariaDB, normaler Traffic	0,8–1,5 GB	Micro-IP 2 GB
PostgreSQL für eine kleine App	0,5–2 GB (du entscheidest über `shared_buffers`)	Micro / Small
n8n mit ein paar Workflows	0,5–1,5 GB	Micro 2 GB
Docker-Host mit 5–10 kleinen Diensten	2–4 GB	Small 4 GB
Coolify + Builds + eine Datenbank	3–4 GB	Small-IP 4 GB
7–8B-LLM, 4 Bit, CPU-Inferenz	5–6 GB	Medium 6 GB
14B-LLM, 4 Bit	~10 GB	Pro-32
32B-LLM, 4 Bit	~20 GB	Pro-32
70B-LLM, 4 Bit	~40–45 GB	Pro-48 / Pro-64

Zwei Dinge fallen auf. Erstens ist der Sprung zwischen „normalen“ Aufgaben und LLMs riesig – ein Bot und ein 70B-Modell unterscheiden sich um den Faktor zweihundert. Zweitens kommen die meisten Dienste mit 1–4 GB aus; man kauft zu viel, weil man für eine Zukunft plant, die selten eintritt.

Die LLM-Formel

Für Sprachmodelle gibt es eine einfache Schätzung: Parameter × Bit pro Gewicht ÷ 8, plus Overhead. Ein 8B-Modell mit rund 4,5 Bit (eine typische Q4-Quantisierung) sind 8 × 4,5 ÷ 8 ≈ 4,5 GB Gewichte. Dazu 1–2 GB für das Kontextfenster (der KV-Cache wächst mit der Kontextlänge) und die Runtime – und du landest bei 5–6 GB.

Der ehrliche Teil: Auf reinen CPU-Servern ist Speicher nur die halbe Geschichte. Rechne mit einstelligen Tokens pro Sekunde für 7–8B-Modelle auf ein paar vCPUs und etwa einem Token pro Sekunde für 70B. Für Batch-Jobs, Hintergrund-Agenten und private Experimente ist das in Ordnung; ein Chat für viele gleichzeitige Nutzer ist es nicht. Wenn du hauptsächlich gehostete Modell-APIs aufrufst, braucht dein Agent weit weniger – siehe VPS-Dimensionierung für KI-Agenten.

Messen statt raten

Wenn du schon einen Server hast, liegen die Zahlen direkt vor dir:

free -h                              # look at "available", not "free"
ps aux --sort=-rss | head -n 8       # the biggest processes, by resident memory
docker stats --no-stream             # per-container usage

Linux nutzt ungenutzten RAM als Festplatten-Cache, deshalb ist „free“ immer klein – und das ist gesund. Available ist die Zahl, die zählt: Speicher, den der Kernel Programmen sofort geben kann. Bleibt available in deiner stärksten Stunde über ~25 %, ist die Größe richtig. Fällt er regelmäßig auf null und wächst der Swap, geh eine Stufe höher.

Prüf auch vergangene OOM-Kills:

journalctl -k | grep -i "out of memory"

Swap: Sicherheitsgurt, kein Motor

Eine 1–2 GB große Swap-Datei auf einem kleinen Server ist eine billige Versicherung: Ein Paket-Upgrade oder ein Docker-Build, der kurz mehr Speicher braucht, überlebt, statt gekillt zu werden. Lebt ein Dienst aber im Swap, wartet jede Anfrage auf die Festplatte. Swap ist für Spitzen. Dauerhaftes Swappen heißt: Du brauchst den nächsten Tarif.

Wie viel solltest du also kaufen?

1 GB – ein Bot, eine kleine API, eine statische Seite.
2 GB – der vernünftige Standard für alles mit Datenbank oder Docker.
4–6 GB – mehrere Dienste auf einer Maschine, Builds auf dem Server, ein kleines lokales Modell.
32–64 GB – nur wenn eine große Sache im Speicher leben muss: ein lokales Modell über 14B, ein großer RAG-Index, eine Agentenflotte. Dafür gibt es die Tarife mit viel Speicher.

Fang eine Nummer kleiner an, als dein Bauch sagt, beobachte free -h eine Woche lang und rüste auf, wenn die Zahlen es verlangen. Bei EQVPS behält ein Tarif-Upgrade deine Daten und berechnet nur die anteilige Differenz (so funktioniert der Tarifwechsel).