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

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

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

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

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

расходы на AI = задачи × вызовы на задачу × токены на вызов × цена токена + лицензии + платформа + зарезервированная ёмкость

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

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

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

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

• —max_cost_usd, число шагов, повторных попыток и одинаковых вызовов инструментов;
• —размер ответа инструмента, таймаут модели, общий таймаут рабочего процесса и параллелизм;
• —полномочия инструментов, допустимые среды и необходимость одобрения человеком;
• —детектор зацикливания, аварийный выключатель и безопасное завершение через резервный сценарий или человека;
• —обязательные теги команды, продукта, среды, сценария и трейса.

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

Спор «бюджетировать на человека, команду или проект» поставлен неверно. Лицензии естественно принадлежат человеку или функции, эксперименты — команде, инференс в рабочей среде — продукту либо рабочему процессу, а общие шлюзы, эвалы и безопасность — платформе. Смешивание этих расходов в одном центре ответственности скрывает и ценность, и причину роста.

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

Сначала прозрачность, затем распределение затрат

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

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

стоимость принятой задачи = (модель + инструменты + поиск + шлюз + вычисления + проверка человеком + доработка + ожидаемая цена ошибки) / принятые задачи

Сначала нужно определить слово «принятая» для каждого класса работы. Для исправления ошибки это скрытый регрессионный тест и зелёный полный набор, для проверки — полезное замечание без шума, для миграции — корректный артефакт и отсутствие регрессии, для рабочего агента — завершённый процесс с допустимыми последствиями. Только после общего порога качества можно сравнивать цену и задержку моделей.

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

Самооценка не заменяет результат

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

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

HTTP-клиент или совместимую с OpenAI конечную точку обычно заменить легче всего. Настоящая зависимость от поставщика проявляется выше: подсказки подстроены под стиль модели, инструменты ожидают конкретное поведение, восстановление опирается на знакомые ошибки, а набор проверок не замечает тихую деградацию. Ещё глубже лежат состояние диалога, данные, коммерческие обязательства и навыки команды.

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

Минимальный общий знаменатель тоже стоит денег: он запрещает использовать полезные возможности провайдера. Практичный авторский ориентир — сделать переносимыми критические 80% и изолировать ценные 20%, зависящие от поставщика, адаптерами, регрессионными проверками и планом выхода. Для критического рабочего процесса должен существовать проверенный резервный маршрут, а не теоретическая совместимость схемы запроса.050505Тот же lock-in со стороны вендора называется «moat»: полезно посмотреть, какие рвы строят AI-стартапы, чтобы понимать, за что именно вы платите переносимостью. Разбирал разбор «7 moats» от YC в канале.Книжный куб · 7 moats для AI-стартапов05Тот же lock-in со стороны вендора называется «moat»: полезно посмотреть, какие рвы строят AI-стартапы, чтобы понимать, за что именно вы платите переносимостью. Разбирал разбор «7 moats» от YC в канале.Книжный куб · 7 moats для AI-стартапов

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

Обязательства разумно строить вокруг базовой нагрузки, например P50–P60, а пики оплачивать по факту, если экономика поставщика это позволяет. Контракт без экспорта данных об использовании, версии модели, окна вывода из эксплуатации и права на выход может дать красивую скидку и одновременно сделать будущую оптимизацию дороже.

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

За интерфейсом нужны три независимых контура. Шлюз отвечает за аутентификацию, секреты, бюджеты, повторные попытки, журналирование и применение правил. Слой маршрутизации выбирает допустимый маршрут по риску, возможностям, стоимости, состоянию и задержке. Проверки отдельно оценивают качество и не позволяют этому слою самому сертифицировать собственное решение.060606Оценивать качество ревью — отдельная нетривиальная задача: в SWE-PRBench берут реальные merged PR и живые комментарии людей как ground truth вместо синтетики. Разбирал этот бенчмарк в канале.Книжный куб · SWE-PRBench про оценку ревью06Оценивать качество ревью — отдельная нетривиальная задача: в SWE-PRBench берут реальные merged PR и живые комментарии людей как ground truth вместо синтетики. Разбирал этот бенчмарк в канале.Книжный куб · SWE-PRBench про оценку ревью

