Сообщается, что внутренний проект Amazon, использующий Claude Sonnet от Anthropic, накопил счета на сумму $1,8 млн, превысив запланированный...
Сообщается, что внутренний проект Amazon с использованием Anthropic Claude Sonnet накопил счета на сумму 1,8 миллиона долларов, превысив запланированный бюджет на 860%, оставался незамеченным в течение пяти месяцев и в итоге так и не был запущен в продакшн.
Сама задача звучит вполне рутинно: сопоставить информацию об авторах с карточками товаров на电商平台 Amazon.
Эта история стала известна благодаря сообщению Financial Times о том, что старший инженер Amazon обсуждал несколько связанных с ИИ случаев перерасхода средств на внутренней встрече сотрудников. Она служит полезным предупреждением для любой организации, переходящей от эпизодического использования чат-ботов к автоматизированным рабочим процессам, которые могут генерировать тысячи или миллионы платных вызовов моделей ежедневно.
Традиционные дефекты программного обеспечения часто приводят к потере инженерного времени или созданию ошибочных результатов. Дефекты в тарифицируемых ИИ-рабочих процессах могут приводить к обоим последствиям одновременно и при этом непрерывно генерировать расходы на токены, инструменты, хранилище и вычисления каждую минуту, пока процесс остается активным.
Урок здесь не в том, что компаниям следует прекратить использовать ИИ, а в том, что автономные или высоконагруженные ИИ-процессы требуют финансового контроля, столь же четкого, как и контроль качества и безопасности.
По информации осведомленных источников, Amazon использовал Claude Sonnet в проекте, предназначенном для сопоставления информации об авторах с карточками товаров на своей розничной платформе.
Согласно сообщениям, данное развертывание:
Старший инженер описал некоторые связанные с ИИ ошибки кодирования как «катастрофически дорогие».
Amazon ответил, что они экспериментируют, учатся и совершенствуют свои методы использования этой технологии, включая управление экономической эффективностью. Компания также заявила, что представление нескольких изолированных случаев как обычной практики неточно отражает применение ИИ в более крупной организации Amazon.
Оба утверждения могут быть верны.
Эти инциденты могут затрагивать лишь небольшую часть команд Amazon, но в то же время они выявляют проблему контроля, к которой другим организациям стоит отнестись серьезно.
Первоначальные китайские сообщения приписывали перерасход программе без ограничения частоты вызовов, которая непрерывно отправляла запросы в цикле.
Такое объяснение правдоподобно, но пока не подтверждено текущими публичными отчетами.
Financial Times описала ошибки кодирования, слабый контроль расходов и задержку обнаружения. Она не публиковала технический посмертный анализ, который показывал бы:
Наиболее безопасный вывод более осторожен: неудачное развертывание Claude Sonnet породило огромный счет, а системы контроля Amazon не смогли обнаружить проблему в течение пяти месяцев.
Пока Amazon не опубликует технический отчет об инциденте, любые более детальные объяснения следует помечать как предположения.
Перерасход средств
Утверждается, что тот же внутренний отчет обсуждал по крайней мере еще два случая.
| Проект | Сообщаемые непредвиденные расходы |
|---|---|
| Инструмент финансового аудита | Около 541 000 долларов |
| Логистический проект, направленный на ускорение доставки | Около 134 000 долларов |
Утверждается, что логистический перерасход был обнаружен только через две с лишним недели.
Эти случаи меньше по масштабу, чем проект сопоставления авторов на 1,8 миллиона долларов, но указывают на ту же закономерность: когда нет технического сбоя, принудительно останавливающего процесс, ИИ-системы с оплатой по использованию могут непрерывно накапливать расходы.
Традиционные пакетные задания могут аварийно завершиться, исчерпать память или не пройти тесты.
А ИИ-процессы могут оставаться технически здоровыми, но уже быть экономически разрушенными.
Даже если проект перестает приносить полезные результаты, он может продолжать получать успешные ответы API, писать журналы, вызывать инструменты, повторять попытки или обрабатывать низкоценные записи.
Затраты традиционных приложений обычно привязаны к относительно знакомым единицам:
ИИ-рабочие процессы могут одновременно увеличивать несколько уровней оплаты по факту использования:
Это создает эффект мультипликатора.
Предположим, задача отправляет очень длинный запрос, генерирует большой объем ответа, вызывает два инструмента, повторяет попытку после ошибки и передает полную историю на следующий раунд. Если приложение обрабатывает миллионы записей, небольшая ошибка проектирования может стать чрезвычайно дорогой.
С эксплуатационной точки зрения приложение может выглядеть вполне нормально. Запросы по-прежнему возвращают 200 OK. Рабочие процессы остаются активными. Очереди продолжают сокращаться. Счет часто оказывается первым местом, где проявляется проблема.
Прежде чем запускать автоматизированный ИИ-процесс, оцените стоимость выполнения одной бизнес-задачи.
Упрощенная модель выглядит так:
| Компонент затрат | Метод расчета |
|---|---|
| Стоимость ввода | Количество входных токенов × цена ввода модели |
| Стоимость вывода | Количество выходных токенов × цена вывода модели |
| Стоимость инструментов | Количество вызовов инструментов × цена инструмента |
| Стоимость повторных попыток | Количество неудачных или повторных попыток × средняя стоимость одной попытки |
| Стоимость инфраструктуры | Вычисления, хранилище, база данных, сеть и журналы |
| Стоимость ручной проверки | Время проверки × общая ставка, включая трудозатраты |
Ключевой показатель — не просто стоимость за токен.
А именно:
Общая стоимость за каждый успешно завершенный бизнес-результат
Более дешевый запрос с более высокой частотой отказов, требующий повторных вызовов или большего ручного контроля, все равно может привести к более дорогому рабочему процессу.
Аналогично, более мощная модель может в итоге оказаться дешевле в целом, если она выполняет задачу за меньшее количество шагов.
Каждый производственный ИИ-рабочий процесс должен иметь назначенного ответственного, который отвечает одновременно за техническое поведение и расходы.
Этот ответственный должен знать:
Расплывчатых бюджетов на уровне проекта недостаточно, когда один работник может непрерывно отправлять запросы.
Бюджеты должны существовать на нескольких уровнях:
| Уровень | Пример |
|---|---|
| Организация | Месячный лимит расходов на ИИ |
| Команда | Месячная квота для одного бизнес-подразделения |
| Приложение | Бюджет для одного продукта или рабочего процесса |
| Среда | Отдельные лимиты для разработки, предпродакшена и продакшена |
| Задание | Максимальная стоимость одного пакетного запуска |
| Пользователь или арендатор | Квота использования на каждого клиента |
| Сессия агента | Максимальное количество токенов, шагов, инструментов и времени |
Нижние уровни обеспечивают самое быстрое и эффективное торможение.
Облачные оповещения о расходах важны, но не заменяют контроль на уровне приложения.
Приложение должно останавливаться или запрашивать одобрение при достижении установленных границ.
Полезные ограничения включают:
Эти средства контроля должны быть отключены по умолчанию.
Если служба отслеживания затрат недоступна или приложение не может определить оставшийся бюджет, самое безопасное поведение — обычно приостановка, а не бесконечное продолжение.
Автономные агенты не должны контролировать собственные конечные полномочия по расходам.
Независимая служба должна иметь возможность:
Аварийный выключатель должен оставаться доступным, даже если агент застрял в цикле повторных попыток или генерирует вводящие в заблуждение сообщения о статусе.
Тестируйте его перед запуском в производство.
Никогда не использованное средство контроля — это всего лишь теория.
Организации, использующие Amazon Bedrock, могут включить журналирование вызовов моделей для поддерживаемых вызовов bedrock-runtime.
AWS заявляет, что эти журналы могут содержать данные запросов и ответов, метаданные, идентификаторы моделей, идентификаторы запросов, информацию об идентификации и данные об использовании токенов. Места назначения журналов могут включать Amazon CloudWatch Logs и Amazon S3.
Журналирование вызовов по умолчанию отключено.
Команда должна включать только те данные, которые необходимы для наблюдаемости, и применять соответствующие меры контроля конфиденциальности, безопасности, хранения и маскирования. Промпты и выходные данные могут содержать чувствительную корпоративную или клиентскую информацию.
Как минимум, записи мониторинга затрат должны содержать:
Это позволяет связать счета с конкретными задачами, а не обнаруживать огромные итоговые суммы только при ежемесячном финансовом обзоре.
AWS Budgets позволяет отслеживать затраты или использование относительно заданных порогов и отправлять уведомления. Бюджетные
действия также могут применяться при превышении порогов для реализации мер контроля, таких как политики IAM или сервисные контрольные политики. В зависимости от конфигурации действия могут выполняться автоматически или ожидать утверждения человеком.
Одна важная специфическая деталь AWS легко упускается из виду.
Документация AWS по обнаружению аномалий затрат указывает, что сервис не отслеживает сторонние продукты, продаваемые через AWS Marketplace, включая сторонние языковые модели, доступные через Amazon Bedrock, такие как Anthropic Claude.
Эти расходы по-прежнему появляются в Cost Explorer и в счетах, но AWS рекомендует использовать AWS Budgets для оповещений о таких расходах.
Бюджеты могут использовать фильтры по платежным сущностям для более точного отслеживания расходов Marketplace.
Именно такая деталь конфигурации может создать ложное чувство безопасности. Компания может включить обнаружение аномалий и полагать, что все расходы на модели покрыты, но конкретная категория платежей не учитывается.
В документации AWS указано, что статус бюджета обновляется несколько раз в день.
Документация также предупреждает, что затраты могут продолжать расти до или после доставки уведомления.
Это означает, что AWS Budgets полезен для финансового управления, но сам по себе он может оказаться недостаточно быстрым для остановки высокопроизводительного агента.
Стек контроля должен включать:
Чем быстрее рабочий процесс тратит деньги, тем ближе к точке вызова должны находиться механизмы контроля.
AWS Cost Anomaly Detection использует модели машинного обучения для выявления аномальных моделей расходов и помогает определить возможные первопричины.
AWS указывает, что сервис оценивает обработанные данные о выставлении счетов примерно три раза в день.
Он может эффективно выявлять неожиданный рост в сервисах AWS, аккаунтах, регионах, типах использования и тегах распределения затрат.
Для систем ИИ он может выявлять аномалии в вспомогательных затратах, связанных с вычислениями, хранилищами, базами данных или сетями.
Однако командам следует помнить об упомянутом выше ограничении Marketplace и при необходимости отдельно создавать бюджеты AWS для расходов на сторонние модели.
Amazon Bedrock применяет сервисные квоты к выполнению моделей, включая ограничения на основе токенов для поддерживаемых моделей и конечных точек.
Опишите идею одной фразой, и We0 AI создаст сайт-витрину, страницы и CMS, а после запуска поможет привлечь клиентов и трафик.
Одна полная генерация проекта для бесплатной регистрации
Лучше всего попробовать один полный поток генерации и быстро увидеть первый черновик проекта.
Квоты предотвращают бесконечную пропускную способность, но они не предназначены для точного финансового бюджетирования.
Квоты всё ещё могут допускать расходы, значительно превышающие запланированные лимиты проекта. И наоборот, повышение квот для решения проблем производственной мощности может непреднамеренно удалить полезную границу безопасности.
Поэтому изменение квот должно требовать:
Лимиты скорости и токенов следует рассматривать как часть проектирования системного риска, а не просто как препятствие для масштабирования.
Для приложений, напрямую вызывающих Anthropic,
консоль Anthropic предоставляет отчёты о затратах и использовании.
Ограничения API Anthropic могут включать лимиты запросов в минуту, лимиты входных токенов в минуту, лимиты выходных токенов в минуту, а также лимиты расходов, связанные с уровнем использования.
Эти ограничения могут снижать неконтролируемую пропускную способность, но их следует дополнять мерами контроля на уровне приложения.
Организации с несколькими командами могут также развернуть LLM-шлюз между приложениями и поставщиком моделей. Шлюз может централизовать аутентификацию, отслеживание использования, бюджеты, ограничения скорости, маршрутизацию моделей и журналы аудита.
Шлюз становится критическим компонентом безопасности, и поэтому он должен эксплуатироваться и проверяться с той же тщательностью, что и любой другой производственный уровень доступа.
Сообщается, что проект Amazon пытался выполнить масштабную задачу сопоставления данных.
Более безопасный паттерн развёртывания:
Не экстраполируйте только по средним записям.
Самые длинные документы, записи с ошибками сопоставления, неоднозначные случаи, повторные попытки и циклы агентов часто доминируют в общей стоимости.
Используйте процентильные оценки, такие как P50, P95 и P99 стоимость каждой задачи.
Рабочий процесс должен останавливаться, когда дополнительные вызовы модели перестают быть экономически оправданными.
Для системы сопоставления авторов полезными метриками могут быть:
Процесс, который стоит $0,02 за запрос, может казаться дешёвым.
Если для него требуется 50 вызовов, половина записей завершается неудачей, а остальные передаются на ручную проверку, реальная экономика может быть плохой.
Не каждая запись требует передовой модели.
Экономичный конвейер может использовать:
Для проектов сопоставления данных традиционное программное обеспечение может решить большинство случаев с меньшими затратами и большей детерминированностью.
LLM следует использовать только тогда, когда языковая неоднозначность действительно требует этого, а не автоматически применять к каждой строке.
Собственные рекомендации Anthropic по ценообразованию предлагают выбирать подходящую модель, использовать кэширование промптов для повторяющегося контекста, применять пакетную обработку для несрочных задач и отслеживать модели использования.
Повторные попытки — частый источник скрытых расходов.
Один неудачный запрос может быть повторён приложением, системой очередей, SDK, шлюзом, менеджером рабочих процессов, агентом или оркестратором рабочих процессов.
Когда несколько уровней выполняют повторные попытки независимо, одна логическая задача может создать несколько платных запросов.
Определите единую стратегию повторных попыток, включающую:
количество повторных попыток
Ошибки не должны создавать бесконечный экономический цикл.
Тестовые скрипты не должны наследовать производственные лимиты.
Используйте отдельные аккаунты или рабочие области, ключи API, роли IAM, бюджеты, квоты, журналы, источники данных и сетевые разрешения.
Среда разработки должна иметь намеренно низкие лимиты расходов.
Прототип, случайно попавший в цикл, должен завершиться небольшим счётом, а не получить корпоративные производственные квоты.
Инцидент касался проекта, написанного с помощью ИИ-ассистента, но ключевая проблема не в том, была ли моделью сгенерирована кодовая база.
Важен вопрос: может ли код тратить деньги.
Любой компонент, способный инициировать платные запросы к моделям, должен проходить проверку по следующим пунктам:
Модульные тесты должны включать сценарии экономических сбоев.
Примеры: модель всегда возвращает недействительный ответ, повторная доставка задач, сбой рабочего процесса после платного вызова, повторяющиеся ошибки ограничения скорости, выходные данные инструментов с растущим контекстом с каждым раундом, а также недоступность сервиса оценки затрат.
Функционально корректного нормального пути недостаточно.
Назначен технический руководитель, ответственный за расходы.
Задокументированы ожидаемое использование и стоимость каждого успешного результата.
[ ]
[ ] Разработка, предрелизная и производственная среды имеют отдельные бюджеты.
Каждая задача имеет максимальные лимиты на количество запросов, токенов, шагов, повторных попыток и время выполнения.
Каждая сессия агента имеет бюджет в долларах США.
Не-агентские сервисы могут остановить рабочий процесс.
Задачи приостанавливаются, если невозможно прочитать оставшийся бюджет.
Повторная работа предотвращается с помощью идемпотентности.
Каждый вызов модели привязан к команде, проекту, пользователю и задаче.
Регистрируется использование входных данных, выходных данных, кэша, инструментов и повторных попыток.
Настроены оповещения как по скорости расходов, так и по общему объему расходов.
В течение первоначального производственного запуска включен ежедневный обзор.
Команды знают о статьях расходов, не покрываемых обнаружением аномалий.
Стоимость измеряется по каждому успешному бизнес-результату.
Там, где это уместно, используются обычный код и меньшие модели.
Протестированы наихудшие сценарии и процентильные затраты.
Учтены затраты на ручную проверку.
Рабочий процесс останавливается, когда дополнительные вызовы больше не приносят пользы.
Код, сгенерированный ИИ, проходит проверку человеком.
Увеличение бюджета и квот требует одобрения.
Аварийный выключатель протестирован.
Реагирование на инциденты включает финансовые и технические заинтересованные стороны.
Команды проверяют расходы после каждого значительного изменения модели или промпта.
По сообщениям, инженеры Amazon создают автоматизированные меры защиты для будущих ИИ-проектов.
Это правильное направление,
но автоматизация должна существовать на нескольких уровнях.
Зрелая система контроля должна сочетать жесткие лимиты приложений, лимиты моделей и шлюзов, облачные бюджеты, автоматизированные операции, журналы использования, финансовые панели, человеческие утверждения и регулярные проверки.
Ранее компания также удалила внутреннюю таблицу лидеров, поощрявшую сотрудников максимально использовать свой инструмент разработки Kiro. По данным Financial Times, эта таблица способствовала «tokenmaxxing» — явлению, при котором сотрудники повышали свой рейтинг, увеличивая потребление токенов.
Это полезное напоминание: стимулы могут подрывать контроль затрат.
Если сотрудников вознаграждают за большее использование ИИ, а не за создание измеримой деловой ценности, использование будет расти, даже если результаты не улучшатся.
Организации должны вознаграждать за решенные проблемы, повышение качества, сэкономленное время, созданный доход, сниженные риски и снижение затрат на единицу результата.
Количество токенов — это входной показатель, а не показатель производительности.
Financial Times сообщает, что внутренний проект Amazon, использующий Claude Sonnet, накопил счета на сумму 1,8 миллиона долларов. Проект, предназначенный для сопоставления информации об авторах с объявлениями электронной коммерции, превысил бюджет на 860% и так и не был запущен.
Согласно публичным отчетам, у Amazon не хватало адекватного контроля расходов, и ошибка в коде была одним из факторов проблемы. Amazon не опубликовал технический посмертный анализ для выявления конкретных дефектов или ошибок мониторинга.
Это объяснение появилось в некоторых вторичных отчетах, но не было подтверждено в основных репортажах. Точное количество запросов, логика повторных попыток, объем токенов и дефекты исходного кода остаются нераскрытыми.
Да. Согласно сообщениям, та же внутренняя презентация включала непредвиденные расходы в размере около 541 000 долларов для проекта финансового аудита и 134 000 долларов для логистического проекта.
В документации AWS указано, что Cost Anomaly Detection не отслеживает сторонние продукты AWS Marketplace, включая модели Anthropic Claude в Bedrock. AWS рекомендует использовать AWS Budgets для управления этими затратами и, при необходимости, фильтры по платежным сущностям.
Сам по себе нет. AWS заявляет, что бюджетная информация обновляется несколько раз в день, и затраты могут продолжать расти до и после периода уведомления. Высоконагруженным приложениям требуются жесткие лимиты на уровне запросов и независимый аварийный выключатель.
Нет. Ограничения скорости контролируют пропускную способность, а бюджетные контроли определяют приемлемые затраты. Рабочий процесс может работать в пределах ограничений скорости, но при этом значительно превышать запланированные расходы в течение недель или месяцев.
Устанавливайте жесткий бюджет для каждой сессии агента, включающий запросы, токены, инструменты, повторные попытки и время. Обеспечивайте соблюдение этого бюджета вне агента и имейте проверенный способ немедленно остановить рабочий процесс.
com/bedrock/latest/userguide/model-invocation-logging.html): Официальное руководство по настройке и обработке данных для журналирования вызовов Bedrock.
По сообщениям, внутренний проект Amazon с использованием Claude Sonnet обошелся в 1,8 миллиона долларов, превысив бюджет на 860%, оставался незамеченным в течение пяти месяцев и так и не был запущен. По сообщениям, другие проекты с ИИ породили непредвиденные расходы на сотни тысяч долларов.
Публичные записи не подтверждают, что основной инцидент был вызван бесконечным циклом запросов. Записи подтверждают разрыв между скоростью расходов в рабочих процессах ИИ и скоростью обнаружения проблем организации.
Предприятиям следует сочетать отслеживание отдельных запросов, бюджеты на уровне заданий, ограничения токенов и инструментов, контролируемые повторные попытки, маршрутизацию моделей, облачные бюджеты, автоматизированные действия, а также аварийные выключатели, которые агенты не могут отключить.
**
Самое безопасное правило простое: ни один процесс ИИ не должен работать пять месяцев без многократного доказательства того, что он по-прежнему полезен, укладывается в бюджет и уполномочен продолжать работу.
Начните с одной фразы и получите полноценный сайт за считанные минуты.
