Привет! На связи Максим Башмаков. Мы в Selectel производим, собираем и внедряем в продакшен серверы на Intel^® Xeon^® 6, используя обе архитектуры: P-ядра (Granite Rapids) и E-ядра (Sierra/Clearwater Forest). Я руковожу лабораторией тестирования «железа», и наша задача — выявлять истинные характеристики оборудования, которые, как показывают наши исследования, далеко не всегда совпадают с маркетинговыми заявлениями вендоров.

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

Содержание
→ История Xeon® 6
→ Применимость
→ Зачем вообще Intel «разделил» Xeon® 6
→ Куда смотрят облака
→ Почему универсальные CPU перестали быть оптимальными
→ Типовые ошибки при выборе сервера или CPU
→ Бенчмарки
→ Заключение

История Xeon® 6

Начнем с небольшой предыстории. Первыми на рынок вышла архитектура Intel Sierra Forest — процессоры Intel^® Xeon^® 6 на базе E-ядер (Efficiency Cores). Их ключевое отличие от предыдущих поколений Xeon^® — отсутствие Hyper-Threading и поддержки инструкций AVX-512. В технические подробности углубляться не станем, вся информация есть в официальных спецификациях Intel.

Процессоры Xeon^® 6 с E-ядрами позиционируются как энергоэффективные решения, оптимизированные под высокую плотность вычислений. Ориентированы они на нагрузки, не требующие максимальной производительности на один поток.

Типичные примеры таких задач:

• микросервисы и приложения в контейнерах;

• облачные и edge-платформы;

• веб-сервисы, CDN и кэширование;

• сетевые и коммуникационные задачи.

Бизнес-требования, под которые Intel создавала эту серию, продиктованы в первую очередь экономикой современных ЦОД.

Ключевая цель — снижение совокупной стоимости владения (TCO). Достигается она прямым путем: за счет значительной экономии электроэнергии и, как следствие, снижения затрат на охлаждение.

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

Наконец, эти процессоры должны быть универсальными для типовых веб-сервисов. Тот факт, что в них отсутствует поддержка AVX-512 (расширенных векторных вычислений) — осознанный компромисс. Предполагается, что для целевых нагрузок этот недостаток с избытком компенсируется огромным количеством доступных ядер.

Таким образом, наш вывод: Xeon^® 6 на E-ядрах лучше всего подходит для инфраструктуры, где приоритет отдается плотности, энергоэффективности и простоте масштабирования. Именно с этими процессорами мы анонсировали свою новую серверную платформу, и результаты нашего тестирования, о которых пойдет речь далее, оказались весьма позитивными.

Следом мы ждали релиза P-ядер (Performance Cores), известных под кодовым названием Granite Rapids. В отличие от E-ядер, P-ядра ориентированы на максимальную производительность в расчете на одно ядро и поддержку сложных вычислительных инструкций.

Основные отличия P-ядер от E-ядер:

• поддержка Hyper-Threading;

• наличие AVX-512 и AMX (Advanced Matrix Extensions), что критически важно для задач ИИ, машинного обучения и высокопроизводительных вычислений (HPC);

• более высокая тактовая частота и увеличенные объемы кэш-памяти.

Собственный сервер Selectel

В основе — самые современные процессоры Intel^® Xeon^® 6, до 8 ТБ DDR5 и специально разработанная материнская плата. Арендуйте сервер у нас или закажите в свой дата-центр.

Узнать подробности →

Применимость

Модели Intel^® Xeon^® 6 с P-ядрами — решения, созданные для самых требовательных и критически важных корпоративных нагрузок. С точки зрения бизнеса, они отвечают трем ключевым требованиям:

• максимальной производительности на каждое отдельное ядро;

• полной поддержке современных инструкций для ИИ и машинного обучения;

• гибкости масштабирования.

Эти требования напрямую определяют их сферу применения:

• HPC — поддержка инструкций AMX и AVX-512 делает их основным выбором для этой цели;

• облачные вычисления;

• аналитика больших данных и обучение нейросетей;

• виртуализация корпоративного уровня, где скорость отклика каждого виртуального ядра имеет первостепенное значение;

• бизнес-критичных приложения, требующие высокой и однопоточной, и многопоточной производительности — например, СУБД.

Таким образом, процессоры Xeon^® 6 с P-ядрами — решения для самых требовательных корпоративных и научных вычислений. В этом сегменте производительность, масштабируемость и поддержка современных технологий важнее энергоэффективности.

Рынок был уверен, что P-ядра окажутся безоговорочно мощнее и будут опережать E-ядра по всем показателям. Однако результаты наших тестов показали, что реальная картина гораздо интереснее.

Да, P-ядра мощнее в расчете на поток и предназначены для тяжелых вычислений. Тем большим сюрпризом для нас стало то, что в ряде сценариев СУБД E-ядра обгоняют P-ядра — на реальных нагрузках и даже в небольшом числе синтетических тестов.

