CPU-only MoE: как запустить 120B модели на DDR5 и не сойти с ума

Когда видеокарты сдаются, а 128 ГБ DDR5 — нет

Вы скачали GPT OSS 120B. У вас есть процессор с 32 ядрами и 128 ГБ DDR5-6400. Вы запускаете модель — и получаете 0.8 токенов в секунду. Это не ошибка. Это реальность CPU-инференса в 2026 году.

Но что, если я скажу, что можно получить 5-7 токенов/сек на той же системе? Без видеокарт. Без экзотического железа. Просто грамотная настройка того, что уже есть.

Математика бедных: как рассчитать реальную скорость

Все говорят про «токены в секунду», но никто не объясняет, откуда берутся эти цифры. Давайте разберёмся.

Скорость CPU-инференса ограничена двумя факторами:

1. Пропускная способность памяти (Memory Bandwidth)
2. Вычислительная мощность (FLOPS)

Для MoE-моделей первый фактор критичен. Каждый токен требует загрузки весов экспертов из RAM. Формула простая, но убийственная:

# Пример расчёта для 120B модели
model_size_gb = 120  # миллиардов параметров
quant_bits = 4       # Q4_K_M
active_experts = 2   # активных эксперта из 8

# Размер активных весов в ГБ
active_size_gb = (model_size_gb * quant_bits / 32) * (active_experts / 8)
# 120 * 4/32 * 2/8 = 120 * 0.125 * 0.25 = 3.75 ГБ

# Теоретическая скорость при DDR5-6400 (dual channel)
memory_bandwidth = 102.4  # ГБ/с (DDR5-6400 dual channel)
tokens_per_second = memory_bandwidth / active_size_gb
# 102.4 / 3.75 ≈ 27.3 токенов/сек (теоретический максимум)

Почему вы получаете не 27, а 0.8? Потому что эта формула — идеальный мир. В реальности добавляются:

• Задержки памяти (latency)
• Наложение вычислений и доступа к памяти
• Оверхед llama.cpp
• Тепловые троттлинг

BIOS: где ломают 30% производительности

Заходите в BIOS. Видите десятки настроек. Большинство из них бесполезны для LLM. Но три — критичны.

1 XMP/EXPO: включаем правильно

XMP (Intel) или EXPO (AMD) — это не просто «включить и забыть». Есть нюансы:

Не делайте так:

# Типичная ошибка — активация XMP без проверки стабильности
# Система загружается, но через час работы появляются битые токены
# LLM особенно чувствительны к ошибкам памяти

Делайте так:

1. Активируйте XMP/EXPO Profile 1
2. Запустите memtest86+ на 4 прохода (оставьте на ночь)
3. Если ошибок нет — уменьшите частоту на 200 МГц
4. Повторите тест

Звучит парадоксально? Зачем уменьшать частоту? Потому что стабильность важнее скорости. Одна ошибка в весах эксперта — и вся генерация превращается в бред.

2 Power Limits: снимаем тепловые ограничения

Современные процессоры сами себя тормозят. Intel PL1/PL2, AMD PPT/TDC/EDC — это лимиты мощности. Для LLM их нужно отключать.

# Мониторим троттлинг во время инференса
sudo apt install lm-sensors
sensors | grep "Package id"
# Если температура > 85°C — процессор уже тормозит

# В BIOS ищем:
# - CPU Power Management
# - Long Duration Package Power Limit (PL1)
# - Short Duration Package Power Limit (PL2)
# Устанавливаем в 4096 (максимум) или «Auto»

Но есть подвох: без адекватного охлаждения процессор перегреется и начнёт троттлить ещё сильнее. Нужен баланс.

3 Memory Context Restore: скрытый убийца скорости

Самая странная настройка в современных BIOS. Memory Context Restore ускоряет загрузку, но ломает тайминги памяти. Для LLM — выключаем.

Где искать:

• AMD: AMD CBS → UMC Common Options → DDR Options → Memory Context Restore → Disabled
• Intel: Advanced Memory Settings → Memory Context Restore → Disabled

