Когда MoE-модели тормозят: оптимизируем llama.cpp для Qwen3-Coder-Next

Почему ваш Qwen3-Coder-Next работает как улитка

Запустили свежую MoE-модель от Alibaba - Qwen3-Coder-Next 32B, а она думает дольше, чем вы пьёте кофе? Первый промпт обрабатывается 30 секунд, хотя в теории MoE должна быть быстрее обычных моделей? Знакомо. Я тоже неделю бился с этой проблемой, пока не разобрался, что llama.cpp по умолчанию настроен под традиционные модели, а MoE-архитектура требует особого подхода.

Проблема в том, что MoE (Mixture of Experts) работает не так, как обычные dense модели. Вместо обработки всех параметров сразу, система выбирает, какие эксперты активировать для каждого токена. Это как иметь команду из 8 специалистов, но работать будут только те, кто действительно нужен для задачи. Звучит эффективно, но реализация в llama.cpp до недавнего времени была... скажем так, неоптимальной.

Параметр --fit: не просто флаг, а ключ к скорости

Большинство гайдов по llama.cpp упоминают --fit вскользь. "Поставьте, если модель большая". Этого недостаточно. Для MoE-моделей этот параметр меняет всё.

1 Что на самом деле делает --fit

Когда вы запускаете llama.cpp с --fit, происходит магия:

• Система анализирует доступную VRAM и RAM
• Оптимизирует распределение слоёв между GPU и CPU
• Для MoE-моделей особенно важно: правильно распределяет экспертов
• Предотвращает частые переключения между устройствами

Без --fit llama.cpp может загрузить экспертов в оперативку, а потом постоянно таскать их в VRAM и обратно. Представьте, что у вас 8 специалистов сидят в разных офисах, и вам нужно бегать между этажами, чтобы с каждым поговорить. С --fit система понимает: "Ага, у нас есть быстрый лифт (GPU) и медленные коридоры (RAM), давайте разместим самых активных экспертов ближе к лифту".

# КАК НЕ НАДО ДЕЛАТЬ (стандартный запуск)
./main -m qwen3-coder-next-32b-q4_k_m.gguf -p "def fibonacci(n):" --n-gpu-layers 35

# КАК НАДО ДЕЛАТЬ (с оптимизацией для MoE)
./main -m qwen3-coder-next-32b-q4_k_m.gguf -p "def fibonacci(n):" --n-gpu-layers 35 --fit

Разница в скорости? От 30% до 60% на первом промпте. На последующих - поменьше, но всё равно заметно.

GPU-конфигурация: сколько слоёв действительно нужно

Вот здесь большинство ошибается. Берут число из гайда для обычной модели и применяют к MoE. Результат? Либо неиспользованная VRAM, либо постоянные свапы.

2 Расчёт оптимального --n-gpu-layers для MoE

Для Qwen3-Coder-Next 32B с квантованием Q4_K_M:

Почему меньше слоёв, чем для dense-моделей? Потому что MoE-архитектура. Каждый "слой" в MoE - это не один линейный слой, а целый блок с роутером и экспертами. Они занимают больше памяти, но за счёт активации только части экспертов - вычисления эффективнее.

# Оптимальная конфигурация для RTX 4070 Super (12 ГБ VRAM)
./main -m qwen3-coder-next-32b-q4_k_m.gguf \
  --n-gpu-layers 30 \
  --fit \
  --ctx-size 8192 \
  --batch-size 512 \
  --threads 8 \
  -p "Напиши функцию на Python для парсинга JSON"

Заметили --batch-size 512? Это не случайность. Для MoE-моделей увеличение batch-size даёт больший прирост, чем для обычных. Почему? Потому что система выбирает экспертов один раз для всего батча, а не для каждого токена отдельно.

Контекст - ваш главный враг и друг

Qwen3-Coder-Next поддерживает 128к контекста. Звучит круто, пока вы не понимаете, что каждый лишний токен в контексте замедляет всё.

В статье "Когда промпт длиннее мозга" я подробно разбирал, почему длинный контекст убивает производительность. Для MoE это вдвойне актуально.

3 Оптимизация размера контекста

Правило простое: устанавливайте --ctx-size ровно под ваши задачи. Если пишете короткие функции - 4096 более чем достаточно. Если работаете с большими файлами - поднимайте до 8192 или 16384, но не до 128к "на всякий случай".

# ПЛОХО: запас на будущее, который никогда не понадобится
./main -m qwen3-coder-next-32b.gguf --ctx-size 131072

# ХОРОШО: реалистичная настройка под задачи
./main -m qwen3-coder-next-32b.gguf --ctx-size 8192  # для большинства задач кодинга

Почему это важно? Потому что память под контекст выделяется сразу. 128к контекста при Q4_K_M - это около 2 ГБ памяти. Просто так, впустую.

Квантование: какое действительно работает в 2026

На 05.02.2026 актуальны следующие варианты квантования для MoE-моделей:

• Q4_K_M - оптимальный баланс для 99% случаев
• Q5_K_M - если качество критично, а скорость не очень
• IQ4_XS - новый формат, лучшее качество при том же размере
• Q3_K_M - только если VRAM совсем мало

