VPS mit 64 GB RAM

Vierundsechzig Gigabyte sind bereits ein spürbarer Teil eines physischen Servers: Auf einem typischen Virtualisierungsknoten mit 256–512 GB belegt eine solche Maschine ein Achtel oder ein Viertel des Speichers. Deshalb verhält sich ein VPS mit 64 GB RAM anders als kleine Tarife: Vom Anbieter hängt nicht nur die Speichermenge ab, sondern auch, wie die Maschine auf der Hardware platziert ist. Einen solchen Server sollten Sie für eine konkrete, messbare Last nehmen und nicht „auf Vorrat“.

Lasten, die wirklich 64 GB brauchen

• Caches und In-Memory-Speicher. Redis oder Memcached mit Dutzenden Gigabyte Daten: Sitzungen, Queues, Zähler eines großen Dienstes. Bedenken Sie bei Redis, dass das Speichern eines Snapshots per fork bei Schreibspitzen den Verbrauch vorübergehend verdoppeln kann, mehr dazu im Abschnitt VPS für Redis.
• Datenbanken mit Hunderten Gigabyte, deren Arbeitsdatensatz – Indizes und aktive Tabellen – 40–50 GB erreicht.
• Suche und Logs. Ein Elasticsearch- oder OpenSearch-Knoten mit 31 GB Heap (mehr lässt die JVM wegen der komprimierten Zeiger nicht sinnvoll zu) und einem gleich großen Anteil für den Dateicache – die klassische Konfiguration genau für 64 GB.
• Sprachmodelle mit 70 Mrd. Parametern in 4-Bit-Quantisierung: Das Modell belegt rund 40 GB. Auf dem Prozessor antwortet es langsam, daher eignet sich ein solcher Server für die Stapelverarbeitung von Texten, nicht für einen Chat.
• Einmalige schwere Aufgaben: Neuberechnung von Analysen, Migration einer großen Datenbank, Build eines großen Monorepos, Verarbeitung eines Datensatzes.

Ein häufiger Fehler: 64 GB für ein Projekt zu nehmen, das nicht Speicher, sondern horizontale Skalierung braucht. Eine Webanwendung stößt mit wachsendem Traffic meist an Prozessor und Datenbank, und zwei bis drei Server mit 16 GB hinter einem Load Balancer sind zuverlässiger als eine große Maschine: Fällt ein Knoten aus, steht der Dienst nicht still. Ein einzelner großer VPS lohnt sich dort, wo sich Daten nicht leicht aufteilen lassen – ein gemeinsamer Cache, eine gemeinsame Datenbank, ein Index.

Kerne, Speicherbandbreite und NUMA

Üblicherweise kommen 64 GB mit 8–16 virtuellen Kernen und Festplatten von 500 GB bis zu mehreren Terabyte. Bei dieser Größe zählt nicht nur die Kapazität, sondern auch die Geschwindigkeit des Speichers: Analytik und KI-Inferenz stoßen an die Bandbreite, die von der Prozessorgeneration und der Zahl der Kanäle abhängt. Serverplattformen mit vielen Speicherkanälen, etwa VPS mit AMD EPYC, sind hier Desktop-Plattformen deutlich überlegen.

Die zweite Besonderheit ist NUMA. Eine Maschine mit 64 GB und 16 Kernen erstreckt sich nicht selten über zwei physische Prozessoren, und der Zugriff auf „fremden“ Speicher ist langsamer. Prüfen Sie lscpu und numactl --hardware: Gibt es zwei Knoten, starten Sie die Datenbank mit numactl --interleave=all oder aktivieren Sie die NUMA-Einstellungen in der Software selbst.

Was Sie im Tarif und nach dem Kauf prüfen sollten

1. Virtualisierungstyp und Speichergarantie. Für diese Größe eignet sich nur KVM oder Vergleichbares mit vollständig zugeteiltem Speicher. Ein Container mit Burst auf 64 GB ist fast sicher ein überbuchter Knoten.
2. Ballooning und MemTotal. Der Wert in /proc/meminfo muss mit dem Tarif übereinstimmen und darf sich mit der Zeit nicht ändern.
3. Tatsächliches Füllen. Der Test stress-ng --vm 8 --vm-bytes 58G --timeout 300s darf weder einen OOM noch SSH-Abbrüche noch einen Steal-Anstieg über wenige Prozent auslösen.
4. Speichergeschwindigkeit. sysbench memory --memory-block-size=1M run oder STREAM: Ein Ergebnis, das um ein Vielfaches unter dem für den angegebenen Prozessor erwarteten liegt, deutet auf einen überlasteten Knoten hin.
5. Snapshots und Backups. Fragen Sie nach, ob der Anbieter Snapshots mit gesichertem Arbeitsspeicher erstellt: Bei einer Maschine mit 64 GB bedeutet das Minuten Ausfallzeit, planen Sie sie daher besser für die Nacht.

Swap und OOM auf einem großen Server

Ein großer Swap ist hier nutzlos: Reichen einem Dienst 64 GB nicht, rettet ihn die Festplattengeschwindigkeit auch nicht. 4–8 GB als Puffer für kurzzeitige Spitzen genügen. Viel wichtiger ist es, den Kernprozess zu schützen: Setzen Sie für die Datenbank OOMScoreAdjust=-900 in der systemd-Unit-Datei und geben Sie Hilfsdiensten MemoryMax= vor, damit der Kernel bei einem Speicherleck diese beendet und nicht den Hauptdienst.

VPS, dedizierter Server oder GPU

Wird die Maschine dauerhaft gebraucht und rund um die Uhr ausgelastet, ist ein physischer Server mit 64–128 GB oft nicht teurer und erspart Ihnen Nachbarn – vergleichen Sie die Varianten im Abschnitt dedizierte Server. Ein VPS ist für befristete Aufgaben günstiger: Tarife mit stundengenauer Abrechnung erlauben es, eine große Maschine für einen Tag Berechnungen zu starten und danach zu löschen. Und für KI-Modelle, bei denen die Antwortgeschwindigkeit zählt, unterliegen 64 GB normaler Arbeitsspeicher einem Server mit Grafikkarte selbst mit weniger RAM.