FastGPT接入本地大模型如何配置

本地跑好了模型，一到 FastGPT 里就答非所问、超时或者干脆连不上——多半不是模型不行，而是接入地址、向量模型和超时参数没对齐。这篇按配置动作走一遍：先确认本地推理服务对外暴露的接口形态，再对应 FastGPT 的模型配置项逐个填，最后给一套从连通性到问答质量的排查顺序，顺带说清什么情况下本地接入并不划算。

本地推理服务跑起来只是第一步。很多人把模型挂到 FastGPT 上之后，发现答非所问、等半天不出字，或者干脆报连接失败，就回头怀疑模型本身不行。实际情况里，绝大多数问题出在三个地方：接口地址对不上、向量模型没配对、超时并发按云端习惯设了。这三件事都不是模型能力问题，是配置问题。

下面按配置顺序走一遍。先让本地推理服务对 FastGPT 可见，再把对话模型和向量模型分别配好，然后按自己机器的真实斤两调超时和并发，最后给一套出问题时的排查顺序。每一步都带可验证的动作，不是看完就完。

先让本地推理服务能被 FastGPT 访问到

FastGPT 对接外部模型，走的是 OpenAI 兼容那套请求格式和返回结构。如果你的本地推理框架本身提供兼容接口，直接开就行；如果只提供私有协议，中间得加一层适配服务做格式转换，别指望 FastGPT 能直连一个自定义协议。这一步没解决，后面所有配置都是白填。

1. 直接请求一次接口用命令行或接口调试工具，按对话接口和向量接口各请求一次，确认返回结构里该有的字段都在。
2. 核对鉴权头看服务端是否校验鉴权字段。不校验就留空，校验就填对应值，别一边留空一边猜。
3. 确认返回体格式重点看向量接口返回的向量维度，和后面 FastGPT 里配的向量模型是否一致，不一致检索直接失效。

在 FastGPT 里把对话模型和向量模型分别配好

FastGPT 里对话模型和向量模型是两套独立配置。对话模型管的是拿到检索片段之后怎么组织成回答，向量模型管的是用户问题能不能检索到对的知识片段。只配一个，流程就断一截。常见误区是只配了对话模型，测试时问简单问题也能答，就以为通了，一到知识库检索就露馅。

对话模型

负责把检索到的片段组织成最终回答，配错表现为答得别扭或答非所问

向量模型

负责把问题和文档切片转成向量做检索，配错表现为检索不到相关内容

接入地址

按推理服务实际暴露的路径填，注意有的框架对话和向量路径不一样

模型名称

填服务端实际加载的模型标识，不是随便起个名字

配置完先保存，然后发起一次最简对话测试。注意：模型列表里能选中，只代表配置项填完了，不代表调用链路已经通。这一步最容易跳过，也是后面排查时最该回来看的地方。

• 对话和向量两个模型都要单独填，别只配一个就收工
• 接入地址按服务端实际路径走，对话和向量路径可能不同
• 鉴权字段先跑通再优化，别在没通的时候反复改
• 保存后必须发一次真实请求，看返回内容而不只是看有没有报错
• 知识库场景要额外测一次检索，确认向量模型能召回

按本地硬件的真实能力设超时和并发

本地单卡的并发能力通常远低于云端接口。FastGPT 侧如果用云端那套并发参数，请求会堆在推理服务前面排队，表现就是首字越来越慢，最后整批超时。把最大并发往下压，让请求排队发生在 FastGPT 侧而不是把推理服务压垮，反而更稳。具体压到多少，要看你本地卡的实际吞吐去 /tools/speed-test 这类工具页面测一下当时的表现。

还有一类容易被忽略的：批量导入知识库、重建索引这类后台任务，和在线问答抢同一块显存。建议错峰跑，或者限制后台任务的并发，否则两件事互相拖累，用户那边感觉是问答变慢了，实际是索引任务在抢资源。

出问题时的排查顺序

顺序很重要：先测接口通不通，再测模型答不答，最后才看回答准不准。反过来先调提示词，往往是在一个根本没连通的链路上折腾。答非所问优先怀疑切片和向量模型，不是对话模型——检索没召回，换再大的生成模型也救不回来。

1. 第一步，测连通直接请求推理接口，确认返回正常。不通就是地址、网络或鉴权问题，跟 FastGPT 配置无关。
2. 第二步，测调用链在 FastGPT 里发一次最简对话，看有没有返回。能返回说明对话模型链路通了。
3. 第三步，测检索拿一个明确写在知识库里的问题去问，看命中的片段对不对。命中不对，回去查切片和向量模型。
4. 第四步，看回答质量前三步都正常，再调提示词和切片策略。这时候的调整才是有意义的。

排查时把每次请求的耗时、命中的片段数、报错原文记下来，攒够几条再改配置。凭感觉反复盲调，改完也说不清是哪个改动起了作用。关于本地接入值不值、和走中转站相比怎么权衡，可以到 /guides 里的相关指南对照自己的场景看，数字类的对比到 /price-watch 核对当时的情况。