Привет, Хабр! Меня зовут Михаил Косцов, я руководитель практики вычислительной инфраструктуры, СХД и СРК К2Тех. Для нас серверное железо – рабочий инструмент, и мы обязаны знать его возможности. Когда к нам в лабораторию попали два сервера YADRO, мы гоняли их 24 часа под полной нагрузкой, выдергивали диски на ходу и до предела грузили вычислениями.
Под катом – разбор VEGMAN R220 G3 (2U-сервер с парой Xeon Max 9480 и встроенной HBM-памятью) и YADRO G4208P G3 (4U-платформа под ИИ-нагрузки с двумя видеокартами NVIDIA H100 и парой H200). Будут бенчмарки, стресс-тесты, проверка отказоустойчивости и много графиков.

У YADRO есть собственная команда промышленного дизайна, и это ощущается даже по неймингу в духе советского конструктивизма: вычислительные платформы носят имя архитектора Георгия Вегмана, системы хранения данных названы в честь Владимира Татлина (кстати, подробный обзор СХД YADRO TATLIN.UNIFIED Gen2 можно почитать здесь). При этом, если многие производители российских серверов полагаются на контрактное производство, то YADRO стремится обеспечить потребности самостоятельно: у компании есть собственное производство оборудования, системных плат и даже текстолита в Дубне. Такой подход дает вендору возможность проектировать платформы под себя и планомерно сокращать зависимость от сторонних поставщиков.
Исследуем VEGMAN R220 G3

VEGMAN R220 G3 – новый флагманский сервер компании YADRO на 4/5 поколении Intel, и мы одними из первых протестировали его в нашей лаборатории. Эта платформа позволяет устанавливать процессоры с TDP до 350 Вт. В данном случае – пара Intel Xeon Max 9480.
Каждый такой процессор оснащен P-ядрами в количестве 56 шт. в комплексе со встроенной сверхбыстрой HBM2e объемом 64 GB, интегрированной на одну подложку с кристаллом процессора. Память HBM2e можно использовать в качестве дополнительного кэша или оперативной памяти (основной и второстепенной).
Кроме того, VEGMAN R220 G3 несет на борту 32 плашки оперативной памяти DDR5-4400 MT/s на 64 GB каждая, поддерживает установку до 28 накопителей и имеет отличные возможности расширения до 11 × PCIe 5.0 с учетом двух отсеков OCP 3.0 SFF и гнезда под RAID/HBA (размещается на системной плате без задействования отсека для карт расширения). В определенных конфигурациях сервер имеет возможность установки до 2-х GPU двойной ширины. В нашем сервере во фронтальной корзине установлены четыре накопителя NVMe SSD объемом 1920 GB каждый.

Еще стоит отметить два слота M.2 / E1.S на задней панели. Для них заявлена поддержка аппаратного и программного RAID, поэтому на этих накопителях можно собрать отказоустойчивый загрузочный том под ОС.
Для удобства эксплуатации в ЦОДе производитель предусмотрел подсказки для инженеров на корпусе сервера, а именно: «Замена накопителя M.2», «Замена OCP-карты», сделал описание индикаторов состояния сервера, индикаций на лотках накопителей и многое другое, что позволяет избежать ошибок и оперативно получить ответы на возникающие вопросы.
Скрытый текст
Также на компонентах сервера присутствуют цветовые индикаторы для быстрой идентификации того, в каком состоянии можно делать их замену. Маркировка привычная: оранжевые маркеры указывают на компоненты «горячей» замены, синие – на компоненты «холодной» замены:

Еще одним интересным решением является дискретный «Модуль системного управления» со множеством интерфейсов, в нем расположен BMC (Baseboard Management Controller, контроллер управления основной платой) и BIOS. Так, например, при выходе из строя чипа BMC не нужно будет менять системную плату сервера целиком.

