Перерасход $1,8 млн на Claude в Amazon: как предотвратить неконтролируемые расходы на ИИ

Введение

Сообщается, что внутренний проект Amazon с использованием Anthropic Claude Sonnet накопил счета на сумму 1,8 миллиона долларов, превысив запланированный бюджет на 860%, оставался незамеченным в течение пяти месяцев и в итоге так и не был запущен в продакшн.

Сама задача звучит вполне рутинно: сопоставить информацию об авторах с карточками товаров на电商平台 Amazon.

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

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

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

Что произошло внутри Amazon

По информации осведомленных источников, Amazon использовал Claude Sonnet в проекте, предназначенном для сопоставления информации об авторах с карточками товаров на своей розничной платформе.

Согласно сообщениям, данное развертывание:

• Обошлось в 1,8 миллиона долларов
• Превысило выделенный бюджет на 860%
• Потребовалось пять месяцев, чтобы его обнаружить
• Так и не было запущено в производственную среду

Старший инженер описал некоторые связанные с ИИ ошибки кодирования как «катастрофически дорогие».

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

Оба утверждения могут быть верны.

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

Конкретный дефект кодирования не раскрыт

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

Такое объяснение правдоподобно, но пока не подтверждено текущими публичными отчетами.

Financial Times описала ошибки кодирования, слабый контроль расходов и задержку обнаружения. Она не публиковала технический посмертный анализ, который показывал бы:

• Исходный код
• Точный дефект
• Был ли процесс бесконечным циклом
• Количество вызовов модели
• Количество входных или выходных токенов
• Обращались ли к модели напрямую или через Amazon Bedrock
• Версию модели
• Конфигурацию использования инструментов
• Компоненты инфраструктуры, породившие расходы

Наиболее безопасный вывод более осторожен: неудачное развертывание Claude Sonnet породило огромный счет, а системы контроля Amazon не смогли обнаружить проблему в течение пяти месяцев.

Пока Amazon не опубликует технический отчет об инциденте, любые более детальные объяснения следует помечать как предположения.

Это не единственная проблема с расходами

Перерасход средств

Утверждается, что тот же внутренний отчет обсуждал по крайней мере еще два случая.

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

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

Традиционные пакетные задания могут аварийно завершиться, исчерпать память или не пройти тесты.

А ИИ-процессы могут оставаться технически здоровыми, но уже быть экономически разрушенными.

Даже если проект перестает приносить полезные результаты, он может продолжать получать успешные ответы API, писать журналы, вызывать инструменты, повторять попытки или обрабатывать низкоценные записи.

Почему сбои затрат в ИИ проявляются иначе

Затраты традиционных приложений обычно привязаны к относительно знакомым единицам:

• Время сервера
• Емкость базы данных
• Хранилище
• Сетевая передача
• Человеко-часы

ИИ-рабочие процессы могут одновременно увеличивать несколько уровней оплаты по факту использования:

• Входные токены
• Выходные токены
• Кэшированный и некэшированный контекст
• Токены рассуждения
• Вызовы инструментов
• Веб-поиск
• Сессии выполнения кода
• Векторный поиск
• Повторные попытки агента
• Параллельные рабочие процессы
• Длинная история диалога
• Облачные вычислительные ресурсы
• Журналы и вывод в хранилище

Это создает эффект мультипликатора.

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

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

Простая модель затрат для ИИ-рабочих процессов

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

Упрощенная модель выглядит так:

Ключевой показатель — не просто стоимость за токен.

А именно:

Общая стоимость за каждый успешно завершенный бизнес-результат

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

Аналогично, более мощная модель может в итоге оказаться дешевле в целом, если она выполняет задачу за меньшее количество шагов.

Первый уровень контроля: назначение финансового ответственного за каждую ИИ-задачу

Каждый производственный ИИ-рабочий процесс должен иметь назначенного ответственного, который отвечает одновременно за техническое поведение и расходы.

