大模型云 API 和本地部署：企业怎么选

选云 API 还是本地部署，很多企业从「哪个模型更强」开始比，比到最后发现方向选错了。真正的头一道分界线是数据：这些数据能不能离开自己的网络。大模型的选型不是一次技术采购，是把未来两三年的成本结构和团队负担一起定下来。

先给数据分级，再谈架构

分四级比较好操作：公开资料、内部资料、敏感资料（个人信息、客户资料、财务明细）、核心机密（配方、源码、未公开交易）。前两级走云 API 没有争议；敏感级要么脱敏后上云，要么走云上的专有实例；核心机密才需要考虑本地。

分级要落到字段，不能落到系统。「这个系统敏感」没法执行，「这三列不能出内网」才能执行。落到字段之后你会发现，真正必须留在本地的数据，往往只占整个业务的一小部分。

脱敏不是万能的。单个字段打码后看着安全，几个字段组合起来仍可能定位到具体的人。做方案时要按「组合后能不能识别」来验，不是按「每个字段有没有打码」来验。

云 API 的钱花在后面

云 API 的显性成本是按量计费，用多少付多少，起步几乎为零。真正要算的是后面几项：应用开发、提示词调优、评测集维护、调用监控、异常兜底。这些不随调用量下降，是固定投入。

计费口径要看懂。输入和输出的单价通常不同，长上下文、缓存命中、批量接口各有各的价，同样的业务量按不同口径算，账单能差出一截。API 价目表怎么读里有拆解，选型阶段先把口径对齐，别拿两个不同口径的数字对比。

云方案还有两类风险。一是供应方策略变化：调价、模型下线、限流，都会直接影响业务。二是能力依赖：应用围绕某个模型的输出特性做了适配，换模型就要重跑评测。备选模型和降级方案要在上线前想好，不是出事时再找。

本地部署的钱花在前面

本地部署是一次性投入：算力设备、机房与电力、网络、存储，加上模型适配和安全加固。设备按三年折旧摊到每个月，这笔钱在业务还没跑起来的时候就已经发生了。

更容易被低估的是人。推理服务的部署、监控、扩容、故障处理、版本升级，都要有人负责，而且不能是兼职——模型出问题时业务是停着的。没有专职运维的团队自建，最后往往是设备在跑、没人敢动。

还有闲置率。本地按峰值买容量，业务有波峰波谷，平均利用率可能只有两三成。这部分浪费不体现在采购单上，但它是实打实的成本。云端按量付费的好处，正是把这部分浪费转移给了供应方。

能力差距也要认。开源权重通常落后云端旗舰一个版本周期，追赶需要时间。同一份权重在不同量化精度、不同推理框架下，输出也会有差异，同一模型的 API 和本地部署输出是否一致，答案通常是不完全一致。

三个判据算出拐点

头一个判据是数据。核心机密且无法脱敏的，本地；其余先考虑云。这一条是否决项，不参与打分。

第二个判据是调用量。做一个粗算：把本地三年的总成本（设备折旧加机房、人力、适配）除以 36，得到每月固定成本；再用云端同等调用量的月账单去比。倍数低于 1.5，说明本地没有明显优势，先上云；倍数超过 2 且调用量稳定，本地才值得算细账。这是判断方法，不是价格结论，实际数字以厂商报价为准。

第三个判据是团队。有没有人能维护推理服务、处理故障、跟进版本升级。没有这个人，前两条算得再漂亮也落不了地。三条里两条不满足，先上云，把业务跑起来再回头看。

混合方案怎么落

这张表的关键在最后两列。混合方案不是两边都买，是按数据密级把请求分流，并且让分流规则写进系统，而不是靠人记得。内部工具和外部 API 的边界，本质也是同一道分流题，内部工具和外部 API 差在哪可以对照着看。

三种常见的选错

头一种是为了数据安全自建，结果安全没做好。设备进了机房，日志没脱敏、权限没分级、管理端口暴露在内网，风险不比上云低。自建不等于安全，安全是另一套工程。

第二种是只算硬件钱。采购单上的数字好算，人力、机房、电费、闲置、升级，这些不进采购单，但每个月都在发生。

第三种是小团队自建。三个人支撑一个推理集群，业务一忙就没人管升级，模型停在半年前，补丁也没打。这不是省钱，是把技术债换了个地方放。

反过来也有选错的：所有数据一律上云，包括本该留在本地的核心资料。这类问题通常不是技术判断错，是没人做分级。先把字段级的分级表做出来，选型才有依据。自部署权重和调 API 的取舍讨论的是同一组权衡。

选型五问

• 哪些字段绝对不能出内网
• 每月调用量的峰值和均值各是多少
• 本地三年总成本除以 36 是多少
• 谁负责推理服务的日常运维
• 主力模型下线时的备选是谁