Дешёвая модель справится с 90% работы

Когда человек строит своего первого агента, он берёт лучшую модель на всё. Естественно — это безопасный выбор, она даёт лучшие ответы, а в демо стоимость — погрешность округления. Навёл самую умную модель на всю задачу и смотришь, как она работает.

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

Разброс цен огромен, и никто туда не смотрит

Вот число, которое должно переосмыслить всё. В 2026-м цены на LLM API простираются примерно от $0.10 за миллион входных токенов у малых моделей до $30 за миллион у фронтир-моделей рассуждения — разброс примерно в 300 раз за токены, которые на лёгкой задаче дают неотличимый результат.

CloudZero сформулировал практическую версию этого прямо: использование фронтир-модели на нагрузке, которой фронтир-рассуждение не нужно, может стоить в 16 раз дороже без сколько-нибудь заметного прироста качества. В шестнадцать раз дороже за тот же ответ. Ты бы нигде в своём стеке такого не потерпел, но с моделями большинство команд даже не проверяет — выбирают лучшую один раз и гонят через неё всё.

Бо́льшая часть работы агента — не размышление

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

Гонять модель за $30 за миллион на «вытащи ID заказа из этого текста» — это платить почасовую ставку senior-инженера за то, чтобы разложить ящик по алфавиту. Это неверно не потому, что не работает, — работает прекрасно. Это неверно потому, что ты покупаешь возможности, которыми не пользуешься, — пятьдесят раз за задачу, всегда.

Паттерн: умная модель планирует, дешёвые — делают

У починки есть имя — plan-and-execute (планируй и исполняй) — и она ровно такая, как звучит. Одна способная (дорогая) модель смотрит на запрос и выдаёт план: рассуждение, декомпозицию, стратегию. Затем дешёвые быстрые модели исполняют каждый шаг этого плана, потому что когда думание закончено, шаги механические, и малая модель делает их не хуже.

Разбор от LangChain и другие оценивают экономию в до 90% против использования фронтир-модели на всём. Это не маргинальный трюк. Это близко к тому, как работает Klarna: фронтир-модель анализирует намерение клиента и размечает шаги решения, а модели поменьше делают саму работу — тянут данные аккаунта, проводят возврат, генерируют ответ. Потрать гениальность один раз, на ту часть, которой она нужна; остальное купи оптом.

И вот что удивляет людей: качество обычно не падает. На узком, чётко определённом шаге малая модель часто лучше — быстрее, предсказуемее и меньше склонна «творить» на задаче, которой нужна была ровно одна скучная вещь. Подгонка модели под работу — не жертва. На тех шагах раздутая модель изначально ничего не добавляла.

Правило, которое всё это делает возможным: никогда не хардкодь модель

Есть подвох, и он архитектурный. Роутить по задачам можно, только если твой код не приварен к одной модели. Если gpt-что-нибудь захардкожен в середине твоей бизнес-логики, ты не подставишь дешёвую модель на механические шаги без хирургии — а значит, не подставишь и продолжишь переплачивать.

Это та же дисциплина, к которой я постоянно возвращаюсь: модель — это зависимость, а зависимости живут за границей, инъецируются, а не вшиваются. Захардкоженное имя модели в логике — запах по той же причине, что и захардкоженная цена или ключ API: это сменная деталь, прикидывающаяся фиксированным фактом. Заведи её за чистый шов — и «используй здесь модель подешевле» становится изменением конфига, а не рефакторингом. (Я поменял целиком провайдера за одним из своих продуктов, изменив одно значение, — это не везение, это просто «не хардкодить то, что и так собиралось меняться».)

Как только модель — сменный параметр, роутинг выпадает естественно: лёгкий классификатор или несколько эвристик определяют сложность каждого шага и шлют его на нужный уровень. Один только роутинг — дешёвая модель на простое большинство, фронтир-модель на трудное меньшинство — по распространённым оценкам срезает 60–80% затрат, сохраняя качество на сложных случаях.

Почему расточительный дефолт всё равно побеждает

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

Есть и про статус: тянуться за самой большой моделью ощущается как серьёзный, безопасный выбор. Это не так. Тратить фронтир-деньги на шаг форматирования — не строгость, это просто «не посмотрел». Настоящая инженерия — знать, каким 10% твоего пайплайна нужен дорогой мозг, и иметь архитектуру, которая шлёт туда только эти 10%.

Фронтир-модель — не флекс. Флекс — знать, где она тебе не нужна.