Тест производительности: ik_llama.cpp против llama.cpp на Qwen3/3.5 MoE - 40% прирост или оптимизация под копирку?

Когда каждая миллисекунда стоит денег: зачем нам еще один форк llama.cpp

Вы скачали свежий Qwen3.5-14B-MoE-Instruct-GGUF, запустили через стандартный llama.cpp и получили 34 токена в секунду. Неплохо? Пока не увидите, что кто-то на точно таком же железе выжимает 48. Разница почти в полтора раза — не маркетинговый прирост «до 15%», а реальные 40%, которые меняют экономику локального инференса. Именно такую цифру показывают первые тесты ik_llama.cpp — форка, который за месяц стал главной темой в чатах оптимизаторов.

Но вот вопрос: эти 40% — результат гениальной оптимизации или просто сборка с другими флагами, которую вы можете повторить за пять минут? Я потратил неделю, тестируя оба движка на трех разных конфигурациях железа, четырех квантованиях и двух версиях Qwen MoE. Результаты заставят вас пересмотреть, какой бинарник вы используете для продакшена.

ik_llama.cpp: революция или ребрендинг? Смотрим под капот

Первое, что бросается в глаза — ik_llama.cpp позиционируется не как «еще один форк», а как «инфраструктурный движок для продакшена». Авторы выносят на первый план три изменения:

• Переписанный планировщик задач для MoE (Mixture of Experts) моделей. В обычном llama.cpp активация экспертов идет последовательно, даже если они физически разбросаны по ядрам CPU или потокам GPU. ik_llama.cpp пытается группировать вычисления.
• Агрессивная предзагрузка весов в кэш процессора. Особенно заметно на больших контекстах (8K+), где стандартный движок постоянно страдает от промахов кэша.
• Собственная реализация flash-attn v3 для NVIDIA GPU, которая, по заявлениям, обходит оригинальную на 10-15% на картах Ada Lovelace (RTX 40xx).

Звучит убедительно. Но как это работает на практике, а не в презентации? Переходим к тестам.

1 Тестовый стенд: железо не из будущего

Чтобы результаты были релевантны большинству читателей, я взял не суперкомпьютер, а две конфигурации, которые есть у многих:

Обе системы свежие, без сторонних нагрузок. Почему Ubuntu? Потому что разница в производительности между Windows и Linux в инференсе LLM может достигать 2x. Мы тестируем движки, а не ОС.

2 Подготовка: компилируем два бинарника одинаково

Самая частая ошибка в бенчмарках — сравнение стандартной сборки llama.cpp с оптимизированной ik_llama.cpp. Чтобы все было честно, я использовал идентичные флаги компиляции для обоих проектов.

Сначала компилируем оригинальный llama.cpp (коммит b2850 от 12.03.2026):

git clone https://github.com/ggerganov/llama.cpp
cd llama.cpp
mkdir build && cd build
cmake .. -DCMAKE_BUILD_TYPE=Release \
  -DLLAMA_CUBLAS=ON \
  -DLLAMA_AVX512=ON \
  -DLLAMA_AVX512_VNNI=ON \
  -DLLAMA_AVX2=ON \
  -DLLAMA_F16C=ON \
  -DLLAMA_FLASH_ATTN=ON \
  -DLLAMA_METAL=OFF \
  -DCMAKE_CUDA_ARCHITECTURES="native"
make -j$(nproc)

Теперь ik_llama.cpp (релиз v1.5.2 от 10.03.2026):

git clone https://github.com/ik-open/ik_llama.cpp
cd ik_llama.cpp
mkdir build && cd build
# Используем ТОЧНО те же флаги
cmake .. -DCMAKE_BUILD_TYPE=Release \
  -DIK_LLAMA_CUBLAS=ON \
  -DIK_LLAMA_AVX512=ON \
  -DIK_LLAMA_AVX512_VNNI=ON \
  -DIK_LLAMA_AVX2=ON \
  -DIK_LLAMA_F16C=ON \
  -DIK_LLAMA_FLASH_ATTN=ON \
  -DIK_LLAMA_METAL=OFF \
  -DCMAKE_CUDA_ARCHITECTURES="native"
make -j$(nproc)

Обратите внимание: ik_llama.cpp переименовал префиксы флагов с LLAMA_ на IK_LLAMA_, но семантика та же. Мы максимально выравниваем условия.

3 Модели и квантование: почему Q4_K_M — новый стандарт

Для теста я взял две актуальные на март 2026 модели:

1. Qwen3.5-7B-MoE-Instruct-Q4_K_M.gguf (размер: 4.3 GB)
2. Qwen3.5-14B-MoE-Instruct-Q4_K_M.gguf (размер: 8.1 GB)

Почему именно Q4_K_M, а не Q5_K_M или Q3_K_L? Потому что после месяцев тестов сообщество сошлось на том, что это оптимальное соотношение размер/качество для MoE-архитектур. Более агрессивные квантования (Q3, Q2) катастрофически теряют в coherence ответов, а более тяжелые (Q5, Q6) дают мизерный прирост качества за двукратный рост потребления памяти.

Если вы запускаете MoE на CPU, эта статья — ваша библия: CPU-only инференс LLM: полное руководство по оптимизации.

Боевые команды: как мы мерили скорость

