1 ноября 2026 года в r/LocalLLaMA появился пост с двумя вопросами: есть ли у сообщества удачный опыт с диффузионными моделями с открытыми весами и движутся ли открытые лаборатории в этом направлении. Автор попробовал Mercury 3 и описал её генерацию так: «different taste, attitude, way of thinking that was actually refreshing». Дальше он упёрся в фильтры: они срабатывали, как только в промпте появлялся adb, поэтому полноценно протестировать модель не удалось (обсуждение на Reddit).
Короткий ответ на главный вопрос: диффузионные языковые модели существуют и работают иначе, чем привычные авторегрессионные, но подтверждённого перечня открытых диффузионных LLM с опубликованными весами в доступных источниках нет. Вопрос из поста остаётся открытым. Про саму Mercury 3 материалы не содержат сведений о весах, архитектуре и пригодности для локального запуска, так что записывать её в «открытые» нет оснований.
Вторая часть истории важнее для практики: даже когда веса открыты, защитные барьеры API вместе с ними не переезжают. Mistral прямо предупреждает, что при самостоятельном хостинге командам нужно строить собственные средства безопасности, потому что встроенные фильтры работают на стороне сервиса.
Что такое диффузионные языковые модели и почему у них другой стиль генерации
Авторегрессионная модель предсказывает следующий токен по уже сгенерированным: вероятность очередного токена при условии предыдущих. Отсюда причинная маска, жёсткий порядок слева направо и KV-cache, который экономит вычисления на каждом следующем шаге. Плата за это - невозможность откатить текст: выданный токен попал в контекст и стал условием для всех следующих.
Диффузионная языковая модель держит в работе всю последовательность целиком. Стартовое состояние - зашумлённое представление будущего ответа, затем идёт несколько шагов денойзинга: модель постепенно убирает шум и уточняет все позиции сразу, а не по одной. Промежуточные версии можно пересматривать, поэтому общий план текста складывается более цельно.
Ниже общее описание архитектур. В источниках к этому материалу нет технического сравнения диффузионных и авторегрессионных LLM с замерами, поэтому цифр по скорости и качеству здесь не будет.
Авторегрессия vs диффузия: где именно расходятся архитектуры
| Свойство | Авторегрессионная LLM | Диффузионная LLM |
|---|---|---|
| Порядок генерации | Слева направо, по одному токену | Итеративно, все позиции за шаг денойзинга |
| Правка готового фрагмента | Невозможна: токен уже в контексте | Возможна на промежуточных шагах |
| Кеширование | KV-cache напрямую ускоряет продолжение | KV-cache даёт меньше выигрыша, счёт идёт на число шагов |
| Планирование текста | Локальное, по префиксу | Более глобальное, по всей длине ответа |
Существуют гибридные схемы и блочно-диффузионные подходы, где денойзинг идёт блоками, а не всей последовательностью сразу. Конкретные названия моделей и их характеристики в источниках к статье не приводятся, поэтому ограничусь уровнем класса архитектур.
Отдельно про скорость: утверждение «диффузия быстрее» проверяемых данных в материале не имеет. Число шагов денойзинга, длина ответа и реализация ядра влияют на итог сильнее, чем сама парадигма.
Почему генерация кажется «другой»: что реально замечает пользователь
Отзыв о Mercury 3 описывает не качество, а характер: другой вкус, другая установка, другой способ мышления. Такое впечатление правдоподобно объясняется механикой. Модель строит ответ целиком, а не наращивает его по префиксу, поэтому реже скатывается в самые предсказуемые продолжения и меньше привязана к ритму первого предложения.
Без контролируемого сравнения на одинаковых промптах отличия легко переоценить. Работает novelty-эффект: необычная формулировка воспринимается как более умная, хотя фактическая точность может быть ниже. Проверить это можно только вслепую: прогнать один и тот же набор промптов через диффузионную и авторегрессионную модель и оценить ответы, не зная, где чей.
Mercury 3 на практике: необычный стиль и фильтр, который срабатывает на adb
Кейс из поста короткий: необычный стиль понравился, тестирование не состоялось. Формулировка автора - фильтры против кибербезопасности «срабатывают, как только я упоминаю adb», из-за чего протестировать модель толком не удалось (по словам автора поста).
adb, или Android Debug Bridge, - штатный инструмент разработки под Android. Через него ставят пакеты, снимают логи, делают скриншоты, получают shell-доступ к устройству. Ничего специфически вредоносного в самом слове нет, им пользуются миллионы разработчиков и тестировщиков.
Почему adb триггерит safety-фильтр
Классификатор безопасности оценивает поверхностные паттерны, а не намерение автора запроса. Отладочные инструменты, shell-лексика, команды установки и доступа к файловой системе устройства попадают в одну категорию с реверс-инжинирингом и рутингом. Дальше срабатывает категорийный запрет, и контекст «я разработчик, объясни синтаксис команды» часто уже не учитывается.
Практический приём один: формулировать задачу, а не инструмент. Вместо «как через adb вытащить логи с устройства» описать, что нужно получить и зачем, и позволить модели предложить способ. Это снижает вероятность ложного срабатывания, но не гарантирует результат: политика фильтра может запрещать и саму задачу. Полный обход фильтров закрытой модели не цель этого разбора и не обещается.
Что это говорит о зрелости диффузионных моделей
Если модель нельзя прогнать на технических задачах из-за ложных срабатываний, для разработчика это блокер, каким бы интересным ни был стиль генерации. Отладка, сборка, работа с устройством, разбор логов - типовой рабочий контур, и он отваливается целиком.
При этом проблема лежит не в диффузионной архитектуре, а в слое безопасности поверх неё. Локальный запуск меняет расклад: фильтры становятся вашей зоной ответственности, и вы сами решаете, где проходит граница между полезной технической лексикой и запрещённой темой.
Какие открытые диффузионные модели с открытыми весами существуют
Прямой ответ: подтверждённого списка открытых диффузионных LLM с опубликованными весами в доступных источниках нет. Вопрос из поста - «Do people here have good experience with open weights diffusion models?» - остался без содержательного ответа в самом обсуждении (исходный тред). Придумывать названия, версии и ссылки на несуществующие релизы в такой ситуации бессмысленно: читатель потратит время на поиск того, чего нет.
Практическая рамка простая: направление существует и обсуждается, но публичная экосистема вокруг него пока не сложилась. Это не значит, что весов нет вообще, это значит, что проверить их наличие нужно самостоятельно по формальным признакам, а не по упоминаниям в комментариях.
Как проверить, что модель действительно открытая
- Веса можно скачать: на странице модели есть файлы, а не только демо и кнопка «попробовать».
- Лицензия названа явно: коммерческое использование разрешено, ограничено по размеру выручки или запрещено.
- Есть карточка модели: архитектура, число параметров, длина контекста, обучающие данные в общих чертах.
- Указаны требования к железу или хотя бы формат весов (bf16, fp8, квантованные варианты).
- Понятно, что именно открыто: код обучения без весов, веса без данных или полный релиз. Три разных сценария с разными практическими следствиями.
Разница между open weights и open source подробно разобрана в материале о паритете open-weight и frontier-моделей: там же про метрики, которые действительно что-то доказывают, и про расчёт VRAM перед скачиванием.
Mistral Large 4 как ориентир открытых релизов
Контрастный пример из авторегрессионного лагеря. Mistral открыла веса улучшенной версии мультимодальной Mistral Large 4, неофициально прозванной «Le Chonk»: триллион параметров, заявленные режимы Low для простых задач, Medium для повседневных и High для сложных случаев с многошаговым анализом. По данным Artificial Analysis модель показывает результат на уровне лучшей открытой модели, расходуя на 47% меньше токенов на задачу (публикация о релизе Mistral Large 4).
Сравнивать эту модель с Mercury 3 по качеству нельзя: общих замеров в источниках нет, а веса Mercury 3 там даже не описаны. Ценность примера в другом: он показывает, как выглядит публичный открытый релиз с лицензией, бенчмарками и режимами работы. На таком фоне диффузионное направление выглядит экспериментальным.
Если планируете оценивать новый релиз Mistral под свои задачи, пригодится чек-лист из разбора чего ждать от новой модели Mistral: рассуждения, код, длинный контекст, русский язык, стоимость токенов и локальный запуск.
Фильтры безопасности диффузионных моделей: API vs локальный запуск
Ключевой тезис, который стоит запомнить: открытые веса не гарантируют переноса защитных барьеров. Mistral формулирует это прямо - при самостоятельном хостинге встроенные барьеры, работающие на стороне API, не переносятся автоматически, и командам, развёртывающим модель локально, необходимо реализовать собственные средства безопасности (сообщение Mistral о локальном развёртывании).
Как вендор измеряет безопасность, видно по его же цифрам: средний уровень отказов 96,6% на вредоносных запросах по тестам JailbreakBench, StrongREJECT и AgentHarm, самый высокий среди открытых моделей по данным компании, и 51% в Artificial Analysis Cyber Index, метрике способности находить, воспроизводить и безопасно исправлять уязвимости в коде. Это данные самой Mistral, независимая проверка в источниках не приводится, так что воспринимать их стоит как заявленные, а не как подтверждённые третьей стороной.
Что вы теряете и что получаете без API-фильтров
Получаете контроль над ложными срабатываниями, возможность спокойно обсуждать adb, shell, отладку и системное администрирование, а также воспроизводимость: одна и та же версия модели отвечает одинаково до и после обновления чужого сервиса. Для исследовательских задач это заметная выгода.
Теряете готовый защитный слой и всю ответственность перекладываете на себя. Нужен собственный классификатор или хотя бы политика: какие темы режем, что логируем, как ограничиваем агентный доступ к файлам и сети. Для внутреннего инструмента разработчика это решаемо. Для продукта с внешними пользователями отсутствие такого слоя означает выпуск модели без ограничений.
Как снизить ложные срабатывания при тестировании
- Описывайте задачу и результат, а не команду: «нужно собрать журнал с тестового устройства» вместо «adb logcat».
- Давайте роль и контекст: учебный проект, отладка собственного приложения, проверка на своём устройстве.
- Дробите запрос: сначала теория, потом конкретный синтаксис, потом разбор ошибки.
- Тестируйте на локальной копии с собственной политикой фильтрации, чтобы отделить ограничения модели от ограничений сервиса.
Ни один из приёмов не даёт гарантии на закрытом API: решение принимает классификатор провайдера. На локальной модели вы хотя бы видите, где именно стоит фильтр и по какому правилу он сработал.
Реальные сценарии локального запуска диффузионных LLM
Подтверждённых сценариев немного, и все они исследовательские: сравнение стилей генерации, эксперименты с нестандартными промптами, проверка гипотез о планировании текста. Именно этим занимался автор поста, пока не упёрся в фильтры.
Гипотетически перспективны задачи, где важен глобальный план: переписывание больших фрагментов, структурная правка, приведение длинного текста к единому ритму. Замеров под это в источниках нет, поэтому воспринимать стоит как гипотезу, а не как преимущество.
Что нужно от железа и софта
Факторы те же, что и для любой локальной LLM: объём VRAM под веса и контекст, поддержка архитектуры в раннере, наличие квантованных версий. Конкретные цифры по диффузионным моделям не привожу, в источниках их нет, а переносить оценки с авторегрессионных моделей некорректно.
Порядок действий экономит нервы: сначала проверить, что выбранный раннер умеет нужную архитектуру, потом посмотреть формат весов и только затем качать десятки гигабайт. Как считается память под веса, контекст и KV-cache, разобрано в статье про архитектуру LLM, контекстное окно и стоимость инференса.
Где диффузионные модели пока проигрывают
- Мало открытых весов: скачать и запустить почти нечего, приходится работать через чужой API.
- Слабая экосистема: меньше готовых рецептов, квантований, обвязки для агентов и RAG.
- Непредсказуемое качество на длинных задачах: пересмотр фрагментов помогает не всегда.
- Нет устоявшихся независимых бенчмарков, сравнивать модели между собой толком нечем.
- Ложные срабатывания фильтров у закрытых версий отрезают целые технические домены.
Вывод прямой: если нужна предсказуемая рабочая лошадка для кода, агентов или продакшена, диффузионная LLM сегодня не первый выбор. Для экспериментов и наблюдения за направлением - вполне.
Куда движутся открытые лаборатории и чего ждать от нового поколения
На вопрос «is that a direction where some of the open labs are going?» прямого подтверждения в материалах нет: никто из крупных лабораторий в источниках не заявлен как разработчик открытой диффузионной LLM. Что видно по фактам: серьёзные открытые релизы выходят в авторегрессионном и мультимодальном лагере. Mistral Large 4 с триллионом параметров и открытыми весами - как раз такой случай.
Рыночный контекст подталкивает именно к этому. Mistral привлекла в сентябре $3,3 миллиарда при оценке в $24 миллиарда, а в июне 2026 года США временно ограничили распространение моделей OpenAI и Anthropic, что усилило спрос на суверенный европейский ИИ, не зависящий от экспортного контроля (материал о релизе и контексте рынка). Деньги и политика влияют на то, какие архитектуры получат открытые веса, и пока приоритет не в пользу диффузии.
Сигналы, за которыми стоит следить
- Крупная лаборатория публикует веса диффузионной LLM, а не только препринт.
- Архитектура появляется в популярных раннерах: если её поддержали vLLM, llama.cpp или аналоги, это признак спроса.
- Возникают независимые бенчмарки, где диффузионные модели меряются с авторегрессионными на одних задачах.
- Выходит релиз с открытой лицензией, допускающей коммерческое использование.
Отсутствие этих сигналов тоже информация: значит, направление остаётся лабораторным. За открытыми сравнениями удобно следить через краудсорсинговый бенчмарк моделей с открытыми весами, где оценки ставят эксперты по доменам, а не LLM-судья.
Прогноз держу как гипотезу: если диффузионные LLM получат открытые веса и поддержку в раннерах, направление оживёт за счёт исследователей и локального сообщества. Без этого оно останется экспериментом с чужим API и непредсказуемыми фильтрами.
Как самому протестировать диффузионную модель: чек-лист
- Определите задачу и базовую модель для сравнения. Без второй модели любой результат превращается в впечатление.
- Подготовьте одинаковый набор промптов, 10-15 штук. Обязательно включите технические: с adb, shell-командами, разбором логов, чтобы проверить ложные срабатывания фильтров.
- Зафиксируйте критерии до запуска: структура ответа, стиль, фактическая точность, число фактических ошибок, готовность следовать формату.
- Проверьте лицензию, формат весов и требования к VRAM до скачивания. Оцените память под веса плюс контекст, а не только размер файла.
- При локальном запуске заранее решите, какие фильтры и правила безопасности ставите сами: без этого вы получите модель без ограничений и без логов.
- Записывайте результаты в таблицу и оценивайте ответы вслепую, не зная, какая модель их выдала. Так novelty-эффект не подменит выводы.
Один удачный ответ ничего не доказывает: ни в плюс, ни в минус. Логика собственного теста на двух моделях подробно разобрана в материале про сравнение двух моделей для реальной разработки, где показано, почему одного бенчмарка недостаточно.
Начните с малого: возьмите пять промптов из своей ежедневной работы, добавьте один провокационный на adb и прогоните оба варианта в один вечер. Этого хватит, чтобы понять, есть ли за «освежающим стилем» практическая ценность или только непривычная формулировка.