Активация экспертов и роутинг стратегий в ИИ: почему одной траектории недостаточно и как работает Qwen3.8-Flash-Next

От вычислений к принятию решений: почему классического роутера недостаточно

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

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

Выход архитектуры Qwen3.8-Flash-Next обнажил эту проблематику с максимальной наглядностью. Масштабная модель способна умещать в себе колоссальный объём весов, но задействовать для обработки каждого конкретного токена лишь скромную их часть. Это отличный пример эффективного распределения вычислительных ресурсов, но одновременно с этим — четкая граница между оптимизацией вычислений и выбором стратегии поведения. В этой статье я хочу детально разобрать эту грань, разграничивая общеизвестные архитектурные механизмы, мою личную интерпретацию и исследовательскую гипотезу.

Разреженная архитектура: гигантский объём при малом рабочем контуре

Согласно технической документации авторов Qwen3.8-Flash-Next, перед нами разреженная модель класса Mixture-of-Experts (MoE) с общим объёмом в 125 миллиардов параметров. При этом на обработку одного токена активируется лишь порядка 6 миллиардов параметров. В дополнение к этому система использует внешние таблицы n-граммных представлений размером 51 миллиард параметров, вынесенные в оперативную память хоста, за пределы видеопамяти ускорителя.

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

Чтобы наглядно представить работу MoE, вообразите крупное инженерное предприятие. В его штате числятся аналитики данных, специалисты по информационной безопасности, инженеры инфраструктуры, разработчики интерфейсов и исследователи ML. Чтобы обсудить оптимизацию кодека для видеопотока, вам не нужно собирать полный консилиум из сотен сотрудников. Достаточно пригласить в переговорку тех двоих или троих экспертов, чья узкая компетенция напрямую касается проблемы.

В архитектуре MoE роль такого модератора выполняет внутренний роутер. Он анализирует векторное представление токена и перенаправляет его к конкретным блокам-экспертам. Эксперты выполняют математические преобразования, после чего их результаты снова объединяются в общий поток модели.

Подобный подход к условной активации параметров не нов. Ещё в Switch Transformer применялась упрощенная схема маршрутизации к одному эксперту, позволявшая наращивать ёмкость сети без пропорционального роста вычислительной сложности на каждый входной токен. Создатели Switch Transformer подробно описывали инженерные компромиссы: проблемы сбалансированности нагрузки между экспертами, нестабильность сходимости при обучении и высокие коммуникационные задержки. Модель Qwen развивает эту концепцию, внедряя продвинутую работу с длинным контекстом, специфические остаточные связи и оффлоудинг n-граммной памяти.

Почему эксперт внутри MoE не равен отдельному аналитику

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

Однако классическая модель MoE устроена иначе:

• Классический MoE-роутер: отвечает на вопрос «Какие именно блоки весов целесообразно подключить для вычисления текущего токена?»
• Стратегический роутер: отвечает на вопрос «Какие альтернативные сценарии действий необходимо сформулировать, как их верифицировать и стоит ли вообще принимать решение прямо сейчас?»

Внутренние эксперты MoE являются фрагментами единого графа вычислений. Это однотипные по структуре слои, обучавшиеся совместно в единой нейросетевой системе. Выбор top-k экспертов для одного токена — это локальная оптимизация вычислений, а не генерация k независимых планов с оценкой альтернативных рисков. Можно скомпоновать крайне экономную систему активации весов, но при этом моментально уйти по абсолютно ошибочному вектору рассуждения.

Аналогия с рекой: как выбор стратегии зависит от условий

Представим стандартную задачу: перед нами река, и нам требуется оказаться на противоположном берегу. Существует несколько принциально разных способов решения:

1. Переплыть вплавь: минимальные затраты времени и ресурсов, но стратегически высокорискованно, если течение сильное или глубина неизвестна.
2. Возвести мост: капиталоёмкий и долгий путь, однако дающий надёжную инфраструктуру для регулярного использования в будущем.
3. Найти брод: путь увеличится по расстоянию, зато уровень риска кардинально снизится.
4. Переосмыслить цель: проанализировать, действительно ли необходимо перебираться на тот берег, или задачу можно решить на текущей стороне.
5. Отложить действие: зафиксировать неопределенность, дождаться прогноза погоды или провести замеры глубины.

В таблице ниже показано, как контекст меняет приоритеты этих вариантов:

Если отправить языковой модели простой промпт «предложи лучший способ пересечь реку», она почти наверняка выдаст один наиболее правдоподобный сценарий. Однако в реальной инженерии задача часто заключается не в том, чтобы написать красивый текст решения, а в том, чтобы понять, достаточно ли у нас данных для совершения этого выбора.

Имеющийся задел: что уже предложили исследователи

Идея не ограничиваться единственной цепочкой токенов развивалась в сообществе AI на протяжении последних лет. На сегодняшний день в арсенале разработчиков есть целый ряд готовых концепций:

• Self-Consistency: сэмплирование нескольких независимых путей рассуждения (Chain-of-Thought) с последующим выбором наиболее часто встречающегося ответа.
• Tree of Thoughts (ToT): представление промежуточных шагов рассуждения в виде дерева поиска, где система может оценивать перспективы веток, заглядывать на шаг вперёд и откатываться назад при тупиках.
• RouteLLM и FrugalGPT: механизмы внешней маршрутизации, которые перенаправляют простые запросы к дешевым компактным моделям, а сложные — к флагманским нейросетям, оптимизируя общий вычислительный бюджет.
• Adaptive Computation Time (ACT): подходы, позволяющие нейросети динамически изменять количество вычислительных шагов в зависимости от сложности входного объекта.
• Selective Classification: концепция, при которой классификатор имеет право отказаться от ответа (модель делает сноску «не уверена»), если уверенность ниже заданного порога, снижая процент фатальных ложноположительных срабатываний.

