AMD EPYC Turin: Die passende Server-CPU für Hosting-Anbieter wählen

AMD EPYC Turin richtig einordnen

AMD EPYC Turin bezeichnet die EPYC-9005-Generation von Serverprozessoren. AMD stellte sie im Oktober 2024 als fünfte EPYC-Generation vor; zur Familie gehören Modelle mit Zen-5- und Zen-5c-Kernen.

Für Hosting-Anbieter ist Turin keine einzelne CPU mit einer einheitlichen Leistungscharakteristik. Die Modellpalette reicht von acht bis 192 Kernen pro Prozessor. Welches Modell passt, hängt davon ab, ob viele unabhängige Kundenanfragen parallel laufen, einzelne Anwendungen kurze Antwortzeiten benötigen oder virtuelle Maschinen vor allem viel Arbeitsspeicher beanspruchen.

Zur Auswahl gehört auch die Frage nach der Sockelzahl: Ein Server mit einem Prozessor bietet eine andere Kombination aus Rechenkapazität, Speicheranbindung und Erweiterungsmöglichkeiten als eine Zwei-Sockel-Plattform. Nicht jedes Modell ist für beide Varianten vorgesehen; Prozessoren mit P-Suffix sind laut Datenblatt für Single-Socket-Systeme ausgelegt.

Eine Vorauswahl beginnt daher beim konkreten Kundenmix und den Anforderungen an RAM, NVMe-Laufwerke und Netzwerk. Ein dichter VPS-Host benötigt beispielsweise Reserven für gleichzeitig aktive virtuelle Maschinen, während ein Datenbankserver zusätzlich auf Speicherbedarf und I/O reagieren kann. Auch Softwarelizenzen und die Freigaben des Serverherstellers gehören zur Planung.

Mehr Kerne allein sagen nicht, wie viele bestehende Hosts sich ersetzen lassen. Dafür braucht der Anbieter vergleichbare Lastprofile und Messwerte der vorhandenen Hosting-Hardware sowie eine festgelegte Ausfallreserve. Ohne diese Grundlage ist eine Modellauswahl möglich, eine belastbare Konsolidierungsquote aber nicht.

Kerne, Chiplets und Takt verstehen

Turin verwendet ein Chiplet-Design: Recheneinheiten und ein separates I/O-Die sind über AMD Infinity Fabric verbunden. Das I/O-Die stellt unter anderem die Verbindungen zum Arbeitsspeicher und zur Ein- und Ausgabe bereit. Für die praktische Serverplanung bedeutet das, dass nicht nur die Kerne, sondern auch die Anbindung der gemeinsam genutzten Ressourcen zählt.

Zen 5 und Zen 5c unterscheiden sich in ihrer Auslegung und Kernorganisation. Zen 5c ermöglicht innerhalb der Generation die höchste Kerndichte; daraus folgt aber keine allgemeine Leistungsrangfolge. Ein stark parallelisierter VM-Mix und eine Anwendung mit wenigen latenzkritischen Aufgaben können unterschiedliche Modelle begünstigen.

Der EPYC 9965 besitzt 192 Zen-5c-Kerne und 384 Threads, der EPYC 9755 dagegen 128 Zen-5-Kerne und 256 Threads. AMD nennt einen maximalen Boost von bis zu 3,7 GHz für den 9965 und bis zu 4,1 GHz für den 9755. Die Werte zeigen unterschiedliche Schwerpunkte, ersetzen aber keinen Vergleich unter dem eigenen Lastprofil.

Der angegebene maximale Boost ist insbesondere kein garantierter Dauertakt für alle Kerne. Welche Frequenz unter Last erreicht wird, hängt unter anderem von der Belastung und den Betriebsbedingungen ab. Für eine Hosting-Entscheidung sind deshalb Durchsatz und Antwortzeiten bei definiertem Anwendungsmix aussagekräftiger als der isolierte Spitzenwert.

