AMD EPYC vs. Intel Xeon: Was Hosting-Käufer wirklich wissen müssen

Du suchst dir CPUs nicht aus, um damit anzugeben, sondern um deine Kunden zufrieden zu halten, den Umsatz stabil zu halten und das Wachstum vorhersehbar zu machen. Die Hardware in deinem Stack entscheidet, wie viele Nutzer du gleichzeitig bedienen kannst, wie schnell Seiten geladen werden und ob der Checkout schnell oder langsam ist. Dieser Leitfaden macht die Kompromisse klar, damit du die richtige Plattform für die Aufgaben finden kannst, die du tatsächlich ausführst.

Bevor wir uns mit Architekturen und Benchmarks beschäftigen, sollten wir mal klären, was im Hosting-Bereich eigentlich „gut“ ist. Dir geht's um niedrige Tail-Latenz, sichere Isolierung zwischen Mandanten und reibungslose Skalierung bei Nachfragespitzen. Mit diesen Zielen im Hinterkopf wird die Wahl des Prozessors viel einfacher.

Wenn du von den Zielen zu den Entscheidungen kommst, wirst du sehen, dass sowohl AMD EPYC als auch Intel Xeon super Ergebnisse liefern können, wenn sie mit dem richtigen Speicher, Speicherplatz und Stromversorgungskonzept kombiniert werden. Der Unterschied liegt darin, wie einfach jede Plattform deine Ziele in Sachen Dichte, Reaktionsfähigkeit und Kosten erreicht. Behalte das im Blick, während wir uns die einzelnen Bereiche ansehen, die die Leistung in der Praxis beeinflussen.

Du weißt, welche Ergebnisse du willst: Geschwindigkeit, Verfügbarkeit und Raum für Wachstum, ohne alles neu verkabeln zu müssen. Um das zu erreichen, solltest du die Wahl der CPU als geschäftlichen Hebel betrachten und nicht nur als ein Kriterium auf einem Datenblatt. Vor diesem Hintergrund erklärt der nächste Abschnitt genau, warum die Auswahl der CPU für den täglichen Hosting-Betrieb so wichtig ist.

Warum die Wahl der CPU beim Hosting wichtig ist

Ausfälle von Rechenzentren haben echt große finanzielle Folgen. Laut der Global Data Center Survey 2024 vom Uptime Institute sagten 54 % der Befragten, dass ihr letzter großer Ausfall mehr als 100.000 Dollar gekostet hat, und jeder Fünfte meinte, dass die Kosten über 1 Million Dollar lagen. Deshalb ist die Wahl der CPU echt wichtig für die Verfügbarkeit und Skalierbarkeit.

CPUs sind das Herzstück deines Kapazitätsmodells: Sie bestimmen die Parallelität, beeinflussen den Durchsatz der Datenbank und legen fest, wie viele Container oder VMs du sicher auf jedem Knoten planen kannst. Wenn die Kerne überlastet sind oder die Speicherbandbreite knapp ist, kann kein Caching die Verlangsamung bei Traffic-Spitzen verhindern. Wenn die Kerne richtig dimensioniert und gut versorgt sind, bekommst du auch unter Last eine konsistente p95- und p99-Latenz.

Jede Entscheidung im weiteren Verlauf profitiert von einer CPU-Plattform, die zur Aufgabe passt. Deshalb schauen wir uns EPYC und Xeon nicht als abstrakte Chips an, sondern als Basis für deine Web-, E-Commerce-, SaaS- und Unternehmens-Bot-Workloads. Schauen wir uns in diesem Zusammenhang mal an, wie sich die beiden Architekturen tatsächlich verhalten.

Du hast gesehen, warum die Wahl des Prozessors weit über die reine Gigahertz-Leistung hinausgeht. Als Nächstes geht's darum zu verstehen, was jede Plattform wirklich zu bieten hat. Nachdem wir uns mit dem „Warum“ beschäftigt haben, können wir uns jetzt auf das „Wie“ konzentrieren, indem wir die Architektur und die Leistungsmerkmale anschauen, die in deinen Metriken auftauchen.

Architektur und Leistung: Wo jede CPU glänzt

AMD EPYC: Multi-Core-Dichte und I/O-Headroom

EPYC zeichnet sich durch eine hohe Kernanzahl pro Sockel, breite Speicherkanäle und viele PCIe-Lanes aus. In der Praxis heißt das, dass du mehr Gäste pro Knoten hosten, PHP-Worker auch bei Spitzenlast reaktionsschnell halten und großzügige NVMe anschließen kannst, ohne den Bus zu überlasten. Die Thread-Skalierung der Plattform bleibt auch bei steigender Parallelität stabil, was sowohl den Durchsatz als auch die Tail-Latenz schützt.

Für Agenturen, die viele Kundenwebsites pro Server packen, bedeutet diese Dichte eine bessere Knotenauslastung und ruhigere p95-Zeiten beim Pushen von Inhalten. Bei Analysejobs, Hintergrundwarteschlangen und ETL sind parallele Aufgaben schneller fertig, sodass der Vordergrundverkehr flüssig bleibt. Wenn du Speicherleistung brauchst, die zur CPU-Kapazität passt, bieten dir die zusätzlichen PCIe-Lanes saubere Pfade für NVMe schnelles Networking.

Der rote Faden ist einfach: Mit EPYC bleibt die Leistung auch dann stabil, wenn du mehr Aufgaben hinzufügst, nicht nur, wenn der Knoten leer ist. Diese Stabilität ist genau das, was Multi-Tenant-Plattformen brauchen. Schauen wir uns diese Stärken mal im Vergleich zum Per-Core-Profil von Xeon an.

Bei EPYC geht's darum, mit steigender Parallelität gut mitzuwachsen. Trotzdem gibt's Anwendungen, bei denen es weniger auf viele Threads als auf schnelle Single-Thread-Reaktionen ankommt. Um diesen Bereich abzudecken, sollten wir uns anschauen, was Intel Xeon gut kann und warum es immer noch in vielen Unternehmens-Stacks zu finden ist.

