Пять лет в LLM-сообществе доминировал один нарратив: больше параметров, больше данных, больше FLOP на тренировку — лучше модель. С выходом OpenAI o1 в сентябре 2024 года открылся второй фронт. Compute можно тратить не только на обучение, но и на сам момент рассуждения. И это даёт измеримый прирост качества — но только на определённых классах задач и за определённую цену.

Как работает reasoning-режим

В reasoning-режиме модель перед финальным ответом генерирует длинную внутреннюю цепочку рассуждений — иногда видимую пользователю, иногда скрытую внутри API. Эти токены расходуют вычисления и время. На задачах с чётко выраженной логической или математической структурой выигрыш значительный: та же модель, отвечающая «напрямую», проигрывает версии с extended thinking по точности на 20–40 пунктов.

Зависимость log-linear: опубликованные OpenAI и Anthropic графики показывают, что удвоение объёма thinking-токенов на задачах AIME (олимпиадная математика) даёт прирост точности на 8–15 пунктов. На GPQA Diamond — на 5–9 пунктов. На задачах общей эрудиции прирост быстро упирается в потолок — там дополнительный compute просто не нужен.

Log-linear зависимость означает: каждое следующее удвоение compute даёт всё меньше дополнительного качества. Первое удвоение с базового уровня — ощутимый скачок. Четвёртое или пятое — маргинальный прирост при кратно большей стоимости. Это задаёт практический потолок полезности reasoning-режима: есть оптимальный диапазон thinking-бюджета, после которого кривая доходности уплощается.

К маю 2026 года reasoning-режим есть у всех frontier-команд: Anthropic — extended thinking в Claude, Google — Gemini Pro Thinking, DeepSeek — R1, Alibaba — QwQ. Это уже не экспериментальная возможность, а стандартный API-параметр.

Сколько это стоит

Reasoning-режим в 5–15 раз дороже по числу токенов, чем эквивалентный direct-запрос. При биллинге по токенам это прямо пересчитывается в стоимость. Грубая разбивка по сценариям:

Простой запрос — фактоид, классификация, краткое резюме — обходится в $0,005–0,02 за запрос в direct-режиме. Reasoning здесь ничего не добавляет.

Сложная задача с цепочкой выводов — математика, генерация или ревью кода, юридический анализ — в reasoning-режиме стоит $0,15–1,5 за запрос. Прирост качества оправдывает стоимость, если цена ошибки сопоставима.

Критическая задача с дорогой ценой ошибки — медицинское заключение, финансовый анализ, аудит безопасности — $1–5 за запрос с reasoning и верификацией. Это уже другой разговор о ROI.

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

Три оси компромисса вместо двух

До reasoning-моделей продуктовый выбор был двумерным: качество против цены. Дорогая модель = выше качество. Сейчас компромисс трёхмерный: качество, цена, латентность. Reasoning-режим выигрывает в качестве, но проигрывает по обоим остальным параметрам. Типичное ожидание — 20–40 секунд на сложный запрос против 1–3 секунд для direct-режима.

Это меняет UX-стратегию. Пользователь, привыкший к мгновенным ответам, плохо переносит ожидание без объяснений. Продуктовый дизайн под reasoning-режим требует другого подхода: явный выбор «думающего режима» как опции, визуальная индикация процесса (показывать, что модель рассуждает, а не зависла), асинхронные паттерны для длинных задач — запустить и получить уведомление о готовности.

Реальные применения уже делятся на два класса. Первый — интерактивные задачи, где пользователь ждёт: переключение в reasoning-режим должно быть осознанным, а ожидание — понятным. Второй — фоновые пайплайны, где latency не критична: ночные аналитические отчёты, пакетная обработка документов, offline-верификация кода. Для второго класса reasoning-режим применяется значительно свободнее, потому что ограничение по времени снимается.

Inference-time scaling vs. pre-training scaling

Принципиальный вопрос: является ли inference-time scaling альтернативой масштабированию тренировки, или это дополняющий инструмент? По имеющимся данным — дополняющий, причём с разной применимостью к разным задачам.

Pre-training scaling улучшает базовые знания и широту охвата модели. Больше данных и параметров дают лучшие «рефлексы» — модель быстрее находит правильный ответ на знакомые задачи. Inference-time scaling улучшает глубину рассуждения на конкретной задаче за счёт дополнительных шагов. Грубая аналогия: pre-training делает человека образованнее в целом, inference-time scaling позволяет ему дольше думать над конкретной задачей.

Из этого следует, что эффект двух подходов не взаимозаменяем. Модель с меньшим числом параметров, но большим thinking-бюджетом, может превзойти крупную модель без reasoning на узком классе логических задач. Но на широкой выборке задач — разговорные, фактологические, творческие — крупная базовая модель выигрывает. Это ставит под сомнение идею «reasoning-режим сделает маленькие модели достаточно хорошими для всего».

Каскадная маршрутизация как архитектурный паттерн

Практика уже выработала устойчивый паттерн: routing на основе сложности задачи. Первый уровень — быстрая классификация запроса: простой или сложный. Простые уходят напрямую в дешёвую модель без reasoning. Сложные — либо в reasoning-режим той же модели, либо в более крупную модель.

Классификатор сложности может быть простым — rule-based по ключевым словам, длине и типу запроса. Или дообученным. Точность здесь не обязана быть высокой: избыточное переключение в reasoning-режим стоит денег, но не ломает результат. Недостаточное — снижает качество на сложных задачах. Асимметрия потерь зависит от конкретного продукта.

Ещё один практический вывод: reasoning-режим неравномерно полезен по типам задач. Измерять его эффект на репрезентативном срезе своих запросов — обязательный шаг перед включением в production. Покупать дорогой режим для задач, где он ничего не добавляет, — прямые потери.

Куда движется индустрия

Следующие 12–18 месяцев, вероятно, принесут дальнейшее расхождение по двум направлениям. Frontier-модели продолжат наращивать reasoning-способности: задачи, которые сейчас требуют нескольких минут вычислений, будут решаться за секунды по мере того, как hardware дешевеет и архитектуры оптимизируются под inference.

Параллельно лёгкие специализированные модели будут оптимизироваться под скорость и стоимость для массовых сценариев. Идея «одной модели для всего» работала до inference-time scaling. Теперь индустрия движется к стратификации: разные задачи — разные инструменты с принципиально разной стоимостью вычислений.

Для команд, которые строят продукты на LLM, это означает одно: стоимость inference становится такой же важной переменной в архитектурных решениях, как стоимость тренировки. Игнорировать её на этапе проектирования — значит обнаружить проблему в production, когда её цена кратно выше.