Этот ответственный должен знать:

• Ожидаемый объем бизнес-операций
• Используемую модель
• Ожидаемую стоимость каждой операции
• Ежедневный и ежемесячный бюджет
• Максимальную стоимость одного запуска
• Условия остановки рабочего процесса
• Кто получает оповещения
• Процедуру утверждения более высоких лимитов

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

Бюджеты должны существовать на нескольких уровнях:

Нижние уровни обеспечивают самое быстрое и эффективное торможение.

Установка жестких лимитов внутри приложения

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

Приложение должно останавливаться или запрашивать одобрение при достижении установленных границ.

Полезные ограничения включают:

• Максимальное количество запросов на задачу
• Максимальное количество шагов агента
• Максимальное количество повторных попыток
• Максимальное количество входных токенов
• Максимальное количество выходных токенов
• Максимальная длина контекста
• Максимальное количество вызовов инструментов
• Максимальное количество параллельных рабочих потоков
• Максимальная продолжительность
• Максимальная стоимость в долларах на одно задание
• Максимальное количество обработанных записей до проверки

Эти средства контроля должны быть отключены по умолчанию.

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

Использование аварийного выключателя, не зависящего от агента

Автономные агенты не должны контролировать собственные конечные полномочия по расходам.

Независимая служба должна иметь возможность:

• Отключать ключи API
• Отклонять вызовы моделей
• Приостанавливать очереди
• Сокращать рабочие потоки до нуля
• Блокировать внешние инструменты
• Отзывать роли
• Останавливать запланированные задачи
• Требовать ручного одобрения перед возобновлением

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

Тестируйте его перед запуском в производство.

Никогда не использованное средство контроля — это всего лишь теория.

Мониторинг каждого вызова модели

Организации, использующие Amazon Bedrock, могут включить журналирование вызовов моделей для поддерживаемых вызовов bedrock-runtime.

AWS заявляет, что эти журналы могут содержать данные запросов и ответов, метаданные, идентификаторы моделей, идентификаторы запросов, информацию об идентификации и данные об использовании токенов. Места назначения журналов могут включать Amazon CloudWatch Logs и Amazon S3.

Журналирование вызовов по умолчанию отключено.

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

Как минимум, записи мониторинга затрат должны содержать:

• Метку времени
• Приложение
• Среду
• Команду или центр затрат
• Модель
• Пользователя или арендатора
• Количество входных токенов
• Количество выходных токенов
• Использование кэша
• Вызовы инструментов
• Количество повторных попыток
• Идентификатор задания
• Оценочную стоимость запроса
• Бизнес-результат
• Ошибки или причины эскалации

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

Использование AWS Budgets для отслеживания расходов на Claude в Bedrock

AWS Budgets позволяет отслеживать затраты или использование относительно заданных порогов и отправлять уведомления. Бюджетные

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

Одна важная специфическая деталь AWS легко упускается из виду.

Документация AWS по обнаружению аномалий затрат указывает, что сервис не отслеживает сторонние продукты, продаваемые через AWS Marketplace, включая сторонние языковые модели, доступные через Amazon Bedrock, такие как Anthropic Claude.

Эти расходы по-прежнему появляются в Cost Explorer и в счетах, но AWS рекомендует использовать AWS Budgets для оповещений о таких расходах.

Бюджеты могут использовать фильтры по платежным сущностям для более точного отслеживания расходов Marketplace.

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

Не рассматривайте AWS Budgets как мгновенный автоматический выключатель

В документации AWS указано, что статус бюджета обновляется несколько раз в день.

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

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

Стек контроля должен включать:

1. Счётчики запросов на уровне приложения
2. Метрики использования в режиме, близком к реальному времени
3. Жёсткие лимиты на каждое задание и каждую сессию
4. Облачные бюджетные оповещения
5. Автоматизированные бюджетные действия там, где это уместно
6. Ежедневный финансовый обзор при высокорисковых релизах

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

