CPU и RAM для AI/LLM: как не «задушить» GPU и снизить латентность

ИИ-сервер — это не только видеокарты. Недооценка роли процессора и оперативной памяти приводит к простаиванию GPU, росту задержек и подорожанию запроса. Ниже — сжатое, но профессиональное руководство по sizing и архитектурным решениям.

Ключевые роли CPU и RAM

CPU обеспечивает токенизацию, препроцессинг/постпроцессинг, сетевые вызовы, планирование задач, работу data-loader’ов.
RAM удерживает кэши и очереди батчей, буферы фреймворков, индексы, KV-кэши длинных контекстов и системный запас. Слабые звенья здесь превращают GPU в «ожидающий ресурс».

Нормативы для sizing

Инференс LLM

• CPU: 8–12 ядер на каждый активный GPU. При высоком RPS и тяжёлом постпроцессинге держите ближе к 12.
• RAM: не ниже ×2 от суммарной VRAM всех GPU, минимум 128 ГБ на узел.

Обучение / дообучение

• CPU: 12–24 ядра на GPU (много параллельных загрузчиков и аугментаций).
• RAM: ×3–4 от суммарной VRAM. Нижняя граница — для «чистых» пайплайнов, верхняя — при агрессивных аугментациях.

Резерв: +20–30% к расчётам для пиков и служебных буферов.

Методика быстрой оценки

1. Сложите объём VRAM всех GPU.
2. Инференс: умножьте результат на 2 и округлите вверх до ближайших 64 ГБ.
3. Обучение: умножьте на 3 (или на 4 при активных аугментациях).
4. Добавьте 20–30% запаса.
5. CPU: 8–12 ядер/GPU (инференс) или 12–24 (обучение). При 200–600 RPS умножьте итог на коэффициент 1,2–1,5.

Кейс-примеры

A. 2×GPU по 48 ГБ, чат-бот, окно 8k, до 300 RPS

• CPU ≈ 26 ядер → берём 32 с запасом.
• RAM: 2×(48+48)=192 ГБ → берём 256 ГБ.

B. 4×GPU по 48 ГБ, контексты 16–32k, ~400 RPS

• CPU ≈ 56 ядер → берём 64.
• RAM: 2×(48×4)=384 ГБ → берём 512 ГБ.

C. 8×GPU по 80–192 ГБ, LoRA/SFT + периодический инференс

• CPU ≈ 96 ядер.
• RAM: ×3 от суммарной VRAM → счёт на терабайты.

Параметры, которые сильнее всего влияют

• Контекстное окно: чем длиннее, тем больше KV-кэш → выше требования к RAM и CPU.
• Формат весов (FP16/BF16/INT8/FP8): снижает VRAM, но системная RAM нужна для кэшей и очередей.
• RPS и батчирование: рост батча увеличивает нагрузку на CPU и может расширять «хвост» латентности.
• Диски и сеть: узкий I/O «душит» пайплайн — прогревайте и кэшируйте данные.
• NUMA: в двухсокетных системах привязывайте процессы и GPU к «своему» сокету.

Типовые ошибки и как их избежать

• Недостаточный однопоток → тормоза на декодинге токенов. Берите современные CPU с высокой частотой и большим L3.
• Недобор RAM → своп и «пилообразная» задержка. Держите +20–30% резерва.
• Игнор NUMA → межсокетные задержки. Пиннинг потоков и привязка GPU к локальному узлу.
• Один NVMe «на всё» → I/O-бутылочное горлышко. Разносите датасеты, логи, чекпоинты по отдельным пулам.
• Отсутствие мониторинга → сложно найти узкие места. Нужны метрики CPU/GPU/RAM/I/O и DRAM-BW.

Базовые ориентиры (инференс)

• 1×GPU 24–48 ГБ, до 200 RPS, 4–8k → 8–16 ядер, 128–256 ГБ RAM.
• 2–4×GPU 48 ГБ, 200–600 RPS, 8–16k → 24–48 ядер, 256–512 ГБ RAM.
• 8×GPU 80–192 ГБ HBM → 64–96 ядер, 512 ГБ – 1,5 ТБ RAM.

Контрольный список перед продом

• Проверен однопоток CPU и L3.
• Рассчитана RAM (методика + резерв).
• Настроен NUMA-пиннинг процессов и привязка GPU.
• Разведён I/O: датасеты, логи, чекпоинты, своп.
• Включено профилирование: утилизация GPU, DRAM-BW, HtoD/DtoH, latency на токен.

Чем поможем

MDM Electronics подберёт CPU и RAM под вашу модель, окна и целевые RPS; соберём сервер или кластер, настроим NUMA и проверим конфигурацию на ваших данных.
Нужен расчёт под задачу — подготовим 2–3 конфигурации с бюджетом, ожидаемой производительностью и планом масштабирования.