Altman will Ihren DRAM im Rechenzentrum: Server-RAM 2026
Kurz gesagt (geprüft am 2026-10-31): Sam Altman hält Arbeitsspeicher in privaten Computern für eine schlechte Verwendung eines knappen Chips; im Rechenzentrum, wo er geteilt wird, leiste er mehr. Die Angebotsseite bestätigt die Knappheit: TrendForce erwartete für Server-DRAM im 3Q26 Vertragspreise +13-18% gegenüber dem Vorquartal und für herkömmlichen DRAM im 4Q26 +10-15%, wobei Server-DRAM knapp bleibt. Für Servermieter ist die nützliche Frage enger: Wie viel des RAM, den Sie schon bezahlen, nutzen Sie wirklich? Unten steht ein Skript, das es misst, und was unsere eigenen Cloud-Tarife pro zusätzlichem Gigabyte kosten.
Quelle. Altman sprach im Podcast Cheeky Pint mit John Collison. Tom's Hardware und andere berichteten am 2026-10-30 darüber, die Aussagen wurden auf Hacker News diskutiert. Die Zitate unten stehen so, wie diese Berichte sie drucken (englisch, mit unserer Übersetzung).
Was er sagte und was er nicht belegte
Zum Thema lokale Inferenz sagte Altman, "a lot of people want local inference" (viele wollen lokale Inferenz) und nähmen an, offene Modelle auf eigenen Rechnern machten Speicher im Rechenzentrum überflüssig. Seine Antwort: "From a global allocation perspective, actually, it's quite terrible to have everybody have a bunch of the world's limited supply of DRAM sitting in their own computer and being used 5% of the time." Also: Aus Sicht der globalen Verteilung sei es schlimm, dass das knappe DRAM der Welt in jedem Rechner liege und 5% der Zeit genutzt werde. Und: In einer so knappen Lage wolle man maximale Auslastung in der Cloud.
Zwei Dinge sollte man trennen. Das Auslastungsargument stimmt, es ist das ganze Geschäftsmodell von Shared Hosting: Der Speicher eines physischen Servers wird an viele Kunden verkauft, also liegt weniger davon brach. Die 5% belegt das Interview aber mit nichts: keine Studie, keine Definition von "genutzt". Und der Sprecher führt ein Unternehmen, dessen Modelle in Rechenzentren laufen, die Schlussfolgerung passt also zu seinem Geschäft. Beides macht die Knappheit nicht falsch; beides ist ein Grund, den eigenen Fall zu messen, statt eine fremde Zahl zu übernehmen.
Die Speicherknappheit mit Datum
| Datum | Was geschah | Quelle |
|---|---|---|
| 2025-12-03 | Micron kündigte den Ausstieg aus dem Crucial-Endkundengeschäft an; Lieferungen an Endkunden enden mit dem Geschäftsquartal Q2 (Februar 2026) | Micron-Pressemitteilung |
| 2026-07-09 | Vertragspreise für Server-DRAM im 3Q26 erwartet +13-18% zum Vorquartal; Langzeitverträge begrenzen Erhöhungen für manche Käufer | TrendForce |
| 2026-09-30 | Vertragspreise für herkömmlichen DRAM im 4Q26 erwartet +10-15% zum Vorquartal; Server-DRAM bleibt knapp | TrendForce |
Die Reihenfolge zählt für Serverkäufer. Die Hersteller verlagern ihre Produktion auf Rechenzentrumsprodukte, und doch nennt TrendForce gerade Server-DRAM weiterhin knapp. Käufer mit mehrjährigen Verträgen sind teilweise geschützt; ein kleines Unternehmen, das Module für einen neuen Server kauft, oder ein Anbieter, der einen auf Bestellung baut, zahlt nahe am aktuellen Vertragspreis.
Was das für Servermieter bedeutet
- Dedizierte Server. Ein dedizierter Server wird aus Teilen zu heutigen Preisen gebaut, und bei RAM erwartete TrendForce bis Ende 2026 weiter steigende Vertragspreise. Eine 2025 kalkulierte Konfiguration kostet heute meist mehr, und ein RAM-Upgrade an einem gemieteten Server folgt demselben Markt. Kalkulieren Sie Ihren Server im Konfigurator für dedizierte Server; er nutzt aktuelle Teilepreise.
- Cloud-Server. In der Cloud mieten Sie Speicher in Scheiben, also Altmans Auslastungsargument zu Ihren Gunsten. Bei unseren veröffentlichten Tarifen (Prag, ohne MwSt., geprüft am 2026-10-31) kostet Large (8 vCPU, 16 GB RAM, 160 GB SSD) EUR 36.88 im Monat und X-Large (8 vCPU, 32 GB RAM, 160 GB SSD) EUR 59.92: Die zusätzlichen 16 GB kosten EUR 23.04, also EUR 1.44 pro GB und Monat. Das sind heutige Preise, kein Versprechen für nächstes Jahr.
- In beiden Fällen ist ungenutzter RAM der Kostenpunkt, den Sie steuern. Ein Server, ausgelegt auf eine Spitze, die nie kommt, ist die Serverraum-Version des Laptops, den Altman beschreibt.
Messen Sie Ihre eigenen 5%: ramuse.py
Linux zeigt in /proc/meminfo, wie viel Speicher ohne Swap vergeben werden könnte (MemAvailable). Gesamt minus diesen Wert ist, was Ihre Last wirklich hält; Seitencache, den der Kernel freigeben kann, zählt nicht. Das Skript misst das in Intervallen und gibt Durchschnitt, Spitze, nie berührten Speicher und die kleinste Zweierpotenz aus, die die Spitze plus 25% Reserve fasst. Python 3, nur Standardbibliothek, nur Linux. Speichern Sie es als ramuse.py:
#!/usr/bin/env python3
"""ramuse.py - how much of this server's RAM is actually used.
Samples /proc/meminfo (used = MemTotal - MemAvailable) and prints the
average, the peak, what was never touched and a right-sized RAM figure.
usage: python3 ramuse.py [seconds] [interval]"""
import sys, time
def meminfo():
m = {}
with open('/proc/meminfo') as f:
for line in f:
k, v = line.split(':')
m[k] = int(v.split()[0]) # kB
return m['MemTotal'], m['MemTotal'] - m['MemAvailable']
dur = int(sys.argv[1]) if len(sys.argv) > 1 else 60
step = int(sys.argv[2]) if len(sys.argv) > 2 else 5
used = []
for i in range(max(1, dur // step)):
total, u = meminfo()
used.append(u)
if i < dur // step - 1:
time.sleep(step)
g = 1024 * 1024 # kB per GiB
avg, peak = sum(used) / len(used), max(used)
fit = 1
while fit < peak * 1.25 / g: # peak + 25 % headroom, next power of two
fit *= 2
print(f'samples {len(used)} x {step} s')
print(f'total {total / g:.1f} GiB')
print(f'used avg {avg / g:.1f} GiB ({100 * avg / total:.0f}%)')
print(f'used peak {peak / g:.1f} GiB ({100 * peak / total:.0f}%)')
print(f'never touched {(total - peak) / g:.1f} GiB')
print(f'fits in {fit} GiB (peak + 25%, next power of 2)')
python3 ramuse.py 60 5
Ausgabe, ausgeführt auf einem DCXV Cloud-Server mit Python 3.14.4 am 2026-10-31:
samples 12 x 5 s
total 3.7 GiB
used avg 1.5 GiB (40%)
used peak 1.5 GiB (40%)
never touched 2.2 GiB
fits in 2 GiB (peak + 25%, next power of 2)
So liest man es. Das ist die 4-GB-Maschine, die diese Beiträge schreibt, eine Minute lang gemessen, während sie genau das tat: höchstens 1,5 GiB belegt, 2,2 GiB in diesem Zeitraum nie berührt. Eine Minute beweist nichts über die richtige Größe. Lassen Sie das Skript eine Woche unter echter Last laufen, etwa python3 ramuse.py 604800 300 > ramuse.txt in tmux, und achten Sie darauf, dass Ihr stärkster Tag dabei ist. Zwei Hinweise: Eine Datenbank oder ein Dateiserver nutzt freien RAM als Cache und wird damit schneller, "never touched" ist also nicht immer Verschwendung; und eine kurze Spitze (Backup, Deploy) ist trotzdem eine Spitze, die passen muss, sonst swappt der Kernel oder beendet einen Prozess. Regeln je Workload stehen in unserem Leitfaden zur Größe von Cloud-Servern.
Lokal, Cloud oder eigener Server
Altmans Darstellung kennt zwei Optionen: Speicher in Ihrem PC oder in seinem Rechenzentrum. Ein Unternehmen hat eine dritte, einen Server, den Sie mieten und selbst kontrollieren:
- Lokal bleiben, wenn die Daten das Gerät nicht verlassen dürfen oder die Arbeit nur gelegentlich anfällt; dieser RAM ist schon bezahlt.
- Eine geteilte API nutzen, wenn die Nachfrage schwankt und die Daten an Dritte gehen dürfen.
- Einen eigenen Server in der EU betreiben, wenn die Last gleichmäßig ist, die Daten unter Ihrer Kontrolle bleiben müssen oder Sie die Modellgewichte selbst wählen wollen. Speicherbedarf je Modellgröße steht in LLMs mit Ollama in Europa hosten, die Preise für 64 GB in was ein Server mit 64 GB RAM kostet.
Speicher ist dieses Jahr der teure Teil, also lohnt sich die dritte Option nur, wenn sie nach Messung und nicht nach Gefühl dimensioniert ist.
Erst messen, dann kaufen
Lassen Sie das Skript eine Woche laufen und wählen Sie den Tarif nach der Zeile "fits in". Unsere Tier-III-Rechenzentren in Prag und Covilha betreiben Cloud-Server mit bis zu 256 GB RAM; für eine feste, hohe Last einen dedizierten Server, konfiguriert auf die gemessene Spitze. Schicken Sie die Ausgabe an sales@dcxv.com, und wir schlagen eine Größe vor.
