# Дешёвая модель справится с 90% работы Дефолтный ход — навести самую большую и умную модель на всё подряд. В демо работает, на масштабе тихо разоряет — потому что бо́льшая часть того, что делает агент, это не рассуждение, а механика, и ты платишь зарплату гения за чтение анкеты. Починка скучная и стоит ~90%: умная модель планирует, дешёвые — делают. Вот экономика и единственное архитектурное правило, без которого это невозможно. - **Author:** Фёдор Чищин - **Published:** 2026-06-03 - **Tags:** agents, architecture, business - **Source:** https://fedorthinks.com/ru/blog/cheap-model-most-of-the-work --- Когда человек строит своего первого агента, он берёт лучшую модель на всё. Естественно — это безопасный выбор, она даёт лучшие ответы, а в демо стоимость — погрешность округления. Навёл самую умную модель на всю задачу и смотришь, как она работает. Потом это уходит в прод, объём вызовов вырастает на пару порядков, и приходит счёт. И оказывается, что «просто используй лучшую модель» — был не нейтральный дефолт. Это было решение платить высшую цену за каждый пустяковый шаг — а большинство шагов пустяковые. ## Разброс цен огромен, и никто туда не смотрит Вот число, которое должно переосмыслить всё. В 2026-м цены на LLM API [простираются примерно от **$0.10 за миллион входных токенов** у малых моделей до **$30 за миллион** у фронтир-моделей рассуждения](https://www.cloudzero.com/blog/llm-api-pricing-comparison/) — разброс примерно в **300 раз** за токены, которые на лёгкой задаче дают неотличимый результат. CloudZero сформулировал практическую версию этого прямо: использование фронтир-модели на нагрузке, которой фронтир-рассуждение не нужно, может [стоить в **16 раз дороже без сколько-нибудь заметного прироста** качества](https://www.cloudzero.com/blog/llm-api-pricing-comparison/). В шестнадцать раз дороже за тот же ответ. Ты бы нигде в своём стеке такого не потерпел, но с моделями большинство команд даже не проверяет — выбирают лучшую один раз и гонят через неё _всё_. ## Бо́льшая часть работы агента — не размышление Причина, почему это так расточительно: задача агента — не один большой акт гениальности. Вскрой настоящую — и найдёшь горстку по-настоящему трудных шагов, зарытых в кучу механических: вытащи поле из этого JSON, классифицируй это сообщение, переформатируй тот список, реши, какой инструмент вызвать, перескажи абзац, заполни шаблон. Трудная часть — понять цель и спланировать подход — может быть одним шагом из пятидесяти. Гонять модель за $30 за миллион на «вытащи ID заказа из этого текста» — это платить почасовую ставку senior-инженера за то, чтобы разложить ящик по алфавиту. Это неверно не потому, что не работает, — работает прекрасно. Это неверно потому, что ты покупаешь возможности, которыми не пользуешься, — пятьдесят раз за задачу, всегда. ## Паттерн: умная модель планирует, дешёвые — делают У починки есть имя — **plan-and-execute** (планируй и исполняй) — и она ровно такая, как звучит. Одна способная (дорогая) модель смотрит на запрос и выдаёт план: рассуждение, декомпозицию, стратегию. Затем дешёвые быстрые модели исполняют каждый шаг этого плана, потому что когда думание закончено, шаги механические, и малая модель делает их не хуже. [Разбор от LangChain](https://www.langchain.com/blog/planning-agents) и другие оценивают экономию в [**до 90%** против использования фронтир-модели на всём](https://www.philschmid.de/agentic-pattern). Это не маргинальный трюк. Это близко к тому, как [работает Klarna](https://www.mindstudio.ai/blog/ai-agent-token-cost-optimization-multi-model-routing): фронтир-модель анализирует намерение клиента и размечает шаги решения, а модели поменьше делают саму работу — тянут данные аккаунта, проводят возврат, генерируют ответ. Потрать гениальность один раз, на ту часть, которой она нужна; остальное купи оптом. И вот что удивляет людей: качество обычно не падает. На узком, чётко определённом шаге малая модель часто _лучше_ — быстрее, предсказуемее и меньше склонна «творить» на задаче, которой нужна была ровно одна скучная вещь. Подгонка модели под работу — не жертва. На тех шагах раздутая модель изначально ничего не добавляла. ## Правило, которое всё это делает возможным: никогда не хардкодь модель Есть подвох, и он архитектурный. Роутить по задачам можно, только если твой код не приварен к одной модели. Если `gpt-что-нибудь` захардкожен в середине твоей бизнес-логики, ты не подставишь дешёвую модель на механические шаги без хирургии — а значит, не подставишь и продолжишь переплачивать. Это та же дисциплина, к которой я постоянно [возвращаюсь](/blog/cheap-code-is-expensive): модель — это зависимость, а зависимости живут за границей, инъецируются, а не вшиваются. Захардкоженное имя модели в логике — запах по той же причине, что и захардкоженная цена или ключ API: это сменная деталь, прикидывающаяся фиксированным фактом. Заведи её за чистый шов — и «используй здесь модель подешевле» становится изменением конфига, а не рефакторингом. (Я поменял целиком провайдера за одним из своих продуктов, изменив одно значение, — это не везение, это просто «не хардкодить то, что и так собиралось меняться».) Как только модель — сменный параметр, роутинг выпадает естественно: лёгкий классификатор или несколько эвристик определяют сложность каждого шага и шлют его на нужный уровень. [Один только роутинг](https://www.mindstudio.ai/blog/ai-agent-token-cost-optimization-multi-model-routing) — дешёвая модель на простое большинство, фронтир-модель на трудное меньшинство — по распространённым оценкам срезает **60–80%** затрат, сохраняя качество на сложных случаях. ## Почему расточительный дефолт всё равно побеждает Если это так очевидно лучше, почему не все так делают? По той же причине, по которой [дешёвая архитектура выигрывает совещание](/blog/cheap-code-is-expensive): расточительство невидимо ровно тогда, когда ты решаешь. В демо «лучшая модель на всё» проще всего собрать и стоит копейки. Счёт, который делает это ошибкой, приходит не раньше, чем ты масштабировался, — и к этому моменту это пяти- или шестизначная строка в инвойсе, прицепленная к коду, где модель захардкожена повсюду, так что починка — теперь проект. Ленивый дефолт дёшев в выборе и дорог в проживании. Ты не сэкономил усилия — ты отложил счёт и дал ему набежать. Есть и про статус: тянуться за самой большой моделью _ощущается_ как серьёзный, безопасный выбор. Это не так. Тратить фронтир-деньги на шаг форматирования — не строгость, это просто «не посмотрел». Настоящая инженерия — знать, каким 10% твоего пайплайна нужен дорогой мозг, и иметь архитектуру, которая шлёт туда только эти 10%. Фронтир-модель — не флекс. Флекс — знать, где она тебе не нужна.