FinOps for AI 概述-阿里云开发者社区

摘要

cost-per-token 等新型使用指标，以及对波动成本和 GPU 资源稀缺性的认知，带来了全新挑战。需定期跟踪和审核 AI 成本与使用情况、设定配额、标记资源、优化 GPU 分配，以此严格管控 AI 支出。要针对 AI 相关内容对团队开展 FinOps 最佳实践培训，并将实时财务监控与业务成果对齐，实现持续优化。

新的 AI 成本与使用挑战，不变的 FinOps 方法论

各行业、各云成熟度水平的企业都在探索生成式人工智能（Gen AI）服务（如大语言模型（LLMs）），以此强化产品、提升员工生产力、为客户创造更大价值。这些服务给 FinOps 团队带来了新的挑战与机遇。

其中部分挑战与任何新型云架构或应用模型落地时的挑战一致，也有部分是 AI 领域独有的。

和 FinOps 实践对接的任何新技术一样，AI 领域需要团队学习新术语与概念、与新的利益相关方协作、理解支出与折扣模型以实现优化。但与此同时，AI 还带来了特殊挑战，包括专业服务管理、GPU 实例优化、专业数据接入需求，以及 AI 成本对更多元跨职能团队更广泛且更快速的影响。

本文聚焦FinOps for AI。而利用 AI 及 AI 工具开展 FinOps（即 AI for FinOps）同样是重要且广泛的议题，但不在本文讨论范围内。

尽管 AI/ML 服务已存在多年，但历史上其落地需要大量精力与专业能力。云服务商和 AI 厂商的近期技术突破，极大简化了 Gen AI 服务的部署流程，进而推动了对 GPU 硬件、可扩展云服务，以及具备相关系统设计与管理能力专业人才的需求激增。

这种易获取性使得产品、营销、销售、管理层等非传统技术团队，也直接产生了 AI 相关的云支出。与此同时，GPU 资源稀缺造成了基础设施市场的波动，而多元的落地模式与成本结构，也让 “理解使用情况与成本”“量化业务价值” 等 FinOps 目标的实现难度有所提升。

云环境下 AI 驱动应用的基础

AI 服务与其他云服务的共性管理方式

Gen AI 服务乍看之下似乎完全是全新领域，有着专属术语和概念，但其实其管理方式和多数云服务相通。对于 FinOps 从业者而言，需牢记其与现有管理的云服务存在诸多相似性，在很大程度上，可沿用现有 FinOps 实践来管理 Gen AI 的成本与使用情况。

基础的 “价格 × 用量 = 成本” 公式依然适用。从业者可通过降低单价（费率）或减少资源使用量来管控成本。

基于云的 AI 服务成本会和其他所有云成本一同体现在云账单数据中。针对非云厂商的数据，或 AI 服务专属可观测性系统的数据，可能需要额外进行数据接入。

多数云服务支持对服务进行标记 / 打标签，以实现成本分摊。在共享环境、训练成本或基于 API 的资源管理场景下，可能需要对标记规则进行调整。

许多 AI 服务组件可享受承诺折扣（预留实例），其费率管理流程与传统云服务十分相似。

AI 服务的差异化管理点

Gen AI 服务会带来一些区别于多数公有云成本的特殊挑战：

诸多 AI 模型与服务的计费方式不统一，且存在多种版本或变体可供采购，定价可能出现大幅涨跌。

云服务商会频繁新增 SKU，其中不少 SKU 无法原生支持打标签，需要借助工程工具配置标签键值，才能实现租户级应用总拥有成本（TCO）的成本拆分与追踪。

服务的名称与类型，可能和 FinOps 团队当前管理的服务存在较大差异。

令牌（Tokens）！计费计量标准或计费要素截然不同。例如，用户输入的令牌数量，与实际发送至 API 端点、用于计费的经压缩和语义精简 / 重写后的提示词输入令牌数量，二者存在差异。相关详细说明可参考本文的使用追踪章节。

以 GPU 服务器为代表的 AI 基础设施资源普遍存在稀缺性与服务可用性问题，需要针对合同、编排和采购方式应用容量管理技术 —— 这在传统云服务中并不常见，且会影响基础设施的可用性与定价。

工程团队在 AI 服务使用方面经验尚浅，要实现持续的成本效益，还需应对多层动态架构的管理难题。

AI 用例的 TCO 核算逻辑，与传统软件应用负载的固定成本和用途存在差异：AI 场景下持续训练是长期成本的一部分，而 “质量” 维度成为关键新考量 —— 既可以选择更小型、低成本的新型模型来满足基础质量需求，也可能需要最先进的推理级前沿基础模型，以实现类人化的高级质量输出。

生成式 AI 的应用，促使头部云服务商构建了完整的技术栈以支撑各类用例。

GenAI 类别	GenAI 组件	Amazon Web Services	Google Cloud	Microsoft Azure
基础模型	运行时	Amazon Bedrock	Vertex AI	Azure OpenAI
	文本 / 聊天	Amazon Bedrock	PaLM	GPT
	代码生成	Amazon Q、Amazon Bedrock	Codey	GPT
	图像生成	Amazon Bedrock	Imagen	DALL-E
	翻译	Amazon Bedrock	Chirp	无
模型目录	商用模型	Amazon SageMaker AI、Amazon Bedrock Marketplace	Vertex AI Model Garden	Azure ML Foundation Models
	开源模型	Amazon SageMaker AI、Amazon Bedrock Marketplace	Vertex AI Model Garden	Azure ML Hugging Face
向量数据库	-	Amazon Kendra、Amazon OpenSearch Service、Amazon RDS for PostgreSQL（搭载 pgvector）	Cloud SQL（pgvector）	Azure Cosmos DB、Azure Cache
模型部署与推理	-	Amazon SageMaker AI、Amazon Bedrock	Vertex AI	Azure ML
模型微调	-	Amazon SageMaker AI、Amazon Bedrock	Vertex AI	Azure OpenAI
低代码 / 无代码开发	-	AWS App Studio、Amazon SageMaker AI Unified Studio	Gen App Builder	Power Apps
代码补全	-	Amazon Q Developer	Duet AI for Google Cloud	GitHub Copilot

2024 年 12 月头部云服务商 AI 服务名称映射表

和所有技术栈一样，Gen AI 服务会根据用例需求组合不同组件，其部署选项覆盖从完全自管理、自托管硬件，到云厂商或第三方厂商提供的全托管 AI 服务等多种形式。

AI 服务总体说明

对于 FinOps 从业者而言，这些服务中的大部分可归入已在追踪的支出类别。以下是构成 Gen AI 系统的几类云服务，以及在 FinOps 实践中如何管理其成本的思路。

