FastGPT 性能优化教程｜零基础可学

前言：为什么 FastGPT 需要做性能优化？

FastGPT 是一个面向大模型应用搭建的平台，常用于知识库问答、智能客服、企业内部助手、流程编排、AI 工作流等场景。很多人刚开始使用 FastGPT 时，通常更关注“能不能跑起来”“知识库能不能回答”“模型效果好不好”。但当用户量增加、知识库变大、并发请求变多之后，性能问题就会逐渐暴露出来。

常见现象包括：

• 对话响应速度慢，用户等待时间过长；
• 知识库检索耗时高，回答延迟明显；
• 多人同时访问时，系统卡顿甚至超时；
• 数据库 CPU 或内存占用过高；
• 向量检索结果不稳定，召回慢且效果差；
• 大模型调用费用升高，但体验并没有明显提升；
• 服务运行一段时间后越来越慢，需要频繁重启。

这些问题并不一定是 FastGPT 本身“不行”，更多时候是部署方式、模型选择、知识库设计、数据库配置、请求流程、硬件资源等多个因素共同造成的。性能优化的目标，不是盲目追求“最快”，而是在成本、稳定性、回答质量和用户体验之间取得平衡。

本文将以零基础用户也能理解的方式，系统讲解 FastGPT 的性能优化思路。你不需要一开始就懂 Kubernetes、数据库调优、向量检索原理或大模型底层机制，只要按照本文的顺序学习，就能逐步建立完整的优化思维。

一、先理解 FastGPT 的基本工作流程

在优化 FastGPT 之前，首先要理解一次完整问答大概经历了哪些环节。只有知道慢在哪里，才能准确优化。

一个典型的知识库问答流程通常包括：

1. 用户在前端输入问题；
2. FastGPT 接收到请求；
3. 系统根据应用配置判断是否需要检索知识库；
4. 如果需要检索，会对用户问题进行向量化；
5. 系统在向量数据库中搜索相关内容；
6. 根据召回结果进行重排、过滤或拼接；
7. 将用户问题、知识库内容、提示词一起发送给大模型；
8. 大模型生成回答；
9. FastGPT 将回答返回给用户，可能还会记录日志。

从这个流程可以看出，影响性能的环节主要有四类：

• 模型调用性能：包括大模型响应速度、Embedding 模型速度、接口稳定性；
• 知识库检索性能：包括向量库查询速度、分段质量、召回数量；
• 系统服务性能：包括 FastGPT 服务本身、Node.js 运行状态、网络延迟；
• 数据库与存储性能：包括 MongoDB、PostgreSQL、向量库、日志数据等。

所以，性能优化不能只盯着一个地方。很多时候，用户以为是“大模型慢”，实际可能是知识库分段太碎、召回数量太大、数据库索引不合理，或者服务器资源不足。

二、优化前先做性能诊断

零基础用户最容易犯的错误，就是还没定位问题就开始乱改配置。比如看到响应慢，就直接换更贵的模型；看到服务器卡，就直接升级机器；看到检索慢，就删除知识库重新导入。这样不仅成本高，还可能让问题更复杂。

正确的做法是：先诊断，再优化。

你可以从以下几个问题入手：

1. 是所有请求都慢，还是部分请求慢？

如果所有请求都慢，可能是模型接口、服务器性能、网络或数据库整体存在瓶颈。

如果只有知识库问答慢，而普通聊天很快，说明问题大概率出在知识库检索、Embedding、向量数据库或上下文拼接上。

如果只有某个应用慢，其他应用正常，说明可能是该应用的工作流过于复杂、提示词过长、知识库配置不合理。

2. 是首字慢，还是整体生成慢？

“首字慢”指用户提交问题后，要等很久才看到第一个字。如果首字很慢，通常可能是检索、重排、模型排队或网络请求耗时较高。

“整体生成慢”指第一个字出现还可以，但完整回答很久才结束。这通常和大模型生成速度、回答长度、输出 token 数量有关。

3. 是低并发慢，还是高并发慢？

如果单个用户访问也慢，说明基础链路就需要优化。

如果单个用户访问很快，但多人同时访问就慢，说明并发能力不足，可能需要优化服务器资源、模型并发、连接池、数据库性能或部署架构。

4. 是偶发慢，还是持续慢？

偶发慢可能和外部模型服务波动、网络抖动、冷启动、数据库临时压力有关。

持续慢则通常说明系统配置、数据结构、硬件资源或应用设计存在长期瓶颈。

