本地已经把 Ollama 跑起来了，Dify 里也能看到模型，但一连知识库就报错、一上图谱就超时，索引还要跑很久——这类问题多半不是模型不行，而是服务暴露方式、索引任务编排和超时口径没对齐。这篇按落地顺序讲：先决定 Ollama 怎么给 Dify 看见，再决定 GraphRAG 的索引在哪一步做，最后是超时、并发、日志与召回效果自检。
本地把 Ollama 跑起来、Dify 里也能看到模型，不代表链路就通了。最常见的情况是：模型列表能刷出来，一连知识库就报错，一上图谱就超时，重建索引还要跑很久。这类问题多半不是模型不行，而是服务暴露方式、索引任务编排和超时口径没对齐。
下面按落地顺序讲四件事：先决定 Ollama 怎么给 Dify 看见，再决定 GraphRAG 的索引在哪一步做，然后是超时、并发与降级怎么设，最后是日志、自检和召回效果怎么验收。每一步都给判断标准和可执行动作，照着做能少走一圈弯路。
第一步：让 Dify 真的能看见 Ollama
先分清部署形态：Dify 和 Ollama 是同机、跨机，还是一边跑在容器里。容器里的 localhost 指的是容器自己，不是宿主机，这是连不上最常见的原因。先把 Ollama 的监听地址放开到局域网或容器网络能访问的范围，然后在 Dify 所在的那个环境里去发一次最简请求验证连通，而不是在本地终端验证。
- 同机裸装：直接指本机端口，但仍要确认监听地址不是只绑回环
- Dify 在容器、Ollama 在宿主机：把宿主机在容器网络里的地址填进去，别填 localhost
- 两个都在容器：用同一条容器网络里的服务名互访，别用 IP 硬编码
- 跨机：确认防火墙和监听地址两边都放行，再谈参数
模型要分两类分别登记：对话模型走生成链路，嵌入模型走索引链路。两者地址写法一样，但用途不同，嵌入模型选错或者地址填错，会直接导致知识库建不起来。建议在 Dify 界面之外先把这两类都验一遍，验证通过再进界面配，省得把网络问题误判成参数问题。
第二步：GraphRAG 的索引放在哪一步做
先想清楚图谱从哪来：是让模型从文档里抽实体和关系，还是已有结构化数据直接映射过去。前者慢、吃算力，但对散乱文档友好；后者快，但要求你提前把数据整理成规整格式。这个选择决定了后面索引任务的编排方式，别跳过去。
| 索引来源 | 适合的输入 | 主要代价 |
|---|---|---|
| 模型抽取实体关系 | 非结构化文档、说明文、报告 | 耗时长、吃算力，结果需要抽检 |
| 结构化数据映射 | 已有表格、字段清晰的业务数据 | 前期整理成本高，后期更新要同步 |
| 两者混合 | 主体文档加少量权威表 | 编排复杂，需要明确谁优先 |
把索引拆成两段看：一段是一次性的建图和抽取，一段是每次提问时的检索和回答。这两段的超时和并发要分开设，别用同一套参数。一次性建图任务放后台慢慢跑，不要挂在对话框的同步链路里；同步链路只负责查，查不到图谱就退回普通向量检索，保证用户有兜底答案。
- 先跑纯向量知识库只用向量检索，用一批固定问题确认能答对，这一步不通就先别上图谱。
- 后台建图把抽取和建图放成独立任务，跑完再看结果，别在问答链路里等它。
- 加图谱检索同步链路里先查图谱，查不到或超时退回向量检索，两条路都留日志。
- 对比命中同一批问题分别跑加图谱和不加图谱，看命中率有没有提升，没提升就先不维护这条链路。
小团队起步建议先跑普通向量检索，确认知识库能答对，再加图谱层。一次上全套，出问题时你分不清是模型不行、图谱没建好，还是检索策略写错了。
第三步：超时、并发与降级怎么设
本地推理的耗时波动大，尤其是首次加载模型那一次。连接超时和读取超时要分开给，读超时要留够余量，别照搬云服务那种短值。连接超时短一点没关系，读超时太短会让本来能出的答案被掐掉，用户看到的就是报错。
并发按硬件给。本地单卡同时跑几个请求很容易把显存打满，接着全线变慢，单个请求耗时被拖垮，反而比串行还慢。先用低并发串行跑通，再逐档往上加，每加一档观察单请求耗时和失败率，涨得明显就退回去。
- 降级第一档：图谱检索超时，退回向量检索
- 降级第二档：向量检索也超时，返回固定话术加原文片段
- 降级第三档：整体不可用时给明确提示，而不是让请求一直挂着
- 批量重建索引和线上问答错峰，或者临时调低问答侧并发
- 把降级动作写进日志，否则事后分不清是正常回答还是兜底回答
第四步：日志、自检与效果验收
每次请求至少记四样：走的哪条检索路径、召回了几条、耗时落在哪一段、最终有没有命中兜底。不记这些，慢和错都归因不了，只能靠猜。耗时最好分段记，把模型推理、检索、图谱查询分开，才知道瓶颈在哪。
准备一组固定问题当回归集，分三类：知识库里明确有的、知识库里明确没有的、需要跨文档串联的。改完配置就跑一遍，看有没有退化。图上检索和向量检索分别统计命中率，才知道图谱层到底有没有加分；如果加不加差不多，就先别花精力维护图谱链路。
接口本身的延迟基线可以先量一遍，再判断是模型慢还是链路慢。做法可以参考 接口测速（/tools/speed-test），先排除网络层，再看模型层。模型和价格的实时资料，到 模型资料库（/models） 核对当时的数字，别凭印象估。
| 现象 | 先看哪一段 | 常见原因 |
|---|---|---|
| 知识库建不起来 | 嵌入链路 | 嵌入模型地址或类型填错 |
| 问答偶尔超时 | 读超时与并发 | 并发过高、模型冷启动 |
| 答案没命中 | 检索路径 | 图谱没建好、向量库为空 |
| 整体变慢 | 算力占用 | 重建索引和问答抢资源 |
常见问题
Dify 里配好 Ollama 模型了，为什么建知识库还是报错？
多半是嵌入模型这条链路的问题，不是对话模型。检查嵌入模型是否也指向了同一个 Ollama 服务、模型名是否与本地拉取的一致、Dify 所在环境能否访问到该地址。对话能通不代表嵌入能通，两条链路要分别验证。
本地跑 GraphRAG 索引特别慢，正常吗？
抽取实体关系本身就要对文档逐段调模型，量一大就很慢，这是任务性质决定的。做法是把建图放到后台一次性跑完并落库，提问时只做检索；同时控制单次处理的文档量，分批推进，别指望一次性全量建完。
图谱检索和向量检索要同时开吗？
不一定。先用固定问题集分别测一遍，看图谱层有没有带来实质提升。如果知识库以短文档、问答对为主，向量检索往往就够了；如果是多实体、跨文档关系类问题，图谱才有明显价值。加不加看测出来的差距。