所使用的云服务类型

基础设施即服务（IaaS）

头部公有云厂商（如亚马逊云科技（AWS）、谷歌云（Google Cloud）、微软 Azure、甲骨文云）提供核心基础设施服务，通常包含计算实例、存储方案、网络及可观测性工具。此外，英伟达等专业厂商还会针对 AI 负载的 GPU 计算需求提供专属服务。

- 成本管理：核心成本驱动因素为计算时长、存储用量和数据传输。常见定价模式包括按需付费、GPU 容量预留、云市场订阅制套餐。理解用量对应的定价模型，是避免意外支出、实现有效成本追踪的关键。

AI 平台与托管服务

云服务商提供的托管服务可降低运维复杂度，例如用于机器学习模型训练的 Amazon SageMaker、用于生成式 AI 的 Amazon Bedrock、用于大语言模型的 Azure 认知服务、可支持各类生成式 AI 需求的谷歌云全托管 Vertex AI。

- 成本管理：托管服务的定价模型通常更复杂且动态，一般基于 API 调用次数、数据处理量或训练时长等指标计费。尽管其成本可能高于直接使用基础设施服务，但能显著节省时间与运维开销。

第三方软件 / 模型提供商

该类别包含提供专业 AI 工具、预训练模型及定制化解决方案的独立厂商，可满足特定业务需求。

- 成本管理：这类方案多基于许可协议、订阅模式甚至收入分成模式计费。企业需评估其总拥有成本（TCO），并与潜在投资回报率（ROI）对比，确保与业务目标对齐。

基于 API 的服务

许多 AI 提供商采用用量计费模式，便于按单位工作量或用量追踪成本。随着大语言模型等前沿 AI 技术兴起，定价常与生成令牌数、API 调用次数或处理时长等使用指标挂钩。

- 成本管理：计费通常与令牌处理量、API 请求量等具体用量单位绑定。对这些指标进行实时监控，是防止预算超支、优化资源利用率的关键。SKU 的持续迭代和资源级定价的动态变化，导致底层成本复杂度较高，需开展细致的追踪与分析。

混合云 / 多云 / 去中心化物理基础设施网络（DePIN）/ 本地服务器 / AI 终端

这类部署模式存在独特挑战与机遇，但不在本文讨论范围内，后续版本将纳入考量。

Gen AI 服务的用户角色

FinOps 实践需服务多类角色，包括工程、财务、管理层及采购人员。而 Gen AI 服务的使用者往往还会覆盖企业内更多利益相关方。理解这些用户角色，是制定贴合其需求与职责的定制化成本管理策略的核心。

由于 AI 服务相对较新且迭代迅速，同时部分角色此前未与 FinOps 团队协作过，也无需对成本和使用情况负责，因此 FinOps 团队可能需要投入更多时间为其提供支持。

在 Gen AI 系统场景下，FinOps 团队可能对接的角色包括：

数据科学家：负责模型开发与微调，需要大量计算资源开展训练、测试与评估。

数据工程师：负责数据管道的搭建与管理，确保数据清洁、规整且可用于 AI 模型训练。

软件工程师（自动化工程师、提示词工程师） ：将 AI 方案集成至应用，常通过 API 实现 AI 工作流自动化。

业务分析师：借助 AI 生成的洞察辅助决策、设计数据结构、保障仪表盘与报表的数据交互。

DevOps 工程师：负责基础设施管理，实现资源高效分配，保障自有 / 托管基础设施的系统性能。

产品经理：定义 AI 功能需求，监控其产品层面的表现与价值贡献。

管理层：制定企业 AI 落地目标、审批预算、明确 AI 项目的成功标准。

终端用户：通过办公生产力工具、SaaS 平台或具备预测与异常检测能力的仪表盘，使用 AI 增强型输出结果。

可能采用的定价模型

Gen AI 系统的定价模型种类繁多，部分与云服务定价相似，部分则接近 SaaS 定价模式。

定价范式	用量模式	成本模型	考量因素	示例
按需 / 按量付费	按需配置资源	按实际用量计费	为不可预测的 AI 负载提供灵活性；需密切监控成本（尤其是高令牌生成量或高 API 调用量模型）；适用于批量推理、临时模型训练等可变负载	OpenAI GPT API、Google Cloud AutoML、AWS SageMaker、云服务商按需 GPU 算力
预留实例与承诺用量折扣	长期用量承诺	承诺期内享折扣费率	主要适用于 AI 模型训练 / 推理所需的 GPU 密集型基础设施；适配可预测 AI 负载；需提前规划与负载分析，避免承诺资源利用率不足；通常可实现成本节约	合同条款、RI/SP 预留、承诺用量折扣（CUD）、优先级归因
预配置容量	长期用量承诺	预购固定容量区块	适配低延迟需求场景（如实时 AI 推荐、对话机器人）；无法随流量峰值动态扩缩，不适用于不可预测用量；若 AI 用量模式与预购容量不匹配，会导致利用率偏低	OpenAI Scale Tier、Azure OpenAI 服务预留 - 预配置吞吐量单元（PTU）
竞价实例 / 批量定价	批量 / 突发负载、测试 / 扩缩、利用闲置容量	费率优惠但可用性受限	适配可容忍中断的批量推理、模型重训练或突发负载；为非时效性 AI 负载（如定期模型更新、数据集预处理）带来显著成本节约；需搭建稳健的调度机制，避免中断影响业务结果	批量负载、突发负载、集群内按需 / 预留 / 竞价实例组合采购、竞价实例
订阅制	固定服务访问权限	定期费用（通常月付 / 年付）	简化稳定用量 AI 平台的预算编制（如预训练模型订阅、托管 AI 服务）；存在利用率不足导致的超支风险；通常包含高级功能	DataRobot 企业级 AI 平台、Hugging Face Model Hub（专业版）、IBM Watson Discovery
分级定价	基于用量的阶梯折扣	成本随用量区间浮动	利于 AI 方案的规模化拓展；需精准预测用量以避免意外成本；持续高用量场景下，阶梯折扣可降低成本	Google Cloud Dialogflow CX、Amazon Polly、Azure 文本分析 API
预览版 / 免费版 / 试用 / 有限使用的免费增值模式	试用 / 预览期折扣 + 基础服务免费、高级功能付费（通常与其他用量模型组合）	基础功能免费、高级功能 / 高用量计费（需注意预览期结束或正式版上线后的成本上涨）	支持在试用阶段开展 AI 服务测试；预览期结束后若用量快速增长，易产生意外成本；通常存在用量限制，可能制约大规模 AI 负载或数据集的测试	OpenAI GPT Playground、Hugging Face 推理 API（免费层）、RunwayML、Google Cloud Gemini、Amazon Nova、AWS 免费套餐

