Wie man eine Server-CPU auswählt: Expertenleitfaden 2026

Einleitung

Eine Server‑CPU ist nicht nur „die leistungsstärkste Komponente“ — sie ist das Bauteil, das die Skalierungsobergrenze setzt, die Balance der gesamten Plattform (Arbeitsspeicher, PCIe, Storage, Netzwerk) definiert und die Gesamtbetriebskosten (TCO) über einen Horizont von 3–5 Jahren direkt beeinflusst. Ein CPU‑Fehler zeigt sich selten „sofort“: häufiger wird er zu chronischen Symptomen — stetige Latenzspitzen in der Datenbank, zu wenige PCIe‑Lanes für NVMe/GPU, keine Möglichkeit, den RAM auszubauen, oder ein plötzlicher Anstieg der Lizenz‑ oder Stromkosten.

Serverprozessoren unterscheiden sich von Desktop‑Chips nicht nur durch die Kernanzahl. Entscheidend ist das Server‑Ökosystem, das um sie herum gebaut ist: Unterstützung für ECC‑Arbeitsspeicher, Zuverlässigkeits‑ und Diagnosefunktionen (RAS), langfristiger Plattform‑Support, vorhersehbares 24/7‑Verhalten unter Last, validierte Kompatibilität mit Mainboards, RAID/HBA‑Controllern, NICs, Hypervisoren und Enterprise‑Betriebssystemen. Dazu kommen erweiterte I/O‑Fähigkeiten: mehr Speicherkanäle und PCIe‑Lanes, die in einem realen Server oft wichtiger sind als „+200 MHz im Turbo“.

Dieser Artikel ist ein praxisnaher Leitfaden für Sysadmins, DevOps‑Engineers und IT‑Manager, die CPUs für konkrete Workloads auswählen: Web‑Anwendungen, Datenbanken (OLTP/OLAP/In‑Memory), Virtualisierung, Kubernetes, softwaredefinierten Storage und AI/ML. Wir zerlegen die wichtigsten Merkmale, geben Formeln und Rechenbeispiele (inklusive Stromkosten und TCO), zeigen typische Konfigurationen und schließen mit einer Checkliste, die eine Entscheidung ohne zusätzliches „Googeln“ erleichtert.

Hauptanbieter: Intel Xeon und AMD EPYC

Intel Xeon (Server‑Ökosystem und Plattform‑Vorhersehbarkeit)

Intel war historisch stark bei Enterprise‑Kompatibilität, Plattform‑Reife und breiter Verfügbarkeit bei Herstellern. Die häufigste „universelle“ Linie ist Xeon Scalable: Sie deckt alles ab — von relativ günstigen Modellen für typische Aufgaben bis hin zu High‑Performance‑CPUs für Datenbanken, Analytics und Virtualisierung. Im Xeon‑Ökosystem geht es nicht nur um Kerne — auch Plattform‑Fähigkeiten zählen: Anzahl der Speicherkanäle, PCIe‑Gen5‑Support, Sicherheits‑ und Telemetrie‑Features sowie Optimierungen für gängige Enterprise‑Workloads. Die offizielle Xeon‑Scalable‑Linie und ihre Positionierung finden Sie auf der Intel‑Seite.

Features, die in realen Workloads häufig relevant sind:

• Hyper‑Threading (Threads) — hilft bei parallelen Workloads, ersetzt aber keine physischen Kerne (insbesondere bei strikten Latenz‑SLOs).
• Vektor‑Instruktionen (inklusive AVX‑512 in einigen Aufgaben) — spürbar in HPC/wissenschaftlichem Rechnen, in Teilen der Analytics und bei Multimedia‑Workloads. (Wichtig: Der Effekt hängt von der Software ab und davon, wie sie kompiliert/konfiguriert wurde.)

AMD EPYC (viel I/O und Speicher „ab Werk“, starke Dichte)

Aktuelle AMD‑EPYC‑Generationen sind eine Wette auf hohe Compute‑Dichte und insbesondere auf I/O: viele PCIe‑Lanes, viele Speicherkanäle, hohe Speicherbandbreite — all das ist oft kritisch für Virtualisierung, Container, Analytics und Storage‑Systeme. Je nach eingesetzter Software kann das auch bei der Lizenzierung wichtig sein: Manche Produkte werden pro Sockel lizenziert, und eine einzelne AMD‑CPU mit vielen Kernen kann kosteneffizienter sein als eine Dual‑Socket‑Intel‑Plattform.

Aktuelle Familien, die bei Beschaffungen 2026 häufig betrachtet werden:

• EPYC 9004 (Genoa) — 4. EPYC‑Generation für moderne Rechenzentren.
• EPYC 9005 (Turin) — 5. EPYC‑Generation (Zen 5 / Zen 5c) als nächster Schritt bei Performance und Effizienz.

AMD betont zudem eine „breite Auswahl“ an Kernzahlen/Power‑Envelopes und positioniert EPYC für Cloud/Enterprise auf der Produktseite. (AMD)

