Что случилось с Qwen3 Next в llama.cpp?
В конце прошлой недели в репозиторий llama.cpp слили пулл-реквест, который должен был остаться незамеченным. Обычное обновление поддержки архитектуры, пара оптимизаций. Но результат оказался неожиданным: Qwen3 Next начала генерировать текст на 30% быстрее. Не обещанные 5-10%, а сразу треть от времени генерации. Для тех, кто запускает большие модели на своём железе, это разница между "можно пользоваться" и "невыносимо медленно".
Суть изменений в одном предложении: разработчики исправили обработку архитектурных особенностей Qwen3 Next в ядре llama.cpp, что позволило задействовать все оптимизации, которые раньше пропускались для этой модели.
Чем новая версия GGUF отличается от старой
Если раньше вы скачивали Qwen3 Next из TheBloke или других источников, вы получали модель, скомпилированную со старыми настройками. Теперь нужно перекачать — или сконвертировать заново. Разница не в весах модели (они те же), а в том, как llama.cpp их интерпретирует.
Новый GGUF использует обновлённый набор флагов метаданных, которые сообщают llama.cpp: "это Qwen3 Next, обрабатывай меня особым образом". Без этих флагов движок применял общую логику, которая оказалась неоптимальной для этой архитектуры.
Тесты: цифры вместо обещаний
Я запустил серию тестов на трёх конфигурациях:
- NVIDIA RTX 4070 (12 ГБ VRAM) с полной загрузкой на GPU
- Intel Core i7-13700K (только CPU, 32 ГБ RAM)
- Смешанный режим (часть слоёв на GPU, часть на CPU)
Тестовый промпт — генерация кода на Python средней сложности (около 200 токенов на выход). Метрика — токены в секунду. Вот что получилось:
| Конфигурация | Старый GGUF | Новый GGUF | Прирост |
|---|---|---|---|
| RTX 4070 (полный GPU) | 42 токен/с | 55 токен/с | +31% |
| Только CPU | 8.2 токен/с | 10.7 токен/с | +30% |
| Смешанный режим | 21 токен/с | 27 токен/с | +29% |
Прирост практически одинаковый на всех платформах. Это говорит о том, что оптимизации касаются не конкретного железа, а самой логики обработки модели.
Как это работает под капотом
Qwen3 Next использует SwiGLU в качестве функции активации вместо обычного ReLU. В старой версии llama.cpp этот факт игнорировался — движок использовал универсальный путь вычислений. Новый код определяет архитектуру модели и включает специализированные ядра для SwiGLU, которые считают быстрее.
Второе изменение — оптимизация обработки ротационных позиционных эмбеддингов (RoPE). В Qwen3 Next они применяются не так, как в Llama или Mistral. Раньше llama.cpp тратил лишние циклы на преобразования, теперь делает это за один проход.
Важный момент: ускорение работает только с последней версией llama.cpp (после коммита #7821). Если вы используете Ollama или LM Studio, которые встроили старую версию, вы не увидите разницы. Нужно либо ждать обновления этих инструментов, либо собирать llama.cpp из исходников.
Сравнение с альтернативами
Пока все обсуждают vLLM против llama.cpp, этот пулл-реквест ставит точку в споре для Qwen3 Next. vLLM до сих пор не имеет полной поддержки архитектуры Qwen3 Next — там используются обходные пути, которые замедляют работу.
Ollama, который многие используют для простоты, тоже проигрывает. Он базируется на устаревшей версии llama.cpp и не получает эти оптимизации. Разница в скорости между свежим llama.cpp и Ollama может достигать 40% для той же модели и железа.
Единственный реальный конкурент — GPTQ через ExLlamaV2. Но там своя головная боль с совместимостью версий и необходимостью переквантования моделей под каждое обновление.
Что делать, если вы уже используете Qwen3 Next
1 Обновите llama.cpp
Соберите из исходников или скачайте последнюю nightly-сборку. Старые бинарные релизы не содержат нужных изменений.
2 Перекачайте модель
Найдите свежую версию GGUF на Hugging Face. Ищите модели, созданные после середины ноября 2024 года. Или сконвертируйте оригинальную модель сами, используя обновлённый convert.py.
3 Проверьте флаги запуска
Убедитесь, что используете --no-mmap или --mlock, если запускаете на SSD. Новые оптимизации чувствительны к скорости доступа к данным.
Кому это нужно в первую очередь
Если вы:
- Запускаете Qwen3 Next для генерации кода или длинных текстов
- Используете модель в продакшене, где каждая секунда стоит денег
- Работаете на ограниченном железе (например, на 12 ГБ VRAM)
- Сравниваете разные модели по скорости (как в нашем предыдущем тесте)
Тогда обновление обязательно. Разница в 30% — это не просто цифра в бенчмарке. Это реальное время, которое вы тратите на ожидание ответа от модели.
Что будет дальше
Этот пулл-реквест — не последнее слово в оптимизации. Разработчики llama.cpp уже работают над поддержкой MXFP4 для архитектуры Blackwell, что даст ещё 20-25% прироста.
Но главный урок здесь другой: даже такая зрелая библиотека, как llama.cpp, всё ещё содержит неоптимальный код для популярных архитектур. Если вы недовольны скоростью своей модели — возможно, проблема не в железе, а в том, как её обрабатывает движок.
Следующими на очереди, вероятно, окажутся модели от DeepSeek и Command R+. Их архитектурные особенности тоже могут обрабатываться неоптимально в текущей версии llama.cpp.
И последнее: не ждите, пока обновление придёт в ваш любимый GUI-клиент. Разработчики LM Studio, Ollama и других обёрток обычно отстают на несколько недель. Если хотите получить ускорение сегодня — собирайте llama.cpp сами. Это проще, чем кажется.