衡量 AI 的业务影响

尽管企业普遍认可 AI 的潜力，但多数组织在将 AI 能力转化为实际业务收益时面临阻碍。这一现状也得到了众多 FinOps 从业者和云 / AI 服务合作方的印证：许多企业对 AI 抱有热情，却不确定如何评估其实际效果，也难以证明持续投入的合理性。

随着 AI 从试验阶段迈向规模化落地，证明清晰的投资回报率（ROI）变得至关重要。为帮助企业充分释放技术潜力，本文构建了一套框架，聚焦六大战略优先级，助力企业管理者高效运用 AI 并量化其价值。

要有效捕捉 AI 的业务价值，需建立清晰的衡量与分析框架。首先要将 AI 举措与企业整体业务目标对齐，优先布局能在 “成本效率、韧性、用户体验、生产力、可持续性、业务增长” 六大核心价值支柱上产生显著影响的能力。

若要全面掌握 AI 的 ROI，不能仅关注成本节约，还需考量更广泛的业务价值驱动因素与 KPI，包括：提升运营韧性以优化服务质量与安全性；改善用户体验以提升客户满意度与营收；加速创新与缩短上市时间以提高生产力；通过资源优化实现可持续发展；最终通过增加线索量、转化率及新产品 / 服务研发实现业务增长。基于这六大支柱分析并衡量 AI 影响，企业才能对 AI 的真正价值形成全面、准确的认知。

管控 AI 服务的影响

有效管理 AI 模型成本，需审慎评估每个应用的具体需求与约束。切忌为所有任务都采用最复杂、最昂贵的模型，这往往会造成不必要的成本浪费。

相反，应根据具体场景与用途选择适配的模型，需综合考量所需的精度水平、数据可用性、计算资源及整体业务影响。

通过将模型与应用需求精准匹配，企业可优化 AI 投资、达成预期成果，同时避免产生无意义支出。

由此可形成成本与业务输出特征的拆解体系，如下图所示：

试想搭建一座塔楼：

地基不牢，便无法支撑多层建筑；

楼层结构脆弱，也无法建成高塔。

AI 领域亦是如此：

若数据（地基）质量低下，AI 模型（楼层）的准确性便无从谈起；

若为简单需求配置了过于复杂的模型，无异于 “小房子非要建摩天楼”。

企业需找到平衡：模型过小将无法满足需求，过大则会造成资源浪费。

针对生成式 AI 服务开展 FinOps 的最佳实践

入门与赋能

教育培训

从向团队普及 FinOps 与生成式 AI 概念入手，可基于《AI 成本白皮书（第一版、第二版）》及《云 AI 成本基础》图解开展基础培训。这些资料可帮助团队建立对 AI 在架构中角色，以及相关云资源类型的宏观认知。之后可逐步讲解不同部署类型与成本范式对应的具体成本表现，例如理解训练 GPT-4 等大语言模型的成本影响至关重要。可利用云服务商（AWS、Azure、Google Cloud）及 OpenAI 等行业头部机构提供的培训资源，同时参考 FinOps 基金会官网的 AI 成本管理指南。

利益相关方协作与 Gen AI 治理模型

对接数据科学家、机器学习工程师、IT 团队、采购、财务、产品经理、项目与变更控制经理、云解决方案架构师等核心利益相关方。定期召开会议，研讨运行大型生成式模型与小型微调模型的预算及成本影响，挖掘优化空间。保持与利益相关方的常态化沟通，提升 Gen AI 成本管理的认知度与效率。

工具与平台

投入资源部署可实现 AI 服务用量、质量、成本可视化的工具，融合软件可观测性原则，同时参考厂商中立与厂商专属工具建议。

- 云厂商工具：对 Amazon Bedrock 等托管 AI 服务，可使用 AWS Cost Explorer、谷歌云成本管理工具；Azure 环境下，可通过 OpenAI 利用率仪表盘（https://oai.azure.com/）洞察 GPT 成本与使用情况。

- 通用工具：可选用 Langfuse、Langsmith、OTEL 等第三方方案，获取精细化分析能力。

成本基线

通过分析历史账单与用量报告，建立 AI 相关支出基线，为制定切实可行的成本节约目标提供依据。例如，核算各项目下生成式模型的月度运行成本，明确成本起点。同时结合质量与预期业务成果，量化 AI 负载的用量与落地程度，确保基线既能反映当前表现，也能匹配对前沿功能的需求。需区分基础文本大语言模型等通用服务，与类人高级推理等高级工程需求 —— 二者的成本基准存在差异。

AI 功能基线

除成本外，需明确 AI 系统所需的基础功能，平衡响应时间、质量、准确性与可靠性目标 / 需求。对在用或备选 AI 模型的功能进行评估，尽可能采用量化指标，同时采集均值与峰值数据，例如模型需求量（平均 / 峰值请求量）、容量（单位时间最大请求数）、准确性（可靠回答占比、用户满意度、幻觉发生率）、可访问性及性能。该评估可全面呈现模型效能，为成本与性能优化决策提供支撑。

组织层面最佳实践与治理

跨职能协作

Gen AI 服务及应用的跨职能属性更强，影响范围远超传统 IT 系统。需促进管理层、数据科学、工程、财务、采购、产品管理等团队的协作，实现 AI 成本的全局化管理。推动各方就成本驱动因素，以及性能、准确性、成本效率的权衡关系达成共识。可通过定期工作坊或交流会，对齐利益相关方的优先级与决策流程，打破信息壁垒，确保成本管理工作与业务流程深度融合。

治理框架

建立覆盖合规、性能基准、成本阈值的治理框架，明确权责归属，实现成本的前瞻性管理。

- 清晰界定 AI 成本管理的角色与职责；

- 指定专人负责成本监控、预算预测、模型部署优化等工作；

- 可组建治理委员会或指导小组，统筹 AI 战略与成本相关决策，确保与企业目标对齐。

成本问责制

提升各团队与部门的 AI 支出认知，推行成本问责文化。可落地 “成本展示” 模式，向不同团队透明化其产生的成本 —— 该模式会按资源、项目或部门拆解成本，让利益相关方看到自身 AI 使用的财务影响，但不会像 “成本分摊” 模式那样直接计费。成本展示模式可作为有效的认知工具，推动团队主动优化用量、做出成本敏感型决策。长期来看，成本透明度的提升通常会带动行为转变，例如减少闲置资源、切换至更高效的部署模式。需定期分享包含用量模式、效率及优化空间的详细成本报告，借助仪表盘或分析平台让成本数据可获取、可落地，鼓励利益相关方主动挖掘优化机会。

