第九章 生产级硬化
9.5 部署形态与私有化
承前：灰度和回滚解决"怎么安全地上线"，这一节解决"上线到哪"。SaaS、私有化、混合——三种部署形态对应完全不同的成本结构、合规边界和工程责任。对中国客户还有一道必答题：国产模型的私有化部署。这一节讲清楚三种形态的边界怎么划，以及私有化路线里最容易踩的坑——把"能部署"误当"能干活"。
9.5.1 三种形态：SaaS、私有化、混合
SaaS（公有云多租户） 混合（边界部署） 私有化（客户机房/专有云）
┌──────────────┐ ┌──────────────┐ ┌──────────────┐
│ 厂商云端统一 │ │ 敏感数据/执行 │ │ 全栈部署在 │
│ 运营，客户接入 │ │ 在客户内网， │ │ 客户环境，厂 │
│ 数据出客户网络 │ │ 推理可上云 │ │ 商远程运维或 │
└──────────────┘ └──────────────┘ │ 驻场 │
上线最快/最便宜 平衡型，边界要划清 └──────────────┘
合规难度看数据敏感度 最常见于大客户 最贵最慢，强监管首选SaaS 形态：模型调用、Agent 服务、日志都在厂商侧，客户通过界面或 API 使用。上线最快（周级）、成本最低（分摊基础设施）、升级自动享受。代价：数据要出客户网络——会员数据、业务数据是否允许出境/出网，是合规部门的第一个问题。
私有化形态：全栈部署在客户机房或客户专有云，数据不出客户边界。强监管行业（金融、政务、医疗、军工相关）常常是硬要求而非选项。代价远不止许可费：模型推理要 GPU 算力（客户机房有没有？谁采购？）、运维要驻场或远程接入（客户网络隔离怎么破？）、升级周期从"天"变成"月"（走客户变更流程）。
混合形态：最常见的务实解。敏感数据和处理在客户内网，非敏感推理上云。边界设计是 FDE 的核心工作：什么数据可以出网（脱敏后的特征？不含 PII 的聚合分析？）、什么必须留下（会员全量数据、审计日志）、执行动作的连接器永远在内网。混合形态的部署架构图要拿给客户法务和 IT 双方签字确认——边界含糊是后期扯不清的根源。
9.5.2 私有化的真实成本：客户机房里的每一件事都是你的问题
私有化部署后，"客户机房的硬件、网络、运维"从背景板变成主战场。FDE 上线前要把这张清单过一遍：
- 算力：GPU 型号与数量是否满足目标 QPS 的推理需求（7 章压测数据在这里兑现）；备件与扩容路径；算力不足时降级方案（量化模型？减并发？）。
- 网络：客户内网到模型 API 出口（如果混合）的链路；机房内服务间带宽；客户网络 ACL 会不会在你部署完第三天突然收紧。
- 运维：谁来重启挂掉的推理服务——客户的运维不熟悉 LLM 栈，你的团队不在现场；远程接入的合规通道；7×24 值班怎么排。
- 升级：模型权重动辄几十上百 GB，走客户内网分发的时间；变更管理流程要提前多久提单。
- 离线依赖：私有化环境通常无公网，你的产品里所有"启动时拉取最新配置/打点上报"的逻辑都要改造。
经验法则：**私有化交付的工作量约等于 SaaS 交付的 2-3 倍，其中"纯 AI"的部分只占一半，另一半是传统企业软件交付的脏活。**报价、工期、人力配置都按这个系数做，别按 SaaS 的直觉报。
9.5.3 国产模型私有化：能力差异大，先验证再选型
国产模型在私有化场景是主要选项（DeepSeek、Qwen、GLM 等开源开放权重，可商用部署），但**"开放权重、可私有部署"和"在你的任务上够用"是两回事**。国产模型之间的能力差异很大，且不同模型在不同能力维度（推理、指令遵循、工具调用、长上下文）上各有强弱——闭源 API 里一行 model= 的切换，私有化后是一次选型决策加一次部署工程。
所以大纲的这条要求是硬规则：**先按模型能力测试标准验证，再定私有化选型。**用第 7 章建好的评估集——本来就是你业务的题目——对候选模型做离线评测：
- 用评估集（建议 500+ 条，覆盖 9.1 的四类输入）对每个候选模型跑分，重点看工具调用格式正确率、拒答行为、指令遵循；
- 用红队用例集（9.2）跑安全性；
- 用压测脚本验证在客户实际算力上的吞吐与延迟（开源模型推理性能与部署框架、量化方案强相关，标称参数量说明不了问题）；
- 输出选型报告给客户 IT——这一步既是工程决策，也是给客户的合规交代（"为什么选这个模型"将来是审计问题）。
另一个工程要点：模型抽象层（8.2/9.4 反复出现的配置化路由）在私有化场景更重要——私有化模型迭代慢，你常常要"云上模型打头阵、私有模型跟后续"或"不同场景路由不同模型"，9.6 成本工程会给出路由的具体设计。
9.5.4 治理与责任矩阵：写进配置，不只是写进文档
生产上线后，客户要的不是一份"治理文档"，是可执行的治理。核心是责任矩阵：每类事项（模型行为、数据质量、基础设施、业务规则、安全事件）的 RACI（谁负责执行/谁负责决策/被咨询/被知会），甲乙双方签字。大纲的提法"治理与责任矩阵、合规做进配置"，后半句是关键：合规要求要落成系统里的配置与机制，不是 PDF 里的承诺。
举例：合规说"会员手机号不能出现在任何日志里"——做进配置意味着：PII 脱敏规则在日志管道里是一道可配置的处理器，规则版本化管理，审计接口能导出"脱敏规则当前生效版本与变更历史"。合规说"高危动作必须双人审批"——做进配置意味着：HITL 分层矩阵（9.3）里对应格子是 dual_approval，改这个格子要走配置发布流程。当合规是配置，审计就是一次 API 调用；当合规是文档，审计就是一次全员加班。
9.5.5 运营交接：运维手册、培训、升级流程
项目上线不等于 FDE 撤场，而是运营交接的开始（尤其订阅制，8.3）。交付四件套：
- 运维手册：架构图、日常巡检清单（9.3 大盘的每日/每周项）、常见故障与处置（含"什么时候自己处理、什么时候打电话"）、回滚手册（9.4 的三条退路操作步骤）。
- 培训：分角色——IT 运维学监控与发布流程；业务运营学 HITL 确认与 bad case 反馈；督导学看大盘。培训要有考核，不是放一遍录像。
- 问题升级流程：L1（客户运营自助）→ L2（客户 IT 按手册处置）→ L3（厂商支持工单，SLA 分级响应）→ L4（FDE/研发介入）。每一级有响应时限和升级标准，写进支持合同。
- 接入客户统一 Agent 管理平面：如果客户已经建（或在建）统一的 AI 管理平台（统一的模型网关、审计视图、权限中心），你的系统要能接入它的管理平面而不是自成孤岛——这经常是 IT 负责人在 9.1 评审会上提出的硬要求，提前预留接口（模型调用走客户网关、审计字段按 9.3 的标准导出格式）。
9.5.6 沙盘：青禾的形态选型与一次边界事故
青禾最终选了混合形态。决策过程值得复盘，因为它是典型的三方拉锯：增长副总裁要快（倾向 SaaS）；合规与法务盯着会员数据（倾向私有化）；IT 负责人给的第三条路是"分数据定边界"。最终边界方案：
内网（数据不出） 云端（可出网）
┌────────────────────────┐ ┌──────────────────┐
│ 会员全量数据/CRM 读写 │ │ 模型推理 API │
│ 发券/打标连接器(执行) │ ←脱敏→ │ Agent 编排服务 │
│ 审计日志(原始) │ 请求 │ 非敏感分析/长文本 │
└────────────────────────┘ └──────────────────┘
出网内容: 脱敏后的会员特征(无手机号/证件号)
留内内容: PII、全量明细、执行通道、审计原文
边界文件: 《数据边界说明 v1.2》法务+IT 双签上线第二个月出过一次边界事故，很小但很典型：运营在对话里粘贴了一段包含会员手机号的原文让 Agent 分析，这段文本作为"用户输入"发到了云端——脱敏管道管住了系统数据，没管住用户自己输入的内容。告警（PII 出口扫描，9.2 输出侧护栏的镜像用在出网方向）10 分钟内报警，值班 FDE 按预案处置：云端日志隔离删除、复盘出根因、修复方案是出网前对用户输入也过一遍 PII 识别（本来只在入库管道有）。这次事故的处理记录进了合规台账，反而成为"边界有人守"的证据。
这个沙盘的教训迁移到任何混合部署：边界不是一个静态的架构图，是一条要持续巡逻的防线——数据会从你没料到的通道（用户输入、报错信息、日志回传）漏出去。边界审计要有定期演练，像 9.4 的回滚演练一样排进日历。
9.5.7 私有化选型的算力核算：一个可套用的估算方法
私有化方案谈崩最常见的原因不是价格，是算力估算双方差一个数量级。给一个 FDE 可用的估算方法（以青禾评估私有化推理为例）：
第一步，从压测数据取单 token 吞吐：候选模型在客户提供的 GPU（如 2×A800）上用 vLLM 实测，得出生成吞吐（token/s/卡，量化前后各测一次）。第二步，算峰值需求：业务峰值 QPS × 每请求平均输出 token（如 50）÷ 9.5（早高峰 3 倍均值）= 峰值 token/s。第三步，除以单卡吞吐再加 30% 冗余（预填充与生成交错、长上下文请求波动），得出卡数。第四步，加一倍冗余或声明降级策略——私有化环境没有"云上再开十台"的弹性，容量规划必须保守。
示例（沙盘数字）:
峰值 8 req/s × 输出 250tk = 2000 tk/s 生成需求
单卡实测吞吐(vLLM, 72B-FP8): ~140 tk/s → 需 15 张 → +30% ≈ 20 卡
× 2 环境(生产+预发) = 40 张 A800 —— 客户预算爆炸
→ 降级路径: 主推理量化到 INT4 + 请求排队 + 溢出路由到云端
(混合形态的第三个理由: 算力弹性)这张算力表在谈判桌上的价值：客户 GPU 采购部门拿到的不再是"大概要几台机器"的含糊说法，而是一张可挑战、可砍价、可分期的清单——数字越具体，谈判越快。同时它暴露了算力现实对方案的反向约束：如果客户只有 8 张卡，方案就从"全私有"自动变成"混合 + 溢出路由"，比你在会议室里争论半天形态选择有效得多。
最后一个提醒：算力估算必须以客户实际硬件上的实测为准，厂商发布的 benchmark 数字在你的部署框架、量化方案、上下文长度组合下可能差数倍——这是 9.5.3 "先验证再选型"在算力维度的重申。
9.5.8 要点总结
- 三形态：SaaS 快而便宜但数据出网；私有化合规强但工作量约 SaaS 的 2-3 倍（一半是传统交付脏活）；混合最常见，边界要法务+IT 双签。
- 私有化清单五项：算力、网络、运维、升级、离线依赖——客户机房的每件事都是你的问题。
- 国产模型私有化先验证再选型：评估集跑分 + 红队 + 客户实际算力压测，输出选型报告（工程决策兼合规交代）。
- 合规做进配置：脱敏、双人审批、HITL 分层都是可配置、可版本化、可审计的机制，不是 PDF 承诺。
- 运营交接四件套：运维手册、分角色带考核的培训、L1-L4 升级流程、接入客户统一管理平面。
参考资料
- DeepSeek-V3 / R2 开源模型 — Hugging Face — DeepSeek 官方开源权重仓库，国产模型私有化部署选型的第一手来源。
- Qwen 系列开源模型 — Hugging Face — 阿里通义千问官方开源仓库，多尺寸权重适配不同算力条件。
- vLLM Documentation — 开源推理引擎官方文档，私有化部署的吞吐、量化与部署实践，支撑"按客户实际算力验证"。
- OWASP Top 10 for LLM Applications — OWASP 清单，LLM03 供应链与 LLM02 敏感信息风险，私有化与数据边界的审查基准。