如果你正在管理云成本，近两年很可能会有一种日益强烈的感受：账单上与人工智能相关的开销正在以肉眼可见的速度攀升。过去，这可能只是几行简单的API调用日志，但如今打开账单，GPU实例费用、模型调用费、向量数据库存储……这些零零总总的项目加在一起，已经成为一笔不容忽视的支出。

更令人困扰的是，AI成本的管理逻辑与传统云服务截然不同。你以往熟悉的那些FinOps方法论——比如标签归因、预留折扣、资源合理调整（Right-sizing）——在AI场景中，有些依然有效，有些则需要彻底换一套思路。

本文作为「FinOps for AI」系列的基础篇，将系统性地梳理三个核心问题：三大云厂商的生成式AI技术栈具体是如何构成的、AI服务的定价模式有哪些，以及各自适合哪些场景；此外，还探讨在AI时代，究竟是谁在消费这些服务，谁又应该为这些成本负责。搞清楚了这些，你才有机会真正有效地管理AI成本。

一、AI 成本管理的本质：像传统云，但又不同于传统云

在深入技术细节之前，必须先把这个框架讲清楚，因为这是许多FinOps团队容易踩坑的起点。

AI服务在很多方面与传统云服务的管理方式有共通之处。你原本积累的FinOps实践经验，并没有白费。

那个最基础的公式依然成立：价格乘以数量等于成本。降低成本的路径只有两条：要么压低单价，要么减少用量。这条法则在AI世界中同样适用，只是执行起来增加了许多细节。

云厂商的AI服务费用会统一出现在你的账单中，与ECS实例、S3存储费用并列。这意味着，你原有的数据摄取流程和账单聚合方式无需推倒重来。大部分AI服务支持资源标签，与传统云服务一样可以进行归属分析。AI基础设施层——也就是GPU实例——同样可以购买预留实例或承诺使用折扣，费率优化的基本思路是一致的。

然而，AI成本管理有几个方面与传统云完全不同，而且这些差异不是细节性的，而是根本性的。

计量单位发生了改变。 传统云服务按CPU核小时、GB内存、GB存储计量，这些单位物理意义清晰、计量逻辑简单。而AI服务大量采用Token计费，输入Token和输出Token分别计费。即使是“一个Token”，在不同模型、不同上下文窗口、不同压缩策略下，对应的实际费用可能相差数倍。你很难像监控CPU利用率那样监控Token消耗，因为Token消耗的波动性远高于传统资源。

SKU 迭代速度快得惊人。 云厂商推出新模型的速率，已远超传统云服务的版本更新频率。更麻烦的是，许多新模型无法在云厂商控制台原生打上标签，成本归属需要依靠工程侧自行实现。

GPU 的稀缺性改变了游戏规则。 传统云服务基本可以随用随扩，容量不足时临时增加机器即可。而AI工作负载所依赖的GPU资源近年来一直处于相对稀缺状态，并非想扩就能扩。这直接影响了你对预留策略的选择——买多了浪费，买少了影响业务，权衡起来比传统云复杂得多。

定价波动性之大，让预算变成猜谜。 同一个模型，不同版本的价格可能相差一倍。模型厂商调整价格的频率也远超传统云服务的费率调整频率。你第一季度做完AI成本预测，第二季度可能发现模型厂商悄悄调了价，导致整个预测失效。

工程团队普遍缺乏成本意识。 这一点很现实但常被忽略。许多工程师是第一次使用AI服务，他们的调用方式、模型选择、中间层架构设计都可能造成严重的资源浪费。

TCO 的复杂度超出了传统软件的边界。 传统软件的优化思路是“一次开发，长期运行”。AI应用除了开发成本，还有持续的模型训练成本、推理成本，并且模型质量直接决定了业务效果——你不能为了省钱而强行使用效果较差的模型。这意味着AI的成本和价值是相互耦合的，不像传统云服务那样可以将成本与价值分开讨论。

