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

В разговорах об AI-бюджете смешивают три разные цены. Первая — стоимость достижения уже известного уровня качества. Она быстро снижается: новые модели, hardware и inference-оптимизации делают вчерашний результат доступнее. Вторая — цена нового frontier-уровня, длинного контекста, высокой скорости и гарантированной ёмкости. Она остаётся премиальной. Третья — полный бюджет компании, который зависит от числа задач, глубины автоматизации и количества production-сценариев.

Рыночные сигналы показывают именно расширение спроса. Menlo Ventures оценила enterprise GenAI spend в США в 37 млрд долларов за 2025 год против 11,5 млрд годом ранее; это модель венчурной компании на опросе примерно пятисот руководителей, а не бухгалтерская перепись всего рынка. State of FinOps 2026 сообщает, что AI-расходами занимается 98% респондентов против 63% годом ранее и 31% двумя годами ранее. McKinsey одновременно фиксирует широкий adoption и заметно более узкий слой компаний, дошедших до масштабирования.010101Это не перепись рынка, а модели на опросах: McKinsey State of AI 2025, например, построен на онлайн-опросе 1993 респондентов со взвешиванием по доле стран в ВВП. Разбирал методологию отчёта в канале.Книжный куб · McKinsey State of AI 2025

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

Оптимизация по цене миллиона токенов видит только один множитель. Реальный счёт определяется числом задач, числом модельных вызовов на задачу, объёмом контекста, ценой каждого вызова, лицензиями, платформой и зарезервированной ёмкостью. Дешёвый вызов делает экономически разумными новые сценарии, а агент превращает одно пользовательское действие в разветвлённый workflow.

AI spend = tasks × calls per task × tokens per call × token price + seats + platform + fixed capacity

FinOps Foundation приводит характерный диапазон: одна агентная интеракция может породить 5, 10 или 50 вызовов модели. Каждый вызов снова передаёт часть контекста, добавляет tool results, retries и потенциальные ветки. Если смотреть только на агрегированный invoice, невозможно отличить полезный сложный trace от зациклившегося агента. Поэтому стоимость должна быть привязана к use_case,task_class и trace_id.

Отсюда важный вывод: снижение unit price не гарантирует снижение total cost. Оно лишь освобождает пространство для нового спроса. Управлять нужно не потреблением как таковым, а тем, какой результат создаёт каждый дополнительный вызов и где у workflow появляется тяжёлый хвост.020202Тот самый премиальный слой ёмкости: по данным SemiAnalysis годовой контракт на H100 подорожал примерно на 40% за полгода, и дефицит теперь гонит не обучение, а production-инференс поверх агентов. Разбирал этот H100 price index в канале.Книжный куб · дефицит GPU и H100 price index

Глобальный лимит токенов на пользователя смешивает autocomplete, архитектурный анализ и production-агента с правом менять систему. Он наказывает полезного power user, но плохо защищает от одного ошибочного workflow. Для copilot стоимость вызова часто меньше пары минут инженера; для автономного агента опасны параллельные ветки, retries, растущий контекст и повторяющиеся tool calls.

Минимальный production-контур ограничивает несколько ресурсов одновременно:

• —max_cost_usd, число шагов, retries и одинаковых tool calls;
• —размер tool output, model timeout, общий workflow timeout и concurrency;
• —полномочия инструментов, допустимые среды и необходимость human approval;
• —loop detector, kill switch и безопасное завершение через fallback или человека;
• —обязательные теги команды, продукта, среды, use case и trace.

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

Спор «бюджетировать на человека, команду или проект» поставлен неверно. Seats естественно принадлежат человеку или функции, exploration — команде, production inference — продукту либо workflow, а общие gateway, evals и security — платформе. Смешивание этих расходов в одном центре ответственности скрывает и ценность, и причину роста.

При короткой истории полезнее планировать P50 и P90, а также держать резерв на неопределённость. Диапазон 15–25% — практическая стартовая эвристика, не стандарт FinOps. Размер резерва должен уменьшаться по мере появления стабильных профилей нагрузки и качества.

Showback раньше chargeback

Ранний жёсткий chargeback заставляет команды прятать эксперименты и спорить о ложной точности распределения общей платформы. Первые один-два квартала лучше показывать стоимость и результат по продуктам и командам, затем вводить бюджеты и мягкие пороги. Chargeback становится полезен для стабильных production workloads с понятным owner и unit economics.