Die jeweils doppelte Threadzahl entsteht durch SMT: Ein physischer Kern stellt zwei logische Threads bereit. Diese teilen sich jedoch Kernressourcen; 384 Threads sind weder 384 physische Kerne noch eine automatische Verdopplung der Rechenleistung. Ob SMT und eine Überbuchung von CPU-Ressourcen helfen, muss anhand der gleichzeitig aktiven Kundenlast geprüft werden.

Speicher und I/O begrenzen Kapazität

Viele CPU-Kerne benötigen eine passende Speicherbestückung. EPYC 9005 unterstützt laut AMD bis zu zwölf DDR5-Speicherkanäle pro CPU. Für einen VM-Host zählt nicht nur die gesamte RAM-Kapazität: Auch die Verteilung der Module und die verfügbare Speicherbandbreite beeinflussen, wie gut gleichzeitig aktive Gäste versorgt werden können.

Das Datenblatt nennt für die aufgeführten Modelle bis zu DDR5-6400 bei einem DIMM pro Kanal. Die tatsächlich nutzbare Geschwindigkeit hängt von der Bestückung und der Plattformfreigabe ab. Auch die im Datenblatt genannten bis zu 6 TB DDR5 beziehen sich auf dort angegebene Konfigurationen mit zwei DIMMs pro Kanal und sind keine Zusage für jeden Server.

Mehr RAM-Module können für die benötigte Kapazität sinnvoll sein, verändern aber die zu prüfende Konfiguration. Deshalb sollten Anbieter die gewünschte Modulgröße und Bestückung mit der Freigabeliste des Serverherstellers abgleichen, statt Kapazitäts- und Geschwindigkeitsmaxima aus dem Datenblatt unabhängig voneinander zu addieren.

Für NVMe-Laufwerke und Netzwerkkarten ist außerdem die PCIe-Anbindung entscheidend. AMD nennt bis zu 128 PCIe-5.0-Lanes für Single-Socket-Systeme und bis zu 160 für Dual-Socket-Server. Wie viele Anschlüsse ein konkretes Board tatsächlich bereitstellt, hängt vom Plattformdesign und der Verwendung der Verbindungen ab; das 2P-Maximum gilt nicht automatisch für einen 1P-Host.

Bei der Konfiguration lohnt sich deshalb ein Blick auf das Zusammenspiel: Mehr NVMe-Laufwerke können zusätzliche Anschlüsse beanspruchen, während schnelle Netzwerkkarten ebenfalls angebunden werden müssen. CXL 2.0 gehört zu den Plattformfähigkeiten, ist aber kein automatisch nutzbares Merkmal jedes Servers. Geräte-, Firmware- und Betriebssystemunterstützung müssen für das gewählte System geprüft werden.

Turin-Modelle für Hosting vergleichen

Die EPYC-9005-Familie bietet unterschiedliche Schwerpunkte: Der 9965 setzt auf maximale Kerndichte, während der 9575F eine höhere Frequenz anstrebt. Für die Auswahl zählt nicht nur die CPU, sondern die Kombination aus konkretem Modell, Sockelzahl und Anwendungslast. Die folgende Tabelle stellt vier Modelle anhand von AMD-Daten gegenüber.

Der 9965 stellt besonders viele physische Kerne für unabhängige Aufgaben bereit. Das kann bei einem stark parallelisierten VM-Mix interessant sein, sofern Speicher und I/O mithalten. Der 9755 bietet weniger Kerne, aber einen höheren maximalen Boost und mehr gesamten L3-Cache. Aus diesen Daten allein folgt keine feste Rangfolge für Hosting-Anwendungen.

Der 9575F ist eine mögliche Vergleichsoption, wenn einzelne Arbeitsschritte kurze Antwortzeiten benötigen. Sein maximaler Boost ist jedoch kein dauerhaft zugesicherter Takt für alle Kerne. Ob er gegenüber einem Modell mit mehr Kernen wirtschaftlicher ist, hängt unter anderem von gleichzeitigen Anfragen und dem Lizenzmodell ab.

