笔记整理自 FinOps 基金会官方文章，聚焦如何根据 FinOps 原则选择 AI 基础设施模型。

---

目录

一、为什么基础设施选择如此重要？

二、传统ML vs. LLM：怎么选？

三、AI基础设施的三种模式

什么时候选哪种？

四、爬、走、跑：基础设施选择框架

五、不同角色的基础设施偏好

六、AI工作负载的识别方法

七、FinOps最佳实践：如何优化AI成本

1. 成本可见性

2. 模型效率与优化

3. 计算成本优化

4. 不同基础设施模式下的KPI差异

八、总结与核心要点

一、为什么基础设施选择如此重要？

当你决定要做一个AI项目时，第一个需要回答的问题往往不是“用什么模型”，而是“AI跑在哪里”。这个选择直接决定了成本结构、管理复杂度、团队技能要求，以及未来的扩展能力。

这篇文章的核心观点非常直白：AI基础设施没有一刀切的方案。你可以选择完全托管（像用SaaS一样调用API）、部分托管（自己控制一部分配置）、或者完全自建（自己买服务器、搭集群）。三种模式在成本、灵活性、运维负担上差异巨大，适合不同阶段、不同规模的组织。

文章还提醒我们：虽然最近生成式AI（大语言模型）很火，但传统的机器学习（如回归、分类、时序预测、推荐系统）仍然是结构化数据任务的主力。大语言模型的计算成本高、可解释性差，并不是所有场景都适合。在启动AI项目之前，应该先判断：这个问题到底需要传统ML模型，还是LLM？

---

二、传统ML vs. LLM：怎么选？

下面的表格给出了典型场景的适用模型：

场景类型	传统ML模型	LLM（大语言模型）
结构化数据	✔ 回归、分类（GBM/SVM）、聚类	—
时间序列预测	✔	—
推荐引擎	✔	可选
图像分析	✔（CNN）	—
问答系统	—	✔
文本摘要	—	✔
内容生成	—	✔
知识抽取	—	✔
情感分析	—	✔
文本分类/归类	—	✔
机器翻译	—	✔
强化学习	✔	—

判断标准：如果你处理的是表格数据、数值预测、推荐、图像识别，传统ML通常更经济。如果你需要理解或生成自然语言，LLM才是合适的选择。

---

三、AI基础设施的三种模式

这是文章最核心的部分。三种模式可以用一张表清晰对比：

维度	完全托管	部分托管	自管理
示例	AWS Bedrock, Google Vertex AI, Azure OpenAI	AWS SageMaker, GKE with AI, Azure ML	自建NVIDIA DGX、裸金属AI集群、本地服务器
特点	供应商管理一切，你只管调API	云上AI环境，你可配置网络、计算实例	全权控制硬件、网络、资源分配
成本可预测性	按量付费，账单简单	更灵活的定价，但需主动管理	大额初始投资（CapEx），长期可能更省
运维复杂度	极低，几乎不需要DevOps	需要DevOps/ML工程师配置和调优	极高，需要专业团队
灵活性	低，有供应商锁定风险	中等，可自选GPU/TPU	最高，完全控制
安全与合规	云厂商托管安全框架	共享责任，需自行治理	完全自控，适合严合规场景
适合谁	早期实验、快速原型、无专业运维团队	需要平衡控制与便利的规模化团队	AI重度企业、合规要求高、负载稳定

什么时候选哪种？

• 完全托管：你刚起步，只想快速验证想法，不想管任何基础设施。团队里可能没有专门的DevOps或ML工程师。成本是按次或按时计费，初期很便宜，但用量大了以后可能比自建贵。

• 部分托管：你已经有一些AI工作负载在跑，需要平衡成本和性能。你可以自己选GPU型号、调参数，但又不用从零搭集群。适合有ML工程师、正在规模化AI的组织。

• 自管理：你的AI是核心业务，负载长期稳定，且对数据安全、合规、延迟有极高要求。你有足够的资本和团队来管理硬件。长期来看，自建的总拥有成本可能更低。

