A 10 year old Xeon is all you need

Как запустить современную нейросеть на сервере десятилетней давности

Запустить Gemma 4 (языковую модель от Google DeepMind с 26 миллиардами параметров) на процессоре Intel Xeon (серверный процессор) образца 2016 года? Звучит как безумная идея из разряда «зачем делать проще, если можно сделать сложнее». Но именно это произошло в блоге point.free — и у них получилось.

Главный результат: модель работает приемлемо для задач без GPU вообще.

Железо и софт: что использовали

Автор статьи взял сервер из техники на помойку современного датацентра:

КОНФИГУРАЦИЯ СЕРВЕРА ДЛЯ INFERENCE (ПРОЦЕССА ГЕНЕРАЦИИ ТЕКСТА)
─────────────────────────────────────────────────────────────────
Процессор    │ Intel Xeon E5-2620 v4 @2.10 ГГц │
             │ 8 ядер / 16 потоков (SMT ───     │
             │ Simultaneous Multithreading)     │
             │ AVX2 (без AVX-512/VNNI/BF16 ──── │
             │ наборы инструкций для ускорения) │
             ├──────────────────────────────────┤
Кэш          │ L3: 20 МБ | L2: ~2 МБ суммарно ──│
             │ быстрая промежуточная память CPU │
             ├──────────────────────────────────┤
Память       │ 128 ГБ DDR3 ─────────────────────│
             │ стандарт оперативной памяти      │
             │ пропускная способность ~50 ГБ/с  │
             ├──────────────────────────────────┤
Видеокарта   │ Нет                               │
             └──────────────────────────────────┘

Для справки: современный ноутбук обычно имеет DDR5 
с пропускной способностью ~300+ ГБ/с — в шесть раз быстрее.

Ключевой момент здесь — нет видеокарты. Ни дискретной, ни интегрированной.

Модель запускали через llama.cpp — библиотеку для эффективного выполнения языковых моделей на CPU и GPU без зависимостей.

Почему это вообще возможно: проблема памяти

Чтобы понять происходящее, нужно уяснить одну вещь о работе больших языковых моделей.

Во время генерации текста модель работает в режиме декодирования — она создаёт токены (слово или его часть — единица текста для модели) по одному за раз. На этом этапе производительность ограничена не вычислительной мощностью процессора, а пропускной способностью памяти.

Процессору приходится постоянно перемещать огромные объёмы весов модели из оперативной памяти в свой кэш для вычислений. Сами вычисления выполняются быстро — процессор большую часть времени просто ждёт данные.

Это называют «стеной памяти» (memory wall) — фундаментальное ограничение: CPU может вычислить всё мгновенно, но тратит время на ожидание данных из RAM.

Как заставить это работать: магия флагов llama.cpp

Наивный запуск через готовые инструменты вроде Ollama на таком железе будет катастрофически медленным — они оптимизированы под типичный сценарий с GPU и не используют все доступные оптимизации для CPU-only окружения.

Автор собрал команду llama-cli с десятками параметров:

llama-cli \
--model gemma-4-26B-A4B-it-Q8_0.gguf \
--model-draft gemma-4-drafter.gguf \
--spec-type mtp --draft-max 3 --draft-p-min 0.0 --spec-autotune \
-cnv --color --jinja --special \
-sm graph -smgs -sas -mea 256 \
--split-mode-f32 \
--temp 0.7 -t 8 --parallel 8 \
--cpu-moe --merge-up-gate-experts \
--flash-attn on --mla-use 3 \
--mlock --run-time-repack --no-kv-offload

Разберём ключевые элементы этой конфигурации.

Спекулятивное декодирование

Это одна из самых элегантных техник обхода memory wall в индустрии:

--spec-type mtp --draft-max 3 --draft-p-min 0.0 --spec-autotune

Идея простая: маленькая «черновая» модель (drafter) генерирует несколько токенов вперёд, а большая основная (verifier) проверяет их за один проход вместо генерации по одному токену за раз.

СПЕКУЛЯТИВНОЕ ДЕКОДИРОВАНИЕ vs ОБЫЧНОЕ ДЕКОДИРОВАНИЕ
─────────────────────────────────────────────────────────

