← 返回首页

亚马逊180万美元Claude成本超支：如何防止AI支出失控

据报道，亚马逊内部一个使用Anthropic的Claude Sonnet的项目累计账单达180万美元，超出计划预算860%，且五个月内未被发现。

发布于 2026年8月5日•general•GEO 评分: 0

选择语言

العربيةDeutschEnglishEspañolFrançaisItaliano日本語한국어PortuguêsРусский中文
图片以深蓝色为背景，左侧有“Claude 3.7”字样，右上角有红色感叹号警告标志。中间大字显示“Amazon’s $1.8M Claude Cost Overrun”，下方小字为“How to Prevent Runaway AI Spending”。左侧有蓝色图表，显示“Monthly Spend $1,823,756 ↑32% vs Budget”。右侧有“Budget Control Active”标识。图片与文档中介绍Amazon内部使用Claude Sonnet项目花费180万美元，超出预算860%，且未被发现五个月，以及探讨如何防止AI代理支出失控的内容相关，起到视觉引导作用。

亚马逊180万美元的Claude成本超支：如何防止失控的AI支出

引言

据报道，亚马逊一个使用Anthropic Claude Sonnet的内部项目累积了180万美元的账单，超出计划预算860%，在五个月内未被发现，最终未能上线。

这项任务本身听起来很常规：将作者信息与亚马逊电商平台上的商品列表进行匹配。

此事由《金融时报》在亚马逊高级工程师在一次内部员工会议上讨论了多起与AI相关的成本超支问题后报道。它为任何从偶尔使用聊天机器人转向自动化工作流的组织提供了有用的警示，因为这些工作流每天可能产生数千或数百万次付费模型调用。

传统软件缺陷往往浪费工程时间或产生错误输出。而计量式AI工作流中的缺陷可能同时造成这两种后果，并在其保持活跃的每一分钟里持续产生token、工具、存储和计算费用。

教训不是企业应该停止使用AI，而是自主或高容量的AI流程需要与其安全和质量控制同样明确的财务控制。

亚马逊内部发生了什么

据知情人士透露，亚马逊在一个旨在将作者信息与其零售平台上的商品列表进行匹配的项目中使用了Claude Sonnet。

据报告，该部署：

  • 花费180万美元
  • 超出分配预算860%
  • 耗时五个月才被发现
  • 未能进入生产环境

高级工程师将一些与AI相关的编码错误描述为“灾难性昂贵”。

亚马逊回应称，他们正在试验、学习和改进其使用该技术的方式，包括如何管理成本效率。该公司还表示，将少数孤立的案例呈现为常规做法并不能准确反映AI在亚马逊更大规模组织中的应用情况。

这两点可能都是事实。

这些事件可能只涉及亚马逊的一小部分团队，但同时也揭示了一个其他组织应该认真对待的控制问题。

具体编码缺陷尚未披露

最初的中文报道将超支归因于一个没有调用频率限制的程序，该程序持续以循环方式发送请求。

这种解释是合理的，但尚未得到当前公开报道的证实。

《金融时报》描述了编码错误、薄弱的支出控制和检测延迟。它没有发布技术事后分析报告，显示：

  • 源代码
  • 精确的缺陷
  • 该过程是否为无限循环
  • 模型调用次数
  • 输入或输出token数量
  • 模型是直接访问还是通过Amazon Bedrock访问
  • 模型版本
  • 工具使用配置
  • 产生费用的基础设施组件

最稳妥的结论更为谨慎：一个失败的Claude Sonnet部署产生了巨额账单，而亚马逊的控制系统在五个月内未能发现该问题。

除非亚马逊发布技术事故报告，否则任何更详细的解释都应被标注为推断。

这并非唯一的成本问题

超支

据称，同一份内部报告还讨论了至少另外两个案例。

项目 报告的非预期成本
财务审计工具 约 541,000 美元
旨在提升配送速度的物流项目 约 134,000 美元

据称，物流超支花了两个多星期才被发现。

这些案例比 180 万美元的作者匹配项目规模更小，但指向了同样的模式：当没有技术故障强制流程停止时，基于使用量的 AI 系统可能会持续累积成本。

传统的批处理作业可能会崩溃、耗尽内存或未通过测试。

而 AI 流程可能在技术上保持健康，但在经济上已经崩溃。