Комплект поставки включает в себя сервер, салазки для установки в стандартную телекоммуникационную стойку 19 дюймов, комплект крепежа, 2 кабеля питания. Дополнительно хотелось бы видеть в комплекте кабель для подключения к mini DP на модуле системного управления.
Вендор сразу указывает, что монтаж сервера в стойку лучше выполнять вдвоем, и на практике это подтвердилось: установка потребовала аккуратного совмещения направляющих, иначе шасси норовило встать с перекосом. При работе с комплектными салазками для M.2-накопителей и пластиковыми заглушками слотов 2.5″-дисков пришлось уделить больше внимания фиксации: при неаккуратной установке заглушки могут проваливаться внутрь корпуса.
24-часовой краш-тест
Сервер без проблем прошел через процесс настройки и базовые функциональные тесты, но мы хотели выяснить: насколько стабильна такая плотная конфигурация во время длительной работы.
Мы запустили стресс-тест и спустя 24 часа непрерывной работы под 100%-й нагрузкой, стало ясно, что VEGMAN R220 G3 справился без нареканий.
Стабильную работу сервера при высокой нагрузке обеспечивает сочетание грамотной проектировки внутренней компоновки сервера, использование радиаторов EVAC, воздуховодов и вентиляторов достаточной мощности.


В ходе тестов на отказоустойчивость мы поочередно выдернули:
один из системных накопителей NVMe в RAID-1 (имитация деградации RAID-массива);
модуль вентилятора (один из 6 в режиме N+1);
блок питания (один из двух).
При отказах работа сервера не была нарушена, но мониторинг отказа NVMe в BMC не сработал: сервер выдал алерты о потере компонентов, загорелись индикаторы сбоя компонентов на передней панели, в BMC отобразились все ошибки, кроме потери накопителя NVMe. Проблема с мониторингом выхода из строя дисков встречается довольно часто. Одной из возможных причин могла стать ошибка конкретного микрокода или конфигурации. Рассчитываем, что производитель устранит проблему в следующих релизах BMC.
Убедившись в стабильной работе сервера даже в аварийных сценариях, мы взялись за синтетические тесты.
Что показывают 7-Zip и Stream
Прикладная производительность CPU традиционно измеряется архиваторами: компрессия – алгоритмически сложная задача с активной работой с кэшем, а декомпрессия отлично параллелится на все доступные потоки. Таким образом, можно проверить сразу два сценария работы процессора.


В этом тесте мы использовали встроенный бенчмарк 7-Zip (алгоритм LZMA). 7-Zip выдает значения MIPS (миллионы операций в секунду) для компрессии и декомпрессии. Кроме того, режим тестирования умеет нагружать четко указанное количество ядер и выдавать результаты в расчете на 1 ядро. В тестах компрессии мы получили 347 827 MIPS, декомпрессии – 447 701 MIPS.
Следующий шаг – синтетический тест Stream. Он измеряет устойчивую пропускную способность памяти на основе четырех базовых векторных операций: Copy (копирование массива), Scale (умножение на константу), Add (сложение двух массивов) и Triad (комбинированная операция). Размер массивов подбирается так, чтобы они были значительно больше кэша. Это позволяет измерить «честную» пропускную способность памяти.
Результаты VEGMAN R220 G3, честно говоря, впечатляют:
Copy – 825 226 МБ/с.
Stream Scale – 796 192 МБ/с.
Add – 835 443 МБ/с.
Triad – 831 646 МБ/с.
Конфигурация сервера мощная, как и полученный результат: тест Copy показал результат в 2 с лишним раза выше, чем было у прошлого лидера с 64 ядрами 2 ГГц, 512 GB DDR5, выдавших 387 669 МБ/с.
Реальные задачи
Синтетика хороша для сравнений, но мы хотели проверить сервер в условиях, приближенных к реальной нагрузке. Мы развернули PostgreSQL и прогнали через него pgbench с типичным OLTP-профилем.
Важная деталь: здесь используется дисковая подсистема на основе накопителей NVMe SSD, собранных в RAID 1 с помощью VROC.


В тесте с 500 клиентами и 10-минутной нагрузкой 53 091 TPS при средней задержке 9,4 мс. при двукратном увеличении нагрузки (1000 конкурентных клиентов) СУБД ожидаемо уперлась в блокировки транзакций: пропускная способность снизилась до 19 923 TPS, задержка выросла до 50,3 мс.


Вторым практическим тестом стал Redis. Гоняли два сценария – на 50 и 500 одновременных потоков, только атомарные операции SET и GET.


На 50 параллельных соединениях redis-benchmark показал 2 621 707 SET/с и 3 225 924 GET/с. На 500 потоках – 1 867 733 SET/с и 2 377 253 GET/с.


