私有化部署和本地部署区别

部门提了句「数据不能出内网」，采购就当成本地部署来询价，结果发现对方只是把机器放进自家机房、账还在别人那儿。私有化和本地部署经常被当成同义词，其实一个说的是谁负责、谁兜底，一个说机器放在哪。这篇按合规、数据流向、运维责任三块拆开，给对照表和排查顺序，方便开会时直接对齐口径。

部门丢下一句「数据不能出内网」，采购转头就按本地部署去询价，听对方说机器放在自己机房，就觉得条件对上了。坐下来细聊才发现：账还在对方那儿，模型升级得联网，出了故障远程通道开在厂商手里。这类误会很常见，私有化和本地部署被当成同义词用，结果合同签完才发现对不上需求。

这两个词说的其实不是一回事：一个讲的是谁负责、谁兜底，一个讲的是机器放在哪。开会前先把口径对齐，比急着比价有用得多。下面按边界、合规、运维三块拆开，最后给一份能直接拿去问供应商的清单。

先定边界：一个讲责任归属，一个讲机器位置

私有化更像是一种权属和责任的安排：模型权重能不能落到你手里，数据往哪流，账号体系和计费在谁那边，出问题谁有权改动。本地部署只回答一个问题——机器摆在哪。机器在你机房，不代表别人不能远程管它，也不代表你拿到了模型的所有权。判断时别只问「能不能本地」，要拆成四问：权重在哪、推理请求走哪、账号计费在谁手里、出问题谁第一时间能改。

最常见的混合形态是：推理机器放在你机房，但调度、账号、版本管理还在厂商那边。这种方案比纯调用API更接近内网，但离完整私有化还有距离。如果需求里明确写了「自主可控」或「退出时能带走」，就得按完整私有化去谈，而不是按本地部署去比价。硬件与规模的测算可以到 /models/deploy 看部署口径，具体数字以页面当时为准。

合规视角：数据流向和备案口径别混着讲

合规审查看的不是机器摆在哪栋楼，而是数据有没有出境、留存多久、谁能访问、出了事能不能审计。这几项要逐项写进合同附件，口头说「绝对不出内网」没有意义。对外提供服务的模型还涉及备案与安全评估，备案主体要和实际运营方对得上，具体条件到 /safety 核对，别拿销售的口头说法当依据。

• 验外呼：抓一遍网络流量，看日志、埋点、授权校验有没有往外发请求
• 验更新：模型和依赖升级是不是必须联网，离线环境怎么分发
• 验通道：厂商远程运维的入口谁来开、谁来关、有没有操作记录
• 验留存：原始请求和推理日志存多久、存在哪、谁能删
• 验退出：合作结束时模型、微调数据、日志能不能完整迁走

这几项里只要有一项说不清，在等保测评或行业审计场景下通常就不适用，别等上线后再补。特别是远程运维通道，很多团队验收时忘了问，等出故障才发现厂商一直在用固定通道连进来，审计时很难解释。

运维视角：谁值班、谁升级、谁背锅

私有化不等于免运维，多数情况是把「厂商替你运维」换成了「你自己运维加厂商远程支持」。值班表、升级窗口、故障响应这些事得在上线前落到纸面，否则第一周就会开始扯皮：你觉得对方该管，对方觉得机器在你那儿该你管。

1. 定变更与升级窗口约定谁能发起升级、提前多久通知、回滚怎么验证，写进运维手册而不是聊天记录
2. 定故障分级与响应时限按业务影响分几档，每档写清响应时间和升级路径，避免所有问题都走同一个工单
3. 定备份与恢复演练模型文件、配置、微调数据分别多久备份一次，每季度至少做一次恢复演练并留记录
4. 对齐基础设施术语离线分发、依赖版本、驱动兼容这些词先统一，可参考 /ai-dict/category/infra，验收时少吵架

还有一种情况要注意：只买了机器、没留支持通道的团队，遇到推理框架版本或驱动兼容问题往往卡在没人能定位，最后只能推倒重来。预算再紧，也要给远程支持留个口子，并把开关权限握在自己手里。

落地前的对照清单与排查顺序

顺序很重要：先定合规红线，再定数据流向，最后才谈硬件和预算。反过来做，很容易买完机器才发现方案过不了审计。下面这份清单可以直接拿去问供应商，逐项要书面答复。

• 权重与许可证归属：交付形式、使用范围、二次分发是否允许
• 更新方式：在线还是离线包，升级失败怎么回滚
• 账号体系：能否脱离厂商独立管理，权限怎么分级
• 日志与审计：留存位置、时长、导出能力
• 远程通道：是否必需、谁能开、有没有操作留痕
• 故障SLA：响应时限、升级路径、赔付口径
• 退出迁移：数据与模型怎么带走、多久完成

小团队不必一刀切。可以先把敏感数据放在自建推理上，非敏感任务继续走官方API，按业务切分而不是按整套系统切分，成本和风险都好控制。租卡和自建的账，到 /compute/tco 按三年口径算，别只比单月账单。