FastGPT 的模型配置集中在自部署配置的模型模块，检查顺序建议从模型类型开始，再核对渠道密钥，随后确认上下文与 token 设置，最后处理重排。每条路径都有明确的入口位置和可观察的失败表现，按顺序核对能减少重复排查。
模型类型检查入口
模型类型决定 FastGPT 在对话、向量化、重排等环节调用哪类模型。自部署场景下，模型配置文件位于 config 目录的模型相关 JSON 中，官方文档在 self-host/config/model/intro 里说明该文件用于声明可用模型及其类型。核对动作是先打开该配置，确认每个模型条目的类型字段与预期用途一致，例如对话模型、嵌入模型、重排模型各自归类正确，再检查模型名称是否与上游服务实际暴露的名称一致。常见失败表现是配置里写了模型但调用时报模型不存在，或者对话正常而知识库检索没有结果，这通常意味着嵌入或重排类型没有正确声明。如果同一上游服务提供多种能力，需要分别声明对应类型，不能只写一个通用条目。检查完成后建议重启服务让配置生效，再进入渠道密钥核对。
渠道密钥与上下文 token 检查入口
渠道密钥和上下文 token 都在模型配置的同一层级处理。渠道密钥对应上游服务的访问凭证，通常写在模型配置的密钥字段或环境变量中，官方文档说明密钥用于鉴权，缺失或错误会直接导致请求被拒绝。核对动作是逐条确认每个渠道的密钥已填写且未过期，并确认密钥与模型条目所属渠道匹配，避免把 A 渠道的密钥填到 B 渠道。上下文与 token 涉及模型可接收的最大上下文长度和单次输出上限，配置项一般以 maxContext 或类似字段出现。核对时要确认该数值不超过上游模型实际支持的范围，过大会在长对话中被上游拒绝，过小会提前截断历史。失败表现包括请求返回鉴权错误、上下文超限报错，或对话进行到一定轮次后突然丢失早期内容。调整后同样需要重启服务并做一次短对话与长对话验证。
重排配置检查入口
重排用于对检索结果做二次排序，配置入口同样在模型配置文件中，需要声明重排模型及其所属渠道。官方文档在模型介绍里把重排列为独立模型类型，说明它和嵌入模型分工不同。核对动作是先确认重排模型条目存在且类型正确，再确认它引用的渠道密钥可用，然后检查知识库或应用侧是否启用了重排。常见失败表现是知识库检索能返回结果但排序不符合预期，或者开启重排后请求报模型未找到。如果上游不提供重排能力，可以暂时不声明该类型，此时检索仍可工作，只是缺少二次排序。检查时还要注意重排模型与嵌入模型的维度、名称不要混用。完成这三类检查后，建议用一条包含明确答案的测试问题走完整流程，观察从检索到回答的链路是否稳定。