Начинать с обучаемого маршрутизатора рано. Сначала нужны полная телеметрия и метки задач, затем псевдонимы и статические правила, сертифицированный резервный сценарий и канареечный выпуск, после — каскад с эскалацией при проваленных тестах, недопустимой схеме или недостаточном поиске. Обучаемый маршрутизатор появляется только после накопления реальных меток результата.

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

Локальная модель не бесплатна: счёт за API превращается в GPU или облачные обязательства, простаивающие мощности, резерв высокой доступности, хранение, инженерную поддержку инференса, SRE, безопасность и обновления. Переменная стоимость может быть ниже, но фиксированная стоимость и недозагрузка делают небольшие или непредсказуемые потоки особенно дорогими. В модели ниже Q — число принятых задач за год, F_local — полная годовая фиксированная стоимость, а c_cloud и c_local — стоимость одной принятой задачи на каждом маршруте.

Cloud(Q) = c_cloud × Q · Local(Q) = F_local + c_local × Q · Q* = F_local / (c_cloud − c_local)

До Q* облако дешевле: у него нет вашего стартового инфраструктурного слоя. После Q* локальный маршрут может выиграть, потому что F_local распределяется по большому потоку, а наклон c_local ниже. Условный пример: при фиксированной стоимости 12 млн ₽ в год, облачной цене 120 ₽ и локальной цене 40 ₽ за принятую задачу порог равен 150 тысячам задач в год.

Формула имеет смысл только после общего порога качества: оба маршрута должны давать сопоставимый принятый результат при одном пороге качества и риска. В стоимость принятой задачи входят не только инференс, но и повторные попытки, проверка, доработка, резервный сценарий и эскалации. Если после их учёта c_cloud ≤ c_local, знаменатель неположителен и экономической точки безубыточности нет. Даже при положительном знаменателе нужно проверить, что реальный стабильный поток достигает Q*, а не опираться на пиковый прогноз. Локальный маршрут особенно полезен для территориального размещения данных, изолированных контуров, стабильной массовой классификации, извлечения данных, векторных представлений, переранжирования и узких задач после дистилляции.070707Если возьмётесь за local всерьёз — есть практичный разбор, как выжать из железа больше: чем llama.cpp быстрее ollama, зачем квантование и как ведут себя Dense против MoE. Пересказывал эту статью в канале.Книжный куб · как выжать больше из локальных LLM07Если возьмётесь за local всерьёз — есть практичный разбор, как выжать из железа больше: чем llama.cpp быстрее ollama, зачем квантование и как ведут себя Dense против MoE. Пересказывал эту статью в канале.Книжный куб · как выжать больше из локальных LLM

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

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

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

Дни 0–30: инвентарь и базовая линия

Найти лицензии, ключи, шлюзы, конечные точки и владельцев. Выбрать 3–5 массовых сценариев, определить принятый результат и начать собирать объём, стоимость, долю пройденных прогонов, время проверки человеком и P50/P90/P99. Без этого переговоры и оптимизация будут опираться на счёт, а не на работу.

Дни 31–60: защитные ограничения и прозрачность затрат

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

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

Сертифицировать резервного поставщика, добавить канареечный выпуск и статические режимы, провести учения по переключению, собрать пакет для переговоров и запустить один локальный пилот с полной TCO. К концу периода у каждого решения должны быть владелец, базовая линия и критерий остановки.

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

Такая карта оценки даёт общий язык разработки, платформы, FinOps, управления риском и закупок. Она отвечает на вопрос «окупается ли работа», а не «хорошо ли работает агент»: инженерная карта оценки агентов разобрана в отдельном лонгриде. Маршрутизатор получает обратную связь по результатам, команда видит цену проверки, платформа — тяжёлые трейсы, а закупки — объём, который действительно стоит закреплять. Управленческая цель звучит не «тратить меньше токенов», а «максимизировать принятую работу при заданных качестве и риске».