Intel Xeon vs AMD EPYC: какой процессор выбрать для сервера

Если выбирать серверный процессор без привязки к задаче, сравнение Intel Xeon и AMD EPYC быстро превращается в спор о брендах и числе ядер. На практике выбор обычно сводится к другому: AMD EPYC чаще оказывается особенно выгодным там, где нужны высокая плотность виртуализации, много ядер, большой запас по памяти и линиям PCIe, а Intel Xeon остаётся сильным выбором там, где важны особенности конкретной платформы, широкая экосистема, ускорение отдельных типов нагрузок и баланс не только по ядрам, но и по возможностям всей системы. У AMD EPYC 9005 заявлены модели до 192 ядер, а у Intel Xeon 6 — до 12 каналов памяти, до 192 линий PCIe 5.0 в двухсокетных конфигурациях и поддержка CXL 2.0, поэтому ответ на вопрос “что лучше” всегда зависит от того, какой именно сервер вы собираете и за что готовы платить.

Почему сравнивать Xeon и EPYC “в лоб” — ошибка

Понятное дело, что лучше выбирать то, что лучше впишется в ваш текущий парк и для чего есть готовые запчасти. Если вся инфраструктура построена на Xeon, то стоит подумать брать ли новый сервер c AMD и оценивать риски. Мы рассмотрим вариант, когда идёт выбор абстрактного нового сервера.

Итак, серверный процессор почти никогда не выбирают по одному параметру. Сравнение только по числу ядер, частоте или цене самого CPU вводит в заблуждение, потому что сервер — это не отдельный процессор, а платформа: сокеты, память, межпроцессорный обмен, линии PCIe, накопители, сеть, ускорители, лицензии и тепловой бюджет. Один и тот же “более мощный” CPU может оказаться лишним в веб-сервере, неудобным для лицензируемой базы данных и, наоборот, очень выгодным в плотном узле виртуализации.

Поэтому при выборе Xeon или EPYC нельзя опираться только на:

• число ядер;
• базовую или максимальную частоту;
• результаты одного синтетического теста;
• цену процессора без стоимости платформы;
• бренд и привычку к определённому вендору;
• опыт с предыдущими поколениями;
• предположение, что “для сервера всегда лучше больше сокетов и больше ядер”.

Гораздо полезнее сразу отвечать на другие вопросы: какая будет нагрузка, сколько нужно памяти на узел, сколько NVMe и сетевых портов потребуется, есть ли лицензирование на ядро, чувствительна ли система к задержкам, нужен ли один мощный сервер или несколько более простых. Именно это и определяет, какой процессор окажется лучше в реальной эксплуатации.

В чём базовая разница подходов Intel Xeon и AMD EPYC

Сегодня уже нельзя честно описать рынок формулой “Intel — это только частота, AMD — это только ядра” или тем более "Intel - это хорошо, а AMD - только от нехватки бюджета", ситуация за десятилетия существенно изменилась и теперь обе платформы заметно сложнее. Но общий вектор у них по-прежнему различим. EPYC традиционно силён там, где нужна высокая плотность ресурсов на сокет: много ядер, большой запас по памяти, большое количество подключаемых устройств и хорошая экономика консолидации. AMD прямо позиционирует EPYC 9005 как платформу для облаков, виртуализации, баз данных, аналитики и инфраструктур высокой плотности.

Xeon, в свою очередь, делает ставку не только на вычислительные параметры, но и на платформенные возможности: разные классы процессоров внутри семейства, поддержка развитой экосистемы серверных платформ, межсокетный обмен, CXL, а также специализированные ускорители и функции, полезные для отдельных типов нагрузок. В Xeon 6 Intel отдельно подчёркивает память, I/O, UPI 2.0, CXL 2.0 и встроенные возможности ускорения для части задач, связанных с шифрованием, сжатием, перемещением данных и аналитикой в памяти.

Отсюда и практический вывод: если задача упирается в плотность виртуализации, число виртуальных CPU, объём памяти и насыщенность устройствами, EPYC часто оказывается очень сильным кандидатом. Если же вы строите сервер под конкретную экосистему, определённую платформенную функцию, межсокетную конфигурацию или нагрузки, где важны фирменные возможности платформы Intel, Xeon может быть уместнее.

Что важнее при выборе: ядра, частота, память или ввод-вывод

Самая частая ошибка — искать универсальный ответ. На деле в разных нагрузках “главный” параметр разный.

Если вы строите узел виртуализации, контейнерную платформу, облачный хост или инфраструктурный сервер, где много параллельных задач, число ядер действительно становится одним из ключевых параметров. Чем больше ядер и потоков, тем выше потенциальная плотность размещения, если её не ограничивают память, хранилище и сеть. AMD прямо связывает EPYC 9005 с облачными сценариями и отмечает преимущество по числу виртуальных CPU в старших моделях.