InMotion Hosting hat InMotion Hosting seinen Extreme Dedicated Server-Tarif vorgestellt, der mit dem AMD EPYC 4545P-Prozessor mit 16 Kernen und 32 Threads ausgestattet ist. Zusammen mit 192 GB DDR5 ECC-RAM und zwei 3,84 TB NVMe bietet diese Konfiguration die Kerndichte und Speicherbandbreite, für die EPYC bekannt ist. Der Plan beinhaltet auch eine burstfähige Bandbreite von 10 Gbit/s, was ihn super für Streaming-Workloads, hohe API-Volumen und große CRM-Bereitstellungen macht, bei denen der Datenverkehr ohne Vorwarnung stark ansteigen kann.

Intel Xeon: Geschwindigkeit pro Kern und Vertrautheit mit dem Ökosystem

Der Vorteil von Xeon ist die starke Leistung pro Kern und ein umfangreiches Ökosystem aus validierten Treibern, Verwaltungstools und zertifizierten Integrationen. Wenn dein Datenverkehr eher transaktionsorientiert ist, helfen schnelle Kerne dabei, p99 niedrig zu halten. Und wenn du dich auf kommerzielle Software mit strengen Zertifizierungspfaden verlässt, bedeutet Xeon oft weniger Überraschungen.

Diese Reife verkürzt die Einrichtungszeit für Teams mit alten Xeon-Playbooks und herstellerspezifischen Tools. Außerdem kann sie Audits vereinfachen, wenn du in regulierten Branchen tätig bist oder spezielle HBAs, NICs oder RAID-Controller einsetzt. Das Ergebnis ist eine schnellere Zeit bis zum Erreichen eines stabilen Zustands für Stacks, bei denen die Geschwindigkeit pro Kern und die Herstellerzusicherungen im Vordergrund stehen.

Keiner der beiden Ansätze ist abstrakt gesehen „besser“; jeder ist für bestimmte Muster besser geeignet. Die richtige Wahl hängt davon ab, ob dein Engpass bei Threads, Speicherbandbreite oder der Latenz des Anforderungspfads liegt. Um das noch deutlicher zu machen, werden wir diese Eigenschaften in gängige Hosting-Muster übersetzen, die du wahrscheinlich verwendest.

Für Aufgaben, die eine maximale Geschwindigkeit pro Kern oder eine hohe Multi-Core-Dichte brauchen, bieten dir dedizierte Server mit AMD EPYC oder Intel Xeon die vollen Vorteile der Architektur.

Architektur ist nur dann nützlich, wenn sie die Arbeitslasten verändert. Du hast jetzt gesehen, wo EPYC eher skaliert und wo Xeon eher am schnellsten reagiert. Als Nächstes schauen wir uns das Threading genauer an, weil diese Funktionen bestimmen, wie sich die Knoten verhalten, wenn alle gleichzeitig auf dich zugreifen.

SMT vs. HT: Effizienz beim Gewindeschneiden, die du spüren kannst

Simultaneous Multi-Threading (SMT bei AMD) und Hyper-Threading (HT bei Intel) machen es möglich, dass sich zwei Threads einen physischen Kern teilen. Wenn Threads sonst wegen Speicher- oder E/A-Problemen hängen bleiben würden, kann der andere Thread die Pipeline weiterlaufen lassen. Wenn das gut abgestimmt ist, führt das zu einem höheren Durchsatz pro Watt und besserem Verhalten bei Bursts.

Das SMT von EPYC nutzt oft die Speicherbandbreite und die Anzahl der Lanes der Plattform, damit Threads auch bei steigender Parallelität weiter mit Daten versorgt werden. Das HT von Xeon ist super für Web- und API-Datenverkehr, wo die Geschwindigkeit pro Kern schon hoch ist, und glättet Spitzen, ohne dass du deine App neu partitionieren musst. In beiden Fällen entscheidet die Threading-Effizienz, wie weit du die vCPU-Zuweisung sicher erhöhen kannst, ohne die Nachbarn zu beeinträchtigen.

Beim Hosting heißt das: VPS-Dichte, stetiges p95 zu Spitzenzeiten und klarere Kostenkurven. Das ist auch wichtig für Echtzeitsysteme wie Discord-Bots in Unternehmen, wo Tausende von Ereignissen gleichzeitig passieren können. Nachdem wir uns um das Threading gekümmert haben, ist der nächste Punkt, den wir checken müssen, wie schnell die Daten die Kerne erreichen können.

Threads helfen nur, wenn Speicher und Speicherplatz mithalten können. Wenn Kanäle verstopft sind oder PCIe ausgelastet ist, bringen zusätzliche Threads deine Metriken nicht weiter. Deshalb geht es im nächsten Abschnitt um Speicherbandbreite und E/A, zwei Bereiche, die leise darüber entscheiden, wie schnell dein Stack sein kann.

Speicher, E/A und Speicherplatz: Die stillen Helden

Die Speicherbandbreite ist echt wichtig für moderne Workloads. EPYC-Plattformen bieten normalerweise mehr Speicherkanäle pro Sockel, was für Datenbanken, PHP-Worker und Analyseaufgaben, die viele Daten bewegen, super ist. Schnellere DDR-Geschwindigkeiten machen diesen Vorteil noch größer, wenn du eher speicher- als rechengebunden bist.

PCIe-Lanes bestimmen, wie viele NVMe und Hochgeschwindigkeits-NICs du ohne Konflikte betreiben kannst. Mit mehr Lanes kannst du Speicher-, Replikations- und Backup-Pfade trennen, sodass die Warteschlangentiefe während Schreibspitzen niedrig bleibt. So bleibt deine Datenbank reaktionsschnell und deine Caches schnell, auch wenn Batch-Jobs ausgelastet sind.

Wenn CPU, Speicher und E/A gut aufeinander abgestimmt sind, läuft das System für deine Nutzer wie von selbst. Wenn einer dieser Bereiche hinterherhinkt, warten die anderen, und deine p95-Latenzzeit zeigt das ganz klar. Mit Blick auf die Leistungsoptimierungen sollten wir uns mit einer weiteren wichtigen Anforderung für Multi-Tenant-Plattformen beschäftigen: Sicherheit und Isolierung.

