deepseek本地部署+构建企业级私有知识库

很多团队卡在同一个位置：模型能在测试机上跑起来，但一接上公司文档、一放到内网给几十个人用，就开始出问题——检索答不准、并发一上来就排队、许可证和合规没人说得清。这篇不讨论「本地好还是调 API 好」，只讲落地时该按什么顺序做决策、每个决策看哪些指标，以及什么条件下这套方案根本不该上。

很多团队卡在同一个位置：模型在测试机上跑通了，一接上公司文档、一放进内网给几十个人用，问题就来了。检索答不准、并发一上来就排队、许可证和合规没人说得清。这篇不讨论本地好还是调外部接口好，只讲落地时按什么顺序做决策、每个决策看哪些指标，以及什么条件下这套方案根本不该上。

先立一个前提：本地部署加私有知识库，本质是两个独立的工程，只是最后拼在一起。模型这块解决的是「谁来读」，知识库这块解决的是「给它读什么」。哪一块没做好，另一块换多大都补不回来。下面按决策顺序往下走，每一步都给出判断标准和可执行动作，拿不准的数字一律到站内对应页面核对当时的实际情况。

先确认你要的到底是本地模型还是私有知识库

这两个词经常被混着说，但它们对应的成本完全不同。本地模型解决的是「数据不出内网」和「推理过程可控」，私有知识库解决的是「答案有依据」和「权限能隔离」。很多团队一上来就说要做前者，聊半小时才发现真正让业务方不满意的是后者：答得不对，而不是算得不够快。

把需求拆成三个独立问题，答案会直接决定方案形态。这三个问题跟模型大小没关系，先问清楚再选技术栈，能省掉后面反复返工。

• 数据能不能出内网：只要有一条硬性规定说不能，本地部署就是前提，没什么可商量的；如果只是「最好不要」，那混合方案值得先算一笔账
• 答错一次的成本有多高：内部查资料答偏了没人受伤，那就优先追速度；如果答案会被拿去对外回复或者进正式流程，就必须做答案可追溯和人工复核入口
• 每天多少人来问、集中在什么时段：这决定你要不要上并发调度，也决定峰值配置该怎么留余量

什么情况下这个拆分不适用：如果业务方的真实诉求只是「少打几个字就能查到制度文件」，那本质上是个搜索问题，用一个轻量检索组件加提示词模板就够，上本地大模型属于过度设计。判断办法是问一句：如果检索结果原样返回给用户，够不够用？够，就别急着上模型。

按显存倒推模型档位，而不是按参数名气挑

选型最容易被带偏的一步，就是先定「要用哪个参数规模」，再回头发现卡装不下。正确顺序反过来：先量出你手上卡的实际可用显存，再决定跑哪个量化档位。参数名气跟实际体验不是一回事，量化档位与质量的取舍需要拿你的真实文档集跑一轮才知道，具体的档位对照可以到 /models/deploy 做一遍测算再定。

还有一个必踩的坑：把「能跑起来」和「能同时服务多少人」混为一谈。单请求跑通，只需要显存装得下权重；多人并发，还要额外留出 KV 缓存和上下文长度的余量。这两笔账要分开算。

1. 定上下文长度先确认业务问题最长会拼进去多少内容。上下文开得越大，单请求占的显存越多，这个参数是后面所有测算的起点。
2. 定并发目标问业务方高峰期大概多少人同时在线，而不是拍一个「越多越好」。这个数字乘以单请求占用，就是最粗的显存需求。
3. 算 KV 缓存占用并发数乘以上下文长度再乘以每 token 的缓存开销，得到缓存总量。这一步最容易超，留一点余量比卡在临界点上强。
4. 加上权重占用再对比权重加缓存对比可用显存，差额不够就先降量化档位，或者先降并发目标，再谈加卡。

什么情况下不用按峰值算：如果只是内部几个人偶尔查资料，按峰值并发配卡就是浪费。按单请求跑通的最小配置来，把省下的资源留给文档解析和向量化这些更影响体验的环节。

推理框架怎么选：先看你要的是吞吐还是好维护

推理框架的取舍，本质是「面向多人并发的服务」和「面向单机试验的运行时」之间的取舍。前者通常选吞吐型框架，支持连续批处理和多卡并行；后者操作简单、换模型方便，适合验证阶段。两边的差别可以对照 /vllm-vs-ollama-selection 的选型思路，但别照着抄结论，要按自己的并发目标对号入座。

部署方式上，优先容器化，把模型权重挂成外部卷。这么做的好处很实在：换模型和回滚都只是改一个挂载路径，不用重做镜像。配置文件也一起外置，改参数不用重新构建。

什么情况下别硬上复杂框架：团队没有运维人手，又不追求并发，硬上只会增加故障面。这种情况下，服务偶尔挂掉带来的信任损失，比多花的那些算力钱更值得担心。

知识库这条链路，重点在切分和检索，不在模型