Если сервер нужен под часть баз данных, корпоративные приложения, 1С-подобные нагрузки, транзакционные системы и сервисы, чувствительные к задержкам, часто важнее не максимум ядер, а производительность одного ядра, стабильная частота под нагрузкой и общая сбалансированность платформы. Здесь уже недостаточно смотреть на количество CPU-ресурсов “в лоб”: задача может плохо масштабироваться по ядрам и при этом выигрывать от более высокой производительности на поток.

Если планируется тяжёлая работа с памятью — аналитика, большие базы данных, кэширование, плотная виртуализация, — процессор надо оценивать через подсистему памяти: число каналов, режим заполнения модулей, объём на сокет и реальную пропускную способность. Для Xeon 6 Intel указывает до 12 каналов памяти и отдельно подчёркивает высокую пропускную способность как ключевую характеристику семейства. Для EPYC 9005 AMD также акцентирует внимание на памяти и ёмкости платформы как на части своего позиционирования для облака и дата-центров.

Если сервер должен не только считать, но и работать с большим числом NVMe-накопителей, быстрыми сетевыми картами, контроллерами хранения и ускорителями, в игру вступает ввод-вывод. У Xeon 6 Intel заявляет до 192 линий PCIe 5.0 в двухсокетных конфигурациях и до 64 линий CXL 2.0. Это делает тему PCIe не второстепенной, а центральной для современных серверов хранения, гиперконвергентных узлов и систем с ускорителями.

Что критично для разных типов нагрузки

Один сокет или два: где начинается реальная разница

Во многих проектах главный вопрос уже не “Intel или AMD”, а “одного сокета достаточно или нужен двухсокетный сервер”. И здесь современные EPYC и Xeon сильно изменили правила игры.

Односокетный сервер хорош тем, что он проще. В нём нет межсокетного обмена, ниже сложность охлаждения, проще плата, часто лучше экономическая эффективность, а главное — меньше риск получить систему, где теоретическая мощность высока, а на практике часть нагрузки теряет производительность из-за удалённого доступа к памяти и неудачного распределения задач между сокетами. Это особенно важно там, где один современный CPU уже закрывает потребность по ядрам, памяти и устройствам ввода-вывода.

Двухсокетная система остаётся оправданной, когда нужен действительно большой объём памяти, очень высокая плотность виртуализации, тяжёлая консолидация нескольких ролей на одном узле или конфигурация, которую один сокет не закрывает по вычислениям и расширяемости. Но два процессора — это не “автоматически вдвое лучше”. Возникает NUMA: память и ядра становятся топологически неравномерными, и если гипервизор, база данных или прикладной стек размещены неудачно, часть запросов начинает ходить к памяти “через соседний процессор”, что ухудшает задержки и снижает предсказуемость производительности.

Для Xeon 6 Intel отдельно указывает рост межсокетной пропускной способности UPI 2.0 до 24 GT/s, то есть сама компания подчёркивает важность межпроцессорного обмена как одного из фундаментальных параметров платформы, а не второстепенной детали.

Практически это означает следующее.

Один сокет чаще всего стоит выбирать, если:

• один CPU уже даёт достаточно ядер;
• хватает памяти на узел;
• нужно много PCIe-устройств, но без экстремального масштаба;
• важны простота, энергоэффективность и более прозрачная настройка;
• нет причин усложнять систему ради “запаса”, который может не понадобиться.

Два сокета чаще оправданы, если:

• нужен очень большой объём памяти;
• сервер будет нести несколько тяжёлых ролей одновременно;
• требуется максимальная плотность виртуализации на одном узле;
• один сокет не закрывает потребность по CPU и расширяемости;
• есть понимание, как управлять NUMA и не потерять производительность на топологии.

Виртуализация: здесь разница ощущается особенно сильно

Узел виртуализации — один из самых честных способов сравнить Xeon и EPYC, потому что здесь быстро видна не только “вычислительная мощность”, но и вся архитектура сервера. Виртуальным машинам нужны ядра, память, пропускная способность памяти, быстрый ввод-вывод и сеть. Если чего-то одного не хватает, остальное перестаёт давать ожидаемый прирост.

Именно поэтому EPYC часто выглядит очень привлекательно в таких сценариях: большое число ядер помогает поднять плотность ВМ, а акцент на ресурсы платформы делает возможными насыщенные конфигурации на одном узле. AMD прямо пишет о плотности и облачных сценариях как о сильной стороне EPYC 9005.