---

四、爬、走、跑：基础设施选择框架

文章用一个经典的三阶段模型，把基础设施选择和技术成熟度、FinOps成熟度对应起来：

阶段	爬行（初学者/早期）	行走（中等/规模化）	奔跑（高级/企业级）
推荐基础设施	完全托管	部分托管	自管理
技术准备度	低，聚焦AI功能，无视基础设施复杂性	中等，需要一些DevOps和ML工程知识	高，需要深度基础设施和AI负载管理能力
FinOps成熟度	基础成本可见性，按量付费，极少优化	成本监控，负载优化，合理调整规格	高级FinOps：CapEx vs OpEx权衡，自定义成本模型
典型场景	实验、AI研究、概念验证（PoC）	规模化AI负载，优化成本性能平衡	企业级AI，关键任务应用
成本特点	单位成本高，但运维开销低	成本效率平衡，需主动控制	前期投资高，长期优化后成本低
性能优化	自动扩缩，但定制少	可自选GPU/TPU/网络	完全控制硬件和性能调优
安全合规	云厂商托管	共享责任，需治理策略	完全控制
主要角色	AI研究员、创新团队、早期采用者	ML工程师、FinOps团队、规模化的组织	AI重度企业、受监管行业、大规模部署

这个框架告诉我们：不要一上来就买服务器。从完全托管开始验证，逐步过渡到部分托管，只有当你真的需要了再考虑自建。

---

五、不同角色的基础设施偏好

不同的人关心不同的事。文章把常见角色和他们对三种基础设施的适配度整理了出来：

角色	使用场景	完全托管	部分托管	自管理
FinOps实践者	实施成本控制，追踪AI预算	通过资源利用率和财务规划优化AI支出	追踪并优化AI基础设施成本，确保治理	追踪成本，优化CapEx/OpEx，财务治理
AI研究员/数据科学家	运行AI训练任务，需要自动扩缩	专注模型开发，不管基础设施	配置AI环境，选择计算资源，调优性能	在专用硬件上设计、部署、优化模型
ML/开发工程师	部署AI聊天机器人或推荐引擎	低运维开销，高可扩展部署	管理部署，做一些基础设施调优	端到端部署，完全控制基础设施
DevOps/云工程师	自动化AI部署流水线，成本高效扩缩	几乎不参与，供应商管理一切	管理基础设施设置、网络、扩缩	负责配置、网络、扩缩和维护
财务	追踪AI支出，确保预算合规	监督AI预算规划，监控云支出	管理AI基础设施财务规划，预测成本	规划和证明大额资本投资，平衡OpEx
采购	谈判基础设施决策，优化采购	确保托管AI服务采购成本有效	监控AI计算成本，优化预算分配，谈判云价格	管理供应商选择，谈判成本，制定采购策略
产品负责人	使AI投资与业务目标一致	同上	平衡AI成本效率与性能目标	确保基础设施投资符合长期业务战略
企业创新团队	测试和验证AI用例	测试和验证	在实验时平衡成本与控制	完全控制模型和数据，驱动创新

一个有意思的观察：销售团队也可以利用AI来做市场细分、客户洞察、内容生成。对他们来说，完全托管最省心；但需要深度控制数据的企业可能会选择自管理。

---

六、AI工作负载的识别方法

在做成本管理之前，你得先知道哪些资源是AI相关的。文章给出了三种识别方式：

1. 已知AI工作负载：供应商明确标注为AI的服务，比如AWS SageMaker、Azure OpenAI。这些从账单上就能直接认出来。

2. 手动标记的AI工作负载：你自己给资源打上的标签，比如把某个运行模型服务的虚拟机标记为“AI推理”。这要求团队有良好的标签习惯。

3. 发现的AI工作负载：通过第三方扫描工具或自定义规则，在基础设施中检测出正在运行的AI进程。适合那些没有打标签、但实际在跑AI任务的资源。

建议是三种方法结合使用：先依赖供应商的分类，再强制团队打标签，最后用扫描工具兜底。

---