Tabelle: Herstellervergleich (vereinfacht, für die praktische Auswahl)

Kriterium	Intel Xeon (Scalable)	AMD EPYC (9004/9005)
„Pro‑Kern“-Performance	Oft stark in Aufgaben, bei denen Single‑Thread/Latenz zählt (modellabhängig)	Je nach Linie stark unterschiedlich; gewinnt oft „pro Server“ durch Plattform‑Ressourcen
Speicher (Kanäle/Bandbreite)	Bis zu 8 DDR5‑Kanäle pro Sockel in typischen Scalable‑Plattformen	12 DDR5‑Kanäle und hohe Bandbreite — ein zentraler Vorteil von EPYC 9004/9005
PCIe und I/O	Oft 80 PCIe‑Gen5‑Lanes pro Sockel	128 PCIe‑Gen5‑Lanes in 1P — starkes Argument für NVMe/GPU/Networking
Ökosystem (Server/Firmware/Kompatibilität)	Sehr breit, viele validierte Konfigurationen	Breit und schnell wachsend, besonders in Cloud und High‑Density

Wichtige CPU‑Eigenschaften (und wie sie sich im Server bemerkbar machen)

Kernanzahl und Taktfrequenz: wo die Wahrheit liegt — und wo Marketing

Physische Kerne vs. Threads (SMT/Hyper‑Threading). Threads (SMT) verbessern die Performance, wenn ein Workload gut parallelisiert und auf Pipeline‑Bubbles stößt (Warten auf Speicher/Branching). Aber Threads sind nicht gleich zusätzliche Kerne: Für Datenbanken mit strikten Latenzanforderungen oder CPU‑gebundene Aufgaben (Kompilierung, einige Berechnungen) sind physische Kerne meist wichtiger.

Wann Sie viele Kerne brauchen:

• Virtualisierung (viele VMs/Container);
• Kubernetes‑Cluster mit hoher Pod‑Dichte;
• Webserver und Anwendungen mit vielen parallelen Requests;
• Analytics/ETL, Batch‑Jobs, viele Storage‑Services.

Wann Takt (und niedrige Latenz) zählt:

• OLTP‑Datenbanken (kurze Transaktionen, viel Locking/Contention, Latenz ist kritisch);
• Legacy‑Anwendungen mit begrenzter Parallelität;
• einige Middleware‑Komponenten, bei denen die Single‑Thread‑Antwortzeit entscheidend ist.

Base vs. Turbo — was das wirklich bedeutet.

• Basisfrequenz — die Frequenz, die die CPU innerhalb ihres Power‑/Thermal‑Envelopes bei anhaltender Last garantiert halten kann (vereinfacht).
• Turbo/Boost — eine „Peak“-Frequenz, wenn thermisches/energetisches Budget verfügbar ist, oft mit einer begrenzten Zahl aktiver Kerne, die höher boosten können.

Praktische Erkenntnis: Wenn Sie „32 Kerne kaufen, weil Turbo 3,9 GHz ist“, stellen Sie sicher, dass Ihr Workload tatsächlich nur wenige Kerne nutzt oder den benötigten Boost unter Ihrem Strom-/Kühlprofil halten kann. Andernfalls bekommen Sie „viele Kerne bei moderatem Takt“ — manchmal völlig okay (Virtualisierung) und manchmal nicht (OLTP).

Cache: warum L3 oft wichtiger ist als „+200 MHz“

Für Server ist Cache ein Puffer zwischen Kernen und Arbeitsspeicher. Wenn das Working Set (Indizes, „hot“ DB‑Pages, Metadaten) häufiger im L3 landet, sinken RAM‑Zugriffe, Latenzen werden geringer und die Vorhersagbarkeit steigt.

In der Praxis:

• OLTP‑Datenbanken profitieren von größerem L3, weil Cache‑Misses auf „hot“ Indizes und interne Strukturen sinken.
• OLAP/Analytics profitieren ebenfalls, insbesondere bei Scans/Aggregationen und wiederholter Datenwiederverwendung.
• Virtualisierung erhält stabilere Latenzen, wenn Hypervisor und „hot“ Pages der Gäste häufiger näher an den Kernen bleiben.

Typische L3‑Spannen sieht man an realen Modellen: AMD EPYC 9554 hat 256 MB L3. Ein High‑End Intel Xeon Platinum 8580 bietet ebenfalls große Cache‑Kapazität und hohe Kerndichte.

Speicherunterstützung: DDR4 vs. DDR5, Kanäle, Kapazität, DIMM‑Typen

DDR4 vs. DDR5. Bei Beschaffungen 2026 ist DDR5 bereits der De‑facto‑Standard für neue Plattformen: höhere Bandbreite und bessere Skalierung für Multi‑CPU/High‑Core‑Konfigurationen. DDR4 kann aber weiterhin wirtschaftlich sinnvoll sein — ebenso wie eine etwas ältere Servergeneration, wenn die Plattform günstiger ist und der erwartete Workload die Speicherbandbreite nicht ausreizt (insbesondere unter Berücksichtigung der Memory‑Preise Anfang 2026).

