Как выбрать сервер для ИИ: отличия специализированных AI серверов от обычных решений

Выбор сервера для искусственного интеллекта — это не просто покупка мощного железа. AI-серверы 2026 года используют гетерогенную конфигурацию CPU+GPU, где ускорители AI-серверов выполняют параллельные матричные операции и тензорные расчёты для обучения и инференса моделей. В отличие от традиционных Enterprise-платформ, рассчитанных на последовательную обработку задач процессором, графические ускорители AI-серверов потребляют сотни ватт энергии каждый. Это требует специализированного жидкостного охлаждения, высокопроизводительной памяти HBM и усиленных линий питания.

Рынок AI-серверов вырос с $83,33 млрд в 2025 году до $88,29 млрд в 2026 году, и ускоренные серверы остаются основным драйвером инвестиций в AI-инфраструктуру. При этом неверный выбор конфигурации приводит к троттлингу GPU, Out of Memory ошибкам и простоям дорогостоящего оборудования. Разберём, как избежать типовых ошибок и подобрать сервер под реальные задачи.

Требования к серверу для обучения моделей машинного обучения и для их внедрения (инференса) кардинально различаются. Обучение упирается в VRAM и скорость обмена градиентами между GPU, инференс — в задержку первого токена и пропускную способность при батчинге. Неправильный выбор конфигурации приводит либо к замедлению обучения в 5–15 раз из-за узкого места PCIe, либо к высоким latency в продакшене.

Обучение современных LLM и GenAI-моделей упирается в два фактора: объём VRAM и пропускную способность обмена данными между GPU. Модель Llama 3 70B в FP16 требует примерно 148–168 ГБ VRAM только для весов, плюс дополнительное место для градиентов, активаций и состояния оптимизатора. Это означает, что одного GPU H100 (80 ГБ) или H200 (141 ГБ) недостаточно: нужен tensor parallelism на 2–4 GPU или data parallelism на 4–8 GPU.

При multi-GPU обучении возникает бутылочное горлышко: каждый GPU должен обмениваться градиентами (гигабайты данных на итерацию) с другими ускорителями. PCIe Gen4 x16 даёт примерно 32 ГБ/с bidirectional — этого мало для 4+ GPU. NVLink обеспечивает до 900 ГБ/с между GPU (на примере H100), снижая задержки обмена параметров.

NVSwitch 7.2T объединяет до 576 GPU в едином домене, позволяя масштабировать обучение без деградации производительности. 800G коммутаторы поддерживают кластеры до 100 000 ускорителей — такая архитектура используется в крупных AI-лабораториях.

Инференс (развёртывание обученной модели) делится на два класса: latency-critical (realtime, низкая задержка) и throughput-oriented (batch processing, высокая пропускная способность). Неправильный выбор GPU и квантизации приводит либо к высоким latency для пользователей, либо к переплате за избыточную мощность.

Квантизация (INT8/FP8/FP16) как способ удешевления:

Квантизация снижает точность вычислений с 32 бит (FP32) до 8 бит (INT8/FP8), уменьшая требования к VRAM и ускоряя инференс. Llama 3 70B в FP16 требует примерно 148 ГБ VRAM, в INT8 — 24–48 ГБ (помещается на 2 GPU RTX 6000 Ada с 48 ГБ). При этом потеря точности модели минимальна для большинства задач.

Batching и KV-cache:

KV-cache хранит историю токенов в контексте, занимая значительную часть VRAM при длинном контексте (32K+ токенов). Батчинг увеличивает throughput в 2–10 раз, но повышает VRAM на 20–50% от весов модели. Пример: Llama 3 8B на A100 (80 ГБ) даёт 50–60 tokens/s при batch=1, более 200 tokens/s при batch=8. Latency первого токена растёт с 50–80 мс до 100–150 мс.

Mixtral 8x7B (модель с mixture-of-experts) на A100 показывает 35–45 tokens/s при batch=1, более 120 tokens/s при batch=8, но latency первого токена выше (80–120 мс) из-за routing между экспертами. Квантизация 4-bit (Q4_K_M) позволяет запустить Mixtral на 2 GPU RTX 4090 (48 ГБ суммарно) вместо 4 GPU A100.