三、模型选择是性能优化的第一步

FastGPT 的性能很大程度上取决于模型。这里的模型主要分为两类：对话模型和 Embedding 模型。

1. 对话模型不要盲目选择最大模型

很多新手认为模型越大越好，于是所有应用都使用最强、最贵、上下文最长的模型。但实际业务中，不是每个场景都需要顶级模型。

例如：

• 简单客服问答，可以使用速度较快、成本较低的模型；
• 复杂推理、合同分析、代码生成，可以使用能力更强的模型；
• 内部知识库查询，如果知识库质量高，中等模型也可能表现很好；
• 高频低价值场景，应优先考虑响应速度和成本。

如果你把所有请求都交给大模型处理，系统自然会变慢，费用也会升高。更合理的方式是根据场景分层：

• 简单问题用轻量模型；
• 复杂问题用强模型；
• 需要精确知识的场景依赖知识库；
• 需要逻辑推理的场景再调用高级模型。

2. 控制输出长度

很多应用响应慢，是因为模型输出太长。用户只问一个简单问题，模型却生成一大段解释，这会增加生成时间和 token 成本。

可以通过提示词约束模型：

请用简洁、准确的中文回答。
如果问题简单，回答控制在 300 字以内。
如果需要分步骤说明，最多列出 5 点。

同时，在模型参数中合理设置最大输出 token。不要所有应用都设置非常大的输出上限。

3. 合理选择 Embedding 模型

知识库检索通常需要 Embedding 模型将文本转成向量。Embedding 模型影响两个方面：

• 向量化速度；
• 检索效果。

如果 Embedding 模型速度很慢，那么每次用户提问前都需要等待问题向量化，整体响应自然变慢。如果知识库导入量大，Embedding 速度也会影响导入效率。

建议：

• 优先选择稳定、响应快、兼容 FastGPT 的 Embedding 模型；
• 不要频繁更换 Embedding 模型；
• 如果更换 Embedding 模型，通常需要重新向量化知识库；
• 对于中文知识库，尽量选择中文表现较好的 Embedding 模型。

四、知识库优化：性能和效果的核心

FastGPT 的很多性能问题都和知识库有关。知识库不是“把文档上传进去就完事”，而是需要合理整理、分段、清洗和配置。

1. 文档质量比模型更重要

如果上传的文档本身混乱、重复、过期、格式差，即使使用很强的模型，也很难得到高质量回答。

常见问题包括：

• 文档中有大量无关内容；
• 同一段内容重复出现多次；
• 标题层级混乱；
• 表格信息缺失；
• PDF 解析后出现乱码；
• 文档中包含页眉、页脚、广告、编号噪音；
• 多个版本的制度文件同时存在，内容互相冲突。

这些问题会导致检索结果变差，模型拿到错误上下文后，就可能生成错误答案。

优化建议：

• 上传前先清理文档；
• 删除重复内容；
• 保留清晰标题；
• 将过期文件归档或移除；
• 对复杂表格进行人工整理；
• 将扫描版 PDF 转成可读文本后再导入；
• 对重要业务知识进行结构化整理。

2. 分段大小要适中

知识库分段过小，会导致语义不完整。比如一条制度被切成很多碎片，模型检索到其中一小段后，无法理解完整上下文。

分段过大，则会导致召回内容冗余，传给模型的上下文过长，既慢又贵，还可能干扰回答。

一般来说：

• FAQ、客服话术：适合较短分段；
• 制度文档、说明书：适合中等分段；
• 技术文档、流程文档：需要保留标题和上下文；
• 长篇报告：建议先整理目录，再分主题导入。

一个简单原则是：每个分段最好能独立表达一个完整意思。

例如，不建议分成这样：

报销申请需要在

也不建议一个分段塞进完整的十页制度。更好的分段应该像这样：

员工报销申请需要在费用发生后 30 日内提交。提交材料包括发票、付款凭证、审批单和相关说明。超过 30 日未提交的，需部门负责人额外审批。

3. 控制召回数量

很多人为了“提高准确率”，会把知识库召回数量设置得很大。但召回越多，不一定效果越好。

召回数量过大会带来几个问题：

• 检索耗时增加；
• 拼接上下文变长；
• 大模型处理速度变慢；
• 无关内容增加，反而影响回答准确性；
• token 成本增加。

建议从较小数量开始测试，比如 3 到 6 条，再根据效果调整。如果知识库质量高、分段合理，通常不需要召回太多内容。

4. 设置合理的相似度阈值