预算编制与预测

在 FinOps 流程中嵌入反馈闭环，建立持续优化机制。定期复盘成本趋势、优化举措与业务成果，迭代优化策略。例如，分析历史部署的成本峰值后，制定可落地的政策避免类似问题复发。持续优化可确保 FinOps 实践随 AI 战略与技术同步演进。

培训与认知提升计划

为 Gen AI 利益相关方提供 FinOps 原则及 Gen AI 负载财务影响的持续培训，内容需覆盖成本驱动因素、优化技术与治理框架。赋能团队分析并应用成本与用量数据的能力，让成本与用量管理成为企业全员责任，而非局限于特定团队。

架构层面最佳实践

资源管理

利用自动扩缩、竞价实例等功能优化资源分配。例如，基于生成式模型 API 的实时需求，自动调整 GPU 实例数量；对可预测的长期部署，可评估预留实例方案以获取更低费率。高效的资源管理不仅能降低成本，还能保障 AI 负载的响应性与效率。

数据存储优化

根据数据访问模式与生命周期选择适配的存储方案。例如，将低频访问的训练数据集存储至 Amazon S3 Glacier、S3 低频访问存储或 Azure 归档存储等低成本冷存储；对高频访问数据集，则采用 SSD 块存储等高性能、低延迟存储。定期审核并迁移数据，避免为非必要的高级存储付费。可部署智能分层存储，自动实现数据分层与生命周期策略的优化。

模型优化

通过模型剪枝、量化、蒸馏等技术提升模型效率，在不显著损失准确性的前提下降低 AI 模型的计算需求。例如，可通过模型蒸馏技术，为 GPT-4、Claude 等大型生成式模型构建更轻量化、更快速的版本，用于生产环境部署。

无服务器架构

适用场景下，可采用无服务器架构部署 AI 负载，实现 “按实际使用的计算资源付费”。该模式对零星或不可预测负载（如处理低频 API 请求、试验性部署）尤为高效。例如，通过 AWS Lambda、Azure Functions、谷歌云函数等无服务器函数部署生成式文本模型，实现成本优化。对低用量用户场景、早期试验或短生命周期项目，可优先采用无服务器方案，在降低前期投入与运维开销的同时，实现小体量或临时负载的成本效益最大化。

推理优化

推理流程的优化是平衡性能与成本的关键，尤其在低延迟或高吞吐量 AI 应用场景中，核心策略包括：

- 实例类型多元化：根据负载需求选择实例，硬件加速推理可考虑 AWS Inferentia 或谷歌云 TPU。但需注意，若模型基于 NVIDIA CUDA 框架开发，AWS Inferentia 与谷歌云 TPU 无法原生支持 CUDA，需将模型转换为 TensorFlow、PyTorch 或 ONNX 等兼容框架；对重度依赖 NVIDIA 库的 CUDA 应用，继续使用 AWS 与谷歌云支持的 NVIDIA GPU 通常更高效。

- 边缘计算落地：对低延迟关键应用，可通过边缘计算将 AI 模型部署至靠近终端用户的节点，降低延迟，提升聊天机器人、预测分析等场景的实时性能。

- 非实时负载批量处理：对非实时负载（如批量预测、定期数据处理），可通过批量处理将多个推理请求合并为单次操作，大幅降低单请求成本。

- 框架适配：利用 GGUF、ONNX、OpenVINO、TensorRT 等框架，实现跨硬件平台的推理性能优化，在保障模型质量的同时提升资源利用率。

使用层面最佳实践

架构层面最佳实践聚焦 AI 部署的基础设施优化，成本优化策略侧重成本的规划与预测，而使用层面最佳实践则着眼于 AI 用量的实时管控，目标是监控、约束并优化用量，实现效率提升、浪费减少，确保资源与实际业务需求对齐。

用量模式监控

需定期监控 AI 资源使用情况，及时发现低效或闲置资源。以 GPU 任务为代表的 AI 负载，其用量往往存在不可预测性，易出现利用率不足问题。例如：

- 若 GPU 实例在特定时段（如非高峰时段）闲置，应关机或为其分配其他负载，可通过标签识别此类实例并实现自动化关机；

- 若推理需求在特定时段出现峰值，需调整自动扩缩策略，满足需求的同时避免过度配置。

- 工具选择：可使用 AWS CloudWatch、谷歌云监控、Azure Monitor 等云原生工具，或 Langsmith 等第三方工具，实现 AI 用量的精细化可视。

资源标记

搭建完善的标记策略，按项目、团队或特定 AI 负载对资源进行分类与追踪。标记不仅用于成本分摊，还能实现资源用量的可视化。例如：

以下为标记示例表：

标记键（标记 ID）	标记值
Project	AI_Model_Training
Project	Generative_Text_Inference
Project	Customer_Chatbot
Environment	Development
Environment	Testing
Environment	Production
Workload	Model_Training
Workload	Model_Inference
Workload	Batch_Inference
Team	Data_Science
Team	DevOps
Team	ML_Engineering
CostCenter	AI_Research
CostCenter	Marketing_AI
CostCenter	Product_AI
UsageType	GPU_Training
UsageType	API_Inference
UsageType	Data_Preprocessing
Purpose	Experimentation
Purpose	RealTime_Inference
Purpose	Batch_Processing
Criticality	High / Medium / Low
ShutdownEligible	True / False

完善的标记策略可保障用量可视，助力团队基于用量做出资源缩容或闲置资源关停等决策。

- 为模型训练与模型推理资源分别打标；

- 按环境打标（如 “环境” 标签的取值：开发、测试、生产），定位高消耗、高成本环节。

资源规格优化

持续确认 AI 负载运行的实例规格与类型是否适配，通过规格优化实现资源与负载需求的精准匹配。例如：

该方式可避免过度配置与利用率不足问题，二者是常见的资源浪费诱因。

- 对无需大型高价 GPU 的 AI 推理任务，可选用小型 GPU 实例；

- 对试验性负载或轻量级模型，可将 GPU 替换为 CPU 计算，无需 GPU 加速；

- 定期分析资源利用率指标，根据实际用量调整实例类型。

配置用量限制、限流与异常检测

为避免不必要成本与突发用量峰值，需配置用量限制、配额与限流机制，并结合异常检测工具，确保用量与预算对齐，防止因意外需求或配置错误导致成本失控。

通过用量限制、限流与异常检测的组合策略，企业可实现用量的可控、高效与预算对齐，既防止资源滥用，也能提前感知可能引发超支的异常用量趋势。

- 设置用量限制与配额：针对 API 计费服务，需设定严格的用量上限。例如，限制各团队 / 项目调用 OpenAI GPT 等大语言模型的 API 次数，管控令牌消耗；为训练任务设置 GPU 用量配额，防止超预算使用。