理解了这些差异，你就会明白为什么许多团队沿用过去的FinOps方法来管理AI成本，会感觉处处不对劲。

二、三大云厂商的 GenAI 技术栈到底长什么样

在了解本质差异后，我们来拆解具体的技术栈。这部分内容有些硬核，但非常重要——因为成本发生在每一层，而每层之间的定价逻辑差异巨大。如果你不清楚哪个组件在收费、收的是什么费，优化就无从谈起。

生成式AI的技术栈已经从几年前的“简单API调用”，演变为一个分层的复杂架构。我绘制了一张简单的分层结构图，结合三大云厂商的组件对照，帮助你建立全局视野。

最底层是硬件层，主要是NVIDIA GPU，存在于各大云厂商的IaaS层中，例如AWS EC2的GPU实例（G4、G5、P4d）、Google Cloud的Compute Engine GPU（Tesla V100/A100/H100），以及Azure的NC系列。硬件之上，IaaS层提供容器编排、负载均衡等基础能力，这与传统云没有本质区别。

再往上一层是模型训练与推理平台，也就是我们常说的AI Platform / Managed AI服务。这层的代表服务包括Amazon SageMaker、Vertex AI、Azure ML。这些平台提供完整的模型训练、部署、微调能力，大大降低了AI的工程门槛。你无需自己搭建训练集群，直接将数据传入，平台会帮你处理分布式训练、资源调度和模型部署。但代价是更复杂的定价模型——按计算时长、数据量、API调用次数计费，计费颗粒度比IaaS细得多。

再往上是基础模型层，这是生成式AI时代全新出现的一层，类似于模型市场的角色。AWS有Amazon Bedrock，Google有Vertex AI Model Garden，Azure有Azure OpenAI Service。这一层提供对各种大模型的统一访问入口——Claude、GPT、PaLM、Gemini、Stable Diffusion——你可以通过同一个API接口访问多个提供商的模型。定价由模型提供商决定，各家费率差异较大。

最顶层是应用层，包括低代码/无代码AI开发工具（如AWS App Studio、Power Apps）、代码生成工具（GitHub Copilot、Amazon Q）、对话式AI等。这一层的成本相对透明，但在后台同样依赖多层服务的调用，成本容易被低估。

下面这张表是三大云厂商生成式AI组件的对照（截至2024年底，信息来自公开资料）。每个厂商的定位和覆盖范围存在差异，实际选型时需要根据具体需求进行评估。

有一点值得特别提醒：许多团队以为使用了某个云厂商的模型服务，只需要关注那一家厂商的账单。实际上，AI应用的架构复杂度远高于传统云服务——你可能在AWS上用Bedrock调用Claude，在GCP上用Vertex AI调用Gemini，同时在应用层用Azure的认知服务做OCR。成本分散在多个云厂商的多个服务中，缺乏统一的可见性，这是AI FinOps面临的最大挑战之一。

三、AI 服务的消费类型：钱到底花在了哪里

了解了技术栈的分层结构后，我们再来看具体的资金流向以及谁在支出。这个问题看似简单，实际上直接决定了成本优化的方向。

第一种消费类型：GPU 算力。这是最底层的成本，与传统云服务的计算成本逻辑最为相似。按GPU实例运行时长计费，成本驱动因素包括GPU型号（V100/A100/H100的单价差异很大）、实例规格、运行时间、数据传输。定价模式也较为标准：按需、预留实例、竞价实例都可选。如果你有自己的模型需要训练和部署，这一层是主要成本来源。

第二种消费类型：托管 AI 平台。SageMaker、Vertex AI、Azure ML 这类平台服务为你省去了大量工程复杂性，但代价是单位成本高于直接使用GPU实例。计费维度包括训练任务的计算时长、部署模型的实例规格和运行时长、处理的数据量。这类服务适合没有成熟AI基础设施团队的团队，用金钱换取时间。