相似度阈值用于过滤低相关内容。如果阈值太低，系统可能把很多无关内容传给模型；如果阈值太高，可能检索不到足够内容。

优化方法：

• 如果回答经常引用无关资料，可以适当提高阈值；
• 如果经常回答“未找到相关内容”，可以适当降低阈值；
• 不同知识库可以设置不同阈值；
• 调整后要用真实问题测试，而不是只看单个案例。

五、提示词优化：减少无效消耗

提示词不仅影响回答质量，也影响性能。提示词越长，每次请求发送给模型的内容越多，响应就可能越慢，成本也越高。

1. 避免过长的系统提示词

有些应用的提示词写了几千字，包括角色设定、语气要求、业务规则、输出格式、限制条件等。这样虽然看起来很完整，但每次对话都会携带大量固定内容。

建议将提示词拆分为：

• 必须每次传递的核心规则；
• 可以放入知识库的业务资料；
• 可以通过工作流判断的条件；
• 可以用前端交互限制的内容。

提示词应尽量清晰、直接、无重复。

2. 明确回答边界

为了减少模型胡乱扩展，可以在提示词中加入边界：

请严格基于知识库内容回答。
如果知识库中没有相关信息，请说明“当前资料中未找到明确答案”。
不要编造政策、价格、时间、联系人或流程。

这样不仅能提高准确性，也能避免模型生成大量无关内容。

3. 固定输出格式

如果业务需要结构化回答，可以让模型按固定格式输出。例如：

请按以下格式回答：

## 结论
用 1-2 句话直接回答问题。

## 依据
列出知识库中的关键依据。

## 补充说明
如有注意事项，简要说明。

固定格式可以减少模型自由发挥，提高结果稳定性，也方便前端展示。

六、数据库与向量库优化

FastGPT 通常会依赖数据库保存应用配置、用户信息、聊天记录、知识库数据、向量数据等。数据库性能对整体体验影响很大。

1. 不要把所有服务挤在低配机器上

很多新手会把 FastGPT、数据库、向量库、反向代理、模型代理服务全部部署在一台低配服务器上。测试时问题不大，但只要知识库变大或并发增加，就容易卡顿。

建议至少关注以下资源：

• CPU 是否长期高占用；
• 内存是否接近耗尽；
• 磁盘 IO 是否过高；
• 数据库连接数是否不足；
• 网络带宽是否稳定。

如果预算允许，可以将数据库和应用服务分开部署。数据库对磁盘和内存比较敏感，单独部署更容易保证稳定性。

2. 定期清理无用数据

聊天日志、调试记录、历史知识库版本、失败任务等数据如果长期不清理，会让数据库越来越大，查询也可能变慢。

建议建立定期维护机制：

• 清理无用应用；
• 删除测试知识库；
• 归档长期不用的聊天记录；
• 删除失败或过期的导入任务；
• 定期备份重要数据。

注意：清理前一定要做好备份，尤其是生产环境。

3. 保证向量库稳定

向量库是知识库检索的关键。如果向量库响应慢，问答就会慢。

优化建议：

• 使用官方推荐或社区验证较多的向量库方案；
• 给向量库分配足够内存；
• 避免单个知识库无限膨胀；
• 大型知识库按业务主题拆分；
• 不要频繁删除、重建、导入大量数据而不维护；
• 监控向量库查询耗时。

七、应用工作流优化

FastGPT 的强大之处在于可以构建工作流，但工作流越复杂，性能压力也越大。

1. 减少不必要的节点

一个问题如果经过多个模型节点、多次知识库检索、多轮条件判断，响应时间一定会增加。

优化时可以检查：

• 是否有重复调用模型的节点；
• 是否有不必要的知识库检索；
• 是否每次都需要联网搜索；
• 是否可以把多个简单判断合并；
• 是否可以用规则判断代替模型判断。

例如，判断用户是否询问售后电话，并不一定需要调用大模型，可以通过关键词或简单规则完成。

2. 将复杂任务拆分

如果一个应用既负责客服、又负责销售、又负责技术支持、又负责内部制度查询，提示词和知识库都会变得复杂。

更好的方式是拆成多个专门应用：

• 售前咨询助手；
• 售后服务助手；
• 内部制度助手；
• 技术文档助手；
• 数据分析助手。

再通过入口应用或菜单进行分流。这样每个应用的知识库更小、提示词更短、回答更稳定。

3. 避免循环式低效调用