Schnelligkeit ist wichtig, aber Sicherheit ist unverzichtbar. Wenn viele Kunden einen Knoten gemeinsam nutzen, braucht man Schutzmaßnahmen auf Hardwareebene. Im nächsten Abschnitt wird erklärt, wie EPYC und Xeon Isolierung und Verschlüsselung handhaben, damit du die Funktionen an dein Risikomodell anpassen kannst.

Sicherheit und Isolierung der Arbeitslast

AMD EPYC hat Secure Encrypted Virtualization (SEV und SEV-SNP), um den Gastspeicher zu verschlüsseln und VMs auf der Hardwareebene zu trennen. Laut der offiziellen Dokumentation von AMD sorgt SEV-SNP für einen starken Schutz der Speicherintegrität, um böswillige Hypervisor-basierte Angriffe wie Datenwiedergabe und Speicher-Remapping zu verhindern. In der Praxis eignet sich das super für Agenturen und SaaS-Plattformen, die viele Mandanten pro Knoten betreiben und eine umfassende Verteidigung wollen, ohne Apps neu schreiben zu müssen. Es ist auch eine praktische Möglichkeit, die Messlatte für mandantenübergreifende Risiken höher zu legen.

Intel Xeon hat Intel SGX für sichere Enklaven und Total Memory Encryption (TME) für die Verschlüsselung des gesamten Speichers. Laut Intels Newsroom hilft TME dabei, sicherzustellen, dass der ganze Speicher, auf den die Intel CPU zugreift, verschlüsselt ist, einschließlich der Zugangsdaten von Kunden, Verschlüsselungsschlüsseln und anderen sensiblen Infos auf dem externen Speicherbus. SGX ist nützlich, um bestimmte Geheimnisse oder sensible Routinen zu schützen, vor allem im Finanz- oder Gesundheitswesen, wo Enklavenmuster schon Teil der Architektur sind.

Beide Ansätze machen deine Sicherheit besser; welche Option die richtige ist, hängt davon ab, wie deine Workloads aufgebaut sind und geprüft werden. Wenn dein Hauptrisiko zwischen Mandanten liegt, passt die Isolierung auf VM-Ebene von EPYC gut zu echtem Hosting. Wenn du Schutz im Enclave-Stil und herstellerspezifische Zertifizierungen brauchst, ist Xeon die richtige Wahl. Nachdem wir uns um die Sicherheit gekümmert haben, schauen wir uns mal an, wie sich Leistung und Schutz auf die Verfügbarkeit auswirken.

Sicherheit verringert Risiken, aber Verfügbarkeit schützt den Umsatz. Im Bereich Stromversorgung kommen diese beiden Aspekte in der Praxis zusammen. Im nächsten Abschnitt wird gezeigt, wie redundante, effiziente Netzteile Ihr Ziel von 99,99 % Verfügbarkeit unterstützen und gleichzeitig die Betriebskosten senken.

Leistung, Redundanz und Verfügbarkeit: Der PSU-Link, den du nicht ignorieren solltest

Deine CPU-Plattform hilft dir nicht weiter, wenn ein einziger Stromausfall den Knoten lahmlegt. In Serverumgebungen sind redundante, im laufenden Betrieb austauschbare Netzteile (idealerweise 80 PLUS Platinum oder Titanium) der Standard für einen unterbrechungsfreien Betrieb. Mit Dual- oder N+1-Designs kannst du eine ausgefallene Einheit ohne Ausfallzeiten ersetzen und die Last verteilen, um die Lebensdauer zu verlängern.

Tests von ServeTheHome mit HPE ProLiant 800-W-Netzteilen zeigen, dass Geräte mit Platin-Zertifizierung bei 230 V und 50 % Last einen Wirkungsgrad von 94 % erreichen, während Geräte mit Titan-Zertifizierung einen Wirkungsgrad von 96 % schaffen. Wenn man zwei 800-W-Netzteile mit einer Gesamtlast von 400 W betreibt, bleiben beide Geräte in ihrem optimalen Wirkungsgradbereich.

Effizienz ist wichtig, weil sie sich auf die ganze Flotte auswirkt. Effizientere Netzteile verschwenden weniger Energie in Form von Wärme, was die Strom- und Kühlungskosten senkt. Selbst kleine Einsparungen pro Server summieren sich bei großem Umfang auf Tausende pro Jahr. Versuche, Netzteile mit 50 bis 80 % ihrer Kapazität und Größe zu betreiben, mit 20 bis 30 % Spielraum, damit Spitzenlasten dich nicht in ineffiziente Bereiche bringen.

Hier kann die Leistung pro Watt von EPYC die Anzahl der Knoten für ein bestimmtes SLA senken, und hier profitieren Xeon-Systeme immer noch von derselben Energieeffizienz. So oder so, die Energieplanung ist ein wichtiger Teil, um eine echte 99,99 %-Erfahrung zu bieten. Wenn das System zuverlässig ist, geht's als Nächstes darum, wie man die Kapazität reibungslos erweitern kann, wenn der Bedarf steigt.

Stabilität ist das A und O, Skalierbarkeit ist das, was den Unterschied macht. Wenn der Datenverkehr plötzlich steigt, willst du die Ressource hinzufügen, die den Engpass behebt, und nicht einfach irgendwelche Hardware. Im nächsten Abschnitt wird Hyperscale einfach erklärt, damit du gezielt skalieren kannst.

Hyperscale: Wie du die Nachfrage schaffst, ohne dass was kaputt geht

Hyperscale ist die Fähigkeit deiner Plattform, die richtigen Ressourcen zum richtigen Zeitpunkt ohne Probleme hinzuzufügen. Wenn die CPU ausgelastet ist, fügst du Kerne oder Knoten hinzu; wenn I/O das Problem ist, fügst du NVMe Lanes hinzu; wenn der Speicher der limitierende Faktor ist, fügst du Kanäle oder schnelleren DDR hinzu. Skalierung funktioniert nur, wenn du den tatsächlichen Engpass behebst.