Таким образом, основные составляющие уже известны: экономная активация весов, построение нескольких траекторий, каскадирование моделей, адаптивные вычисления и механизм отказа. Наша цель — правильно соединить их для решения практических задач с высокой ценой ошибки.

Инженерная гипотеза: маршрутизация режимов действия

Я предлагаю взглянуть на архитектуру системы, которая начинает работу не с прямым формированием ответа, а со стартовой оценки самой задачи. Первичный модуль определяет категории риска: насколько обратимо действие, какова стоимость ошибки, достаточно ли входящей информации и сколько токенов/секунд оправданно потратить на обработку.

Для этой первичной оценки не обязательно использовать тяжелую LLM — с ней отлично справится компактный классификатор или настраиваемый свод правил. После оценки система переключается в один из пяти режимов:

1. Быстрый режим: применяется для простых и легкообратимых запросов. Работает одна ветка с минимальным циклом проверки.
2. Режим альтернатив: параллельно формируется несколько принципиально разнящихся стратегий, а не переформулировки одной идеи.
3. Режим критической проверки: отдельный компонент пытается целенаправленно опровергнуть сформированные гипотезы, проверяя граничные условия и логические противоречия.
4. Режим воздержания: система прямо указывает, каких именно сведений не хватает, отказавшись от генерации галлюцинаций.
5. Передача оператору: если действие связано с критическими рисками или финансами, система формирует аргументированную сводку и передаёт право финального клика человеку.

Чтобы избежать ситуации, когда три независимых агента предлагают одну и ту же мысль разным словесным оформлением, каждая стратегия должна строго соответствовать следующей структуре:

• action — конкретное предлагаемое действие;
• assumptions — набор допущений, при которых план имеет смысл;
• required_evidence — факты и метрики, необходимые для финальной валидации;
• cost — вычислительная стоимость, временные задержки или бюджет;
• risk — потенциальные последствия в случае провала.

Ансамбли и мультиархитектурность: иллюзии и реальная польза

Ранее у меня была гипотеза, что использование кардинально разных нейросетевых архитектур в одной цепочке автоматически спасет от дублирования ошибок. На практике это работает не всегда. Разные модели зачастую обучаются на пересекающихся датасетах из интернета, проходят схожие процедуры выравнивания (RLHF) и одинаково ложно трактуют двусмысленные формулировки.

Это подтверждают и свежие исследования многомодельных систем. В работе Rethinking Mixture-of-Agents авторы доказали, что объединение слабосовместимых различных моделей часто уступает по точности многократному сэмплированию решений от одной сильной модели. Слабые компоненты не добавляют «мудрости», они лишь зашумляют итоговый ансамбль.

При проведении экспериментов я рекомендую измерять не различие в названиях архитектур, а реальную структуру ошибок:

• Частоту коррелированных (одновременных) ошибок компонентов;
• Степень смыслового разнообразия сгенерированных стратегий;
• Уровень уверенности модели при совершении ложных выводов;
• Способность арбитра выявлять скрытые логические конфликты;
• Итоговый прирост точности с учётом задержки (latency) и стоимости токенов.

Применение подхода в прикладных системах

Подобный подход критически важен в реальных инженерных проектах:

• Анализ пассажиропотока: спорный визуальный кадр с камеры видеонаблюдения не должен сразу формировать итоговую цифру в отчёте. Быстрый поток обрабатывает четкие кадры, а сомнительные случаи отправляются на дополнительную валидацию по телеметрии или на ручную выборку.
• Корпоративные базы знаний (RAG): сервер авторизации обязан жестко отсекать права доступа до того, как контекст передаётся нейросети. Если данных недостаточно, система задает уточняющий вопрос пользователю, а не пытается додумать содержание регламента.
• Автоматический осмотр транспорта: если алгоритм OCR считывает госномер авто с низкой уверенностью, намного выгоднее попросить водителя сделать повторный снимок, чем привязать повреждения к чужому автомобилю.

Запуск Qwen3.8-Flash-Next 125B на видеокарте с 6 ГБ VRAM

Для практической проверки работы разреженных архитектур мы развернули оригинальный весовой чекпоинт Qwen3.8-Flash-Next 125B на рабочей станции с одной видеокартой NVIDIA GeForce RTX 4090. Благодаря архитектурным особенностям модели и выносу таблиц n-граммных представлений в системную память (RAM), пиковое потребление видеопамяти VRAM составило всего 5,95 ГБ.

При этом генерация выполнялась без применения агрессивной 4-битной квантизации или дистилляции — использовался исходный чекпоинт в формате precision bf16. Это наглядно демонстрирует, как современный раздельный роутинг вычислений позволяет запускать модели с 125B параметров на локальном железе среднебюджетного сегмента.

Выводы и дальнейшие шаги

Разреженные архитектуры вроде MoE в Qwen3.8-Flash-Next доказали: физический размер модели и объём активных вычислений на токен больше не связаны жесткой пропорцией. Однако экономный роутинг параметров внутри нейросети не решает задачу верхнего уровня — умение вовремя переключиться на альтернативный сценарий, запросить вводные данные или отказаться от совершения действия.

В следующем материале я представлю строгий численный эксперимент и код на Python, где на конкретных метриках покажу, как соотносится точность отдельных компонентов с надёжностью всей цепочки принятия решений.

Источник: habr.com