有些工作流会让模型先分析问题，再改写问题，再检索，再总结，再润色。虽然看起来高级，但如果业务场景只是简单问答，这种流程会明显拖慢速度。

建议只有在必要时才使用复杂链路。例如：

• 用户问题很口语化，需要问题改写；
• 需要多知识库融合；
• 需要生成正式报告；
• 需要进行多步骤推理；
• 需要对答案进行审核。

普通客服问答不一定需要这么复杂。

八、并发优化：多人同时访问怎么办？

当 FastGPT 从个人测试走向团队使用或公开服务时，并发能力就非常重要。

1. 控制单用户请求频率

如果没有任何限制，一个用户可以连续发送大量请求，导致系统资源被占满。

可以考虑：

• 前端按钮增加发送间隔；
• 对匿名用户设置频率限制；
• 对高频接口设置限流；
• 对异常请求进行拦截；
• 对不同用户组设置不同额度。

这不仅保护系统性能，也能控制模型调用成本。

2. 使用流式输出

流式输出可以让用户更快看到回答内容。虽然模型完整生成时间可能没有减少，但用户感知速度会明显提升。

例如，非流式输出时，用户需要等模型全部生成完才看到答案；流式输出时，模型生成一点就展示一点，体验会好很多。

对于问答、客服、助手类应用，建议优先启用流式输出。

3. 区分高峰和低峰任务

知识库批量导入、批量向量化、数据清洗等任务会消耗大量资源。如果在用户访问高峰执行，可能影响正常问答。

建议：

• 大批量导入放在低峰期；
• 导入前先整理文档；
• 分批导入大型知识库；
• 监控导入过程中的 CPU、内存和数据库压力；
• 避免多人同时进行大规模导入。

九、服务器部署优化

对于自部署 FastGPT 的用户，服务器环境对性能影响很大。

1. 选择合适配置

如果只是个人测试，小配置服务器也可以。但如果是团队使用，建议不要过低配置。

一般需要关注：

• CPU：影响服务处理能力、数据库查询、向量计算等；
• 内存：影响数据库、向量库、缓存和服务稳定性；
• 磁盘：建议使用 SSD，数据库场景尤其重要；
• 带宽：影响用户访问和模型接口调用；
• 地域：尽量选择离用户和模型服务较近的区域。

2. 使用稳定的网络环境

如果 FastGPT 需要调用外部模型接口，网络延迟会直接影响响应速度。即使本地服务很快，只要模型接口连接慢，用户仍然会感觉慢。

建议：

• 选择网络质量稳定的服务器；
• 避免跨境高延迟链路；
• 使用可靠的模型服务商；
• 对外部 API 做超时设置；
• 观察不同时间段的接口延迟。

3. 配置反向代理

生产环境中通常会使用 Nginx、Traefik 等反向代理。合理配置反向代理可以提升稳定性。

需要注意：

• 请求超时时间不要过短；
• 支持流式响应；
• 上传文件大小限制要合理；
• HTTPS 证书配置正确；
• 避免代理层缓存错误内容；
• 记录必要访问日志便于排查问题。

十、缓存思路：减少重复计算

缓存是提升性能的常见方法。虽然具体实现方式取决于部署环境和业务需求，但思路很简单：重复出现的问题，不要每次都完整计算一遍。

1. 常见问题缓存

对于客服场景，很多用户的问题高度重复，例如：

• 如何申请退款？
• 发票怎么开？
• 售后电话是多少？
• 密码忘了怎么办？
• 产品价格是多少？

这些问题可以通过 FAQ、固定回复或缓存机制快速回答，而不必每次都调用大模型。

2. 静态内容前置

对于固定政策、流程、联系方式等内容，可以在前端、菜单、快捷问题中展示，减少用户重复询问。

例如在聊天窗口上方放置：

• 常见问题入口；
• 热门问题按钮；
• 最新公告；
• 联系人工客服按钮。

这样不仅减少模型请求，也能提升用户体验。

十一、回答质量与速度的平衡

性能优化不是单纯追求速度。有些优化会让速度变快，但可能牺牲回答质量；有些配置会提高准确性，但会增加延迟。

例如：

• 减少召回数量：速度更快，但可能漏掉资料；
• 提高相似度阈值：减少无关内容，但可能无结果；
• 使用轻量模型：响应更快，但复杂问题能力下降；
• 缩短输出长度：生成更快，但解释可能不充分；
• 简化工作流：延迟降低，但功能可能减少。

因此，优化时要结合业务目标。

