Яндекс опубликовал открытые веса модели AliceAI-T5-35B-A0.6B Base, обученной с нуля: это encoder-decoder с высоко-разреженным MoE по рецепту UL2, где на каждый токен активно около 0,6 млрд параметров из 34,35 млрд. Модель отвечает за секунды и обслуживает быстрые ответы Алисы AI в Поиске Яндекса.

image
image
image

Что произошло

В репозиторий на Hugging Face выложены веса в формате safetensors (порядка 35 млрд параметров), код и инструкция по загрузке через Hugging Face Transformers, а также два готовых примера: генерация ответа и минимальное дообучение через LoRA на базе Transformers + PEFT. Архитектура кастомная, aliceai_t5_moe: энкодер 16 слоёв с 12 головами внимания, декодер 12 слоёв с 12 query-головами и 4 KV-головами, скрытое состояние 1 536, словарь 135 040, эмбеддинги, связанные с LM head. Контекст модели — 128k токенов с RoPE + YaRN, в каждом MoE-слое 512 экспертов с маршрутизацией top-8. Из-за нестандартной архитектуры загрузка требует trust_remote_code=True.

Контекст

Модель — претрейн под конкретную продуктовую задачу: быстрые ответы Алисы AI в Поиске Яндекса. Дообученная версия Alice AI Search уже генерирует такие ответы в проде, а архитектура спроектирована под нагрузку в сотни тысяч запросов в минуту. Рецепт UL2 означает предобучение на предсказании пропущенных spans, а не на чистом языке, что ближе к задаче QA, чем классический next-token. В официальной карточке опубликованы и сильные, и слабые стороны: по фактуальности модель показывает WikiWebFacts 81,3, CultCat 68,0, извлечение на 32K — Ruler 94,7; при этом уступает Qwen 3.5 35B-A3B Base по математике (MATH 500: 62,9 против 81,9), MMLU (78,5 против 84,4) и работе с 128K контекстом (Ruler: 81,4 против 90,1). Публичное указание слабых сторон вместе с сильными — признак добросовестной отчётности, а не cherry-picking бенчмарков.

Почему это важно для индустрии

Релиз показывает, что высоко-разреженная encoder-decoder MoE с долей активных параметров порядка 1:58 способна обслуживать массовый поисковый сценарий с дешёвым и быстрым инференсом, а не только лабораторные бенчмарки. Связка span-prediction претрейна, очень высокой разреженности и связанных эмбеддингов — конкретная инженерная ставка на search/QA/RAG нагрузки, а открытие весов с примером LoRA делает её воспроизводимой: другие команды могут повторить подход для собственных русскоязычных поисковых моделей. Для рынка это публичный референс, задающий новую точку отсчёта по соотношению цены инференса и скорости ответа, и сигнал о том, что экономика search/QA/RAG на русском может заметно подешеветь.

Почему это важно для пользователей

Практический выход простой: веса уже можно скачать с Hugging Face, прогнать инференс — активных параметров немного, поэтому он дешёвый, — и дообучить модель под свои данные через LoRA, минимальный рабочий пример есть в репозитории. Получается готовый baseline быстрых русскоязычных ответов и возможность собственных QA/RAG-экспериментов на 128k контексте без API и без зависимости от внешних сервисов. Ограничения для самостоятельного развертывания: кастомный код через trust_remote_code, нет публичных цифр задержек и пропускной способности, API нет.

Что пока неизвестно / ограничения

Опорные цифры — внутренние бенчмарки Яндекса на претрейне, независимых замеров качества пока нет. Публичных latency/throughput-измерений за пределами заявлений о продуктовой нагрузке источники не приводят: факт работы в проде подтверждает задержки и пропускную способность продуктовой связки, но не является научным подтверждением качества. Полный рецепт претрейна (данные, вычисления) не раскрывается, а причинная связь между рецептом, архитектурой и данными в источниках не доказана.

Источники

Автор

Look at AI, редакция