Anzahl der Speicherkanäle und Speicherbandbreite sind kritisch für:

• Datenbanken (insbesondere In‑Memory und Analytics);
• Virtualisierung bei hoher VM‑Dichte;
• viele Datenverarbeitungs‑ und Storage‑Workloads (z. B. Ceph auf ausgelasteten Nodes).

Auf Plattformebene sind die Unterschiede deutlich:

• Intel Xeon Scalable liefert typischerweise bis zu 8 Speicherkanäle.
• AMD EPYC 9004/9005 liefert 12 DDR5‑Kanäle als grundlegenden Plattformvorteil.

Maximale Speicherkapazität hängt nicht nur von der CPU, sondern auch vom Server ab (Anzahl DIMM‑Slots und RDIMM/LRDIMM‑Support). Hersteller nennen diese Limits explizit: Zum Beispiel listet HPE ProLiant DL360 Gen11 bis zu 8 TB DDR5 und PCIe‑Gen5‑I/O.

RDIMM vs. LRDIMM.

• RDIMM ist in der Regel günstiger und für die meisten Workloads ausreichend.
• LRDIMM wird genutzt, wenn Sie die maximale Kapazität pro Sockel benötigen (teurer, teils mit Nuancen bei Frequenz/Latenz).

Tabelle: Speicher und I/O in gängigen Linien (praktische Referenz)

Linie	Speicher	Kanäle	PCIe	Kommentar
Intel Xeon Scalable (Beispiel: Gold 6430)	DDR5	8	80 Gen5‑Lanes	Starkes Ökosystem, ausgewogener „Generalist“
AMD EPYC 9004/9005	DDR5	12	128 Gen5‑Lanes	Hohe I/O‑ und Speicherdichte „ab Werk“
Entry‑Server (Beispiel: Dell PowerEdge T360)	DDR5 ECC UDIMM	plattformspezifisch	abhängig	Bis zu 128 GB ECC UDIMM — typisch für KMU/Filialen

PCIe‑Lanes: NVMe, GPUs und 100G — wo die CPU alles entscheidet

PCIe 4.0 vs. 5.0. PCIe Gen5 verdoppelt die Bandbreite pro Lane gegenüber Gen4. Das wird wichtig, wenn:

• Sie viele NVMe‑Drives nutzen (insbesondere U.2/U.3/EDSFF und netzwerkbasierte RAID‑Ansätze);
• Sie mehrere GPUs einsetzen;
• Sie schnelle NICs (25/100/200G) sowie SmartNIC/DPU verwenden.

Wie viele Lanes brauchen Sie wirklich? Ein einfacher Weg ist das Zählen der Devices nach „Breite“:

• eine NVMe‑SSD ist fast immer x4;
• eine 100G‑NIC ist oft x16 (modellabhängig);
• eine GPU ist meist x16.

Beispiel‑Aufteilung (eine Idee, nicht das einzige Schema):

• 8× NVMe (8 × x4 = 32 Lanes)
• 2× 100G NIC (2 × x16 = 32 Lanes)
• 4× GPU (4 × x16 = 64 Lanes)
  Total: 32 + 32 + 64 = 128 Lanes — ein typischer „Ideal“-Fall für eine CPU, die 128 PCIe‑Lanes bereitstellt (z. B. eine EPYC‑Plattform).

Bei konkreten Intel‑Modellen kann man sehen, wie viele Lanes pro Sockel verfügbar sind: Xeon Gold 6430 nennt 80 PCIe‑Lanes.
Praktische Erkenntnis: Wenn Sie „von allem viel“ planen, ist PCIe nicht „nebensächlich“ — es ist oft der Haupt‑Limiter.

Power (TDP) und Geld: eine Beispielrechnung

TDP ist nicht „exakte Steckdosenleistung“, aber eine solide Referenz für thermisches Design und das Verständnis der CPU‑Klasse. In der Realität kann ein Server mehr/weniger verbrauchen — abhängig von Turbo‑Modi, BIOS‑Power‑Profilen, Auslastung, Anzahl DIMMs, Laufwerken usw.

Um nicht zu raten, nutzen Sie eine Näherung auf Basis der durchschnittlichen Leistung unter Ihrem Workload. Nehmen wir an:

• der Server liegt im Mittel bei 250 W (0,25 kW) für CPU+Plattform unter realer Last;
• Strompreis $0.12/kWh (Beispiel);
• 24/7‑Betrieb über 5 Jahre.

Rechnen Sie:

• Stunden pro Jahr: 24 × 365 = 8760
• Jahresverbrauch: 0,25 × 8760 = 2190 kWh
• Jahreskosten: 2190 × 0,12 = $262.80
• 5‑Jahres‑Kosten: 262.80 × 5 = $1314.00

Stellen Sie sich nun vor, Sie wählen eine CPU/ein Power‑Profil, das im Schnitt +100 W mehr verbraucht (0,10 kW) — für einen kleinen Performance‑Gewinn, den Sie nicht benötigen. Dann liegen die „Mehrkosten“ über 5 Jahre bei:

• 0,10 × 8760 × 0,12 × 5 = 876 × 0,12 × 5 = 105,12 × 5 = $525.60
  Und das ohne Kühlung und Rack/USV. Fazit: Eine „günstigere CPU“ ist nicht automatisch günstiger in der Realität.

Multi‑Socket (1P vs. 2P) und NUMA: wann eine zweite CPU wirklich nötig ist

1P (Single Socket) ist einfacher: weniger NUMA‑Effekte, leichteres Tuning und oft vorhersehbarere Latenz. Gleichzeitig bietet AMD NUMA‑Tuning: Auf einem Single‑Socket lässt sich von 1 bis 4 NUMA‑Nodes konfigurieren, und je nach Workload kann und sollte das angepasst werden.
2P (Dual Socket) liefert mehr Kerne, mehr Speicher, mehr PCIe und oft eine höhere Skalierungsobergrenze.

Aber 2P hat einen Preis: NUMA. Speicher ist „näher“ an seinem Sockel, und wenn eine Anwendung ständig Remote‑Memory nutzt, steigt die Latenz und die Performance sinkt. Das ist kritisch für:

• OLTP‑Datenbanken,
• einige latenzsensitive Services,
• dichte Virtualisierung ohne korrektes NUMA‑Pinning.

Praktische Regel:

• Wählen Sie 2P, wenn Sie wirklich Speicher/PCIe/Kerne jenseits dessen benötigen, was 1P liefern kann, oder wenn der Server viele heterogene Workloads konsolidiert.
• Bleiben Sie bei 1P, wenn der wichtigste KPI Latenz und operative Einfachheit ist und ein Sockel genügend Ressourcen mit Reserve bietet.

Spezialisierte Instruktionen und Beschleuniger: wann es zählt

• AES‑NI / Hardware‑Verschlüsselung: beschleunigt TLS, VPN, Laufwerksverschlüsselung. Bei modernen Server‑CPUs ist das typischerweise ein „Must‑have“.
• AVX‑512: kann einen spürbaren Boost in HPC/wissenschaftlichem Rechnen, einigen Analytics‑Workloads und Spezialsoftware liefern (wenn diese Instruktionen genutzt werden).
• AI/ML‑Beschleunigung (z. B. VNNI/DL‑Accelerators): relevant, wenn Sie Inference auf der CPU durchführen oder bestimmte Matrix‑Operationen ohne GPUs beschleunigen. Wichtig ist, Benchmarks für Ihr konkretes Framework/Ihre Version zu prüfen.

Workload‑Typen und Anforderungen: die Aufgabe in CPU‑Parameter übersetzen

Webserver und Anwendungen

Profil: viele parallele Requests; stabiler Throughput ist wichtig, Sie brauchen genügend Kerne, aber der Takt beeinflusst auch p95/p99‑Latenz.

Typische Empfehlung: 16–32 Kerne, moderater Takt, genügend RAM und schnelles I/O.
Beispiel‑Logik: Intel Xeon Silver/Gold oder AMD EPYC Mid‑Range. Als EPYC‑Referenzpunkt gelten Modelle der EPYC 9254‑Klasse (9004‑Serie) oft als ausgewogene Kerne/Takt‑Option für allgemeine Anwendungen.

Datenbanken

OLTP (transaktional)

Profil: viele kurze Operationen, Locks, Journaling; Latenz ist kritisch.

Sie brauchen:

• hohen Turbo‑Takt auf den „arbeitenden“ Kernen;
• schnellen Speicher und ausreichende Bandbreite;
• vorhersehbare Latenz (oft besser mit 1P oder gut getuntem 2P/NUMA).

Beispiel‑CPU‑Klasse für OLTP: Intel Xeon Gold mit Fokus auf Frequenz (z. B. wird Gold 6538N häufig als high‑frequency/DB‑orientierte Option in der Linie eingeordnet).

OLAP (analytisch)

Profil: Scans, Aggregationen, parallele Queries, Batch‑Jobs.

Sie brauchen:

• viele Kerne (32–64+);
• großen Cache;
• hohe Speicherbandbreite;
• genügend PCIe für schnelle NVMe und Networking.

In‑Memory‑DB (Redis / SAP‑HANA‑ähnlicher Ansatz)

Profil: alles im Speicher; Bandbreite und Kapazität sind entscheidend.

Sie brauchen:

• maximale Anzahl an Speicherkanälen;
• hohe Speicher‑Geschwindigkeit und korrekte DIMM‑Bestückung;
• große Gesamtkapazität an RAM.

Tabelle: schnelle Konfigurationshinweise für Datenbanken

Datenbanktyp	CPU	Speicher	I/O
OLTP	weniger, aber schnellere Kerne; hoher Turbo‑Takt	hohe Frequenz/Bandbreite, ausreichende Kapazität	NVMe/Journal, niedrige Latenz
OLAP	viele Kerne, großer Cache	viel RAM und Bandbreite	NVMe/Throughput, Networking
In‑Memory	Balance aus Takt und Kernen	maximale Kanäle und Kapazität	oft sekundär, aber Stabilität ist wichtig

