Mit einem Server-Prozessor ist es ein bisschen so, dass man sich am leichtesten gleich zu Beginn vertut. Das Wichtigste, was man von Anfang an wissen sollte: Der Prozessor bestimmt die Ökonomie der gesamten Infrastruktur, nicht nur ihre Leistung. Er entscheidet, wie viele virtuelle Maschinen du auf einem Host aufsetzt, wie viel du für SQL- oder VMware-Lizenzen zahlst, wie viel Strom der Schrank zieht und wie stark er gekühlt werden muss. Deshalb ist die Wahl der CPU keine Entscheidung „nach Zahlen aus dem Katalog“ – es ist eine Entscheidung, die den Rest des Servers nach sich zieht.
Und noch etwas, bevor wir weitergehen: Die meisten Firmen brauchen keinen Spitzenprozessor mit hundert Kernen – sondern einen, der gut auf ihre Workload abgestimmt ist. Meist ist das der Unterschied zwischen zu viel bezahlen und Hardware, die einfach ihren Job macht.
Zuerst die Last – wie viel Leistung ergibt sich wirklich aus deinem Projekt?
Alles beginnt mit einer Frage: Was soll dieser Server berechnen? Ohne das ist jede Konfiguration Raten. Das Lastprofil entscheidet, ob du auf viele Kerne oder auf hohen Takt setzt – und das sind zwei unterschiedliche Philosophien, nicht zwei Varianten desselben.
In der Praxis sieht das ziemlich vorhersehbar aus:
- Virtualisierung und viele VMs → viele Kerne und viele Speicherkanäle (Richtung AMD EPYC),
- transaktionale Datenbank, ERP, latenzempfindliche Anwendungen → starker Einzelkern und hoher Takt (Richtung Intel Xeon),
- Backup, Storage, Dateiserver → moderate Kernanzahl, dafür viele PCIe-Lanes für Laufwerke und RAID-Controller,
- Rendering, AI/ML, Analytik → maximale Kernanzahl und großzügiger Cache.
Und hier das Entscheidende – das ist keine lineare Skala. Kerne hinzuzufügen ergibt nur dann Sinn, wenn du eine Workload hast, die sie auch tatsächlich nutzt. Andernfalls steigen die Kosten – der Hardware und, schlimmer noch, der Lizenzen – und nicht die Leistung.
Warum wiegt diese Wahl mehr, als es scheint?
Ein Server ist kein isolierter Prozessor, sondern eine ganze Plattform – Sockets, Speicher, Kommunikation zwischen CPUs, PCIe-Lanes, Storage, Netzwerk, Lizenzen und Wärmebudget. Die CPU sitzt mitten in all dem und entscheidet, wie viel vom Rest sich real nutzen lässt.
Und die Folgen eines Fehlers sind nicht theoretisch. Eine Untersuchung des Uptime Institute (2024) zeigt, dass 54 % der Firmen ihren letzten schweren Ausfall auf über 100.000 USD bezifferten und jede fünfte Kosten von über 1 Mio. USD meldete. Ein Teil dieser Ausfälle stammt direkt aus einer unterdimensionierten Plattform – zu wenige Ressourcen auf dem Host, Throttling unter Last, keine Reserve für die Spitzenstunden.
Die zweite Kostenstelle ist deutlich leiser, kann aber stärker schmerzen: die Lizenzen. Ein schlecht gewählter Prozessor treibt die Rechnung für SQL Server oder VMware stärker hoch als jedes Hardware-Upgrade. Das ist das am häufigsten übersehene Element des ganzen Puzzles – und wir kommen darauf noch gesondert zurück, denn es verdient einen eigenen Abschnitt.
Parameter, die wirklich zählen – und was daraus für die Firma folgt
Die Prozessorspezifikation sieht aus wie eine Wand aus Zahlen, aber in der Praxis entscheiden einige wenige Dinge. Der Rest sind Details.
- Kerne vs. Takt. Viele Kerne = Dichte, also wie viele parallele Aufgaben (VMs, Container) der Host gleichzeitig bewältigt. Hoher Takt = Geschwindigkeit einer einzelnen Aufgabe, also wie schnell die Datenbank eine Antwort liefert. Selten brauchst du beides zugleich – und genau deshalb lohnt es sich, mit der Workload zu beginnen.
- Speicherkanäle. Ein oft unterschätzter Parameter. 12 Kanäle im EPYC liefern bei DDR5-4800 ca. 460,8 GB/s Durchsatz – um die Hälfte mehr als ein klassisches 8-kanaliges Xeon-Design (neuere Xeon 6 gehen ebenfalls in Richtung 12 Kanäle). Bei dichter Virtualisierung und Datenbanken spürt man das real.
- PCIe-Lanes. Sie entscheiden, wie viele NVMe-Laufwerke, GPUs und 25/100-GbE-Netzwerkkarten du ohne Kompromisse anschließt. Wenige Lanes = ein Flaschenhals, den man im CPU-Benchmark nicht sieht.
- TDP und Kühlung. Ein stärkerer Prozessor bedeutet mehr Wärme. Er muss zum Formfaktor (1U/2U) und zu einem Kühlkörper mit passendem TDP abgestimmt werden – sonst frisst Throttling die Leistung, für die du bezahlt hast.
- Remote-Management und RAS. iDRAC (Dell) und iLO (HPE), ECC sowie RAS-Funktionen sind kein Zusatz, sondern die Voraussetzung für den 24/7-Betrieb ohne physischen Zugriff auf den Server.
Lizenzfallen – hier verlieren Firmen am meisten
Das ist der Abschnitt, der am häufigsten übersprungen wird – und den man am teuersten bezahlt. Ein sehr häufiger Fehler ist es, die Kosten der Hardware selbst zu minimieren, um kurz darauf eine Lizenzrechnung zu bekommen, die die Ersparnis um ein Vielfaches übersteigt.
Drei Dinge, die du wissen solltest, bevor du die Kernanzahl wählst.
- SQL Server rechnet pro Kern ab. Du lizenzierst jeden physischen Kern, mindestens 4 pro Prozessor, in 2-Kern-Paketen. Ein Prozessor mit vielen Kernen unter einer leichten Datenbank = weggeworfenes Geld.
- Eine falsche VM-Konfiguration kann die Hälfte der Lizenzen verschwenden. Klassischer Fall: eine Maschine, eingestellt auf 1 Kern pro Socket – SQL Server Standard sieht nur die ersten 4 Sockets und nutzt von 8 lizenzierten Kernen die Hälfte. Die Lösung ist kostenlos: ein Socket mit vielen Kernen statt vieler Sockets mit je einem Kern.
- VMware ist auf ein Modell pro Kern umgestiegen. Lizenzen in 32-Kern-Paketen, mindestens 16 Kerne pro Socket. Deshalb sind Prozessoren mit sehr hoher Kernanzahl bisweilen ein zweischneidiges Schwert – sie bieten Konsolidierungspotenzial, führen aber zu „license sprawl“, also einer Rechnung, die mit jedem Kern wächst.
Das Fazit ist einfach: Das Lizenzmodell prüfst du, bevor du die Kernanzahl wählst, nicht danach. Bei Servern für VMware oder SQL-Datenbanken ist das oft eine wichtigere Entscheidung als die Wahl des CPU-Modells selbst.
Intel oder AMD – kurz und konkret
Beide sind gut. Sie unterscheiden sich darin, worin sie am besten sind – und das sollte entscheiden, nicht die Marke.
AMD EPYC steht heute für Kerndichte, Speicherdurchsatz und das beste Preis-Leistungs-Verhältnis. Ein Dual-Socket-EPYC kann 30–40 % mehr Gesamtleistung liefern als ein vergleichbarer Dual-Socket-Xeon, und in Single-Socket-Modellen (wie dem 7702P) bekommst du mehr Kerne als bei Intel in einer Dual-Socket-Konfiguration – ohne Board, Netzteile und Controller zu verdoppeln. Das ist die natürliche Wahl für Virtualisierung, Hosting, Big Data und Storage.
Intel Xeon antwortet mit starkem Single-Thread, einem reifen Ökosystem und Beschleunigern (AMX, QAT). Das ist die Wahl dort, wo Leistung pro Kern und niedrige Latenz zählen – transaktionale Datenbanken, ERP, Echtzeit-Analytik, Finanzumgebungen. Dazu volle Unterstützung von ECC, RAS und ISV-Zertifikaten (VMware, Windows Server, Red Hat), also das, worauf man Produktion aufbaut.
Wir vertiefen beide Themen gesondert – schau bei den Intel-Prozessoren und den AMD-Prozessoren vorbei, wenn du konkrete Modelle für deinen Fall möchtest.
Was zu vermeiden ist und welche CPU wofür – Entscheidungstabelle
Vor der Tabelle eine kurze Liste der Dinge, die am häufigsten mit zu hohen Kosten oder einem Flaschenhals enden:
- sehr hohe Kernanzahl dort, wo eine Lizenz pro Kern gilt und die Workload leicht ist,
- Desktop-Prozessoren ohne ECC in der Serverrolle (keine Fehlerkorrektur = Risiko im Dauerbetrieb),
- eine Single-Thread-abhängige Datenbank, aufgesetzt auf einer CPU mit vielen langsamen Kernen,
- Prozessoren ohne Plattformunterstützung (Microcode/BIOS) – bei uns ist die Hardware sofort einsatzbereit, ohne Herumbasteln.
Und jetzt die einfachste Abkürzung – welcher Prozessor für welchen Einsatz:
|
Einsatz |
Empfehlung |
Warum |
|---|---|---|
|
Virtualisierung / viele VMs |
AMD EPYC (viele Kerne) |
Kerndichte und Speicherdurchsatz – mehr VMs auf einem Host |
|
Transaktionale Datenbank / ERP |
Intel Xeon (hoher Takt) |
Enterprise-Datenbanken und -Anwendungen leben von der Leistung eines einzelnen Kerns |
|
SQL mit Lizenz pro Kern |
weniger Kerne, höherer Takt |
Jeder physische Kern ist ein Lizenzkostenfaktor – weniger Kerne, niedrigere Rechnung |
|
HPC / Analytik / Big Data |
AMD EPYC (Cache + I/O) |
Riesiger L3-Cache und I/O-Durchsatz für PostgreSQL, Oracle, MongoDB |
|
Rendering / AI / ML |
high core-count |
Viele Kerne und großzügiger Cache verkürzen Render- und Trainingszeit |
|
Hosting / max. VM pro Watt |
Intel (E-Core, Sierra Forest) |
Beste Dichte pro Watt – sinnvoll für VPS und Hosting |
Server-Prozessoren von Hardware Direct – geprüft, einsatzbereit
Bei uns kaufst du nicht die Katze im Sack. Jeder Prozessor wird getestet, auf Kompatibilität mit Socket und Mainboard geprüft, mit Garantie und vollem Support versehen – inklusive Abstimmung der Kühlung und RAM-Kompatibilität. Einige Einheiten, die am häufigsten ins Schwarze treffen:
- Xeon E5-2680 v4 (14C/28T) – ein bewährtes Arbeitspferd für Virtualisierung und Datenbanken, für einen Bruchteil des Neupreises (beispielsweise gebraucht ab ca. 162 zł).
- Xeon Silver 4210 (10C/20T) – ERP, Dateiserver, Backup. Eine gute Balance aus Kernen, TDP und Preis.
- EPYC 7702P (64C/128T) – dichte Virtualisierung und Hosting auf einem Socket, ohne das Board zu verdoppeln.
- Xeon Platinum 8168 (24C/48T) – Rendering, AI/ML und Datenanalyse, wo rohe Leistung zählt.
Wir verkaufen nicht bloße Parameter – wir helfen, den Prozessor auf ein konkretes Problem abzustimmen. Wenn du weißt, was der Server tun soll, wählen wir eine CPU, die das trägt, ohne dass du zu viel zahlst.
FAQ
Bedeuten mehr Kerne immer einen schnelleren Server?
Nein. Bei Aufgaben, die von einem einzelnen Kern abhängen (viele Datenbanken, ERP), zählt der Takt, nicht die Kernanzahl. Ein Überschuss an Kernen kann sich schlicht langweilen – und bei Lizenzen pro Kern zusätzlich Geld kosten.
Womit beginnt man bei der Prozessorwahl?
Mit der Workload. Lege zuerst fest, was der Server tun soll (Virtualisierung, Datenbank, Backup, AI), berechne den Bedarf an RAM und I/O, und wähle erst danach Kerne und Takt.
Ist ein gebrauchter (Leasingrückläufer) Prozessor eine sichere Wahl?
Ja, wenn er getestet und mit Garantie versehen ist. Server-CPUs sind für den Dauerbetrieb 24/7 ausgelegt, und eine geprüfte Einheit kann dieselbe Leistung für einen Bruchteil des Neupreises liefern.
Intel oder AMD für Virtualisierung?
Meist AMD EPYC – mehr Kerne und Speicherkanäle bedeuten mehr VMs pro Host. Intel Xeon gewinnt dort, wo die Leistung eines einzelnen Kerns und niedrige Latenz zählen.
Beeinflusst der Prozessor die Lizenzkosten?
Sehr. SQL Server und VMware lizenzieren pro Kern, also schlägt sich die Kernanzahl direkt in der Rechnung nieder. Das Lizenzmodell sollte man prüfen, bevor man die Kernanzahl wählt.




















































































