FastGPT 性能优化教程｜附配置文件

在企业知识库、智能客服、内部问答系统等场景中，FastGPT 经常承担“高并发问答 + 知识库检索 + 大模型推理编排”的核心角色。随着知识库规模扩大、用户访问量上升，很多团队会遇到响应变慢、检索不稳定、接口超时、数据库压力过大、向量库查询变慢等问题。

本文将从部署架构、数据库、向量检索、模型调用、缓存、并发控制、Docker 配置、Nginx 反向代理等多个方面，系统讲解 FastGPT 的性能优化思路，并附带可直接参考的配置文件示例。

一、FastGPT 性能瓶颈通常在哪里？

在优化 FastGPT 之前，首先要明确性能瓶颈可能出现在哪些环节。FastGPT 的一次完整问答通常包含以下流程：

1. 用户提交问题；
2. FastGPT 接收请求并进行权限、上下文、应用配置处理；
3. 如果启用知识库，则进行向量检索；
4. 检索结果进入 Prompt 组装流程；
5. 请求大模型接口；
6. 模型流式或非流式返回结果；
7. FastGPT 将结果返回给前端，并可能记录日志、保存对话历史。

因此，性能问题一般不是单点造成的，而是多个环节叠加的结果。

常见瓶颈包括：

• MongoDB 查询慢；
• PostgreSQL 或向量库检索慢；
• 大模型接口响应慢；
• Docker 容器资源限制过低；
• Nginx 超时时间过短；
• FastGPT 并发任务过多导致 CPU 或内存压力升高；
• 知识库分块不合理，召回内容过多；
• 日志、历史记录、数据集过大但缺少清理策略；
• 服务部署在单机，缺少扩展能力。

优化的关键不是盲目提高服务器配置，而是根据业务链路逐步定位问题，并针对具体瓶颈进行处理。

二、服务器资源建议

FastGPT 对资源的消耗与使用场景高度相关。如果只是小团队内部测试，普通 2 核 4G 服务器也可以运行；但如果是生产环境，尤其是知识库规模较大或并发较高，建议使用更高配置。

1. 测试环境推荐

适合个人体验、小型知识库测试、Demo 演示。

2. 中小型生产环境推荐

适合企业内部知识库、低到中等并发客服系统。

3. 高并发生产环境推荐

高并发场景不建议所有服务都放在同一台机器上。FastGPT 本身、数据库、向量库、大模型代理服务最好进行拆分部署，这样更容易定位问题，也方便横向扩展。

三、Docker Compose 优化配置

很多用户使用 Docker Compose 部署 FastGPT。默认配置通常适合快速启动，但未必适合生产环境。生产环境中应重点关注以下几点：

• 容器自动重启；
• 数据卷持久化；
• 合理的环境变量；
• 数据库连接配置；
• 日志大小限制；
• 网络隔离；
• 资源限制。

下面是一份参考配置，可根据实际版本和官方配置进行调整。

version: "3.8"

services:
  fastgpt:
    image: registry.cn-hangzhou.aliyuncs.com/fastgpt/fastgpt:latest
    container_name: fastgpt
    restart: always
    ports:
      - "3000:3000"
    environment:
      - DEFAULT_ROOT_PSW=yourStrongPassword
      - OPENAI_BASE_URL=https://api.openai.com/v1
      - CHAT_API_KEY=yourApiKey
      - DB_MAX_LINK=30
      - TOKEN_KEY=yourTokenKey
      - ROOT_KEY=yourRootKey
      - FILE_TOKEN_KEY=yourFileTokenKey
      - LOG_LEVEL=info
    depends_on:
      - mongo
      - pg
    networks:
      - fastgpt-net
    logging:
      driver: json-file
      options:
        max-size: "100m"
        max-file: "3"

  mongo:
    image: mongo:5.0
    container_name: fastgpt-mongo
    restart: always
    command: mongod --wiredTigerCacheSizeGB 2
    volumes:
      - ./data/mongo:/data/db
    networks:
      - fastgpt-net
    logging:
      driver: json-file
      options:
        max-size: "100m"
        max-file: "3"

  pg:
    image: ankane/pgvector:latest
    container_name: fastgpt-pg
    restart: always
    environment:
      - POSTGRES_USER=postgres
      - POSTGRES_PASSWORD=yourPgPassword
      - POSTGRES_DB=postgres
    volumes:
      - ./data/pg:/var/lib/postgresql/data
    networks:
      - fastgpt-net
    logging:
      driver: json-file
      options:
        max-size: "100m"
        max-file: "3"

