2026年4月17日，AWS在其机器学习官方博客上发布了一个看起来不起眼的公告：Amazon Bedrock推理成本现在可以自动归因到具体的IAM主体。技术上说，就是每次AI调用的费用现在会标注是哪个用户、哪个应用程序、哪个团队发起的，直接出现在AWS Billing和Cost Explorer里。不需要额外配置，不需要修改代码，不收额外费用。

看起来只是一个小小的计费功能更新。

但如果你还记得2014年AWS推出Cost Allocation Tags和Cost Explorer时发生了什么，你会意识到这个「小功能」的重要性被严重低估了。

2014年，一位负责AWS账单的财务分析师提出了一个简单的问题：「我们每月在AWS上花$30万，但我不知道这30万谁花的、为什么花、花得值不值。」这个问题，在当时没有答案。三年后，CloudHealth用$5亿美元的估值被VMware收购，专门回答这一类问题。又六年后，Apptio用$19.4亿美元被IBM收购，把云成本管理变成了一个近$200亿美元的市场。

现在，完全相同的问题正在AI领域发生：「我们每月在LLM上花了$XX，但我不知道谁花的、为什么花、花得值不值。」Amazon Bedrock成本归因功能的发布，是回答这个问题的第一块砖。而历史告诉我们，这块砖意味着什么。

第一章：AI账单黑箱的形成机制

要理解这个功能的真正价值，需要先理解「AI账单无法追踪」这个问题是怎么形成的，以及它今天在企业里造成了什么实际困境。

在传统云计算场景里，每个EC2实例、S3存储桶都可以打标签（tag），通过标签追踪到具体的业务线、项目或团队。这个标签机制是云成本治理的基础。但AI API调用的成本追踪，从一开始就没有被好好设计。

典型的企业AI架构是这样运作的：工程团队A搭建了一个内部聊天助手，工程团队B开发了一个自动化代码审查工具，产品团队C在用AI生成客户邮件摘要，数据团队D在用AI分析用户反馈。这四个用例共用同一个AWS账号下的Amazon Bedrock访问权限，通过各自的应用程序后端发起API调用。

从Bedrock计费系统的视角，这些调用全部来自同一个IAM服务角色（service role），因为应用程序后端使用的是公司统一的IAM角色。CFO每月收到的账单只有一行：「Amazon Bedrock推理：$84,000」。

哪个团队花了多少？哪个功能最贵？哪个用例的成本效益最高？没有答案。

这个问题的严重程度随着AI使用规模的增长在加速。2024年，很多企业的AI成本还在$5,000到$50,000/月的「可以接受、不需要精细管理」的范围内。但2026年，随着AI Agent的大规模部署，很多中大型企业的月度AI推理成本已经进入$100,000到$1,000,000的范围，而且增速是每季度翻倍。在这个规模上，「黑箱账单」不再是小问题，而是财务管理的重大失控风险。

第二章：四种归因场景，最重要的是LLM网关

AWS的成本归因功能覆盖了四种具体场景，每个场景对应企业AI架构中的一种典型部署模式。

场景一：IAM用户直接调用

这是最简单的场景——开发者用自己的AWS IAM用户账号直接调用Bedrock API（通常是在开发和测试阶段）。新功能会把这次调用的费用归因到具体的IAM用户名下，CFO可以在Cost Explorer里看到「张工（user: zhangsan@company.com）本月在Bedrock上花了$2,300」。

这个场景的商业价值对企业来说相对有限，因为生产环境几乎不会让员工直接用个人账号调用API。但对开发文化的影响是真实的：当开发者知道自己的测试调用有成本记录时，他们会更谨慎地控制实验规模，不会因为「反正不知道是我花的」而过度调用。

场景二：应用程序假设的IAM角色

这是生产环境中最常见的部署模式。一个应用程序后端（如Node.js服务）在运行时会「假设」（assume）一个IAM角色，使用该角色的临时凭证来调用AWS服务，包括Bedrock。这样做的安全原因是避免把长期有效的密钥hardcode在代码里。

新功能会把通过IAM角色发起的Bedrock调用，归因到具体的角色名称。如果每个产品功能或每个服务都有独立的IAM角色（这是AWS安全最佳实践推荐的），那么成本就能自动追踪到功能级别。

