Что за PR #29184 и что он меняет в llama.cpp
В репозитории ggml-org/llama.cpp появился pull request #29184 с заголовком «CUDA: fuse shared experts into MMVQ». Автор изменения, am17an, предлагает объединять shared experts в MMVQ-вычислениях, чтобы ускорить инференс MoE-моделей: описание PR в обсуждении.
Суть в одной фразе: обработка shared experts перестаёт быть отдельным проходом и вплавляется в вычислительный путь, который и так выполняется для каждого токена. Заявленный выигрыш касается не всех MoE-архитектур. В описании PR как пример приведена Qwen 35B A3B.
Оговорка, без которой новость читается неправильно. Pull request - это предложение, а не код, уже лежащий в основной ветке. Нет подтверждения, что изменение принято, нет независимых замеров, нет гарантии, что финальная реализация совпадёт с текущей. Дальше речь идёт о заявленной идее и о том, как её оценивать.
Статус PR: предложение, а не готовое решение
Pull request живёт в отдельной ветке автора и проходит ревью. Мейнтейнеры могут его принять, попросить переделать, разбить на части или отклонить. Пока изменение не влито в основную ветку, пользоваться им можно только сборкой из ветки автора, а это уже эксперимент со всеми сопутствующими рисками: нестабильность, конфликты с другими правками, отсутствие гарантий корректности на длинных прогонах.
Сроки никто не называет, и строить планы на конкретную дату появления оптимизации в релизе нельзя. Практический ориентир простой: следить за статусом PR и за тем, попадёт ли он в очередной тег llama.cpp.
Что такое MMVQ и при чём тут CUDA
MMVQ расшифровывается как matrix-vector quantization, то есть умножение вектора на квантованную матрицу весов. Это вычислительный путь в CUDA-бэкенде llama.cpp, рассчитанный на сценарий, когда за раз обрабатывается мало токенов: генерация идёт по одному токену, а веса хранятся в квантованном виде, чтобы экономить VRAM.
В таком режиме узким местом становится не арифметика, а чтение весов из памяти. Ядро, которое умеет сразу разобрать квантованный формат и умножить вектор, читает матрицу один раз и не разворачивает её в полную точность. Shared experts устроены похоже: это тоже умножение вектора на матрицу весов. Логика PR в том, чтобы не гонять для них отдельный проход, а обработать тем же путём, что и остальные матричные операции.
Shared experts в MoE: что это и почему они вообще есть
MoE (mixture of experts) заменяет один большой блок FFN на набор экспертов и роутер. Для каждого токена роутер выбирает top-k экспертов, они и выполняют вычисление. Разреженность даёт экономию: активных параметров на токен тратится меньше, чем всего в модели.
Shared experts ломают эту схему частично. Это эксперты, которые активны всегда, независимо от решения роутера. Они добавляют к каждому токену фиксированный объём вычислений и чтения весов.
Чем shared experts отличаются от маршрутизируемых
Маршрутизируемые эксперты включаются выборочно: одни токены идут в одну пару экспертов, другие в другую. Shared experts включены всегда. Их задача - давать общий фоновый вклад, который не зависит от того, куда попал токен, и разгружать маршрутизируемые эксперты от базовых закономерностей.
Именно из-за постоянной активности к ним и возникает интерес. Пропустить их нельзя, значит, их стоимость входит в каждый сгенерированный токен.
Почему shared experts - это дополнительная нагрузка на инференс
Представьте, что модель гоняет один токен за шаг. Роутер выбрал пару экспертов, и для них загружаются веса. Параллельно для того же токена работают shared experts, и для них загружаются свои веса. Пока эти вычисления идут отдельным проходом, GPU тратит время на запуск дополнительных ядер и на промежуточные записи в память.
При генерации по одному токену пропускная способность памяти уже загружена чтением весов MoE-слоя. Лишний проход по shared experts добавляет к этому ещё немного, и на моделях, где таких экспертов много или они крупные, накладные расходы становятся заметной долей времени шага.
Shared experts есть не во всех MoE-моделях. В описании PR как раз приводится пример архитектуры, где они есть: Qwen 35B A3B. Если в вашей модели их нет, оптимизация ей ничего не даст по определению.
Как объединение shared experts в MMVQ может ускорять инференс
Идея PR - не менять архитектуру модели и не трогать веса, а переписать вычислительный путь так, чтобы shared experts обрабатывались тем же ядром, что и остальные матричные операции в MMVQ.
Что даёт fuse с точки зрения вычислений
Fuse в контексте вычислений означает объединение нескольких операций в один проход. На практике это меньше запусков ядер, меньше промежуточных тензоров в памяти и лучшее переиспользование уже загруженных данных. Каждое обращение к глобальной памяти стоит времени, и если данные удаётся прочитать один раз вместо двух, экономия появляется без изменения математики.
Масштаб выигрыша зависит от того, какую долю времени шага занимают shared experts. Если это небольшая часть вычислений, эффект будет скромным. Если модель активно использует такие эксперты, объединять есть что.
Почему это касается именно CUDA-бэкенда
Изменение относится к CUDA-пути llama.cpp. Пользователи CPU, Metal, Vulkan и других бэкендов не получат этого ускорения даже после того, как PR примут. Для тех, кто запускает MoE-модели на NVIDIA, это повод следить за темой, для остальных просто информация.
Смежные оптимизации CUDA-пути для MoE в llama.cpp появляются регулярно, и разбирать их удобнее в одной связке: о расширении CUDA fusion для MoE и speculative decoding.
Почему ускорение работает не для всех MoE-архитектур
Формулировка автора PR прямая: ускорение есть, но только для некоторых MoE-архитектур (то же описание PR). Причин минимум три: наличие shared experts, их доля в вычислениях и то, как конкретная модель реализована в коде llama.cpp.
Пример Qwen 35B A3B: почему именно она
Qwen 35B A3B приведена в описании PR как образец архитектуры, для которой заявлено ускорение. Не стоит читать это как гарантию для всего семейства Qwen или для любой модели с похожим названием: автор назвал конкретный пример, а не список. Детали архитектуры модели в описании не раскрыты, и додумывать их не нужно.
Логично предположить, что в таких моделях shared experts дают достаточную долю работы на шаг генерации, чтобы объединение с MMVQ было заметно. Но это объяснение общей механики, а не измеренный факт.
Какие MoE-модели могут остаться без ускорения
- Модели без shared experts: объединять нечего, выигрыша от этого изменения не будет.
- Модели с иной реализацией MoE в llama.cpp: если путь вычисления устроен иначе, вплавление в MMVQ может не примениться без отдельной доработки.
- Запуски не на CUDA: CPU, Metal, Vulkan, ROCm остаются в стороне.
Точный список архитектур на момент публикации неизвестен и может уточняться по ходу ревью. Автор назвал один пример, остальные остаются под вопросом.
am17an ведёт и другие CUDA-оптимизации для моделей Qwen в llama.cpp: пример с разреженным Flash Attention для Qwen4.
Что это значит на практике для тех, кто запускает MoE локально
Если вы запускаете MoE-модель с shared experts на NVIDIA через llama.cpp, изменение потенциально может добавить скорости генерации. Пока PR не в основной ветке, попробовать его можно только сборкой из ветки автора.
Как оценить потенциальную выгоду для своего сценария
- Доля shared experts в общем времени шага: чем она выше, тем больше смысла ждать.
- Размер модели и её квантование: на сильно сжатых вариантах узким местом чаще становится память, а не вычисления.
- Длина контекста и батчинг: при обработке промпта и при генерации по одному токену профиль нагрузки различается.
- Замеры в токенах в секунду до и после: без них любые выводы остаются предположением.
Задачи с длинным промптом и задачи с длинной генерацией упираются в разные ресурсы, поэтому один и тот же патч может дать разный эффект.
Ограничения и риски преждевременных выводов
Заявленное ускорение не подтверждено независимой проверкой. PR могут отклонить или переработать, и тогда описанный выигрыш останется на бумаге. Даже после принятия результат зависит от версии llama.cpp, драйвера, конкретной квантованной сборки модели и настроек запуска.
Соседние темы по MoE на GPU полезно держать в голове вместе с этой: Hot Expert Reload и подкачка активных экспертов в VRAM и экспериментальная ветка с expert expansion. Все они решают одну задачу с разных сторон: снизить накладные расходы при работе с экспертами.
Итог: кому и когда это пригодится
PR #29184 - точечная оптимизация CUDA-пути llama.cpp для MoE-моделей с shared experts. Она не универсальна: модели без таких экспертов и запуски не на NVIDIA выигрыша не получат. Принятие в основную ветку не гарантировано, независимых замеров нет.
Следить за темой стоит, если вы запускаете Qwen-подобные MoE-модели на NVIDIA и хотите выжать скорость генерации. Остальным достаточно знать, что такая оптимизация существует, и не строить на ней планы до момента, когда изменение окажется в основном репозитории.