Xeon vs EPYC

Xeon vs EPYC - как серверный процессор выбирают люди, которые потом за него отвечают

Выбор между Intel и AMD в серверной инфраструктуре редко начинается с вопроса «что быстрее». Обычно всё выглядит намного приземлённее.

Сначала приходит задача. Например, нужно собрать кластер виртуализации под Proxmox, или сервер под Microsoft SQL, или инфраструктуру под 1С, которая живёт уже десять лет и боится любых изменений.

Потом открывается калькулятор лицензий. Затем появляется инженер по охлаждению и говорит, что стойки уже перегружены. И только после этого начинается разговор про процессоры.

И вот тут становится ясно - EPYC и Xeon отличаются не скоростью. Они отличаются философией построения инфраструктуры.

Почему хостинг-провайдеры массово пересели на EPYC

Если вы арендуете VPS или выделенный сервер, очень высокая вероятность, что он работает на AMD. Причина максимально скучная - экономика.

EPYC позволяет запихнуть больше виртуальных машин в один физический сервер. Причём не в лабораторных тестах, а в реальной жизни.

Например, при построении узлов под Proxmox или OpenStack EPYC обычно позволяет разместить больше контейнеров и виртуальных машин без перегрузки памяти и NUMA-узлов. Это не магия, просто у AMD больше ядер и выше пропускная способность памяти.

Именно поэтому EPYC стал любимцем облаков. Когда платформа продаёт ресурсы по виртуальным ядрам, плотность вычислений напрямую превращается в прибыль.

Но есть один нюанс, который редко обсуждают в маркетинговых сравнениях. Большое количество ядер усложняет балансировку нагрузки. Если гипервизор настроен плохо, сервер может начать работать не быстрее, а наоборот - менее предсказуемо.

Где Xeon неожиданно остаётся удобнее

Теперь неприятная правда, которую редко любят фанаты AMD.

В инфраструктуре под 1С Xeon всё ещё часто показывает более стабильную производительность. Не потому что быстрее архитектурно, а потому что сама 1С исторически оптимизировалась под высокую частоту ядра, а не под массовый параллелизм.

Похожая история встречается с Microsoft SQL Server. На EPYC он работает отлично, но иногда требует более аккуратной настройки NUMA и распределения памяти. Если всё настроено правильно - разницы почти нет. Если нет - база может начать вести себя странно.

И да, это как раз тот случай, где опыт администратора важнее модели процессора.

Лицензирование - место, где всё сложнее, чем кажется

Есть популярный миф, что EPYC автоматически делает лицензии дороже из-за большого количества ядер. Это правда только наполовину.

SQL Server, Oracle и Windows Server действительно лицензируются по ядрам. Но никто не запрещает отключать ядра в BIOS или брать младшие модели EPYC с высокой частотой и небольшим числом ядер. Например, линейка F-серии у AMD как раз создана для задач, где важна частота, а не массовый параллелизм.

Настоящая разница появляется в другом месте.

Когда сервер строится под виртуализацию, EPYC часто позволяет заменить два старых узла одним новым. И вот здесь лицензия Datacenter может оказаться дороже на один сервер, но дешевле на инфраструктуру в целом.

Это тот случай, когда архитекторы считают не стоимость процессора, а стоимость одной виртуальной машины.

NUMA - тема, про которую забывают почти все

Один из самых частых сюрпризов при переходе на EPYC связан с архитектурой NUMA. У AMD она более выражена из-за чиплетной структуры.

Если гипервизор или база данных плохо учитывает NUMA-топологию, сервер может показывать нестабильную производительность. Особенно это проявляется в старых версиях VMware.

Современные гипервизоры с этим работают нормально, но если инфраструктура обновляется постепенно, переход на EPYC иногда требует пересборки архитектуры виртуальных машин.

Xeon в этом плане проще. Он традиционно показывает более предсказуемую топологию памяти и межъядерного взаимодействия.

PCIe и NVMe - место, где EPYC часто ломает архитектуру серверов

Если сервер строится под хранение данных или GPU-нагрузки, количество PCIe линий начинает играть огромную роль.

EPYC позволяет подключать больше NVMe-дисков напрямую. Это уменьшает количество RAID-контроллеров и упрощает архитектуру хранения.

В системах хранения это иногда позволяет убрать целый слой оборудования. А каждый убранный слой - это минус одна точка отказа.

Энергопотребление - тема, которую начинают понимать только после роста инфраструктуры

Пока серверов два или три, электричество почти никто не считает. Когда их становится несколько десятков, ситуация резко меняется.

EPYC обычно показывает лучшую эффективность при полной загрузке. Но если сервер простаивает большую часть времени, разница может исчезать.

Здесь многое зависит от сценария использования. Облачные платформы выигрывают от энергоэффективности AMD. Корпоративные серверы с переменной нагрузкой часто показывают сопоставимые показатели.

Где EPYC объективно сильнее

Он почти всегда выигрывает, когда нужно разместить максимальное количество рабочих нагрузок на одном сервере. Это виртуализация, контейнерные платформы, хостинг, аналитика и системы хранения.

Если задача - построить вычислительный кластер с высокой плотностью, EPYC почти всегда выглядит рациональнее.

Где Xeon остаётся безопасным выбором

Xeon чаще выбирают, когда инфраструктура завязана на старые корпоративные системы, строгие стандарты совместимости или программное обеспечение, которое годами тестировалось именно на Intel.

Иногда Xeon берут просто потому, что компания не хочет менять архитектуру, которая уже работает.

И это, кстати, абсолютно рациональное решение. Самый дорогой сервер - тот, который ломает бизнес-процессы.

Самая частая ошибка при выборе CPU

Многие пытаются выбрать процессор по тестам производительности. В реальных проектах гораздо важнее предсказуемость нагрузки, лицензирование и стоимость эксплуатации.

EPYC обычно выигрывает в плотности вычислений. Xeon чаще выигрывает в совместимости и стабильности внедрения.

Самый честный вывод

EPYC - инструмент для масштабирования инфраструктуры.

Xeon - инструмент для консервативных корпоративных систем.

Лучший процессор - не тот, который быстрее в тестах, а тот, который дешевле обслуживать в течение жизненного цикла сервера.