实操中，很多企业还没有做到「每个服务独立IAM角色」的粒度，而是共用几个大角色。但这个成本归因功能本身，会成为推动企业改进IAM角色粒度的动力——因为只有细粒度的角色划分，才能真正发挥成本可见性的价值。

场景三：联合认证身份（Okta/Entra）

很多企业使用Okta或Microsoft Entra（前Azure AD）作为统一身份认证平台，员工通过单点登录（SSO）访问AWS控制台。这种场景下，员工登录时使用的是联合认证身份，而不是直接的IAM用户。

新功能覆盖了这种场景：通过Okta/Entra联合认证后访问Bedrock的调用，会归因到具体的企业用户身份（如zhangsan@company.com）。对于那些允许员工直接访问AWS控制台进行AI实验的企业（这在数据科学和AI研究团队中很常见），这个归因能力意义重大。

场景四：LLM网关代理（最重要）

这是四个场景中技术上最复杂、商业价值最高的一个。

LLM网关（LLM Gateway）是大量中大型企业AI架构的核心组件。LiteLLM、Portkey、OpenRouter、Kong AI Gateway等工具充当LLM调用的中间层：统一管理不同模型的访问、实现限速和重试、记录调用日志、路由到最合适的模型。

在典型的LLM网关架构里，来自多个应用程序的AI调用，全部经过LLM网关汇总后，以LLM网关的IAM角色发出。从Bedrock计费的视角，只能看到LLM网关的调用，看不到LLM网关代表的是哪个下游应用程序。

AWS的新功能通过一个巧妙的机制解决了这个问题：LLM网关可以在调用Bedrock时，在请求中附带x-amzn-bedrock-caller-source-identity头，标注这次调用的最终发起者是谁（比如「product-feature-email-summary」或「team-data-analytics」）。Bedrock会把这个信息纳入成本归因，实现网关架构下的精确归因。

这个场景之所以最重要，是因为大多数已经规模化部署AI的企业都在使用LLM网关架构。没有这个场景的覆盖，其他三个场景的价值都是残缺的。

第三章：FinOps历史课——成本可见性催生了什么

让我们仔细复盘云FinOps的发展历程，因为AI FinOps将以高度相似的方式演化。

2012年到2013年：成本失控的早期症状

AWS在2012年前后开始真正意义上的企业级规模采用。早期迁移到AWS的企业很快发现，云的弹性成了双刃剑——弹性意味着可以随时扩容，但也意味着忘记关掉的资源会不断计费。「僵尸EC2实例」（zombie instances，早就不用了但没有被关掉的虚拟机）成了企业账单中普遍存在的浪费来源。Gartner在2013年估算，企业平均有20-35%的云支出是浪费的。

但在没有好的追踪工具的情况下，识别和消除这些浪费需要人工排查，成本极高。大多数企业采取的策略是「定期清理」，而不是「实时监控」。

2014年到2015年：成本可见性基础设施的出现

AWS在2014年推出了改进版的Cost Explorer（带有历史趋势分析）和Cost Allocation Tags功能成熟化（允许给资源打自定义标签，按标签维度分析成本）。这是企业云成本管理的第一次真正的基础设施升级。

与此同时，CloudHealth、Cloudability等专注云成本优化的创业公司开始快速成长。它们做的事情，本质上是把AWS的原始账单数据，转化为业务友好的洞察：「工程团队每月成本$45,000，其中$12,000是可以通过Reserved Instance节省的」、「生产环境成本上周异常增长40%，主要来自新上线的推荐算法服务」。

2016年到2020年：FinOps文化的形成

CloudHealth在2016年进行了C轮融资，2018年被VMware以约$5亿美元收购。Apptio在2019年退市后，于2023年被IBM以$19.4亿美元收购。FinOps作为一个专业领域，在2019年成立了专门的FinOps Foundation（https://www.finops.org），发布了FinOps框架和认证体系。

更重要的是，「云成本治理」从IT运营问题变成了董事会级别的议题。CFO开始要求工程VP定期汇报云成本效率。工程团队开始在架构设计中考虑成本影响。「成本优先级」成为工程文化的一部分。

这个文化转变的直接触发因素，是「成本可见性」的建立——当CFO看得到每个团队花了多少，他们开始要求每个团队解释为什么花了这些。问责带来改进，改进带来文化。

第四章：AI FinOps将改变什么

