Зачем вообще CPU-инференс? Графическая карта сгорела, бюджет кончился
Представьте ситуацию: нужно запустить Meta-Llama-3.1-70B локально. RTX 4090 не хватает памяти. Две RTX 4090 — это уже стоимость небольшой иномарки. Четыре MI50 из статьи про бюджетного монстра требуют отдельной серверной и молитв богам ROCm. А что если просто... процессор?
AMD Epyc 9175F выглядит на бумаге идеально: 16 ядер, 32 потока, поддержка памяти до 6 ТБ (серьезно, кто-то проверял?), и главное — заявленная пропускная способность памяти 600 ГБ/с. Цифра красивая. Звучит как решение всех проблем. Но между спецификациями на сайте AMD и реальным инференсом Llama 3.1 лежит пропасть, заполненная разочарованием и вопросами "почему так медленно?".
Спойлер: те самые 600 ГБ/с — это теоретический максимум для всего процессора при идеальных условиях. В реальности llama.cpp с его оффлоадингом слоев на CPU никогда не увидит и половины этой цифры. Но об этом позже.
Стенд: что мы тестировали и как обманывали себя
Конфигурация тестового стенда максимально простая, чтобы исключить все, кроме процессора и памяти:
- CPU: AMD Epyc 9175F (16C/32T, 4.0 GHz boost)
- Память: 256 ГБ DDR5-4800 (8 каналов, именно так — это не опечатка)
- Модель: Meta-Llama-3.1-70B-Instruct-Q4_K_M (через llama.cpp)
- Сравнение: Apple MacBook Pro M3 Max (16-core CPU, 40-core GPU, 128 ГБ унифицированной памяти)
- Метрика: Токенов в секунду (t/s) на промпте длиной 512 токенов, генерация 256 токенов.
| Платформа / Конфигурация | Скорость (t/s) | Загрузка CPU | Потребление (Вт) |
|---|---|---|---|
| Epyc 9175F (все ядра, Q4_K_M) | 1.8 - 2.1 | ~85% | 280-320 Вт |
| Epyc 9175F (8 ядер, offloading) | 1.2 - 1.4 | ~45% | ~180 Вт |
| M3 Max (CPU только, Metal offload) | 3.5 - 4.2 | ~60% CPU, 70% GPU | ~45 Вт |
| M3 Max (полный Metal, все слои на GPU) | 8.7 - 9.5 | ~20% CPU, 95% GPU | ~65 Вт |
Цифры говорят сами за себя. M3 Max в режиме полного Metal-оффлоадинга почти в 5 раз быстрее Epyc 9175F, работающего на всех ядрах. И делает это при в 5 раз меньшем энергопотреблении. Эпично? Скорее эпично провально для Epyc.
Где же обещанные 600 ГБ/с? Ловушка архитектуры Zen 4c
Вот тут начинается самое интересное. AMD пишет "до 600 ГБ/с" — и технически не врет. Но эта цифра достигается при одновременном доступе ко всем 12 каналам памяти DDR5-4800, которые поддерживает платформа SP5. Наш тестовый стенд имел "всего" 8 каналов, что давало теоретический максимум около 400 ГБ/с.
Почему? Потому что архитектура Zen 4c в Epyc 9175F оптимизирована для плотности ядер, а не для максимальной скорости каждого отдельного ядра. Когда вы запускаете инференс, вы упираетесь не только в память, но и в:
- Латентность доступа к кешу L3: общий кеш 64 МБ на 16 ядер — это 4 МБ на ядро. Llama 3.1 с ее миллиардами параметров постоянно выталкивает данные из кеша.
- Скорость AVX-512 инструкций: да, они есть, но нагрузка на инференс в основном целочисленная (INT8, INT4), а не floating point.
- Синхронизацию между потоками: 32 потока — это хорошо для рендеринга видео. Для последовательного инференса LLM это часто избыточно, и накладные расходы на управление потоками съедают преимущество.
M3 Max: почему Apple Silicon просто издевается над x86 в этой дисциплине
Сравнение не совсем честное — и в этом вся соль. M3 Max использует унифицированную память, где GPU и CPU видят один адресное пространство. Когда llama.cpp (через Metal) оффлоадит слои, данные не копируются между устройствами. Они уже там.
На Epyc же, даже если бы мы подключили GPU (например, как в статье про 7900 XTX и ROCm), данные модели пришлось бы держать в системной памяти, а затем частями перекачивать в память GPU через PCIe 4.0/5.0. И вот тут вспоминаем, что PCIe 5.0 — не панацея. Пропускная способность PCIe 5.0 x16 — это около 63 ГБ/с в одну сторону. Против 800 ГБ/с пропускной способности памяти M3 Max. Разница на порядок.
Ошибка, которую все совершают: покупать Epyc 9175F или аналогичный CPU с мыслью "у меня будет много памяти, и я буду гонять большие модели на CPU". На практике, если модель не помещается в память GPU, ее инференс на CPU будет настолько медленным, что использовать его в интерактивном режиме станет невозможно. Это сценарий для пакетной обработки, где за ночь можно сгенерировать 1000 ответов.
Когда Epyc 9175F все-таки имеет смысл? Три нишевых сценария
Не все так плохо. Есть ситуации, где этот процессор не просто уместен, а оптимален:
1 Сервер оффлоадинга для множества мелких запросов
Представьте, что у вас есть локальный ассистент, к которому подключены 10-20 пользователей. Каждый делает короткие запросы к Llama 3.1-8B. Epyc с его множеством ядер может параллельно обслуживать множество таких легковесных инференсов, выделяя по 2-4 ядра на запрос. Пропускная способность памяти здесь важнее, чем latency одного запроса.
2 Хостинг MoE-моделей с оффлоадингом "холодных" экспертов
В Mixture of Experts моделях типа DeepSeek V3.2 не все эксперты активны одновременно. "Горячих" экспертов можно держать на GPU (например, на тех самых 16 картах MI50), а "холодных" — выгружать в огромную оперативную память Epyc. При необходимости активации эксперт быстро подгружается обратно в GPU. Здесь 256+ ГБ памяти Epyc — не роскошь, а необходимость.
3 Стенд для тестирования и отладки больших моделей
Когда вы экспериментируете с новыми архитектурами моделей или методами квантования, возможность загрузить модель целиком в оперативку и не думать о сегментации по GPU — бесценна. Скорость не критична, важна возможность запуска. Epyc 9175F с 512 ГБ RAM спокойно примет Llama 3.1-70B в формате Q4 и еще останется место для операционной системы и браузера с сотней вкладок.
Оптимизация llama.cpp под Epyc: что реально работает, а что — нет
По умолчанию llama.cpp не настроен для максимальной производительности на серверных процессорах. Вот что стоит попробовать:
# Неправильно: просто запустить с максимальным количеством потоков
./llama-cli -m llama-3.1-70b-q4_k_m.gguf -p "Your prompt" -t 32 -ngl 0
# Лучше: ограничить потоки и привязать к конкретным NUMA-нодам
numactl --cpunodebind=0 --membind=0 ./llama-cli -m model.gguf -p "Prompt" -t 16 -ngl 0 -b 512
# Еще лучше: использовать слоистый оффлоадинг, если есть хоть какая-то GPU
./llama-cli -m model.gguf -p "Prompt" -t 8 -ngl 20 -b 512 --no-mmapФлаг -b 512 (batch size) важен — он уменьшает количество обращений к памяти за счет предзагрузки большего контекста. На Epyc это дает прирост 15-20% по сравнению с дефолтными настройками.
Вердикт: кому продали этот процессор для AI?
Epyc 9175F — отличный процессор для виртуализации, баз данных, веб-серверов с тысячами одновременных подключений. Но позиционировать его как решение для CPU-инференса больших языковых моделей — маркетинговая натяжка.
Если вам нужен быстрый инференс для интерактивной работы с Llama 3.1-70B, смотрите в сторону:
- Mac Studio M3 Ultra (из наших тестов он показывает феноменальные результаты для своей цены)
- Система с 2-4 RTX 4090 и правильной настройкой tensor parallelism
- Сервер с картами H100/H200 (если бюджет позволяет купить небольшую страну)
Epyc 9175F оставляем для энтузиастов, которые собирают тихого монстра не для скорости, а для возможности сказать "у меня в оперативке лежит вся Llama 3.1, и еще место осталось". Иногда этого достаточно.
Что будет дальше? Прогноз на 2025
AMD уже анонсировала процессоры с 3D V-Cache для серверов. Представьте Epyc с 1 ГБ L3 кеша на чипе. Это может кардинально изменить ситуацию с CPU-инференсом, потому что значительная часть весов модели сможет находиться в сверхбыстром кеше, а не в оперативной памяти. Пропускная способность кеша измеряется терабайтами в секунду — на порядок выше, чем у самой быстрой DDR5.
До тех пор правило простое: для инференса берем GPU с большим объемом памяти или Apple Silicon. CPU оставляем для того, что он умеет делать хорошо — считать много параллельных задач, а не одну последовательную максимально быстро.
