FinOps for AI 基础篇：技术栈、定价模型与用户画像

如果你在管云成本，这两年一定有种越来越强烈的感觉：账单里 AI 相关的支出正在以肉眼可见的速度攀升。以前可能只是几行 API 调用日志，现在打开账单，GPU 实例费用、模型调用费、向量数据库存储……零零总总加起来，已经成了一笔不能忽视的数目。

更让人头疼的是，AI 成本的管理逻辑和传统云服务完全不同。你熟悉的那些 FinOps 方法论——标签归因、预留折扣、Right-sizing——放在 AI 场景里，有的依然管用，有的却需要彻底换一套思路。

本文作为「FinOps for AI」系列的基础篇，会带你系统梳理三件事：三大云厂商的 GenAI 技术栈到底是怎么构成的、 AI 服务的定价模式到底有哪些以及各自适合什么场景、以及在 AI 时代到底谁在消费这些服务、谁应该为这些成本负责。搞清楚这些，你才有机会把 AI 成本真正管起来。

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

在深入技术细节之前，我想先花点时间把这个框架讲清楚，因为这是很多 FinOps 团队踩坑的起点。

AI 服务在很多方面和传统云服务的管理方式是共通的。你原来的 FinOps 实践积累下来的能力，没有白费。

最基础的那个公式依然成立：Price 乘以 Quantity 等于 Cost。降低成本永远只有两条路，要么压低单价，要么减少用量。这条法则在 AI 世界里同样适用，只是执行起来细节多了很多。

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

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

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

SKU 迭代速度匪夷所思。 云厂商推出新模型的速度，已经远远超过传统云服务的版本更新频率。更麻烦的是，很多新模型无法在云厂商控制台原生打标签，成本归属要靠工程侧自己实现。

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

定价波动性大到让预算变成猜谜。 同一个模型，不同版本价格可能差出一倍。模型厂商调整价格的频率也远超传统云服务的费率调整频率。你可能 Q1 做完 AI 成本预测，Q2 发现模型厂商悄悄调了价，整个预测全部作废。

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

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

理解了这些，你就知道为什么很多团队沿用老的 FinOps 方法管 AI 成本，会感觉哪里都不对劲。

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

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

Generative 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 细得多。

再往上是 Foundation Model 层，这是 GenAI 时代全新出现的一层，类似于模型市场的角色。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 等等。这一层的成本相对透明，但在后台同样依赖多层服务的调用，成本容易被低估。

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

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

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

知道了技术栈的分层结构，我们再来看具体的钱花在哪里、谁在花钱。这个问题看似简单，实际上直接决定了成本优化的方向。

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

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

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

第四种消费类型：向量数据库和相关存储。RAG（Retrieval-Augmented Generation）架构现在是企业 AI 应用的主流选择，这意味着你的应用里一定有向量数据库的成本——无论是pgvector 还是专门的向量数据库服务 Pinecone、Milvus、Qdrant。这一层成本相对固定，但数据量增长时存储费用会明显上升。

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

理解了这些消费类型，你就可以理解为什么同一个 AI 应用，不同团队的账单结构可能完全不一样——有的团队 GPU 成本占比高，有的团队 API 调用费是大头，有的团队可能是向量数据库存储费用最高。不了解消费结构，优化就无从谈起。

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

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

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

**Reserved / CUDs（承诺使用折扣）**是成本优化的第一选择，尤其对于稳定的推理服务。如果你的 AI 服务每天的调用量相对稳定，没有任何理由用 On-Demand。CUD 可以帮你拿到 30% 到 60% 的折扣，具体幅度取决于你承诺的用量和时长。但这里有一个常见的坑：CUD 适合稳定的 production 负载，不适合还在快速迭代的实验性项目。如果你预估错了用量，买多的部分既不能退款也不能转让，生亏。

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

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

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

Tiered / 阶梯定价是规模效应的体现——用量越大，单价越低。如果你有明确的增长预期，阶梯定价可以帮助你在业务增长的过程中逐步降低单位成本。但这里需要你有准确的用量预测能力，如果增长比预期慢，阶梯定价的优势就体现不出来。

在实际工作中，一个成熟的 AI FinOps 架构通常会混合使用多种定价模式：核心的 production 推理服务买 CUD 锁定成本，训练任务充分利用 Spot，API 调用量大的模型走阶梯定价，还在探索的实验性项目先用 On-Demand 保持灵活性。没有银弹，只有适合。

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

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

在传统云时代，云成本的制造者是开发者和运维——他们知道自己在用什么资源，也知道为什么要用这些资源。财务团队可以追着他们问「这个账单是怎么回事」，他们答得上来。

AI 时代不一样了。产品经理可以直接掏钱开一个 GPT-4 API 账号来做产品调研，这个费用可能直接挂在了公司的企业账号下，但产品经理本人可能完全没有成本意识。市场营销的同事可能用了公司订阅的某个 AI 写作工具来生成内容，这个工具背后的 API 调用费用在账单里显示为你完全不认识的 SKU。管理层要求「所有部门都要用 AI 提效」，然后 AI 的使用量开始飙升，但没有人为这个飙升负责。

所以在做 AI FinOps 之前，必须先回答一个问题：谁在用 AI，谁应该为成本负责。

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

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

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

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

运维工程师（DevOps Engineers） 是 AI 基础设施落地的关键执行者。他们负责 GPU 实例的部署、成本监控和优化策略的执行。他们有技术能力理解成本，但因为工作职责广，往往缺乏深入研究 AI 成本结构的时间和精力。这个群体是 FinOps 团队推动 AI 成本优化时最应该链接的对象。

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

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

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

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

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

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

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

我翻了一下 FinOps Foundation 发布的相关资料，结合实际经验，把 FinOps 各项核心能力在 AI 场景下的变化整理了一张表。绿色标签代表通用，黄色标签代表有差异。绿色不代表简单，而是代表底层逻辑一致，只需要针对 AI 做局部调整。黄色则代表需要全新的方法论或者有根本性的挑战。

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

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

Unit Economics（单位经济） 通用但维度增加。cost-per-token、cost-per-call 等是新增的单位，需要单独建立追踪和分析体系。在衡量 AI 业务价值时，除了常见的业务指标，还需要建立一套新的指标体系，比如「AI 推理单次成本 vs 带来的用户满意度提升」。

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

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

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

写在最后

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

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

如果你觉得这篇文章有帮助，请分享给团队里正在为 AI 成本头疼的同事。下期我们会继续推出进阶篇，聚焦 AI 业务价值的量化方法论，敬请期待。