即使项目不再产生有用结果，它仍可能继续收到成功的 API 响应、写入日志、调用工具、重试任务或处理低价值记录。

为什么 AI 成本故障表现不同

传统应用的成本通常与相对熟悉的单位挂钩：

  • 服务器时间
  • 数据库容量
  • 存储
  • 网络传输
  • 人工工时

而 AI 工作流可以同时增加多个按量计费的层级：

  • 输入令牌
  • 输出令牌
  • 缓存和未缓存上下文
  • 推理令牌
  • 工具调用
  • 网络搜索
  • 代码执行会话
  • 向量搜索
  • Agent 重试
  • 并行工作进程
  • 长时间对话历史
  • 云计算资源
  • 日志和存储输出

这产生了乘数效应。

假设一个任务发送了很长的提示词，生成大量响应，调用两个工具，出错后重试，并将完整历史传递给下一轮。如果应用处理数百万条记录，一个小小的设计失误就可能变得极其昂贵。

从运维角度看，应用可能看起来并无异常。请求仍然返回 200 OK。工作进程保持活跃。队列持续缩减。账单往往是问题最先暴露的地方。

AI 工作流的简单成本模型

在启动自动化 AI 流程之前，先估算每完成一项业务任务的成本。

简化模型如下：

成本构成 计算方式
输入成本 输入令牌数 × 模型输入价格
输出成本 输出令牌数 × 模型输出价格
工具成本 工具调用次数 × 工具价格
重试成本 失败或重复尝试次数 × 单次尝试平均成本
基础设施成本 计算、存储、数据库、网络和日志
人工审核成本 审核时间 × 含人工成本的综合费率

关键指标不仅仅是每令牌成本。

而是：

每成功完成的业务成果的总成本

更便宜的请求如果失败率更高、需要重复调用或产生更多人工审核，仍然可能导致更昂贵的工作流。

同样，一个更强的模型如果在更少的步骤内完成任务，总体成本反而可能更低。

第一道控制：为每个 AI 任务指定财务负责人

每个生产环境的 AI 工作流都应有一个具名的负责人，同时负责技术行为和支出。

该负责人应当了解：

  • 预期业务量
  • 所使用的模型
  • 每项预期成本
  • 每日和每月预算
  • 单次运行的最大成本
  • 停止运行的条件

工作流

  • 接收告警的人员
  • 审批更高限额的流程

当一名工作人员可以持续发出请求时，模糊的项目级预算是不够的。

预算应存在于多个层级：

层级 示例
组织 月度AI支出上限
团队 一个业务单位的月度配额
应用 一个产品或工作流的预算
环境 开发、预发布和生产分别设限
作业 一个批次的最高成本
用户或租户 每个客户的用量配额
智能体会话 最大令牌数、步骤数、工具数和耗时

较低层级能提供最快、最有效的刹车机制。

在应用内部设置硬性限制

云计费告警很重要，但不能替代应用层面的控制。

应用应在达到设定边界时停止运行或要求审批。

有用的限制包括：

  • 每个任务的最大请求数
  • 智能体最大步骤数
  • 最大重试次数
  • 最大输入令牌数
  • 最大输出令牌数
  • 最大上下文长度
  • 最大工具调用次数
  • 最大并行工作线程数
  • 最大耗时
  • 每个作业的最高美元成本
  • 审核前最多处理的记录数

这些控制应默认关闭。

如果成本跟踪服务不可用，或应用无法确定剩余预算，最安全的行为通常是暂停而不是无限期继续。

使用不依赖智能体的紧急停止开关

自主智能体不应控制自身的最终支出权限。

独立服务应能够：

  • 禁用API密钥
  • 拒绝模型调用
  • 暂停队列
  • 将工作线程缩减为零
  • 阻止外部工具
  • 撤销角色
  • 停止计划任务
  • 在恢复前要求人工审批

即使智能体陷入重试循环或产生误导性状态消息，紧急停止开关也应保持可用。

在生产环境前进行测试。

从未使用过的控制措施只是理论。

监控每次模型调用

使用Amazon Bedrock的组织可以为受支持的bedrock-runtime调用启用模型调用日志。

AWS表示这些日志可包含请求和响应数据、元数据、模型标识符、请求标识符、身份信息和令牌使用情况。日志目的地可包括Amazon CloudWatch Logs和Amazon S3。