Полный список тестов
Выше мы подробно разобрали несколько показательных тестов: поведение процессора, памяти, дисковой подсистемы и баз данных под разной нагрузкой, но в рамках испытаний учитывали более широкий набор бенчмарков. В таблице ниже собраны результаты синтетических и прикладных тестов YADRO VEGMAN R220 G3.
Приведенные показатели получены в рамках конкретного тестового стенда и сценариев нагрузки, поэтому могут иметь статистические отклонения при повторении тестов или изменении аппаратной и программной конфигурации.
CPU-нагрузки показывают вычислительную производительность процессоров, STREAM – пропускную способность памяти, Redis – скорость in-memory операций чтения и записи, pgbench – поведение PostgreSQL под транзакционной нагрузкой, mysqlslap – производительность MySQL при разной конкурентности, а сборка Linux kernel дает интегральную оценку сервера на реальной инженерной задаче. Метрики requests/sec, TPS, MIPS и MB/s интерпретируются по принципу «чем выше, тем лучше»; для latency и времени сборки наоборот – «чем ниже, тем лучше».
Таблица с результатами тестов
Тест / инструмент |
Профиль / операция |
Результат |
Комментарий |
sysbench |
CPU |
256 749,79 events/sec |
Производительность CPU в синтетических вычислениях. Чем выше, тем лучше. |
stress-ng |
CPU Stress |
239 179,61 ops/sec |
Условная производительность CPU под стресс-нагрузкой. Чем выше, тем лучше. |
7-Zip |
Compression Rating |
347 827 MIPS |
Производительность при сжатии данных. Чем выше, тем лучше. |
7-Zip |
Decompression Rating |
447 701 MIPS |
Производительность при распаковке данных. Чем выше, тем лучше. |
STREAM |
Copy |
825 226,3 MB/s |
Пропускная способность памяти при копировании массива. Чем выше, тем лучше. |
STREAM |
Scale |
796 192,9 MB/s |
Пропускная способность памяти при умножении массива на коэффициент. |
STREAM |
Add |
835 443,4 MB/s |
Пропускная способность памяти при сложении массивов. |
STREAM |
Triad |
831 646,8 MB/s |
Комбинированная операция A = B + scalar × C |
build-linux-kernel |
defconfig |
31,896 с |
Время сборки Linux kernel с базовой конфигурацией. Чем меньше, тем лучше. |
build-linux-kernel |
allmodconfig |
258,375 с |
Время сборки ядра с большим набором модулей. Чем меньше, тем лучше. |
redis-benchmark |
GET, 50 клиентов |
3 225 924,54 requests/sec |
Скорость операций чтения из Redis. Чем выше, тем лучше. |
redis-benchmark |
SET, 50 клиентов |
2 621 707,50 requests/sec |
Скорость операций записи в Redis. Чем выше, тем лучше. |
redis-benchmark |
GET, 500 клиентов |
2 377 253,22 requests/sec |
Скорость чтения при высокой конкурентной нагрузке. |
redis-benchmark |
SET, 500 клиентов |
1 867 733,18 requests/sec |
Скорость записи при высокой конкурентной нагрузке. |
redis-benchmark |
GET, 1000 клиентов |
2 434 782,15 requests/sec |
Скорость чтения при 1000 параллельных клиентах. |
redis-benchmark |
SET, 1000 клиентов |
1 931 262,47 requests/sec |
Скорость записи при 1000 параллельных клиентах. |
pgbench |
Read Write, scale 1, 50 клиентов |
7 253 TPS |
Смешанная транзакционная нагрузка: чтение и запись. Чем выше, тем лучше. |
pgbench |
Read Write Average Latency, scale 1, 50 клиентов |
6,918 ms |
Средняя задержка транзакции. Чем ниже, тем лучше. |
pgbench |
Read Only, scale 1, 50 клиентов |
1 208 171 TPS |
Производительность PostgreSQL в режиме только чтения. |
pgbench |
Read Only Average Latency, scale 1, 50 клиентов |
0,042 ms |
Средняя задержка read-only транзакции. |
pgbench |
Read Write, scale 100, 100 клиентов |
66 393 TPS |
Смешанная нагрузка на базе большего размера. |
pgbench |
Read Write Average Latency, scale 100, 100 клиентов |
1,507 ms |
Средняя задержка mixed-транзакции. |
pgbench |
Read Only, scale 100, 100 клиентов |
1 234 896 TPS |
Read-only производительность при 100 клиентах. |
pgbench |
Read Only Average Latency, scale 100, 100 клиентов |
0,081 ms |
Средняя задержка read-only транзакции. |
pgbench |
Read Write, scale 1000, 1000 клиентов |
19 923 TPS |
Тяжелая mixed-нагрузка при высокой конкуренции. |
pgbench |
Read Write Average Latency, scale 1000, 1000 клиентов |
50,328 ms |
Средняя задержка mixed-транзакции при 1000 клиентах. |
pgbench |
Read Only, scale 1000, 1000 клиентов |
766 273 TPS |
Read-only производительность при 1000 клиентах. |
pgbench |
Read Only Average Latency, scale 1000, 1000 клиентов |
1,305 ms |
Средняя задержка read-only транзакции. |
pgbench |
Read Write, scale 1, 250 клиентов |
3 097 TPS |
Mixed-нагрузка на маленькой базе при 250 клиентах. |
pgbench |
Read Write Average Latency, scale 1, 250 клиентов |
80,723 ms |
Резкий рост задержки из-за высокой конкуренции. |
pgbench |
Read Only, scale 1, 250 клиентов |
631 337 TPS |
Read-only производительность при 250 клиентах. |
pgbench |
Read Only Average Latency, scale 1, 250 клиентов |
0,398 ms |
Средняя задержка read-only транзакции. |
pgbench |
Read Write, scale 100, 250 клиентов |
57 083 TPS |
Mixed-нагрузка на scale 100 при 250 клиентах. |
pgbench |
Read Write Average Latency, scale 100, 250 клиентов |
4,381 ms |
Средняя задержка mixed-транзакции. |
pgbench |
Read Only, scale 100, 250 клиентов |
727 871 TPS |
Read-only производительность при 250 клиентах. |
pgbench |
Read Only Average Latency, scale 100, 250 клиентов |
0,351 ms |
Средняя задержка read-only транзакции. |
pgbench |
Read Write, scale 1, 500 клиентов |
1 782 TPS |
Mixed-нагрузка на маленькой базе при 500 клиентах. |
pgbench |
Read Write Average Latency, scale 1, 500 клиентов |
280,645 ms |
Очень высокая задержка, вероятно из-за конкуренции за одни и те же данные. |
pgbench |
Read Only, scale 1, 500 клиентов |
612 000 TPS |
Read-only производительность при 500 клиентах. |
pgbench |
Read Only Average Latency, scale 1, 500 клиентов |
0,817 ms |
Средняя задержка read-only транзакции. |
pgbench |
Read Write, scale 100, 500 клиентов |
53 091 TPS |
Mixed-нагрузка на scale 100 при 500 клиентах. |
pgbench |
Read Write Average Latency, scale 100, 500 клиентов |
9,425 ms |
Средняя задержка mixed-транзакции. |
pgbench |
Read Only, scale 100, 500 клиентов |
718 898 TPS |
Read-only производительность при 500 клиентах. |
pgbench |
Read Only Average Latency, scale 100, 500 клиентов |
0,696 ms |
Средняя задержка read-only транзакции. |
mysqlslap |
64 клиента |
1 262 queries/sec |
Производительность MySQL при 64 параллельных клиентах. |
mysqlslap |
256 клиентов |
317 queries/sec |
Производительность MySQL при 256 клиентах. |
mysqlslap |
512 клиентов |
148 queries/sec |
Производительность MySQL при 512 клиентах. |
mysqlslap |
1024 клиента |
68 queries/sec |
Производительность MySQL при 1024 клиентах. |
mysqlslap |
2048 клиентов |
67 queries/sec |
Производительность MySQL при 2048 клиентах. |
mysqlslap |
4096 клиентов |
68 queries/sec |
Производительность MySQL при 4096 клиентах. |
mysqlslap |
8192 клиента |
68 queries/sec |
Производительность MySQL при 8192 клиентах. |
Подведу итог: сервер VEGMAN R220 G3 успешно прошел 24‑часовой краш‑тест под 100‑процентной нагрузкой, корректно отработал сценарии отказов и показал высокие результаты в синтетических тестах. В совокупности это подтверждает, что система охлаждения выдерживает тепловые нагрузки без троттлинга, признаков деградации NVMe в протестированном профиле не выявили, что соответствует базовым требованиям корпоративных заказчиков к предсказуемой производительности под длительной нагрузкой.
Исследуем YADRO G4208P G3
Если VEGMAN R220 G3 универсальное решение для виртуализации и баз данных, то YADRO G4208P G3 спроектирован под задачи машинного обучения и генеративного ИИ, и вся архитектура этого сервера строится вокруг графических ускорителей.