七、FinOps最佳实践：如何优化AI成本

文章给出了四个维度的最佳实践，我把它们整理成了清晰的列表。

1. 成本可见性

• 结构化标签：使用像 AI_Chatbot_Store101 这样的标签，按功能、位置、部门追踪AI工作负载。

• 动态标签：根据实际用量动态添加标签，不阻碍资源创建。

• 元数据归因：衡量AI的业务影响，比如聊天机器人的响应时间、交互频率、解决率、每次交互成本。

• 服务映射：将AI支出与业务KPI关联，比如由聊天机器人带来的转化率、峰值使用时段等，用于优化基础设施成本。

• 比例规则分配：对于共享的AI资源（比如一个GPU同时跑报表和推理），定义比例分配规则，例如70%归报表、30%归AI推理。

2. 模型效率与优化

• 提示词工程：优化输入/输出的token用量，能显著降低成本。

• 模型选择：用托管模型时，选对模型（如用GPT-3.5代替GPT-4）至关重要。

• 特征工程：减少参数数量，降低训练时间和成本。

• 早停法：当准确率达到目标后立即停止训练，避免过拟合和无谓计算。

• 数据清洗与预处理：删除重复、修正错误、处理缺失值，减少计算开销。

3. 计算成本优化

• 成本感知的训练：优化再训练频率，倾向小模型，利用迁移学习。

• 工作负载调度：把AI任务安排在非高峰时段，对非关键任务使用抢占式/Spot实例。

• 可持续AI计算：使用低碳、节能的区域，GPU池化，自适应冷却策略。

• 预留与Spot实例结合：稳定负载用预留容量，波动负载用Spot。

• 自动化预算控制：设置成本告警、闲置资源自动关机、异常检测。

4. 不同基础设施模式下的KPI差异

文章给出了一个很有价值的对比表，展示了三种模式下关键指标的差异：

KPI	自管理AI	完全托管AI	混合AI（部分托管）
训练成本	直接控制GPU，需容量规划	每小时云成本高，但全托管	本地做标准训练，云上做大规模
微调成本（每百万参数）	成本较低，但需基础设施	基于API的高参数成本	轻量微调用本地，大更新用API
推理成本（每千次预测）	长期较低，需基础设施	每次查询价格高，零设置	高频推理用本地，突发流量用云API
API成本 vs 自托管	自托管无API成本，但需基础设施	云API贵，但无需基础设施	常用模型本地化，偶尔调用API
每次训练会话的计算成本	直接GPU控制，需规划	每小时成本高，但可扩展	本地基础训练，云上大规模运行
合规成本（CapEx/OpEx）	内部工作量大，外部成本低	云合规工具降低人工投入	内部团队与云治理平衡
能源消耗（每次训练周期）	能耗高，可用可再生能源优化	云厂商优化效率，但成本高	本地计算节能，云上扩展

---

八、总结与核心要点

读完整篇文章，可以提炼出几个可以直接拿去用的结论：

1. 没有唯一的正确答案。完全托管适合快速验证和早期实验；部分托管适合规模化中的平衡；自管理适合重度AI、严合规、长期稳定负载。

2. 不要跳过爬行阶段。很多企业一上来就想自己买服务器、搭集群，结果运维成本远超预期。从API开始，等真正需要了再往下走。

3. 成本可见性是一切的基础。如果连哪些资源是AI相关的都分不清，优化就无从谈起。标签、发现工具、比例分配，缺一不可。

4. 模型选择和提示词工程是性价比最高的优化手段。换一个小模型，或者把提示词精简一下，可能省下30%-50%的费用，而对效果影响极小。

5. 不同角色要坐在一起讨论。FinOps团队关心成本，工程师关心性能，产品关心价值。只有一起敲定基础设施方案，才能避免“省了钱但没法用”或“性能很好但买不起”的尴尬。

6. 用KPIs衡量，而不是凭感觉。训练成本每百万参数、推理成本每千次预测、合规成本、能耗……这些指标可以帮你客观比较不同基础设施方案的真实经济性。