Но важно не попасть в ловушку “чем больше ядер, тем лучше гипервизор”. Если память закончится раньше, чем ядра, вы получите недоиспользованный процессор. Если упрётесь в сеть, массив или контроллеры, вычислительный запас тоже не превратится в полезную плотность. Если у вас лицензируемые гостевые системы или базы данных внутри виртуальных машин, избыток ядер может ещё и ухудшить экономику.

Отдельный практический момент — SQL Server в виртуализированной среде. Microsoft прямо указывает лимиты вычислительной ёмкости по редакциям и отмечает, что Standard Edition ограничен меньшим из двух значений: 4 сокета или 32 ядра, а для SQL Server 2022 и более ранних версий — 4 сокета или 24 ядра. Это значит, что при проектировании виртуализированного узла нельзя бездумно гнаться за максимумом ядер, если в нём будут жить лицензируемые экземпляры SQL Server.

Базы данных и лицензируемое ПО: здесь ошибка стоит особенно дорого

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

Есть два разных сценария. Первый — когда база данных или приложение чувствительны к производительности одного ядра, к задержкам, к пропускной способности памяти и качеству всей платформы. В этом случае слепая ставка на максимум ядер может почти не дать выигрыша. Второй — когда ПО лицензируется по ядрам, процессорам или вычислительной ёмкости. Здесь лишние ядра могут прямо увеличить стоимость владения.

Microsoft для SQL Server очень ясно показывает, что редакции отличаются по пределам вычислительной ёмкости. Для Standard Edition есть предел “меньшее из 4 сокетов или 32 ядер”, а для SQL Server 2022 и более ранних версий — “меньшее из 4 сокетов или 24 ядер”; у Enterprise при core-based licensing таких ограничений нет. Это не просто формальность из документации. Это означает, что при части сценариев сервер с более умеренным числом ядер может оказаться рациональнее, чем максимально ядерная конфигурация, которую конкретная редакция всё равно не использует полностью.

Oracle идёт ещё дальше в сторону связи железа и лицензирования. В документе по Database Licensing компания прямо указывает, что число требуемых лицензий по Processor metric рассчитывается через общее число ядер и коэффициент из Processor Core Factor Table. То есть выбор аппаратной платформы здесь влияет на затраты не косвенно, а напрямую.

Как лицензирование меняет выбор

Практический вывод здесь очень простой: чем дороже лицензия, тем опаснее выбирать процессор “с максимальным запасом”.

Память: раздел, который часто недооценивают

О серверном CPU часто говорят так, будто он работает сам по себе. В реальной инфраструктуре это почти никогда не так. У виртуализации, баз данных, аналитики, кэшей, распределённых хранилищ и многих инфраструктурных сервисов производительность упирается в память раньше, чем кажется на этапе выбора железа.

Для Xeon 6 Intel заявляет до 12 каналов памяти и отдельно подчёркивает пропускную способность как одно из ключевых достоинств семейства. AMD для EPYC 9005 также позиционирует платформу как решение для нагрузок, где важны ёмкость и пропускная способность памяти.

Но из этого не следует, что “если можно поставить много памяти, всё будет хорошо”. На практике важны:

• сколько каналов реально задействовано;
• сколько модулей установлено на канал;
• на какой скорости память работает в данной конфигурации;
• какой объём приходится на сокет;
• как нагрузка чувствует себя в NUMA-топологии.

Типичная ошибка — купить CPU с большим числом ядер, а затем сэкономить на памяти или собрать конфигурацию, где слоты заполнены не так, как нужно для оптимальной пропускной способности. В итоге узким местом становится не процессор, а память, и спор “Xeon или EPYC” теряет смысл: обе платформы будут страдать от плохой конфигурации.

PCIe, NVMe, сеть и ускорители: иногда платформа важнее самого CPU

Старый подход “главное — ядра и частота” всё хуже работает в современных серверах. Сегодня сервер часто является узлом обработки, хранения и передачи данных одновременно. Он должен не только считать, но и принимать поток по сети, работать с массивом NVMe, обслуживать гипервизор, распределять нагрузку между контейнерами или взаимодействовать с ускорителями.

Здесь значение имеют линии PCIe, топология подключения устройств и общий запас платформы по расширению. Intel в Xeon 6 указывает до 192 линий PCIe 5.0 для двухсокетных систем и до 64 линий CXL 2.0, включая сценарии расширения памяти и подключения устройств разных типов.

Отсюда несколько практических выводов.

Если вы строите сервер:

• с большим числом NVMe;
• под гиперконвергентную инфраструктуру;
• с несколькими скоростными сетевыми картами;
• с ускорителями;
• под программно-определяемое хранилище,