Связка CPU и GPU определяет производительность AI-сервера. Типовая ошибка — купить топовые GPU, но «забыть» про CPU с достаточным числом линий PCIe. Результат: GPU простаивают из-за узкого места между процессором и ускорителями.

GPU обменивается данными с CPU, RAM, NVMe и другими GPU через PCIe или NVLink. Если CPU даёт только 64 линии PCIe Gen4, а нужно подключить 4 GPU (каждый требует x16) + NVMe (x4) + сетевую карту (x8), возникает конфликт: часть устройств переходит в режим x8 или x4, теряя до 50% пропускной способности.

Основные узкие места:

Мало PCIe-линий от CPU: AMD EPYC 9005 даёт 128 линий PCIe 5.0 на сокет, Intel Xeon 6 — 80–136 линий. Для 4 GPU нужно минимум 64 линии (4 × x16), плюс запас для NVMe и сети.

Медленный storage: NVMe PCIe Gen3 x4 даёт примерно 3,5 ГБ/с, Gen4 x4 — примерно 7 ГБ/с. При обучении на датасетах более 1 ТБ GPU простаивают, ожидая загрузки батчей. Решение: RAID 0 из нескольких NVMe или распределённая FS.

Нехватка RAM: правило эмпирическое — RAM = 2x VRAM GPU. Для 4 GPU H100 (320 ГБ VRAM) нужно 640 ГБ DDR5 ECC. Без этого модель не загружается в GPU, либо система использует swap, замедляя обучение в разы.

NUMA и латентность: в двухсокетных серверах GPU должны подключаться к ближайшему CPU-сокету. Если GPU на NUMA node 1, а CPU на node 0, задержки доступа к памяти вырастают на 20–60%.

GPU выполняет параллельные матричные операции для forward/backward pass в нейросетях. CPU отвечает за препроцессинг данных, управление обучением и координацию между GPU. Без баланса CPU перестаёт успевать подавать батчи, GPU простаивают (GPU utilization <50%). Рекомендация: 16+ физических ядер CPU на 4 GPU, 32+ ядер на 8 GPU.

GPU H100 использует HBM3 с bandwidth 3,35 ТБ/с, H200 — HBM3e с 4,8 ТБ/с. Это на порядок выше, чем у системной RAM DDR5 (до 200 ГБ/с на канал). HBM критична для memory-bound задач (attention-механизмы в трансформерах), где вычисления ограничены скоростью доступа к весам модели, а не TFLOPS.

Выбор GPU определяется четырьмя критериями: объём VRAM, пропускная способность памяти (HBM), тип интерконнекта (PCIe vs NVLink) и поддержка точности вычислений (FP32/FP16/INT8/FP8). Неправильный выбор приводит к Out of Memory ошибкам или переплате за избыточные характеристики.

VRAM «съедается» тремя компонентами: веса модели, градиенты/оптимизатор (при обучении), KV-cache и batch size (при инференсе). Для компьютерного зрения добавляется разрешение изображений и длительность видео.

• Веса модели: базовый объём (Llama 3 70B FP16 примерно 140 ГБ).
• Градиенты: копия весов для backward pass (ещё примерно 140 ГБ).
• Состояние оптимизатора (Adam): ещё две копии весов (ещё примерно 280 ГБ).
• Активации: промежуточные тензоры forward pass (зависит от batch size, +20–50 ГБ).

Итого для Llama 3 70B при обучении: 140 + 140 + 280 + 50 = примерно 610 ГБ минимум. Это требует 8 GPU H100 (640 ГБ) или 5 GPU H200 (705 ГБ). При использовании техник оптимизации (gradient checkpointing, mixed precision) можно снизить требования, но с замедлением обучения.

Рекомендация — закладывать +20–30% над расчётным значением. Причины: overhead операционной системы, драйверов CUDA, буферы для асинхронных операций. Если модель занимает 22 ГБ, а GPU имеет 24 ГБ, высок риск OOM при росте batch size или длины контекста.

Если модель не помещается в один GPU, есть два пути: model sharding (tensor/pipeline parallelism) на несколько GPU или использование GPU с большей VRAM (переход с H100 80 ГБ на H200 141 ГБ). Первый вариант часто дешевле, но требует NVLink для низких задержек обмена параметрами.