networks:
  fastgpt-net:
    driver: bridge

配置说明

restart: always 可以保证容器异常退出后自动重启，适合生产环境。logging 中的 max-size 和 max-file 用于限制 Docker 日志大小，避免日志无限增长占满磁盘。MongoDB 的 wiredTigerCacheSizeGB 可以根据服务器内存调整，避免 MongoDB 占用过多内存导致系统压力过大。

如果服务器只有 8GB 内存，不建议给 MongoDB 设置过高缓存。通常可以设置为 1GB 到 2GB。如果服务器有 32GB 内存，可以适当提升到 4GB 或更高，但仍要为 FastGPT、PostgreSQL 和系统本身预留空间。

四、MongoDB 性能优化

FastGPT 的很多业务数据会存储在 MongoDB 中，例如用户、应用、对话、知识库元数据等。MongoDB 性能不佳会直接影响后台管理、对话加载和历史记录查询。

1. 使用 SSD 磁盘

数据库最怕低速磁盘。机械硬盘或低性能云盘会显著拖慢查询和写入。生产环境应优先使用 SSD 云盘，并关注 IOPS 指标。

2. 限制日志和历史数据增长

如果对话历史、日志、调试记录长期不清理，数据库会越来越大，查询自然变慢。建议根据业务要求制定清理策略，例如：

• 保留最近 90 天普通对话；
• 重要会话单独归档；
• 定期清理无用调试日志；
• 删除废弃应用和测试知识库。

3. 为 MongoDB 设置合理缓存

如果 MongoDB 与 FastGPT 部署在同一台机器上，必须限制 MongoDB 缓存，否则它可能占用大量内存。

command: mongod --wiredTigerCacheSizeGB 2

对于 8GB 内存服务器，建议设置为 1-2GB；对于 16GB 内存服务器，可以设置为 2-4GB；对于 32GB 以上服务器，可以根据实际监控结果调整。

4. 定期备份和压缩

长期运行的 MongoDB 建议配置定时备份。备份不仅用于容灾，也方便在数据异常增长时进行分析。

示例备份命令：

docker exec fastgpt-mongo mongodump --out /data/db/backup

更推荐将备份输出到宿主机挂载目录，并定期上传到对象存储。

五、PostgreSQL 与向量检索优化

FastGPT 的知识库检索性能很大程度上取决于向量数据库或 pgvector 的表现。知识库越大，检索优化越重要。

1. 合理设置向量索引

如果使用 pgvector，需要确认向量字段是否建立了合适索引。不同版本的 pgvector 支持不同索引方式，例如 ivfflat、hnsw 等。对于大规模数据，索引是提升检索性能的关键。

示例 SQL：

CREATE INDEX CONCURRENTLY IF NOT EXISTS idx_dataset_vector
ON modeldata
USING hnsw (vector vector_cosine_ops);

如果你的环境不支持 hnsw，可以考虑 ivfflat：

CREATE INDEX CONCURRENTLY IF NOT EXISTS idx_dataset_vector_ivfflat
ON modeldata
USING ivfflat (vector vector_cosine_ops)
WITH (lists = 100);

索引建立完成后，建议执行：

ANALYZE modeldata;

这样 PostgreSQL 可以更新统计信息，提升查询计划准确性。

2. 控制知识库分块大小

知识库分块过小会导致数据量膨胀，向量数量过多，检索压力变大；分块过大又会导致召回内容不精准，Prompt 变长，模型响应变慢。