Beim 9655P begrenzt das P-Suffix die Sockeleignung auf Single-Socket-Systeme. Für einen Zwei-Sockel-Server ist dieses Modell daher keine Option. Ein breiterer Plattformvergleich sollte konkrete Konfigurationen und Messungen einbeziehen; dazu liefert der Artikel zur Plattformwahl zwischen AMD EPYC und Intel Xeon weitere Orientierung.

Hosting-Workloads und Engpässe zuordnen

Eine Server-CPU muss zu den gleichzeitig laufenden Diensten passen. Im Shared Hosting entstehen viele unabhängige Anfragen, bei virtuellen Maschinen konkurrieren ganze Betriebssysteme um Ressourcen, und Datenbanken reagieren je nach Arbeitslast empfindlich auf Speicherzugriffe oder Storage-Latenz. Die folgende Übersicht übersetzt diese Unterschiede in Prüffragen für die Auslegung.

Für Shared Hosting ist die Zahl gleichzeitig aktiver Worker ebenso relevant wie die Dauer einzelner Anfragen. Eine hohe CPU-Auslastung kann bei gutem Durchsatz akzeptabel sein; sie sagt für sich genommen aber nicht, ob Kunden lange warten. Deshalb gehören Antwortzeitverteilungen und Fehlerraten bei definierten Laststufen zum Vergleich.

Bei Datenbanken ist der L3-Cache nur ein Teil des Bildes. Der 9755 besitzt insgesamt 512 MB, der 9965 insgesamt 384 MB. Diese Modellwerte beweisen keinen Datenbankvorteil: Datensatzgröße, Zugriffsmuster, Verteilung der Arbeit und RAM-Konfiguration beeinflussen, wie häufig Daten aus anderen Speicherebenen benötigt werden.

Ein verwalteter Redis-Dienst ergänzt den Anwendungsmix beispielsweise als Cache. Dafür müssen Anbieter neben CPU-Ressourcen insbesondere den verfügbaren Arbeitsspeicher und die Anforderungen des konkreten Dienstes betrachten. Der Beitrag zu Redis 8 und Upgrade-Entscheidungen für Hosting-Anbieter behandelt unter anderem Speichergrenzen und den Betrieb solcher Angebote.

Für einen fairen Modellvergleich bleiben VM-Mix, RAM-Bestückung, Storage und Laststufen möglichst vergleichbar. Unterschiede bei Antwortzeiten oder Durchsatz lassen sich sonst nicht sinnvoll der CPU-Auswahl zuordnen. Auch eine schnellere Einzelanfrage und ein höherer Gesamtdurchsatz sind getrennte Ziele, die bei der Tarifplanung unterschiedlich gewichtet werden können.

VM-Kapazität beispielhaft planen

Ein rechnerisches Beispiel macht die Größenordnungen sichtbar: Ein Host mit einem EPYC 9965 verfügt über 192 physische Kerne und 384 Threads. Werden darauf 48 VMs mit jeweils vier vCPUs eingerichtet, ergeben sich 48 × 4 = 192 zugewiesene vCPUs. Das ist eine Zuordnungsrechnung und keine Messung der erreichbaren VM-Leistung.

Eine vCPU ist dabei nicht automatisch ein exklusiv reservierter physischer Kern. Der Hypervisor plant virtuelle Prozessoren auf verfügbaren logischen Prozessoren ein; die tatsächliche Ausführung hängt davon ab, welche VMs gleichzeitig arbeiten und welche Ressourcen ihnen zugeteilt werden. Auch die 384 Threads des Prozessors entsprechen nicht 384 unabhängigen physischen Kernen.

Für die Überbuchung solltest du zunächst festhalten, welche gleichzeitige Auslastung du erwartest und welche Leistung ein Tarif zusagt. Eine höhere Zahl zugewiesener vCPUs kann bei selten zusammenfallenden Lastspitzen funktionieren, erhöht aber das Risiko von Wartezeiten, wenn viele Gäste zugleich rechnen. Prüfe diese Annahme mit dem tatsächlichen Kundenmix statt mit der Threadzahl allein.