Маркетинговые характеристики GPU часто указывают TFLOPS (триллионов операций с плавающей точкой в секунду), но реальная производительность может ограничиваться memory bandwidth, если задача memory-bound.

• Compute-bound: вычисления (умножение матриц) доминируют над загрузкой данных из памяти. Производительность определяется TFLOPS. Пример: training с большими батчами, где каждый тензор переиспользуется многократно.

• Memory-bound: вычисления простые, но требуют постоянной загрузки данных из VRAM. Производительность определяется HBM bandwidth. Пример: attention-механизмы в трансформерах, где веса модели загружаются для каждого токена.

Пример: H100 (80 ГБ HBM3) даёт 1000 TFLOPS FP16, но пропускная способность памяти 3,35 ТБ/с. При инференсе LLM с длинным контекстом GPU загружает веса модели (условно 140 ГБ) для каждого токена. Если bandwidth недостаточна, TFLOPS простаивают. A100 (40 ГБ) имеет 1,56 ТБ/с — в 2 раза медленнее, что снижает tokens/s в инференсе пропорционально, несмотря на близкие TFLOPS.
H200 с HBM3e даёт 4,8 ТБ/с (на 43% выше H100), что может ускорить инференс больших моделей на 30–40% при тех же TFLOPS. Для задач обучения разница меньше, так как батчинг и повторное использование данных снижают зависимость от bandwidth.

Интерконнект (способ соединения GPU между собой и с CPU) определяет, насколько эффективно GPU обмениваются градиентами, активациями или параметрами модели. PCIe подходит для одиночных GPU или инференса, NVLink — обязателен для multi-GPU обучения.

Для инференса и fine-tuning на 1–2 GPU PCIe Gen4/Gen5 не создаёт узкого места. Данные загружаются в GPU единожды, дальнейшие вычисления идут внутри ускорителя. Даже при batch inference GPU успевает обработать batch за время, пока CPU готовит следующую порцию данных.

Multi-GPU обучение (data parallelism или tensor parallelism) требует постоянного обмена градиентами между GPU. PCIe Gen4 x16 (примерно 32 ГБ/с) создаёт bottleneck: для 4 GPU H100 (каждый генерирует 10–20 ГБ/с градиентов) суммарный трафик 40–80 ГБ/с превышает пропускную способность. Результат: GPU простаивают, ожидая синхронизации. NVLink даёт 900 ГБ/с на пару GPU, снимая ограничение.

Точность вычислений (число бит на число) определяет компромисс между качеством модели, скоростью и требованиями к VRAM. Современные GPU поддерживают mix-precision training и квантизацию для ускорения.

FP32 (32 бита): высокая точность и диапазон, стандарт для обучения до 2020 года. Сегодня используется редко из-за высоких требований к памяти (в 2 раза больше, чем FP16).

FP16 (16 бит): в 2 раза меньше VRAM, в 2 раза быстрее вычисления на Tensor Cores. Склонен к underflow (очень малые числа обнуляются), что требует loss scaling при обучении. Стандарт для inference и mixed precision training.

BF16 (Brain Float 16): сохраняет диапазон чисел как FP32, но точность как FP16. Устраняет проблему underflow. Рекомендуется для обучения на современных GPU (H100/A100) и TPU.

INT8 (8 бит): квантизация весов модели для инференса. Llama 3 70B в INT8 занимает 24–48 ГБ вместо примерно 140 ГБ FP16. Точность модели может незначительно снизиться, что допустимо для большинства продакшн-систем. Ускорение инференса в 2–4 раза на edge-устройствах.

FP8 (8 бит, E4M3/E5M2): новый формат от NVIDIA для Blackwell GPU (B200). В 4 раза меньше памяти, чем BF16. Поддерживает block-scaling для снижения потерь точности. Может ускорить обучение foundation models при приемлемой деградации метрик.

CPU в AI-сервере выполняет роль координатора: управляет GPU, загружает данные, препроцессит батчи. Неправильный выбор CPU создаёт bottleneck в линиях PCIe или пропускной способности памяти.

