Экономика AI в разработке: от токенов к принятой работе

Выпуск начинает с авторского прогноза, а не с обещания точных тарифов. К 2029 году достижение качества моделей 2026-го может подешеветь в 3–10 раз, типовая принятая задача — в 2–5 раз, но бюджет масштабированного AI-портфеля способен вырасти в 2–5 раз. Направление поддерживают разные сигналы: enterprise-расходы и adoption быстро растут, тогда как масштабирование и доказанный вклад в финансовый результат отстают. Эти выборки несопоставимы напрямую, но вместе показывают, что AI уже превращается из эксперимента в производственный класс расходов. Прогноз специально разделяет удешевление единицы и рост общего потребления. Когда приемлемое качество становится доступно большему числу процессов, организация автоматизирует то, что раньше экономически не рассматривала, поэтому меньшая цена не обязана освобождать бюджет.

Механика роста описывается формулой: число задач × вызовы на задачу × токены на вызов × цена токена, плюс лицензии, платформа и зарезервированная capacity. Агентная задача может породить 5, 10 или 50 модельных вызовов, повторно передавать контекст, обращаться к инструментам и запускать fallback. Цена токена уменьшается только в одном множителе, а остальные растут. Поэтому рост бюджета может означать полезное расширение работы, но без телеметрии на уровне трейса его невозможно отличить от циклов, лишних повторов и скрытого rework. Счёт поставщика показывает лишь часть картины: дешёвый вызов может инициировать дорогой поиск, вычисление или проверку человеком. Нужна причинная связь от расхода до конкретной задачи, иначе оптимизация одного множителя просто перемещает стоимость в соседний слой.

Глобальный лимит на человека смешивает быстрые подсказки и длинные production-workflow. Выпуск предлагает ограничивать полный трейс: стоимость, число шагов, retries и одинаковых tool calls, объём результатов инструментов, время, concurrency и полномочия. У агента должны быть loop detector, kill switch и безопасный fallback на человека, потому что неуспешная автономная попытка не обнуляет расходы — она добавляет разбор и восстановление. Владельца назначают на естественном уровне: seat относится к человеку, exploration — к команде, инференс в проде — к use case, shared platform — к центру. Такой бюджет одновременно служит ограничителем безопасности: бесконечный цикл прекращается до того, как исчерпает деньги или повторит действие во внешней системе. Эскалация должна сохранять трейс, чтобы человек продолжил с накопленным контекстом, а не начинал расследование заново.

Зрелость FinOps начинается с visibility и showback: команда видит стоимость по продуктам, workflow и средам, строит прогноз и только затем получает мягкие пороги или chargeback. Главный знаменатель — accepted task. В числитель входят модель, tools, retrieval, gateway, compute, человеческое review, переделка и ожидаемая цена ошибки; в знаменатель — только работа, прошедшая критерий приёмки. Для bugfix это тесты и отсутствие регрессии, для review — полезное замечание без шума, для production-агента — завершённый workflow с допустимыми последствиями. Showback сначала создаёт общий язык без наказания команды за исследование. Chargeback имеет смысл позже, когда категории стабильны, владельцы согласны с атрибуцией, а случайный эксперимент нельзя перепутать с устойчивой production-нагрузкой.

Маршруты сравниваются на одинаковых реальных задачах и общем quality threshold, с несколькими прогонами, retries, fallback, human time и хвостами распределения стоимости. Только прошедшие кандидаты образуют Pareto frontier качества, цены и latency. Такой подход одновременно раскрывает настоящий vendor lock-in: он живёт не в HTTP endpoint, а в prompts, поведении tools, state, evals, коммерческих обязательствах и навыках команды. Переносимым должен быть бизнес-контракт задачи — вход, ожидаемый artifact, критерий приёмки и допустимый эффект — при осознанной изоляции provider-specific возможностей. Среднее значение здесь опасно: редкий дорогой хвост может определять capacity и пользовательский опыт сильнее типичного запуска. Поэтому сравнение хранит распределение, долю fallback и причину отказа, а не только среднюю цену успешной демонстрации.

Зрелость роутинга строится ступенями: один наблюдаемый маршрут, task tags, статические правила, проверенный fallback, каскад с эскалацией и только затем обучаемый router на реальных outcome labels. Локальная модель тоже допускается после того же quality gate. Её экономика включает GPU или cloud commitment, idle capacity, HA, storage, инженерию инференса, SRE, security и обновления; точка безубыточности существует лишь при достаточном стабильном потоке принятых задач. Enterprise-контракт оценивается вместе с capacity, retention, версионированием, экспортом usage data и exit rights, а не только по скидке. Преждевременный умный router скрывает отсутствие базовых данных: без меток задачи и принятого исхода ему нечему учиться. Сначала система должна надёжно наблюдать один путь, и лишь затем сложность маршрутизации получает экономическое основание.