Такие системы становятся основой для прикладных ИИ-платформ. Например, YADRO G4208P G3 используются в ПАК-AI от К2 НейроТех (входит в К2Тех). На них можно решать ресурсоемкие задачи: обучать и дообучать модели, запускать алгоритмы компьютерного зрения, обрабатывать большие массивы данных и так далее.
Наш тестовый образец YADRO G4208P G3 работает на базе пары Intel Xeon Gold 6442Y (4-е поколение Scalable) и 32 планок оперативной памяти DDR5-4400 MT/s по 32 GB каждая, которые служат в качестве буфера для загрузки весов моделей. Главная особенность платформы в том, что она поддерживает до 8 GPU, а также NVLink Bridge для совместимых GPU. Они устанавливаются довольно плотно, и при использовании всех GPU-слотов укладка кабелей питания становится сложной задачей.

Мы тестировали конфигурацию из неравных пар: две NVIDIA H100 и две NVIDIA H200 одновременно, без использования NVLink. В официальной документации производитель рекомендует устанавливать до 4 видеокарт с TDP до 600 Вт (таких как H200) при температуре окружающей среды 25 °C, либо ставить до 8 видеокарт H100, которые способна «переварить» платформа.
За долговременное хранение данных отвечают пять накопителей SATA SSD 3840 GB с возможностью расширения до 12-ти под управлением RAID контроллера MegaRAID 9560-8i. Все это упаковано в 4-юнитовый корпус.