- 限流控成本：高峰时段若成本效率优先于性能，可对负载进行限流。例如，减少推理服务的请求处理量，避免系统过载与额外成本产生；对试验性或非核心负载实施速率限制，使资源消耗与既定优先级、预算对齐。

- 集成异常检测：结合用量限制与异常检测工具，前瞻性识别并处理异常用量模式。例如，为 GPU 使用时长或 API 调用量的突增设置告警（可能预示失控的训练任务或低效用量）；通过对比实际用量与历史基线，识别异常成本峰值（如令牌消耗翻倍且无合理解释时，需排查是否为提示词低效或应用逻辑错误所致）。

- 工具选择：可使用 AWS Cost Anomaly Detection、谷歌云异常检测等云原生工具，或第三方监控方案实现异常检测自动化，实现成本问题的快速响应。

优化基于 API 模型的令牌消耗

对 GPT API 等令牌计费模型，减少令牌用量可显著降低成本。可通过提示词工程优化 API 请求的提示词，例如：精简输入提示词并保留核心信息，避免令牌浪费；对高频 API 响应进行缓存，减少重复调用。追踪令牌消耗可定位优化空间，保障服务的高效使用。

成本优化最佳实践

AI 成本的有效管理，需结合传统 FinOps 方法与 AI 专属考量，以下为核心优化实践，可在保障性能与创新的同时实现支出优化。

承诺用量管理

利用预留实例与承诺方案，获取相比按需定价的显著折扣，需结合用量模式制定容量预留决策：

- GPU 容量预留：若训练或推理负载可预测，可承诺 GPU 容量预留；

- 云费率优化与厂商折扣：挖掘 AI 专属采购承诺（如 OpenAI Scale Tier 的预付费 API 用量折扣），并定期关注厂商新优惠（AI 定价模型迭代快，常存在成本节约机会，例如 Azure 在 2024 年 12 月前仅支持年付预配置吞吐量单元（PTU），后新增月付选项）；

- 承诺折扣：分析用量模式，判断预留实例、节约计划或承诺用量折扣（CUD）是否能实现比按需定价更优的成本，例如若计划长期使用 GPU 实例开展模型训练，可承诺 1 年期预留。承诺折扣可覆盖更广的实例类型或服务，灵活性更高，尤其适用于 GPU 需求不明确或负载会演进的场景。

数据传输成本优化

通过将数据与计算资源部署在同一云地域、使用内容分发网络（CDN），降低数据传输支出。例如，确保训练数据集与 GPU 实例同地域部署，避免跨地域传输费用；对低延迟推理负载，可通过 CDN 优化数据分发。

前瞻性成本监控与审核

定期审核账单，及早发现异常或意外支出。例如，为生成式 AI 服务的高额支出配置告警，实现问题的即时排查。

随着 AI 领域的演进，FinOps 从业者需保持敏捷性，把握新兴成本节约机会，确保 AI/ML 投资实现价值最大化与竞争优势提升。

运维层面最佳实践 —— 面向工程师 / 机器学习运维角色

AI/ML 模型生命周期、性能与效率的有效管理，需依托运维层面最佳实践实现部署、监控与持续优化的流程化。部分实践无需 FinOps 团队直接执行，但可作为成本与用量管理要点，协同工程与运维团队落地。

持续集成 / 持续部署（CI/CD）

搭建专为 AI/ML 工作流设计的 CI/CD 流水线，实现模型交付的自动化与提速。与传统软件 CI/CD 不同，AI 工作流需额外增加数据验证、模型重训练、性能基准测试等步骤。例如，通过 Jenkins、GitLab CI 或 Amazon SageMaker Pipelines、Azure ML 等云原生服务，实现模型更新的自动化部署；在模型上线前，增加准确性与资源消耗的校验节点。

- 核心建议：自动化部署可降低运维开销，同时保障模型更新的一致性、可靠性与成本效益。

CI/CD 中集成持续训练

持续训练（CT）是指基于新数据自动重训练 AI 模型，确保其准确性与相关性的流程。从 FinOps 视角，持续训练可通过自动化重训练保障模型精度，同时避免人工干预带来的成本浪费，核心实践包括：

- 成本触发式重训练：监控数据漂移或性能衰减，仅在必要时启动模型重训练，降低不必要的计算成本，例如通过 AWS Lambda 或 Azure Event Grid，基于预设阈值触发训练工作流；

- 训练阶段资源优化：对非核心重训练任务，可利用竞价实例或抢占式虚拟机，大幅降低计算成本；

- 选择性模型部署：在部署前，基于推理成本、训练成本效率等财务指标评估重训练模型，仅当性能提升的收益能覆盖额外成本时，才将模型投入生产。

模型生命周期管理

对 AI 模型的全生命周期（从开发、部署、监控到退役）进行主动管理：归档或删除老旧、低效或闲置模型，释放存储与计算资源；定期审计已部署模型，识别过时用例下的无用模型。

- 示例：定期审核模型利用率指标，删除失效模型以降低存储成本。

- 核心建议：将模型管理视为结构化流程，集成自动化生命周期工具，实现成本效益与运维整洁度的统一。

性能监控

生成式 AI 模型需持续监控，确保在成本可控的前提下达成性能目标，需聚焦影响质量与资源消耗的核心指标：推理延迟（保障 AI 服务的用户体验）、资源利用率（识别 GPU/CPU 资源的低效使用）、准确性指标（追踪预测精度与数据漂移）。可通过 Prometheus、Grafana 或 Amazon CloudWatch、谷歌云监控等云原生工具实现自动化追踪。

- 核心建议：为性能或效率偏差（如延迟增加、资源利用率不足）配置告警，实现问题的前瞻性处理。

反馈闭环

建立运维、开发与终端用户间的清晰反馈闭环，实现模型性能、效率与业务影响的迭代优化。该流程可确保 AI 模型适配实际使用模式：收集终端用户反馈，定位已部署模型的响应质量差等问题；基于运维洞察开展模型重训练或微调，兼顾准确性与成本优化。

- 示例：对聊天机器人模型，可监控用户满意度并定位高成本提示词 / 响应，实现令牌用量优化与成本效率提升。

渐进式构建：AI 成本管理的 “爬、走、跑” 阶段

由于 AI 相关举措相对较新且风险高于传统数字化方案，需将其划分为不同阶段，各阶段对应差异化的成本管理策略，可通过经典的 “爬、走、跑” 理念来阐释。

