MiniMax M2.5 на двух старых 3090: как выжать 12.9 токенов в секунду с 72k контекстом

Почему MiniMax M2.5 на старом железе — это боль

У вас есть две 3090. Или даже три. Вы скачиваете MiniMax M2.5 230B MoE в GGUF — и получаете 2-3 токена в секунду. Контекст 8k, а не 72k. Видеопамять забита, но модель всё равно тормозит.

Проблема не в железе. Проблема в том, как вы его используете.

MoE-модели (Mixture of Experts) — это не обычные плотные модели. В MiniMax M2.5 из 230B параметров активны только ~37B на каждом токене. Но стандартный llama.cpp до версии 2025 года не умел с этим работать эффективно. Он пытался загрузить все эксперты в VRAM, даже те, что не нужны.

Решение: llama-server с cpu-moe флагом

llama.cpp с версии 0.12.0 (январь 2025) научился работать с MoE через флаг --cpu-moe. Но встроенный сервер (llama-server) получил эту возможность только в коммитах февраля 2026 года.

Суть проста: эксперты, которые не активны в данный момент, живут в оперативной памяти. В VRAM остаются только активные слои. Это сокращает требования к видеопамяти в 4-6 раз для MiniMax M2.5.

Сборка llama-server с поддержкой cpu-moe

Не берите готовые билды. Соберите сами — там всего три команды.

1Ставим зависимости

# Для Ubuntu/Debian
sudo apt update
sudo apt install -y build-essential cmake git
# CUDA 12.4 (актуально на февраль 2026)
sudo apt install -y cuda-toolkit-12-4

2Клонируем и собираем

git clone https://github.com/ggerganov/llama.cpp
cd llama.cpp
mkdir build && cd build
# Ключевой момент: включаем поддержку CUDA и сервера
cmake .. -DLLAMA_CUDA=ON -DLLAMA_SERVER=ON -DCMAKE_BUILD_TYPE=Release
make -j$(nproc)
# Проверяем, что cpu-moe есть в помощи
./bin/llama-server --help | grep cpu-moe

Если в выводе есть --cpu-moe — всё готово. Если нет — ваша версия устарела. Ищите свежий коммит.

Загрузка правильного GGUF файла

MiniMax M2.5 в GGUF бывает разный. На февраль 2026 актуальны квантования от bartowski и IkariDev.

Я тестировал на Q4_K_M. Разница с Q5_K_M в качестве почти незаметна, но экономия 30GB — это возможность загрузить больший контекст.

Конфигурация для двух 3090 (24GB каждая)

Вот команда, которая дала 12.9 t/s с контекстом 72k:

./bin/llama-server -m /path/to/MiniMax-M2.5-230B-Q4_K_M.gguf \
  --host 0.0.0.0 --port 8080 \
  --cpu-moe \
  --ctx-size 73728 \
  --parallel 4 \
  --batch-size 512 \
  --ubatch-size 512 \
  --flash-attn \
  --no-mmap \
  --mlock \
  --n-gpu-layers 120 \
  --tensor-split 20,20 \
  --cont-batching \
  --numa \
  --rope-freq-base 1000000 \
  --rope-freq-scale 0.5

Разбор флагов (почему именно так)

• --cpu-moe — главный флаг. Эксперты в RAM, активные слои в VRAM.
• --ctx-size 73728 — не 8192, а полные 72k. MiniMax M2.5 обучен на таком контексте, иначе теряет способности.
• --tensor-split 20,20 — 20GB на первую 3090, 20GB на вторую. Оставляем 4GB про запас на систему.
• --n-gpu-layers 120 — примерно половина слоёв на GPU. Остальные в RAM через cpu-moe.
• --no-mmap --mlock — файл модели в RAM полностью. Ускоряет доступ к экспертам.
• --rope-freq-base 1000000 --rope-freq-scale 0.5 — настройки RoPE для длинного контекста. Без них на 72k будет полная ерунда.

Оперативная память: сколько нужно на самом деле

С cpu-moe модель ест RAM как сумасшедшая. Q4_K_M весит 130GB. Плюс контекст 72k — ещё ~15GB. Плюс система.

Итог: минимум 192GB RAM. Лучше 256GB.

Если RAM меньше — используйте mmap (уберите --no-mmap и --mlock). Скорость упадёт на 10-15%, но будет работать.

Кстати, если RAM действительно мало, посмотрите мою статью про SSD Offload для llama.cpp. Там есть хаки для работы с диском как с расширенной памятью.

Почему Linux, а не Windows