12 hot-swap вентиляторов справляются с отводом 2000 Вт тепла от восьми карт. Во время нашего суточного стресс-теста с четырьмя картами они удержали среднюю температуру процессоров в коридоре 65–70 °C. Для серверов такого класса результат отличный. Для более горячих задач в спецификациях YADRO G4208P G3 заложена возможность интеграции системы жидкостного охлаждения (СЖО): водоблоки ставятся прямо на процессоры и GPU, отводя до 8 кВт тепла от одного сервера через внешние драйкулеры.
Функциональные тесты
В сервере используется Aptio BIOS, модифицированная компанией YADRO. Система ввода-вывода предоставляет весь самый необходимый функционал для первичной настройки сервера: например, настройка сети для IPMI и настройка RAID массива.

Главная страница BMC YADRO G4208P G3 поделена на несколько вкладок и предоставляет довольно полный обзор состояния системы, включая функции для комплексного сбора логов и монтирование образов:

Тесты отказа компонентов
После установки, как и в случае с VEGMAN R220 G3, мы проверяли поведение системы при отказе различных компонентов. Извлечение диска, блока питания, модуля системы охлаждения не привело к сбоям в работе сервера.
LuxMark и рендеринг физики
LuxMark оценивает производительность GPU при трассировке лучей через API OpenCL. И служит хорошим маркером общей производительности подсистемы памяти и готовности карт к тяжелым визуальным вычислениям.



Базовая сцена Luxball HDR выдала 690 707 баллов, тяжелая сцена Hotel (серьезная нагрузка на видеопамять) – 114 684 балла. Система отработала штатно, никаких аномалий разнородный кластер не показал, но это был лишь разогрев.
Rodinia и нюансы синхронизации
А вот здесь началось интересное. Rodinia – набор специализированных алгоритмов для научных вычислений. В отличие от сырого рендеринга, этот бенчмарк чувствителен к задержкам между памятью хоста (CPU) и памятью GPU. Чем меньше время выполнения, тем лучше.

Мы запустили тест OpenCL Myocyte (моделирование поведения биологических клеток) и получили следующую картину:
Пара H200 отдельно – 22,29 с.
Пара H100 отдельно – 23,06 с.
Гибридная сборка (все 4 карты вместе) – 23,16 с.
Hashcat и сырая математика


Этот инструмент максимально утилизирует ALU графических чипов, заставляя их генерировать хэши. Результат измеряется в H/s (хэшей в секунду).
Вскоре мы увидели, что пара H100 в соло выдает 174,9 млрд H/s, а гибридная сборка из четырех карт (H100+H200) выдала… те же самые 174,9 млрд H/s (а в тесте SHA-512 даже чуть меньше).
Если вы собираете гибридный кластер под ML-задачи, будьте готовы к тому, что эффективность масштабирования во многих сценариях будет далека от линейной. Однако не спешите ставить крест на таких сборках. В том же Hashcat мы запустили алгоритм bcrypt, он считается сложным для GPU из-за тяжелой математики. Пара H200 выдала 316 147 H/s, пара H100 – 269 181 H/s, а гибридный кластер показал 584 671 H/s. Прирост – 99,8% от идеального линейного. И это без попарного объединения NVLink.

