1.3 LLM 选型实战：公有云、私有化、开源模型该怎么选？

大家好，我是冰点，今天我们聊聊大模型落地里最容易吵架的一个决策：到底用公有云 API，还是私有化部署，还是开放权重自建。

我参加过好几次这种选型会，场面都差不多：安全部门说数据不能出域，必须私有化；财务说私有化要买卡买机器，预算批不下来；业务说你们别吵了，下个月就要上线。三方说的都有道理，但也都只说了一半。这件事没有标准答案，得把数据、成本、团队和业务时限放在一起取舍。这一节我就把账掰开讲，最后给一个我自己在用的选型办法。

不过，公有云 API、私有化部署、开放权重自建并不是三个互斥选项。公有云 API、专有云、企业机房和端侧说的是服务跑在哪里；专有权重、开放权重和软件许可证说的是企业能拿到什么。 开放权重模型也能由公有云托管，专有模型也可能交付到客户专有环境。把这两条轴拆开，很多争论就顺了。

两条轴，别揉成一道单选题

先看部署与服务方式：共享托管 API、云上专属实例或厂商托管专有云、企业自建机房、边缘与端侧。越往企业控制的环境走，数据路径和变更窗口越可控，但容量规划、故障处理和升级的责任也越多。

再看模型开放性：权重能不能拿到、许可证允许什么、推理代码能不能改、厂商有没有 SLA。开放权重自建给了团队更大的优化空间，但不保证效果更好、成本更低、许可风险自动消失；专有模型通过 API 使用，企业也不是只能躺平，网关、检索、工具、评测和数据最小化都还在自己手里。

公有云 API：最快的第一步，但别忽视隐形成本

公有云 API 的好处人人都知道：不用管机器，不用管模型升级，厂商帮你把不少脏活累活干了。对于验证场景、跑 MVP，这条路很有优势。但有两个隐性成本，很多团队是事后才发现的。

一个是账单会跟着业务量和上下文一起长。我帮一家做干线物流的公司算过运单摘要：试点期每天几千单，一个月几百块钱，大家觉得挺好；全量推开后每天几十万单，再加上长上下文，月账单直奔六位数。这个数字是当时那个项目的供应商价格和 Prompt 口径，不能据此断言自建一定能省到多少。缓存、批处理、失败重试、峰值冗余和人员成本一变，交叉点就会跟着变。

另一个是数据边界。运单里有收发货人电话、地址、货物品类，这在物流行业不是可以随手扔出去的普通文本。调用第三方 API，意味着数据进入另一个处理者或受托处理方的系统边界，但不当然等于数据出境。是不是出境，要看接收方、基础设施、远程访问和后续处理的实际链路；是不是能上云，也不能只用「敏感」两个字拍板。

落到架构上，先给输入字段做目的和必要性清单，按个人信息、敏感个人信息、重要数据、商业秘密分级；再把供应商地域、留存、训练使用、删除、转委托和审计写进准入。涉及境外接收方时，单独走数据出境判断、影响评估和相应授权流程，不能拿个人信息数量门槛替代告知、单独同意、影响评估等其他义务。处理记录、业务正文和普通运行日志也要分开定保留期，别为了省事全塞进一个日志库。精确法规名称、适用对象和条款口径放在文末官方入口，项目上线时按当期文本复核。

私有化和开放权重自建：别为了面子，也别低估门槛

私有化最大的驱动力就是合规、安全和控制边界。我在车联网行业遇到过客户明确要求行车轨迹、驾驶行为数据不出专有环境，这种时候私有化不是面子工程，而是准入门槛。可行方案也不只有「全部进机房」这一条：本机先处理「开空调、开车窗」这类实时指令，云端只接收完成目的所需的字段；涉及驾驶行为分析时，再根据授权、合同和风险评估决定走境内托管专属实例还是本地部署。

我也见过「为了私有化而私有化」的项目：机器买回来了，模型跑起来了，然后呢？没人会做效果评估，没人会调推理参数，模型升级还得排窗口。私有化的真实成本不只是采购价，还有电力、运维、升级的人力，以及经常被忽略的机会成本——人都拴在底层设施上，就没精力做真正产生价值的业务场景。

开放权重自建的弹性更大，门槛也更高。想微调、量化、做推理优化，团队都有空间；反过来，容量、安全、升级和效果回归也都得自己扛。我给一个很直观的判断：如果团队还搞不定 GPU 推理服务的性能调优，就别急着自建，先把场景价值验证出来。 这不是丢人，这是少交学费。

先把业务事件换算成 LLM 负载

IoT 项目特别容易在这里算错。探头每隔几秒上报一次，不等于每条遥测都调用一次大模型。规则引擎、流计算和传统异常检测应该先筛选、聚合，把需要语言理解或报告生成的少量事件交给 LLM。可以按这条链算：

设备上报量
× 有效数据率
× 异常候选率
÷ 每个分析窗口聚合的事件数
× 需要 LLM 复核或生成的比例
= LLM 请求量

LLM 请求量 × 平均输入 Token / 输出 Token = Token 用量
峰值到达率（req/s）× 平均响应时间（s）≈ 在途并发

