AI 时代的 FinOps：工作流、RAG、AI Agent 与 Agentic AI 指南

MofCloud
FinOps
05 Dec, 2025

一位兼具 FinOps 思维的 CPO，正在让创新与成本效率保持平衡

人工智能正在重塑产品构建方式，但它也带来了新的成本复杂性 —— 即便是经验丰富的云团队也可能被它打得措手不及。

炫酷的 AI 功能”必须和“云预算”保持沟通。

从 FinOps 视角拆解四类快速演进的 AI 架构：

LLM Workflows（大模型工作流）
RAG（检索增强生成）
AI Agents（AI 代理）
Agentic AI（自治式智能系统）

对每类架构，我们会逐一分析：

核心技术组件
这些组件如何影响云成本
控制支出的 FinOps 原则
AWS/GCP/Azure 实践建议
如何评估 ROI，让效率最大化、意外最小化

Part 1：LLM 工作流 — 最直观、最“聊天式”的模型

架构概览

LLM 工作流是所有 AI 架构中最简单的一类：输入一个提示（prompt），得到一个模型生成的回答。典型场景包括基础的问答机器人、文本摘要工具、代码助手等。

技术组件也非常精简：

核心就是 LLM 本身（可能是调用 OpenAI 之类的 API，也可能是自托管模型）；
少量 Prompt Engineering（系统提示、few-shot 示例等）；
通常没有长期记忆，也没有外部工具调用。

LLM 看到输入 → 根据训练知识生成结果 → 返回给你。流程简单明了。

成本驱动因素

别被它的简单骗了 —— 花钱的地方可一点不少。

LLM 工作流的主要成本是 推理费用（inference cost）

大多数 API 按 输入/输出 token 数量计费，所以提示越长、回答越啰嗦，花的钱越多。
如果你自托管模型，则成本来自 GPU/CPU 计算 和 高性能实例的租用费。
大模型（如 GPT-4 级别）远比小模型贵，模型大小对成本影响巨大。
还可能有 AWS Lambda/容器等外围基础设施的费用。

一句话总结：

在 LLM 工作流中，账单上最大的一行通常就是“处理了多少 tokens”。

小技巧：

FinOps Foundation 的调研指出，只要在提示里加一句 “be concise”，平均可以减少 15–25% 的 token 用量（和费用）。

FinOps 原则实战：给最简单的 LLM 也做成本治理

即便是一个简单的 LLM 服务，也需要 FinOps 的三大基石：

1. Visibility（可视化）

让工程师和产品团队 清楚看到每一次模型调用的成本。

操作示例：

使用 OpenAI/Azure OpenAI 的用量报表，做成每日/每周的成本图表。
如果是自托管模型，监控 GPU 利用率与每次请求的 token 数。
将成本展示成“每 1000 次请求的费用”“每个用户会话的费用”。

开发者一看到“这个 prompt 改动让 token 翻倍了”，自然会更注意。

2. Allocation（分摊与归属）

将 LLM 使用量按团队或功能拆分 —— 谁用的，谁承担。

做法：

为不同服务/团队使用不同的 API Key 或 Metadata。
AWS Bedrock 等服务支持为调用加 Tag（例如：Project=MarketingAI）。
这样你可以做 showback/chargeback，避免月底出现“谁把 AI 用了 $10k？！”的大型互相甩锅。

3. Optimization（优化）

优化 LLM 使用方式，在 不影响输出质量 的前提下降低成本。

关键技巧包括：

模型选型（Right-sizing）：不是所有请求都需要最大的模型。90% 的查询也许用中型模型就够。
提示压缩（Prompt brevity）：减少示例、减少无用话、总结历史对话。
缓存（Caching）：重复请求的结果直接返回，不再调用模型。
限流（Rate limiting）：防止 bug 或用户滥用导致成本爆炸。
分析最贵的 prompt：重点优化那 20% 的请求，它们可能贡献 80% 的 token 消耗。

作为有 FinOps 思维的产品人，建议经常深入 prompt 设计，找潜在的节省空间。

云上部署的最佳实践（AWS/GCP/Azure）

1. Serverless 适合波动性大、使用不连续的场景

例如：