Токены — удобная единица биллинга, но слабая единица ценности. Сгенерированный patch ещё не является результатом: он может не пройти тесты, потребовать долгого review или создать регрессию. В знаменателе unit economics должны находиться только задачи, прошедшие общий критерий приёмки.030303«Прошёл тесты» и «принят» — не одно и то же: модель может выбить хороший pass rate и всё равно оставить код, который enterprise-команда будет долго разгребать. Разбирал доклад Sonar ровно про это в канале.Книжный куб · почему pass rate уже мало

cost per accepted task = (model + tools + retrieval + gateway + compute + human review + rework + expected failure loss) / accepted tasks

Сначала нужно определить слово «принятая» для каждого класса работы. Для bugfix это скрытый regression test и зелёный full suite, для review — полезное замечание без шума, для миграции — корректный artifact и отсутствие регрессии, для production-агента — завершённый workflow с допустимыми последствиями. Только после общего quality threshold можно сравнивать цену и latency моделей.

Кандидатов нужно прогонять на одинаковых реальных задачах несколько раз и считать весь trace: tools, retries, fallback и human time. Дешёвая модель с 70% успеха может выиграть у более дорогой с 95%, пока разница в review и rework мала. Одна дополнительная минута инженера или редкая дорогая ошибка способны полностью перевернуть сравнение.

Самооценка не заменяет outcome

RCT METR 2025 года на 16 опытных open-source разработчиках и 246 задачах показал 19% замедления с инструментами начала 2025 года, хотя участники после эксперимента считали, что ускорились примерно на 20%. Сами авторы теперь помечают этот результат как устаревший: обновление 2026 года сместило оценку в сторону ускорения, но столкнулось с сильными selection effects и изменило дизайн следующего эксперимента.

Правильный вывод — не «AI всегда замедляет» и не «новые модели всё исправили». Узкая выборка не описывает всю разработку, а инструменты быстро меняются. Она показывает, что ощущение, activity и benchmark нельзя подставлять вместо собственного baseline. DORA формулирует это устойчивее: AI усиливает сильные и слабые стороны delivery-системы.040404Про этот METR-эксперимент я звал в гости СРО платформы из Яндекса, и мы 40 минут разбирали и методологию, и выборку в 16 инженеров, и то, как громкие заголовки обогнали само исследование. Запись — в канале.Книжный куб · Research Insights #17 про METR

HTTP-клиент или OpenAI-compatible endpoint обычно заменить легче всего. Настоящая миграция ломается выше: prompts подстроены под стиль модели, tools ожидают конкретное поведение, recovery опирается на знакомые ошибки, а eval-набор не замечает тихую деградацию. Ещё глубже лежат conversation state, данные, commercial commitment и навыки команды.

Поэтому абстрагировать нужно не минимальный общий API, а бизнес-контракт задачи: вход, ожидаемый artifact, критерий приёмки и допустимые эффекты. Бизнес-код вызывает review_patch илиsummarize_incident, а конкретная модель выбирается конфигурацией. State, документы, audit trail и evals остаются под контролем компании.

Lowest common denominator тоже стоит денег: он запрещает использовать полезные возможности провайдера. Практичный авторский ориентир — сделать переносимыми критические 80% и изолировать ценные provider-specific 20% адаптерами, regression evals и exit plan. Для критического workflow должен существовать проверенный secondary route, а не теоретическая совместимость схемы запроса.050505Тот же lock-in со стороны вендора называется «moat»: полезно посмотреть, какие рвы строят AI-стартапы, чтобы понимать, за что именно вы платите переносимостью. Разбирал разбор «7 moats» от YC в канале.Книжный куб · 7 moats для AI-стартапов

Обращаться к account team нужно не только после большой суммы в invoice. Критичный процесс, чувствительные данные, требования SLA, региона или гарантированной capacity оправдывают разговор раньше. Устойчивые 10–25 тысяч долларов в месяц у одного провайдера или прогноз 100–250 тысяч в год — лишь экономический ориентир окупаемости закупок и юристов, а не официальный порог какого-либо поставщика.

Commitment разумно строить вокруг базовой нагрузки, например P50–P60, а пики оставлять PAYG, если экономика поставщика это позволяет. Контракт без экспорта usage data, версии модели, deprecation window и exit rights может дать красивую скидку и одновременно сделать будущую оптимизацию дороже.