常见建议：

• 普通知识库分块长度：500-800 字；
• 技术文档分块长度：800-1200 字；
• 问答型知识库可以更短；
• 法律、合同、制度类文档要结合标题层级切分；
• 不建议盲目把分块设置得非常小。

3. 控制召回数量

很多用户为了“提高准确率”，会把召回数量设置得很高，例如一次召回 20 条甚至 50 条。这样会带来两个问题：

第一，向量检索压力变大；第二，进入 Prompt 的上下文变长，大模型处理时间增加，费用也会上升。

一般建议：

• 普通问答召回 3-6 条；
• 专业文档问答召回 5-10 条；
• 如果启用重排模型，可适当增加初始召回数量；
• 最终进入 Prompt 的内容应保持精简。

知识库问答的性能优化，不是召回越多越好，而是召回越准越好。

六、大模型接口优化

在 FastGPT 问答链路中，大模型接口通常是耗时最长的部分。即使 FastGPT 和数据库都很快，如果模型供应商接口响应慢，用户仍然会感觉系统卡顿。

1. 优先使用流式输出

流式输出不会减少模型总生成时间，但可以显著改善用户体验。用户不需要等待完整答案生成完毕，而是可以边生成边阅读。

如果模型服务支持 SSE 或流式接口，建议在应用中开启流式响应。

2. 使用稳定的大模型代理

如果你使用的是 OpenAI、Azure OpenAI、通义千问、智谱、DeepSeek、Moonshot 等接口，建议通过稳定的代理层或网关统一管理。

代理层可以提供：

• Key 管理；
• 限流；
• 重试；
• 日志追踪；
• 多模型切换；
• 熔断降级；
• 请求统计。

生产环境不要把所有模型 Key 分散写在不同配置中，否则后期排查和迁移成本会很高。

3. 控制 Prompt 长度

Prompt 越长，模型首 token 响应越慢，费用越高。FastGPT 的知识库问答中，Prompt 通常由系统提示词、用户问题、历史上下文、知识库召回内容组成。

优化建议：

• 减少无意义系统提示词；
• 控制历史对话轮数；
• 精简知识库召回内容；
• 避免把整篇文档直接塞给模型；
• 对长文档场景使用总结、分层检索或重排。

4. 设置合理超时时间

模型接口偶尔响应慢是正常现象。Nginx、应用服务、代理服务都需要设置合理超时时间，否则会出现前端提前断开，而后端仍在生成的情况。

七、Nginx 反向代理配置

如果 FastGPT 部署在生产环境，通常会使用 Nginx 做 HTTPS、反向代理、域名访问和 WebSocket/SSE 转发。对于流式输出场景，Nginx 配置非常重要。

下面是一份参考配置：

server {
    listen 80;
    server_name fastgpt.example.com;

    client_max_body_size 50m;

    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_http_version 1.1;

        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;

        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";

        proxy_buffering off;
        proxy_cache off;

        proxy_connect_timeout 300s;
        proxy_send_timeout 300s;
        proxy_read_timeout 300s;

        send_timeout 300s;
    }
}

配置重点

proxy_buffering off 对流式输出很重要。如果开启缓冲，用户可能无法实时看到模型生成内容，而是等后端生成一段或全部后才返回。

proxy_read_timeout 建议设置得比模型最长响应时间更长。对于复杂问答、长文本生成、知识库问答，建议设置为 300 秒或更高。

client_max_body_size 要根据上传文档大小设置。如果用户需要上传 PDF、Word、Excel 等文件，默认大小可能不够。

如果使用 HTTPS，可以在此基础上增加证书配置，或使用宝塔、1Panel、Nginx Proxy Manager 等工具管理证书。

八、FastGPT 应用层优化

除了基础设施，FastGPT 应用配置本身也会影响性能。

1. 减少不必要的工作流节点

FastGPT 支持编排复杂工作流，但每个节点都可能增加耗时。例如：

• 多次调用大模型；
• 多次知识库检索；
• 多次 HTTP 请求；
• 多层条件判断；
• 外部插件调用。

