Z procesorem serwerowym jest trochę tak, że najłatwiej pomylić się na samym starcie. Najważniejsze, co warto wiedzieć na wejściu: procesor ustawia ekonomię całej infrastruktury, nie tylko jej wydajność. Decyduje, ile maszyn wirtualnych postawisz na hoście, ile zapłacisz za licencje SQL czy VMware, ile prądu pobierze szafa i jak mocno trzeba ją chłodzić. Dlatego dobór CPU to nie jest wybór „z katalogu po liczbach” – to decyzja, która ciągnie za sobą resztę serwera.
I jeszcze jedno, zanim przejdziemy dalej: większość firm nie potrzebuje topowego procesora z setką rdzeni – tylko dobrze dobranego pod swój workload. Zwykle to różnica między przepłaceniem a sprzętem, który po prostu robi robotę.
Najpierw obciążenie – ile mocy naprawdę wynika z Twojego projektu?
Wszystko zaczyna się od jednego pytania: co ten serwer ma liczyć? Bez tego każda konfiguracja to zgadywanie. Profil obciążenia decyduje o tym, czy stawiasz na dużo rdzeni, czy na wysoki zegar – a to dwie różne filozofie, nie dwa warianty tego samego.
W praktyce wygląda to dość przewidywalnie:
- wirtualizacja i dużo VM-ek → dużo rdzeni i dużo kanałów pamięci (kierunek AMD EPYC),
- baza transakcyjna, ERP, aplikacje wrażliwe na opóźnienia → mocny pojedynczy rdzeń i wysoki zegar (kierunek Intel Xeon),
- backup, storage, serwer plików → umiarkowana liczba rdzeni, za to dużo linii PCIe pod dyski i kontrolery RAID,
- rendering, AI/ML, analityka → maksimum rdzeni i pojemny cache.
I tu kluczowa rzecz – to nie jest skala liniowa. Dorzucanie rdzeni ma sens tylko wtedy, gdy masz workload, który je faktycznie wykorzysta. W przeciwnym razie rośnie koszt – sprzętu i, co gorsza, licencji – a nie wydajność.
Dlaczego ten wybór waży więcej, niż się wydaje?
Serwer to nie odizolowany procesor, tylko cała platforma – gniazda, pamięć, komunikacja między CPU, linie PCIe, storage, sieć, licencje i budżet termiczny. CPU siedzi w środku tego wszystkiego i decyduje, ile z reszty da się realnie wykorzystać.
A konsekwencje błędu nie są teoretyczne. Z badania Uptime Institute (2024) wynika, że 54% firm wyceniło swoją ostatnią poważną awarię na ponad 100 000 USD, a co piąta zgłosiła koszty powyżej 1 mln USD. Część tych przestojów bierze się wprost z niedoszacowanej platformy – za mało zasobów na hoście, throttling pod obciążeniem, brak zapasu na godziny szczytu.
Drugi koszt jest znacznie cichszy, ale potrafi zaboleć bardziej: licencje. Źle dobrany procesor podbija rachunek za SQL Server albo VMware mocniej niż jakikolwiek upgrade sprzętu. To najczęściej pomijany element całej układanki – i wrócimy do niego osobno, bo zasługuje na własną sekcję.
Parametry, które naprawdę mają znaczenie – i co z nich wynika dla firmy?
Specyfikacja procesora wygląda jak ściana liczb, ale w praktyce decyduje kilka rzeczy. Reszta to szczegóły.
- Rdzenie vs taktowanie. Dużo rdzeni = gęstość, czyli ile równoległych zadań (VM-ek, kontenerów) host obsłuży naraz. Wysoki zegar = szybkość pojedynczego zadania, czyli jak szybko baza odda odpowiedź. Rzadko potrzebujesz obu naraz – i właśnie dlatego warto zacząć od workloadu.
- Kanały pamięci. To często niedoceniany parametr. 12 kanałów w EPYC daje przy DDR5-4800 ok. 460,8 GB/s przepustowości – o połowę więcej niż klasyczny 8-kanałowy projekt Xeona (nowsze Xeon 6 też idą w 12 kanałów). Przy gęstej wirtualizacji i bazach to realnie czuć.
- Linie PCIe. Decydują, ile podłączysz dysków NVMe, GPU i kart sieciowych 25/100 GbE bez kompromisów. Mało linii = wąskie gardło, którego nie widać w benchmarku CPU.
- TDP i chłodzenie. Mocniejszy procesor to więcej ciepła. Trzeba go dopasować do formatu (1U/2U) i do heatsinka o właściwym TDP – inaczej throttling zje wydajność, za którą zapłaciłeś.
- Zdalne zarządzanie i RAS. iDRAC (Dell) i iLO (HPE), ECC oraz funkcje RAS to nie dodatek, tylko warunek pracy 24/7 bez fizycznego dostępu do serwera.
Pułapki licencyjne – tu firmy tracą najwięcej
To sekcja, którą najczęściej się pomija – i najdrożej za to płaci. Bardzo częsty błąd to minimalizowanie kosztu samego sprzętu, po to żeby chwilę później dostać rachunek za licencje, który przewyższa oszczędność kilkukrotnie.
Trzy rzeczy, które warto wiedzieć, zanim wybierzesz liczbę rdzeni.
- SQL Server liczy per rdzeń. Licencjonujesz każdy fizyczny rdzeń, minimum 4 na procesor, w pakietach 2-rdzeniowych. Procesor z dużą liczbą rdzeni pod lekką bazę = wyrzucone pieniądze.
- Zła konfiguracja VM potrafi marnować połowę licencji. Klasyczny case: maszyna ustawiona na 1 rdzeń na socket – SQL Server Standard widzi tylko pierwsze 4 sockety i z 8 licencjonowanych rdzeni używa połowy. Rozwiązanie jest darmowe: jeden socket z wieloma rdzeniami zamiast wielu socketów po jednym rdzeniu.
- VMware przeszło na model per-rdzeń. Licencje w pakietach 32-rdzeniowych, minimum 16 rdzeni na socket. Dlatego procesory z bardzo wysokim core-count bywają mieczem obosiecznym – dają potencjał konsolidacji, ale prowadzą do „license sprawl”, czyli rachunku rosnącego z każdym rdzeniem.
Wniosek jest prosty: model licencjonowania sprawdzasz zanim wybierzesz liczbę rdzeni, nie po. Przy serwerach pod VMware czy bazy SQL to często ważniejsza decyzja niż sam wybór modelu CPU.
Intel czy AMD – krótko i konkretnie
Oba są dobre. Różnią się tym, w czym są najlepsze – i to powinno decydować, nie marka.
AMD EPYC to dziś gęstość rdzeni, przepustowość pamięci i najlepszy stosunek wydajności do ceny. Dwusocketowy EPYC potrafi dać o 30–40% więcej łącznej mocy niż porównywalny dwusocketowy Xeon, a w jednogniazdowych modelach (jak 7702P) dostajesz więcej rdzeni niż u Intela w konfiguracji dual-socket – bez dublowania płyty, zasilaczy i kontrolera. To naturalny wybór pod wirtualizację, hosting, Big Data i storage.
Intel Xeon odpowiada mocnym single-threadem, dojrzałym ekosystemem i akceleratorami (AMX, QAT). To wybór tam, gdzie liczy się wydajność na rdzeń i niska latencja – bazy transakcyjne, ERP, analityka real-time, środowiska finansowe. Do tego pełne wsparcie ECC, RAS i certyfikaty ISV (VMware, Windows Server, Red Hat), czyli to, na czym buduje się produkcję.
Rozwijamy oba wątki osobno – zajrzyj do procesorów Intel i procesorów AMD, jeśli chcesz konkretne modele pod swój przypadek.
Czego unikać i jaki CPU do czego – tabela decyzyjna
Zanim tabela, krótka lista rzeczy, które najczęściej kończą się przepłaceniem albo wąskim gardłem:
- bardzo wysoki core-count tam, gdzie obowiązuje licencja per-rdzeń, a workload jest lekki,
- procesory desktopowe bez ECC w roli serwera (brak korekcji błędów = ryzyko przy pracy ciągłej),
- baza zależna od single-threada postawiona na CPU z wieloma wolnymi rdzeniami,
- procesory bez wsparcia platformy (microcode/BIOS) – u nas sprzęt jest gotowy do pracy od razu, bez kombinowania.
A teraz najprostszy skrót – jaki procesor pod jakie zastosowanie:
|
Wirtualizacja / dużo VM |
AMD EPYC (dużo rdzeni) |
Gęstość rdzeni i przepustowość pamięci – więcej VM-ek na jeden host |
|
Baza transakcyjna / ERP |
Intel Xeon (mocny zegar) |
Bazy i aplikacje enterprise żyją z wydajności pojedynczego rdzenia |
|
SQL z licencją per-core |
mniej rdzeni, wyższy zegar |
Każdy fizyczny rdzeń to koszt licencji – mniej rdzeni, niższy rachunek |
|
HPC / analityka / Big Data |
AMD EPYC (cache + I/O) |
Ogromny cache L3 i przepustowość I/O pod PostgreSQL, Oracle, MongoDB |
|
Rendering / AI / ML |
high core-count |
Dużo rdzeni i pojemny cache skracają czas renderu i treningu |
|
Hosting / max VM na wat |
Intel (E-core, Sierra Forest) |
Najlepsza gęstość na wat – sensowne pod VPS i hosting |
Procesory serwerowe od Hardware Direct – sprawdzone, gotowe do pracy
U nas nie kupujesz kota w worku. Każdy procesor jest testowany, sprawdzony na zgodność z socketem i płytą główną, objęty gwarancją i pełnym wsparciem – łącznie z dopasowaniem chłodzenia i kompatybilnością RAM. Kilka jednostek, które najczęściej trafiają w punkt:
- Xeon E5-2680 v4 (14C/28T) – sprawdzony koń roboczy do wirtualizacji i baz danych, za ułamek ceny nowego (przykładowo poleasingowo od ok. 162 zł).
- Xeon Silver 4210 (10C/20T) – ERP, serwery plików, backup. Dobry balans rdzeni, TDP i ceny.
- EPYC 7702P (64C/128T) – gęsta wirtualizacja i hosting na jednym sockecie, bez dublowania płyty.
- Xeon Platinum 8168 (24C/48T) – rendering, AI/ML i analiza danych, gdzie liczy się surowa moc.
Nie sprzedajemy samych parametrów – pomagamy dobrać procesor do konkretnego problemu. Jeśli wiesz, co serwer ma robić, dobierzemy CPU, które to udźwignie bez przepłacania.
FAQ
Czy więcej rdzeni zawsze znaczy szybszy serwer?
Nie. Przy zadaniach zależnych od pojedynczego rdzenia (wiele baz, ERP) liczy się zegar, nie liczba rdzeni. Nadmiar rdzeni potrafi się po prostu nudzić – a przy licencjach per-core jeszcze kosztować.
Od czego zacząć dobór procesora?
Od workloadu. Najpierw ustal, co serwer ma robić (wirtualizacja, baza, backup, AI), policz potrzeby RAM i I/O, a dopiero potem dobieraj rdzenie i zegar.
Czy procesor poleasingowy to bezpieczny wybór?
Tak, jeśli jest przetestowany i objęty gwarancją. Serwerowe CPU są projektowane do pracy ciągłej 24/7, a sprawdzona jednostka potrafi dać tę samą wydajność za ułamek ceny nowej.
Intel czy AMD do wirtualizacji?
Najczęściej AMD EPYC – więcej rdzeni i kanałów pamięci oznacza więcej VM-ek na host. Intel Xeon wygrywa tam, gdzie liczy się wydajność pojedynczego rdzenia i niska latencja.
Czy procesor wpływa na koszt licencji?
Bardzo. SQL Server i VMware licencjonują per rdzeń, więc liczba rdzeni przekłada się wprost na rachunek. Model licencjonowania warto sprawdzić zanim wybierzesz core-count.











































































