围绕企业级DeepSeek私有化部署，从算力评估、推理架构、安全合规到运维赋能，给出可执行的落地路径与关键控制点。
企业引入DeepSeek时，API调用试点往往进展很快，一旦进入生产环境，问题就会从“模型能不能回答”转向“系统能不能稳定、可控、可审计地回答”。私有化部署不是下载模型权重后启动一个推理服务，而是模型选型、算力规划、数据安全、应用集成和运维赋能共同组成的工程闭环。以AI指导老师的项目经验看，落地成败通常不取决于参数规模，而取决于需求边界是否清晰、验收指标是否可量化，以及业务团队能否持续运营知识库和提示词。
1. 需求边界与算力基线评估
企业私有化DeepSeek的第一步不是采购GPU，而是把业务场景和SLA写清楚。知识库问答、合同审查、代码补全和客服辅助对上下文长度、并发量、首token延迟的要求差异很大，知识库问答常使用8K至32K上下文，合同审查可能涉及64K以上长文档，代码助手则对首token延迟更敏感。生产SLA应明确峰值并发、P95首token延迟、输出速度和可用性，并区分哪些场景必须使用满血模型，哪些场景用蒸馏版即可满足。缺少这层界定，后续算力采购很容易出现“按峰值买贵了、按均值买少了”的偏差。
算力基线要同时计算权重、KV cache和冗余。DeepSeek-V3/R1采用MoE架构，总参数671B、激活参数37B，FP8权重约680GB，满血部署通常需要多机多卡80GB级GPU，通过张量并行和专家并行分摊显存；INT4量化可显著降低显存占用，但必须用业务评测集验证精度损失。蒸馏版14B或32B模型更适合单机8卡或更少卡的首期试点。KV cache会随并发数和上下文长度增长，不能只按模型权重估算显存。某大型制造集团在POC阶段用32B蒸馏模型和8卡80GB节点支撑约200路知识库问答，峰值首token延迟约1.2秒，并预留30%显存余量，进入生产后再按实际并发扩容。
存储与网络同样属于算力基线。模型仓库、向量库、日志、备份和评测数据集需要独立容量规划，推理节点之间建议使用IB或RoCE网络，模型加载和存储访问走万兆以上链路，避免权重加载成为扩容瓶颈。POC验收应使用500条以上真实业务问题，记录准确率、引用命中率、拒答率和延迟分布，而不是只看演示效果。只有把业务指标和资源指标绑定，算力预算才能从“拍脑袋”变成可复核的工程决策。
2. 模型选型与推理服务架构
模型选型要围绕任务复杂度和成本展开。满血DeepSeek-R1适合复杂推理、多步骤分析和长文档审阅，DeepSeek-V3适合通用问答与内容生成，蒸馏版32B或14B在知识库问答、坐席辅助等场景中往往已经够用。领域知识优先通过RAG注入，而不是一上来做全量微调；确有风格、术语和格式要求时，再用LoRA做轻量微调，并把微调模型纳入统一评测集回归。某金融机构在合同要素抽取场景中先用32B蒸馏模型加RAG，准确率达到业务阈值后再评估满血模型，避免了首期过度投入。
推理服务架构要把模型能力和工程能力分开。推理引擎可在vLLM、SGLang和TensorRT-LLM之间按硬件与吞吐目标选型，重点验证continuous batching、PagedAttention和prefix caching对并发与长上下文的效果。对外提供OpenAI兼容接口，前面加API网关做鉴权、限流、租户路由和用量统计，底层用Kubernetes加GPU Operator管理推理副本，模型路由根据场景把请求分发到满血模型或蒸馏模型。量化方案不能只看显存下降，FP8、INT8和INT4都要在业务评测集上比较答案质量、引用准确率和拒答表现。
高可用与灰度发布决定生产可用性。推理服务至少保持多副本，模型权重和向量库做冷热分层，热点知识缓存到低延迟存储，网关层设置超时、重试和熔断，避免单次长请求拖垮队列。模型升级要走灰度流程，先导入10%流量，观察错误率、延迟和业务采纳率，再逐步扩大；每次升级前用固定评测集跑回归，记录版本号和配置基线。某零售企业在客服助手项目中把模型版本、提示词版本和知识库版本绑定发布，出现答案质量波动时可在30分钟内回滚到上一组合，显著降低了上线风险。
3. 数据安全、权限与合规控制
私有化部署并不自动等于安全，模型落在企业机房只解决了数据不出域的一部分问题。企业应先做数据分级，明确哪些文档可进入知识库、哪些只能做脱敏后检索、哪些禁止进入模型上下文。传输链路启用TLS 1.3，模型权重、向量库和备份盘做静态加密，密钥通过KMS集中管理并定期轮换，模型文件加载前校验哈希和签名，防止权重被替换。某集团在多子公司共享推理平台时，把财务、人事和研发文档划分为不同密级，低密级租户无法通过提示词绕过检索权限访问高密级内容。
权限控制要落到文档级和字段级。统一身份通过SSO、OIDC或LDAP接入，权限模型采用RBAC与ABAC结合，按部门、项目、角色和数据标签授权；RAG检索必须在召回前执行权限过滤，而不是先召回再让模型判断，否则敏感内容已经进入上下文。审计日志记录用户、时间、问题、召回文档编号、模型版本和输出摘要，保留180天以上，满足追溯和合规检查需要。提示注入防护要覆盖系统提示词隔离、检索内容可信标记和输出审核，对涉及个人信息、合同金额和客户名单的回答设置二次确认或拒答策略。
合规工作要前置到方案设计阶段。涉及个人信息处理的场景需对照个人信息保护法做最小必要评估，涉及等保要求的系统要把推理平台纳入定级备案和测评范围，跨境业务要确认数据出境路径。某制造集团在上线前完成数据分类清单、权限矩阵和审计字段设计，把密钥轮换周期定为90天，并将模型服务日志接入企业SIEM平台。这样做虽然增加了前期工作量，但避免了上线后因权限漏洞或审计缺失被迫停服整改。
4. 运维监控、应用集成与组织赋能
上线只是私有化平台的起点，运维监控决定它能否稳定运行。监控应覆盖GPU利用率、显存占用、KV cache命中率、首token延迟、每token输出时间、QPS、错误率和请求队列长度，用Prometheus采集指标、Grafana做看板，日志进入Loki或ELK，按租户和场景拆分。告警阈值要结合业务峰谷设置，例如队列长度持续超过阈值或P95延迟翻倍时触发通知，而不是等用户投诉。容量预测按周复盘并发和显存增长趋势，模型版本、提示词版本和知识库版本统一登记，灰度发布和回滚脚本纳入运维手册，成本按租户和场景分摊，便于业务部门感知资源消耗。
应用集成要把模型能力嵌入现有流程。OA、ERP、CRM和客服工单系统通过OpenAI兼容接口或SDK接入，文档解析、向量化、检索和重排封装成RAG服务，前端保留引用来源和人工复核入口。AI指导老师在这一阶段的价值不是讲模型原理，而是带业务团队做场景工作坊，把高频问题拆成提示词模板、知识库更新规则和验收标准，并培训坐席、法务和研发人员学会判断何时需要转人工。某零售企业的客服坐席助手先从“推荐回答、人工确认”开始，经过三周培训和每周复盘，坐席采纳率从35%提升到62%，知识库运营小组也形成了固定的文档更新和问题回流机制。
组织赋能要落到可持续的运营动作。项目组应建立由业务负责人、AI指导老师、平台运维和开发组成的轻量CoE，按季度评审场景优先级，按月更新评测集，按周处理bad case和知识缺口。培训内容覆盖提示词编写、引用核验、敏感信息识别和反馈提交，避免把平台当成黑盒问答工具。项目组随后把知识库更新、提示词迭代和月度效果复盘移交给业务运营小组，平台进入常态运营。
