dify ollama deepseek 本地知识库

很多人卡在同一处：Ollama 里模型跑起来了，Dify 也装好了，但一接上知识库就答非所问，或者一到多人用就卡死。这篇不重复「本地部署值不值」那类结论，只给具体动作——按显存挑量化和上下文、算清并发、把分段和召回参数调到能验收，最后补上许可与迁移的检查项。

很多人卡在同一处：Ollama 里模型跑起来了，Dify 也装好了，但一接上知识库就答非所问，或者一到多人用就卡死。这篇不重复「本地部署值不值」那类结论，只给具体动作——按显存挑量化和上下文、算清并发、把分段和召回参数调到能验收，最后补上许可与迁移的检查项。

先说清读者画像：你手上有一台或几台带显卡的机器，有一批不方便外传的内部文档，想把问答放在自己网内跑。如果是公开资料问答、追求开箱即用，那直接用在线服务更省事，本地这条链路适合的是「数据不出内网」这个前提成立的时候。前提不成立，后面所有调参都是白干。

先把这条链路的四个角色分清楚

这条链路上有四个东西各干各的：Ollama 只是推理服务，负责把模型加载起来、暴露一个可调用的接口；Dify 管编排和检索，负责把用户问题变成向量检索、再把检索结果拼进提示词；向量库管索引，负责存片段、查相似度；DeepSeek 在这里只是一个被 Dify 调用的模型，它不知道你的知识库存在。想清楚这四层，出问题时才知道该查哪儿。

Ollama

推理服务层，只负责把模型跑起来并对外提供接口，不参与检索

Dify

编排与检索层，负责把问题向量化、召回片段、拼提示词、调模型

向量库

索引层，存切好的片段和向量，负责相似度查找

DeepSeek

被调用的生成模型，只看到被塞进上下文的内容，看不到原始文档

最常见的误区是把「模型跑通」当成「知识库能用」。模型跑通只证明推理层没问题，检索这一半出问题时你去调模型参数是白费——温度调低、换个提示词，都救不了压根没召回到的答案。

• 排查顺序先分层：答非所问时先看召回的片段对不对，再怀疑生成环节
• 模型跑通只是第一层通过，用一条已知答案的问题测一遍检索再谈上线
• 向量库和生成模型可以是两个不同模型，别强求一个模型全包
• 把这张角色图贴进项目文档，标注每层出问题时的查看入口（日志、向量库检索结果、Ollama 日志）

按显存定模型和量化档位，别先定模型

选型顺序反了就一定返工：正确顺序是显存→量化档位→参数规模→上下文长度。先看手上卡能装多少，再决定用哪一档量化把模型塞进去，然后挑参数规模，最后切上下文长度。反过来先定「我要用某个大模型」，结果就是装不下、只能疯狂降量化，质量掉得比预期多。

量化会带来质量损失，哪一档在你这批语料上够用，只能自己试，别照搬别人的档位结论——别人的语料是合同，你的是论坛帖，结论不通用。上下文也要留余量：系统提示、历史对话、检索片段都要占位置，不能按模型标称上限去填满。

• 把候选量化档位排个序，每个档位跑同一批测试问题，记录哪档开始明显掉准
• 上下文长度按你语料里最长的那个片段加倍预留，不要按模型上限设
• 可核对入口：到 用部署测算按你手上的卡跑一遍
• 模型规格和参数规模对照，到 看当时的数字
• 测完把「哪个档位配哪个上下文」写进配置说明，别只留在某个人脑子里

显存与并发：按目标人数反推，不按峰值猜

在动手配之前，先把三项写下来：使用人数、同时提问的峰值、单次回答可接受的等待时间。这三项定不下来，后面所有配置都是拍脑袋，上线后互相甩锅也没依据。注意是「同时提问」的峰值，不是总人数——一个十人团队可能同时只有两个人真的在问。

并发吃的是显存里的 KV 缓存，不是模型权重那块。上下文开得越大，每个请求占的缓存越多，能同时服务的人就越少——这是最容易被忽略的一刀。很多人把上下文拉满，测单人时很爽，第二个人一提问就开始排队。

这三个是典型的「三选二」关系：量化、上下文、并发，你想同时要三样好，基本要加卡。把这层取舍写进配置说明里，后面有人抱怨慢，至少知道是当初主动换来的。

1. 写下目标场景明确人数、并发峰值、可接受延迟，写在项目文档第一行。
2. 算出显存预算用站内测算工具按模型和量化档位算权重占用和缓存占用，再到 对照显存口径。
3. 定并发上限反推一次能同时处理几个请求，按结果设 Dify 和 Ollama 侧的并发参数，不要留默认无限。
4. 实测验证开几个终端同时打请求，观察延迟曲线，确认高峰不抖再交付。

