Стоимость ИИ-агента за пределами тарифа поставщика

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

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

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

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

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

Одним предложением определите успех, другим - неудачу. Например: «Обработка счета завершена, если все обязательные поля заполнены, данные прошли проверку и ровно один раз попали в бухгалтерскую очередь». Дубликат, неполная запись, отклоненная запись и запуск, после которого данные пришлось вводить вручную, считаются неудачей. Такое определение не даст поставщику назвать успешной технически завершенную задачу, которая не принесла результата.

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

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

Рекомендации AWS Well-Architected по оптимизации затрат предлагают распределять расходы на рабочую нагрузку через показатели использования или бизнес-результаты. Я согласен с частью про результаты, но почасовое распределение само по себе не решает учет агентов. Работа агента часто переходит из одного часа в другой, повторяется асинхронно и обращается к нескольким сервисам. Нужен постоянный идентификатор работы, который сопровождает задачу по всему пути.

Поэтому разумное сравнение начинается с work_id, outcome и accepted_at, после чего к этой записи привязывают все платежи поставщику и затраты труда. Без такой связи отдел закупок сравнивает страницы тарифов, а инженеры оплачивают поведение системы, которое никто не может объяснить.

Тариф за место оплачивает доступ, а не выполненную работу

Тариф за место подходит, когда агентом часто пользуется стабильная группа, а объем работы меняется в разумных пределах. Финансовый отдел получает предсказуемую подписку, а пользователям не нужно думать о счетчике при каждом запросе. Но при неравномерном использовании число мест плохо отражает ценность.

Базовое уравнение простое:

monthly seat cost = paid seats x price per seat
cost per accepted unit = monthly seat cost / accepted units

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

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

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

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

Цена за задачу зависит от определения задачи

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

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

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

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

Используйте коэффициент оплачиваемых задач:

billable task ratio = billed tasks / accepted business units
effective task price = total task charges / accepted business units

Если коэффициент растет, сначала проверьте повторы, поведение пользователей и изменения определения задачи, а уже затем объясняйте рост объемом. При цене $0.20 за задачу и коэффициенте 1.8 стоимость принятой единицы составит $0.36 еще до проверки и интеграции. Объявленная цена остается правдивой, но предположение покупателя оказывается неверным.

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

Цена за результат передает риск только на бумаге

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

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

Модель действительно передает поставщику часть риска исполнения. Неудачные запуски, которые не стали оплачиваемым результатом, могут остаться на его стороне. Но покупатели часто забирают риск обратно через минимальные обязательства, широкие правила приемки, исключения и требования к качеству данных. Читайте коммерческие условия вместе с определениями.

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

Для цены за результат также нужен предел ценности. Платить $20 за результат, который экономит $8, бессмысленно даже при безупречной работе агента. Оцените общую выгоду от принятой единицы, вычтите труд человека и последующие расходы, затем установите максимальную плату поставщику с достаточным запасом на неопределенность. Не исходите из затрат поставщика с наценкой. Исходите из ценности, которая останется у вас.

Модель подходит узким процессам, где качество проверяется объективно, а поставщик контролирует достаточно этапов, чтобы отвечать за результат. Она хуже подходит регулируемым решениям и задачам, где требуется профессиональное суждение, потому что ответственность все равно несет человек. В таких случаях честным результатом будет «дело подготовлено к проверке», а не «дело одобрено».

Передача стоимости токенов показывает расход, но скрывает систему

Прямая оплата токенов подходит техническим командам, которые умеют управлять запросами, выбором моделей, контекстом и повторными попытками. Покупатель напрямую видит потребление модели. Но одних токенов недостаточно для прозрачного расчета полной стоимости агента.

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

Например, документация OpenAI API указывает в данных об использовании входные токены, кешированные токены, выходные токены и токены рассуждения для поддерживаемых конечных точек. Такая разбивка полезна, потому что категории могут иметь разные ставки и объяснять неожиданное поведение. Но она не показывает, приняли ли ответ, сколько было повторов и сколько времени проверяющий потратил на исправления. Приложение должно связать использование с результатом работы.

Стоимость токенов нужно рассчитывать для каждого вызова модели, а затем складывать по идентификатору работы:

call cost =
  input_tokens x input_rate
  + cached_tokens x cached_input_rate
  + output_tokens x output_rate
  + tool_charges

accepted unit cost = sum(call cost for work_id) / accepted outcome

Внимательно проверьте правила поставщика. В некоторых отчетах кешированные токены уже входят в общее число входных токенов, поэтому неверное вычитание или сложение приводит к двойному учету. Токены рассуждения могут находиться в детализации выходных токенов, а не в отдельной оплачиваемой строке. Храните исходные поля поставщика, а нормализованные значения рассчитывайте отдельно.

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

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

Полная стоимость не помещается в один счет

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

Используйте такую месячную модель:

TCO = fixed_fees
    + usage_charges
    + integration_amortization
    + review_hours x loaded_hourly_cost
    + exception_hours x loaded_hourly_cost
    + operations_hours x loaded_hourly_cost
    + expected_failure_loss

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

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

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

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