基于云FinOps的历史，可以预测Amazon Bedrock成本归因功能将在企业内部引发类似的一连串变化。

变化一：工程师行为的「成本意识转变」

在AI账单是黑箱的时候，工程师对AI调用的态度类似于对「共用的无限制资源」——既然不知道是我花的，就没有太多顾虑地调用。一个工程师可以在开发和测试阶段，反复调用昂贵的大模型来验证一个功能，完全不考虑成本影响。

当每次调用都有明确归因时，工程师会开始做以下决策：这个场景用Claude Opus（$15/百万token）还是Claude Haiku（$0.25/百万token）就够了？这个结果可以缓存吗（避免每次都重新调用）？这个批量处理任务能在非高峰时段运行以利用可能的折扣吗？

这些决策单独看起来都很小，但在规模上的累积效应是显著的。云FinOps时代，工程师的成本意识提升，被估算为云支出节省的最大来源之一，占总节省的30-40%。

变化二：CFO要求AI ROI成为标准审批项目

目前，很多企业的AI投资审批是「战略性的」——CTO说「我们需要在AI上投入」，CFO说「好的，批多少」，然后钱就花出去了，没有人系统性地追踪每个AI项目的实际ROI。

成本归因功能改变了这个局面的信息对称性：一旦每个AI功能的成本变得可见，CFO会自然地开始要求每个AI项目提供ROI计算——「这个AI功能每月成本$12,000，它帮助公司节省了多少人力？增加了多少收入？」如果答案是「不确定」，审批下一个类似项目的阻力会增大。

这对AI工程团队来说是一个压力，也是一个机会——那些能够清晰说明AI价值的项目会获得更多投资，那些价值模糊的项目会被自然淘汰。

变化三：AI成本分摊推动每个业务线的AI自主性

在很多企业，AI成本是IT部门统一承担的「基础设施成本」，各业务线不需要为自己的AI使用负责。这创造了一个已知的经济学问题：公地悲剧（tragedy of the commons）——每个人都有动力过度使用共享资源，因为成本是分散的而利益是集中的。

成本归因使得AI成本分摊（AI chargebacks）成为可能——每个业务线按实际使用量承担AI成本，直接反映在业务线的损益表中。这会在两个方向上改变行为：一方面，业务线会更谨慎地使用AI，因为成本现在是真实的，不再是「别人的钱」；另一方面，业务线在证明AI价值时会更有动力，因为他们需要向自己的上级解释为什么这笔AI支出是值得的。

成本分摊制度的引入，本质上是把「AI使用决策权」从IT中心化管理下移到各业务线。这既是授权，也是问责。业务线获得了更大的AI使用自主权，同时也承担了相应的成本责任。这种权责统一的机制，比任何AI使用政策都更有效地推动了「AI使用的理性化」——不是靠规定和限制，而是靠让每个团队真实感受到自己的AI使用成本，从而自发地优化使用方式。

从组织设计角度看，AI成本分摊制度的推广，可能还会推动企业内部「AI产品经理」角色的正式化。当业务线需要对AI成本负责时，他们会需要一个专门负责平衡AI功能价值和AI使用成本的角色——这个角色的核心能力，不是写代码，而是理解业务需求、评估AI方案的成本效益、优化AI使用模式。

变化四：AI FinOps工具市场的兴起

AWS的成本归因功能是基础设施层，它解决了「有没有原始数据」的问题，但没有解决「如何把原始数据变成业务洞察」的问题。这个空白，将催生新一批专注于AI成本优化的FinOps工具。

类比云FinOps时代的CloudHealth和Apptio，AI FinOps工具将提供：跨多个AI服务提供商（包括AWS、Anthropic直接API、Azure OpenAI等）的统一成本视图；AI使用效率分析，识别哪些调用是真正必要的，哪些可以通过缓存或模型降级优化；AI成本预测和异常检测，在成本突破预算前提前告警；模型选择建议，在质量满足要求的前提下推荐最具成本效益的模型组合。这是一个在未来两到三年内将形成独立产品赛道的市场机会，估计初期规模数十亿美元，并随着企业AI支出的增长而同步扩大。

第五章：局限性与下一步

值得清醒认识的是，Amazon Bedrock成本归因功能解决了AI成本追踪的基础设施层问题，但AI FinOps是一个比成本追踪宽得多的领域，这个功能只是起点。