调用日志默认关闭。

团队应仅启用可观测性所需的数据，并应用适当的隐私、安全、保留和脱敏控制。提示词和输出可能包含敏感的公司或客户信息。

至少，成本监控记录应包含：

  • 时间戳
  • 应用
  • 环境
  • 团队或成本中心
  • 模型
  • 用户或租户
  • 输入令牌数
  • 输出令牌数
  • 缓存使用情况
  • 工具调用
  • 重试次数
  • 作业标识符
  • 估算请求成本
  • 业务结果
  • 错误或升级原因

这样可以将账单与具体任务关联起来，而不是在月度财务审查时才发现一个庞大的总额。

使用AWS Budgets跟踪Bedrock上的Claude费用

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成本异常检测使用机器学习模型来识别异常支出模式，并帮助定位可能的根本原因。

AWS表示，该服务大约每天评估三次已处理的计费数据。

它可以有效检测AWS服务、账户、区域、使用类型和成本分配标签中的意外增长。

对于AI系统，它可能识别涉及计算、存储、数据库或网络的支撑性成本异常。

然而，团队应记住上述Marketplace限制，并在必要时为第三方模型费用单独创建AWS Budgets。

将Service Quotas作为安全边界，而非预算

Amazon Bedrock对模型推理应用服务配额，包括对支持的模型和端点的基于令牌的限制。

配额可以防止无限吞吐量，但它们并非设计为精确的财务预算。

配额仍可能允许支出远超预期项目限额。相反，为解决生产容量问题而提高配额，可能会在无意中移除一个有用的安全边界。

因此，配额变更应需要：

  • 业务合理性说明
  • 更新的成本预测
  • 具名审批
  • 更新的告警阈值
  • 回滚计划
  • 流量增加后的审查

速率和令牌限制应被视为系统风险设计的一部分，而不仅仅是扩展的障碍。

适当时直接跟踪Anthropic的使用量和成本

对于直接调用Anthropic的应用程序，Anthropic

控制台提供成本和使用情况报告。

Anthropic 的 API 限制可包括每分钟请求数、每分钟输入词元数、每分钟输出词元数，以及与使用层级相关的支出限制。

这些限制可以减少不受控的吞吐量，但仍应辅以应用层控制。

拥有多个团队的组织还可以在应用程序与模型提供商之间部署 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 角色、预算、配额、日志、数据源和网络权限。

开发环境应刻意设置较低的花费上限。

意外进入循环的原型应以小额账单失败，而不是获得企业级生产配额。

像审查生产金融基础设施一样审查 AI 生成的代码

该事件涉及一个借助 AI 辅助编写的项目，但关键问题不在于代码是否由模型生成。

重要的问题是代码是否可能花费资金。

任何能够发起付费模型请求的组件都应接受以下审查：

  • 循环终止
  • 重试行为
  • 并发性
  • 队列扩展
  • 最大上下文
  • 工具调用限制
  • 超时处理
  • 取消机制
  • 成本归属
  • 错误路径
  • 日志记录
  • 预算执行
  • 紧急停机行为

单元测试应包含经济失败场景。

示例包括模型始终不返回有效答案、重复的任务投递、付费调用后工作进程崩溃、反复出现速率限制错误、每次回合工具输出不断增长上下文，以及成本估算服务不可用。

功能正确的正常路径远远不够。

生产级 AI 成本控制检查清单

所有权与规划

  • 指定的技术负责人对支出负责。

  • 记录每次成功结果的预期用量和成本。

  • 开发、预发布和生产环境具有独立的预算。

  • 全规模处理需要明确批准。

应用控制

  • 每个任务都有最大请求数、令牌数、步骤数、重试次数和耗时上限。

  • 每个 Agent 会话都有以美元计价的预算。

  • 非 Agent 服务可以停止工作流。

  • 无法读取剩余预算时暂停任务。

  • 通过幂等性防止重复工作。

监控

  • 每次模型调用都归属于团队、项目、用户和任务。

  • 记录输入、输出、缓存、工具和重试的使用情况。

  • 对支出速率和总支出均设置告警。

  • 初始生产上线期间启用每日审查。

  • 团队了解异常检测未覆盖的费用项目。

