Железо для ИИ: как проектируют аппаратный стек ПАК и почему обычный сервер не подходит
Инженерные команды, создающие программно-аппаратные комплексы для ИИ, раскрывают детали проектирования аппаратного стека. Обычные серверы не рассчитаны на экстремальные нагрузки, характерные для обучения и инференса больших моделей, поэтому требуется особая архитектура. В статье разбираются ключевые слои: GPU, питание, охлаждение и хранение, а также приводятся конкретные цифры и рекомендации.
Разработчики инфраструктуры для ИИ-задач продолжают цикл публикаций о создании программно-аппаратных комплексов (ПАК). На этот раз внимание сосредоточено на аппаратном стеке — от выбора графических ускорителей до организации питания и охлаждения. Авторы подчёркивают, что стандартный сервер, даже оснащённый GPU, не способен эффективно справляться с профилем нагрузок, характерным для современных нейросетей. Причина кроется в резких пиках энергопотребления, непрерывном обмене данными между ускорителями и жёстких требованиях к задержкам синхронизации. Структура материала построена по слоям: для каждого из них — GPU, питание, охлаждение, хранение — показано, какую инженерную задачу решали проектировщики и почему выбрали именно такое решение, а не альтернативное. Там, где это уместно, приводятся цифры, помогающие понять пороги: когда одно решение заменяется другим и что это означает по деньгам и по производительности. Отдельный бонус — чеклист из пяти вопросов, которые стоит задать любому вендору при обсуждении железа для ИИ-нужд.
ИИ-нагрузка принципиально отличается от традиционных серверных задач, таких как OLTP или веб-сервисы. Обучение больших моделей сопровождается кратковременными всплесками потребления энергии при старте эпох, затем длительным плато на максимуме и мгновенными просадками. Между GPU идёт интенсивный обмен, сопоставимый по объёму с пропускной способностью отдельных сетевых сегментов. Любая задержка синхронизации приводит не к замедлению, а к потере итерации обучения. Поэтому при проектировании ПАК GPU становится центральным элементом, вокруг которого выстраиваются все остальные компоненты: шины, память, питание, охлаждение и сеть. Это смена парадигмы: GPU — не плата расширения, вокруг которой компонуется сервер, а основной вычислительный ресурс, под который проектируется всё остальное. Если не учесть эту инверсию на этапе проектирования, получится просто дорогой сервер с GPU. Стандартный сервер не проектировался под подобный профиль нагрузок, стандартный ЦОД — тоже.
В качестве примера приводится поддержка нескольких типов GPU, каждый из которых ориентирован на свой класс задач. NVIDIA H200 предназначена для крупных языковых моделей от 30 млрд параметров, обеспечивая до 30-кратного ускорения инференса за счёт Transformer Engine с FP8 и памяти HBM3e объёмом до 141 ГБ с пропускной способностью 4,8 ТБ/с; тензорные ядра четвёртого поколения поддерживают весь спектр точностей — FP64, TF32, FP16, INT8, FP8, а по сравнению с H100 даётся до 2x ускорения LLM inference. Для инференса GPU-узлы могут комплектоваться двумя изолированными сегментами по четыре карты, что позволяет развёртывать модели до 70 млрд параметров; сетевая связность здесь менее важна, поэтому высокопроизводительные PCIe x16 отдаются под графические карты, а на сеть остаются карты 25 GbE и/или 100 GbE. Для дообучения используется один сегмент с четырьмя H200, и решающую роль играет межсетевое взаимодействие: применяются сетевые карты 400 GbE, по одной на каждую GPU, чтобы избежать конкуренции за пропускную способность. Альтернативой выступают RTX 6000 Pro с 96 ГБ GDDR7 с ECC и 512-битной шиной, поддержкой FP4 (NVFP4), FP8, FP16/BF16, TF32, FP32 (около 126 TFLOPS), FP64, INT8/INT4/INT1 — они дают до +50% токенов на рубль в нетяжёлых задачах инференса при существенно меньшем CAPEX по сравнению с топовыми решениями с жидкостным охлаждением. Также упоминаются Moore Threads MTT S4000 с архитектурой MUSA и CUDA-совместимостью через MUSIFY, а также MetaX C500 для масштабируемого инференса средних моделей.
Контекст разработки связан с предыдущими материалами цикла, где обсуждался выбор между самостоятельной сборкой и готовым ПАК (на примере ПАК Скала^р). Тогда отмечалось, что заказчик осознаёт все риски самосбора лишь через полгода эксплуатации. Нынешняя статья углубляется в инженерные решения, показывая, почему стандартный ЦОД не подходит для ИИ. Рынок аппаратного обеспечения для ИИ быстро развивается: конкуренция между NVIDIA, китайскими производителями и новыми архитектурами растёт. В ответ на это вендоры предлагают всё более специализированные комплексы, учитывающие особенности нагрузки. Приводится чеклист из пяти вопросов, которые стоит задать поставщику перед закупкой, что подчёркивает важность экспертизы при выборе инфраструктуры. Показательно, что в тестах на ПАК запускали две модели MWS AI: старшую Cotype Pro 3 размером 27 млрд параметров и облегчённую Cotype Light 3 на 9 млрд параметров.
Для российского рынка эта тема особенно актуальна в свете импортозамещения и ограничений на поставки западного оборудования. ПАК на базе китайских GPU, таких как Moore Threads и MetaX, демонстрируют результаты, сопоставимые с NVIDIA H100 в отдельных сценариях инференса. Например, при контексте около 27 000 токенов модель начинает отвечать через 8 секунд, а интервал между токенами составляет от 111 мс (до 9 токенов в секунду). Настройка драйверов и программного окружения позволила повысить производительность в 2–2,2 раза. Это открывает возможности для создания решений в закрытом контуре, что важно для компаний, работающих с чувствительными данными. Однако остаются вопросы совместимости с существующим стеком и доступности компонентов. Отдельно стоит учитывать, что задачи обучения по профилю нагрузки существенно отличаются от стандартной серверной работы, и это влияет на требования к каждому слою ПАК.
Сравнение с альтернативами показывает, что выбор GPU зависит от задачи. H200 ориентирована на максимальную производительность в обучении и крупном инференсе, но требует значительных затрат на инфраструктуру, включая жидкостное охлаждение. RTX 6000 Pro предлагает лучшую экономическую эффективность для менее требовательных нагрузок, хотя и уступает в пиковой производительности. Китайские ускорители выигрывают в вопросах реестровой принадлежности и миграции CUDA-кода, но их экосистема пока менее развита. Таким образом, универсального решения нет — необходим тщательный подбор под конкретные сценарии, а пороги замены одного решения другим напрямую связаны с деньгами и производительностью.
В будущем ожидается дальнейшее развитие аппаратного стека для ИИ, включая более эффективные системы охлаждения и питания. Открытыми остаются вопросы масштабируемости при переходе к моделям с сотнями миллиардов параметров, а также стандартизации интерфейсов между различными производителями. Следующая статья цикла будет посвящена сетям интерконнекта для ИИ-задач, что дополнит картину построения полноценного ПАК. Пока же ясно одно: проектирование железа для ИИ — это сложная инженерная задача, требующая глубокого понимания как вычислительных процессов, так и физических ограничений оборудования. И именно от того, насколько точно удастся согласовать все слои — от GPU до хранения, — зависит, окупится ли инфраструктура и будет ли она готова к следующим поколениям моделей.