如果目标是在线客服或高频问答，应尽量保持流程简洁。复杂任务可以拆分为异步任务或后台流程，不要全部放在用户实时等待链路中。

2. 控制历史上下文轮数

历史上下文可以提升连续对话体验，但也会增加 Prompt 长度。对于大多数知识库问答，保留 3-5 轮上下文已经足够。过多历史上下文不仅拖慢响应，还可能引入干扰信息。

3. 区分高质量模型和高速模型

并不是所有任务都需要使用最强模型。可以根据场景分层：

合理的模型分层可以同时降低成本和提升整体吞吐量。

4. 使用重排模型要谨慎

重排模型可以提升检索准确率，但也会增加额外耗时。对于知识库规模较大、内容相似度较高的场景，重排非常有价值；但对于简单 FAQ 或小型知识库，重排可能收益有限。

建议做 A/B 测试：

• 不使用重排时的准确率和响应时间；
• 使用重排后的准确率和响应时间；
• 用户真实满意度变化；
• 单次请求成本变化。

九、缓存优化思路

缓存是提升性能的重要手段，但要根据业务场景谨慎使用。

1. 静态资源缓存

如果 FastGPT 前端资源通过 Nginx 或 CDN 分发，可以为静态资源设置缓存，降低服务器压力。

示例：

location ~* \.(js|css|png|jpg|jpeg|gif|ico|svg|woff|woff2)$ {
    expires 7d;
    add_header Cache-Control "public, max-age=604800";
}

2. 接口级缓存

对于完全相同的问题，可以考虑在业务层做问答缓存。但这类缓存要注意两个问题：

• 用户权限不同，知识库可见范围可能不同；
• 同一问题在不同上下文下答案可能不同。

因此，问答缓存更适合 FAQ、公开知识库、固定答案场景。

3. 模型结果缓存

如果大量用户会问相似问题，可以引入语义缓存。语义缓存不是简单匹配字符串，而是把问题向量化后判断相似度。如果相似度超过阈值，就直接返回已有答案。

适合场景：

• 高频客服问题；
• 标准化政策解释；
• 产品使用说明；
• 售前咨询问答。

不适合场景：

• 需要实时数据；
• 用户权限严格隔离；
• 答案必须每次重新生成；
• 高风险法律、医疗、金融决策。

十、系统监控与排查方法

性能优化不能靠感觉，必须有监控数据。建议至少监控以下指标：

• CPU 使用率；
• 内存使用率；
• 磁盘空间；
• 磁盘 I/O；
• MongoDB 查询耗时；
• PostgreSQL 查询耗时；
• FastGPT 接口响应时间；
• 模型接口平均耗时；
• 错误率；
• 超时率；
• 容器重启次数。

常用排查命令

查看容器状态：

docker ps

查看资源占用：

docker stats

查看 FastGPT 日志：

docker logs -f fastgpt

查看 MongoDB 日志：

docker logs -f fastgpt-mongo

查看 PostgreSQL 日志：

docker logs -f fastgpt-pg

查看磁盘空间：

df -h

查看目录大小：