PCIe-линии от CPU определяют, сколько устройств можно подключить на полной скорости. Нехватка линий приводит к переключению GPU в режим x8 или x4, теряя до 50% bandwidth.

Риск: если CPU даёт только 64 линии PCIe, а нужно 4 GPU (64 линии) + NVMe (4 линии) + сетевая карта 100 GbE (x16), суммарно 84 линии — часть устройств переходит в x8, теряя производительность. Решение: использовать PLX-переключатели (разветвители PCIe), но это добавляет 1–2 мкс задержки.

В двухсокетных серверах линии PCIe распределяются между сокетами. Пример: каждый сокет EPYC 9005 даёт 64 линии для GPU. Если установить 4 GPU на один сокет, они работают через один NUMA-узел (низкая задержка). Если распределить по 2 GPU на сокет, возникает NUMA-эффект: обращение GPU к памяти дальнего сокета замедляется на 20–60%.

GPU работают в сотни раз быстрее CPU, поэтому bottleneck смещается на загрузку данных. Нехватка RAM или медленный storage приводят к простою GPU, когда они ждут следующий batch.

Эмпирическое правило: RAM = 2× VRAM GPU (минимум). Для продакшн-систем — 2–4 ГБ RAM на каждый 1 ГБ VRAM GPU.

Storage для AI-задач делится на три уровня: горячие данные (активные датасеты), тёплые (архив обучений, чекпойнты), холодные (долгосрочное хранение).

NVMe PCIe Gen4 x4 стоит условно $100–300 за 1 ТБ, Gen5 — условно $200–500. Если датасет 50 ТБ, полностью на NVMe это значительные затраты. Холодные данные (80% от 50 ТБ примерно 40 ТБ) загружаются раз в месяц — достаточно SATA/NAS за условно $20–50/ТБ. Экономия значительная.

Сеть становится критична при multi-node обучении: GPU на разных узлах обмениваются градиентами через сетевые карты. Медленная сеть или высокая задержка убивают масштабирование.

Сценарий → сеть

Недооценка питания и охлаждения — типовая ошибка, приводящая к троттлингу GPU, аварийным отключениям и сокращению срока службы оборудования.

Оценка потребления

Рекомендация запаса: +20–30% над расчётным значением для пиковых нагрузок и старения компонентов. 3240 Вт × 1,25 примерно 4050 Вт. Нужен БП на 4000–4500 Вт или два БП по 2000–2500 Вт (redundant).

В стойке обычно доступно 15–20 кВт (зависит от ЦОД). Один сервер 4 кВт примерно 5 серверов на стойку. Если превысить лимит, сработает защита PDU, отключив оборудование.

Воздушное охлаждение работает до плотности примерно 20 кВт на стойку. Выше этого порога температура в стойке растёт, GPU троттлят (снижают частоты для защиты), производительность падает на 10–30%.

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

Симптомы:

• OOM (Out of Memory): обучение прерывается с ошибкой "CUDA out of memory".

• Forced offloading: модель частично выгружается в RAM, замедляя обучение в 10–100 раз.

• Низкий batch size: приходится снижать batch до 1–2, что увеличивает время обучения и ухудшает convergence.

• Нестабильная скорость: GPU utilization прыгает от 10% до 90% из-за свопинга.

Что делать:

• Квантизация: переход с FP16 на INT8/FP8 снижает VRAM в 2–4 раза.

• Gradient checkpointing: пересчитывает активации вместо хранения в памяти, экономит 30–50% VRAM за счёт 10–20% замедления.

• Model sharding: распределение модели на несколько GPU (tensor/pipeline parallelism).

• Переход на GPU с большей VRAM: 4 GPU H100 (320 ГБ) → 3 GPU H200 (423 ГБ).

Симптомы:

• Низкая утилизация GPU: nvidia-smi показывает <70% GPU utilization, хотя задача compute-heavy.

• Просадки производительности: обучение идёт 100 samples/s, затем падает до 30 samples/s на несколько секунд.

• Неравномерность между GPU: GPU 0 загружен на 90%, GPU 2 — на 40%.

Причины:

• Нехватка PCIe-линий: GPU работают в режиме x8 вместо x16, пропускная способность упала вдвое.