Anschließend rechnest du den Speicherbedarf separat: Addiere den geplanten RAM der VMs und berücksichtige zusätzlich den Bedarf des Hypervisors sowie betriebliche Reserven. Die CPU-Rechnung sagt nicht, ob der Host genügend RAM bereitstellt oder die benötigte Speicherbandbreite bei gleichzeitig aktiven Gästen ausreicht.

Dasselbe gilt für Storage und Netzwerk. Viele VMs können gleichzeitig auf NVMe-Laufwerke zugreifen oder Daten übertragen; dabei sind neben dem Gesamtdurchsatz auch I/O-Latenzen und Lastspitzen relevant. Plane deshalb die Anbindung und die Leistungsfähigkeit der tatsächlich eingesetzten Laufwerke und Netzwerkkarten mit ein.

Schließlich brauchst du Reserve für Wartung und Ausfälle. Soll ein verbleibender Host nach dem Ausfall eines anderen zusätzliche VMs aufnehmen, darf die reguläre Belegung nicht bereits alle dafür benötigten Ressourcen beanspruchen. Das Beispiel mit 48 VMs legt weder eine sichere Belegungsgrenze noch eine Konsolidierungsquote fest; beides muss anhand der konkreten Umgebung geprüft werden.

Plattform und Virtualisierung vorbereiten

Beginne die Plattformplanung mit dem konkreten CPU-Modell und der Frage, ob ein oder zwei Sockel benötigt werden. Der Bedarf an Kernen, RAM und I/O muss gemeinsam auf das gewünschte Hostsystem passen. Ein P-Modell wie der EPYC 9655P ist für einen Sockel ausgelegt und kommt deshalb für eine Zwei-Sockel-Konfiguration nicht infrage.

Prüfe anschließend die Herstellerfreigabe für CPU, Mainboard und BIOS. Turin verwendet zwar den Sockel SP5; ein vorhandener SP5-Server unterstützt aber nicht allein deshalb jedes 9005-Modell. Auch Stromversorgung und Kühlsystem müssen für die ausgewählte CPU und das vorgesehene Gehäuse freigegeben sein.

Plane die RAM-Module nach Kapazität, Kanalbestückung und den Vorgaben des Serverherstellers. Dazu kommen die benötigten NVMe-Laufwerke und Netzwerkkarten: Entscheidend ist nicht nur ihre Anzahl, sondern auch, welche Steckplätze oder Laufwerksschächte im konkreten System angebunden sind. So lässt sich vor der Bestellung erkennen, ob die gewünschte Kombination auf der Plattform überhaupt möglich ist.

Für vertrauliche Kunden-VMs kann SEV-SNP den Schutz des VM-Speichers um Integritätsmechanismen ergänzen. Trusted I/O über TDISP ist ein weiterer möglicher Baustein für Gerätezugriffe. Ob daraus ein nutzbares Angebot entsteht, hängt jedoch von der Kombination aus Firmware, Hypervisor, Gastbetriebssystem und gegebenenfalls Geräten ab.

Vor einer Produktzusage solltest du außerdem klären, wie Gäste eingerichtet, attestiert und verwaltet werden und welche Einschränkungen für die angebotenen VM-Funktionen gelten. Eine CPU-Funktion allein bestätigt weder die Kompatibilität des gesamten Stacks noch schützt sie vor allen Angriffen. Dokumentiere daher die tatsächlich unterstützte Konfiguration und halte sie bei Updates nach.

Betrieb messen und Engpässe finden

Für einen Vergleich mit bestehender Hosting-Hardware brauchst du ein nachvollziehbares Lastprofil: etwa denselben VM-Mix, vergleichbare Datenmengen und definierte Anfragearten. Halte RAM-Bestückung, Storage, Netzwerk und Softwarekonfiguration fest. Nur so lässt sich später unterscheiden, ob eine Abweichung eher mit der CPU oder mit einer anderen Änderung am System zusammenhängt.