du -sh ./data/*

如果响应突然变慢，建议按以下顺序排查：

1. 先看大模型接口是否变慢；
2. 再看服务器 CPU、内存、磁盘是否异常；
3. 查看 Docker 容器是否频繁重启；
4. 检查 MongoDB 和 PostgreSQL 日志；
5. 检查最近是否导入了大量知识库；
6. 检查是否有异常用户或脚本高频请求；
7. 检查 Nginx 是否出现超时或 502。

十一、生产环境推荐架构

对于正式使用 FastGPT 的企业，推荐逐步从单机架构升级为分层架构。

1. 基础生产架构

用户
  ↓
Nginx / HTTPS
  ↓
FastGPT
  ↓
MongoDB + PostgreSQL/pgvector
  ↓
大模型 API

这种架构简单，适合中小规模业务。

2. 优化生产架构

用户
  ↓
负载均衡 / Nginx
  ↓
FastGPT 多实例
  ↓
MongoDB 独立节点
  ↓
PostgreSQL / 向量数据库独立节点
  ↓
模型网关 / API 代理
  ↓
多个大模型服务商

这种架构的优点是：

• FastGPT 可以横向扩展；
• 数据库资源独立，不容易互相抢占；
• 模型接口可以统一管理；
• 可以做限流、熔断和降级；
• 更适合企业级稳定运行。

3. 高可用建议

如果业务对稳定性要求较高，可以进一步考虑：

• MongoDB 副本集；
• PostgreSQL 主从或云数据库；
• FastGPT 多实例部署；
• Nginx 双节点；
• 数据定期备份；
• 对象存储保存上传文件；
• 接入 Prometheus、Grafana、ELK 等监控系统。

十二、常见优化误区

误区一：只增加服务器配置

很多性能问题不是 CPU 不够，而是 Prompt 太长、召回太多、模型接口慢、数据库无索引。盲目升级服务器可能花了钱却没有明显效果。

误区二：知识库分块越小越好

分块过小会导致向量数量暴增，也会造成检索结果碎片化。合理分块比极细分块更重要。

误区三：召回数量越多越准确

召回太多会拖慢检索和模型响应，也可能引入无关内容，让模型更容易答偏。

误区四：所有任务都使用最强模型

最强模型通常更慢、更贵。对于分类、改写、简单问答等任务，轻量模型往往更合适。

误区五：忽略日志和备份

日志无限增长会占满磁盘，数据库没有备份则会带来严重风险。生产环境必须重视运维策略。

十三、推荐参数配置清单

下面给出一份通用优化参考，适合大多数中小型生产环境：

如果知识库超过百万级分块，建议认真评估独立向量数据库、分布式部署、冷热数据拆分和索引优化方案。

十四、完整 Nginx HTTPS 示例

如果需要启用 HTTPS，可以参考以下配置：

server {
    listen 80;
    server_name fastgpt.example.com;
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl http2;
    server_name fastgpt.example.com;

    ssl_certificate /etc/nginx/ssl/fastgpt.example.com.pem;
    ssl_certificate_key /etc/nginx/ssl/fastgpt.example.com.key;

    client_max_body_size 50m;

    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_http_version 1.1;

        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto https;

        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";

        proxy_buffering off;
        proxy_cache off;

        proxy_connect_timeout 300s;
        proxy_send_timeout 300s;
        proxy_read_timeout 300s;
        send_timeout 300s;
    }
}

证书可以通过 Let’s Encrypt、acme.sh、宝塔面板、1Panel 等方式申请。需要注意的是，如果使用 CDN，还要确认 CDN 是否支持流式传输，否则可能影响模型实时输出体验。

十五、总结

FastGPT 性能优化是一项系统工程，不能只看某一个参数。真正有效的优化应当围绕完整请求链路展开：前端访问、Nginx 代理、FastGPT 服务、数据库查询、向量检索、Prompt 构造、大模型接口、日志与监控，每一环都可能影响最终体验。

对于大多数团队，可以按照以下顺序进行优化：

1. 先确认大模型接口是否稳定；
2. 优化 Nginx 超时和流式输出配置；
3. 控制知识库分块大小和召回数量；
4. 限制历史上下文，减少 Prompt 长度；
5. 优化 MongoDB 和 PostgreSQL 资源配置；
6. 设置 Docker 日志限制，避免磁盘被打满；
7. 建立监控、备份和清理机制；
8. 在并发提升后拆分数据库和 FastGPT 服务；
9. 对高频问题引入缓存或语义缓存；
10. 根据任务类型选择不同模型，降低成本并提升速度。

如果只是个人或小团队使用，单机部署加上合理配置即可满足需求；如果是企业级生产系统，则建议尽早规划数据库独立部署、模型网关、监控系统和数据备份策略。只有把性能、稳定性、成本和可维护性一起考虑，FastGPT 才能在真实业务中长期稳定运行。