Использование обнаружения аномалий для затрат в пределах покрытия сервиса

AWS Cost Anomaly Detection использует модели машинного обучения для выявления аномальных моделей расходов и помогает определить возможные первопричины.

AWS указывает, что сервис оценивает обработанные данные о выставлении счетов примерно три раза в день.

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

Для систем ИИ он может выявлять аномалии в вспомогательных затратах, связанных с вычислениями, хранилищами, базами данных или сетями.

Однако командам следует помнить об упомянутом выше ограничении Marketplace и при необходимости отдельно создавать бюджеты AWS для расходов на сторонние модели.

Использование Service Quotas как границы безопасности, а не бюджета

Amazon Bedrock применяет сервисные квоты к выполнению моделей, включая ограничения на основе токенов для поддерживаемых моделей и конечных точек.

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

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

Поэтому изменение квот должно требовать:

• Обоснования бизнес-необходимости
• Обновлённого прогноза затрат
• Утверждения конкретным лицом
• Обновлённых порогов оповещения
• Плана отката
• Пересмотра после увеличения трафика

Лимиты скорости и токенов следует рассматривать как часть проектирования системного риска, а не просто как препятствие для масштабирования.

Отслеживание использования и затрат Anthropic напрямую там, где это уместно

Для приложений, напрямую вызывающих Anthropic,

консоль Anthropic предоставляет отчёты о затратах и использовании.

Ограничения API Anthropic могут включать лимиты запросов в минуту, лимиты входных токенов в минуту, лимиты выходных токенов в минуту, а также лимиты расходов, связанные с уровнем использования.

Эти ограничения могут снижать неконтролируемую пропускную способность, но их следует дополнять мерами контроля на уровне приложения.

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

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

Начинайте с небольшой репрезентативной выборки

Сообщается, что проект Amazon пытался выполнить масштабную задачу сопоставления данных.

Более безопасный паттерн развёртывания:

1. Запустите 100 репрезентативных записей.
2. Измерьте точность и стоимость.
3. Запустите 1 000 записей.
4. Проверьте ошибки и распределение токенов.
5. Протестируйте наихудшие варианты ввода.
6. Подтвердите механизмы остановки.
7. Оцените расходы на полную обработку.
8. Запросите утверждение перед обработкой полного набора данных.

Не экстраполируйте только по средним записям.

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

Используйте процентильные оценки, такие как P50, P95 и P99 стоимость каждой задачи.

Устанавливайте максимальный предел затрат на каждый успешный результат

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

Для системы сопоставления авторов полезными метриками могут быть:

• Стоимость одного успешного сопоставления автора
• Стоимость одной записи, требующей ручной проверки
• Процент записей, решённых автоматически
• Доля ошибочных сопоставлений
• Стоимость ошибочных сопоставлений
• Экономия по сравнению с ручной обработкой
• Количество вызовов модели на один принятый результат

Процесс, который стоит $0,02 за запрос, может казаться дешёвым.

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

Маршрутизация простых задач к более дешёвым методам

Не каждая запись требует передовой модели.

Экономичный конвейер может использовать:

1. Точное сопоставление
2. Соединения с базой данных
3. Правила
4. Сходство по эмбеддингам
5. Более мелкие модели
6. Более сильная модель только для неоднозначных случаев
7. Ручную проверку для решений с высоким риском

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

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

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

Предотвращение неограниченных повторных попыток

Повторные попытки — частый источник скрытых расходов.

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

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

Определите единую стратегию повторных попыток, включающую:

• Небольшое максимальное количество попыток
• Экспоненциальную задержку
• Джиттер
• Явную обработку неповторяемых ошибок
• Идемпотентность
• Очереди недоставленных сообщений
• Оповещения о повторяющихся сбоях
• Бюджет на каждую задачу, включающий все связанные затраты, в том числе