Поначалу это выглядело «странно». Мы пересобирали тесты, меняли методики, проводили глубокое профилирование и в итоге разобрались. Удалось выявить, в каких конкретно сценариях E-ядра выигрывают, а где P-ядра остаются абсолютно незаменимыми из-за более быстрых кешей, пропускной способности памяти или поддержки специфических инструкций.

Считаем, что этот материал станет хорошим руководством при выборе сервера, особенно при столкновении с такой задачей впервые.

Профессионалы, конечно, прогонят собственные бенчмарки перед покупкой или арендой. Однако они могут не заметить колоссальную разницу между «ветками» Intel^® Xeon^® 6, если не проведут такое же глубокое профилирование, как мы. Поэтому мы предоставляем клиентам максимально подробную информацию о тестируемом железе.

Наша цель — показать узкие места современных CPU и помочь бизнесу сделать осознанный выбор сервера под конкретную нагрузку, будь то:

• OLTP или OLAP;

• key-value хранилища или кэши;

• стриминг;

• пре- и постобработка, а также сборка данных для AI;

• задачи компрессии и шифрования;

• сетевые сервисы и т. п.

Зачем вообще Intel «разделил» Xeon® 6

Исторически процессоры Xeon^® были универсальными. Один и тот же CPU предназначался и для баз данных, и для виртуализации, и для микросервисов. Однако с ростом масштабов облачных платформ и изменением профиля нагрузок стало очевидно, что универсальность — это компромисс. Такой подход приводит к потере эффективности по двум ключевым параметрам: по производительности на ватт и совокупной стоимости владения (TCO).

Центры обработки данных, такие как AWS, Google Cloud, Azure, Alibaba Cloud, столкнулись с радикальной диверсификацией нагрузок. В одном кластере работают высокопроизводительные инстансы ИИ, а рядом — тысячи микросервисов в контейнерах, которые большую часть времени простаивают или потребляют доли ядра. Использовать для этих полярных задач один и тот же тип CPU — крайне неэффективно.

Intel отреагировала на возникший запрос, разделив линейку Xeon^® 6 на две специализированные ветви:

• Sierra Forest (E-ядра) — для массовых, параллельных и энергоэффективных задач;

• Granite Rapids (P-ядра) — для нагрузок, требующих максимальной производительности на поток и поддержки сложных инструкций, таких как AVX-512 или AMX.

Такое разделение позволило, наконец, оптимизировать платформу под конкретные сценарии, а не под «среднюю температуру по больнице».

Куда смотрят облака

Современные hyperscale-компании давно измеряют эффективность не в гигагерцах, а в ваттах на один запрос. В этой экономической модели приоритет отдается не пиковой скорости, а четырем ключевым метрикам:

• производительности на ватт (Perf/Watt);

• совокупной стоимости владения (TCO);

• плотности размещения ядер в стойке;

• гибкости подбора ресурсов под конкретный тип нагрузки.

Именно поэтому облачные провайдеры, такие как Google, AWS, Azure, уже перешли на гибридные кластеры. В таких средах ресурсы подбираются не по количеству ядер, а по их типу и TDP-профилю, что позволяет достичь оптимального баланса цены, энергопотребления и производительности.

Почему универсальные CPU перестали быть оптимальными

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

Он по своей природе является компромиссом:

• для легких сервисов слишком мощен и энергозатратен;

• для тяжелых вычислений, наоборот, не хватает поддержки специфических инструкций или высокой тактовой частоты.

В масштабах hyperscale-инфраструктуры этот компромисс выливается в огромную сумму переплаты за электроэнергию и охлаждение.

Именно поэтому рынок движется к специализации. Теперь разные типы ядер и даже разные архитектуры — x86, ARM, RISC-V — работают в общей экосистеме. Такой подход позволяет оптимизировать каждый тип нагрузки по его собственному, ключевому параметру эффективности.

Типовые ошибки при выборе сервера или CPU

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

Ошибка №1: «Главное — количество ядер»

— Вот возьмем побольше ядер, частоту и… будет быстрее.
— А вот и нет!

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

Во множестве реальных сценариев — будь то веб-приложения, API, базы данных, ETL-пайплайны или аналитика — прирост скорости упирается не в число доступных потоков. Настоящим «бутылочным горлышком» становятся:

• пропускная способность памяти (Memory Bandwidth),

• задержки при межъядерном взаимодействии (inter-core latency),

• задержки при межсокетном взаимодействии,

• ограничения со стороны дисковой подсистемы (I/O) или сети,

• программные блокировки (locks) внутри самого приложения.

Ошибка №2: «Главное — мощность»

— Так все равно же выгрузим данные в GPU!
— Но CPU-часть кластера по‑прежнему останется узким местом.