Пользователю не нужно знать прайс-листы, availability регионов и свежий leaderboard. Ему нужно распознать намерение и цену ошибки. Практичный интерфейс состоит из режимов: Auto для большинства запросов, Быстро для простых преобразований, Глубоко для архитектуры и сложных дефектов, Чувствительные данные для разрешённого local или контрактного маршрута.

За интерфейсом нужны три независимых контура. Gateway отвечает за auth, secrets, budgets, retries, журналирование и enforcement. Router выбирает допустимый маршрут по risk, capability, cost, health и latency. Evals отдельно проверяют качество и не позволяют роутеру самому сертифицировать собственное решение.060606Оценивать качество ревью — отдельная нетривиальная задача: в SWE-PRBench берут реальные merged PR и живые комментарии людей как ground truth вместо синтетики. Разбирал этот бенчмарк в канале.Книжный куб · SWE-PRBench про оценку ревью

Стартовать с learned router рано. Сначала нужна полная telemetry и task tags, затем aliases и статические правила, сертифицированный fallback и canary, после — каскад с эскалацией по failed tests, invalid schema или недостаточному retrieval. Обучаемый router появляется только после накопления реальных outcome labels.

RouteLLM и FrugalGPT показывают потенциал каскадов, но опубликованный процент экономии нельзя переносить на другую компанию без её task distribution и evals. Роутинг — не способ найти самую дешёвую модель, а способ выбрать самый дешёвый маршрут, который всё ещё проходит приёмку.

Локальная модель не бесплатна: API invoice превращается в GPU или cloud commitment, idle capacity, HA headroom, storage, inference engineering, SRE, security и обновления. Переменная стоимость может быть ниже, но fixed cost и недозагрузка делают небольшие или непредсказуемые потоки особенно дорогими.

Q* = fully loaded local fixed cost / (cloud variable cost per accepted task − local variable cost per accepted task)

Формула имеет смысл только после общего quality gate. Если local-кандидат чаще требует review, rework или эскалацию, его переменная стоимость на принятую задачу может оказаться выше облачной. Local особенно полезен для data residency, air-gap, стабильной массовой классификации, extraction, embeddings, reranking и узких задач после distillation.070707Если возьмётесь за local всерьёз — есть практичный разбор, как выжать из железа больше: чем llama.cpp быстрее ollama, зачем квантование и как ведут себя Dense против MoE. Пересказывал эту статью в канале.Книжный куб · как выжать больше из локальных LLM

Гибрид сильнее инфраструктурной религии

В зрелой системе local — один из маршрутов. Он берёт повторяемый поток, preprocessing и задачи с жёстким data path; сложный или неуверенный хвост эскалируется во frontier API под тем же критерием приёмки. Так privacy, latency и утилизация не требуют отказываться от frontier-quality там, где она действительно окупается.

Первые три месяца не должны начинаться с большого model marketplace или закупки GPU. Цель — сделать видимыми объём, качество, стоимость и цену ошибки на нескольких массовых сценариях, затем поставить guardrails и только после этого усложнять routing и коммерческий контур.

Дни 0–30: инвентарь и baseline

Найти seats, keys, gateways, endpoints и owners. Выбрать 3–5 массовых use cases, определить accepted outcome и начать собирать volume, cost, pass rate, review time и P50/P90/P99. Без этого переговоры и оптимизация будут опираться на invoice, а не на работу.

Дни 31–60: guardrails и showback

Ввести trace budgets, loop detection, kill switches, границу sandbox и production, showback по продуктам и golden evals. Проверить caching и batch только на реальном профиле: низкий hit rate может не окупить новый слой сложности.

Дни 61–90: маршруты и устойчивость

Сертифицировать secondary provider, добавить canary и статические режимы, провести failover drill, собрать пакет для переговоров и запустить один local pilot с fully loaded TCO. К концу периода у каждого решения должен быть owner, baseline и критерий остановки.

Итоговую систему нельзя свести к одной средней цене или интегральному баллу. Для каждого task class вместе нужны acceptance, стоимость, distribution tails, human time, технические сбои и последствия ошибок. P99 важен не меньше P50: именно в хвосте живут циклы, перегрузка и редкие дорогие инциденты.

Такой scorecard даёт общий язык engineering, platform, FinOps, risk и procurement. Router получает outcome feedback, команда видит цену review, платформа — тяжёлые trace, а закупки — объём, который действительно стоит закреплять. Управленческая цель звучит не «тратить меньше токенов», а «максимизировать принятую работу при заданных качестве и риске».