甲方说「要私有化部署」时，他到底要什么：三种含义与报价差异
「我们要私有化部署」——这句话在项目里出现的频率很高，但它的含义高度依赖说话的人。
我们见过按第一种理解报价、按第三种要求验收的项目。 双方都觉得对方不讲理，其实是从一开始就没说同一件事。
这篇讲怎么问清楚。
三种含义，成本差好几倍
第一种：装在我们的服务器上就行
含义：应用部署在甲方的机房或他们自己的云上，但模型可以调用在线 API。
成本：最低。普通服务器就能跑，不需要 GPU。
关键点：这种情况下数据依然会出网——提问和检索到的文档片段要发给模型厂商。甲方可能没意识到这一点。
适合：甲方要的其实是「系统归我管」，而不是「数据一个字节都不能出去」。这类需求比想象中多——很多时候甲方说私有化，真实诉求是不想依赖别人的服务、怕对方涨价或停服。
第二种：数据不能出我们的网
含义：全链路不出内网。这才是合规部门想要的那个东西。
要求：模型也必须本地部署。需要 GPU，显存要够跑得动选定的模型。
容易被漏掉的一点：嵌入模型也要本地部署。 建索引和检索时都要用它，如果它是在线服务，文档内容照样出网。这一点在方案里经常被忽略，验收时才发现。
成本：硬件投入是另一个量级。而且效果要打折——本地开源模型通常不如顶尖的在线模型。
适合：涉及敏感数据、有明确合规要求的项目。
第三种：完全不能连外网
含义：在第二种基础上，服务器根本没有外网连接。
额外要求：
- 镜像和依赖包要提前下载好带进去
- 更新升级要人工带介质进场
- 内网可能需要自己的镜像仓库
- 排障时你无法在线搜资料、无法拉取补丁
成本：实施复杂度再上一层，而且后续维护的每一次都要重来一遍。
适合：涉密单位、金融核心系统这类环境。
怎么问清楚
不要直接问「你们要哪种私有化」——甲方通常答不上来，因为他们没想过这个区分。
问具体的：
「用户提的问题和检索到的文档内容，可以发给模型厂商吗？」
这是最关键的一问。能——第一种就够；不能——第二种起步。
「服务器能访问互联网吗？」
能——第一或第二种；不能——第三种。
「这个要求是谁提的？」
如果是业务部门随口一说，可能有商量余地；如果是合规部门或安全部门的硬性要求，那就没得谈，按最严的做。
「有没有已经通过审批的类似系统可以参考？」
甲方内部往往有先例。照着已经过审的方案做，比自己猜标准省事得多。
方案里必须写明的一句话
不管最后是哪种，方案里都要把数据流向写清楚，让甲方签字确认。
大意是这样：
本方案采用【某种】部署形态。其中，用户提问与检索到的文档片段【会 / 不会】发送至模型服务方。若需实现全链路数据不出内网，需采用本地部署的开源模型，硬件配置与成本另行评估。
这一段是保护双方的。 不写的话，验收时被问一句「你们调的哪家 API」，会非常被动。
而且这不是甩锅，是让甲方在做决定时知道自己在选什么。 很多甲方在了解了成本差异之后，会主动接受第一种方案——因为他们的数据其实没那么敏感。
别把三件事混在一起
项目里最常见的三个混淆，值得单独列出来：
一、「开源」不等于「能商用」。 有些项目源码公开但许可限制商用——比如 n8n 只允许自己内部使用，部署给客户收费很可能越界。而 Dify 和 FastGPT 明确允许交付给企业。详见开源 Agent 平台的许可证差别。
二、「自部署」不等于「数据不出网」。 前面讲透了，这是本文的核心。
三、「私有化」不等于「安全」。 装在内网只是解决了数据流向，权限隔离、访问控制、审计日志这些还得单独做。同一个知识库里，销售能不能查到人事的文件？ 这跟部署在哪没关系。详见知识库权限该怎么设计。
第二种方案的隐性代价：效果会打折
如果甲方选了「全链路不出内网」，有一件事必须提前说清楚，否则验收时会很难看。
本地部署的开源模型，效果通常不如顶尖的在线模型。
这不是危言耸听，是当前的客观情况。而甲方的心理预期，往往是他们平时用在线产品形成的——他们会拿内网系统的表现，和自己手机上用的那个对比。
怎么提前处理：
一、在方案阶段就说明这个取舍。 数据不出网是有代价的，代价就是效果打折。让甲方在知情的前提下做选择。
二、用他们的真实数据做一次对比演示。 同一批问题，分别用本地模型和在线模型跑，把结果摆出来。这比任何解释都有说服力，也能避免验收时的争议。
三、把验收标准建立在本地模型的实际表现上，而不是在线模型的表现上。
四、有个折中方案值得提：知识库问答这类场景，答案主要来自检索到的资料，模型负责的是组织语言。这类任务对模型能力的要求没那么高，中等规模的本地模型往往够用——差距最明显的是复杂推理，而不是照着材料回答。
这一条能帮甲方在成本和效果之间找到平衡点，而不是简单地在「安全」和「好用」之间二选一。
报价时的建议
一、三种形态分别报，让甲方自己选。 把差异和代价摆出来，比你替他们决定好——而且这本身就是专业度的体现。
二、别写死硬件价格数字。 硬件价格会变。写清楚影响成本的变量和结构，让甲方理解为什么是这个量级。
三、把扩容路径写清楚。 现在按试点规模配，将来全量上线怎么扩、大概什么代价。甲方最怕「买了发现不够用还得全换」。
四、运维责任写进合同。 保修期多长、包含什么、升级算不算、响应时间多久、数据备份谁做。含糊过去的结果通常是：出任何问题客户都找你，而你没法收钱。
硬件估算的方法见 FastGPT 部署要多少硬件，部署前的决策清单见 Dify 本地部署前要想清楚的六件事。
我们三种部署形态都做过——客户内网物理机、客户自有云或运营商云、我们托管的云。要判断项目该走哪条路的，可以聊聊。