то выбирать процессор без учёта PCIe и схемы ввода-вывода нельзя. Более “быстрый” CPU на бумаге может проиграть просто потому, что платформа неудобна для насыщенной конфигурации устройств. И наоборот: иногда выигрыш даёт не более сильное ядро, а более удачное распределение ресурсов по шинам, памяти и контроллерам.

Энергопотребление, тепло и реальная стоимость владения

Процессор — это только одна строка в бюджете сервера. Реальная стоимость владения включает гораздо больше: цену платформы, память, накопители, сетевые карты, лицензии, энергопотребление, охлаждение, стойко-место, сопровождение и сценарий роста на несколько лет.

Именно поэтому два частых подхода одинаково опасны. Первый — выбрать “максимум ядер на всякий случай”. Второй — взять CPU подешевле, не посчитав, сколько серверов потом придётся докупать, чтобы закрыть тот же объём задач. В одном случае вы переплачиваете сразу и, возможно, ещё и за лицензии. В другом — теряете на масштабе, потреблении, стойках и операционной сложности.

Intel в Xeon 6 указывает тепловой пакет до 500 Вт на CPU в отдельных конфигурациях, что само по себе напоминает: современные серверные процессоры уже нельзя оценивать вне контекста охлаждения и энергетики.

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

Когда чаще смотреть в сторону Intel Xeon, а когда — AMD EPYC

Когда чаще имеет смысл выбирать Intel Xeon

Xeon обычно особенно интересен в случаях, когда:

• важны особенности конкретной серверной платформы и экосистемы;
• проект опирается на привычную инфраструктуру определённого вендора;
• нужны функции CXL, межсокетного обмена и платформенные возможности Intel;
• есть нагрузка, которой полезны специализированные ускорители Intel, включая QAT, DSA, IAA и AMX;
• важен не рекорд по ядрам, а определённый баланс платформы, памяти, I/O и встроенных функций.

Когда чаще имеет смысл выбирать AMD EPYC

EPYC особенно часто выглядит сильным выбором, когда:

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

Важно не превращать эти рекомендации в догму. Они описывают типичные сильные стороны, а не заменяют расчёт под конкретный сервер.

Типичные ошибки при выборе

Больше всего проблем возникает не из-за “неудачного бренда”, а из-за неверной логики выбора. Чаще всего ошибаются так:

• выбирают по бренду, а не по нагрузке;
• сравнивают только число ядер;
• игнорируют лицензирование;
• не считают память и ввод-вывод;
• покупают сервер “на вырост”, не понимая цену этого роста;
• недооценивают NUMA в двухсокетных системах;
• делают выводы по одному тесту;
• сравнивают старое поколение одной платформы с новым поколением другой;
• считают только цену CPU, а не цену всей конфигурации.

Самая дорогая ошибка — перепутать “мощнее” и “лучше для задачи”. Это разные вещи.

Как принять решение без ошибки

Надёжный алгоритм выбора выглядит так.

Сначала надо определить тип нагрузки: виртуализация, база данных, хранилище, инфраструктурный сервер, контейнерная платформа, лицензируемое приложение. Затем понять, что для неё важнее: производительность одного ядра, общее число ядер, память, линии PCIe или их сочетание. После этого проверить модель лицензирования: нет ли ограничений по сокетам, ядрам или редакциям ПО. Дальше — решить, нужен один сокет или два, посчитать память с запасом на рост, оценить число NVMe, сетевых карт и других устройств, проверить тепловой и энергетический бюджет, а потом сравнивать уже не процессоры сами по себе, а готовые серверные конфигурации. Именно такой порядок почти всегда даёт более точный выбор, чем спор о том, “кто сильнее вообще”.

Вывод

AMD EPYC и Intel Xeon сегодня решают один и тот же класс задач, но делают это с разными акцентами. EPYC особенно силён там, где важны высокая плотность, много ядер, ресурсоёмкий односокетный узел, облачная консолидация и насыщенность по памяти и устройствам. Xeon остаётся очень сильной платформой там, где важны экосистема, межсокетные конфигурации, платформенные функции Intel, CXL и встроенные ускорители для отдельных типов нагрузок. У AMD EPYC 9005 акцент сделан на плотность и масштабирование, а у Intel Xeon 6 — на память, I/O, CXL, UPI и специализированные возможности платформы. Поэтому правильный ответ на вопрос “что выбрать для сервера” звучит так: не Xeon или EPYC вообще, а та платформа, которая лучше совпадает с вашей нагрузкой, лицензиями, схемой масштабирования и полной экономикой сервера.