• NUMA cross-access: GPU 0 обращается к памяти дальнего сокета, задержки выросли в 2 раза.

• PLX-переключатели: использование PCIe-свитчей добавляет 1–2 мкс латентности, снижая производительность синхронизации между GPU.

Симптомы:

• Thermal throttling: GPU снижают частоты при достижении 83–85°C, производительность падает на 10–30%.

• Аварийное отключение: при температуре >90°C GPU выключаются для защиты.

• Сбои питания: PDU отключает стойку из-за превышения лимита kW.

Причины:

• Недостаточное охлаждение: плотность GPU >20 кВт/стойка, воздушное охлаждение не справляется.

• Нехватка мощности БП: суммарное TDP GPU + CPU превышает мощность PSU.

• Неправильная конфигурация ЦОД: холодный/горячий коридоры смешаны, нет изоляции.

Контрольные точки мониторинга:

• Температура GPU: <75°C норма, 75–83°C — предупреждение, >83°C — критично.

• Мощность GPU: должна быть стабильной (±5% от TDP). Если прыгает ±20%, проблема с питанием.

• Частоты GPU: проверка через nvidia-smi -q | grep "Clocks". Падение на 10%+ — троттлинг.

• Вентиляторы: скорость >90% длительно — система не справляется с охлаждением.

Решение:

• Переход на жидкостное охлаждение (DLC).

• Добавление резерва мощности PSU (+20–30%).

• Проверка лимитов стойки и PDU в ЦОД перед установкой.

Пошаговая инструкция для самостоятельного подбора конфигурации.

1. Определение задач: обучение/инференс, LLM/CV/GenAI, размер модели (7B/70B/100B+), частота запросов (RPS), длина контекста.
2. Выбор GPU: определить минимальную VRAM (из раздела «Сколько VRAM нужно»), добавить +20–30% запас.
3. Подбор платформы: PCIe-сервер (до 4 GPU) или HGX/DGX (8 GPU), NVLink для multi-GPU training.
4. Расчёт мощности БП: суммировать TDP GPU + CPU + NVMe + вентиляторы, добавить +20–30% запас.
5. Выбор системы охлаждения: воздушное до 20 кВт/стойка, DLC выше.
6. Подбор CPU: обеспечить достаточные PCIe-линии (16 на GPU + резерв для NVMe/сети), 16+ ядер на 4 GPU.
7. Расчёт RAM: минимум 2× VRAM GPU, комфортно 2–4 ГБ на 1 ГБ VRAM.
8. Выбор NVMe: ≥3 ГБ/с throughput, объём 1–8 ТБ в зависимости от размера датасета, RAID 0 для обучения.
9. Подбор сети: 10–100 GbE для одиночных узлов или inference, InfiniBand для multi-node training.
10. Проверка лимитов площадки: доступная мощность стойки (кВт), охлаждение (PUE), требования к линиям питания (230V/400V).
11. Выбор софта: драйверы NVIDIA/AMD, CUDA/ROCm, PyTorch/TensorFlow — проверка совместимости по матрице.
12. Настройка мониторинга: nvidia-smi exporter, Prometheus/Grafana для GPU utilization/memory/temps.

Ограничения: рекомендации основаны на типовых сценариях; для уникальных задач (custom архитектуры, нестандартные нагрузки) требуется индивидуальный аудит. Мы не гарантируем отсутствие bottlenecks без тестирования реальной нагрузки на подобранной конфигурации.

Источники данных:

Статья основана на следующих типах источников (в порядке приоритета):

1. Официальные спецификации производителей: datasheets NVIDIA (A100/H100/H200, NVLink, CUDA), AMD (Instinct MI300X/MI450X, ROCm), Intel/AMD (Xeon 6, EPYC 9005).
2. Peer-reviewed публикации: документированные исследования по производительности инференса LLM и AI-оптимизации.
3. Отраслевые аналитики и исследования: отчёты по рынку AI-серверов.
4. Документация фреймворков: PyTorch (совместимость CUDA), TensorFlow (ROCm support), NVIDIA Kubernetes Device Plugin.
5. Практический опыт Work System: проекты поставки GPU-серверов для клиентов (2020–2026), анализ типовых ошибок и bottlenecks.