团队要上大模型，会上总有人问「为什么不自己部署一套」。这个问题没有统一答案，卡人的往往不是技术，而是没人把成本口径、数据边界和增长预期摊在一张表上算。这篇给一套三行对照的判断框架和一份开会前该填完的清单，让你能说清什么条件下走本地、什么条件下走云端，以及混合方案在哪一步开始划算。
团队要上大模型，会上总有人问「为什么不自己部署一套」。这个问题没有统一答案，卡人的往往不是技术，而是没人把成本口径、数据边界和增长预期摊在一张表上算。说服人的方式不是讲原理，是把三行对照摆出来，当场能填的先填，填不了的形成待办。
下面按成本、隐私、扩展性三条线给判断标准，最后附一份开会前该填完的自查清单。结论导向是：能说清什么条件下走本地、什么条件下走云端，以及混合方案在哪一步才开始划算。凡涉及具体数字，一律到站内对应页面核对当时的数据，再代入自己的实际负载。
成本：先分清一次性、持续性、隐性三笔账
本地这条线的支出拆成三块：硬件与机房的一次性投入、电费与运维人力这类长期固定开销、模型换代带来的重复投入。云端则拆成调用费、限流后加购的额度，以及为稳定性做的冗余调用。拆完你会发现两边比的不是同一个东西，直接比总额没有意义。
判断分界线不看总额，看负载曲线。请求集中在少数时段、总量起伏大，云端的按量付费更容易压住成本；24 小时稳定跑量的场景，本地的固定成本会被摊薄。先把最近一两个月的调用分布画出来，再谈选型。
| 成本项 | 本地部署 | 云端调用 |
|---|---|---|
| 启动投入 | 硬件、机房、部署验证人力 | 基本为零，按量起步 |
| 长期开销 | 电费、运维、监控值班 | 调用费随量走 |
| 换代成本 | 重新测算显存、重新部署 | 改模型名，但要重测效果 |
| 隐性风险 | 故障时没人兜底的时间 | 供应商调价、模型下线后的迁移 |
隐性成本最容易被漏掉：本地要算上模型下载与版本管理、监控告警、出问题后没有人兜底的时间；云端要算上供应商调价、模型下线的迁移成本。具体单价到 AI 官方 API 价格（/official-api） 与 买卡还是租卡（/compute/tco） 核对当时的数字，再代入自己的月调用量。
隐私：区分「数据不能出内网」和「数据不想被留存」
先给数据定级：能公开的、内部一般的、明确不能出网的。只有最后一档才构成本地部署的硬理由，前两档用云端加上合同条款通常就够。定级要落到具体字段上，而不是笼统说「我们的数据比较敏感」。
另外一个常见误区是：本地部署不等于自动合规。内网机器谁都能访问、日志不脱敏、模型权重和微调数据没有权限控制，风险只是从外部搬到了内部。反过来，云端也不是只有一条路，商用接口一般提供不留存或短期留存的选项，走前先确认口径。
- 把数据按「可公开、内部一般、不能出网」三档分类，落到具体字段和来源系统
- 只对第三档评估本地部署的必要性，前两档优先走云端加合同约束
- 本地方案也要过一遍内网权限、日志脱敏、权重访问控制三项
- 云端方案确认不留存或短期留存的条款口径，写进合同附件
要判定自己的场景属于哪档，可参照 安全与合规（/safety） 的检查维度逐条打勾。不适用的情形也要说清：如果业务本身要求模型能离线跑在无网环境，这一节直接跳过，按本地方案设计即可，不必再比。
扩展性：两边扩容的瓶颈位置完全不同
本地扩容要过采购和到货周期，短期峰值只能靠排队、限流或者降级模型来扛；云端扩容基本是改额度，瓶颈变成预算审批和供应商的可用性。也就是说，本地的瓶颈在物理侧，云端的瓶颈在财务和合同侧，出问题找的人都不一样。
能力扩展方向也不同：本地想上新模型要重新做显存测算和部署验证，云端换模型通常改一个模型名，但效果要重新测。用 部署测算（/models/deploy） 先把要跑的模型和卡对上，再看扩不扩得起，别先买卡再找模型。
- 量化峰值统计过去一段时间的峰值并发和最慢可接受响应时间，形成一页纸的事实依据，而不是拍脑袋
- 算物理上限按目标模型做显存与吞吐测算，得出单机或单集群能扛多少并发，留出余量
- 比对扩容动作本地填采购周期与到货时间，云端填提额审批流程，哪边的等待时间能接受就选哪边
- 小规模验证挑一个真实任务在两条路线各跑一遍，比对效果与单位成本，不拿榜单分数代替
混合是常见终点：敏感数据走本地小模型做预处理和脱敏，重活在云端跑。判断要不要走到这一步，看你的敏感数据占比和峰值并发是否同时偏高，只有一边高的话单一路线更省心，混合反而多了一套要维护的东西。
开会前填完的自查清单
下面这份清单的目标是让选型会开成结论，而不是开成第二次讨论。填不满的项就是行动项，指派到人，定好回收时间，再约下一次会。不要在没有数据的情况下先表态支持哪条路线。
- 三条数：月均请求量、峰值并发、能接受的最长响应时间。有一条答不上来，先别比方案，去做一段时间埋点
- 一条边界：哪类数据绝对不能出网，由谁签字确认
- 一条时间线：未来一年内模型换代几次、能力需求会不会明显跳档
- 一次试跑：挑一个真实任务，本地与云端各跑一遍，记录效果和单位成本
- 一个兜底：本地方案谁负责故障响应，云端方案供应商出问题时备选是谁
最后提醒一句：效果比对别用榜单分数代替。口径参考 AI 模型库（/models） 里的规格说明，再看选型时是否需要关注延迟与稳定性的实测，可用 速度测试（/tools/speed-test） 的方法自测一遍，把结论写回清单。
选本地还是云端，本质是选你愿意承担哪种不确定性：一次性的资本支出，还是持续的价格与可用性波动。下一步把清单里的三条数填完，再带上海量数字去 价格追踪（/price-watch） 核对当时的单价和趋势，选型会就能当场出结论，而不是再约一轮。→
常见问题
小团队是不是一律用云端更划算？
多数情况是，因为本地的固定开销摊不开。但如果你们的请求量小却对数据边界要求极严，或者需要离线运行，规模小反而更容易被单个硬约束决定路线，这时不必按成本算。
本地部署之后是不是就完全不用再花钱了？
不是。硬件是一次性的，电费、运维人力和模型换代是持续的，还有故障时没人兜底的时间成本。把这些按年摊开和云端调用费对比，结论往往和直觉不一样。
两种方式能不能混着用？
可以，而且很多团队最后都走到这一步。常见拆法是敏感数据在本地做清洗脱敏、重负载交给云端。前提是两条链路都要有监控和降级方案，否则出问题时排查成本翻倍。