ТРАДИЦИОННЫЙ ПОДХОД:
Модель → Токен → Модель → Токен → Модель → Токен...
          ↑ каждый вызов требует чтения всех весов (~26 ГБ)

СПЕКУЛЯТИВНОЕ:
Drafter(крошечный): [токен][токен][токен] ──┐  
                                             ▼  
Verifier(основной):    [проверка всех трёх за один проход]

Выигрыш: drafter целиком помещается в L3-кэш процессора,
а verifier читает веса лишь один раз вместо трёх.

На CPU этот подход особенно эффективен потому что вычисления дешевы относительно стоимости перемещения данных по памяти.

MoE и маршрутизация для CPU

Gemma 4 использует архитектуру Mixture-of-Experts (смесь экспертов): из примерно ста двадцати восьми «экспертов» модель активирует только восемь для каждого токена — остальные параметры остаются «спящими».

Параметры модели Gemma-4-A4B:
├── Всего экспертов..........128  
├── Активируется.............8 на токен  
├── Активных параметров......~3.8 млрд  
└── Всего параметров.........~25 млрд  

На GPU это не проблема благодаря быстрой HBM (High-Bandwidth Memory). На CPU с DDR3 постоянное переключение между экспертами вызывает катастрофическое поведение кэша (cache thrashing) — процессор непрерывно выгружает данные и загружает новые из медленной оперативки.

Два флага решают эту проблему:

--cpu-moe               # умная маршрутизация под иерархию CPU-кэша  
--merge-up-gate-experts # объединение двух проекций матриц в одну операцию 

Второй флаг экономит лишние пересылки данных по шине памяти внутри каждого эксперта.

Планирование памяти под конкретное железо

--mlock              # закрепить все данные модели в RAM (никакого swap!)
--run-time-repack    # переупорядочить тензоры под layout кэша процессора 

Параметр `--mlock` предотвращает выгрузку модели на диск операционной системой при нехватке памяти — событие катастрофическое для inference: скорость упадёт до нуля при попытке прочитать обратно двадцать семь гигабайт с жёсткого диска.

Флаг `--run-time-repack` тратит несколько секунд при запуске на физическую реорганизацию матриц весов так, чтобы CPU мог потреблять их максимально эффективно через свой кэш.

При неправильной конфигурации системы можно увидеть ошибку:

warning: failed to mlock buffer (27 ГБ): Cannot allocate memory  
Try increasing RLIMIT_MEMLOCK ('ulimit -l' as root)

Это не проблема модели — просто системный лимит mlock слишком мал для такой памяти (по умолчанию обычно шестьдесят четыре мегабайта).

Ограничения и что можно улучшить

Даже с агрессивными оптимизациями железо остаётся узким местом:

Автор отмечает что статья оборвалась на части про graph layout — судя по всему там были дополнительные оптимизации графа вычислений под конкретную архитектуру процессора без GPU Turbo Boost и других современных фичей энергосбережения.

Выводы

Запуск Gemma 4 (~27 ГБ) целиком в RAM без GPU звучит как демонстрация «делайте дома», но автор сделал это рабочим решением:

• Программные оптимизации часто важнее железа; правильная конфигурация софта компенсирует возраст оборудования.

• Спекулятивное декодирование особенно ценно именно когда memory bandwidth критична.

• Стандартные инструменты скрывают нюансы; нужен явный контроль над всеми параметрами inference.

• Llama.cpp остаётся лучшим выбором для полной прозрачности и доступа ко всем возможностям движка.

Такие эксперименты показывают, что старое серверное оборудование ещё долго будет полезным ресурсом для локальных NLP-задач (конфиденциальность, отсутствие зависимости от облачных API).

Если интересно попробовать самостоятельно даже скромный ноутбук позволит запустить компактные модели через Llama.cpp; документация проекта отлично написана и проведёт вас от установки до первого результата буквально за минуты; а если хочется погрузиться глубже обратите внимание на оригинальную статью point.free где автор подробно описал всю математику speculative decoding; удачного экспериментирования!

Ссылки

• Original Article — A Ten Year Old Xeon Is All You Need от point.free

• Llama.cpp Official Repository — GitHub репозиторий проекта

• Gemma Models — официальная документация семейства моделей Gemma от Google DeepMind

• Speculative Decoding Paper — оригинальная научная статья о методе спекулятивного декодирования