AWS Lambda
GCP Cloud Functions / Cloud Run
Azure Functions

按调用付费，避免 24/7 的实例闲置成本。
缺点：冷启动会增加延迟，用户侧应用可考虑“预热”策略。

2. 正确选择 GPU（自托管模型）

例如：

AWS Inf2（Inferentia2）更适合便宜推理
Spot 实例适合非关键的 batch 推理任务
GCP 则可对比 TPU 与 GPU 的性价比

务必避免 GPU 长期闲置 —— 那是最烧钱的浪费。

3. 小心使用托管服务（SageMaker / Azure OpenAI / Vertex AI）

托管服务有自动扩缩优势，但价格未必最低。
如果可以“scale-to-zero”，一定打开 —— 空闲时不付费最重要。

4. 控制数据传输成本

跨云、跨区域调用外部 API 会产生额外的流量费用。
尽量让调用端靠近模型所在区域。

5. 监控与预算告警

使用各云的预算工具设置：

“今天花钱超过 X”的告警
“本月支出可能超过预算”的预测告警

这是防止意外账单的最后安全带。

如何衡量 ROI 和效率

我们必须证明这个 LLM 工作流是否“值回票价”。

定义“单位价值”

例如：

每次对话成本
每份文档摘要成本
每个用户会话成本

如果一个 AI 客服对话成本 $0.02，而用户满意度与人工相当，那就 物超所值。

持续追踪效率趋势

例如：

在优化 prompt 后，请求的平均 token 成本下降 20%
这就是实际省下的钱，应当作为效率指标记录下来

我们常用的指标包括： tokens per user session
目标：保持平稳或下降。

避免虚假“成功”

“AI 已处理 100 万次请求” 不说明价值。
关键问题是：

这些请求是否产生了超过 $1000 的价值（如果成本是 $1000）？

FinOps 就是要不断把成本与业务结果关联起来。

随规模变化持续优化

LLM 工作流通常成本随使用线性增长，但也可能出现：

prompt 越用越长
用户问题越来越复杂

如果发现平均成本上升，要马上检查。

FinOps Foundation 研究显示：

未经优化的 AI 部署与优化后的成本差异可达 30x–200x。

做好 FinOps，可以用 零头级别的成本实现原本同等的 AI 价值。

Part 2：检索增强生成（RAG）— 为 LLM 配备一个“知识副驾”

架构概览：

检索增强生成（RAG）就像给你的 LLM 配了一张专属的“图书证”。在 RAG 架构中，系统可以检索外部信息（文档、数据库条目、网页结果等），并将其输入 LLM，以确保回答更加可靠。技术上，这引入了几个新的组件：

Embedding 模型与向量数据库（或其他检索系统） 用于存储和查询相关信息。你的数据（如公司知识库或文档）会被转换成数值向量，并索引在向量数据库中。
检索步骤 在用户查询后，通过相似度搜索找到最相关的文本片段并返回。
LLM 仍负责生成最终答案，但现在其提示词中包含了检索到的文本（通常作为上下文或参考材料）。
可选的编排逻辑 负责将这些步骤串联起来：接收用户查询 → 执行检索 → 组装 LLM 提示词（可能包含诸如“根据以下信息回答”的系统提示）→ 获取回答 → 以及可选的引用标注。

总结来说，RAG 架构让 LLM 具备“开卷”能力——在生成回答时可以实时查阅资料。这能够显著提升准确性，并允许使用更小的模型（因为事实记忆的重负被转移给知识库）。一个常见示例是企业内部的政策问答机器人：RAG 会从数据库中取出相关政策片段，LLM 再将其组织成自然语言答案。

RAG 架构示例工作流：

文档会被切分成 chunks 并生成 embeddings 存入向量数据库；查询时系统检索相关 chunks 并将其作为上下文提供给 LLM。流程通常包括文档检索、上下文生成、LLM 响应和评估等阶段。RAG 在实践中只向 LLM 提供最相关的信息，以优化准确性并控制提示词长度。

成本影响：RAG 带来了新的成本来源

使用 RAG 后，成本不再只来自 LLM 推理本身，还包括：

1. 向量数据库存储

