Зачем это читать, если у всех есть GPU?
Потому что у 90% компаний нет бюджета на ферму H100. Потому что облачные API съедают прибыль. Потому что иногда нужно запустить модель на сервере, где единственное, что есть - 256 ГБ оперативки и старый добрый Xeon.
Я три недели мучил три модели на двух разных CPU-серверах. Цель простая: понять, какая из современных больших моделей ещё хоть как-то работает на процессоре. Не на M3 Max, не на Threadripper, а на нормальном серверном железе, которое стоит в дата-центре.
Спойлер: 7-11 токенов в секунду - это не ошибка. Это реальность 2025 года для 120-миллиардных моделей на CPU.
Если вы ждёте магических 50 токенов в секунду - закройте статью. Здесь только правда, и она горькая. Но рабочая.
Что мы тестировали и на чём
Три модели, которые сейчас на слуху у всех, кто работает с open-source LLM:
| Модель | Параметры | Контекст | Квантование | Размер на диске |
|---|---|---|---|---|
| GPT-OSS 120B | 120 миллиардов | 32K | Q4_K_M | ~68 ГБ |
| Gemma 3n E4B | 4 миллиарда | 128K | Q4_K_M | ~2.4 ГБ |
| Mistral Large 3 | ~24 миллиарда | 64K | Q4_K_M | ~13.5 ГБ |
Железо было таким:
- Сервер 1: 2x Intel Xeon Gold 6348 (56 ядер, 112 потоков), 512 ГБ DDR4-3200
- Сервер 2: AMD EPYC 9175F (32 ядра, 64 потока), 256 ГБ DDR5-4800
Да, тот самый EPYC 9175F, про который я писал в статье про CPU-инференс. Он здесь не главный герой, но появляется в камео.
Цифры, которые всех ждут
Забудьте про синтетические бенчмарки. Я тестировал на реальных промптах:
- Генерация кода на Python (200 токенов)
- Анализ технической документации (500 токенов контекста + 100 токенов ответа)
- Перевод с русского на английский (300 токенов)
| Модель | Xeon Gold 6348 (токенов/сек) |
EPYC 9175F (токенов/сек) |
Пиковая RAM | Загрузка CPU |
|---|---|---|---|---|
| GPT-OSS 120B Q4_K_M | 7.2 | 8.9 | ~240 ГБ | 98% |
| Gemma 3n E4B Q4_K_M | 42.5 | 51.3 | ~8 ГБ | 65% |
| Mistral Large 3 Q4_K_M | 18.7 | 22.1 | ~45 ГБ | 85% |
Видите разницу между Xeon и EPYC? Это не погрешность. Это DDR5 против DDR4 и более агрессивный буст у AMD. Если выбираете железо специально для CPU-инференса - читайте мою статью про EPYC 9175F.
Почему GPT-OSS 120B еле дышит
Не в архитектуре дело. Проблема в математике.
120 миллиардов параметров в формате Q4_K_M - это примерно 60 ГБ весов. Плюс кеш для контекста. Плюс overhead llama.cpp. Когда вы запускаете инференс, эти 60+ ГБ нужно постоянно читать из RAM.
Пропускная способность DDR4-3200 в двухканальном режиме на ядро - около 25 ГБ/с. Но когда 112 потоков пытаются читать одни и те же данные... получается очередь. Длинная очередь.
Главный миф: «Больше ядер = быстрее LLM». Неправда. После определённого порога дополнительные ядра просто стоят в очереди за доступом к памяти.
На EPYC ситуация лучше из-за DDR5-4800 и архитектуры Chiplet. Но всё равно - вы упрётесь в лимиты памяти, а не в вычислительную мощность.
Gemma 3n E4B: маленький, но дерзкий
4 миллиарда параметров. 2.4 ГБ на диске. 8 ГБ RAM в работе.
Эта модель - тёмная лошадка тестов. Она не просто быстрая. Она невероятно быстрая для своего размера. 51 токен в секунду на EPYC - это уровень некоторых 7B-моделей на бюджетных GPU.
Почему? Google сделали две умные вещи:
- Архитектура оптимизирована для инференса (меньше операций на токен)
- Модель помещается в кеш L3 процессора (частично, но это важно)
Если вам интересно, как ведёт себя самая маленькая модель семейства, у меня есть отдельная статья про Gemma 3 270M. Но E4B - это другой уровень.
Mistral Large 3: золотая середина?
24 миллиарда параметров. 13.5 ГБ на диске. 18-22 токена в секунду.
Здесь интересная история. Mistral Large 3 показывает лучший баланс между качеством и скоростью. 22 токена в секунду - это уже почти интерактивная скорость. Можно вести диалог без ощущения, что ждёшь автобус.
Но есть нюанс: качество ответов. В моих тестах Mistral Large 3 consistently outperformed Gemma 3n E4B в сложных reasoning-задачах. Заплатить 3x замедлением за 2x улучшение качества - стоит ли оно того?
Как правильно настроить llama.cpp для CPU
Вот где большинство обламывается. Стандартные настройки - путь в никуда.
1 Количество потоков - не всё, что нужно
Типичная ошибка: -t 0 (использовать все потоки). Не делайте так.
Для больших моделей типа GPT-OSS 120B оптимально: количество физических ядер * 1.5. Для 56 ядер - 84 потока. Почему? Потому что Hyper-Threading помогает скрыть латентность доступа к памяти.
# ПЛОХО для GPT-OSS 120B:
./main -m gpt-oss-120b-q4_k_m.gguf -t 0
# ХОРОШО для GPT-OSS 120B:
./main -m gpt-oss-120b-q4_k_m.gguf -t 84 --threads-batch 42
2 batch-потоки - секретное оружие
Параметр --threads-batch контролирует, сколько потоков работает над одним batch. Для CPU с большим количеством ядер уменьшайте это значение.
Эмпирическое правило: --threads-batch = общее_количество_потоков / 2
3 Размер batch - не трогайте
Не меняйте -b (batch size) на CPU. Оставьте 512. Увеличение batch size даёт прирост на GPU, но на CPU чаще всего замедляет из-за нехватки кеша.
Ошибки, которые съедят вашу производительность
Ошибка 1: Запуск на виртуалке без pinned memory. Если ваш CPU-сервер - виртуальная машина, проверьте настройки гипервизора. Memory ballooning убивает производительность LLM.
Ошибка 2: NUMA без настройки. На многопроцессорных системах (2+ CPU) модель должна целиком находиться в памяти одного NUMA-узла. Используйте numactl:
# ПЛОХО:
./main -m model.gguf
# ХОРОШО для 2-процессорной системы:
numactl --cpunodebind=0 --membind=0 ./main -m model.gguf -t 28
Ошибка 3: Неправильный swappiness. Linux по умолчанию слишком агрессивно использует swap. Для LLM-сервера установите:
echo 1 > /proc/sys/vm/swappiness
Что выбрать для production?
Зависит от того, что вы называете production.
GPT-OSS 120B - только если:
- Качество ответов критически важно
- У вас есть 256+ ГБ RAM
- Латентность 10+ секунд приемлема
- Параллельных запросов не больше 2-3 одновременно
Gemma 3n E4B - если:
- Нужно обслуживать много пользователей (см. расчёт инфраструктуры для 1000 запросов)
- Бюджет на железо ограничен
- Задачи относительно простые (классификация, извлечение информации)
Mistral Large 3 - золотая середина для:
- Чат-ботов с хорошим качеством ответов
- Анализа документов средней сложности
- Сценариев, где важна и скорость, и качество
А что насчёт GPU?
Справедливый вопрос. Если у вас есть возможность поставить хотя бы одну RTX 4090 (24 ГБ) - Mistral Large 3 будет давать 80-100 токенов в секунду. В 4-5 раз быстрее.
Но это если у вас есть GPU. А если нет? Если вы в дата-центре, где можно арендовать сервер с 512 ГБ RAM за $500 в месяц, но сервер с A100 стоит $5000?
Математика простая: 10 токенов в секунду на CPU против 100 на GPU. Но цена - 10x разница. Иногда 10 токенов в секунду - это то, что нужно бизнесу.
Что будет через год?
Мой прогноз: CPU-инференс не умрёт. Он станет нишевым, но важным.
Почему? Потому что закон Мура для видеокарт упёрся в стену. H100 уже стоит как автомобиль. H200 будет стоить как квартира. А серверы с терабайтами RAM становятся дешевле.
Следующее поколение моделей (Gemma 4, Llama 4) будет ещё более оптимизировано для инференса. Возможно, мы увидим специализированные CPU-инструкции для матричных умножений (как AMX у Intel).
А пока - 7-11 токенов в секунду для 120B-моделей. Медленно? Да. Работает? Тоже да.
Иногда лучшее - враг хорошего. Иногда 7 токенов в секунду - это всё, что нужно, чтобы автоматизировать процесс, который раньше делал человек за час.
P.S. Если вы запускаете LLM на CPU в продакшене - поделитесь вашими цифрами в комментариях. Особенно интересны случаи с нестандартным железом (ARM-серверы, мейнфреймы, кто знает).