количество повторных попыток

Ошибки не должны создавать бесконечный экономический цикл.

Разделение учётных данных разработки и производства

Тестовые скрипты не должны наследовать производственные лимиты.

Используйте отдельные аккаунты или рабочие области, ключи API, роли IAM, бюджеты, квоты, журналы, источники данных и сетевые разрешения.

Среда разработки должна иметь намеренно низкие лимиты расходов.

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

Проверка ИИ-сгенерированного кода так же, как проверка производственной финансовой инфраструктуры

Инцидент касался проекта, написанного с помощью ИИ-ассистента, но ключевая проблема не в том, была ли моделью сгенерирована кодовая база.

Важен вопрос: может ли код тратить деньги.

Любой компонент, способный инициировать платные запросы к моделям, должен проходить проверку по следующим пунктам:

• Завершение циклов
• Поведение при повторных попытках
• Параллелизм
• Расширение очередей
• Максимальный контекст
• Лимиты вызовов инструментов
• Обработка тайм-аутов
• Механизмы отмены
• Атрибуция затрат
• Пути ошибок
• Логирование
• Исполнение бюджета
• Поведение при экстренной остановке

Модульные тесты должны включать сценарии экономических сбоев.

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

Функционально корректного нормального пути недостаточно.

Контрольный список производственного контроля затрат на ИИ

Владение и планирование

• Назначен технический руководитель, ответственный за расходы.

• Задокументированы ожидаемое использование и стоимость каждого успешного результата.

• [ ]

[ ] Разработка, предрелизная и производственная среды имеют отдельные бюджеты.

• Полномасштабная обработка требует явного одобрения.

Контроль приложений

• Каждая задача имеет максимальные лимиты на количество запросов, токенов, шагов, повторных попыток и время выполнения.

• Каждая сессия агента имеет бюджет в долларах США.

• Не-агентские сервисы могут остановить рабочий процесс.

• Задачи приостанавливаются, если невозможно прочитать оставшийся бюджет.

• Повторная работа предотвращается с помощью идемпотентности.

Мониторинг

• Каждый вызов модели привязан к команде, проекту, пользователю и задаче.

• Регистрируется использование входных данных, выходных данных, кэша, инструментов и повторных попыток.

• Настроены оповещения как по скорости расходов, так и по общему объему расходов.

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

• Команды знают о статьях расходов, не покрываемых обнаружением аномалий.

Качество и экономическая эффективность

• Стоимость измеряется по каждому успешному бизнес-результату.

• Там, где это уместно, используются обычный код и меньшие модели.

• Протестированы наихудшие сценарии и процентильные затраты.

• Учтены затраты на ручную проверку.

• Рабочий процесс останавливается, когда дополнительные вызовы больше не приносят пользы.

Управление

• Код, сгенерированный ИИ, проходит проверку человеком.

• Увеличение бюджета и квот требует одобрения.

• Аварийный выключатель протестирован.

• Реагирование на инциденты включает финансовые и технические заинтересованные стороны.

• Команды проверяют расходы после каждого значительного изменения модели или промпта.

Уроки из ответа Amazon

По сообщениям, инженеры Amazon создают автоматизированные меры защиты для будущих ИИ-проектов.

Это правильное направление,

но автоматизация должна существовать на нескольких уровнях.

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

Ранее компания также удалила внутреннюю таблицу лидеров, поощрявшую сотрудников максимально использовать свой инструмент разработки Kiro. По данным Financial Times, эта таблица способствовала «tokenmaxxing» — явлению, при котором сотрудники повышали свой рейтинг, увеличивая потребление токенов.

Это полезное напоминание: стимулы могут подрывать контроль затрат.

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

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

Количество токенов — это входной показатель, а не показатель производительности.

Часто задаваемые вопросы

Действительно ли Amazon потратил 1,8 миллиона долларов на Claude Sonnet?