文档和文本片段需要存储。如果使用托管服务（Pinecone、Weaviate Cloud、Azure Cognitive Search 等），需要支付存储和读写费用；自建服务则需支付 VM / 容器与存储成本。大量 embedding（即便只是浮点数）也可能累积到 GB 级别。

2. Embedding 生成

将文本转换成 embedding 需要调用 embedding 模型。例如 10 万份文档就意味着 10 万次 embedding 调用。用户每次查询也可能需要 embedding，因此形成持续成本。若你有每月百万级查询，即便每次 embedding 只需几分钱，也会累积成千上万的费用。

3. 检索开销

查询向量数据库也可能有费用（尤其在托管服务中），包括按查询量计费或计算资源消耗。即便自托管，也存在 CPU 成本。

4. 提示词变长（上下文注入）

检索内容会加入提示词，使输入 token 变多，LLM 推理成本上升。例如一个 300 字片段会增加几百个 token 的输入成本。

5. 编排开销

如果使用云函数、Step Functions 等进行多步骤编排，步骤执行也有费用（如 Step Functions 收取状态转换费用）。

6. 数据传输

跨区域或跨云传输 embedding、检索结果等可能产生额外流量成本。

在不少团队中，RAG 的引入是为了降低 LLM 推理成本或提升准确性，但他们常常忘记 embedding、向量数据库等成本。FinOps 的核心是：比较“RAG 总成本”与“不使用 RAG”的差异。

RAG 的 FinOps 原则

与一般 FinOps 原则一致，但有一些特定关注点：

1. 可见性

将整个 RAG 管道成本分解为：

LLM 推理成本
Embedding 成本
向量数据库成本
检索与编排成本

这样才能在成本异常时找到真正的暴涨来源。

2. 分摊

如果多个团队使用同一个 RAG 基础设施，需要按查询量或数据占比进行费用分摊。

3. 优化

常见优化包括：

限制上下文大小：只检索 top-k 小片段，不要把整个文档塞进提示词。
Embedding 优化：
- 缓存重复问题的 embedding
- 使用更便宜或更低维度的 embedding 模型
检索调优：
- 运用 metadata 过滤减少无关检索
- 将文档切分得更细
选择合适的向量数据库：自建 vs 托管、容量规划等。
监控使用模式：去掉长期不用的数据，优化索引大小。
合理安排 re-embedding 周期：只 re-embed 变更内容，而不是全量重跑。
建立预算与限额：embedding 与 LLM 一样需要预算保护。

AWS / GCP / Azure 的最佳实践

⭐ AWS

检索：OpenSearch（支持 vector search）、Amazon Kendra
Embedding：Bedrock、SageMaker 模型
注意 Step Functions 的状态转换成本
建议将 LLM、向量数据库、Lambda 部署在同一区域减少延迟与跨区费用

⭐ GCP

检索：Vertex AI Matching Engine
Embedding：Google Embedding APIs
BigQuery 也可用于存储或部分向量任务
全部组件尽量放在同一区域，避免 egress

⭐ Azure

检索：Azure Cognitive Search
Embedding & LLM：Azure OpenAI
留意 Cognitive Search 的索引容量与单位成本
Durable Functions 费用可能随大型编排增长

通用建议：

所有组件尽可能同区域部署
对高频查询做结果缓存
限制检索片段数量和长度
优化向量库的容量规划

ROI 与效率评估

衡量 RAG 性价比的方式包括：

答案质量 vs 成本：准确率显著提升时，适度成本上升通常可以接受。
单位查询成本：拆解为 embedding + 检索 + LLM 的综合成本。
数据利用率：被检索的文档占总文档比例，评估向量库 ROI。
可扩展性与吞吐量：在流量增长时成本增长是否线性或加速。
异常监控：embedding 重跑、检索风暴等导致的成本突增。

在很多情况下，RAG 能：

让你使用更便宜的模型 → 降低成本
提升回答可靠性 → 减少人工介入
提升用户满意度 → 增加业务价值

但需要持续监控与优化，确保投入与价值匹配。

可视化建议

你可以加入以下图示来辅助说明：

RAG 工作流图
RAG 成本分布饼图（例如 “LLM 70% / Embedding 20% / Vector DB 10%”）
优化前后单位成本对比折线图