第三种消费类型：第三方模型和 API。OpenAI、Anthropic、Hugging Face 这类第三方模型服务商通常按消耗量计费，最常见的方式是按Token收费。这种模式对成本追踪较为友好——你可以清楚地知道每次API调用花费了多少Token、乘以单价就是总价。但问题在于单价不固定，模型版本更新时费率可能上调，而且不同模型、不同版本的费率差异很大。

第四种消费类型：向量数据库和相关存储。RAG（检索增强生成）架构已成为企业AI应用的主流选择，这意味着你的应用中必然包含向量数据库的成本——无论是pgvector还是专门的向量数据库服务如Pinecone、Milvus、Qdrant。这一层的成本相对固定，但数据量增长时存储费用会明显上升。

第五种消费类型：订阅制和预付费套餐。许多AI平台和模型服务商提供订阅方案——按月或按年支付固定费用，获得一定量的调用额度或功能权益。这种方案适合用量稳定的场景，优点是预算简单，但如果用量不足，就等于白白浪费。

理解了这些消费类型，你就明白为什么同一个AI应用，不同团队的账单结构可能截然不同——有的团队GPU成本占比高，有的团队API调用费是主要开销，还有的团队可能是向量数据库存储费用最高。不了解消费结构，优化就无从谈起。

四、六种定价模型：没有最好的，只有最合适的

这部分是AI FinOps最实用的内容之一。AI服务的定价模式比传统云服务复杂得多，但本质上还是在“按量付费”和“承诺付费”之间进行权衡。以下是六种常见的AI定价模型，以及它们的适用场景和避坑指南。

按需付费（On-Demand）是最灵活的模式，用多少付多少，不存在浪费。这种模式适合新项目上线初期——由于不清楚实际用量，如果直接购买一年或三年的承诺，很容易造成浪费。它也是短期、临时性AI工作负载的首选，比如一次性的大规模数据处理任务。但按需付费的问题也很明显：单价最高，而且AI调用的波动性大，你很难将月度成本控制在确定的范围内。

预留实例 / 承诺使用折扣（CUDs）是成本优化的首选，尤其适用于稳定的推理服务。如果你的AI服务每天的调用量相对稳定，没有任何理由使用按需付费。CUD可以为你提供30%到60%的折扣，具体幅度取决于承诺的用量和时长。但这里有一个常见陷阱：CUD适合稳定的生产负载，不适合仍在快速迭代的实验性项目。如果你预估错了用量，多买的部分既不能退款也无法转让，会造成直接损失。

预置容量（Provisioned Capacity）是一种更重的承诺——你提前购买一段固定算力，无论是否使用都需要付费。这种模式适合低延迟的实时AI应用，例如对话式AI或实时推荐系统。这些场景对响应时间敏感，不能接受冷启动延迟，必须确保有足够算力随时待命。预置容量的问题是利用率风险——如果流量波动大或存在季节性，购买的容量大部分时间可能闲置，浪费明显。

抢占式实例（Spot）是成本敏感型工作负载的救星。如果你有批量推理任务、模型重训练任务，或任何可以接受中断的工作负载，Spot可以帮你获得比按需付费低60%到80%的价格。但天下没有免费的午餐，Spot实例随时可能被云厂商回收，你需要具备健壮的调度机制来处理中断。这个机制本身带有工程成本，不适合缺乏DevOps能力的团队直接使用。

订阅制（Subscription）常见于AI平台服务和一些模型服务商，按月或按年支付固定费用，换取特定量级的调用额度或高级功能权益。订阅制的优点是预算简单——你清楚地知道每月需要支付多少费用，不会收到意外账单。缺点是如果实际用量达不到这个水平，就等于在补贴云厂商。建议在订阅前至少观察一两个月的实际用量，确认能充分利用后再签约。