После отключения система будет загружаться на 5-10 секунд дольше. Зато память заработает на полной скорости.

Операционная система: Linux против Windows

Windows 11 с WSL2 — это удобно. Но медленно. На 15-30% медленнее чистого Linux.

Если серьёзно — ставим Ubuntu 24.04 LTS. И настраиваем:

# 1. Отключаем swap для моделей, которые помещаются в RAM
sudo swapoff -a

# 2. Настраиваем huge pages (критично для больших моделей)
echo "vm.nr_hugepages = 32768" | sudo tee -a /etc/sysctl.conf
sudo sysctl -p

# 3. Выставляем governor в performance
sudo apt install cpufrequtils
echo "GOVERNOR=\"performance\"" | sudo tee /etc/default/cpufrequtils
sudo systemctl restart cpufrequtils

# 4. Привязываем процессы к ядрам (для NUMA-систем)
# Определяем, какие ядра на каком NUMA-узле
numactl -H
# Запускаем llama.cpp на ядрах 0-15, если они на одном узле с памятью
numactl -C 0-15 -m 0 ./main -m model.gguf

Квантование: почему Q4_K_M, а не Q4_0

В 2026 году появились десятки форматов квантования. Для MoE-моделей выбор критичен.

Q4_0 — стабильно, но грубо. Q4_K_M — умное квантование с блочным масштабированием. Разница в качестве 5-7%, разница в скорости — минимальна.

Но есть нюанс: не все MoE-модели хорошо квантуются в Q4_K_M. Особенно чувствительны роутеры (которые выбирают экспертов).

Правило выбора:

1. Для GLM-4.7-Flash — только Q4_K_M (роутер ломается в Q4_0)
2. Для GPT OSS 120B — Q4_K_M или IQ4_XS (новый формат 2025 года)
3. Для Mixtral 8x22B — Q4_0 (стабильнее)

Как конвертировать самостоятельно:

# Используем llama.cpp с поддержкой MoE
cd llama.cpp
make -j$(nproc)

# Конвертируем в Q4_K_M
python3 convert.py \
  --outtype q4_k_m \
  --model-path /path/to/original \
  --outfile /path/to/quantized.gguf

# Ключевой флаг для MoE:
--moe-experts 8  # Указываем количество экспертов
# Без этого флага конвертер сломает архитектуру

llama.cpp: флаги, которые меняют всё

Запускаете ./main с дефолтными параметрами? Теряете 40% производительности.

Вот конфиг для 128 ГБ DDR5 и 32-ядерного процессора:

./main -m model.gguf \
  -t 28 \  # Оставляем 4 ядра системе
  -c 32768 \  # Контекст 32K
  -b 512 \  # Размер batch (экспериментируйте!)
  -ngl 0 \  # Нет GPU layers
  -fa \  # Flash Attention (для CPU! работает через AVX-512)
  -cb \  # Continuous batching (для чатов)
  -eps 1e-5 \  # Точность для MoE
  -moer 2 \  # Количество активных экспертов (если модель поддерживает)
  --mlock \  # Фиксируем модель в RAM
  --no-mmap \  # Не используем mmap (быстрее для частых доступов)
  -np 4 \  # Параллелизм для prompt processing
  -n 1024  # Генерируем 1024 токена

Самый важный флаг — -b (batch size). Для MoE-моделей:

• Слишком маленький batch (128) — неэффективное использование памяти
• Слишком большой batch (1024) — переполнение кэша процессора
• Золотая середина — 256-512

Реальные цифры: что можно ожидать

Система: Ryzen 9 7950X, 128 ГБ DDR5-6000 CL30, Ubuntu 24.04

4.7 токенов/сек для 120B модели — это медленно? Да. Но это работает. И это дешевле, чем сервер с 8×H100.

Ошибки, которые все совершают

1. Запуск без mlock

Без --mlock операционная система вытесняет части модели в swap. Каждый доступ к вытесненному эксперту — пауза на 10-100 мс. Итог: скорость падает в 2-3 раза.

