一家做合同审核 SaaS 的 CTO 在白板前画了三天
去年年底，一家做合同审核 SaaS 的公司找到我们。他们的客户里有几家头部券商和保险公司，AI 审核功能在内测阶段反响很好，但要正式商用就卡住了——大客户的安全部门明确要求：合同文本不能出公网，模型不能调用境外 API，审计日志要本地留存三年以上。
这家公司的 CTO 在白板前画了三天架构图。一边是已经跑得很顺的云 API 方案，按 Token 计费，每个月几万块，团队只需要写业务代码；另一边是客户合规清单上画的红线，逼着他考虑要不要自己买 GPU、自己部署开源模型、自己维护一整套推理服务。他算过一笔账：如果今年只是把现有客户接住，云 API 完全够用；可一旦签下两三家头部金融客户，年化 Token 费用会涨到两百多万，而且没有任何谈判空间。
他最后问了我们一个问题：「我们这种阶段，到底是该咬牙自建，还是再撑一撑用云？」
这不是一个能一句话回答的问题。云服务和自建之间的差异，远不止「贵不贵」三个字。这篇文章想把这道题拆开讲清楚——从合规、成本、长期性三个维度，帮正在做这个决策的 CTO/CIO 看到全貌。
痛点：很多团队是被一份合规清单逼着选自建的
我们接触过几十家正在做 AI 落地的中大型企业，发现一个反复出现的模式：第一阶段大家都用云 API 起步，因为快、便宜、不用养团队；第二阶段开始纠结，要么是调用量涨到肉疼，要么是有客户/监管把合规要求拍到桌上；第三阶段被迫上自建，但因为前期没规划，要么硬件采购踩坑，要么团队接不住，最后变成「云和自建两套都跑、两份钱都花」的尴尬局面。
这一节我们不展开吐槽，直接进入正题，把决策的几个关键变量摆清楚。
云服务 vs 自建的本质：边际成本 vs 一次性投入
这一节先把最底层的财务结构讲明白，后面所有维度都建立在这个差异上。
云 AI 的财务特征是「线性边际成本」。 每多一次调用就多一份 Token 费用，模型升级、机房运维、卡的折旧都被分摊在单价里，你看到的只是一个干净的 API。优点是启动门槛极低，团队不用懂底层就能跑起来；缺点是当调用量大到某个阈值之后，单价再低也是巨大的支出。
自建的财务特征是「高一次性投入 + 低边际成本」。 GPU 服务器、机房、网络、运维人力一次性砸下去，单次推理的真实成本可以压得很低，但前提是你要把这些卡跑满。如果平均利用率只有 20%，那一次性投入摊到每次调用上的成本可能比云 API 还贵。
| 维度 | 云 AI 服务 | 自建 AI |
|---|---|---|
| 初期投入 | 几乎为零，按用量付费 | 硬件 + 机房 + 团队，百万级起 |
| 边际成本 | 每次调用都付 Token 费 | 卡跑满后接近电费 |
| 拐点位置 | 调用量小、波动大时占优 | 调用量大、稳定时占优 |
| 团队要求 | 业务工程师就够 | 需要 MLOps、推理优化、模型工程师 |
| 模型选择 | 厂商提供什么用什么 | 想跑什么跑什么，包括微调 |
| 升级速度 | 厂商升级你跟着升 | 自己评估、自己迁移 |
读这张表的姿势是：不要只看左右两列哪个数字漂亮，要看你自己的业务长什么样。下面三节就是教你怎么把自己的业务对到这张表上。
合规维度：金融/医疗/政企的硬约束
合规这件事，是很多公司被迫上自建的第一动因，但它不是一个「自建就万事大吉」的话题。
第一类是数据出境约束。涉及个人信息、生物特征、健康医疗数据时，PIPL 和行业细则都明确要求境内存储和处理。如果你的云 AI 厂商用的是境外模型，或者推理节点不在境内，这一关就过不去。这种情况自建几乎是默认选项，相关的合规边界我们在 AI 合规与 PIPL 企业落地指南 里讲得比较细。
第二类是行业监管约束。金融、医疗、能源、政务这些行业，除了通用法规之外，还有行业自己的细则。比如金融机构的「数据不出域」、医院的「患者数据不出 HIS」、政务的「等保三级以上」。这些约束不会因为你用了「合规版」云服务就消失，往往要求物理隔离、专属硬件、独立审计。
第三类是客户合同约束。这是最容易被忽视的。你自己不是金融机构，但你的客户是——客户一句「你们的 AI 推理过程不能出我们的内网」，整个架构都要重做。SaaS 公司尤其要注意这一点，最好在产品早期就把私有化部署版本的可能性留出来。
| 行业 | 典型约束 | 云 AI 是否可行 | 推荐姿势 |
|---|---|---|---|
| 金融券商保险 | 数据不出域、独立审计 | 否 | 全自建 + 完整审计链 |
| 医疗 | 患者数据不出 HIS | 否 | 院内自建小集群 |
| 政企央企 | 等保三级 + 国产化 | 部分场景 | 自建优先，云作辅助 |
| 教育消费品零售 | 一般合规 | 可行 | 云为主，敏感模块自建 |
| 互联网 SaaS | 看客户要求 | 大部分可行 | 留好私有化口子 |
结论：如果你的业务踩在前三行里的任意一行，合规这一项就已经替你做了决定，不用再纠结成本——成本是有合规之后才需要算的题。数据安全的整体框架建议参考 AI Agent 数据安全企业落地 和 AI Agent 权限审计 这两篇。
成本维度：调用量大小决定拐点
撇开合规，纯算账的话，云 vs 自建的拐点在哪？我们用过去两年帮客户做过的几十个测算，整理出一个粗略的经验区间。
年化 Token 调用费用 30-80 万：云 API 通常更划算。 这个量级下，云的便利性远大于差价。自建的话，光机房、运维、人力的固定成本就能吃掉省下来的钱，而且把团队精力从业务上拽走了。
80-150 万：开始进入纠结区。 这个阶段建议做精细化拆分——把高频、低难度的调用（比如客服 FAQ、文档摘要）放到自建的小模型上，把低频但难度高的（比如复杂推理、多步规划）留给云上的旗舰模型。也就是后面会讲的混合架构。
150-300 万：自建与云的 TCO 开始接近。 这个区间是决策最难的，因为只看现金流自建可能略贵一点，但把数据资产沉淀、议价能力、未来扩展性算进去，自建的战略价值开始显现。
500 万以上、调用稳定：自建优势明显。 此时云 API 的边际成本会成为持续的财务负担，而且你已经被厂商的定价策略绑住了。
| 年化 Token 费用 | 推荐策略 | 关键风险 |
|---|---|---|
| < 80 万 | 全云 | 别过早自建 |
| 80-150 万 | 云 + 自建小模型 | 别两套都不专 |
| 150-300 万 | 混合架构，主体逐步迁自建 | 团队跟不上 |
| > 500 万 | 自建为主，云作灾备和试错 | 模型迭代滞后 |
两个常见误区：
第一个，只算 Token 单价不算 TCO。自建的真实成本里，硬件折旧只占 30-40%，剩下的是机房、电力、网络、运维人力、模型迭代、安全合规。很多团队拍脑袋算账只看 GPU 价格，上线之后才发现总成本比想象的高一倍。
第二个，用峰值算云的成本。云 API 的优势之一就是弹性，你不用为峰值买单。如果你的业务有明显的潮汐特征（比如 To C 应用的晚高峰、To B 应用的月底报表期），云的成本优势会比算静态平均值时显得更突出。开发成本的更细拆解可以看 AI Agent 开发成本拆解 和 AI 数字员工 ROI。
长期性维度：模型迭代 + 团队维护责任
这一维度最容易被低估，但实际是决定项目成败的关键。
模型迭代的速度比你想象的快。开源世界基本上每 2-3 个月就有一次代际更新，闭源旗舰模型也差不多这个节奏。云 API 模式下，你只要改个模型名字就用上了新版本；自建模式下，每一次升级都意味着：下载几十 GB 的权重、重新评测在你业务数据上的表现、重新做 prompt 适配、重新跑安全测试、重新部署、回滚预案。
团队是另一道隐性门槛。一个能把开源 70B 模型稳定跑在生产上的团队，至少需要：1 名懂分布式推理的工程师、1 名懂模型评测和微调的算法工程师、1 名 MLOps/SRE。这三个岗位在 2026 年的市场上都不便宜，且流动性都不低。如果团队规模本就紧张，再砍出三个 HC 去支撑自建，业务侧就会感到资源被吸走。
自建≠永久持有。我们看到的健康姿势是「自建一代，云上看下一代」——自己跑的是上一代经过验证的稳定模型，云上同时调用最新模型用于研发评测和功能预研，等下一代稳定之后再迁到自建上。这样既享受了云的速度，又保住了自建的成本和合规优势。
这种架构上的演进方式，和我们在 AI Agent 架构模式 里讲的多模型路由其实是同一套思路，多模型路由策略 里有具体的实现细节。
GPU 自建：单卡/多卡/集群的不同选择
一旦决定自建，硬件选型是绕不开的硬骨头。把常见的三档摆出来：
单卡工作站（5-15 万）。适合 7B-14B 级别的开源模型，做对话、文档问答、代码补全。常见配置是 4090 / L20 / RTX 6000 Ada 单卡 + 64-128G 内存 + 中等 SSD。优点是便宜、上手快、机房要求低；缺点是并发能力有限，一旦同时在线超过 20-30 人就明显卡。适合：50 人以下团队、内部使用、研发原型。
单台 8 卡整机（80-200 万）。8 卡 A800 / H800 / 国产昇腾整机，可以跑 32B-70B 级别的模型，并发能力大幅提升。这是大多数中大型企业自建的「主力机型」。适合：百人以上规模、对外服务、需要稳定并发。 选型时要注意 NVLink/NVSwitch 的拓扑、电源冗余、散热设计。
小型集群（300-800 万起）。多台 8 卡整机 + InfiniBand 互联，能跑超大模型推理和小规模微调。这个量级已经是「准 AI 中台」，需要专门的机房、专门的运维。适合：把 AI 当核心能力售卖的公司、有大规模微调需求的团队。
| 档位 | 适用模型 | 并发能力 | 投入区间 | 团队门槛 |
|---|---|---|---|---|
| 单卡工作站 | 7B-14B | 20-30 人 | 5-15 万 | 1 人兼职 |
| 单台 8 卡 | 32B-70B | 200-500 人 | 80-200 万 | 2-3 人 |
| 小型集群 | 70B+ / 微调 | 1000+ | 300-800 万 | 5-8 人 |
两个采购避坑点：
一是别迷信顶配。很多团队上来就盯着 H100/H200，但绝大多数企业的实际场景，A800/L20 甚至国产卡就够用，多花的钱完全可以投到第二台机器上做冗余。
二是二手卡可以考虑但要看场景。二手 A800 价格通常是新卡的 5-7 折，对预算紧张的研发场景很友好，但用在主力推理节点要谨慎，至少要从靠谱的服务器商手里拿、要求完整健康报告和质保。
混合架构：核心走自建、试错走云
实战里我们最常推荐的，不是「全云 or 全自建」二选一，而是混合架构。
核心业务走自建。高频、稳定、合规敏感的调用放到自建集群上，比如客服问答、文档审核、内部知识检索。这部分要求是「成本可控、合规可审、稳定可靠」。
长尾和试错走云。低频、波动大、需要最新模型能力的调用放到云上，比如战略分析、复杂推理、新功能预研。这部分要求是「能力前沿、弹性扩展」。
关键是要有一个统一的路由层。它根据请求类型、合规等级、模型能力要求，自动把流量分发到合适的后端，对业务代码屏蔽底层差异。这层做好之后，未来再调整云/自建的比例就不用动业务代码了。
这套架构的核心抽象，和 AI Memory 与 Tool Use、RAG、企业级 AI 落地 8 步法 里讲的工程化路径是一脉相承的，落地 roadmap 可以参考 AI Agent 实施路线图。
什么样的企业必须自建：5 个硬信号
如果下面五条里有任意一条命中，自建基本就是默认答案，不用再纠结：
- 行业监管明文要求数据不出域——金融、医疗、政企的硬约束，云用得再爽也得回到自建。
- 客户合同里写了私有化部署条款——尤其是 To B SaaS，大客户的红线就是你的红线。
- 年化 Token 费用稳定超过 300 万——拐点已经过了，自建的 TCO 优势会持续放大。
- AI 是产品核心壁垒不是辅助功能——如果 AI 直接构成你的护城河，模型权重、推理优化、数据闭环都不能让渡给第三方。
- 有强烈的模型微调和私有数据训练需求——云 API 的微调能力有限且贵，自建在这方面自由度大得多。
反过来，如果你只是想给团队加点 AI 工具、给产品加点 AI 功能、客户也不关心模型跑在哪里，那大概率不用自建——把钱花在业务上更合算。能力边界的判断可以对照 AI 数字员工能力盘点 和 AI Agent 前置条件自检。
决策表：一张表把方向定下来
| 你的情况 | 推荐方向 | 关键动作 |
|---|---|---|
| 行业有合规硬约束 | 自建为主 | 先做合规架构，再选硬件 |
| 客户要求私有化 | 自建为主 | 产品形态要支持私有化交付 |
| 年化 Token < 80 万 | 全云 | 别折腾自建，把精力留给业务 |
| 年化 Token 80-300 万 | 混合 | 先做路由层，再分高低频 |
| 年化 Token > 300 万 | 自建为主 | 团队先到位再砸硬件 |
| 团队 < 50 人无 AI 工程师 | 全云 | 自建养不起 |
| AI 是产品核心壁垒 | 自建 | 算 ROI 时把战略价值计入 |
| 业务流量潮汐明显 | 云为主 + 自建保底 | 享受云的弹性 |
| 主要做对内提效 | 云为主 | 速度优先 |
| 主要做对外服务 | 看客户合规 | 合规优先 |
把这张表打印出来贴在白板上，比开三天会都管用。
结语
回到开头那位 CTO 的问题。我们最后给他的建议是：今年继续用云把业务跑起来，同时启动小规模自建做合规预研，等下半年签下第一家头部金融客户的时候，自建集群正好能交付。半年后他给我们发消息说，第一个金融客户的合规审查一次过——审计专员看到他们已经有了独立的自建推理环境，态度直接从「需要论证」变成了「合规友好」。
云 vs 自建从来不是非黑即白的选择题，而是一道关于「你公司处在哪个阶段、要去哪里、能调动什么资源」的综合题。靠谱的决策不是抄一个标准答案，而是把自己的业务画清楚、把约束摆明白、把资源算干净，剩下的方向自然会浮现。
如果这道题你已经想了好几个月还没头绪，欢迎找我们聊一聊——我们不一定能帮你省钱，但大概率能帮你少走几个弯。