从更宏观的角度看，「AI成本可见性」的建立，也是AI技术真正成熟的标志之一。一项技术从「实验性」进入「运营性」有几个典型的里程碑：规模可预测、质量可测量、成本可管理。云计算在经历了早期的野蛮增长后，FinOps的出现标志着「成本可管理」里程碑的到达，也是云计算从IT实验进入企业核心基础设施的关键信号。AI推理也在经历完全相同的历程——Amazon Bedrock成本归因的发布，正是AI版「成本可管理」里程碑到达的信号。每一项真正改变世界的技术，都需要经历这个「从创新者到主流基础设施」的成熟过程，成本透明度是这个过程不可跳过的关键一步。

局限一：仅覆盖Amazon Bedrock

AWS的成本归因只适用于通过Amazon Bedrock调用的模型。对于直接调用OpenAI API、Anthropic API、Google Vertex AI等其他AI服务的场景，同等级别的归因能力还不存在（或需要通过企业级合同单独获取）。

大多数规模化的企业AI使用是多云、多模型提供商的——同一家公司可能在不同场景下分别使用Bedrock上的Claude、Azure OpenAI的GPT-4o、直接调用Anthropic API的Claude。真正完整的AI成本追踪需要覆盖所有这些来源，AWS的功能只解决了其中一部分。

局限二：成本可见性不等于成本理解

知道每个团队花了多少，和理解「为什么花了这么多、值不值」，是两件不同的事。成本归因提供的是「谁花了多少」的数字事实，但分析这个数字背后的商业逻辑，需要额外的工具和洞察层。

局限三：没有解决责任框架问题

成本归因是问责机制的技术前提，但不是完整的问责机制本身。「我知道工程团队A每月花了$45,000在Bedrock上」和「我知道工程团队A是否应该为这$45,000的支出负责、以什么标准评估」，是两件事。后者需要组织、流程和文化的配合，不是技术功能能直接提供的。

第六章：从「知道花了多少」到「知道花得值不值」——AI成本治理的完整闭环

成本归因解决了「知道是谁花的」这个问题，但一个完整的AI成本治理体系需要回答三个问题：谁花了多少（成本可见性）、花得合理吗（成本合规性）、花得值吗（成本效益性）。AWS的新功能只解决了第一个问题。

成本合规性：有没有浪费？

成本合规性关注的是「这笔AI支出是否按预期方式被使用」。常见的合规问题包括：开发者在生产环境使用了过于昂贵的模型（用Claude Opus做一个简单的文本分类任务）；测试代码被意外部署到生产环境持续调用；未被使用的AI功能仍然保持运行状态消耗资源；并发量远超预期导致成本激增。

这些问题的发现需要成本归因数据加上业务上下文——光知道某个团队花了$30,000不够，还需要知道这$30,000里哪些是符合预期的正常使用，哪些是异常的浪费。这需要一层分析工具，目前市面上还没有成熟的AI成本合规产品，这是一个正在形成的市场空白。

成本效益性：花得值吗？

这是最难回答的问题，也是CFO最关心的问题。某个产品功能的AI成本是$8,000/月，它带来的价值是多少？节省了多少客服人力？提高了多少用户留存？增加了多少转化？

把AI成本与业务结果关联起来，需要将AWS Billing数据与产品分析数据（如Mixpanel、Amplitude）、业务指标数据（如Salesforce的销售数据）打通。这个数据整合工作相当复杂，目前只有少数技术成熟度最高的企业在系统性地做这件事。

成本归因功能是这个完整闭环的起点——没有清晰的成本归因，其他两个问题都无从回答。这就是为什么它的发布意义重大：它移除了建立完整AI成本治理体系的最大障碍。

第七章：对比分析——AWS之外，其他AI服务提供商如何应对成本追踪需求

AWS的成本归因功能出现，也给其他AI服务提供商造成了差异化压力。了解竞争格局，有助于企业制定多云AI成本管理策略。

Anthropic直接API：目前Anthropic的API调用账单是按工作区（workspace）级别管理的，可以创建多个API密钥对应不同的项目，但细粒度的IAM主体级别归因功能还不存在。企业级客户（通过AWS Marketplace购买的Claude访问）可以受益于本次AWS的成本归因更新；直接调用Anthropic API的客户暂时还不能。Anthropic有企业级账单管理路线图，但具体功能和时间线未公布。

