Режим thinking в Qwen3 заставляет модель рассуждать по шагам перед ответом: качество на сложных задачах растёт, а время и расход токенов растут вместе с ним. Поэтому его включают осознанно: на тестовом наборе своих задач сравнивают оба режима и оставляют рассуждение там, где оно окупается. Для коротких справочных вопросов режим лишний, для расчётов, кода и многошаговой логики он нередко решает исход.
Два режима
По блогу Qwen, у Qwen3 есть режим рассуждения и режим быстрых ответов: переключатель enable_thinking в шаблоне чата, а внутри диалога команды /think и /no_think. Режим рассуждения включён по умолчанию, лицензия Apache 2.0.
В режиме рассуждения модель строит цепочку шагов и лишь затем выдаёт ответ, поэтому ответ приходит позже и стоит больше токенов. Быстрый режим отвечает сразу и подходит для простых вопросов. Блог Qwen называет объём рассуждения управляемым бюджетом: чем больше модель размышляет, тем выше качество, но выгода убывает.
Какие модели Qwen3 существуют и как выбрать размер, описано в статье Qwen3: что нового и какую модель выбрать. Здесь один вопрос: как проверить рассуждение на ваших задачах и принять решение по цифрам.
Переключатель есть лишь у части моделей поколения: обновление 2507 выпущено отдельными моделями, и, по карточке, Qwen3-235B-A22B-Thinking-2507 работает только в режиме рассуждения, а Instruct-2507 отвечает без рассуждения. Поэтому перед запуском читайте карточку конкретной модели: есть ли в ней переключатель или нужна отдельная версия. Для режима рассуждения Qwen рекомендует температуру 0,6 и предупреждает, что жадное декодирование ухудшает качество; кроме того, в карточках советуют оставлять модели большой запас длины ответа, в десятки тысяч токенов. Актуальные детали лежат в блоге Qwen о третьем поколении.
Тестовый набор
Оценивать рассуждение по одной эффектной задаче бесполезно. Нужен набор, который отражает ваши реальные случаи и содержит ответы, проверяемые без модели.
- Соберите задачи разной сложности из своей работы: простые вопросы, расчёты, фрагменты кода, разбор документа, многошаговые условия.
- Для каждой задачи запишите правильный ответ или способ проверки: число, прохождение теста, совпадение с эталонным текстом.
- Зафиксируйте запрос и параметры генерации, чтобы оба режима работали в одинаковых условиях; для каждого режима карточка модели даёт свои рекомендованные значения.
- Прогоните набор в режиме рассуждения и в быстром режиме, записывая время, число токенов и верность ответа.
- Повторите прогон несколько раз: ответы модели меняются, и по одному запуску судить рано.
Условный пример: аналитик готовит набор из тридцати расчётных задач по продажам, у каждой есть проверенный ответ. В быстром режиме модель справляется с простыми задачами и чаще ошибается на многошаговых; в режиме рассуждения ошибок на сложных обычно меньше, зато время ответа заметно растёт. Аналитик оставляет рассуждение для сложных задач, а простые отправляет в быстрый режим.
Размер набора определяется терпением и задачами: десятков примеров достаточно для первой оценки, сотни нужны, если решение дорогое. Важнее разнообразие, чем количество: задачи одного типа дают картину только по этому типу.
Время и бюджет
Рассуждение обходится дорого дважды: пользователь дольше ждёт, а сервер тратит больше токенов. Эти издержки измеряют и сравнивают с выигрышем в качестве.
| Показатель | Как измерить | О чём говорит |
|---|---|---|
| Доля верных ответов | Сверка с эталоном на тестовом наборе | Окупается ли рассуждение на данном типе задач |
| Время до ответа | Среднее и худшие запросы в обоих режимах | Приемлемо ли ожидание для вашего сценария |
| Расход токенов | Сумма токенов входа и выхода по набору | Сколько стоит рассуждение на своём сервере или у вендора |
| Стабильность | Разброс результатов при повторных прогонах | Можно ли на ответ полагаться без перепроверки |
| Длина рассуждения | Объём промежуточного текста | Нет ли ухода модели в долгие бесплодные размышления |
Время ответа в режиме рассуждения плохо предсказуемо: простая задача решается быстро, а сложная способна породить очень длинную цепочку. Поэтому в приложении задайте предельное время ожидания и запасной сценарий: если рассуждение затянулось, показывайте пользователю статус или переходите к быстрому ответу с пометкой. Пользователь простит задержку, когда видит ход работы, и теряет терпение перед пустым экраном.
Если вы запускаете модель на своём оборудовании, время превращается в загрузку видеокарты и очередь запросов, а токены — в нагрузку на сервер. О выборе размера и проверке на своих задачах мы писали в статье про Qwen через Ollama, схема там похожая.
Какие ваши задачи требуют рассуждения, а какие обойдутся без него?
Проверяемый итог
Развёрнутое рассуждение создаёт ощущение надёжности, и это опасно. Длинная цепочка шагов может привести к неверному выводу, а убедительность текста о верности свидетельствует слабо. Поэтому принимают итог и оценивают его по результату проверки, а красота рассуждения в расчёт идёт в последнюю очередь.
- Расчёты: пересчитайте ключевые числа вручную или другим инструментом, без опоры на промежуточные выкладки.
- Код: запустите тесты и прочитайте изменения, как для кода от человека.
- Факты: сверьте с источником, потому что рассуждение лишь перебирает то, что модель уже знает.
- Условия и правила: проверьте, учтены ли все ограничения задачи, включая последние.
- Согласованность: задайте тот же вопрос иначе и сравните выводы; расхождение сигнализирует о слабом месте.
Отдельно отслеживайте задачи, на которых рассуждение ухудшает результат. Такое случается: модель накручивает лишние шаги и уходит от простого верного ответа к сложному неверному. Вносите такие случаи в набор и помечайте, чтобы при смене модели проверять их первыми и вовремя замечать регрессию.
Сам текст рассуждения полезен как подсказка для проверки: по нему видно, на каком шаге модель свернула. Но хранить и показывать его пользователям следует осторожно: он содержит промежуточные догадки и бывает путаным. Для внутренних процессов хранение рассуждений помогает разбирать ошибки, для клиентов обычно показывают только итог.
Когда рассуждать
Включайте рассуждение для задач с несколькими шагами и проверяемым итогом, быстрый режим оставляйте для справок, перефразирования и классификации. Решение принимайте по тестовому набору, а ощущение от одного ответа в расчёт берите в последнюю очередь.
Для регламента ведите короткую карточку модели: версия, режим, параметры генерации, результаты тестового набора и дата проверки. Когда придёт новое обновление, вы повторите прогон и увидите, что изменилось: выросла ли точность, подорожало ли рассуждение, появились ли новые типы ошибок. Без карточки разговор о качестве сводится к впечатлениям.
Режимы удобно сочетать: простые запросы идут в быстрый режим, сложные в режим рассуждения. Маршрутизацию делают либо по типу задачи, либо первой дешёвой классификацией запроса. Выигрыш виден в расходе: большая часть обращений обходится без длинных размышлений. Подобный подход к выбору режима у другой модели мы разбирали в статье про режим рассуждения DeepSeek.
После каждого обновления модели прогоняйте типовой набор и сравнивайте долю верных ответов и среднее время. Оценка, сделанная один раз, быстро устаревает: новая версия сдвигает баланс, и прежнее решение приходится пересматривать. Подобрать режимы под ваш процесс можно в формате консалтинга по внедрению ИИ.