阶梯定价（Tiered）体现了规模效应——用量越大，单价越低。如果你有明确的增长预期，阶梯定价可以在业务增长过程中逐步降低单位成本。但这需要你具备准确的用量预测能力，如果增长慢于预期，阶梯定价的优势就无法体现。

在实际工作中，一个成熟的AI FinOps架构通常会混合使用多种定价模式：核心的生产推理服务购买CUD来锁定成本，训练任务充分利用Spot，API调用量大的模型选择阶梯定价，仍在探索的实验性项目先用按需付费保持灵活性。没有万全之策，只有最适合的方案。

五、八类用户画像：谁在用 AI，谁应该为成本负责

这是我认为AI FinOps与传统FinOps最大的区别所在——AI服务的使用者已经远远超出了工程团队的范畴。

在传统云时代，云成本的制造者是开发者和运维人员——他们清楚自己正在使用什么资源，也明白为什么使用这些资源。财务团队可以询问他们“这笔账单是怎么回事”，他们能够给出答案。

AI时代则不同。产品经理可能直接付费开通一个GPT-4 API账号进行产品调研，这笔费用可能记在公司的企业账号下，但产品经理本人可能完全没有成本意识。市场营销同事可能使用公司订阅的某个AI写作工具生成内容，这个工具背后的API调用费用在账单中显示为一个你不认识的SKU。管理层要求“所有部门都要用AI提效”，导致AI的使用量飙升，却没有人为此负责。

因此，在着手AI FinOps之前，必须先回答一个问题：谁在使用AI，谁应该为成本负责。

梳理了八类最常见的用户画像，理解他们是谁、他们的动机是什么、他们对成本的态度如何，才能进行有效的成本分摊和归属。

数据科学家是模型训练和评估的主要制造者。他们需要大量GPU算力进行实验和迭代，GPU成本主要从这里产生。这个群体通常有一定的成本意识，但主要关注点在于模型效果而非成本最小化。他们的痛点是：当GPU资源紧张时，实验进度会受影响，因此他们有动机多占用GPU以保证实验速度。

软件工程师是将AI能力集成到产品应用中的桥梁。他们通过API调用和自动化工作流使用AI，对成本有一定认识但并非首要关注点。他们的工作目标是交付功能，成本优化往往排在功能之后。更糟糕的是，许多软件工程师不了解AI的计量机制——他们可能在循环中重复调用同一个API，每次调用都重新发送完整上下文，导致Token消耗是实际需要的数倍。这是一个非常普遍且严重的成本漏洞。

业务分析师利用AI生成的洞察进行决策，使用量通常不大但分布广泛。他们对底层技术了解有限，更关注AI输出质量和获取速度，而非成本。他们使用的AI能力可能嵌入在日常使用的SaaS工具中（如BI平台、办公软件），使得成本归属困难。

运维工程师是AI基础设施落地的关键执行者。他们负责GPU实例的部署、成本监控以及优化策略的执行。他们具备技术能力理解成本，但由于工作职责广泛，往往缺乏深入研究AI成本结构的时间和精力。这个群体是FinOps团队推动AI成本优化时最需要对接的对象。

产品经理定义AI功能需求并监控AI对产品价值的贡献。他们是AI支出的主要申请人，也是最需要建立成本意识的群体之一。许多产品经理第一次接触到AI成本概念，是在收到财务团队发来的账单预警时。这是一个很大的认知断层——他们申请AI功能时，并不知道这个功能将花费多少钱、资金从哪里来。FinOps团队有责任在功能上线前与产品经理对齐预期成本，建立基本的成本意识。

管理层设定组织层面的AI目标、审批预算、定义成功标准。他们需要看到的是汇总后的数字——AI总支出是多少、带来了什么业务价值、ROI是多少。他们不是成本优化的执行者，但却是政策制定者和预算分配者。向管理层汇报时，需要采用他们能理解的语言——业务价值和财务影响，而非技术细节。