接进 Dify：接口地址、模型名与连通性检查

接线这一步最常见的坑就两个：地址不通和模型名对不上。Ollama 默认走本地端口，如果你的 Dify 是跑在容器里的，容器里的 localhost 通常指容器自己，访问不到宿主机上的 Ollama——要用宿主机可达的地址，或者把两者放同一个网络里。模型名则要和 Ollama 里实际拉下来的名字完全一致，差一个字符就是 404。

还有一点要提前分清：对话模型和嵌入模型是两回事，要分别指定。别指望一个模型既负责生成回答又负责做向量，那是两个不同的能力，混用的结果就是检索质量莫名其妙地差。

1. 先打通接口在 Dify 所在的环境里用命令行请求 Ollama 的接口，确认能拿到返回，这一步过了再碰 Dify 配置。
2. 在 Dify 里测连通到模型供应商配置里填地址和模型名，点测试，看是否能列出模型或返回正常。
3. 建最小知识库先丢一两份短文档进去，问一个答案明确在文档里的小问题，确认整条链路通。
4. 再接入正式语料最小链路验收通过后，才把所有文档导进去，避免一上来就分不清是语料问题还是配置问题。

分段与检索：决定答得准不准的关键

这一步才是决定「准不准」的地方，前面配得再顺，这里参数不对照样答非所问。分段长度和重叠要按文档结构定：法规、合同这类长句、条款分明的文档，和大段说明文的最优切法完全不同。条款类适合按条款边界切，宁可切碎一点也别把两条无关条款混进一段。说明文类可以切大一点，保住上下文连贯。

Top K 不是越大越好。召回多了噪声也跟着进来，反而把真正正确的片段挤掉，模型看到一堆不相关的内容更容易编。中文语料建议单独评估嵌入模型，别直接用默认那个——不同嵌入模型在中文上的表现差异不小，选法可以到站内嵌入模型相关入口对照。

• 先按文档类型分组，合同类和说明类分开配参数，不要一套走天下
• 分段重叠设一个适中值，保证跨段落的句子不被切断
• Top K 先给偏小的值往上试，看命中率什么时候开始下降
• 验收方法：准备一批「答案在文档第几页」的问题，人工对一遍命中率再上线
• 把每轮参数调整和对应的命中率记下来，下次换模型才有对照基准

验收别只看「答得像不像」，要看「引对段了没」。答案对了但引用的是无关段落，说明检索在瞎撞，下次换个问法就崩。要做到能指出答案来自哪个片段，才叫私有知识库跑通。

上线前的验收清单与不适用场景

上线前用四个问题过一遍，每一条都要有明确的通过标准，不能只凭感觉。这四问也适合做成一张检查表，每次换模型、换量化档位、换分段参数都重跑一遍——参数一动，之前的验收结论就作废了。

第三条尤其重要：知识库里没有答案时，宁可让它说不知道，也不要用模型自己的知识补。这是私有知识库的底线，一旦它开始自己发挥，你就没法判断哪些答案是有依据的、哪些是编的，整库的可信度都没了。

许可边界、迁移与回退

许可这块别只盯模型权重。模型权重、Dify、向量库三者的许可证要分别看，商用前逐项确认，任何一个环节的条款卡住，整个方案就不能直接拿去对外。权重许可的常见边界，比如能不能商用、要不要署名、改过之后怎么算，可以到 对照当时的口径。

回退路径一定要提前留好：旧模型和旧索引先别删，新配置出问题能切回去。迁移的触发条件也提前写进文档，不要等出事再临时决定——出问题时人是最慌的，没提前定好标准就容易互相指责。

• 模型权重、编排工具、向量库三份许可分别过一遍，列成清单存档
• 旧模型文件和旧索引保留一段时间，确认新配置稳定后再清理
• 迁移触发条件提前定：延迟明显变差、命中率下降、并发撑不住，满足任意一条就回退
• 真实用量和成本走势到 对照，判断是该继续优化还是换方案
• 每次改动记录时间、改了什么、验收结果，方便回溯是哪一步引入的问题

最后提醒一句：本地自建不是一劳永逸，它是一个需要维护的方案。语料在变、模型在更新、人数在涨，配置和参数也得跟着动。如果没人愿意定期重跑验收清单，那这套东西上线半年后大概率会退化成「装过但没人信」的状态。