Часто выбор делают, глядя только на «бумажные» спецификации: тактовую частоту, объем кеша и TDP.

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

Вывод: правильный подход — это подбор CPU под конкретный SLA и тип задачи, а не «по принципу запаса». Например, для микросервисов мы берем энергоэффективные E-core. Для AI и аналитики — производительные P-core. А для смешанных сценариев — сбалансированные гибридные платформы.

Как избежать

Современный CPU — это не просто «коробка с ядрами», а сложный специализированный компонент, интегрированный во всю экосистему дата-центра.

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

Снижаем цены на выделенные серверы в реальном времени

Успейте арендовать со скидкой до 35%, пока лот не ушел другому.

Подробнее →

Бенчмарки

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

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

Для тестов мы использовали двухсокетные серверы Selectel в двух конфигурациях:

• 2x Xeon^® 6710E (E-cores): 128 ядер / 128 потоков (на графиках — сиреневый),

• 2x Xeon^® 6530P (P-cores): 64 ядра / 128 потоков (на графиках — зеленый).

Результаты на реальных приложениях сразу показали неожиданную картину. Вопреки ожиданиям, P-ядра (6530P) значительно уступили по всем бенчмаркам E-ядрам (6710E). Изначально это выглядело нелогично, но дальнейшее исследование прояснило общую картину.

В синтетических тестах все было наоборот и соответствовало привычной логике: чем выше частота и дороже процессор (P-core), тем лучше результат. Эта предсказуемость в «синтетике» лишь подчеркнула аномалию, выявленную на реальных нагрузках.

На следующей иллюстрации сравниваем две конфигурации:.

• 2x Xeon^® 6710E (E-cores): 128 ядер и 128 потоков (сиреневый график);

• 2x Xeon^® 6530P (P-cores): 64 ядра и те же 128 потоков (зеленый график).

Синтетические бенчмарки действительно показали преимущество P-ядер, однако оно оказалось не таким решающим, как можно было ожидать.

Такой поворот заставил нас идти дальше. Мы углубились в анализ специфики реальных нагрузок и конкретных сценариев применения, чтобы понять, как процессоры поведут себя за рамками «синтетики».

Наши тесты выявили сферу, где P-ядра абсолютно доминируют и не имеют альтернатив — задачи ML и HPC. Благодаря поддержке инструкций вроде AVX-512 и AMX, которых нет у E-ядер, мы зафиксировали 20‑кратное преимущество в производительности. Такой разрыв особенно впечатляет, если учесть, что 48 P-ядер опередили топовый 112-ядерный E-core (модель 6746E).

На диаграмме выше — сравнение масштабируемой производительности двухпроцессорных конфигураций Xeon^® 6747P и Xeon^® 6746E. Рабочие нагрузки — самые разные: криптография, кодирование видео, архивирование, Blender и Java. Хорошо видна разница в специализации ядер.

P-ядра показывают доминирование во всех задачах, чувствительных к частоте и однопоточной производительности:

• на 230% — ускорение криптографических алгоритмов OpenSSL, таких как RSA, ChaCha20, AES-GCM;

• на 90−150% — кодирование видео SVT-AV1;

• на 47% — архивирование при работе с 7-Zip;

• на 12−22% — Blender.

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

Таким образом, P-серия нацелена на высокопроизводительные вычисления, а E-серия — на энергоэффективность и массовый параллелизм.

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

На диаграмме выше — сравнение ускорения в задачах машинного обучения при использовании Llama.cpp и BLAS-оптимизаций для моделей Llama, Granite и Mistral на двухпроцессорных системах Xeon^® 6746E и Xeon^® 6747P.

Тестирование показывают колоссальный отрыв модели 6747P в задачах BLAS. Прирост производительности относительно базовой линии — от 900% до 2 300%. Столь внушительные цифры подтверждают безоговорочное превосходство P-ядер в бенчмарках машинного обучения, основанных на линейной алгебре.

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

Лидерство модели 6747P во взятых сценариях объясняется эффективной реализацией наборов инструкций AVX и AMX, которые обеспечивают аппаратное ускорение вычислений.

В данной выборке ML-бенчмарков P-ядра имеют неоспоримое преимущество при ускорении вычислений, интенсивно использующих библиотеки BLAS. Напротив, E-ядра в показывают значительно меньшую эффективность, проигрывая в производительности при той же стоимости.

Заключение

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

Правильный подбор специализированного железа под конкретную задачу становится не просто оптимизацией, а экономической необходимостью. Такой подход позволяет не только получить максимальную производительность там, где она нужна, но и значительно сэкономить, так как P-ядра ощутимо дороже E-ядер.

Надеемся, что наше небольшое исследование поможет компаниям точнее определять профиль своей нагрузки и подбирать под нее оптимальный CPU. Такой подход позволяет не только сэкономить миллионы на электроэнергии, но и повысить общий КПД своих дата-центров.