私有化部署不是一道是非题
"我们的数据不能出去"——这句话在企业 AI 项目的第一次会议上出现的频率极高。它通常被直接翻译成"必须私有化部署"，然后讨论就跳到了硬件选型。但这个翻译丢掉了大量信息：哪些数据不能出去？出到哪里算出去？是合规要求还是内部惯例？不同的答案会导向完全不同的部署形态和完全不同的投入结构。
本文提供一份评估清单，帮助技术负责人和数字化负责人在选型之前，把该问的问题问清楚。清单分三部分：数据边界怎么划、算力预算按哪些变量估、运维成本有哪些容易被漏掉的隐性项。文中不涉及任何具体金额，只讲评估方法与变量构成——因为这些数字高度依赖具体规模，脱离场景的数字没有参考价值。
一、三种部署形态与它们的真实差别
1.1 形态一：公有云 API 调用
直接调用云端模型服务。优点是启动快、无需运维、模型能力随服务商升级而升级。风险点在于数据出企业网络边界、调用链路依赖外部可用性、以及长期成本随调用量线性增长。适合场景：数据敏感度低、需要快速验证、调用量尚不确定的早期阶段。
1.2 形态二：专属实例 / 私有网络部署
模型运行在为企业单独划分的资源上，通过专线或私有网络访问，数据不与其他租户混合。它是前两种形态之间的折中：数据不出企业可控网络，同时避免自建机房的全部负担。适合场景：有明确合规要求但尚未到必须完全离线的程度，或者集团有统一的云上安全基线。
1.3 形态三：完全本地部署
模型权重与推理服务全部运行在企业自有机房或指定机房，网络物理隔离。这是数据主权最强的形态，代价是全部的硬件、运维与升级责任由企业承担。适合场景：金融、政务、医疗等有明确离线要求的领域，或者数据本身构成核心资产的企业。
1.4 混合形态往往是实际答案
真实项目里，纯粹的单一形态并不常见。常见做法是按数据敏感度分级路由：涉及客户身份、合同条款、财务明细的处理走本地模型；不涉及敏感信息的通用任务（如公开素材的文案润色）走公有云。这种做法的前提是先把数据分级做出来——这也正是下一节的内容。
二、数据边界清单
在选型之前，先回答下面七个问题。它们决定了你到底需要哪种形态，而不是相反。
2.1 数据分级：哪些必须留在内网
把 AI 链路会接触到的数据逐类列出，标注敏感等级。常见分级维度：是否包含个人身份信息、是否包含商业秘密、是否受行业监管条款约束、泄露后的影响范围。清单要落到具体字段，而不是停在"客户数据"这种粒度——很多时候只有其中两三个字段真正敏感，脱敏之后整条链路的约束会大幅放松。
2.2 数据流向：数据会经过哪些环节
一条完整的 AI 链路通常包含：输入采集、预处理、模型推理、结果后处理、日志留存、效果评估。其中日志留存最容易被忽略——很多合规问题不出在推理环节，而出在调试日志里完整记录了输入内容并存放在了没有同等保护级别的地方。清单里必须包含每个环节的数据落盘位置与保留期限。
2.3 训练与推理要分开评估
用企业数据做模型微调，和把企业数据送去推理，是两个不同性质的问题。前者涉及数据是否会被固化进模型权重，后者只涉及一次性传输。有些企业的合规策略允许推理调用但禁止训练，二者必须分别确认。
2.4 留存与删除：谁保存、保存多久、如何删除
明确三件事：数据在链路中的每一处保留多久、到期后如何删除、删除动作是否可审计。这不仅是合规要求，也直接影响存储规模的估算。
2.5 访问控制：谁能看到什么
AI 系统往往横跨多个部门的数据。原本靠部门隔离实现的访问控制，在统一的 AI 入口面前可能失效。设计阶段必须回答：某个部门的用户通过 AI 提问时，能不能间接获得他本来无权访问的信息。这是私有化部署也无法自动解决的问题，需要在应用层单独设计权限护栏。
2.6 合规资质：模型服务本身的备案情况
在国内提供面向公众的生成式服务，需要相应的算法备案。如果企业使用的是服务商提供的模型能力，应当确认对方的备案情况。菲咏科技的自研模型持有国家算法备案（网信算备编号已在官网页脚公示），这类信息在合规评审阶段通常会被要求提供。
2.7 出境判定：是否涉及跨境传输
如果服务商的推理节点不在境内，或者企业本身有海外业务，需要单独评估数据出境的合规路径。这一条往往是最终否决公有云方案的决定性因素。
三、算力预算：按变量估，而不是按型号估
算力评估常见的错误是直接跳到"买几张卡"。正确顺序是先估负载，再由负载推导资源。下面是需要先确定的五个变量。
3.1 变量一：并发量与峰值分布
关键不是日总调用量，而是峰值并发。很多企业场景的负载高度集中——比如月末结算、开学季、大促期间。按平均值配置资源，会在峰值时全线排队；按峰值配置，则大部分时间资源闲置。先画出一天与一个月的负载曲线，再决定是按峰值配置、还是按均值配置加弹性扩容。
3.2 变量二：单次请求的上下文长度
推理资源消耗与上下文长度强相关。处理一段客服对话和处理一份两百页的合同，资源需求相差很大。清单里应当区分场景，分别估算典型长度与最大长度。最大长度决定显存下限，典型长度决定吞吐量，两者不能混用。
3.3 变量三：延迟要求
用户在界面上等待结果，与后台批量处理隔夜完成，对应完全不同的部署策略。前者要求低延迟、需要常驻资源；后者可以排队、可以用更经济的调度方式。把"实时"和"准实时"分开，很多被标为实时的需求其实允许数秒到数十秒的延迟，这个差别对资源规划影响很大。
3.4 变量四：模型规模的选择空间
不是所有任务都需要最大的模型。信息抽取、分类、格式转换这类任务，中小规模模型往往就能达到可用准确率，资源消耗低一个量级。合理做法是按任务分配模型规模，而不是全站统一用一个大模型。评估阶段应当对关键任务做一次小模型可行性测试，这一步经常能显著改变整体资源需求。
3.5 变量五：是否需要微调
微调需要额外的训练算力，且它是阶段性而非常态负载。评估时要把训练资源与推理资源分开计算，并考虑训练是否可以借用弹性资源、在业务低谷期进行。
四、运维成本：容易被漏掉的隐性项
硬件与算力是显性成本，通常在预算表上不会被漏掉。真正容易被低估的是下面几项，它们构成了私有化部署的长期负担。
- 模型升级适配：底层模型迭代后，提示词与后处理逻辑常需重新调优。这是持续性工作，不是一次性投入。
- 效果监控：需要有人定期检查准确率是否漂移。业务数据分布变化会让原本达标的能力悄悄退化，没有监控就发现不了。
- 数据与索引维护：知识库类应用需要持续更新语料、重建索引、清理过期内容。这部分工作量与业务变化速度成正比。
- 人员能力建设：私有化部署意味着企业要自己承担运维责任，团队需要具备相应技能。培训与人员储备是真实成本。
- 灾备与可用性：本地部署后，可用性由企业自己保障。冗余节点、故障切换、备份恢复都需要提前设计。
- 安全维护：模型服务本身也是需要打补丁、做安全评估的软件系统，不能部署完就不管。
一个实用的经验：把这些隐性项按"每年需要多少人天"来估，而不是按金额估。人天口径更容易在内部达成共识，也更容易与现有团队的产能对照。
五、一条可执行的决策路径
把前面的内容压缩成一条决策路径，可以直接用于内部评审：
- 第一步：做数据分级，落到字段粒度，标出哪些必须留在内网。
- 第二步：画出数据流向图，包含日志与评估环节，确认每处的落盘位置与保留期限。
- 第三步：分别确认训练与推理的合规策略，以及是否涉及出境。
- 第四步：如果只有部分字段敏感，先评估脱敏方案能否解除约束——这一步经常能把方案从形态三降到形态一或二。
- 第五步：估算五个负载变量，对关键任务做一次小模型可行性测试。
- 第六步：把运维隐性项按人天列出，与团队现有产能对照。
- 第七步：如果结论是混合形态，明确路由规则——哪类请求走哪条链路，由谁来维护这条规则。
六、私有化不是终点，是起点
私有化部署解决的是"数据在哪"的问题，它不自动解决"AI 能不能干好活"的问题。见过不少企业投入大量资源完成本地部署，然后发现真正的瓶颈在于：没有梳理清楚要做什么场景、没有准备可用的测试集、没有人负责持续调优。
合理的顺序是：先用低敏感场景把能力和流程验证清楚，同时并行推进私有化的合规与基础设施准备。两条线在能力成熟时汇合，比先建机房再想场景要稳妥得多。
菲咏造智在合作形态上把"私有化平台"单列为一种形态，交付内容包括平台部署、团队培训，以及让企业团队自己具备构建能力——最后一项往往比部署本身更重要，因为它决定了私有化之后企业是持续产出还是持续依赖外部。相关说明与其他合作形态可在 /agent-services 查看；如果想先确认自己的场景对应哪些能力，可以对照菲咏造智 · 能力库中按层级与行业筛选的 70+ 项原子能力清单。
总结
私有化部署的评估，核心不在于选哪种形态，而在于把三组问题问清楚：数据边界到底在哪（七个问题）、负载究竟有多大（五个变量）、长期要投入多少运维（六项隐性成本）。
把这三组问题答完，形态的选择通常会自然浮现，甚至常常会发现——真正需要完全离线的只是链路中的一部分，其余部分有更经济的方案。先做分级，再做选型，这个顺序能省下的不只是预算，还有大量在错误方向上花掉的时间。