最终用户通过办公工具、SaaS平台或仪表板消费AI输出。他们是AI能力的使用终端，其行为直接决定API调用量和Token消耗。例如，在客服场景中，用户每提出一个问题，AI就会产生一次推理成本。如果用户倾向于长篇大论地提问，Token消耗会显著高于简洁提问。提升用户的使用效率，实际上也是在降低成本。

数据工程师负责构建和管理AI训练数据的管道。他们是经常被忽视但实际对成本有重要影响的群体——数据质量直接影响模型效果，糟糕的数据质量会导致需要更多训练迭代才能达到目标效果，从而推高训练成本。此外，数据管道的效率也会影响GPU的有效利用率——如果数据供给跟不上，GPU在等待数据时会造成浪费。

理解了这些画像，你会发现一个关键问题：AI成本归属的复杂度远高于传统云服务。传统云服务中，成本通常可以归属到“哪个团队、哪个项目、哪个环境”。而在AI服务中，同一个API key可能被多个团队共用，同一个模型可能同时服务于多个产品功能，成本归属涉及的不仅是谁在用，还包括“用在哪里、产生了什么价值”。

六、AI 时代 FinOps 能力发生了什么变化

如果你已经具备FinOps实践经验，你的方法论中哪些可以复用、哪些需要调整？这可能是你最关心的问题。

我查阅了FinOps Foundation发布的相关资料，并结合实际经验，将FinOps各项核心能力在AI场景下的变化整理成了一张表。绿色标签表示通用，黄色标签表示存在差异。绿色并不代表简单，而是指底层逻辑一致，只需针对AI进行局部调整。黄色则意味着需要全新的方法论或面临根本性挑战。

成本分摊 通用，但难度显著增加。标签体系和方法论整体通用，但多租户、多Agent场景下的成本归属是个大挑战。同一个AI模型可能同时被“客服机器人”和“新用户引导机器人”使用，前者属于售后场景，后者属于转化场景，业务价值完全不同，但成本混在一起，缺乏行业通用的分摊标准。

预测 差异巨大，是AI FinOps中最难的环节之一。传统云的用量预测基于历史数据和稳定的扩展规则，相对准确。AI服务的预测难度来自多个方面：Token计量的不可预测性（用户输入长短不一、模型版本更新后消耗模式可能变化）、定价波动（模型厂商随时可能调价）、新功能上线带来的用量跃升。实际经验是，在起步和探索阶段，AI成本预测的误差可能高达±50%，只有经过多轮迭代、积累足够数据后，误差才能收敛到可接受范围。

单位经济 通用但维度增加。每Token成本、每次调用成本等是新增的单位，需要单独建立追踪和分析体系。在衡量AI业务价值时，除了常见的业务指标，还需要建立一套新的指标体系，例如“AI推理单次成本 vs 带来的用户满意度提升”。

费率优化 通用但动态性更强。费率优化的基本原则不变——争取最优的折扣组合。但AI市场的动态性使费率优化更像一场持续进行的博弈，需要更频繁地重新评估当前费率是否最优。

对标 差异巨大，外部基准少且一致性低。每个企业的AI应用场景差异太大，很难建立有效的外部对标。内部基准的建立也需要时间和数据积累。

云可持续性 通用，但AI请求的碳排放是新增维度。每次AI推理请求都有碳排放足迹，这个指标在传统云服务中几乎无需关注，但在AI场景中开始变得重要。部分云厂商已提供按请求的碳排放报告，可作为参考。

写在最后

AI成本管理的本质，是在高度动态、高度复杂的新范式中应用FinOps的核心原则——可见性、优化、归属、持续改进。只是每个环节的复杂度都比传统云高出至少一个数量级。

好消息是：你积累的FinOps基础能力没有白费。坏消息是：AI的特殊性要求FinOps团队快速学习新技能——Token计量、GPU容量规划、模型选择评估，这些概念在传统云中根本不存在。你需要补课，并且要加快速度。