阶段	可开展的工作	成本管理策略	工具特性
爬	新技术学习、验证技术在业务流程中应用的可行性与合理性、原型开发、最小可行产品（MVP）研发、试点项目落地、收集反馈并验证用例	1. 投入最低限度成本，覆盖技术调研、原型 / MVP 设计，必要时可在隔离环境（测试链路或生产业务流程的小范围场景）部署；2. 采用 “快速试错” 策略，确保以最低成本快速获取阶段成果，及时调整风险；3. 提前设定成本与时间上限并监控达标情况；4. 高不确定性与风险场景下，不可忽视待验证环节的成本（如模型精度为关键风险点时，需在该阶段投入成本保障模型质量）；5. 可精简其他非关键成本（如服务可用性可预测时，可降低该环节的验证成本）	1. 成本核算以手动为主；2. 预算需频繁调整；3. 成本与成果的衡量中，非财务指标（耗时、假设验证成功、工件 / 组件就绪等）占主导
走	将方案集成至业务流程、实现方案的常态化正向输出	1. 合理投入成本，将方案落地至简单业务流程（通常为 “爬” 阶段已验证的用例），仅保障日常使用所需的最低非功能需求；2. 相比 “爬” 阶段，将生产部署、集成、可用性相关成本控制在业务流程常态化运行所需的最低水平；3. 严控非功能需求超标的成本（如过度扩缩、过度可用）；4. 新增功能时仍沿用 “快速试错” 策略；5. 严格管控集成成本；6. 预算可拆分（如分为系统运维预算与版本发布预算）	1. 引入基础的成本追踪自动化能力；2. 实现基础的异常分析；3. 财务指标的重要性提升；4. 预算调整频率降低
跑	依托 AI 支撑核心业务流程	1. 总成本需与 AI 模型带来的业务收益匹配，不得低于基准水平；2. 持续监控成本并挖掘优化空间，同时需保障非功能需求（NFR）达标（成本优化的首要前提是不降低约定的需求标准）；3. 优先优化无价值成本（既不满足当前需求，也无未来价值）；4. 若成本优化涉及模型功能或非功能特性的缩减（即使仍高于最低约定标准），需通过架构权衡评估节约收益与潜在负面影响；5. 集成成本优先级提升，优化空间收窄；6. 预算按组件的拆分粒度进一步细化	1. 实现成本追踪全自动化；2. 具备高级异常追踪能力；3. 综合财务指标（如 AI 模型整体 ROI）的重要性凸显；4. 预算趋于稳定

关键绩效指标（KPI）与度量指标

工程团队运维的 Gen AI 系统，其 KPI 与传统负载存在一定共性，但同时也需要专属 KPI 来衡量 AI 资源的使用效能或 Gen AI 系统的构建成效。以下为结合 AI 与 FinOps 术语的 KPI，可用于衡量企业各 Gen AI 系统的目标达成情况。

单次推理成本

- 衡量对象：AI 模型处理单次输入并生成输出（即单次推理）产生的成本，适用于聊天机器人、推荐引擎、图像识别等场景。

- 核心意义：追踪已部署 AI 模型的运维效率（尤其高并发场景），助力资源分配优化与低效代码 / 基础设施的成本峰值定位。

- 计算方式：公式为单次推理成本 = 推理总成本 / 推理请求总数；数据来源为云账单数据、OpenAI/Vertex AI 等 AI 平台日志。

- 示例：若推理总成本为 5000 美元，处理推理请求 10 万次，则单次推理成本为 0.05 美元 / 次。

训练成本效率

- 衡量对象：机器学习模型的训练总成本与模型性能指标（如准确率、精确率）的比值。

- 核心意义：GPT 等大型 AI 模型的训练成本高昂，该指标可确保资源的成本效益，同时保障性能达标。

- 计算方式：公式为训练成本效率 = 训练成本 / 性能指标（如准确率） 。

- 示例：若准确率 95% 的模型训练成本为 1 万美元，则其成本效率为每 1% 准确率对应 105 美元。

令牌消耗指标

- 衡量对象：OpenAI GPT 等令牌计费模型，基于输入 / 输出令牌用量的成本。

- 核心意义：可预测并管控大语言模型的令牌计费成本，助力提示词工程优化，在不降低输出质量的前提下减少令牌消耗。

- 计算方式：公式为单令牌成本 = 总成本 / 令牌使用量；工具为 API 用量报告、厂商仪表盘。

- 示例：若推理总成本 2500 美元，处理令牌量 100 万，则单令牌成本为 0.0025 美元 / 个。

- 优化建议：对重复提示词与响应实施缓存策略。

资源利用率

- 衡量对象：AI 训练与推理阶段，GPU、TPU 等硬件资源的使用效率。

- 核心意义：识别资源的过度配置或利用率不足问题，实现成本节约，同时追踪自动扩缩机制的效能。

- 计算方式：公式为资源利用率 = 实际资源使用量 / 已配置容量。

- 示例：若实际 GPU 使用时长为 800 小时，已配置容量为 1000 小时，则资源利用率为 80%。

异常检测率

- 衡量对象：AI 支出异常（如突发成本峰值、意外用量模式）的发生频率与成本影响。

- 核心意义：可前瞻性识别并遏制失控成本。

- 计算方式：可通过 AWS Cost Anomaly Detection、谷歌云异常检测等工具，基于历史趋势识别异常值。

AI 举措投资回报率（ROI）/ 价值

- 衡量对象：AI 举措产生的财务或价值回报与成本的比值。

- 核心意义：可验证 AI 服务的投资合理性，确保与业务成果对齐。

- 计算方式：公式为ROI=（财务收益 - 成本）/ 成本 ×100% 。

- 示例：若 AI 项目财务收益 5 万美元，总成本 2 万美元，则 ROI 为 150%。

单次 API 调用成本

- 衡量对象：调用 AI 服务的平均单次 API 成本。

- 核心意义：追踪 Amazon SageMaker、谷歌 Vertex AI 等托管 AI 服务的使用效率。

- 计算方式：公式为单次 API 调用成本 = API 总成本 / API 调用次数。

- 示例：若 API 总成本 1200 美元，调用次数 24 万，则单次 API 调用成本为 0.005 美元 / 次。

业务价值达成周期

- 衡量对象：AI 举措从启动到产生可量化业务价值的时长，即 AI 实现某功能与其他方式（如人工）的 “盈亏平衡点”。

- 核心意义：可对比业务价值达成的预期周期与实际周期，理解机会成本与月度价值。

- 示例：若预期 1 个月内实现月均 10 万美元业务价值，但实际耗时 5 个月且仅达成月均 5 万美元，则需将 5 个月作为业务价值达成周期指标并推动优化。

- 计算方式：公式为业务价值达成周期（天）=AI 服务总价值 / 替代方案的日成本。