完整链路是这样的：文档解析、清洗、切分、向量化、检索、重排、拼进提示词。本地模型只负责最后一环。前面任何一环出问题，换个更大的模型也救不回来。这也是为什么很多团队换了模型之后感觉没变好——瓶颈根本不在那。

切分是最容易被忽略、又最影响结果的一步。按文档结构走，沿着标题、条款、表格边界切，不要按固定字数硬切。硬切出来的片段本身就不完整，检索再准也是把半截话喂给模型。

1. 先跑通纯向量检索只用向量召回，看目标问题能不能找到对应片段。这一关过不了，后面加什么都白搭。
2. 加关键词混合专有名词、编号、缩写这类词，纯向量经常召不回。加一路关键词检索做合并，能明显改善。
3. 再加重排候选片段多了以后再排一次序，把最相关的顶上来。这一步放在最后，因为前面的召回集不对，重排也无从发挥。
4. 一次只改一个变量每次只动切分规则、或者只动检索策略，跑同一组问题对比，否则分不清是哪一步起了作用。

什么情况下先别调检索：如果文档里有大量扫描件和图片，解析质量会是主要瓶颈。这时先解决 OCR 和版面还原，把文本拿准了，再谈检索调优。否则你是在优化一个输入本身就错掉的环节。

上线前必须压一遍：并发、延迟和失败表现

测试环境能跑通不代表能上线。上线前至少要测三组数据：单请求延迟是多少、目标并发下的排队情况如何、显存打满时系统怎么退化。第三组最容易被跳过，但它决定了出事时用户看到的是什么。

退化表现有两种：一种是变慢，用户等一会儿还能拿到答案；一种是直接报错，用户什么都拿不到。这两种体验差别很大，必须在验收前定下来你要哪一种。

• 并发超限时的降级策略：是排队等、是返回缩短的答案、还是提示稍后重试，三个选项各有代价，提前定好别临时拍
• 请求日志记延迟和命中的片段，用来调性能；业务日志记提问内容，用来改文档和切分规则，这两类别混在一起
• 排查顺序固定下来：先看显存占用是不是长期高位，再看检索耗时占比，最后才怀疑模型本身
• 定期看一遍命中率低的那些问题，它们比任何报错都更能说明知识库缺了什么

多数「答不好」的抱怨，查到最后其实是检索没召回，也就是压根没找到对的片段，模型只能凭常识编。所以排查顺序里把检索排在模型前面，不是为了省事，是因为它命中率更高。

许可证和合规：上会之前先把这两张表填完

技术方案走到评审环节，最容易被问住的不是性能，是许可证和数据来源。这两块不用很深，但必须能当场答上来，临时去查会很被动。

内部要留一份可出示的说明：数据流向图、谁能访问、日志保留多久。这份东西比任何技术指标都更容易在评审时被问到，而且临时补很难补得像样。

什么情况下可以简化：如果只是技术验证阶段的小范围试用，可以先简化流程。但一旦接入真实业务文档，这两张表就必须补齐，没有中间状态。

给自己留退路：模型换代和方案回退怎么设计

本地部署的一个隐性成本，是模型换代时要自己动手。新模型出来了，要不要换、换了会不会更差，这些问题如果没提前设计，每次换代都是一次冒险。

最有效的做法是解耦：把接口层和模型层分开，业务侧只调统一接口，换模型时改的是路由配置，不是业务代码。这样换代的影响面从整个系统缩小到一个配置文件。

• 升级前准备一组固定问题集，新旧版本都跑一遍，对比检索命中率和回答稳定性，只看离线感受很容易误判
• 旧权重至少留一份，向量索引保留可重建的原始文档，配置文件有版本记录，这三样凑齐才叫能回退
• 回退方案要真的演练一次，没演练过的回退方案等于没有
• 什么情况下别频繁换：如果业务对答案一致性要求高，换代带来的波动本身就是风险，宁可慢一点稳一点

判断标准可以简化成一句话：这次换代能解决的具体问题是什么？如果答不上来，只是想用更新的，那这次升级的收益不足以覆盖风险。

什么情况下这套方案不该上

讲完怎么做，还得讲什么时候别做。本地部署加私有知识库是一条完整的工程链路，它解决的是特定问题，不是所有问题。硬上带来的维护负担，可能是团队接下来半年最大的隐性支出。

三种情况要停下来想清楚。第一种，文档量很小、问题集中在少数几个固定场景，用提示词加检索就能解决，上完整链路属于过度工程。第二种，没有稳定的机器和运维人手，本地服务频繁挂掉，用户对系统的信任损失会比直接调外部接口更大。第三种，真正敏感的只是少数几类数据，那就只把这部分留在内网，其余走外部接口，混合方案往往比全本地更划算。

判断办法很土但有效：拿一张纸，左边写「数据不出内网」的具体理由，右边写「维护成本」的具体理由，哪边的理由更具体、更说得出口，就选哪边。全是形容词的那边，通常是没想清楚。