Virtualisierung

Profil: viele unterschiedliche VMs, Wettbewerb um CPU/Cache/Speicher; „flache“ Latenz zählt.

Praktische Dimensionierung: Eine gängige Faustregel sind 4–6 vCPU pro physischem Kern (stark abhängig vom VM‑Profil). Es lohnt sich, das als potenzielles Anti‑Pattern für kritische VMs zu kennen (mehr vCPU als physische Kerne/Threads) — das heißt CPU‑Oversubscription und kann unter ernsthafter Last nicht die besten Ergebnisse liefern.

Grobe Schätzung: Wenn Sie 30–50 VMs mittlerer Dichte anpeilen, ist ein sinnvoller Startpunkt 32–64 physische Kerne, plus Reserve.

2P‑Beispiele:

• 2× Intel Xeon Gold 6430 (ein typischer 32‑Core‑Sockel ergibt in 2P 64 Kerne gesamt).
• 2× AMD EPYC 9334 (Referenz: 32 Kerne pro Sockel in 2P).

Schlüsselpunkt: NUMA‑bewusste Konfiguration — Pinning, korrektes VM‑Placement und Prüfung auf Remote‑Memory‑Zugriffe.

Containerisierung (Kubernetes)

Profil: hohe Pod‑Dichte, Plattform‑Overhead, requests/limits, mögliche Spikes.

Empfehlung: mehr Kerne bei mittlerem Takt + genügend RAM und Speicherbandbreite. Wenn Sie viele Sidecar‑Container und ein Service‑Mesh haben, „schmilzt“ CPU‑Budget schneller, als es die Application‑Metriken nahelegen.

Storage‑Systeme

• Ceph / softwaredefinierter Storage: Häufig reichen pro Node 16–32 Kerne, aber vieles hängt von der Rolle (OSD/Monitor), dem Netzwerk und den Laufwerken ab. CPU ist relevant für Codecs (Erasure Coding), Kompression, Verschlüsselung und den Netzwerk‑Stack.
• NVMe‑over‑Fabrics: Bottlenecks liegen in PCIe, Networking und Queue‑Processing — CPU und PCIe‑Lanes sind kritisch.
• Fileserver: CPU ist meist nicht der Engpass, außer bei starker Verschlüsselung/Kompression/Deduplizierung.

ML/AI und Compute

Wenn Sie einen GPU‑Server bauen, ist die Hauptaufgabe der CPU, der GPU nicht „im Weg zu stehen“:

• oft reichen 16–32 CPU‑Kerne für einen Multi‑GPU‑Node (wenn kein schweres Preprocessing auf der CPU läuft);
• kritisch ist PCIe x16 für jede GPU und dass Lanes nicht durch Disks/Networking „aufgebraucht“ werden.

Plattformen mit vielen PCIe‑Lanes (z. B. 128) sind für solche Builds besonders komfortabel.

Zusätzliche Faktoren, die die Auswahl verändern

Zuverlässigkeit: ECC und RAS sind keine „Optionen“, sondern Basishygiene

ECC‑Arbeitsspeicher ist Server‑Standard: Er reduziert das Risiko seltener, aber zerstörerischer Speicherfehler. RAS‑Features (Diagnostik, Hardware‑Error‑Logging) sind wichtig im Betrieb: Sie wollen DIMM/CPU‑Degradation erkennen, bevor es zum Ausfall kommt.

Kompatibilität: HCL, Firmware und Hersteller‑Support

Prüfen Sie HCL‑Kompatibilität (Hypervisor/OS/Controller/NICs) und unterstützte CPUs für das konkrete Servermodell. Derselbe „Xeon Gold“ kann physisch mit einer anderen Servergeneration inkompatibel sein.

Software‑Lizenzierung: per Core kann eine „günstige CPU“ teuer werden

Einige Enterprise‑Produkte werden pro Kern lizenziert. Das verändert die Wirtschaftlichkeit: Manchmal ist es besser, eine CPU mit weniger, aber schnelleren Kernen zu wählen, statt „mehr günstige Kerne“ zu nehmen und dann für Lizenzen zu zahlen.

TCO (Total Cost of Ownership): eine Formel, die sich lohnt

Vereinfacht:
TCO = Serverpreis + (Durchschnittsleistung × Tarif × 24 × 365 × 5)
Ja, es ist grob, aber selbst auf diesem Level sieht man: Strom und Kühlung können den Unterschied zwischen zwei CPU‑Klassen „auffressen“.

Sicherheit: Spectre/Meltdown‑Klasse und Performance‑Impact