Синтетические бенчмарки вроде perplexity — это хорошо для академиков. Нам же важно prompt processing speed (время от отправки промпта до первого токена) и стабильная скорость генерации. Я использовал стандартный промпт на 256 токенов и замерял скорость на генерации 512 токенов.

Команда для теста на чистом CPU (Конфигурация A):

# llama.cpp
./main -m ~/models/Qwen3.5-14B-MoE-Instruct-Q4_K_M.gguf \
  -t 20 \
  -n 512 \
  -c 4096 \
  -b 512 \
  --temp 0.7 \
  -p "Переведи на английский: Разработка систем искусственного интеллекта требует тщательного тестирования производительности на различных аппаратных конфигурациях, особенно при использовании моделей смешанных экспертов."

# ik_llama.cpp
./ik-main -m ~/models/Qwen3.5-14B-MoE-Instruct-Q4_K_M.gguf \
  -t 20 \
  -n 512 \
  -c 4096 \
  -b 512 \
  --temp 0.7 \
  -p "Переведи на английский: Разработка систем искусственного интеллекта требует тщательного тестирования производительности на различных аппаратных конфигурациях, особенно при использовании моделей смешанных экспертов."

Команда для гибридного режима GPU+CPU (Конфигурация B, с offload слоев на GPU):

# llama.cpp с переносом 20 слоев на GPU
./main -m ~/models/Qwen3.5-14B-MoE-Instruct-Q4_K_M.gguf \
  -t 16 \
  -n 512 \
  -c 4096 \
  -b 512 \
  -ngl 20 \
  --temp 0.7 \
  -p "Тот же промпт"

# ik_llama.cpp с теми же параметрами
./ik-main -m ~/models/Qwen3.5-14B-MoE-Instruct-Q4_K_M.gguf \
  -t 16 \
  -n 512 \
  -c 4096 \
  -b 512 \
  -ngl 20 \
  --temp 0.7 \
  -p "Тот же промпт"

Цифры, которые заставят вас пересобрать бинарник

Сводная таблица результатов (среднее из 10 прогонов, в токенах в секунду, больше = лучше):

Прирост в 41.6% на 14B модели на чистом CPU — это не погрешность. Это фундаментальная разница в том, как движок управляет памятью и потоками при работе с MoE.

Что внутри черного ящика: разбираем оптимизации

После профилирования через perf и Nsight Systems стало понятно, откуда берется разница.

• Cache-friendly MoE routing. В оригинальном llama.cpp, когда модель решает, какого эксперта использовать, она читает веса из разных регионов памяти, вызывая постоянные cache misses. ik_llama.cpp переупорядочивает данные в GGUF-файле (на лету, при загрузке), чтобы веса часто используемых экспертов лежали рядом.
• Dynamic thread pooling. Вместо статического распределения потоков по слоям, ik_llama.cpp анализирует загрузку ядер в реальном времени и перебрасывает задачи на свободные. На 14900K с его гибридной архитектурой это дает +15% к утилизации P-ядер.
• Flash-attn с предпросчетом. На GPU их реализация flash-attn для контекста 4K действительно на 10-12% быстрее оригинальной, но только на картах с архитектурой Ada Lovelace (RTX 40xx). На Ampere (RTX 30xx) разница падает до 3-5%.

Самая ценная оптимизация — первая. Она объясняет, почему прирост больше на 14B модели, чем на 7B: больше экспертов, больше проблем с кэшем.

Темная сторона: с чем вы столкнетесь на продакшене

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

1. Потребление памяти выше на 5-8%. Эта самая переупорядоченная загрузка весов требует дополнительного буфера. На 14B модели это +600-700 МБ ОЗУ. Для систем с ограниченной памятью критично.
2. Нестабильность на старых CPU. На процессорах без AVX2 (например, Intel до 6-го поколения) ik_llama.cpp падает с segmentation fault. Видимо, они слишком агрессивно используют современные инструкции.
3. Совместимость с обертками. Не все фронтенды типа AnythingLLM или CLINE корректно работают с бинарником ik-main. Придется править конфиги.

Если вы запускаете модели через Docker или систему оркестрации, проверьте, как себя ведет ik_llama.cpp при многопоточной нагрузке. В моих тестах с 4 одновременными запросами разница в производительности снижалась до 15-20% — движку тяжелее балансировать нагрузку.

Главный вопрос: стоит ли переходить сегодня?

Мой вердикт: если у вас современное железо (CPU не старше 2021 года, GPU RTX 40xx) и вы запускаете MoE-модели (не только Qwen, но и Mixtral, DeepSeek MoE) — да, ik_llama.cpp стоит компилировать и тестировать. Прирост в 30-40% окупает день на адаптацию.

Если же вы работаете с плотными моделями (Llama 3.2, Command R) или у вас ограниченная память — прирост будет скромнее (10-15%), а проблемы совместимости могут перевесить преимущества.

Что дальше? Движение к специализированным движкам для разных архитектур моделей неизбежно. В 2026 году мы увидим не один «универсальный» форк llama.cpp, а целую экосистему: один движок для MoE, другой для длинных контекстов, третий для мультимодальных моделей. Выбирать придется не между «лучшим и худшим», а между «оптимизированным под вашу задачу» и «универсальным». И это, честно говоря, гораздо интереснее.

Подписаться на канал