2. Неправильный выбор процессора

Intel Core i9-14900K быстрее в играх. Но для LLM важнее не частота, а количество ядер и кэш L3. Ryzen 9 7950X с 64 МБ L3 кэша часто обгоняет Intel на 20-30% в CPU-инференсе.

3. Одна планка памяти вместо двух

Single-channel против dual-channel — это не +10% скорости. Это ×2 пропускной способности. Для MoE-моделей — разница между 2 и 4 токенами в секунду.

Проверяйте:

sudo dmidecode -t memory | grep "Size:"
# Должно быть 2 или 4 планки одинакового размера
# Не должно быть: 1 планка 128 ГБ (single channel)

4. Терпимость к ошибкам памяти

«Система работает, игры не вылетают, значит память стабильна» — самое опасное заблуждение. LLM используют память интенсивнее любых игр. Ошибка в одном бите — и эксперт начинает генерировать бессмыслицу.

Что делать, если не хватает RAM?

У вас 64 ГБ, а модель требует 68. Кажется, нужно покупать ещё память. Но есть хитрости.

1. Zswap вместо swap

# Включаем zswap (сжатие RAM)
echo "GRUB_CMDLINE_LINUX_DEFAULT=\"quiet splash zswap.enabled=1 zswap.compressor=zstd zswap.max_pool_percent=20\"" | sudo tee -a /etc/default/grub
sudo update-grub
sudo reboot

Zswap сжимает редко используемые данные. Для MoE-моделей это часто спящие эксперты. Экономия 10-15% RAM.

2. Layer-wise offloading на... другой компьютер

Звучит безумно, но работает. Запускаете часть экспертов на втором ПК через сеть 10 Гбит/с. Задержка добавляется, но для некоторых сценариев приемлемо. Подробнее в нашей статье про Tesla P40 для MoE-оффлоудинга.

Мониторинг и тонкая настройка

Запустили модель — и что дальше? Смотрите метрики:

# 1. Нагрузка на память
sudo apt install numactl
numastat -m
# Смотрим, как память распределена по NUMA-узлам

# 2. Пропускная способность
sudo apt install perf
sudo perf stat -e "memory/uncore_imc/data_reads/,memory/uncore_imc/data_writes/" -a sleep 1

# 3. Тепловое троттлинг
watch -n 1 "cat /sys/devices/system/cpu/cpu*/thermal_throttle"
# Если видите числа > 0 — процессор тормозит

На основе этих данных корректируем:

• Если память неравномерно загружена — меняем привязку NUMA (numactl -m)
• Если пропускная способность ниже 70% от теоретической — уменьшаем batch size
• Если процессор троттлит — улучшаем охлаждение или снижаем частоту

Итог: когда CPU лучше GPU

В 2026 году появилась странная тенденция: для моделей больше 70B параметров чистый CPU часто выигрывает у GPU-оффлоудинга. Почему?

Потому что PCIe 5.0 ×16 даёт 128 ГБ/с. А DDR5-6400 в dual-channel — 102.4 ГБ/с. Разница всего 25%. Но задержки доступа к системной памяти в 2-3 раза ниже, чем при переброске данных через PCIe.

MoE-модели идеально ложатся на эту архитектуру: эксперты живут в RAM, загружаются большими блоками, обрабатываются параллельно.

Ваша RTX 4090 плачет от 120B модели? Не мучайте её. Отдайте модели всю оперативку и ядра процессора. Получите стабильные 5 токенов в секунду вместо рваных 3 с оффлоудингом.

И помните главное: самая дорогая оптимизация — это добавление оперативной памяти. 128 ГБ DDR5 стоят дешевле, чем апгрейд с RTX 4090 на что-то с большей VRAM. А дают возможность запускать модели, которые в 2025 году считались серверными.

P.S. Если интересно, как это работает с совсем старым железом — читайте 64 ГБ RAM, чистая CPU и MoE-модели: кто выживает в спартанских условиях. Там есть примеры на DDR4 и процессорах 2019 года.