如果是智能客服，用户更看重快速、准确、简洁；如果是法律文档分析，用户可能愿意等待更久，但要求更严谨；如果是内部办公助手，稳定性和权限控制可能比极限速度更重要。

十二、推荐的优化顺序

对于零基础用户，建议按照以下顺序优化，不要一开始就做复杂架构调整。

第一步：清理知识库

先整理文档，删除重复、过期、无关内容，保证知识库质量。

第二步：调整分段和召回

让每个分段表达完整含义，并合理设置召回数量和相似度阈值。

第三步：优化提示词

删除重复内容，保留核心规则，限制回答边界和输出长度。

第四步：选择合适模型

根据业务复杂度选择模型，不要所有场景都使用最大模型。

第五步：检查服务器资源

观察 CPU、内存、磁盘、网络，确认是否存在明显瓶颈。

第六步：简化工作流

删除不必要节点，减少重复模型调用和重复检索。

第七步：做并发和限流

当用户量增加后，再考虑限流、拆分服务、数据库独立部署等方案。

十三、一个实用的优化案例

假设你做了一个企业制度问答助手，员工可以询问请假、报销、加班、考勤等制度。上线后发现回答慢，而且有时答非所问。

你可以这样优化：

1. 检查知识库内容
   发现上传了多个版本的制度文件，其中有些是旧版，内容互相冲突。先删除旧版，只保留当前有效版本。

2. 重新整理文档结构
   将“请假制度”“报销制度”“考勤制度”“加班制度”拆成不同文档，每个文档标题清晰。

3. 调整分段
   原来系统把文档切得很碎，导致检索到的内容不完整。重新设置分段，让每段包含完整规则。

4. 减少召回数量
   原来每次召回 12 条，很多内容无关。调整为 5 条，提高响应速度。

5. 优化提示词
   要求模型只根据知识库回答，不编造审批流程，并优先给出结论。

6. 限制回答长度
   简单问题控制在 300 字以内，复杂问题再分点说明。

7. 测试常见问题
   用员工真实问题测试，例如“年假可以跨年吗”“打车费能报销吗”“加班需要提前审批吗”。

经过这些优化后，通常能同时提升速度和准确性，而不一定需要立刻升级服务器或更换昂贵模型。

十四、常见误区

误区一：模型越强，系统越好

强模型确实能力更高，但也可能更慢、更贵。很多知识库问答场景，关键在于知识库质量，而不是盲目堆模型。

误区二：召回越多，答案越准确

召回太多会带来噪音，让模型难以判断重点。高质量分段加适量召回，通常比大量召回效果更好。

误区三：文档全部上传就完成了

知识库建设需要清洗、分类、更新和测试。未经整理的文档会严重影响效果。

误区四：只要服务器配置高就能解决问题

硬件升级可以缓解压力，但如果知识库混乱、工作流低效、提示词冗长，升级服务器也只是暂时掩盖问题。

误区五：性能优化只做一次

性能优化是持续过程。随着用户量、知识库规模、业务需求变化，配置也需要不断调整。

十五、日常维护建议

为了让 FastGPT 长期稳定运行，建议建立简单的维护机制。

每周检查

• 查看是否有异常慢请求；
• 检查模型调用失败率；
• 清理测试应用和无用知识库；
• 观察用户高频问题；
• 收集错误回答案例。

每月检查

• 更新过期知识库内容；
• 优化热门问题的回答；
• 检查数据库容量；
• 评估模型成本；
• 回顾并发情况和服务器资源。

每次业务变更后检查

• 新制度是否已同步到知识库；
• 旧内容是否已删除；
• 提示词是否需要更新；
• 常见问题是否需要重新测试；
• 是否影响已有工作流。

结语：性能优化的核心是系统思维

FastGPT 性能优化并不是某一个按钮、某一个参数或某一个模型就能彻底解决的问题。它更像是一个系统工程，需要从模型、知识库、提示词、工作流、数据库、服务器、网络和用户体验多个角度综合考虑。

对于零基础用户来说，不必一开始就追求复杂架构。最有效的路径往往是：

• 先把文档整理干净；
• 再把知识库分段调好；
• 然后控制召回和输出长度；
• 接着选择合适模型；
• 最后再考虑服务器、并发和部署架构。

只要按照这个顺序逐步优化，大多数 FastGPT 应用都能获得明显的速度提升、成本下降和回答质量改善。真正优秀的 AI 应用，不只是“能回答”，而是能在稳定、快速、准确和可维护之间取得平衡。