本地跑一个 Ollama 当推理后端，上面挂 RAGFlow 做知识库问答，这套组合很多人试过，但真正卡住的地方往往不是装不上，而是接起来之后不稳：检索一慢整条链路就超时，几个人同时问就排队，Ollama 那边挂了前端只报个 500 看不出原因。这篇按工程落地顺序，把适用边界、接入方式、以及上线前该补的几件事讲清楚。
本地跑一个 Ollama 当推理后端，上面挂 RAGFlow 做知识库问答，这套组合不少人试过。装是能装上的，真正卡住的地方往往在接起来之后：检索一慢整条链路就超时，几个人同时问就排队，Ollama 那边挂了前端只报个 500，看不出原因在哪一层。
下面按工程落地的顺序讲四件事：这套组合什么时候值得上、接入按什么顺序跑通、超时和并发怎么设、降级和日志该补什么。只给判断标准和可执行动作，具体数字自己到站内对应页面核对，因为你的机器和别人的机器不是一回事。
这套组合什么时候合适，什么时候别硬上
一句话判断：资料不便出内网、调用量不大、对首字延迟不敏感的内部问答，这套组合很合适。数据完全落在自己机器上，不依赖外部接口，也不产生按量计费的顾虑。反过来，只要下面任何一条成立，就别硬上，先换思路。
- 多人高并发同时提问，或者要求秒级首字返回——本地单机推理的吞吐会先成为瓶颈。
- 知识库经常大批量重建、频繁灌新文档——向量化和解析速度同样受限于本地算力。
- 你其实只是想让模型用上自己的资料，并不需要自托管整套——这种情况先看 api-vs-self-host-decision 那篇的判断口径。
- 机器规格本身就不够：Ollama 的模型、RAGFlow 的向量库和解析进程都要吃内存和显存，装之前先到 /models/deploy 做一遍部署测算，别跑到一半被 OOM 打断。
还有一种情况容易忽略：团队里没人愿意长期维护这套东西。自托管省下的是调用成本，搬回家的是运维成本，包括模型更新、磁盘清理、进程守护。如果没人接手，这就不算合适的场景。
接入顺序：谁调谁，先跑通哪一段
推荐的分工是：RAGFlow 负责解析入库、切分和召回，Ollama 只当生成和嵌入的后端。别让两边都做检索，否则排错时你分不清是哪一层的锅。分工定下来，再按三段验证，不要一次性全接。
- 第一段：单独确认 Ollama 能出字用最简单的调用方式直接问一句，确认服务在跑、模型已加载、能稳定返回。这一步不通，后面都白搭。
- 第二段：确认 RAGFlow 能检索出片段灌一小份文档，只做召回，看返回的分片内容是否相关。这一步只看检索质量，不接生成。
- 第三段：把两段接起来检索结果作为上下文交给 Ollama 生成。哪段断了一眼能看出来，比一次性端到端联调省时间。
模型口径要对齐：生成模型和嵌入模型是两件事。换嵌入模型意味着已有的库要重建，动手前先到 /embeddings 看清模型差异再决定，别改完发现历史数据全废了。接口结构、字段、鉴权这些细节，站内 ragflow-api-quickstart 和 ollama-openai-compatible-setup 已经讲透，这篇不重复。
超时和并发：本地链路最容易崩的两处
本地链路最常见的两个故障是超时和排队，而且它们经常一起出现。超时不要只设一个全局值，按用途分档，快操作设短、慢操作留够，否则一个卡死的检索能把整个请求拖垮。
| 环节 | 超时怎么设 | 设错的后果 |
|---|---|---|
| 检索召回 | 设短，几秒级别 | 设太长，一个卡死的检索拖垮整条请求 |
| 文档解析入库 | 留足，按批次设 | 设太短，大文档总在中途失败 |
| 生成输出 | 按最长回答估 | 设太短，长回答被截断或直接报错 |
| 连接建立 | 单独设一层 | 不区分，分不清是连不上还是算得慢 |
并发别按线上接口的经验开。本地单卡的并发上限基本由显存和批处理决定，建议从很小的并发起步逐档往上加，同时到 /tools/speed-test 量一遍自己的延迟基线，用数字说话，不要凭感觉拍一个数。
- 排队要有上限和超时：请求堆积不报错但越来越慢，比直接失败更难排查。
- 超过阈值就快速失败，把错误暴露出来，而不是让用户等一个永远不来的回答。
- 批量灌库和在线问答别抢同一份算力，安排在错峰时段跑。
- 错峰没安排好，用户提问会突然变慢，你还以为是模型退化。
降级策略和日志：出问题时能说清哪一层坏了
降级的目标不是「看起来一切正常」，而是让用户知道自己拿到的是什么。分三档处理，每档都要在前端有明确标识，否则用户会把没有依据的回答当成有依据的。
- 检索失败
- 退化成纯模型回答，并明确标注「未引用资料」。
- 生成超时
- 返回已召回的片段摘要，让用户至少看到来源。
- 后端整体不可用
- 干脆报错，别硬凑一个看起来正常的答案。
日志至少要记这几项：请求 id、命中的知识库和分片、各段耗时、后端模型标识、是否走了降级。没有这几项，线上偶发慢请求你复盘不出来，只能靠猜。而且要用同一个请求 id 串起 RAGFlow 和 Ollama 两侧，否则一边说检索慢、一边说推理慢，互相甩锅。
最后是评测。固定一组问题，定期跑一遍，比对召回片段和最终答案有没有变化。模型、切分策略、嵌入模型任何一项动了，都先跑一遍再上线，别靠感觉判断。具体看哪些指标、怎么比对，到 /tools/index 里找对应的评测口径。
上线前的检查清单
- 部署测算做过，内存和显存留了余量，没被 OOM 打断过。
- 三段验证各自单独跑通，能说清每段断在哪。
- 超时按检索、解析、生成分档设置，不是一刀切。
- 并发从小往上加过，量过延迟基线，知道自己的上限在哪。
- 三档降级都有明确标识，用户能分辨有没有引用资料。
- 两侧日志用同一个请求 id 对齐，各段耗时和是否降级都记下来了。
- 固定评测集跑过，模型或切分策略一改动就先跑一遍。
常见问题
Ollama 和 RAGFlow 一定要装在同一台机器上吗
不一定，但同机最省事。拆开部署时，两边之间的网络延迟会直接叠加到每次问答上，而且模型和向量库各占资源，反而更难算够不够。如果非要拆，先确认内网带宽和延迟稳定，再按分档设超时。
接起来之后回答很慢，先查哪一层
按耗时拆：如果检索阶段就慢，问题多半在文档解析质量、切分粒度和向量化速度；如果检索很快但出字慢，瓶颈在本地模型和显存。两边耗时都记到同一条日志里，用请求 id 对齐，比反复改参数有效。
本地这套组合需要做评测吗
需要，而且比在线接口更需要。因为本地的模型、切分策略、向量模型都可能被你随手换掉，换完效果变好还是变差没有账单和用量榜可以看。固定一组问题做小规模回归，改动前后各跑一次，成本很低。