Die Dichte und die Anzahl der Lanes von EPYC machen das horizontale Wachstum in VM- und Container-Clustern einfach. Die Tiefe des Xeon-Ökosystems ist super, wenn dein Hyperscale-Plan auf zertifizierten Anbieter-Tools und langjährigen Integrationen basiert. Beide können eine tolle Basis für die automatische Skalierung sein, wenn du die Ressourcen an die Nachfragesignale anpasst.

Deine Leser müssen keine Kapazitätsplaner werden, um von dieser Idee zu profitieren. Sie müssen nur wissen, dass die Skalierung am besten funktioniert, wenn sie anhand der Latenz p95/p99, der Warteschlangentiefe und der Auslastung bestimmter Subsysteme gemessen wird. Nachdem wir das Skalierungsmodell festgelegt haben, wenden wir alles auf reale Hosting-Szenarien an.

Diese Theorie ist nur dann nützlich, wenn sie sich auf deine tägliche Arbeit anwenden lässt. Die folgenden Anwendungsfälle zeigen, wie die Wahl der CPU die Dichte, Latenz und das Risiko in gängigen Hosting-Konfigurationen beeinflusst. Nutze sie als Vorlage, wenn du deinen nächsten Knoten spezifizierst.

Praktische Hosting-Szenarien

1. Agenturen, die Hunderte von Kundenwebsites hosten (EPYC-orientiert)

Warum EPYC passt: Viele Kerne und eine breite Speicherbandbreite sorgen für eine gleichbleibende TTFB, wenn du Websites pro Knoten hinzufügst. Viele PCIe-Lanes machen NVMe und schnelle NICs einfach, was das Lesen von Datenbanken schnell hält, wenn Redaktionsteams Inhalte veröffentlichen. Die SMT-Effizienz hilft dabei, plötzlichen Datenverkehr über viele kleine Mandanten zu verteilen.

Was du tun solltest: Passe die Anzahl der PHP-Worker an die physischen Kerne und SMT-Threads an, setz Limits pro Mandant, um Nachbarn zu schützen, und speicher Logs/Backups auf separaten Speicherpfaden. Füge Lesereplikate für beliebte Inhaltstypen hinzu und behalt während Marketingevents die Warteschlangentiefe und die p99-Latenz im Auge. Halte 20–30 % Leistungsreserve, damit du nicht in ineffiziente PSU-Bereiche gerätst.

Erwartetes Ergebnis: Mehr Kunden pro Knoten mit stabilen p95-Zeiten und vorhersehbaren Skalierungsentscheidungen. Diese Kombination verbessert die Marge, ohne die Benutzererfahrung zu beeinträchtigen.

Agenturen kümmern sich um die Dichte, aber Geschäfte kümmern sich um die Geschwindigkeit an der Kasse. Transaktionsschritte belasten andere Teile des Stacks als Blogbeiträge und CMS-Updates. Hier kann das Per-Core-Profil von Xeon helfen.

Der Extreme-Tarif von InMotion passt super zu diesem Anwendungsfall. Der AMD EPYC 4545P hat 32 Threads für die gleichzeitige Verarbeitung von Verbindungen, während DDR5-ECC-RAM die Speicherbandbreite liefert, die für Analyse- und Caching-Ebenen nötig ist. Die burstfähige Bandbreite von 10 Gbit/s fängt Traffic-Spitzen ab, ohne dass es zu Drosselungen kommt, und 32 dedizierte IPs unterstützen Multi-Tenant-Architekturen, die eine IP-Isolation brauchen.

2. E-Commerce mit spitzen Checkouts (oft Xeon-lastig)

Warum Xeon passt: Die hohe Geschwindigkeit pro Kern ist super für synchrone, transaktionsintensive Abläufe wie Warenkorb-Updates, Zahlungen und Betrugsüberprüfungen. Mit dem richtigen Speicherlayout kannst du die Schreiblatenz niedrig genug halten, um Warteschlangen zu vermeiden. Das Unternehmens-Ökosystem ist auch hilfreich, wenn du auf vom Hersteller zertifizierte Module angewiesen bist.

Was du tun solltest: Richte große Seiten-Caches ein, teile viel genutzte Tabellen auf, wenn es sinnvoll ist, und leg NVMe auf dedizierte PCIe-Lanes. Nutze Ratenbegrenzung und Warteschlangen, um p99 während Werbeaktionen zu schützen, und instrumentiere die langsamsten Endpunkte. Halte TLS und Bildbearbeitung möglichst vom Hot Path fern.

Was wir uns davon versprechen: Schnellere Latenzzeiten bei den Transaktionsschritten, die für die Kunden am wichtigsten sind, vor allem bei Spitzenauslastungen. Das Ergebnis sind weniger abgebrochene Transaktionen und stabilere Einnahmen.

Manche Workloads haben viele Nutzer, laufen im Hintergrund und haben manchmal Spitzen. Das ist typisch für SaaS-Plattformen, wo Isolation und Skalierbarkeit wichtig sind. Hier passt die Thread-Skalierung von EPYC super zur Isolation auf Hardware-Ebene.

3. SaaS-Plattform für mehrere Mandanten (EPYC-orientiert)

Warum EPYC passt: SEV/SEV-SNP passt super zur Multi-Tenant-Isolation auf VM-Ebene, und Thread-Skalierung macht Spitzen in der Parallelität flüssiger. Die Speicherbandbreite hilft dabei, Analyse- und Berichtsaufgaben zu erledigen, ohne dass die Request-Worker zu kurz kommen. Dank der vielen PCIe-Schnittstellen lassen sich NVMe schnelle Netzwerke einfach und sauber anschließen.

Was du tun solltest: Redis für Hot Data hinzufügen, Hintergrundwarteschlangen auf NVMe legen und CPU-Obergrenzen pro Mandant festlegen. Nutze Lese-Replikate, um BI-Abfragen auszulagern, und behalte Noisy-Neighbor-Muster mit klaren Regeln zur Behebung im Auge. Halte Failover-Pfade und redundante Netzteile bereit, um 99,99 %-Ziele zu erreichen.