FOCUS, открытая спецификация FinOps по затратам и использованию, вводит еще одно полезное различие. List Cost отражает опубликованные единичные цены, а Effective Cost распределяет скидки и применимые предоплаченные покупки по фактическому использованию. Сравнивайте предложения агентов по эффективной стоимости. Годовое обязательство со скидкой не делает сервис дешевле в те месяцы, когда неиспользованный объем сгорает; при распределении расходов этот простой должен быть виден.

Небольшая модель полезнее красивого прогноза

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

Рассмотрим агента для извлечения данных из счетов в условном месяце. Цифры показывают методику и не претендуют на рыночный ориентир.

• Подано 10,000 счетов, доля приемки равна 85 процентам
• В тарифе за задачу на один отправленный счет приходится 1.2 оплачиваемой задачи
• При прямой оплате токенов расходуется 900,000 токенов на 100 счетов
• Проверяющие тратят 300 часов при полной стоимости часа $60
• Ежемесячная амортизация интеграции и эксплуатации составляет $4,000

Предположим, что предложение за задачу стоит $0.40 за оплачиваемую задачу, предложение за результат - $1.10 за принятый счет, а токеновый вариант в среднем обходится в $6 за миллион токенов после учета набора моделей и кеширования. Допустим также, что тариф за места стоит $500 для каждого из 15 мест. Эти придуманные предложения нужны только для демонстрации расчета.

Платежи поставщику составят $7,500 за места, $4,800 за задачи, $9,350 за результаты и $540 за токены. Если процесс работает одинаково во всех вариантах, проверка человеком добавит каждому $18,000. Интеграция и эксплуатация добавят $4,000. Итоговые месячные расходы составят $29,500, $26,800, $31,350 и $22,540 соответственно.

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

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

Фактические события можно записывать в таком виде:

{"work_id":"inv_10482","pricing_model":"per_task","attempts":2,"billed_tasks":2,"input_tokens":18420,"output_tokens":1260,"tool_cost":0.03,"review_minutes":4.5,"outcome":"accepted","vendor_charge":0.80}

Одна запись не должна заменять исходные журналы поставщика. Это нормализованная связь между техническим потреблением, данными счета, трудом и результатом. Сверьте сумму vendor_charge со счетом, затем на том же наборе данных рассчитайте стоимость принятой единицы. Так у инженеров и финансового отдела появится общий предмет спора, который можно проверить.

Гибридная цена честнее распределяет риск

Гибридная цена часто оказывается самым обоснованным выбором, потому что расходы на агента включают зарезервированную мощность и переменную работу. Базовая плата за платформу вместе с оплатой потребления покрывает фиксированную часть услуги поставщика и связывает рост расходов с использованием. Включенный в места объем с доплатой за задачи подходит команде людей, которая также обрабатывает общие очереди. Плата за результат с минимальным объемом работает, если минимум соответствует подтвержденному спросу.

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

Ограничьте риск при неопределенном использовании. Месячный минимум дает поставщику обязательство, а потолок защищает покупателя при зацикливании или скачке спроса. В договоре можно предусмотреть пересмотр при приближении к потолку вместо молчаливого продолжения работы по ставкам перерасхода. Потолок бесполезен, если необходимая работа просто останавливается, поэтому определите режим снижения нагрузки, согласование или запасной процесс.

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

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

Выбирайте гибрид, когда он соответствует реальным затратам сервиса и способу, которым процесс создает ценность. Отказывайтесь, если предложение просто собирает все возможные счетчики в одном документе.

Условия договора определяют судьбу модели

В тарифном приложении нужно определить оплачиваемое событие, источник данных, учет повторов, кредиты, перерасход и порядок изменений. Ясная таблица не защитит от расплывчатого договора.

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

Запишите, как оплачиваются следующие случаи:

• Повторы, тайм-ауты и дубликаты событий по вине поставщика
• Исправления клиента и повторно открытые результаты
• Тестовый, промежуточный и оценочный трафик
• Неудачные вызовы инструментов и частичные завершения
• Приостановка сервиса на время проверки расходов

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

Срок обязательств должен соответствовать имеющимся данным. Годовая скидка имеет смысл после пилота, который показал стабильный объем, приемку и труд проверяющих. До этого скидка остается платой за оптимизм. Предусмотрите постепенный рост или ежеквартальное изменение объема, если внедрение зависит от команд, которыми вы не управляете.

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

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

Выбирайте счетчик, которым команда умеет управлять

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

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

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

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

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

Основателям, у которых нет чистых данных о процессах или общего взгляда финансового и инженерного отделов, oleg.is предлагает Team & AI Audit: фиксированная цена $5,000, срок пять рабочих дней, выявленная экономия не менее $50,000 в год или работа бесплатна. В этом случае полезным результатом будет не общий план внедрения ИИ, а исходная модель затрат, которая показывает, какую работу стоит автоматизировать и какой ценовой риск способна принять команда.

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