Untersuche mehrere Laststufen statt nur einen Spitzenwert. Erfasse dabei Durchsatz, Antwortzeitverteilung und Fehlerraten: Ein höherer Durchsatz ist für ein Hosting-Angebot wenig wert, wenn gleichzeitig viele Anfragen langsam werden oder fehlschlagen. Lege vorab fest, welche Antwortzeiten und Fehlerquoten für den jeweiligen Dienst akzeptabel sind.

Beobachte parallel RAM-Auslastung und Speicherverhalten sowie Latenz und Auslastung von Storage und Netzwerk. Steigen Antwortzeiten, obwohl die CPU noch Reserven zeigt, kann beispielsweise ein anderer Teil der Plattform begrenzen. Umgekehrt beweist eine hohe CPU-Auslastung allein noch nicht, dass Kunden eine schlechte Nutzererfahrung haben.

Bei auffälligen VM-Antwortzeiten prüfe die angenommene Gleichzeitigkeit und die CPU-Überbuchung. Vergleiche anschließend die tatsächliche RAM-Bestückung, Firmware- und Hypervisor-Einstellungen mit der geplanten Konfiguration. Ändere möglichst gezielt einzelne Faktoren und wiederhole dieselbe Laststufe, damit die Ursache nicht mit einer gleichzeitig geänderten Arbeitslast verwechselt wird.

Zum laufenden Betrieb gehören außerdem Sicherheitsbulletins, Firmwarepflege, Zugriffskontrollen und überprüfbare Backups. AMD veröffentlicht auch für EPYC-Prozessoren Hinweise auf Sicherheitslücken und Maßnahmen; Betreiber müssen passende Aktualisierungen des Serverherstellers einplanen. Prüfe nach Wartungen erneut, ob Schutzfunktionen und angebotene Gastkonfigurationen wie vorgesehen verfügbar sind.

Beschaffung und Wirtschaftlichkeit entscheiden

Eine Beschaffungsentscheidung beginnt mit der Frage, ob die Bestandsplattform die Anforderungen weiterhin erfüllt. Reichen Kapazität und Reserven aus, kann ihr Weiterbetrieb sinnvoll sein. Für ein Upgrade auf Turin müssen dagegen das konkrete CPU-Modell, die Firmware und die übrigen Komponenten vom Serverhersteller freigegeben sein; der gemeinsame Sockel SP5 genügt nicht als Nachweis.

Vergleiche einen 1P-Host mit einer 2P-Konfiguration anhand des gesamten Bedarfs an Kernen, RAM und Anschlüssen. Zwei Sockel sind nicht allein wegen einer hohen angestrebten VM-Zahl erforderlich. Umgekehrt kann eine Ein-Sockel-Plattform ausscheiden, wenn die benötigte Kombination aus Speicher und I/O im gewählten Server nicht unterzubringen ist.

Bei vielen unabhängigen, gleichzeitig aktiven Aufgaben kann Kerndichte ein wichtiges Auswahlkriterium sein. Für latenzempfindliche Anwendungen lohnt es sich dagegen, auch Modelle mit höherem Takt im eigenen Anwendungsmix zu untersuchen. Kalkuliere daneben das konkrete Lizenzmodell: Kosten pro Kern, Sockel oder VM können die wirtschaftliche Reihenfolge der Plattformen verändern.

Die TDP ist keine Messung des Stromverbrauchs eines vollständigen Servers. AMD nennt für den EPYC 9755 und den 9965 jeweils 500 Watt TDP; daraus folgen weder die Leistungsaufnahme unter deiner Last noch die jährlichen Energiekosten. RAM, Laufwerke, Netzwerk und Kühlung gehören zur Systembetrachtung dazu.

Miss für einen Energie- und Kostenvergleich das Gesamtsystem bei repräsentativen Laststufen und beziehe die benötigten Reserven ein. Gegenüberstellen solltest du Anschaffung, Softwarelizenzen und Betrieb über den geplanten Nutzungszeitraum. Ohne vergleichbare Bestandsdaten lässt sich weder eine bestimmte Einsparung noch eine belastbare Konsolidierungsquote versprechen.