Erwartetes Ergebnis: Vorhersehbare Leistung für Mieter während deines Wachstums, mit geringerem Risiko von Auswirkungen auf andere Mieter. Du bekommst Skalierbarkeit und Isolation, ohne ständig Probleme lösen zu müssen.

Community-Plattformen funktionieren ähnlich wie SaaS, sind aber größeren Schwankungen ausgesetzt. Ein gutes Beispiel dafür sind Enterprise-Discord-Bots: Tausende von Nutzern können innerhalb von Sekunden Aktionen auslösen. Das ist ein perfekter Ort, um eine hohe Thread-Anzahl mit schnellem Speicher und robusten Netzwerken zu kombinieren.

4. Enterprise Discord Bot Cluster (EPYC-Kern; ausgewählte Xeon-Prozessoren, wo es auf kurze Latenzzeiten ankommt)

Warum EPYC passt: Bots, die 5.000 bis 10.000+ aktive Nutzer bedienen, profitieren von vielen Kernen und Threads; SMT hilft bei gleichzeitigen Ereignissen. NVMe schnelle Warteschlangen und Job-Protokolle, und zusätzliche PCIe-Lanes unterstützen schnelle NICs für niedrige RTT. Wenn ein einzelner Microservice absolute Geschwindigkeit pro Kern braucht, kann ein kleines Xeon-Segment das übernehmen.

Was du tun solltest: Lass mehrere Instanzen hinter einem Load Balancer laufen, nutze PostgreSQL Lesereplikaten und füge Redis-Caching für Hotkeys hinzu. Setze das Ganze regionenübergreifend ein, um Ziele unter 50 ms zu erreichen, und nutze eine auf Ereignisraten abgestimmte automatische Skalierung. Ergänze das Ganze mit redundanten Netzteilen und DR-Übungen, damit Failovers zur Routine werden und nicht selten vorkommen.

Erwartetes Ergebnis: Reibungslose Reaktionen bei Community-Spitzen und vorhersehbare Kosten, wenn die Zielgruppe wächst. Deine Marke wirkt zuverlässig, weil die Infrastruktur so aufgebaut ist.

Nachdem du jetzt gesehen hast, wie die CPUs auf die tatsächliche Arbeit abgestimmt sind, stellt sich die nächste Frage: Was passiert, wenn KI in immer mehr Bereiche deines Stacks vordringt? Training und Inferenz ziehen in unterschiedliche Richtungen. Im nächsten Abschnitt wird erläutert, wer wo am besten geeignet ist und warum.

KI und neue Arbeitslasten

Training und Batch-Analysen brauchen Parallelität und Speicherbandbreite. Die Core-Anzahl und Kanäle von EPYC sind hier super und erledigen schwere Jobs schneller und mit weniger Knoten für die gleiche Arbeit. Das spart Strom und verkürzt den Zeitraum, in dem Hintergrundjobs mit dem Benutzerverkehr konkurrieren könnten.

Die Inferenz mit geringer Latenz ist etwas komplizierter. Wenn das Modell nicht so groß ist und synchron im Anfragepfad läuft, kann die Geschwindigkeit pro Kern von Xeon dir helfen, knappe p99-Ziele zu erreichen. Wenn die Arbeitslast außerhalb des Hot Paths liegt oder gebündelt ist, kann die Thread-Skalierung von EPYC die Hardware während Bursts besser nutzen.

Die meisten Teams mischen verschiedene Ansätze: EPYC für die schweren Aufgaben und Xeon, wenn es um die Integration von Anbietern oder Single-Thread-Pfade geht. Wichtig ist, dass man sich an realistischen Eingaben orientiert, statt sich auf ein bestimmtes Muster festzulegen. Mit der KI-Dimension ist es an der Zeit, über die Planung für morgen zu reden, ohne heute zu viel zu kaufen.

Zukunftssicherheit heißt nicht, die Zukunft vorhersagen zu können, sondern lieber später bereuen zu müssen. Du willst Optionen haben, ohne dich auf große Umstellungen festlegen zu müssen. Im nächsten Abschnitt wird gezeigt, wie jede Plattform Upgrades, Hersteller-Tools und langfristige Stabilität unterstützt.

Skalierbarkeit und Zukunftssicherheit

Vorteile von EPYC

Eine hohe Kerndichte bedeutet weniger physische Knoten, um ein Parallelitätsziel zu erreichen, und zusätzliche PCIe-Lanes machen NVMe einfacher, ohne dass man alles umstellen muss. Konsistente Sockelstrategien über mehrere Generationen hinweg reduzieren die Anzahl der störenden Neuaufbauten, mit denen man während der Lebensdauer einer Plattform konfrontiert ist. Diese Beständigkeit passt gut zu Hyperscale-Strategien, die bei Bedarf präzise Ressourcen hinzufügen.

Vorteile von Xeon

Ein starkes Anbieter-Netzwerk, Zertifizierungen und vertraute Tools können die Projektlaufzeiten verkürzen, vor allem in geprüften Umgebungen. Wenn du auf bestimmte HBAs, RAID-Firmware oder kommerzielle Software setzt, die zuerst auf Xeon getestet wurde, musst du weniger Zeit damit verbringen, die Konformität nachzuweisen oder seltsame Treiberprobleme zu lösen. Diese Vorhersehbarkeit kann mehr wert sein als ein paar Prozentpunkte bei der Leistung oder dem Durchsatz.

Beide Wege können richtig sein. Die beste Wahl hängt von deinem Plan, der Software, die du nutzt, und den Audits, denen du dich stellen musst, ab. Wenn die Richtung feststeht, geht's nur noch um die Kosten. Die solltest du anhand des Stromverbrauchs, der Lizenzen und der Knoten, die du wirklich brauchst, berechnen.

