Скрытый счет находится где-то между промптом и результатом. Вопрос для предприятия заключается в том, кто несет ответственность за расходы на выполнение работы.
Разработчик просит ИИ-ассистента по написанию кода исправить ошибку. Запрос звучит просто: найти проблему, написать патч, запустить тест. Однако за кулисами эта единственная задача может превратиться во множество. Ассистент сканирует репозиторий, проверяет документацию, пишет код и запускает тест; когда тест не проходит, он извлекает больше контекста и пробует снова. Для разработчика это все еще одна задача. Для инфраструктуры, стоящей за этим, — это растущая гора оплачиваемых операций.
Вот почему более дешевая модель не обязательно делает работу дешевле. Меньшая, специализированная модель может отлично справляться с рутинными задачами, но экономия исчезает, если ей требуются дополнительные исправления. Ограничение по токенам создает аналогичный риск, если оно останавливает ассистента прямо перед тем, как он найдет подходящее решение. В любом случае счет за ИИ может уменьшиться, даже если предприятие тратит больше времени и денег на выполнение работы.
Организации фокусируются на токенах, потому что их легко посчитать. Однако подсчет токенов похож на управление фабрикой путем отслеживания потребления электроэнергии: счетчик необходим, но он не может сказать вам, произвела ли фабрика что-то, что стоит покупать. Вывод (inference), работа, которую выполняет модель при использовании, превращает каждый запрос в повторяющиеся расходы. Снижение цен помогает, а рост использования может быть хорошей новостью, когда он приносит ценные результаты. Проблема начинается тогда, когда потребление растет быстрее, чем кто-либо успевает определить, чего стоит эта работа.
Выбор стоящих пилотных проектов и их тщательное финансирование — это дисциплинированные инвестиции. Ограничение этих систем после того, как они начинают приносить пользу, — это другое решение, поскольку ограничение расходов может сократить производственные мощности вместе с потерями. Для ИТ-директоров, финансовых директоров и бизнес-лидеров экономика сводится к трем вопросам: Что движет расходами? Сколько на самом деле стоит полезная работа? И у кого есть полномочия и доказательства для улучшения этой экономики?
Вернемся к ассистенту по написанию кода. В течение нескольких минут он может отправить один и тот же контекст репозитория через несколько запросов, многократно обрабатывая информацию, которая почти не изменилась. Кэширование промптов (prompt caching) позволяет избежать части этого повторения за счет повторного использования вычислений, когда начало промпта остается неизменным.
Подвох в том, что окно повторного использования может быть коротким. Кэш промптов по умолчанию у Anthropic длится пять минут и обновляется при использовании, с платной опцией на один час. Повторное использование в течение нескольких дней требует более надежного подхода, такого как поддерживаемый индекс поиска или сохраненные сводки. Другими словами, кэширование может устранить повторение, но оно не устраняет архитектуру, необходимую для его поддержки.
Важно то, кто контролирует эту архитектуру. При использовании API поставщика поставщик владеет кэшем и машинами, обслуживающими его, а предприятие получает скидку, когда его промпты соответствуют требованиям. Когда предприятие само выполняет вывод, оно также может направлять запросы на машины, в которых уже есть соответствующий кэш, освобождая мощности для новой работы. Модель не стала дешевле; окружающая система стала эффективнее.
Существуют пределы такого повторного использования. Кэширование промптов повторно использует вычисления, а не предыдущий ответ, и измененное содержимое промпта нарушает соответствие с этого момента. Если в промпт попадают устаревшие материалы, система поиска требует внимания; повторное использование предыдущих ответов через семантическое кэширование создает другую проблему актуальности. В любом случае текущая информация и разрешения по-прежнему имеют значение.
Тот же принцип применим к выбору модели. Узкоспециализированное исправление может подойти для небольшой специализированной модели, в то время как ошибка, затрагивающая несколько сервисов, может потребовать чего-то более мощного. Выбор модели и усилия по рассуждению — это отдельные решения, и большие усилия не могут надежно обеспечить возможности, которых у модели нет. Извлечение только релевантного кода уменьшает ненужный контекст; ночные задания, такие как сортировка бэклога ошибок или создание тестов, могут претендовать на пакетную обработку со скидкой. Инженерная работа определяет, сколько повторений, простаивающих мощностей и переделок заложено в рабочий процесс.
Эффективность на уровне системы все еще не говорит вам, сколько стоит успешная работа. В этом рабочем процессе создание патча — это лишь промежуточный этап. Команде нужно согласованное определение принятого исправления, включая соответствующие тесты и проверку разработчиком, прежде чем она сможет судить о том, что на самом деле предоставил ассистент.
Чтобы проиллюстрировать учет, предположим, что 100 задач по исправлению ошибок потребляют 30 долларов США в токенах по всем вызовам и повторным попыткам, включая ответы инструментов, возвращаемые в модель, но только 60 из них приводят к принятым исправлениям. Это 30 центов за отправленную задачу и 50 центов за принятое исправление. Эти гипотетические цифры не являются эталонными. Первая скрывает неудачные задачи; вторая исключает расходы на шлюз, наблюдаемость и проверку разработчиком. Оставшиеся 40 ошибок все еще требуют решения.
Чтобы судить о том, экономит ли ИИ деньги, команде необходимо сравнить полную стоимость выполнения этих 100 задач с тем, что она потратила бы на их решение с помощью существующего процесса. Предположим, что этот процесс стоит, для примера, 100 долларов США за принятое исправление для сопоставимой работы: 10 000 долларов США для решения всех 100 ошибок. Процесс с поддержкой ИИ должен включать проверку, исправления, накладные расходы и решение оставшихся ошибок при сравнении с этим базовым уровнем. При том же качестве он должен явно превосходить существующие затраты. Более высокая стоимость требует доказанных преимуществ, таких как более быстрая доставка, снижение рисков или мощности, которые команда не могла бы обеспечить иным способом.
Стоимость полезного результата обеспечивает объектив для такого сравнения, а не универсальный KPI. Даже при наличии определения принятых исправлений учет требует работы. Трассировка может записывать промпты, вызовы инструментов и выходные данные, но она не может автоматически распределить долю этого рабочего процесса кодирования в ежемесячном счете за ИИ-шлюз, обслуживающий несколько вариантов использования. Общие расходы требуют явного метода распределения и соглашения о его пределах. Ложная точность все еще остается ложной.
Более низкий счет за токены сам по себе не доказывает ни экономии, ни окупаемости.
Получение скидки от поставщика отличается от контроля экономики. Тариф определяет, сколько предприятие платит сегодня; его способность адаптироваться определяет его варианты, когда эти условия меняются. Страница цен на API для разработчиков Gemini от Google предлагает конкретный пример: для Gemini 3.8 Flash стандартная цена на ввод вырастет с 0,75 до 1,50 доллара США за миллион токенов 1 января 2027 года, а цена на вывод вырастет с 3,75 до 7,50 доллара США. Указанные тарифы на пакетную обработку и кэширование контекста также удваиваются, включая кэшированное хранилище с 0,50 до 1 доллара США за миллион токенов в час. У более низких тарифов есть дата окончания, поэтому бюджет, построенный вокруг них, тоже должен ее иметь.
Для команды, отвечающей за работу ассистента по написанию кода, изменение цен ставит практический вопрос: насколько сложно будет перейти на другую модель, способную выполнять ту же работу? Если ассистент создан собственными силами, инструменты могут быть написаны под интерфейс одного провайдера, а промпты настроены под поведение конкретной модели. Если это приобретенный продукт, выбор модели может во многом зависеть от поставщика. Выгодный тариф все равно может создать дорогостоящую зависимость, поэтому отдел закупок договаривается о текущей цене, в то время как архитекторы определяют варианты на будущее.
Модульная архитектура позволяет сохранить интеграции, права доступа и средства контроля при смене модели. Даже в этом случае может потребоваться перенастройка промптов, замена специфических функций провайдера, а команде придется повторно провести оценку и регрессионное тестирование на репрезентативных исправлениях ошибок. Портативность сокращает объем переделок, но не избавляет от необходимости доказывать, что замена работает корректно.
Сам репозиторий может сузить круг доступных вариантов. Проприетарный код и конфиденциальные данные конфигурации не могут покидать утвержденную среду, если этого требуют правила безопасности, договорные обязательства, требования к месту хранения или суверенитету данных. Более дешевая модель не отменяет эти ограничения. В рамках этих границ экономику определяют расходы на передачу данных, задержки и создание дополнительных копий. Когда того требуют ограничения, интеллект должен приходить к данным через подходящий управляемый сервис, инфраструктуру под управлением предприятия или их комбинацию.
Ни один из подходов не является универсально лучшим. Самостоятельное размещение (self-hosting) влечет за собой ответственность за оценку, безопасность и обслуживание, а недогруженные графические процессоры могут быстро стать дорогостоящими. Сохранение портативности также стоит денег. Контроль ценен не потому, что он диктует одну модель развертывания, а потому, что позволяет предприятию сделать более выгодный выбор, включая использование управляемого сервиса, если это экономически оправдано.
Кажущаяся простота ассистента по написанию кода скрывает множество решений в рамках рабочего процесса: какая модель получает отчет об ошибке, к каким файлам репозитория она имеет доступ, где выполняется логический вывод (inference) и какие инструменты и защитные барьеры применяются.
Сложность заключается в том, что эти решения редко принимаются в одном месте. Шлюз может отвечать за маршрутизацию, оркестратор — за управление инструментами, система поиска — за предоставление контекста, отдел безопасности — за установку барьеров, а инфраструктурные команды — за выбор места размещения. Поставщики могут контролировать части каждого из этих элементов. Вместе они создают расходы, которые невозможно полностью объяснить через какой-то один компонент.
Поэтому операционная модель ИИ должна связывать эти зоны ответственности: кто определяет успех, кто может изменять рабочий процесс и кто оценивает совокупный результат. Это требует прав на принятие решений и доказательств эффективности в существующих системах; покупка еще одного инструмента оркестрации не решает вопрос владения. Как и одна лишь прозрачность. Видимость политики маршрутизации не означает, что вы можете ее изменить, а наличие полномочий для изменения не означает, что это изменение стоит делать.
Практическим первым шагом будет изучение репрезентативного набора успешных и неудачных задач по исправлению ошибок. Определите повторяющийся контекст, количество повторных попыток и вмешательств разработчиков, а затем объедините эти данные с затратами на инфраструктуру и поддержку, чтобы установить базовый уровень. Протестируйте одно изменение, например, маршрутизацию узкоспециализированных исправлений на меньшую модель, и сравните количество принятых исправлений и общие расходы при том же пороге качества.
Предположим, счет за токены снизился, но разработчики тратят больше времени на проверку патчей. Из 60 принятых исправлений в нашем примере, всего 10 дополнительных минут проверки на каждое исправление добавят 10 часов работы разработчиков. Команда платформы фиксирует экономию, в то время как инженерный менеджер берет на себя дополнительную нагрузку. Владелец процесса, отвечающий за результат и бюджет, должен иметь возможность объединить эти выводы. ИТ-отдел предоставляет рычаги реализации и технические доказательства, финансовый отдел учитывает перекрестные расходы, а служба безопасности проверяет, соблюдаются ли необходимые контроли. Принятые исправления, общие расходы и качество определяют, стоит ли сохранять или отменять изменения.
В большинстве предприятий у каждого отдельного вопроса по затратам на ИИ уже есть владелец: токены, счета за облачные услуги, контракты, результаты использования. Чего часто не хватает, так это владельца общей стоимости выполнения работы. Пока кто-то не будет отвечать за этот полный результат, расходы на ИИ могут продолжать расти, в то время как каждая команда будет отчитываться о том, что ее часть находится под контролем.
[1] Anthropic, Кэширование промптов. Время жизни кэша и повторное использование. Проверено 19 октября 2026 г. https://platform.claude.com/docs/en/build-with-claude/prompt-caching
[2] Google, Тарифы Gemini Developer API. Таблицы Gemini 3.8 Flash Standard и Batch, включая кэширование контекста и хранение. Проверено 20 октября 2026 г. Тарифы указаны в долларах США. https://ai.google.dev/gemini-api/docs/pricing
Справочные материалы: Арвинд Кришна, «Изменение кривой затрат на ИИ», предоставленный внутренний черновик; IBM Consulting, «Руководство по токеномике для предприятия», конфиденциальная презентация для клиентов. Рабочий процесс написания кода и все показатели рабочего процесса являются иллюстративными, а не отчетом о клиентском кейсе или эталонным тестом производительности.