Mitigations für CPU‑/OS‑Kernel‑Schwachstellen können die Performance reduzieren. Je nach Szenario und Plattform kann der Effekt klein sein, in manchen Fällen aber spürbar; Red Hat weist darauf hin, dass der Einfluss stark vom Workload und den Schutzmechanismen abhängt.
Praxis: Halten Sie Firmware/Microcode und den OS‑Kernel aktuell und messen Sie den Effekt auf Ihrem eigenen Workload‑Profil, bevor Sie „blind“ kaufen.

Use‑Cases 2026: Beispiele für Dell/HPE‑Server und passende CPUs (ohne Bindung an konkrete Preise)

Hinweis: Preise hängen von Region, Support, Storage/Networking/RAM‑Konfiguration und Lieferbedingungen ab — daher geht es unten nur um die Konfigurationslogik.

Dell PowerEdge für ein kleines Unternehmen / eine Filiale

Server: Dell PowerEdge T360 (Tower, Single‑Socket) — eine typische Option für Büro/Filiale.
CPU: Intel Xeon E‑2488 (8 Kerne/16 Threads; Frequenzangaben — Intel‑Spezifikationen).
Einsatzszenarien: Fileservices, Domain Controller, Small‑Business‑Anwendungen, leichte Virtualisierung.
Speicher: bis zu 128 GB DDR5 ECC UDIMM.

HPE ProLiant für Webhosting / Container

Server: HPE ProLiant DL360 Gen11 (1U, 2P).
HPE nennt explizit Support für Intel Xeon Scalable 4./5. Gen, bis zu 64 Kerne, bis zu 8 TB Speicher und PCIe Gen5.
CPU‑Optionen: Intel Xeon Silver 4416+ (günstiger Einstieg) oder Xeon Gold 6430 (höhere Dichte).
Einsatzszenarien: Webhosting, Kubernetes, Mid‑Tier‑Services, „moderate“ Datenbanken.

Dell PowerEdge für OLTP‑Datenbanken (latenzsensitiver Workload)

Server: Dell PowerEdge R760 (2U, Plattform für moderne Xeon Scalable; Angaben zu Speicher/PCIe — Dell‑Specs).
CPU: Intel Xeon Gold 6538N (oft als frequenzfokussierte/DB‑Profil‑Option betrachtet; Kompatibilität mit der gewählten Plattform prüfen).
Einsatzszenarien: hochlastige OLTP‑Systeme, ERP/CRM‑Klasse‑Anwendungen, transaktionale Services.
Kommentar: Für OLTP ist es fast immer wichtiger, Speicher/Disks/Journaling korrekt zu bauen und stabile p95/p99 zu erreichen, als „noch 16 Kerne“ hinzuzufügen.

HPE ProLiant für Virtualisierung (2P, hohe Dichte)

Server: HPE ProLiant DL380 Gen11 (2U, 2P). HPE nennt Xeon Scalable 4./5. Gen Support und bis zu 8 TB DDR5 und positioniert das Modell für Virtualisierung.
CPU‑Optionen:

• 2× Intel Xeon Gold 6430 (64 Kerne gesamt)
• oder eine AMD‑Plattform mit 2× EPYC 9334 (Referenz: 32 Kerne pro Sockel)

Einsatzszenarien: 50–100 VMs (je nach Profil), ein Hypervisor‑Cluster.

Dell/HPE für OLAP/Analytics (Data Warehouse, ETL)

Ansatz: viele Kerne + hohe Speicherbandbreite + schnelles I/O.
CPU‑Klassen als Referenz:

• Intel Xeon Platinum 8580 (High‑End, viele Kerne und Cache)
• AMD EPYC 9554 (64 Kerne/128 Threads, 256 MB L3)
  Als „Chassis“ für diese Aufgaben werden oft Plattformen der Dell‑PowerEdge‑R760‑Klasse oder entsprechende HPE‑2U‑Serien gewählt — abhängig von Anforderungen an Disks/GPU/Networking.

HPE ProLiant für ML/AI (GPU‑Server)

Server: HPE ProLiant DL385 Gen11 (eine AMD‑fokussierte Plattform). Hersteller‑Materialien betonen EPYC‑Support und einen Fokus auf Skalierung für moderne Workloads.
CPU: EPYC 9554 oder eine andere EPYC‑9004/9005‑CPU für die gewünschte Balance aus Takt/Kernen.
Kritisch: PCIe‑Topologie für GPUs (x16 pro GPU), Networking sowie Strom/Kühlung.

Tabelle: Dell vs. HPE‑Use‑Cases (nach Zweck)

Zweck	Dell (Beispiel)	HPE (Beispiel)	CPU‑Klasse
Kleines Unternehmen/Filiale	PowerEdge T360	ProLiant ML‑Klasse (ähnliches Segment)	Xeon E‑2400 (Beispiel: E‑2488)
Web/Container	PowerEdge R760‑Klasse	ProLiant DL360 Gen11	Xeon Silver/Gold
OLTP‑DB	PowerEdge R760	ProLiant DL360/DL380 Gen11	High‑Frequency Xeon Gold (Beispiel: 6538N)
2P‑Virtualisierung	PowerEdge R760‑Klasse	ProLiant DL380 Gen11	2× Xeon Gold 6430 / 2× EPYC 9334
OLAP/Analytics	PowerEdge 2U‑Klasse	ProLiant 2U‑Klasse	Xeon Platinum 8580 / EPYC 9554
ML/AI (GPU)	PowerEdge Accelerator‑Klasse	ProLiant DL385 Gen11	EPYC 9004/9005 + GPU