- 示例：若 AI 举措 2024 年 1 月 1 日启动，4 月 1 日完成模型部署，则业务价值达成周期为 3 个月。

首次提示词响应周期（研发敏捷性）

- 衡量对象：服务从启动研发到实现首次可用的工程耗时，或从概念验证（POC）/ 试验到生产可用的周期。

- 核心意义：成熟的 AI 模式与工具自动化可提升工程师的功能交付效率，该指标可衡量工程师将想法转化为生产级用户需求交付物的速度；同时可体现不同服务开发方式在推理就绪环节的权衡，通常需平衡精度（质量）与成本。

- 计算方式：公式为首次提示词响应周期 = 部署日期 - 研发启动日期。

- 示例：若 AI 举措 2024 年 1 月 1 日启动，4 月 1 日完成模型部署，则首次提示词响应周期为 3 个月。

大语言模型选型质量得分需求与现状偏差

- 衡量对象：提示词需求（复杂度、质量等）的基准得分，与所选模型实际能力的匹配度。

- 示例：若仅需判断文本情感（“文本为正面还是负面？”），仅需 MMLU 质量得分为 54 的模型，此时需衡量在用模型的 MMLU 得分，以及需求质量与所选模型的差值（可参考 MMLU 排名）。

- 核心意义：若用高成本的高质量模型处理低难度提示词，会造成资源浪费。

- 计算方式：先明确任务所需的最低 MMLU 质量得分，再获取在用模型的 MMLU 得分，最终核算所选模型与最优模型的成本差值。

监管与合规考量

生成式 AI 领域 FinOps 管理的监管与合规考量，是实现成本管理与法律、伦理标准对齐的关键。鉴于 AI 的快速演进与跨行业落地，理解这些考量可在保障财务效率的同时，降低不合规风险。

数据隐私法规

- 概述：AI 服务常处理训练与推理阶段的敏感数据，欧盟《通用数据保护条例》（GDPR）、美国《加州消费者隐私法案》（CCPA）等全球各地的法规，对数据收集、处理、存储提出了严格要求。

- 成本影响：合规需求可能需要额外投入加密、匿名化、数据脱敏、监控工具，增加基础设施成本；不合规可能面临高额罚款，需纳入预算考量。

- 生成式 AI 领域特殊权衡：生成式 AI 模型存在 “黑箱” 特性，且个人身份信息（PII）会直接影响输出质量，因此该领域的隐私 - 质量 - 成本平衡方案，通常成本高昂且技术实现难度大。

- FinOps 从业者核心考量：评估数据驻留要求，避免跨境数据传输罚款；利用 AWS Artifact、Azure Purview、谷歌云 DLP 等云厂商工具开展合规监控；为处理敏感数据的资源配置专属标记。

知识产权（IP）与许可

- 概述：生成式 AI 模型可能使用受许可限制或需付费的预训练模型 / 数据集。

- 成本影响：专有数据集或第三方预训练模型的许可费用可能较高；若误用受版权保护的数据或模型，会引发法律责任与意外支出。

- FinOps 从业者核心考量：在 FinOps 仪表盘中追踪许可条款与相关成本；监控模型使用情况，确保符合许可协议；协同法务团队审核第三方 AI 服务合同。

AI 偏见与伦理合规

- 概述：多国已出台法规规范 AI 偏见、公平性与伦理使用，要求企业为 AI 系统搭建审计与治理框架。

- 成本影响：偏见审计与修正可能需要额外的模型重训练或资源投入，推高成本；合规需求可能需要采购第三方偏见检测工具。

- FinOps 从业者核心考量：将定期 AI 偏见审计成本纳入预算；协同工程团队构建符合法规的可解释性 AI 模型；利用 IBM AI Fairness 360 等工具评估并缓解模型偏见。

行业专属法规

- 概述：医疗、金融、政府等行业需遵循专属法规（如医疗行业的 HIPAA、金融行业的 FINRA），对 AI 系统的使用进行约束。

- 成本影响：合规需求可能强制要求特定加密等级、存储方案或审计链路，增加运维成本；AI 系统常需通过认证流程，耗时且成本高昂。

- FinOps 从业者核心考量：协同合规团队，将 AI 负载映射至法规要求；针对本地法规配置地域专属架构（如美国政府负载可使用 AWS GovCloud）；为合规所需的认证 / 审计预留预算。

数据留存政策

- 概述：法规可能要求企业为审计目的，留存特定周期的训练与推理数据。

- 成本影响：大规模数据集的长期存储成本较高，需通过高效归档方案平衡合规与成本。

- FinOps 从业者核心考量：采用 AWS Glacier、谷歌归档存储等低成本冷存储方案保存归档数据；为数据集配置留存策略标记，实现成本自动化追踪；定期审核存储数据，清理非必要数据集。

环境法规

- 概述：大型模型训练等 AI 负载能耗较高，部分地区已强制要求数据中心开展碳足迹报告或遵循能效标准。

- 成本影响：投入高能效硬件或可再生能源额度会增加成本，但可助力合规；碳排放量追踪可能需要专用工具。

- FinOps 从业者核心考量：利用云厂商原生或第三方碳报告工具；将碳抵消成本纳入 AI 项目总支出；优化负载以减少非必要能耗；在能源碳排放强度最低的地域部署负载（可参考https://app.electricitymaps.com/）。

新兴 AI 专属法规

- 概述：各国正出台 AI 专属法规（如欧盟《人工智能法案》），基于风险等级对 AI 系统分类并提出合规要求。

- 成本影响：医疗 AI 等高风险类别，需满足更严格的合规要求，推高成本；法规的频繁更新需企业持续监控并调整，增加适配成本。

- FinOps 从业者核心考量：跟踪核心市场的 AI 法规动态；为新兴法规的合规需求预留预算（包括风险评估与模型文档编制）。

AI 范围与 FinOps 框架的映射

要理解 AI 应用给 FinOps 实践带来的变化，需明确 AI 成本管理中差异显著的核心能力。

