你大概是这样卡住的：Ollama 已经能把模型跑起来，FastGPT 也想本地装，但一到「填模型地址」这步就懵——是填 Ollama 的端口还是 OpenAI 兼容地址？知识库那套嵌入和重排又要不要单独起服务？这篇按部署顺序走一遍，把两边各自负责什么、配置项怎么对、出问题按什么顺序排查讲清楚，数字和型号你自己按机器去站内页面核。
你大概是这样卡住的：Ollama 已经能把模型跑起来，FastGPT 也想本地装，但一到「填模型地址」这步就懵——是填 Ollama 的端口还是 OpenAI 兼容地址？知识库那套嵌入和重排又要不要单独起服务？这篇按部署顺序走一遍，把两边各自负责什么、配置项怎么对、出问题按什么顺序排查讲清楚。
先给个预期：这篇不涉及具体数字和型号，模型选型、显存占用、接口响应速度这些，你自己按机器配置去站内资料页核对。这里只讲接法和排查逻辑，照着走完你应该能得到一套能问能答的本地 RAG，而不是一堆跑不起来的配置。
先把两边的分工划清楚，别一上来就装
很多人第一次接这两样东西，最大的误区是职责搞混：跑去 Ollama 那边找知识库功能，或者在 FastGPT 里折腾模型权重。实际分工很简单，Ollama 是模型运行时，FastGPT 是应用层，前者对后者来说就是一个可替换的后端接口。
- Ollama 的职责
- 把模型加载起来，对外暴露推理接口；对话、嵌入、重排通常是不同模型，可能需要在 Ollama 里分别拉取
- FastGPT 的职责
- 知识库切分、向量检索、工作流编排、对话界面，它不关心模型怎么跑，只关心接口通不通
- 配置方向
- 永远是「在 FastGPT 里填 Ollama 的地址」，反着配不会成功，也不该成功
还有一种情况值得提前想清楚：如果你只是单机自用、问几个问题，不打算做知识库、不打算给多人用，那两个都上的收益其实有限。真正需要这套组合的场景，是你要在本地跑检索增强、数据不出机器、又想要个能用的界面。
推荐的上手顺序：先跑通接口，再接应用
顺序错了会浪费很多时间。下面这个顺序的核心原则是：每步只引入一个新变量，坏了能立刻定位。跳步的代价是出问题时你分不清是模型、网络、配置还是应用本身的锅。
- 单独验证 Ollama先用命令行或直接请求接口，确认模型能正常出字、连续请求不崩。这一步没过就别往下走，带着问题接应用只会更难查
- 确认网络可达性看 Ollama 暴露的地址和端口，FastGPT 所在的容器或主机能不能访问到。跨容器时写 127.0.0.1 基本是不通的，要用宿主机可达地址
- 在 FastGPT 里配模型按它要求的 OpenAI 兼容格式填地址和模型名，对话模型和向量模型分别配。只配对话不配嵌入，知识库检索会是空的
- 建小知识库做端到端验证丢两三页文档进去，问一个只有文档里有答案的问题，能答对才算真通了。答不出但接口报错，回上一步
配置里最容易踩的几个点
配置这一步报错信息往往很模糊，分不清是格式问题还是网络问题。下面这张对照表把常见现象和大致方向列出来，方便你先缩范围再去查日志。
| 现象 | 先怀疑什么 | 下一步动作 |
|---|---|---|
| 报找不到模型 | 模型名和 Ollama 里的实际名字不一致 | 在 Ollama 侧列出模型确认名称 |
| 连接超时 | 地址不可达或端口写错 | 从 FastGPT 所在环境测一次连通性 |
| 检索结果为空 | 嵌入模型没配或配错 | 单独确认向量模型配置这一项 |
| 检索到了但答错 | 上下文长度或超时参数偏小 | 放宽参数后重跑同一问题对比 |
- 地址写法：容器访问宿主机要走宿主机的可达地址，不是回环地址，能通不代表接口路径对
- 模型名：必须和 Ollama 里的实际名字一致，换模型就得同步改配置
- 嵌入与对话是两条独立配置：只配一条，知识库链路会断在中间
- 参数别设太紧：上下文长度、超时设小了，长文档场景会表现成「检索到了但答不出」，容易误判成模型不行
特别提醒最后一条，这是最容易被误判的坑。很多人一看长文档答不出，第一反应是模型太小，换了一圈模型还是不行，其实是参数卡住了。排查时先把参数放宽试一次，能定位就省下大量试错。想对比不同模型的实际表现，可以到站内的评测页面看当时的记录，别凭感觉换。
出问题时的排查顺序，从下往上查
排查的原则是从底层往上，而不是从你眼前看到的那个报错开始猜。下面这个顺序能帮你快速把问题缩到一层里，避免四五个变量同时跳。
- 先看 Ollama 侧日志请求有没有进来？是直接报错还是正常返回？这一步能分清是压根没连上，还是连上了但模型本身出错
- 再看 FastGPT 侧日志它连的地址到底是什么、是超时还是收到错误码。地址对了再看格式，这一步能区分网络问题和请求格式问题
- 绕过应用直接测接口脱离 FastGPT，直接对 Ollama 发一次请求，确认模型本身正常。变量缩到一个，结论才干净
- 最后才怀疑资源和模型显存不够、模型能力弱属于最后一层。前面三层没排除就换模型，多数时候是白换
这套顺序的核心是「一次只动一个变量」。如果你同时改地址、换模型、调参数，问题解决了你也不知道是哪一步治好的，下次再犯还是不会查。真遇到拿不准的情况，把两侧日志按时间对齐看一遍，通常比换配置快得多。
什么情况下别走这条路
本地部署不是所有场景都划算。下面这些情况下，硬上这套组合的隐性成本可能高于直接买托管服务，值得先评估清楚再动手。
- 要多用户并发、要稳定服务承诺的生产场景：单机推理的排队和吞吐会成瓶颈，先评估换推理框架或加机器
- 团队里没人愿意长期维护机器、跟进升级：本地这套的维护成本是持续的，不是装完就完事
- 知识库规模很大、召回质量要求高：默认嵌入和切分策略往往不够，需要单独调检索链路，工作量可能比部署本身还大
- 数据敏感度不高、只是想快速验证想法：托管接口能让你把时间花在应用逻辑上，而不是环境上
反过来说，如果你的核心诉求是数据不出机器、想自己掌控整条链路、又有人愿意维护，那这套组合是合理的起点。判断标准不是「哪个更先进」，而是「谁愿意为它持续负责」。
本地部署省的是数据外流的顾虑，花的是持续维护的时间，先把这笔账算清楚再装。下一步配置里要填的地址格式、模型清单、以及不同模型在本地的实际表现，站内都有对应的页面可以核对当时的数字，别照着旧截图抄参数。→
常见问题
FastGPT 必须配 Ollama 吗？
不必须。FastGPT 的模型后端是可替换的，Ollama 只是本地起模型的一种省事方式，你也可以接别家 OpenAI 兼容接口。选它的理由通常是数据不出内网、不用按量付费；代价是模型能力受你机器限制，量化档位越低效果越打折。
为什么配好了却检索不到内容？
多数是嵌入模型没配对或没生效。知识库入库和提问都要经过向量模型，这条链路单独配置，和对话模型不是一回事。先确认嵌入模型在 Ollama 里存在、FastGPT 里填的名字一致，再重建一次知识库看是否恢复。
本地跑得慢是正常的吗？
先分清是模型推理慢还是检索慢。同一个问题在 Ollama 直连下也慢，就是算力问题，可以调量化档位或换更小的模型；直连很快、走 FastGPT 才慢，那要看知识库规模和检索参数。测速口径可到 /tools/speed-test 先量个基线。