Financial Times сообщает, что внутренний проект Amazon, использующий Claude Sonnet, накопил счета на сумму 1,8 миллиона долларов. Проект, предназначенный для сопоставления информации об авторах с объявлениями электронной коммерции, превысил бюджет на 860% и так и не был запущен.

Почему перерасход средств не был обнаружен в течение пяти месяцев?

Согласно публичным отчетам, у Amazon не хватало адекватного контроля расходов, и ошибка в коде была одним из факторов проблемы. Amazon не опубликовал технический посмертный анализ для выявления конкретных дефектов или ошибок мониторинга.

Была ли проблема вызвана бесконечными циклами ИИ?

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

Были ли у Amazon другие случаи перерасхода средств на ИИ?

Да. Согласно сообщениям, та же внутренняя презентация включала непредвиденные расходы в размере около 541 000 долларов для проекта финансового аудита и 134 000 долларов для логистического проекта.

Может ли AWS Cost Anomaly Detection отслеживать расходы на Claude в Amazon Bedrock?

В документации AWS указано, что Cost Anomaly Detection не отслеживает сторонние продукты AWS Marketplace, включая модели Anthropic Claude в Bedrock. AWS рекомендует использовать AWS Budgets для управления этими затратами и, при необходимости, фильтры по платежным сущностям.

Может ли AWS Budgets немедленно остановить неконтролируемые расходы на ИИ?

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

Эквивалентны ли ограничения скорости ограничениям расходов?

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

Какие средства контроля наиболее важны для ИИ-агентов?

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

Связанные инструменты

• AWS Budgets: отслеживает затраты и использование по сравнению с порогами и запускает уведомления или настроенные бюджетные действия.
• AWS Cost Anomaly Detection: обнаруживает аномальные модели расходов AWS в поддерживаемых категориях выставления счетов.
• AWS Cost Explorer: помогает командам анализировать исторические затраты и использование по сервисам AWS и параметрам выставления счетов.
• Журналы вызовов моделей Amazon Bedrock: регистрируют поддерживаемые вызовы моделей и связанные метаданные в CloudWatch Logs или Amazon S3.
• Сервисные квоты Amazon Bedrock: показывают ограничения моделей и конечных точек, которые могут ограничивать пропускную способность вывода.
• Anthropic Console: предоставляет ключи API, отчеты об использовании, отчеты о затратах, рабочие пространства и контроль на уровне аккаунта для прямого использования Anthropic API.

Связанные ссылки

• Financial Times: перерасход средств на ИИ в Amazon: основной репортаж о проекте на 1,8 миллиона долларов и дополнительных внутренних перерасходах.
• Документация AWS Budgets: официальное руководство по отслеживанию затрат и использования AWS относительно бюджетов.
• AWS Budget Actions: описывает действия, которые выполняются автоматически или требуют одобрения человека при превышении порогов.
• Ограничения AWS Cost Anomaly Detection: документирует мониторинг аномалий и исключение сторонних моделей из Marketplace.
• [Журналы вызовов Amazon Bedrock](https://docs.aws.amazon.

com/bedrock/latest/userguide/model-invocation-logging.html): Официальное руководство по настройке и обработке данных для журналирования вызовов Bedrock.

• Отчеты о затратах и использовании Anthropic: Описание отчетов о затратах, использовании, токенах, моделях, рабочих пространствах и ограничениях скорости в консоли Anthropic.
• Ограничения скорости API Anthropic: Описание ограничений на количество запросов, входных токенов, выходных токенов и уровней использования.

Резюме

По сообщениям, внутренний проект Amazon с использованием Claude Sonnet обошелся в 1,8 миллиона долларов, превысив бюджет на 860%, оставался незамеченным в течение пяти месяцев и так и не был запущен. По сообщениям, другие проекты с ИИ породили непредвиденные расходы на сотни тысяч долларов.

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

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

**

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