Wann Dell wählen (häufige Gründe):

• komfortable Remote‑Management‑Tools iDRAC und Server‑Administration über die Infrastruktur hinweg.

Wann HPE wählen (häufige Gründe):

• starke ProLiant‑Linie und iLO‑Remote‑Management in Enterprise‑Szenarien.

Beachten Sie außerdem die offiziellen Dell‑ und HPE‑Server‑Line‑Pages — direkt bei den Herstellern.

Schritt‑für‑Schritt‑Auswahlmethodik (was wirklich funktioniert)

Schritt 1. Workload‑Typ bestimmen und das aktuelle System profilieren.
Starten Sie nicht mit „welcher Xeon besser ist“. Starten Sie mit Metriken: CPU‑Auslastung (mit user/system/iowait‑Aufschlüsselung), p95/p99‑Latenz, Disk‑Throughput, Netzwerk, Cache‑Misses (falls verfügbar), RAM‑Nutzung und Swap sowie Disk‑Queue‑Depth.

Schritt 2. Metriken in Anforderungen übersetzen.

• Kerne: Nehmen Sie Ihren aktuellen „sustained peak“ und multiplizieren Sie ihn mit 1,5–2 (Wachstum + Reserve).
• Takt: Wenn OLTP/latenzkritisch — Takt zählt; bei parallelem Web/Containern zählen Kerne und Speicher oft mehr.
• Speicher: Kapazität + Kanäle. Wenn RAM bereits „knapp“ ist, hilft ein CPU‑Upgrade nicht.
• PCIe: Zählen Sie Devices (NVMe/GPU/NIC) und stellen Sie sicher, dass die Lanes nicht ausgehen, bevor es Ihr Budget tut.

Schritt 3. Eine Shortlist aus 3–5 CPU‑Modellen erstellen.
Wählen Sie nicht „ganz oben“, sondern mehrere Kandidaten: eine Mid‑Range‑Option, eine „optimale“ Option und eine „mit zusätzlicher Reserve“.

Schritt 4. Benchmarks prüfen — aber richtig.
Nutzen Sie:

• SPEC CPU2017 als Industrie‑Referenz für CPU‑Workloads.
• PassMark — als Massenvergleich (mit Methodik‑Einschränkungen).
  Und am wichtigsten: Wenn möglich, testen Sie Ihre Anwendung (oder das nächste synthetische Profil).

Schritt 5. TCO vergleichen, nicht nur den CPU‑Preis.
Dazu gehören Strom, Kühlung, Lizenzierung, Downtime sowie die Kosten zukünftiger RAM/PCIe‑Erweiterungen.

Schritt 6. Kompatibilität und Verfügbarkeit prüfen.
Servergeneration, BIOS/UEFI, DIMM‑Support, kompatible NIC/HBA‑Liste, Hypervisor‑Support.

Schritt 7. Entscheidung mit 30–50% Wachstumspuffer treffen.
Ein Server, der vom ersten Tag an „am Limit“ ist, ist fast immer teurer auf lange Sicht.

Häufige Fehler (und warum sie viel kosten)

• Überzahlen für ein Top‑Modell bei Workloads, bei denen der Engpass tatsächlich Speicher/Storage/Networking ist oder die CPU deutlich unterausgelastet bleibt.
• Speicher unterschätzen: Der Flaschenhals ist oft nicht die CPU, sondern RAM‑Bandbreite/-Kapazität.
• Stromverbrauch ignorieren: Sparen bei der CPU kann in 5 Jahren zum Draufzahlen führen (siehe Rechnung oben).
• Eine veraltete Generation kaufen „wegen Rabatt“, PCIe Gen5/DDR5 verlieren und mit Zeit/Risiko bezahlen.
• Per‑Core‑ oder Per‑Socket‑Lizenzierung ignorieren, besonders bei Enterprise‑Datenbanken/Virtualisierung.
• Kein Puffer: Ein Server, der „noch so eben“ reicht, reicht nach dem ersten Wachstumsschritt nicht mehr.
• NUMA vernachlässigen: Dann erscheinen p99‑Latenz und „seltsame“ Drops „plötzlich“.

Vergleichstabelle und Checkliste

Tabelle: „Top“-CPU‑Klassen nach Budget (Kategorien‑Referenz, keine Preisliste)

Budget‑Klasse	Typische Szenarien	CPU‑Referenz
Entry	Büro/Filiale, Fileservices, leichte Virtualisierung	Xeon E‑2400 (Beispiel: E‑2488)
Mid‑Range	Web/Container, allgemeine Services	Xeon Silver/Gold oder EPYC 9004 Mid‑Range (Beispiel: EPYC 9254)
High‑Range	High‑Density‑Virtualisierung, OLAP/ETL	Xeon Gold 6430 / EPYC 9334‑Klasse
Ultra / HPC	schwere Analytics, High‑End‑Konsolidierung	Xeon Platinum 8580 / EPYC 9554 und höher