Budgets klären jede Diskussion. Wenn man Energie, Anzahl der Knoten und Bereitstellungszeit zusammenrechnet, ergibt sich die richtige Antwort oft von selbst. Im nächsten Abschnitt findest du eine einfache Methode, um die Gesamtkosten zu vergleichen und Überraschungen zu vermeiden.

Kosten, Gesamtbetriebskosten und Energie

Effizienteres Threading und eine höhere Kerndichte reduzieren die Anzahl der Knoten, die du brauchst, um deine SLA zu erfüllen. Weniger Knoten bedeuten weniger Stromverbrauch, weniger zu patchende Betriebssysteminstanzen und geringere Lizenzkosten, wenn die Gebühren pro Sockel berechnet werden. Kombiniere das mit 80 PLUS Platinum/Titanium-Netzteilen und 20–30 % Spielraum, um unter typischer Last in die höchste Effizienzklasse zu kommen.

EPYC bietet oft eine bessere Leistung pro Watt für Multithread- und gemischte Workloads, was deine Ausgaben über ein Jahr hinweg deutlich senken kann. Xeon kann die Amortisationszeit verkürzen, wenn die Zertifizierung durch den Anbieter die Bereitstellung beschleunigt und den Integrationsaufwand reduziert. Der richtige Vergleich ist „Kosten pro Einheit des Geschäftsergebnisses“ und nicht einfach „CPU-Preis“.

Um es einfach zu halten, rechne den Durchsatz aus, den du bei deinem Zielwert p95 brauchst, schätze die Knoten für jede Plattform anhand gemessener Tests und multipliziere das Ergebnis mit der Leistung und den Lizenzkosten. Du siehst dann sofort die Steigung jeder Option. Nachdem wir uns die Kosten angesehen haben, lassen Sie uns mit einem einfachen Workflow zur Größenbestimmung abschließen, den du vor dem Kauf durchführen kannst.

Du kennst die Grundsätze, jetzt brauchst du einen schnellen Prozess, um sie anzuwenden. Eine kurze Checkliste hilft dir, zu wenig oder zu viel zu kaufen. Im nächsten Abschnitt findest du eine wiederholbare Methode zur Dimensionierung und Validierung mit kleinen Tests.

Schritt für Schritt: Pass deine Arbeitslast an die richtige CPU an

Die Entscheidung zwischen AMD EPYC und Intel Xeon muss nicht kompliziert sein. Das Wichtigste ist, echte Daten aus deinen Workloads zu sammeln und deine Entscheidung von den Zahlen leiten zu lassen. Dieser fünfstufige Prozess hilft dir, unnötige Hardware-Anschaffungen zu vermeiden oder Server mit zu geringen Spezifikationen zu kaufen, die unter Last Probleme haben werden.

Schritt 1: Erfasse deine aktuelle Auslastung

Bevor du irgendwelche Hardware checkst, musst du wissen, was deine Arbeitslast wirklich braucht. Raten führt zu Servern, die entweder überdimensioniert sind (was Geld verschwendet) oder zu klein (was die Nutzer nervt).

Fang damit an, deine Spitzenanfragen pro Sekunde oder Ereignisse pro Sekunde während deiner geschäftigsten Zeiten zu erfassen. Schau dir den Traffic der letzten 30 bis 90 Tage an und finde die höchste anhaltende Auslastung heraus, nicht nur die momentanen Spitzen. Wenn du eine E-Commerce-Website betreibst, könnte deine Basislinie von einem Flash-Sale oder einem Feiertagswochenende kommen. Bei einer SaaS-Plattform könnte es die letzte Stunde des Arbeitstages sein, wenn die Nutzer sich beeilen, ihre Aufgaben zu erledigen.

Als Nächstes legst du deine Latenzziele fest. Die meisten Teams verfolgen die Latenzwerte p95 und p99, die die Antwortzeit der langsamsten 5 % bzw. 1 % der Anfragen darstellen. Ein p95-Wert von 200 ms bedeutet, dass 95 % deiner Nutzer Antworten schneller als dieser Schwellenwert erhalten. Wenn dein aktueller p95-Wert 180 ms beträgt und dein Ziel 200 ms ist, hast du einen Puffer von 20 ms. Wenn dein p95-Wert bereits bei 250 ms liegt, brauchst du schnellere Hardware oder Änderungen an der Architektur.

Identifiziere schließlich deinen Engpass. Setze deine Überwachungstools während der Spitzenauslastung ein und finde heraus, ob du CPU-, Speicher- oder E/A-gebunden bist. Bei einer CPU-gebundenen Arbeitslast werden die Prozessoren zu fast 100 % ausgelastet sein, während Speicher und Festplatte noch Kapazitäten frei haben. Bei einer speichergebundenen Arbeitslast wird eine hohe Speicherauslastung oder Swap-Aktivität zu beobachten sein, selbst wenn die CPU-Auslastung moderat ist. Bei einer I/O-gebundenen Auslastung werden Festplatten- oder Netzwerkwarteschlangen angezeigt, während CPU-Zyklen ungenutzt bleiben. Wenn du deinen Engpass kennst, weißt du, welche Hardware-Spezifikationen für deine Situation am wichtigsten sind.

Schritt 2: Wähl 'ne Maßeinheit aus

Mit einer Größeneinheit kannst du Hardware-Konfigurationen einfach vergleichen. Ohne sie musst du raten. Mit ihr werden A/B-Tests für Hardware zum Kinderspiel.

Bei Web-Apps solltest du die Anfragen pro Sekunde (RPS) messen, bei denen die Latenz bei p95 unter oder gleich deinem Zielwert bleibt. Wenn deine Checkout-Seite für 95 % der Nutzer in weniger als 200 ms reagieren muss, ist deine Maßeinheit „RPS bei p95 ? 200 ms“. Test jede Plattform und schau, wie viele Anfragen sie verarbeiten kann, bevor die Latenz diesen Schwellenwert überschreitet.