给个纯演算示例，不代表任何行业统计：假设一天有 100 万条设备上报，清洗后 98% 有效，其中 1% 进入异常候选；每 20 条聚合成一个温控事件，只有一半需要生成文字报告，那么是 1,000,000 × 98% × 1% ÷ 20 × 50% = 245 次 LLM 请求，不是 100 万次。这里的 98%、1%、20 和 50% 都必须换成企业自己的观测数据。吞吐看 req/s、Token/s 或 Token/min，并发看同一时刻在途请求数，两者不能混着报。

TCO 不只比较 Token 和显卡

API 月成本可以从「输入 Token 费 + 输出 Token 费 + 缓存/批处理 + 专属吞吐 + 网络与存储 + 重试放大」算起。自建月成本则要把「服务器或云 GPU 折旧/租赁 + 机房与电力 + 软件与支持 + 人员 + 监控安全 + 容灾冗余 + 升级回归」放在一起。单位成本要除以实际成功业务量，不能拿满载理论吞吐当分母。

方案	固定成本	变动成本与弹性	数据与控制边界	团队责任	更常见的适用条件
共享托管 API	低到中	按量为主，峰值弹性较好；价格、限流和缓存规则会改变曲线	数据进入供应商边界；是否出境按实际链路判断	供应商管模型服务，企业管数据最小化、评测、权限和降级	流量不确定、验证期、团队暂不具备推理运维能力
云上专属实例 / 托管专有云	中到高	常有保底资源或订阅，弹性取决于合同	租户隔离、地域和运维访问需写清	双方按合同分工，企业仍要做业务治理	需要更强隔离、稳定容量与厂商支持
企业机房自建开放权重	高	利用率高时可能摊薄，峰值冗余和升级会抬高成本	企业控制较多，供应链与远程运维仍需审查	企业承担推理、容量、安全、升级和效果回归	内网硬约束、负载稳定、已有 GPU 平台与专业团队
边缘 / 端侧模型	设备与适配投入高	云调用少，但受功耗、存储和车型碎片化约束	原始数据可就地处理	还要管理 OTA、模型压缩、兼容与回滚	地库、矿区、弱网下的低延迟指令和数据预处理
混合路由	建设复杂度中到高	可按风险、质量和成本分流	不同数据走不同路径，策略必须可审计	要维护网关、分类分级、评测和多路降级	场景多、数据等级不同、既要弹性又有内网要求

决策时，我会看一条很朴素的式子：

三年 TCO = 建设与迁移成本
         + 36 ×（模型/算力 + 人员 + 机房网络 + 安全合规 + 运维支持）
         + 扩容、故障与退出成本

单位成功任务成本 = 三年 TCO ÷ 三年内通过质量门槛的业务任务数

API 用量变大后未必比自建贵，自建也未必省。负载波动、模型大小、延迟目标、GPU 利用率、人员复用和供应商折扣都会改变交叉点。把候选方案放进同一套业务回放和容量压测，用 p95 延迟、成功率、质量通过率和单位成功任务成本说话，才算同口径。

冷链案例：四个问题问完，答案才会长出来

举个完整的例子，看这套方法怎么落地。前年我帮一家做冷链运输的公司做选型，他们的场景是：几百辆冷藏车的温控探头持续回传，系统分析温度异常的原因，再给调度员生成处理建议。

第一个问题，数据和动作风险是什么？报告里可能带司机身份、轨迹、客户和货物信息，确实敏感，但「敏感」不等于一句话排除所有托管服务。要看能不能最小化、供应商处理地域和留存怎样，以及合同和准入能不能过。

第二个问题，真正的 LLM 负载有多大？几百辆车 7×24 小时上报，不等于每条遥测都调一次模型。时序规则先判断持续超温、传感器漂移和开门事件，再按车辆与时间窗聚合；只有证据冲突或需要生成报告的事件才进入模型。峰值异常事件有多少，得拿真实数据算。

第三个问题，团队扛不扛得住？他们当时有三个平台工程师，没有 AI 推理运维经验，直接开放权重自建很容易把精力全耗在底层。第四个问题，有没有离线要求？地库、偏远线路的即时告警要在车端或规则层完成，文字报告可以等网络恢复再生成，不能把两件事混在一起。

四个问题问完，答案可能是境内托管 API，也可能是专属实例、自建或混合方案，不会只因为「商业数据敏感」或「车辆一直上报」就自动冒出唯一选项。 这才是选型，不是拍脑袋。

现实中更常见的答案其实是混合：不同数据、动作风险和负载走不同的路。我自己的原则还是那句话：能用规则和小模型解决的别抬到大模型；能最小化的数据别整包发送；价值没验证前别锁死重资产；有内网或合同硬约束，也别为了接入快绕过准入。 反过来做，团队往往先在硬件和运维上交一轮学费，业务价值还没来得及验证。

下一节我们换个视角，聊聊不同规模的企业，整体落地规划应该怎么做。

官方法规核验入口

• 《个人信息保护法》：https://www.cac.gov.cn/2021-08/20/c_1631050028355286.htm
• 《促进和规范数据跨境流动规定》：https://www.cac.gov.cn/2024-03/22/c_1712776611775634.htm
• 《网络数据安全管理条例》：https://www.gov.cn/zhengce/zhengceku/202409/content_6977767.htm
• 《数据安全法》：https://www.cac.gov.cn/2021-06/11/c_1624994566919140.htm

本节只给技术选型时的核验框架，不替代企业法务、数据合规和行业主管部门意见。