这些都能帮助读者理解成本结构与 FinOps 优化效果。

Part 3: AI Agents：如何让大模型真正“动起来”（含成本管理）

AI Agent 架构概览

如果说单一 LLM 更像一个“非常聪明的图书管理员”（被动回答问题），那么 AI Agent 更像是一个“主动的研究助理”。它不会在回答完一个问题后立刻停止，而是能够规划动作、调用工具、执行多步骤任务来达成目标。例如，一个 Agent 可以帮你规划旅行：它会反复搜索航班、询问偏好、通过 API 预订酒店，所有过程都由 LLM 的“思考”进行编排。

从技术角度看，构成通常包括以下部分：

1. LLM（Agent 的大脑）

核心依然是大语言模型，但它被放入一个循环中使用，使其不仅能输出答案，还能输出“下一步行动”。Agent 的提示（prompt）通常会要求模型： “根据用户目标，决定下一步行动（使用某个工具或给出最终答案），并逐步推理。”

这通常通过 ReAct（Reason + Act）模式或链式思考提示来实现。

2. Tools / Actions（工具 / 动作）

这些可以是外部 API、数据库、计算器、甚至其他模型。Agent 可以调用它们获取中间结果。例如，在一个代码 Agent 中，LLM 会决定调用“执行代码”工具，获取输出后继续下一步。

3. Memory / State（记忆 / 状态）

与只处理单轮对话的 LLM 不同，Agent 需要记住之前的步骤。这可能包括：

短期记忆（上下文或规划步骤）
长期记忆（写入数据库或向量库）

部分框架内置可增长的内存结构，部分则借助向量数据库存储会话中推理得到的重要信息。

4. Planning / Decision Logic（规划 / 决策逻辑）

有些框架会将“规划者（planner）”和“执行者（executor）”分离：

Planner 制定高层计划
Executor 执行具体步骤

但更多时候，一个 LLM 通过提示完成所有工作。

5. Orchestration（编排）

通常会有一段协调逻辑（如使用 LangChain、Semantic Kernel 等框架），负责：

将 LLM 输出的工具调用请求传递给实际的工具
获取工具输出
将结果喂回给 LLM
循环直到任务完成

运行位置可以是 serverless、容器或专业服务。

6. System Prompts / Guardrails（系统提示 / 轨道护栏）

包括：

系统级提示词（告知 Agent 可执行的任务与工具）
超时、步数上限、内容审查等防护逻辑

总结一句话：

AI Agent 是一种“会反复推理并采取行动的 LLM”，可与外部系统互动，比单轮 LLM 强大许多。但能力越强，若不加控制，云成本也可能迅速膨胀。

成本因素：为什么 Agent 比单次 LLM 调用贵

AI Agent 引入循环逻辑与工具调用，这会造成显著成本增长。

1. 多次 LLM 调用

一个 Agent 会进行多轮自我对话，每一轮至少一次 LLM 推理。
例如，一个任务触发 5 次 LLM 调用，就是 5 倍 token 成本（甚至更多，因为每轮 prompt 会变长）。

生产案例中出现过这样的情况：

Demo 中一个 200-token 回答
实际运行中需要 1200 tokens 的内部推理与检查

成本是原来的 6 倍

2. 工具 API 的成本

每次调用工具可能产生成本：

对外 API（天气、股票等）
第三方 AI 服务（如图像生成）
内部服务的性能成本（对流量敏感的微服务会引发间接成本）

3. 编排与基础设施开销

例如：

使用 AWS Step Functions，每次 Action 都有 状态转换费用 + Lambda 调用费
或者如果编排器一直运行，会消耗 CPU / 内存

4. 执行时间增长

Agent 的多步骤任务可能需要数秒甚至数分钟：

Serverless 模型按时长计费
长时间占用容器也会产生成本

5. 状态存储

写入数据库 / 向量库虽然成本低，但高频写入也会累计。

6. 错误与重试

错误循环可能迅速造成费用爆炸。
必须限制无限循环，否则代理将反复消耗资源。

“单次 LLM 调用像一次函数调用；AI Agent 则像运行一个完整程序。”

应用 FinOps 原则：让 Agent 有成本意识