能力维度	与非 AI 技术的共性	AI 技术的独特性
数据接入	1. 数据采购、清洗、转换的组织流程基本一致；2. 多数操作的技术工具通用；3. 云市场或云厂商直采服务的成本，已自动纳入云账单实现数据接入	1. 数据来源选择的不确定性更高，对技能与人力要求提升；2. 数据接入的成本效益评估难度显著增加；3. 第三方提供商类型更多样；4. 对厂商数据质量的预判不确定性更强
成本分摊	1. 标记的通用原则一致；2. 核心利益相关方相同；3. 底层基础设施的分摊逻辑相似	1. 模型输出使用者的定位难度加剧（如同一模型可能支撑同一应用内的 “技术支持聊天机器人”“新客聊天机器人” 等不同模块）；2. 架构复杂度提升，新增多层级结构，可追溯性进一步降低；3. 多智能体负载的成本分摊缺乏通用框架；4. 厂商账单信息的不统一 / 不完整，会进一步增加分摊复杂度
报告与分析	分析工程与报表构建的流程、工具通用	1. 需定制包含 AI 负载专属指标的报表形式；2. 需新增数据结构，实现多维度成本追踪并关联业务输出；3. 关注报表的利益相关方范围扩大（RACI 矩阵中的 “知情” 环节）
异常管理	1. 异常管理的通用方法论一致；2. 异常追踪与阈值设定的底层算法通用	1. 异常的风险更高，需投入更多关注；2. 异常管理流程的执行频率提升；3. 成本波动性更高，异常判定标准的制定难度加大
规划与估算	规划与估算的原则、流程通用	1. 需区分模型的 “有效” 输出与 “无效” 输出（如无关响应、幻觉），该任务较新且工作量大；2. 估算质量与精度阈值，并基于 TCO 选择最优 AI 模型的难度较高；3. 缺乏模型无效输出的估算基准；4. 工具迭代速度快且类型繁多
预测	1. 传统云技术的 FinOps 预测实践，可作为 AI 成本预测的基础；2. 核心利益相关方相同；3. 基础的基于数学近似的方法通用	1. 预测的可确定性整体偏低（尤其 “爬”“走” 阶段），需更丰富的经验支撑；2. 第三方服务商的定价与实际用量评估复杂度高且一致性低（如令牌计费模式）；3. 云与非云 AI 支出预测、不同成本组件预测的整合难度大；4. 成本波动性高，趋势化预测的难度增加；5. 预测的更新频率需提升
预算编制	1. 预算流程的权责划分原则通用；2. 高层级预算报表的编制原则基本一致；3. 核心利益相关方相同	1. 基于总美元成本的 “自上而下” 预算编制，因厂商定价的异构性与波动性，准确性受限；2. “自下而上” 预算编制的工作量极大，需为每个组件单独估算成本，同时适配特定厂商的定价特性；3. 试点新 AI 项目时，因用量不可预测，需投入更多精力管理利益相关方并采用弹性预算；4. 预算调整频率需提升；5. AI 使用的利益相关方分布广泛，AI 服务的损益责任难以界定
基准对比	1. 除令牌相关指标外，高层级业务价值指标（客户满意度、成本、性能）通用；2. 核心利益相关方相同	1. 新增大量专属基准指标（以令牌相关指标为主）；2. 外部基准较少且一致性低；3. 企业内部 AI 项目的独特性强，内部基准的构建难度大
单位经济效益	1. 单位经济效益核算的宏观方法论通用；2. 核心利益相关方相同	1. 新增令牌相关的核算单位与驱动因素；2. 除通用指标外，可新增负载与价值类专属指标（如客服 AI 的单次通话成本、问题解决时长、AI 成本分摊后的客户满意度）
费率优化	1. 厂商管理的经典通用原则依然适用；2. 核心利益相关方相同	1. 需考量的影响因素数量多且权重差异大（包括资源稀缺性、承诺用量等）；2. 方法论的动态性更强（如 OpenAI Scale Tier 等厂商定价模型会持续调整）
负载优化	1. 利益相关方与核心流程通用；2. 优先级排序的方法论通用；3. 多数负载追踪工具通用	1. 流程监控需更精细且频繁，人力投入更高；2. 市场波动性强，需提前锁定用量（如预采购、容量预留）
许可与 SaaS	利益相关方通用	1. 新厂商与新服务的出现，会增加传统仅使用简单云服务企业的协作流程复杂度；2. 订阅管理流程的动态性提升
云架构设计	1. 多数基础架构通用（如容器编排、API 管理、负载均衡等）；2. 已落地微服务架构的企业，其设计思路可复用至 AI 应用	1. 新增模型训练等工程环节；2. 云厂商提供大量 AI 专属服务，需组合使用；3. AI 专属工具与通用工具的选型难度提升；4. 对微服务架构的落地要求更高
云可持续性	1. 基础理念通用；2. 治理机制通用；3. 核心利益相关方相同	1. 单请求环境影响的关注度提升；2. 闲置容量的关注度提升，企业会在无可靠高性能预测时，尽量减少长期承诺（即使早期采用无服务器架构）
FinOps 实践运营	流程、利益相关方、沟通机制等核心要素通用	1. 可能新增 FinOps 团队不熟悉（或不熟悉 FinOps）的利益相关方；2. 对各相关团队的 FinOps 实践落地要求提升，需实现企业去中心化业务流程的端到端覆盖
FinOps 教育与赋能	核心利益相关方与流程通用	1. 需补充适配多种部署方案与定价模型的新知识；2. 对赋能引导的要求提升
云政策与治理	1. 核心利益相关方相同；2. 成熟治理体系的关键特性依然必要且通用；3. 核心法规持续适用	1. 需大规模落地配额、预留容量、限流等多重限制；2. 对试点与试验性项目，可能需要放宽部分传统云项目的既有法规
FinOps 工具与服务	基础工具依然适用	1. 需新增架构组件级的专属追踪工具；2. 工具迭代频繁，且工具间的集成难度提升
信息安全	1. 所有传统信息安全需求依然有效；2. 传统技术的安全要求，需全面覆盖至 AI 技术；3. 传统技术手段仍适用（如数据加密、数据匿名化等）	1. 模型自训练阶段的敏感内容传输，存在额外专属风险；2. 向第三方现成模型传输敏感信息，存在额外风险；3. AI 生成信息的精度不足，存在额外风险；4. 安全技术手段需拓展（如进阶的上下文匿名化方案）

致谢

感谢以下人员对本文的贡献：

Brent Eubanks（Wayfair）、James Barney（MetLife）、Eric Lam（Google）、Max Audet（COVEO）、Joshua Collier（Superhuman 前身为 Grammarly）、Ermanno Attardo（Trilogy）、Jean Latiere（Sanofi）、Borja Martinez（NTT Data）、Ilia Semenov（Stealth）、Janine Pickard-Green（MagicOrange）、Haritza Zubillaga（Roche）、Rahul Kalva（Wells Fargo）、JJ Sharma（KPMG）、Andrew Qu（Everest Systems）、Thiago Mozart（RealCloud）、Bhaskar Bhowmik（Accenture）、Dilli B（Munich Re）、Andy Paneof（KT）、Adam Richter（Amazon Web Services）、Karl Hayberg（EY）

最后更新时间：2025 年 10 月 3 日

FinOps for AI 概述

摘要

目录