AI‑инференс и большие данные: как российским компаниям подобрать оптимальное сочетание CPU, GPU и памяти

В условиях санкций и роста интереса к AI‑продуктам российские компании всё чаще пытаются “решить всё GPU” — закупают дорогие ускорители под задачи, которым достаточно CPU и большой памяти. В результате бюджет легко раздувается на 40% и выше, а часть GPU простаивает недогруженной. Эта статья помогает архитекторам и data‑science‑командам подобрать комбинацию CPU + GPU + DDR5‑памяти под онлайн‑инференс, пакетную аналитику и ETL, удержав трёхлетний TCO ниже примерно 1,6× от стоимости закупки.

Классифицируем нагрузки: инференс против больших данных

Базовая ошибка — пытаться обслуживать и LLM‑чат, и Spark‑ETL на одном и том же профиле “монструозного” GPU‑сервера. Гораздо эффективнее разделить нагрузки на три класса: онлайн‑инференс, пакетный AI‑инференс и большие данные (Spark/Hadoop/ETL) и уже под них подбирать CPU, GPU и память.

• Онлайн‑инференс: диалоги, рекомендации, визуальный скоринг с целевой задержкой <50 мс; здесь критичны TFLOPS и пропускная способность GPU‑памяти, поэтому выгодны специализированные ускорители NVIDIA с Tensor Cores и NVLink.
• Пакетный инференс и аналитика: периодический прогон больших батчей данных, где допустима более высокая задержка, но важна пропускная способность по данным; CPU и NVMe‑кеш могут частично заменить дорогое GPU.
• Большие данные и ETL: Spark, Hadoop, Dask, где узким местом чаще выступает объём и полоса памяти DDR5; здесь AMD EPYC выигрывает за счёт числа каналов и ёмкости, тогда как GPU используется точечно (например, RAPIDS) и далеко не для всех job‑ов.

Для каждого класса имеет смысл заранее считать бюджет FLOPS и пропускную способность памяти, ориентируясь на размер модели, batch size и целевую задержку. Малые модели до ~1 млрд параметров во многих случаях рационально держать на CPU‑инференсе, экономя дефицитные GPU‑слоты и энергию.

Онлайн‑инференс: когда решает GPU, а когда хватит CPU

Для LLM‑чатов, рекомендательных систем и real‑time компьютерного зрения требования по задержке и количеству запросов в секунду почти всегда выводят архитектуру на GPU‑акселераторы. GPUs благодаря высокой параллельности и пропускной способности HBM/GDDR‑памяти дают существенно лучшую производительность при инференсе, чем CPU, особенно на больших моделях.

В классах A100/H100 Tensor Cores дают максимальную производительность на крупных моделях, но их TCO и санкционные ограничения требуют очень аккуратного обоснования. Для среднего LLM‑инференса часто выгоднее использовать более доступные A40/L40S или несколько A100 вместо единичных H100, добиваясь загрузки ускорителей >70% по TFLOPS и соблюдая целевые 50 мс по задержке.

Большие данные и ETL: ставка на CPU и память

Spark, Hadoop и тяжёлые ETL‑пайплайны чаще всего упираются не во FLOPS, а в полосу и объём оперативной памяти и скорость NVMe. Современные AMD EPYC благодаря большему числу каналов DDR5 и ёмкости на сокет обеспечивают более высокую пропускную способность памяти, чем многие линейки Intel Xeon, что важно для in‑memory‑вычислений.

Практика показывает, что для Spark‑нагрузок увеличение каналов DDR5 и оптимальная раскладка модулей по слотам дают больший прирост, чем дополнительные несколько десятков ядер CPU. В то же время GPU‑ускорение библиотеками RAPIDS и аналогами оправдано лишь там, где профилирование показывает кратный выигрыш по времени при приемлемом росте TCO.

Память и NVMe: Samsung, Micron или SK Hynix?

Для AI‑инференса и in‑memory‑аналитики DDR5‑память становится ключевым ресурсом: объём, задержки, поддержка ECC и доступность под санкциями напрямую влияют на стабильность и скорость. Крупные вендоры — Samsung, Micron и SK Hynix — предлагают разные типы ECC‑модулей (RDIMM, LRDIMM, 3DS), которые по‑разному подходят под тренинг, инференс и большие данные.

В реальных проектах часто используется смешанная стратегия: Samsung для низколатентного инференса и фронтов, Micron для “тяжёлых” batch‑задач и обучения, SK Hynix — для узлов с максимальной ёмкостью памяти. Помимо этого NVMe‑слой строится на сериях, оптимизированных либо под чтение, либо под записи и смешанные профили, что особенно важно для логов и промежуточных данных ETL.

Типичные ошибки и расчёт TCO для смешанных нагрузок

В российских условиях часто встречаются либо “перегретые” конфигурации с избыточным количеством H100 под малые модели, либо кластеры ETL без ECC‑памяти и мониторинга, где единичный бит‑флип убивает часами считавшийся job. При этом электроэнергия и охлаждение легко превращают 3‑летний TCO в сумму, значительно превосходящую закупочную стоимость железа.

• Избыточный выбор H100 под малые модели: для моделей <7B параметров часто достаточно A40/L40S или CPU‑инференса, особенно если в приоритете стоимость и энергопотребление, а не рекордный throughput.
• Большие данные без ECC: отказ от ECC‑модулей в Spark/Hadoop‑узлах ради экономии приводит к трудноотлавливаемым ошибкам в данных; для корпоративной аналитики это неприемлемый риск.
• Игнор NVLink/NVSwitch: при нескольких GPU внутри узла пропускная способность шины становится критичной; меж‑GPU обмен по NVLink даёт кратный выигрыш против чистого PCIe, особенно для тензорного параллелизма.

FAQ: частые вопросы про выбор CPU, GPU и памяти

Материал основан на внутренних проектах Elishtech и открытых источниках о серверных платформах AMD EPYC, Intel Xeon, NVIDIA GPU и DDR5‑памяти ведущих вендоров. Конкретные спецификации и наличие оборудования уточняются индивидуально под запрос.