FinOps 为 Agent 治理提供了理想框架。

1. Visibility（可见性）

记录每一步：

调用哪个工具
多少 tokens
LLM 调用次数
执行时长
成本统计

可生成类似报告：

“任务 ABC – 平均 4.2 步、3 次 API 调用、1500 tokens、平均 $0.05”

并对异常行为设置报警。

2. Allocation（成本归属）

为不同 Agent、不同团队设置独立 API Key、Resource Group 或 project code，用于成本分摊。

3. Optimization（优化）

重点手段包括：

限制循环次数：例如限制最多 10 步，否则交由人工。
控制 Prompt 增长：如只保留最近 N 轮或压缩历史内容。
分层模型（Tiered Reasoning）：简单步骤用便宜模型，关键步骤用贵模型。
工具调用成本意识：工具可以设置“成本标签”，提示 LLM： “这个方法贵，除非必要请不要调用。”
会话内缓存 / 跨会话缓存：避免重复工具调用。
错误处理策略：而不是盲目重试。
限制并发与 fan-out：避免不必要的广度调用。

4. Monitoring & Alerts（监控与报警）

例如：

单个会话成本超过 $1 触发告警
步骤超过阈值中止

5. Governance（治理流程）

建立例行审查机制：

看任务价值是否匹配成本
调整 prompt 或工具集

云平台最佳实践

AWS

注意：

Lambda 调用频率 vs 长时间运行的成本差异
Step Functions 每步都计费
Bedrock Agents 的计费模型
标签（tags）用于成本追踪
Tool 调用结果可使用 DynamoDB + TTL 进行缓存

GCP

可使用：

Cloud Run 运行 Agent 循环
Cloud Functions 处理事件
Workflows 编排
设置 Project Budget 控制支出

Azure

可使用：

Durable Functions（但要注意编排成本）
Logic Apps
App Service / AKS 长跑容器

集成复杂性

每个新系统集成都可能变成一个子项目，特别是旧系统或无 API 的服务，会引入低效与额外成本。
应聚合数据或使用中间层来改善性能。

Tool Caching（工具缓存）

如 AWS 建议，将高频查询结果（例如股票价格）写入 DynamoDB（带 TTL），跨会话共享，大幅减少重复调用。

衡量 ROI 与规模效率

1. 成功率与价值贡献

如果一个任务自动化能节省人工时间，就可量化价值。

2. 任务成本 vs 人工成本

例如：

Agent 自动处理一次支持请求成本 $0.50
人工同样任务成本 $5 → 明确 ROI

3. 系统级效率

例如：

“Agent 系统总月成本 vs 完成任务数”

关注成本是否按线性增长。

4. 人工监督成本

需要考虑：

prompt 调整
输出审核
维护成本

5. 用户体验与采用率

满意度提升可创造间接价值（留存、收入）。

6. 持续改进

基于 log 进行迭代。
例如发现 Agent 每次多做了 3 个无意义步骤，通过调整 prompt 节省成本。

7. 基线比较

定期比较：

单次 LLM vs Agent
看准确率 vs 成本是否值得

结语：管理好你的“热情 AI 实习生”

AI Agent 像一个积极但容易做多余工作的初级员工——如果不给界限，它会不断采取行动。FinOps 就像它的经理，确保它：

不做冗余步骤
不调用昂贵工具
不无限循环

通过合理的架构与治理，Agent 可以成为高效的自动化工具，而不是不可控的云账单生成器。

可视化建议

Agent 循环流程图（标注各阶段成本点）
“单次 LLM vs Agent” 成本对比堆叠条形图
有趣的小插画：机器人疯狂执行任务、财务在后面追赶提醒成本

Part 4：Agentic AI — 自主式 AI（以及那些隐藏的成本）

Agentic AI（自主式 AI）指的是具备高度自主能力的系统，通常以多智能体（multi-agent）形式运行，能够自己决策、协作，甚至创建新的任务或子代理。一个 AI Agent 就像一个智能助理，而一个 Agentic 系统更像一个由多名智能助理组成的团队，彼此沟通、合作，有时甚至会“竞争”，以达成更大范围的目标。

这些系统可以持续运行，对开放式目标进行不断迭代。典型例子包括：