Clover в llama.cpp: MoE-модель на базе Qwen3.6-35B-A3B с блочной диффузией и контекстом 128K

Clover - текстовая MoE-модель, построенная на базе Qwen3.6-35B-A3B. У неё 35 млрд параметров при примерно 3 млрд активных на токен, гибридная архитектура Gated DeltaNet (GDN) и полного внимания внутри MoE, а текст генерируется блоками через диффузию. Заявленный контекст - 128K, до 131 072 токенов суммарно на промпт и ответ.

Повод говорить о ней появился вместе с пул-реквестом feat: add Clover support by Maphist0 (PR #31306) в репозитории ggml-org/llama.cpp (описание пул-реквеста). Это шаг к поддержке модели в популярном локальном рантайме, и шаг первый: статус слияния в описании не указан.

Оговорка по фактам, без которой разбор превратится в пересказ анонса. Все характеристики Clover ниже взяты из описания пул-реквеста. Независимых замеров, бенчмарков, данных о скорости и требованиях к памяти в источнике нет, поэтому эти цифры остаются заявленными, а не проверенными.

Что такое Clover и почему о ней заговорили в контексте llama.cpp

Clover - текстовый вариант на базе Qwen3.6-35B-A3B с переработанной генерацией. Наследственность важна: базовый масштаб, токенизатор и большая часть поведения наследуются от Qwen3.6-35B-A3B, а диффузионная надстройка меняет то, как модель выдаёт текст.

Ключевые параметры модели: 35B всего, ~3B активных, 128K контекста

Разница между 35 млрд и 3 млрд - не бухгалтерская тонкость. В MoE на каждом токене активируется только часть экспертов, поэтому ~3 млрд активных параметров описывают вычисления на шаг, а 35 млрд общих - объём весов, которые должны быть доступны. Для локального железа это два разных ограничения: скорость упирается в активные параметры, вместимость памяти - в общие.

С контекстом тоже есть нюанс, который легко упустить. 131 072 токена - это суммарный бюджет на промпт и сгенерированный ответ, а не отдельный лимит на каждую часть. Если промпт занял 100 тысяч токенов, на ответ остаётся около 31 тысячи.

Чем Clover отличается от привычной авторегрессионной LLM

Авторегрессионная модель пишет строго слева направо. Каждый следующий токен считается по всем предыдущим, и токен физически не может посмотреть на токены, которых ещё нет. Отсюда последовательная генерация и жёсткая причинность на каждом шаге.

Clover генерирует блоками. Внутри блока работает двунаправленное внимание: токены видят друг друга и уточняются совместно. Между блоками сохраняется причинный префикс, то есть уже сгенерированный текст остаётся опорой для следующих блоков, а не переписывается заново.

Это архитектурное отличие. В описании пул-реквеста нет ни сравнений с авторегрессионными моделями того же масштаба, ни цифр по скорости или качеству. Выводы в духе «диффузия быстрее» пока остаются гипотезой без данных.

Как устроена гибридная архитектура: Gated DeltaNet и полное внимание в MoE

Гибрид здесь складывается из двух механизмов внимания и маршрутизации на экспертов. Gated DeltaNet (GDN) - рекуррентный по своей природе компонент: он ведёт внутреннее состояние и обновляет его по ходу последовательности, вместо того чтобы каждый раз пересчитывать внимание по всей истории. Полное внимание решает другую задачу: токен собирает информацию по всему доступному контексту без сжатия в компактное состояние. Оба механизма сосуществуют внутри одной модели, а MoE-слой отправляет каждый токен на подмножество экспертов - отсюда ~3 млрд активных из 35 млрд.

Смысл гибрида в общем случае понятен: полное внимание дорожает на длинном контексте, рекуррентная часть держит состояние дешевле. Заявленные 128K как раз тот режим, где такая разница проявляется. Конкретных замеров под Clover в источнике нет, поэтому это объяснение принципа, а не измеренная характеристика модели.

Зачем GDN дополнительные обученные параметры для диффузии

Ключевая деталь из описания PR: дополнительные обученные параметры GDN поддерживают блочную диффузию при сохранении причинного префикса.

Задача нетривиальная. Диффузия внутри блока требует, чтобы токены блока видели друг друга. При этом нельзя терять причинность относительно уже сгенерированного текста, иначе модель начнёт переписывать прошлое и развалится в циклы. Обученные под диффузию параметры GDN - заявленный механизм, который удерживает этот баланс.

Как именно это реализовано на уровне тензоров и формул, описание пул-реквеста не раскрывает. Нужна глубина - смотреть код и обсуждение PR, когда появится рабочая ветка.

Блочная диффузия: как Clover генерирует текст

Единица генерации здесь не токен, а блок. Общая схема блочной диффузии для текста выглядит так:

1. Модель берёт блок фиксированной длины, а не одну позицию.
2. Позиции блока инициализируются заготовкой и уточняются за несколько проходов, при этом все токены блока доступны друг другу благодаря двунаправленному вниманию.
3. Доведённый блок фиксируется и становится частью причинного префикса для следующего блока.
4. Цикл повторяется до лимита контекста или до появления признака остановки.

Это общая механика блочной диффузии, а не документированное описание конкретных шагов Clover: числа итераций, расписания уточнения и правил сэмплинга в источнике нет.

Сравнение по числу шагов напрашивается само: блок из N токенов в теории можно довести за меньшее число проходов, чем N последовательных шагов авторегрессии. На практике у диффузии своя цена - несколько проходов по одному блоку, накладные расходы на уточнение, открытый вопрос стабильности качества. В источнике нет ни одного замера tok/s, поэтому обещаний по скорости тут не будет.

По факту можно утверждать одно: Clover меняет единицу генерации с токена на блок. Для тех, кто следит за диффузионными языковыми моделями как классом, это отдельная механика уточнения, и переносить на неё привычные ожидания от авторегрессии не стоит.

Что даёт поддержка Clover в llama.cpp и что это значит для локального запуска

llama.cpp - открытый рантайм для локального инференса на базе ggml. Он собирается под CPU и основные GPU-бэкенды, работает с квантованными весами и потому стал рабочим инструментом для тех, кто запускает модели на своём железе. Поддержка архитектуры в нём - условие того, что модель вообще можно конвертировать, запустить и прогнать через привычные инструменты.

Для Clover в репозиторий ggml-org/llama.cpp добавлен пул-реквест feat: add Clover support by Maphist0 (PR #31306). Слово «добавлен» относится к появлению PR, а не к слиянию в основную ветку. Статус слияния и наличие в релизах в источнике не указаны.

Практический вывод: пока PR не слит и не попал в релиз, планировать локальный запуск Clover через llama.cpp преждевременно. Нет ни готовых квантов, ни проверенных команд запуска, ни данных о потреблении памяти. Следить за веткой смысл есть, строить на ней рабочий процесс - нет.

Кто не готов ждать, обычно смотрит на альтернативные движки. Сравнение llama.cpp и vLLM (разбор на конфигурации с RTX 3090 и RTX 5060) показывает, что разница между ними часто не в скорости, а в том, кто быстрее получает поддержку новых MoE-архитектур.

Почему MoE-модели интересны для локального запуска

MoE разрывает связь между «сколько весов» и «сколько вычислений на токен». На каждом шаге работает лишь часть экспертов, поэтому 3 млрд активных параметров дают вычислительную нагрузку уровня небольшой модели. Память при этом считается по общим 35 млрд: неактивные эксперты всё равно должны быть доступны, иначе маршрутизация приведёт в пустоту.

Отсюда типичный компромисс на домашнем железе: вычислений хватает, места под веса не хватает. Решения известны - квантование, выгрузка части слоёв в системную память, подкачка экспертов по требованию. В экосистеме llama.cpp это отдельное направление. Разбор Hot Expert Reload (подкачка активных экспертов в VRAM во время генерации) показывает, что выигрыш упирается в пропускную способность памяти и поведение роутера. Материал про expert expansion в экспериментальной ветке (что даёт расширение числа активных экспертов) напоминает, почему один удачный тест на Metal не доказывает ничего для CUDA и CPU.

Ещё один пример оптимизаций под MoE в llama.cpp - PR #29184, где shared experts объединяют в MMVQ-вычислениях (разбор CUDA-оптимизации); выигрыш там касается не всех архитектур. К Clover эти наработки напрямую не прикладываются: в источнике нет ни требований к VRAM, ни данных о том, сколько занимают веса после квантования. Принцип общий, конкретика отсутствует.

Ограничения и открытые вопросы: что пока неизвестно

Список неизвестного здесь длиннее списка известного, и это главное, что стоит запомнить о пул-реквесте:

• Статус PR: открыт, в ревью, слит или заброшен, в описании не сказано.
• Характеристики модели (35 млрд, ~3 млрд активных, 128K, GDN, блочная диффузия) приведены как заявленные и независимой проверкой не подтверждены.
• Нет данных о скорости генерации и о том, как ведёт себя prefill.
• Нет требований к памяти, VRAM и RAM.
• Нет сравнения с авторегрессионными моделями того же масштаба, в том числе с базовой Qwen3.6-35B-A3B.
• Нет информации о квантовании: как блочная диффузия переживает потерю точности, неизвестно.
• 131 072 токена относятся к сумме промпта и ответа, а не к каждой части по отдельности.

Описание пул-реквеста легко принять за анонс готового продукта. Перед нами техническое предложение. Пока нет слияния, релиза и независимых замеров, любые планы на Clover строятся на одном документе.

Кому стоит следить за Clover, а кому подождать

Делить стоит по сценариям, а не по уровню энтузиазма.

• Экспериментируете с локальным запуском MoE и держите llama.cpp в рабочем состоянии. PR стоит добавить в отслеживаемые: слияние и первые кванты дадут реальный материал для выводов.
• Нужна стабильная модель под рабочую нагрузку. Опирайтесь на архитектуры с готовой поддержкой и проверенными квантами. Clover не даёт ни одного аргумента для миграции прямо сейчас.
• Изучаете диффузионные языковые модели. Кейс интересен архитектурно: сочетание GDN с блочной диффузией при сохранении причинного префикса встречается редко, и разбирать его лучше по коду, когда он появится.

Чек-лист, по которому удобно проверять обновления:

1. Статус PR #31306: открыт, в ревью или слит.
2. Релизные заметки llama.cpp: упоминается ли Clover в списке поддержанных архитектур.
3. Наличие GGUF-квантов от конвертеров, которым вы доверяете.
4. Независимые замеры: tok/s на prefill и генерации, потребление VRAM и RAM.
5. Поведение на длинном контексте: как расходуется бюджет 131 072 токена.
6. Качество против базовой Qwen3.6-35B-A3B на ваших задачах, а не на чужих демо.

Пока не закрыты первые три пункта, тема остаётся новостью для отслеживания. Как только появятся слияние, кванты и хотя бы один независимый замер памяти, разговор перейдёт из плоскости «интересно» в плоскость «попробовать на своём железе».

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