Важно понимать, что такая гибридная конфигурация с разнотипными GPU носит лабораторный характер и не соответствует поддерживаемым вендором профилям поставки. Тем не менее результаты теста показывают, как система ведет себя в смешанных сценариях и что в ряде вычислительных задач разнородные ускорители могут давать близкий к линейному прирост производительности при корректной настройке и учете ограничений по связности и эксплуатации.
На протяжении всех тестов YADRO G4208P G3 работал в штатном режиме. Мы также прогнали для него стандартный набор тестов на отказоустойчивость и провели замеры производительности CPU, аналогичные VEGMAN R220 G3.
Результаты собраны в таблице.
Тест / инструмент |
Профиль / операция |
Результат |
Комментарий |
sysbench |
CPU |
140 652,60 events/sec |
Производительность CPU в синтетических вычислениях. Чем выше, тем лучше. |
stress-ng |
CPU Stress |
123 831,54 ops/sec |
Условная производительность CPU под стресс-нагрузкой. Чем выше, тем лучше. |
7-Zip |
Compression Rating |
406 882 MIPS |
Производительность при сжатии данных. Чем выше, тем лучше. |
7-Zip |
Decompression Rating |
272 914 MIPS |
Производительность при распаковке данных. Чем выше, тем лучше. |
STREAM |
Copy |
391 764,5 MB/s |
Пропускная способность памяти при копировании массива. Чем выше, тем лучше. |
STREAM |
Scale |
316 317,4 MB/s |
Пропускная способность памяти при умножении массива на коэффициент. |
STREAM |
Add |
400 961,8 MB/s |
Пропускная способность памяти при сложении массивов. |
STREAM |
Triad |
401 112,8 MB/s |
Комбинированная операция A = B + scalar × C |
build-linux-kernel |
defconfig |
34,500 с |
Время сборки Linux kernel с базовой конфигурацией. Чем меньше, тем лучше. |
build-linux-kernel |
allmodconfig |
337,059 с |
Время сборки ядра с большим набором модулей. Чем меньше, тем лучше. |
redis-benchmark |
GET, 50 клиентов |
3 685 121,50 requests/sec |
Скорость операций чтения из Redis. Чем выше, тем лучше. |
redis-benchmark |
SET, 50 клиентов |
3 026 567,17 requests/sec |
Скорость операций записи в Redis. Чем выше, тем лучше. |
redis-benchmark |
GET, 500 клиентов |
3 169 689,67 requests/sec |
Скорость чтения при высокой конкурентной нагрузке. |
redis-benchmark |
SET, 500 клиентов |
2 543 115,83 requests/sec |
Скорость записи при высокой конкурентной нагрузке. |
redis-benchmark |
GET, 1000 клиентов |
3 134 105,83 requests/sec |
Скорость чтения при 1000 параллельных клиентах. |
redis-benchmark |
SET, 1000 клиентов |
2 525 106,06 requests/sec |
Скорость записи при 1000 параллельных клиентах. |
pgbench |
Read Write, scale 1, 50 клиентов |
7 374 TPS |
Смешанная транзакционная нагрузка: чтение и запись. Чем выше, тем лучше. |
pgbench |
Read Write Average Latency, scale 1, 50 клиентов |
6,789 ms |
Средняя задержка транзакции. Чем ниже, тем лучше. |
pgbench |
Read Only, scale 1, 50 клиентов |
2 052 909 TPS |
Производительность PostgreSQL в режиме только чтения. |
pgbench |
Read Only Average Latency, scale 1, 50 клиентов |
0,024 ms |
Средняя задержка read-only транзакции. |
pgbench |
Read Write, scale 100, 100 клиентов |
29 140 TPS |
Смешанная нагрузка на базе большего размера. |
pgbench |
Read Write Average Latency, scale 100, 100 клиентов |
3,432 ms |
Средняя задержка mixed-транзакции. |
pgbench |
Read Only, scale 100, 100 клиентов |
1 959 085 TPS |
Read-only производительность при 100 клиентах. |
pgbench |
Read Only Average Latency, scale 100, 100 клиентов |
0,051 ms |
Средняя задержка read-only транзакции. |
pgbench |
Read Write, scale 1000, 1000 клиентов |
25 507 TPS |
Тяжелая mixed-нагрузка при высокой конкуренции. |
pgbench |
Read Write Average Latency, scale 1000, 1000 клиентов |
39,299 ms |
Средняя задержка mixed-транзакции при 1000 клиентах. |
pgbench |
Read Only, scale 1000, 1000 клиентов |
1 515 907 TPS |
Read-only производительность при 1000 клиентах. |
pgbench |
Read Only Average Latency, scale 1000, 1000 клиентов |
0,660 ms |
Средняя задержка read-only транзакции. |
pgbench |
Read Write, scale 1, 250 клиентов |
4 094 TPS |
Mixed-нагрузка на маленькой базе при 250 клиентах. |
pgbench |
Read Write Average Latency, scale 1, 250 клиентов |
61,073 ms |
Резкий рост задержки из-за высокой конкуренции. |
pgbench |
Read Only, scale 1, 250 клиентов |
2 189 312 TPS |
Read-only производительность при 250 клиентах. |
pgbench |
Read Only Average Latency, scale 1, 250 клиентов |
0,115 ms |
Средняя задержка read-only транзакции. |
pgbench |
Read Write, scale 100, 250 клиентов |
29 216 TPS |
Mixed-нагрузка на scale 100 при 250 клиентах. |
pgbench |
Read Write Average Latency, scale 100, 250 клиентов |
8,557 ms |
Средняя задержка mixed-транзакции. |
pgbench |
Read Only, scale 100, 250 клиентов |
2 288 527 TPS |
Read-only производительность при 250 клиентах. |
pgbench |
Read Only Average Latency, scale 100, 250 клиентов |
0,109 ms |
Средняя задержка read-only транзакции. |
pgbench |
Read Write, scale 1, 500 клиентов |
1 947 TPS |
Mixed-нагрузка на маленькой базе при 500 клиентах. |
pgbench |
Read Write Average Latency, scale 1, 500 клиентов |
257,416 ms |
Очень высокая задержка, вероятно из-за конкуренции за одни и те же данные. |
pgbench |
Read Only, scale 1, 500 клиентов |
2 132 742 TPS |
Read-only производительность при 500 клиентах. |
pgbench |
Read Only Average Latency, scale 1, 500 клиентов |
0,235 ms |
Средняя задержка read-only транзакции. |
pgbench |
Read Write, scale 100, 500 клиентов |
27 900 TPS |
Mixed-нагрузка на scale 100 при 500 клиентах. |
pgbench |
Read Write Average Latency, scale 100, 500 клиентов |
17,922 ms |
Средняя задержка mixed-транзакции. |
pgbench |
Read Only, scale 100, 500 клиентов |
2 205 738 TPS |
Read-only производительность при 500 клиентах. |
pgbench |
Read Only Average Latency, scale 100, 500 клиентов |
0,226 ms |
Средняя задержка read-only транзакции. |
mysqlslap |
64 клиента |
2 003 queries/sec |
Производительность MySQL при 64 параллельных клиентах. |
mysqlslap |
256 клиентов |
505 queries/sec |
Производительность MySQL при 256 клиентах. |
mysqlslap |
512 клиентов |
241 queries/sec |
Производительность MySQL при 512 клиентах. |
mysqlslap |
1024 клиента |
113 queries/sec |
Производительность MySQL при 1024 клиентах. |
mysqlslap |
2048 клиентов |
110 queries/sec |
Производительность MySQL при 2048 клиентах. |
mysqlslap |
4096 клиентов |
110 queries/sec |
Производительность MySQL при 4096 клиентах. |
mysqlslap |
8192 клиента |
113 queries/sec |
Производительность MySQL при 8192 клиентах. |
Подведу итог: YADRO G4208P G3 в тестах показал себя как стабильная платформа для длительных вычислительных нагрузок ИИ‑ и ML‑класса. Это делает его практичным вариантом для обучения и инференса моделей – от классических ML‑сценариев до генеративного ИИ и LLM, где важны предсказуемая производительность и масштабируемость всей системы, а не только паспортные характеристики отдельных ускорителей.
Мелкие недостатки протестированных серверов
Аппаратная основа обоих серверов на высоте. К разводке плат, охлаждению или реализации подсистемы питания придраться сложно, а вот к софтовой обвязке за время тестирования у нас накопились вопросы.
В качестве BMC (контроллера управления основной платой) YADRO использует YSCM – глубоко переработанный форк OpenBMC. Интерфейс выглядит современно, работает быстро, документация написана на грамотном русском языке, но в некоторых базовых сценариях YSCM усложняет пусконаладку.
Микрокоды по закрытым каналам
Обновления BIOS и BMC у YADRO довольно закрытая история. Публичного доступа к свежим микрокодам нет, скачивание возможно только при наличии действующего аккаунта на сервисном портале, но наличие портала и прошивок на нем – уже огромный плюс.
Лаги BIOS
В BIOS YADRO G4208P G3 мы регулярно ловили сильные зависания при настройке встроенной системы управления. Как только управление передается загрузчику ОС, все работает как часы, но при первоначальной настройке фризы отнимают время и портят впечатление от машины. Прибавьте к этому, что RAID-массив собирается только через BIOS.
Итоги тестирования
При подсчете итоговых баллов мы опирались на взвешенную систему метрик. Каждый параметр имеет свой вес, отражающий его значимость в проде. Оценки выставляли по 5-балльной шкале.
Критерий |
Вес (%) |
VEGMAN R220 G3 |
YADRO G4208P G3 |
Комментарий |
Надежность / стабильность |
30% |
5 |
5 |
Отказоустойчивость на высоте, тесты с нештатным отключением компонентов пройдены. |
Производительность |
20% |
5 |
5 |
Железо выдает максимум. |
Доступность документации |
15% |
5 |
5 |
Открытые и подробные мануалы на русском языке. |
Качество сборки |
15% |
4 |
4 |
Все собрано аккуратно: кабели разведены и убраны в кабель-каналы. На компонентах есть наклейки с FRU, точки касания для монтажа и демонтажа размечены. VEGMAN R220 G3 теряет балл из-за неудобств при инсталляции, а YADRO G4208P G3 – из-за неэргономичного расположения разъемов. |
Удобство эксплуатации (BMC) |
10% |
4 |
4 |
YSCM хорош, однако большинство крупных вендоров выкладывают микрокоды в открытый доступ, поэтому минус один балл. |
Удобство инсталляции |
10% |
4 |
3 |
Настройка VROC только через BIOS. YADRO G4208P G3: фризы BIOS при первичной пусконаладке. |
ИТОГОВЫЙ РЕЙТИНГ |
100% |
4,65 |
4,55 |
Оба сервера получили высшие баллы за то, что действительно важно: производительность и стабильность. YADRO G4208P G3 потерял доли балла из-за «сырости» интерфейсов при первичной пусконаладке (оценка 3 из 5 за инсталляцию). Напомню, что сравнивать их между собой по итоговому баллу не имеет смысла: серверы имеют разное предназначение и заточены каждый под свои задачи:
VEGMAN R220 G3 – двухпроцессорная платформа под нагруженные базы данных и плотную виртуализацию;
YADRO G4208P G3 – специализированный инструмент для обучения и инференса моделей.
Заключение