质量与经济性

  • 按每项成功的业务成果衡量成本。

  • 在适当情况下使用常规代码和较小的模型。

  • 已测试最坏情况和高百分位成本。

  • 包含人工审查成本。

  • 当额外调用不再有价值时，工作流停止。

治理

  • AI 生成的代码接受人工审查。

  • 预算和配额提升需要批准。

  • 紧急停机开关经过测试。

  • 事件响应包含财务和技术相关方。

  • 团队在每次重大模型或提示词变更后审查支出。

亚马逊回应的启示

据报道，亚马逊工程师正在为未来的 AI 项目构建自动化防护措施。

这是正确的做法。

方向，但自动化需要存在于多个层面。

一个成熟的控制系统应当结合应用硬性上限、模型与网关限额、云预算、自动化操作、使用日志、财务仪表板、人工审批以及定期审查。

该公司此前还移除了一个鼓励员工最大化使用其 Kiro 开发工具的内部排行榜。据《金融时报》报道，该排行榜助长了“tokenmaxxing”现象，即员工通过增加令牌消耗量来提升排名。

这是一个有用的提醒：激励机制可能削弱成本控制。

如果员工因使用更多 AI 而非创造可衡量的商业价值而获得奖励，那么即使产出没有改善，使用量也会上升。

组织应当奖励所解决的问题、质量的提升、节省的时间、创造的收入、降低的风险以及单位产出成本的下降。

令牌数量是一项输入指标，而非生产力指标。

常见问题

Amazon 真的在 Claude Sonnet 上花费了 180 万美元吗？

《金融时报》报道称，Amazon 内部一个使用 Claude Sonnet 的项目累计产生了 180 万美元的账单。该项目旨在将作者信息与电商列表进行匹配，超出预算 860%，且未能上线。

成本超支为何在五个月内未被发现？

公开报道称，Amazon 缺乏足够的支出控制，且编码错误是导致该问题的因素之一。Amazon 尚未发布技术性事后分析报告，以查明具体缺陷或监控失误。

问题是由无限 AI 循环引起的吗？

这一解释出现在部分次级报道中，但尚未在主要报道中得到证实。确切请求次数、重试逻辑、令牌量及源代码缺陷仍未公开。

Amazon 还有其他 AI 成本超支案例吗？

是的。据称同一份内部演示文稿还包含约 54.1 万美元的财务审计项目意外成本，以及 13.4 万美元的物流项目成本。

AWS Cost Anomaly Detection 能否监控 Amazon Bedrock 上的 Claude 费用？

AWS 文档指出，Cost Anomaly Detection 不监控第三方 AWS Marketplace 产品，包括 Bedrock 上的 Anthropic Claude 模型。AWS 建议使用 AWS Budgets 来管理这些费用，并酌情使用账单实体筛选器。

AWS Budgets 能否立即阻止失控的 AI 支出？

单靠它本身不能。AWS 表示预算信息每天更新数次，且通知时段前后成本可能继续增加。高流量应用需要请求级硬性上限以及独立的紧急停止开关。

速率限制是否等同于支出限制？

不同。速率限制控制吞吐量，而预算控制可接受的成本。一个工作流可以在速率限制范围内运行，却仍可能在数周或数月内远超计划支出。

对 AI 代理而言，最重要的控制手段是什么？

为每个代理会话设定包含请求、令牌、工具、重试和时间的硬性预算。在代理之外强制执行该预算，并提供经过测试的方式来立即停止工作流。

相关工具

com/aws-cost-management/aws-budgets/)：可跟踪成本和用量与阈值的对比，并触发通知或配置的预算操作。

相关链接

摘要

据报告，一个使用 Claude Sonnet 的内部亚马逊项目花费了 180 万美元，超出预算 860%，在五个月内未被发现，且从未上线。据报告，其他 AI 项目产生了数十万美元的意外支出。

公开记录并未证实主事件是由无限请求循环导致的。记录所证实的是 AI 工作流的支出速度与组织检测问题的速度之间存在差距。

企业应结合单次请求跟踪、作业级预算、token 和工具限制、受控重试、模型路由、云预算、自动化操作，以及代理无法覆盖的紧急停止开关。

**

最安全的规则很简单：任何AI流程都不应在未反复证明其仍然有用、在预算内且被授权继续的情况下运行五个月。