Bei Datenjobs solltest du die pro Sekunde verarbeiteten Zeilen messen und dabei die CPU-Auslastung unter einer sicheren Obergrenze halten. Eine Größeneinheit wie „10.000 Zeilen/Sek. bei ? 70 % CPU“ zeigt dir, dass die Plattform deinen ETL-Batch mit ausreichender Reserve bewältigen kann. Wenn du die CPU-Auslastung auf 95 % maximierst, um diesen Durchsatz zu erreichen, hast du keine Kapazität mehr übrig, wenn der Job parallel zum Produktionsverkehr läuft.

Bei Bots solltest du die Ereignisse pro Sekunde messen und dabei die API-Ratenbeschränkungen einhalten. Discord und Slack haben strenge Ratenbeschränkungen, sodass der Rohdurchsatz weniger wichtig ist als der nachhaltige Durchsatz. Deine Größeneinheit könnte „1.200 Ereignisse/Sekunde ohne Auslösen einer Ratenbeschränkungsrücknahme“ sein. Eine Plattform, die schneller verarbeitet, aber ständig Ratenbeschränkungen auslöst, wird von den Benutzern als langsamer empfunden als eine, die knapp unter dem Schwellenwert bleibt.

Schritt 3: Kleine Tests auf beiden Plattformen

Mach ein paar kurze, kontrollierte Tests mit EPYC- und Xeon-Konfigurationen, bevor du dich für eine komplette Implementierung entscheidest. Ein paar Stunden Benchmarking können dir Monate des Bedauerns ersparen.

Halte deine Testumgebung konsistent. Verwende auf beiden Plattformen NVMe gleichen NVMe , die gleiche RAM-Kapazität und passende Netzwerkschnittstellen. Wenn ein Server über einen schnelleren Speicher oder mehr Arbeitsspeicher verfügt, spiegeln deine Ergebnisse eher diesen Unterschied wider als die CPU-Leistung, die du eigentlich messen möchtest.

Schalte während deiner Tests SMT (bei AMD) und Hyper-Threading (bei Intel) ein und aus, um zu sehen, wie sich die jeweilige Plattform mit aktiviertem bzw. deaktiviertem Threading verhält. Manche Workloads profitieren stark von den zusätzlichen Threads, während andere nur minimale Verbesserungen oder sogar leichte Verschlechterungen zeigen. Wenn du das Threading-Verhalten deiner Workloads verstehst, kannst du besser vorhersagen, wie sich der Server bei einer höheren Anzahl gleichzeitiger Benutzer verhalten wird.

Wenn deine Infrastruktur es hergibt, solltest du während deiner Tests den Stromverbrauch aufzeichnen. Viele Server zeigen Stromverbrauchsdaten über IPMI an, und die meisten PDUs in Rechenzentren können den Verbrauch pro Steckdose melden. Mit diesen Daten kannst du die Leistung pro Watt berechnen, was wichtig ist, wenn du auf mehrere Knoten skalierst oder Colocation-Verträge aushandelst.

Haltet die Tests kurz, aber realistisch. Ein 30-minütiger Test mit produktionsähnlichen Verkehrsmustern bringt euch mehr als ein 4-stündiger Test mit künstlicher Belastung. Verwendet realistische Datenbankgrößen, echtes Benutzer-Sitzungsverhalten und echte API-Nutzdaten, wann immer das möglich ist.

Schritt 4: Entscheide dich anhand von Zahlen

Wenn du mit dem Testen fertig bist, schau dir deine Ergebnisse in drei Bereichen an: Durchsatz pro Kern, p95-Latenz bei deiner Zielauslastung und Energieverbrauch pro Arbeitseinheit.

Der Durchsatz pro Kern zeigt dir, wie gut jede Plattform ihre Rechenleistung nutzt. Wenn ein EPYC-Server mit 64 Kernen 50.000 RPS schafft, während ein Xeon-Server mit 32 Kernen 30.000 RPS schafft, ist der Xeon pro Kern eigentlich effizienter (937 RPS/Kern gegenüber 781 RPS/Kern). Das könnte wichtig sein, wenn deine Arbeitslast vertikal besser skaliert als horizontal.

Die Latenz bei der Zielauslastung zeigt, wie sich jede Plattform unter Druck verhält. Ein Server, der zwar super Durchsatzwerte hat, aber deinen p95-Schwellenwert 10 % früher als die Alternative überschreitet, wird eher Probleme für die Nutzer verursachen als die andere Option.

Die Energie pro Arbeitseinheit wirkt sich direkt auf die Betriebskosten aus. Wenn beide Plattformen deine Leistungsanforderungen erfüllen, kostet diejenige, die weniger Strom verbraucht, über die gesamte Lebensdauer des Servers weniger. Multipliziere die Differenz mit deinem Strompreis, deiner PUE (Stromverbrauchseffizienz) und der erwarteten Lebensdauer des Servers, um die tatsächlichen Einsparungen zu ermitteln.

Such dir die Plattform aus, die deinen SLA mit den wenigsten Knoten und der einfachsten Bedienung erfüllt. Ein etwas schnellerer Server, der eine spezielle Kernel-Optimierung und spezielle Treiberversionen braucht, kostet mehr Entwicklungszeit als ein etwas langsamerer Server, der mit den Standardkonfigurationen zuverlässig läuft.

Schritt 5: Energieverbrauch und Betriebszeit sichern

Die Hardwareauswahl hört nicht bei der CPU auf. Wie du die Stromversorgung und Redundanz planst, entscheidet darüber, ob der Server wirklich 99,99 % Verfügbarkeit schafft oder nur auf dem Papier gut aussieht.

Entscheide dich für redundante Netzteile in einer N+1-Konfiguration, das heißt, du hast ein Netzteil mehr, als du brauchst, um den Server bei voller Auslastung zu betreiben. Zwei Netzteile, die sich eine Last von 400 W teilen, laufen jeweils mit etwa 50 % ihrer Kapazität, was sie in den effizientesten Betriebsbereich für 80 PLUS Platinum- und Titanium-Geräte bringt. Wenn eines ausfällt, übernimmt das verbleibende Netzteil die volle Last ohne Unterbrechung, während du einen Ersatz planst.

