第 29 篇 部署形态决策公有云、私有化与开源模型第二季第 13 篇 · 温习第 06 篇的〈选型是成本决策、不看榜单用自己的测试集测〉、第 13 篇的〈AI 产品可变成本占比高边际成本不趋近于零〉、第 14 篇的〈数据不出域是硬约束〉 · 新增在选哪个模型之上先做以什么形态部署的决策用打分矩阵、私有化 TCO 与降级预案把它落到动作温习第一季的三条结论第 06 篇模型选型本质是成本决策不能看榜单要用自己的测试集测。第 13 篇AI 产品可变成本占比高调用规模上来后边际成本并不趋近于零。第 14 篇数据不出域是金融、医疗、政务等行业的硬约束直接决定算力能放在哪。这三条共同指向一件事选模型之前先要决定模型以什么形态部署。形态一旦定下来成本结构与合规边界就锁死了迁移代价极高。本篇补的就是这一层决策。一、三种形态的本质差别“部署形态回答的不是用哪个模型”而是算力由谁承担、数据去哪里、责任归谁、你能改什么。同一份权重放在三种形态里成本、合规、体验完全不同。维度调用公有云 API云上私有部署自管权重本地或专有云全私有化谁承担算力供应商你租用云资源租户隔离你自有/专有硬件数据流向出域到供应商推理不出你的云账户完全不出域责任边界供应商担可用性与升级你担业务结果你担运维与稳定性供应商担底层资源你全担变更控制权供应商何时升级、是否下架你控制不了部分在你权重、版本你定完全在你单位成本结构按调用量计费无固定投入资源租用 运维人力硬件折旧CAPEX 运维人力上线速度最快接 API 即可较快需部署与适配最慢采购、机房、集成关键认知三种形态不是贵贱关系而是控制权与成本、速度的三角权衡。公有云把控制权换成速度私有化把速度换成控制权。选错形态后面再怎么选型都补不回来。二、决策维度清单与打分矩阵把形态选择从拍脑袋变成可填的表。下面八个维度覆盖了绝大多数决策按权重打分后取总分最高者。维度权重公有云 API云上私有部署全私有化评注怎么打分数据敏感度0.15145涉个人敏感/行业机密则打 5合规要求0.15145有不出域硬规定则打 5调用规模稳定且高0.12344长期高且稳才摊得薄私有化延迟要求0.10345端侧/内网强实时打 5定制深度0.10245需改权重、加插件打 5运维能力0.13531没有专职团队打 1上线速度0.13531两周内要上线打 5供应商风险承受0.12135怕锁卡/停服打 5判定规则可直接套用form_score sum(weight[i] * score[form][i]) # 每个形态各算一次 recommend argmax(form_score) # 但先过两条硬约束硬约束不满足直接否决该形态 if 数据敏感度 4 or 合规要求 4: 否决公有云 API # 不出域是硬边界 if 运维能力 2: 否决全私有化 # 没人运维等于定时事故 if 上线速度 5 and 数据敏感度 2: 优先公有云 API # 速度压倒一切且数据允许 # 硬约束都通过后取 form_score 最高者 # 若云上私有部署与全私有化分差 0.1且运维能力 3选前者先轻私有化试水。这张表的价值不在算出一个神谕答案而在逼团队把隐性判断显性化权重是谁拍的、分数为什么这么打冲突点就浮出来了。三、私有化的真实总成本私有化最常被低估。团队只算硬件采购价忽略买回来之后持续烧钱且会过时的部分。下面用变量把总拥有成本TCO拆开——全部用变量不写死金额。成本项变量表示说明硬件 CAPEXC_HW加速卡、网络、存储采购与机房利用率浪费C_HW × (1 - u)有效利用率u常远低于 1低谷算力闲置即浪费运维人力C_ops_year × n_year年运维成本 × 使用年限含值班与扩容模型升级重做C_rebuild × n_gen每换一代大模型适配/部署/评测要重做n_gen次评测与回归C_eval私有化后质量保障不能外包持续发生闲置与峰值冗余C_idle为峰值预留的容量在低谷完全闲置TCO_private ≈ C_HW × (1 r_waste) C_ops_year × n_year C_rebuild × n_gen C_eval C_idle TCO_public ≈ price_token × call_volume # 随用随付无固定投入盈亏平衡怎么想别比单次推理单价要比总拥有成本 灵活性。私有化摊薄的前提是调用量高、且稳定、且需求长期不变。此时C_HW被大分母摊薄TCO_private才可能低于TCO_public。私有化吃亏的两个场景一是调用量剧烈波动低谷期C_idle和C_HW×(1-u)白白烧钱二是模型代际快n_gen大每次C_rebuild吞噬收益硬件还没贬完就又该换了。还有隐性代价私有化把升级变成你的项目而公有云把升级变成供应商的运维。后者免费获得能力进步前者要自己再花C_rebuild。经验判据把一年预期调用量代入两边公式若TCO_private与TCO_public之差落在单年预算波动范围内优先公有云——灵活性本身就是值钱的项。四、开源模型的适用判断开源权重能不能用唯一正确的判据是第 06 篇那条不看榜单用你自己的 golden set 测。这里只给哪些任务类型通常够用、哪些仍差明显的经验分区最终仍以你的测试集为准。任务类型开源模型通常表现是否够用验证方式格式转换、字段抽取规则性强、确定性高够用用业务样本跑准确率文本分类、打标类别边界清晰时稳定够用混淆矩阵 抽样复核短文本摘要抽取式摘要基本达标多够用人工盲评可读性内部知识问答检索增强检索命中后生成可控够用忠实度 召回率复杂多步推理易在中段出错、不自纠仍差明显多跳推理测试集超长上下文理解长程依赖易丢信息仍差明显长文档抽取测试多模态图/音/视频开源与前沿差距大仍差明显模态专项评测强对齐的安全输出需自建护栏成本高谨慎红队用例库判定动作从你的真实业务里抽N条构成 golden set分别用候选开源模型与候选闭源前沿模型跑记录在你的四指标见第 09 篇上的差距。差距在容忍阈值内就开源超了就闭源或混合。开源省钱只有在 golden set 达标后才成立否则省的是账单、亏的是口碑。五、混合部署分层路由现实里很多产品不是三选一而是敏感走本地、通用走公有云的混合。路由按数据敏感度与任务难度分层。路由设计示例可直接套用if 数据敏感度(请求) 阈值: 路由 - 本地/专有云私有化模型 # 数据不出域 elif 任务难度(分类器) 简单 and 有开源可用: 路由 - 本地开源模型 # 省钱、低延迟 else: 路由 - 公有云前沿模型 # 啃难任务 # 所有路径共用一套输出后处理与评测复杂度代价必须提前计入新增代价说明多套评测每条路径都要单独测质量golden set 要覆盖各路多套降级每条路径都要有自己的兜底否则一处挂全挂一致性保障两路输出风格/质量不一用户会察觉时好时坏路由层失败点路由误判会把敏感数据送出去路由本身故障则整体不可用混合部署不是取各家所长的免费午餐它把单点问题变成单点 × 路径数的问题。只有当确有敏感/通用分界、且分界稳定时才值得上。六、降级与容灾形态选定后要预设供应商侧出事的预案。下面四类风险每个产品都该有答案。风险影响预案触发条件验证方式供应商不可用核心功能停摆切备用供应商 / 降级本地小模型主路连续失败超阈值定期故障注入演练限流rate limit高峰排队、超时本地兜底 异步队列错误率/延迟越线压测观察降级涨价毛利被吞成本预警 重谈/切换单价变动超预算月度成本看板模型下架能力断供权重归档 迁移预案收到停服通知归档完整性校验要点预案写在文档里没用要触发条件可观测、验证方式可执行。建议把以上四项纳入发布前的上线检查项。七、什么时候该重新评估部署形态形态不是一次定终身。出现以下任一信号重新跑一遍第二节的打分矩阵调用量级变化升或降一个数量级原形态的盈亏平衡被打破。合规要求变化新法规/客户合同把不出域从软要求变硬约束。模型能力变化开源在某类任务追平闭源golden set 重测后结论翻转。成本结构变化公有云单价上调或你的人力成本变化使私有化 TCO 重算。供应商策略变化锁卡、限售、停服风险上升供应商风险承受维度打分骤降。重新评估的成本远低于用错形态扛三年。建议每半年例行重评一次不必等出事。八、迁移路径从一种形态切到另一种形态决策很少一步到位。更常见的情况是先用公有云 API 快速上线规模上来后成本压力显现或合规要求升级于是考虑私有化。这时候最危险的动作是把迁移当成一次切换。8.1 迁移不是切换是并行两种形态的输出不可能完全一致——模型不同、参数不同、版本不同、甚至分词与截断行为都不同。因此迁移必须经过一段双跑期在这期间两套系统同时运行、结果互为参照。双跑期有三个容易低估的代价代价项说明是否常被漏算成本叠加双跑期间两套都要付费成本是单跑的一倍以上常被漏算人力投入需要专人对比差异、判定哪边是对的常被漏算切换窗口必须选业务低峰意味着周期可能被拉长有时考虑8.2 三阶段迁移路径阶段目标关键动作退出条件一、影子运行验证新形态能否达到同等水平同一批真实输入同时跑两套用同一份冻结的 golden set 做对照差异逐条归因是模型差异、参数差异还是实现 bug质量差距收敛到可接受范围且差异原因已全部解释清楚二、灰度切流在真实流量上验证按比例切流从个位数百分比起步同时监控质量、延迟、成本、错误率四条线灰度比例下的指标与原形态无显著差异且成本符合预期三、全量切换完成迁移并保留退路全量切流旧路径保留一段时间不要立刻拆掉观察期结束且无回退事件方可下线旧路径8.3 迁移中的三个关键动作金标准对照必须冻结。不能用新形态的新测试集验证新形态。两份测试集不可能是同一把尺子。差异要归因不能只看总量。总体分持平是有欺骗性的——可能一半场景变好了、一半变差了合计抵消。必须按场景与失败模式分层对比。回切条件要提前写死。什么情况下回切、谁有权决定、多久内生效——这些必须在迁移开始前定好。等出问题再讨论损失已经开始计。# 迁移回切预案 触发的任一条件 □ 质量指标跌破原形态同期水平按分层对比不只看总分 □ P95 延迟超出预算 □ 出现原形态不存在的失败模式尤其是安全类 □ 单次成本超预算上限 回切决策人___ 生效时限___ 观察期___ 周8.4 什么时候不要迁移迁移本身有巨大隐性成本。以下情况建议维持现状现有形态的成本占比还很低迁移的收益覆盖不了迁移成本团队没有运维能力承接私有化会从用模型变成运维一套系统业务处于高速变化期此时应当把工程资源放在产品迭代上判断依据迁移的理由应当是必须合规、成本、能力而不是看起来更可控。一页速查部署形态决策一页速查 三种形态 公有云API 供应商算力 / 数据出域 / 最快 / 控制权最低 云上私有部署 你租算力自管权重 / 不出云账户 / 较快 全私有化 你自有硬件 / 不出域 / 最慢 / 控制权最高 八维度打分数据敏感度 合规 调用规模 延迟 定制 运维 速度 供应商风险 每形态算 form_score Σ(权重×分)取最高 硬约束先否决 数据敏感≥4 或 合规≥4 - 否决公有云API 运维能力≤2 - 否决全私有化 私有化TCO ≈ C_HW*(1r_waste) C_ops_year*n C_rebuild*n_gen C_eval C_idle 对比 TCO_public ≈ price_token * volume 比总拥有成本不只比单价波动大/代际快时私有化吃亏 开源模型用自己 golden set 测呼应第06篇不看出身榜单 够用抽取/分类/短摘要/内部问答 仍差复杂推理/超长上下文/多模态/强对齐 混合路由敏感/难 - 本地或私有通用/简单 - 公有云 代价多套评测多套降级一致性路由失败点 必做降级预案不可用/限流/涨价/下架 各填 触发条件验证方式 重评信号量变化/合规变/能力变/成本变/供应商变半年一次常见坑把私有化当成安全终点不出域只是数据保护的一环权重管理、访问审计、输出护栏照样要建私有化不自动等于合规。只算硬件价、不算 TCO忽略利用率浪费与模型升级重做上线一年发现比公有云还贵。用榜单选开源模型榜单任务分布和你的业务无关必须用自己的 golden set 测第 09 篇四指标。为怕供应商而全私有化却无运维团队没人值守的私有化是定时事故供应商风险没降、稳定性风险反倒升了。混合部署上了路由却没建多套降级主路挂时路由把流量导到同样没兜底的旁路整体仍不可用。把延迟要求想当然内网私有化延迟低但跨机房、跨可用区的网络跳数会吃掉这部分优势要实测不要假设。忽视变更控制权供应商悄然后台升级模型你的评测基线漂移却不知情应在合同/接口层锁定版本或可回滚。降级预案只写在文档没有可观测的触发条件和演练真出事时没人知道该切哪条路。一次性定形态后不重评调用量涨一个数量级或开源追平闭源后仍用旧形态硬扛。结语形态决定成本结构与合规边界选型只决定在这副骨架上填什么肉先定形态、再用自己的测试集选模型才不会在错误的骨架上越建越贵。本文为「AI 产品经理入门与进阶」系列第二季第 13 篇总第 29 篇。温习自第 06 篇《微调与模型选型决策框架》、第 13 篇《Token 经济学成本结构与商业化》、第 14 篇《安全合规与负责任 AI》。数据来源部署形态维度的行业通用权衡框架成本以变量公式表示。具体数值随技术迭代变化请以最新数据为准。