Избегайте Q2_K и Q3_K_S для MoE-моделей. Они слишком агрессивно квантуют веса экспертов, и модель начинает генерировать ерунду. Проверено на горьком опыте.

Сборка llama.cpp: какие флаги включать

Если собираете llama.cpp сами (а для максимальной производительности это нужно), вот конфигурация для MoE:

# Для систем с NVIDIA GPU
cmake -B build -DLLAMA_CUBLAS=ON -DLLAMA_CUDA_MMV_Y=2 -DLLAMA_CUDA_F16=ON -DLLAMA_AVX2=ON

# Для систем с AMD GPU (ROCm)
cmake -B build -DLLAMA_HIPBLAS=ON -DLLAMA_AVX2=ON

# Для CPU-систем
cmake -B build -DLLAMA_AVX2=ON -DLLAMA_F16C=ON -DLLAMA_BLAS=ON -DBLAS_VENDOR=OpenBLAS

Ключевые моменты:

• LLAMA_CUDA_MMV_Y=2 - оптимизация для batch processing, критично для MoE
• LLAMA_CUDA_F16=ON - использование половинной точности там, где возможно
• LLAMA_AVX2=ON - даже для GPU-систем, часть вычислений всё равно на CPU

Полный рабочий конфиг для разных сценариев

4 Сценарий 1: Ноутбук с RTX 4060 (8 ГБ VRAM)

./main -m ~/models/qwen3-coder-next-32b-q4_k_m.gguf \
  --n-gpu-layers 22 \
  --fit \
  --ctx-size 4096 \
  --batch-size 384 \
  --threads 6 \
  --temp 0.7 \
  --top-k 40 \
  --top-p 0.95 \
  --repeat-penalty 1.1 \
  -p "Напиши SQL-запрос для выборки пользователей за последний месяц"

5 Сценарий 2: Рабочая станция с RTX 4090 (24 ГБ VRAM)

./main -m ~/models/qwen3-coder-next-32b-q4_k_m.gguf \
  --n-gpu-layers 999 \
  --ctx-size 16384 \
  --batch-size 1024 \
  --threads 12 \
  --temp 0.8 \
  --top-k 50 \
  --top-p 0.9 \
  --mlock \
  --no-mmap \
  -p "Рефактори этот код на TypeScript с использованием async/await"

Обратите внимание на --mlock и --no-mmap. Для систем с большим количеством RAM эти флаги фиксируют модель в памяти, убирая overhead от page faults.

Что ещё ускорит вашу MoE-модель

1. Температурные параметры: MoE-модели более чувствительны к температуре. Используйте --temp 0.7-0.8 для кодинга, 0.9-1.0 для креативных задач.

2. Параллелизация: Если у вас несколько GPU, можно распределить экспертов. Но это тема для отдельной статьи.

3. Кэширование: Для повторяющихся промптов (например, код-ревью) используйте --prompt-cache. MoE особенно хорошо кэшируется, потому что выбор экспертов стабилен для одинаковых входов.

4. Оптимизация Top-K: Как я писал в статье "Оптимизированный Top-K для LLM", правильная настройка --top-k может ускорить генерацию на 20% без потери качества.

Чего делать не стоит (ошибки, которые я совершил за вас)

1. Не ставьте --tensor-split без чёткого понимания. Для MoE это может разорвать экспертов между GPU, и они будут общаться через медленную шину.

2. Избегайте --no-kv-offload. Кэш ключей-значений для MoE огромен, и его оффлоад на CPU часто выгоднее, чем хранение в VRAM.

3. Не экономьте на --batch-size. Для MoE это важнее, чем для dense-моделей. Минимум 256, лучше 512 или 1024.

Бенчмарки: что получилось в итоге

После всех оптимизаций на RTX 4070 Super:

• Первый промпт: с 28 секунд до 11
• Последующие промпты: с 15 токенов/с до 22
• Потребление памяти: снизилось на 1.5 ГБ
• Стабильность: перестали появляться артефакты в длинных генерациях

Самое интересное: после настройки Qwen3-Coder-Next начала работать быстрее, чем некоторые dense-модели аналогичного размера. MoE-архитектура действительно эффективна, когда её правильно настроить.

Если вы столкнулись с проблемами tool calling (а они случаются), посмотрите мой гайд по починке tool calling в Qwen3-Coder-Next. Там есть нюансы, специфичные для MoE.

Что будет дальше с MoE в llama.cpp

На 05.02.2026 разработчики llama.cpp активно работают над:

• Более умным распределением экспертов между GPU и CPU
• Оптимизацией роутера (который выбирает экспертов)
• Поддержкой sparse attention для MoE
• Автоматическим подбором параметров под конкретное железо

Мой прогноз: через полгода MoE-модели в llama.cpp будут работать ещё на 30-40% быстрее. А пока - используйте настройки из этой статьи, и ваш Qwen3-Coder-Next перестанет думать как улитка и начнёт летать.

P.S. Если у вас слабое железо, но хочется MoE, посмотрите статью про запуск MoE-моделей на чистом CPU. Там свои хитрости.