Wähle deine Netzteile mit 20 bis 30 % Spielraum über dem gemessenen Spitzenstromverbrauch. Dieser Puffer sorgt dafür, dass die Geräte im Normalbetrieb in ihrem effizienten Bereich bleiben und bietet Kapazität für unerwartete Lastspitzen. Wenn Netzteile mit 90 % oder mehr ausgelastet sind, werden sie in weniger effiziente Bereiche gedrängt und der Verschleiß der Komponenten wird beschleunigt.

Leg deine Failover-Pfade fest, bevor du sie brauchst. Schreib auf, welche Dienste auf welche Backup-Systeme umgeschaltet werden, wie lange das Failover dauert und welche manuellen Schritte (falls nötig) erforderlich sind. Mach mindestens einmal im Quartal DR-Tests, um sicherzustellen, dass deine Dokumentation der Realität entspricht. Ein Failover-Plan, der nie getestet wurde, ist kein Plan, sondern nur Wunschdenken.

Betrachtet Leistung und Wiederherstellung als wichtige Teile eurer Infrastruktur und nicht als irgendwelche Extras, die man nach dem Einsatz einfach so draufpackt. Ein Server, der zwar super Benchmarks liefert, aber einen Ausfall des Netzteils nicht übersteht, ist nicht produktionsreif.

Konfigurationsbeispiele, die du wiederverwenden kannst

API mit hohem Durchsatz oder Streaming-Knoten (AMD EPYC)

• CPU: AMD EPYC 4545P (16 Kerne/32 Threads)
• RAM: 192 GB DDR5 ECC für schnellen Speicherzugriff
• Speicher: 2×3,84 TB NVMe SSD RAID-Konfiguration
• Netzwerk: Burstable 10 Gbit/s mit der Option für dedizierte Bandbreite
• IPs: 32 dedizierte IPs für Multi-Tenant- oder CDN-Edge-Bereitstellungen

Hochdichter VPS-Knoten (EPYC-orientiert)

• CPU: EPYC mit vielen Kernen
• RAM: So dimensioniert, dass es bei Bursts nicht zum Swapping kommt
• Speicher: NVMe auf separaten PCIe-Lanes
• Netzwerk: 10/25 GbE mit isoliertem Backup-Datenverkehr
• Stromversorgung: Zwei Hot-Swap-Netzteile, 80 PLUS Platinum, mit 20–30 % Spielraum

Transaktionsintensiver E-Commerce-Knoten (oft mit Xeon-Prozessoren)

• CPU: Xeon mit starken Taktraten pro Kern
• RAM: Ausgelegt für großen Seitencache
• Speicher: NVMe für schnelles Schreiben; Replikate für Lesevorgänge
• Netzwerk: Netzwerkkarten mit niedriger Latenz; TLS/Bildverarbeitung nicht auf dem Hot Path laufen lassen
• Stromversorgung: Mehrere Netzteile, die für Spitzenlasten ausgelegt sind

Unternehmens-Discord-Bot-Cluster (EPYC-Kern + ausgewählte Xeon-Prozessoren)

• CPU: EPYC für den Worker-Pool; optional kleiner Xeon-Slice für latenzkritische Microservices
• Datenbank: PostgreSQL Lesereplikaten
• Cache: Redis für Hotkeys
• Netzwerk: Lastenausgleich über mehrere Regionen, um unter 50 ms zu bleiben
• Stromversorgung: Zwei Netzteile; DR-Test jeden Monat

Diese Builds sind keine Regeln, sondern Beschleuniger. Passt sie an euren Code, euer Datenmodell und eure Latenzziele an. Mit praktischen Konfigurationen können wir zum Schluss kommen und die wichtigsten Punkte zusammenfassen, die ihr für die Einweisung eures Teams verwenden könnt.

Du hast gesehen, wie jede Plattform verschiedene Aufgaben unterstützt und wie du die Größe ohne Rätselraten bestimmen kannst. Der letzte Schritt besteht darin, die Entscheidung zusammenzufassen, damit dein Team handeln kann. Der nächste Abschnitt gibt dir eine kurze Zusammenfassung und einen klaren nächsten Schritt.

Ein paar letzte Gedanken

AMD EPYC bietet eine hohe Multi-Core-Dichte, eine großzügige Speicherbandbreite und jede Menge PCIe-Lanes. Es ist super für Virtualisierung, Multi-Tenant-Hosting, Analysen und KI-Training, wo Thread-Skalierung und I/O-Headroom p95 stabil halten. Zusammen mit effizienten, redundanten Netzteilen kann es SLAs mit weniger Knoten und weniger Energie pro Arbeitseinheit erreichen.

Intel Xeon bietet eine starke Leistung pro Kern und ein ausgereiftes Unternehmensökosystem. Es eignet sich super für Transaktionspfade, zertifizierte Stacks und Teams, die von Hersteller-Tools und Validierungen profitieren. Mit dem richtigen Speicher- und Netzwerk-Layout sorgt es für schnelle Checkout- und API-Pfade, wenn man Latenzen nicht vermeiden kann.

Such dir die Plattform aus, die am besten zu deinem größten Engpass und deinem Wachstumsplan passt, und probier sie dann mit kleinen, realistischen Tests aus. Nutze dann Hyperscale-Praktiken und leistungsstarke Designs, die eine Verfügbarkeit von 99,99 % ermöglichen. So wird deine CPU-Entscheidung zu einem Geschäftsvorteil und nicht zu einem wissenschaftlichen Projekt.

Wenn du einen neuen Knoten dimensionierst oder eine Migration planst, gib uns deine Spitzenwerte und dein Ziel p95. Wir helfen dir dabei, die richtige CPU, den richtigen Arbeitsspeicher, Speicherplatz und das richtige Stromversorgungsdesign für deine Ziele und dein Budget zu finden. Das Ergebnis ist ein Plan, der am Starttag funktioniert und sich nahtlos skalieren lässt, wenn deine Zielgruppe wächst. Sprich mit einem Experten von InMotion Hosting, und wir helfen dir dabei, den besten Plan für dein Team zu finden.