Azure OpenAI Service：微软的Azure OpenAI提供了相对更成熟的成本归因机制，通过Azure的Cost Management和Tags系统可以实现部门级和项目级的成本追踪。但与AWS的新功能相比，Azure的粒度仍然在「标签」级别而非「请求发起者」级别——也就是说，你可以把某个Azure资源组的成本归因到某个部门，但还无法自动追踪到具体的用户或应用程序角色。

OpenAI API（企业版）：OpenAI的企业版产品提供了基本的使用量统计，可以按API密钥查看使用情况。但其成本归因能力远不如AWS细致，特别是在复杂的多应用架构和LLM网关场景下。

从竞争角度看，AWS这次的成本归因功能是一个重要的差异化举措，特别是对那些已经在AWS生态系统中重度投资的企业。对于正在评估AI基础设施平台的企业，「成本可见性」将成为一个越来越重要的评估维度。

结语：AI成本从黑箱到可问责，是AI从实验进入运营的必要仪式

云FinOps的历史告诉我们：当大规模基础设施成本从黑箱变成可追踪、可分析、可优化时，整个行业的使用方式都会发生结构性变化——不只是省钱，而是整个采购、使用、优化、问责的工作流都会重建。

Amazon Bedrock成本归因功能的发布，不是一个功能更新的故事，而是一个时代开始的信号：AI推理成本终于可以被精确追踪了，AI FinOps时代正式到来了。

在未来3年里，我们会看到AI FinOps工具市场的兴起（类比CloudHealth/Apptio时代），会看到CFO开始在董事会层面要求AI ROI透明度，会看到「AI成本管理」成为技术领导者的核心绩效指标之一，会看到工程师在设计AI功能时把成本纳入架构考量。

这一切的起点，是「知道AI账单是谁的」。这一步，AWS已经迈出了。而对于企业决策者来说，真正重要的行动不是等待更完善的工具出现，而是现在就开始建立AI成本透明度的内部文化。

为什么「现在」是关键时间节点

很多企业会把AI成本治理列为「未来某个时候需要解决的问题」。这是一个代价很高的拖延。

企业AI成本的增长是指数级的，不是线性的。当AI Agent从12个增长到20个，当每个Agent的调用频率随着业务规模上升，当新的AI功能被不断部署，成本复合增长的速度会超出大多数预期。在AI成本还在可接受范围内的时候建立追踪和治理机制，成本极低；等到AI账单大到无法忽视的时候才开始建设，不但追溯性分析极其困难，还可能已经积累了大量难以量化的浪费。

云FinOps的历史告诉我们，最早建立云成本治理体系的企业，在云计算规模化阶段节省了远超同行的成本，因为他们从一开始就保持了对云支出的精确控制。AI FinOps的故事，会以高度相似的方式重演。

具体而言，企业应该立即做的三件事：第一，梳理所有Bedrock使用场景，确保IAM角色的划分足够细粒度，让成本归因数据有意义；第二，开始定期向业务领导层汇报AI成本分项数据，让AI成本从「IT黑箱」变成「业务可见数字」；第三，在下一个新AI项目的立项审批中，明确要求提供AI成本预测和ROI计算，建立成本导向的AI投资文化。

AI成本治理的旅程，从今天开始。对于那些已经在AI上投入大量资金、但对自己的AI支出结构一知半解的企业来说，现在是开始建立这种透明度的最好时机——不是因为已经出了问题，而是因为现在的基础设施已经让这件事变得可能，而且比任何时候都更重要。在AI资本密集度持续上升的2026年，知道自己的钱花在哪里，是每个企业最基本的财务管理职责，也是对股东、员工和客户负责任的商业行为的基础。

参考资料

  1. AWS Machine Learning Blog, “Introducing granular cost attribution for Amazon Bedrock”, April 17, 2026. https://aws.amazon.com/blogs/machine-learning/introducing-granular-cost-attribution-for-amazon-bedrock/

  2. CNBC, “VMware Buys CloudHealth Technologies for $500 Million”, August 2018. (VMware press release, August 27, 2018)

  3. Reuters, “IBM to acquire Apptio for $1.94 billion”, June 2023. https://www.reuters.com/technology/ibm-acquire-apptio-19-billion-2023-06-26/

  4. FinOps Foundation, “The FinOps Framework and Certified Practitioners”. https://www.finops.org