На Windows с двумя 3090 вы получите максимум 9-10 t/s. На Linux — 12.9 t/s. Разница в 30%.

Причины:

1. Лучший менеджер памяти CUDA в Linux
2. Меньшие накладные расходы ядра
3. Возможность использовать --numa для привязки к ядрам CPU
4. Стабильность при полной загрузке VRAM

Если вы всё ещё на Windows — установите Ubuntu 24.04 LTS. Это займёт час. Результат того стоит. Более подробно про оптимизацию Linux для LLM я писал в отдельном гайде.

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

Запустили сервер. Как проверить, что всё работает?

# Смотрим загрузку GPU
nvidia-smi --query-gpu=memory.used,memory.total,utilization.gpu --format=csv -l 1

# Смотрим загрузку RAM
htop

В идеале:

• VRAM: ~20GB на каждой 3090 (из 24GB)
• RAM: ~140-150GB используется (модель + контекст)
• GPU Utilization: 70-90% во время генерации

Если VRAM забита под завязку (23.5/24GB) — уменьшите --tensor-split до 19,19. Оставьте воздух.

Если GPU Utilization ниже 60% — увеличьте --batch-size до 1024. Но проверьте, не переполнится ли память.

Почему не vLLM или Text Generation Interface?

vLLM до сих пор (февраль 2026) плохо работает с MoE. Он оптимизирован для плотных моделей и теряет преимущества cpu-moe.

TGI (Text Generation Interface) от Hugging Face поддерживает MoE, но требует PyTorch и больше памяти. И даёт 8-9 t/s на том же железе.

llama-server в данном случае — самый низкоуровневый и эффективный вариант. Особенно с самосборкой.

А если у меня три 3090?

Поздравляю. Вы можете:

1. Залить больше слоёв на GPU: --n-gpu-layers 140
2. Увеличить batch-size до 768 или 1024
3. Попробовать квантование Q5_K_M

Команда будет такой:

./bin/llama-server -m /path/to/MiniMax-M2.5-230B-Q5_K_M.gguf \
  --cpu-moe \
  --ctx-size 73728 \
  --tensor-split 16,16,16 \
  --n-gpu-layers 140 \
  --batch-size 768 \
  --parallel 6 \
  # остальные флаги как раньше

Ожидаемая скорость: 14-15 t/s. Не линейный рост, но ощутимо.

Частые ошибки (и как их избежать)

А что насчёт качества генерации?

12.9 t/s — это для контекста 72k. Если ваш промпт короче (1-2k токенов), скорость будет 16-18 t/s.

Качество на Q4_K_M практически неотличимо от FP16. MoE-модели лучше переносят квантование, чем плотные. Эксперты работают независимо, и ошибки квантования не накапливаются.

Проверьте сами:

curl http://localhost:8080/completion -d '{
  "prompt": "Ты — опытный программист. Напиши функцию на Python, которая проверяет, является ли строка палиндромом. Объясни алгоритм.",
  "temperature": 0.7,
  "max_tokens": 500
}'

Ответ должен быть логичным, код — рабочим. Если нет — возможно, проблема с RoPE настройками для длинного контекста.

Зачем всё это?

Потому что MiniMax M2.5 на февраль 2026 — одна из лучших открытых моделей. Она обходит Llama 3.1 405B в большинстве бенчмарков, но требует в 2 раза меньше ресурсов для инференса.

12.9 t/s с контекстом 72k — это уровень, когда модель можно использовать для реальных задач:

• Анализ длинных документов (договоры, кодовая база)
• Многошаговые рассуждения с сохранением контекста
• Пакетная обработка запросов с --cont-batching

И всё это на железе, которое считается "устаревшим" (3090 выпущена в 2020).

Кстати, если вам нужно запустить модель ещё быстрее, но с меньшим контекстом, посмотрите мою статью про оптимизацию MiniMax M2.5 для 3x3090. Там другие настройки для максимальной скорости.

А если у вас нет GPU вообще, но есть многоядерный CPU — есть отдельный гайд по CPU-only инференсу. Там свои хитрости.

Что дальше?

llama.cpp развивается быстро. К марту 2026 обещают:

• Поддержку динамической загрузки экспертов (не все эксперты в RAM сразу)
• Оптимизацию для multi-GPU с разной памятью (3090 + 4090, например)
• Встроенную поддержку длинного контекста до 1M токенов

Но даже текущая версия даёт то, что нужно: рабочую модель на старом железе. Без облаков, без подписок, без ограничений.

Запускайте. Тестируйте. Делитесь результатами. И помните: главное — не количество видеокарт, а умение их настроить.