一边是法务催着「数据不能出内网」，一边是业务问「能不能像公有 API 那样跑」，中间还夹着采购问预算。这篇不讲概念，直接给你三步：先把数据分级、再算显存和并发、最后在私有云托管和本地部署之间选一条起步路线，并附上退出与迁移的检查项。
一边是法务发消息说「这批数据不能出内网」，一边是业务问「能不能像公有 API 那样直接调」，中间还夹着采购问「到底要批多少钱」。这三件事如果混在一起谈，会议一定开不完。私有化部署这件事，顺序错了会白花很多钱：先选模型、先买卡、先比价，都属于顺序错了。
这篇按三步走：先把数据分级，再算显存和并发，最后在私有云托管和本地部署之间挑一条起步路线。每一步都给判断标准和可执行动作，也会写清什么情况下这套做法不适用。数字类的信息一律不在正文写死，需要时到站内对应页面核对当时的报价和规格。
第一步不是选模型，是给数据分级
分级的落点不是给部门贴标签，而是落到具体字段和具体流程。同一份业务输入，进模型的内容、写进日志的内容、落到检索库的内容、经过缓存的内容，外发风险可能完全不同。只给部门打个「敏感」标签，最后谁也不知道该拦哪一段。
| 数据档位 | 典型内容 | 可选路线 |
|---|---|---|
| 可外发 | 公开资料、已发布文案、非涉密问答 | 公有 API 即可 |
| 脱敏后可外发 | 去标识化的客户信息、内部流程描述 | 公有 API 加脱敏层 |
| 绝不出内网 | 原始客户数据、合同、源代码、内部财务 | 私有云托管或本地部署 |
- 先列出模型链路上所有会离开内网的环节：请求体、返回体、日志、检索索引、缓存、监控埋点
- 对每个环节逐条判定属于哪一档，判定结果要有负责人确认，不是技术同学自己拍
- 只有第三档才真正需要私有化部署；前两档用公有 API 加脱敏层通常更省，脱敏口径可参考 /ai-dict/category/safety
- 不适用：监管明确要求全链路本地化的行业，分级只用来决定部署范围有多大，不用来决定是否部署
三条路对照：公有 API、私有云托管、本地部署
这三条路不是好坏排序，是代价不同的三种交易。公有 API 用数据出网换零运维和弹性；私有云托管用一部分运维换数据不出你的网络边界；本地部署用硬件和值班换完全离线可控。选哪条，取决于你的第三档数据有多少、用量稳不稳。
| 维度 | 公有 API | 私有云托管 | 本地部署 |
|---|---|---|---|
| 数据边界 | 出网，依赖对方策略 | 不出你的 VPC | 完全离线 |
| 运维量 | 几乎为零 | 中等，管实例和网关 | 高，管硬件到框架 |
| 弹性 | 最好，按量伸缩 | 受实例规格限制 | 受本机资源限制 |
| 成本形态 | 随用量线性涨 | 固定租费加部分弹性 | 前期投入大，后期边际低 |
| 适合场景 | 前两档数据、用量波动大 | 第三档数据、用量中等且稳定 | 数据绝不能出机房、用量稳定 |
判断时可以先问两个问题：第三档数据占比有多大？峰值和均值用量差多少倍？占比小、波动大，就往前两条路靠；占比大、曲线平，本地部署的账才容易算平。
合规不是「买了服务器」就完事
买了服务器只解决了物理位置，合规要能回答四个问题：数据存在哪、谁能读日志、调用记录留存多久、第三方组件会不会回传。这四个问题答不上来，审计或客户尽调时一样过不去。
- 梳理数据流把请求从入口到落盘画成一条线，标出每一段停留的位置和保留时长，确认没有绕开内网的旁路
- 确认组件联网行为推理框架、监控探针、自动更新通道、遥测开关逐个检查是否联网，能关的关掉，关不掉的记录在案
- 核实许可证模型权重、推理引擎、微调产物三者的许可可能不一致，商用前逐项核，别只看模型卡上的说明
- 明确日志与留存写清调用记录留多久、谁能查、删除流程是什么，这既是合规证据也是后续扩容的依据
不适用的情况：纯离线内网且从不引入外部组件时，前两条的压力会小很多，但许可证这条无论如何都要核，因为它跟联网与否无关。
显存与并发：先量需求，再挑卡
挑卡之前先量需求，否则很容易买多或买少。显存占用不只是权重，上下文长度乘并发数带来的 KV 缓存往往更吃显存，长对话和长文档场景尤其明显。先把这个量估出来，再决定卡型和数量。
- 按「上下文长度 × 并发数」估 KV 缓存占用，这一项常被低估
- 量化档位换的是显存和速度，降得越狠，长文本和推理类任务掉得越明显
- 先跑通单并发基线，用 /tools/speed-test 量出延迟基线，再按目标并发反推卡数
- 算不清就用 /tools/model-cost-calculator 先出个数量级，再去看 /models/deploy 的规格口径
不适用的情况：只做离线批处理、对首字延迟没有要求的场景，可以牺牲并发去换更大的模型，这时的估算逻辑要换一套，重点从显存转向吞吐和排队时间。
最小可落地方案：一台机器 + 一个网关
起步别上集群。单机跑一个中小尺寸模型，前面加一层内网网关，统一做鉴权、限流和日志。网关这一层很关键：它把「谁在什么时候问了什么」记下来，既是合规证据，也是后面判断该不该扩容的依据。
- 选一个小尺寸模型先跑通目标是把链路跑通，不是把效果做到最好，先验证网关、鉴权、日志三个环节
- 搭网关做统一入口鉴权、限流、审计日志都在网关层做，业务侧不直连推理服务，方便后续替换
- 用真实任务集验收上线前用 /tools/quality-check 跑一轮自己的任务集，别只看公开榜单分数
- 写死扩容与回退触发条件比如并发持续超过某个阈值多久就扩，或某类任务效果不达标就回退到公有 API，避免临时拍脑袋
这套最小方案的前提是你已经完成了数据分级，且第三档数据量不至于压垮单机。如果第三档数据量很大或并发峰值很高，单机只是过渡，网关这一层仍然要保留，因为它决定了你后面换路线时业务代码改不改。
运维、扩容与迁移：别把自己锁死
私有化最大的隐性风险是被锁死：模型换了要重做一遍，想回公有 API 发现业务代码全是私有接口。避免这件事的办法不复杂，核心是把协议和配置做标准化，把版本管起来。
| 环节 | 要做的事 | 锁死的表现 |
|---|---|---|
| 协议 | 网关层保持主流兼容协议 | 业务代码直连私有接口，换模型就得改代码 |
| 权重 | 确认权重与量化格式可导出 | 换推理引擎要重新转换甚至重新微调 |
| 配置 | 模型文件、配置、提示词进版本管理 | 改一次配置靠手改，无法回滚 |
| 值班 | 明确值班人和回滚方案 | 出问题没人知道怎么退回上一版本 |
不适用的情况：一次性项目或短期验证，可以跳过版本管理，但至少把配置和提示词存档一份，否则几周后没人说得清当时跑的是哪一版。留一条退路这件事，成本很低，收益在你想换路线的那一天才会显现。
把账算全：硬件只是其中一项
私有化的总成本等于硬件或租用费用，加电力和机房，加运维人力，加模型更新与调优的时间投入。前两项看得见，后两项最容易被漏掉，也最容易在第二年变成真金白银的支出。
- 硬件或租用：到 /compute/gpu-rental 核对当时的报价和自己的用量曲线
- 电力与机房：别忽略散热、机柜、网络这些附加项
- 运维人力：值班、故障处理、版本升级都要算人头
- 模型更新与调优：换代时重新评估和适配的时间，是持续的支出
- 公有 API 的对比口径参考 /official-api 和 /inference，注意输入输出单价和缓存口径可能不同
上线前照着走一遍的清单
- 数据侧分级表已确认签字，第三档数据路径已封闭，日志与留存策略已写明
- 性能侧单并发基线和目标并发下的实测数据都有记录，扩容触发条件已写死
- 合规侧许可证、模型来源、组件联网行为三项已核实，有回滚方案和明确值班人
- 接入侧网关鉴权、限流、审计日志齐备，业务侧用兼容协议接入，迁移退路保留
这份清单的作用是让上线的每个环节都有明确的责任人和验证方式。走完一遍再上线，比上线后补材料要省事得多。如果某一条暂时做不到，至少要写清为什么暂时做不到、计划什么时候补。
下一步先把你们自己的数据分级表和用量曲线拉出来，再去对照三条路的代价，结论会比看任何评测都准。站内的部署规格、价格追踪和速度测试工具可以帮你把估算落到数字上，具体报价以页面当时显示的为准。→常见问题
数据不出内网，是不是必须自己买卡？
不一定。私有云托管模式下模型跑在你自己的网络边界内，数据不出你的环境，运维压力比本地机房小。只有合规要求到「物理隔离、禁止任何外部连接」这一档，才必须自建机房。先用数据分级定档，再决定买不买卡。
量化到低比特会不会明显变差？
取决于任务类型。摘要、抽取、分类这类任务通常感知不强；长文本推理、代码生成、数学题掉得明显。建议做法是先用候选量化档位在你的真实任务集上跑一轮，用 /tools/quality-check 对比，别只看别人给的结论。
私有化之后还能不能做微调？
可以，但要先看许可证是否允许衍生模型商用，以及微调后权重的归属。数据不出内网时微调反而更省心，因为训练数据本来就在里面。微调服务商口径可参考 /stacks/fine-tuning。
并发上不去，是该加卡还是换小模型？
先分层排查：是不是 KV 缓存吃满、是不是量化档位太低导致单请求变慢、是不是网关限流设错了。多数情况换更合适的量化档位或调上下文长度就能缓解。加卡是最后手段，因为成本和运维都会上一个台阶。
以后想换回公有 API，会不会很麻烦？
如果网关层保持 OpenAI 或 Anthropic 兼容协议，业务代码基本不用改，只需换 Base URL 和 Key。这也是建议起步就上内网网关的原因之一：迁移成本被压在一层配置里。