VEGMAN R220 G3 – надежный сервер для высоконагруженных баз данных, виртуализации и некоторых задач ИИ. Сервер выдерживает тепловые нагрузки, процессоры выдают хороший КПД, в протестированном профиле нагрузок признаков деградации NVMe‑подсистемы мы не выявили. Однако для полного счастья хотелось бы, чтобы производитель оптимизировал работу BIOS и BMC.
YADRO G4208P G3 – специализированная вычислительная платформа для ИИ‑ и ML‑задач с поддержкой до восьми GPU и возможностью объединения совместимых ускорителей через NVLink, рассчитанная на высокую тепловую и электрическую нагрузку (резервирование питания 3+1, опция интеграции жидкостного охлаждения). По итогам тестов основное замечание относится к программной части: регулярные зависания BIOS при пусконаладке усложняют первичную настройку и отнимают время у инженеров.
Обе платформы показывают, что инженерные решения YADRO давно вышли за рамки отверточной сборки OEM-комплектующих. В софте остаются шероховатости, но YADRO определенно есть, чем гордиться.
И, конечно, будем рады вашему опыту: если вы уже работали с VEGMAN, G‑серией или решениями YADRO – делитесь в комментариях, особенно интересно, как оборудование показывает себя в долгосрочной эксплуатации. Какие параметры для вас критичны при выборе и использовании серверов? С какими сложностями вы столкнулись после перехода на российские решения? И что, на ваш взгляд, обязательно стоит включать в тесты и обзоры реестрового железа, чтобы сделать будущие материалы точнее и полезнее для всех?
V-core
для полноценного тест-драйва не хватает одной строчки:
розничная стоимость протестированной комплектации составляет хх.ххх млн. рублей