Nützliche Ressourcen

• CPU‑Spezifikationen: Intel ARK und die offiziellen Intel Xeon Scalable‑Seiten.
• AMD EPYC: die offizielle EPYC‑Linie und Generationsseiten für 9004/9005.
• Benchmarks: SPEC (CPU2017) und PassMark (als breite Vergleichsdatenbank).
• Praxis‑Reviews/Community: ServeTheHome, Nischenforen und Subreddits (homelab/sysadmin) — nützlich für reale Fallstricke und Konfigurationen.

FAQ

Q: Was ist der Hauptunterschied zwischen Server‑Prozessoren?
A: Vorhersehbarer 24/7‑Betrieb, ECC‑Arbeitsspeicher, RAS‑Features, mehr Speicherkanäle und PCIe‑Lanes sowie ein längerer Plattform‑Lebenszyklus.

Q: Kann man eine Desktop‑CPU in einem Server verwenden?
A: Technisch manchmal ja — aber meist verlieren Sie ECC/RAS und erhalten geringere Zuverlässigkeit und Kompatibilität, was für Produktion eine schlechte Wette ist. Außerdem unterstützen Server‑CPUs typischerweise deutlich größere RAM‑Kapazitäten. Ein Desktop‑Prozessor kann schneller und günstiger sein als eine Server‑CPU; das wird dort genutzt, wo ECC und Zuverlässigkeit nicht erforderlich sind, aber maximale Performance und niedrige Latenz zählen — z. B. in Handelssystemen (Trading).

Q: Wie viele Kerne braucht man für einen Datenbankserver?
A: OLTP funktioniert oft komfortabel im Bereich 8–32 „schneller“ Kerne; OLAP benötigt häufiger 32–64+ und starken Speicher. Die genaue Antwort kommt nach Profiling.

Q: Was ist wichtiger: Kerne oder Takt?
A: Parallele Aufgaben und hohe Dichte = Kerne/Speicher/PCIe. Latenzkritische Transaktionen = Takt und vorhersehbare Latenz.

Q: Intel oder AMD?
A: AMD liefert oft mehr Speicher/I/O „pro Sockel“ (12 DDR5‑Kanäle und 128 PCIe‑Lanes sind ein starkes Argument).
Intel ist stark im Ökosystem und in der großen Auswahl validierter Hersteller‑Plattformen.

Q: Sollte man ein Top‑Tier‑Modell kaufen?
A: Meistens nein. Mid‑Range bietet typischerweise das beste Preis/Performance/TCO‑Verhältnis, außer Sie haben extreme Anforderungen.

Q: Wie beeinflusst die CPU die Lizenzierung?
A: Wenn ein Produkt pro Kern lizenziert wird, bedeuten mehr Kerne mehr Lizenzen. Manchmal sind weniger, aber leistungsstärkere Kerne kosteneffizienter.

Q: Ein starker Prozessor oder zwei schwächere?
A: Einer ist einfacher und oft besser für Latenz (weniger NUMA). Zwei liefern mehr Speicher/PCIe/Kerne, erfordern aber korrektes Tuning.

Fazit

Die Wahl einer Server‑CPU im Jahr 2026 ist ein Balanceakt aus Performance, Plattform‑Ressourcen (Speicher und PCIe), Preis und zukünftigem Wachstum. Der häufigste Fehler ist, eine CPU „nach Name“ oder „nach Kernanzahl“ zu wählen, ohne zu prüfen, ob der Workload tatsächlich CPU‑gebunden ist. In der Praxis ist ein Server ein System: Speicher, Disks, Networking und PCIe‑Topologie können die Ergebnisse stärker begrenzen als „noch +16 Kerne“.

Der richtige Weg ist, mit dem Profiling des aktuellen Systems zu starten, Metriken in Anforderungen zu übersetzen (Kerne, Takt, Speicher, PCIe), eine Shortlist zu erstellen, Benchmarks und Kompatibilität zu validieren und dann die Optionen nach TCO zu vergleichen — inklusive Strom und potenzieller Lizenzierung. Und planen Sie unbedingt 30–50% Reserve für Wachstum: Ein Server, der „knapp“ dimensioniert ist, wird zum Dauer‑Firefighting‑Projekt.

Wenn Sie die Empfehlungen in diesem Artikel befolgen und Speicher/PCIe/TCO ehrlich durchrechnen, wird die CPU‑Auswahl meist offensichtlich — und, wichtig: gegenüber dem Business mit Zahlen statt „Gefühl“ gut begründbar. Und wenn etwas unklar ist oder Sie weitere Fragen haben, wenden Sie sich an unsere Manager — wir beraten Sie und helfen, das optimale Modell auszuwählen.