FastGPT 如何提高网站速度｜附配置文件

在使用 FastGPT 搭建 AI 应用、知识库问答系统或企业内部智能助手时，很多团队都会遇到一个共同问题：功能已经跑起来了，但访问速度不够理想。页面打开慢、接口响应慢、知识库检索耗时长、模型回复等待时间久，都会直接影响用户体验，甚至让用户误以为系统“不稳定”或“不可用”。

事实上，FastGPT 的速度表现并不只取决于模型本身，还和服务器配置、网络链路、数据库性能、向量检索、反向代理、缓存策略、Docker 配置、并发设置等多个因素有关。本文将从实战角度出发，系统讲解如何优化 FastGPT 网站速度，并附上常用配置文件示例，方便你直接参考和调整。

一、为什么 FastGPT 网站会变慢？

在优化之前，先要明确一个原则：不要盲目优化，先找到瓶颈。FastGPT 的一次完整访问通常会经过以下几个环节：

1. 用户访问前端页面；
2. Nginx 或其他反向代理接收请求；
3. 请求转发到 FastGPT Web 服务；
4. FastGPT 调用数据库、向量数据库或缓存服务；
5. 如果涉及对话，再调用大模型接口；
6. 大模型返回结果后，FastGPT 组织响应；
7. 前端逐步渲染结果。

其中任何一个环节出现性能瓶颈，都会让用户感觉“网站很慢”。

常见原因包括：

• 服务器 CPU、内存不足；
• Docker 容器资源限制不合理；
• MongoDB 查询性能较差；
• 向量数据库检索速度慢；
• Nginx 没有开启压缩或缓存；
• 静态资源加载缓慢；
• 模型接口网络延迟高；
• 并发过高导致请求排队；
• 日志过多影响磁盘 IO；
• HTTPS 配置不合理；
• 没有使用 CDN 加速前端资源。

因此，提高 FastGPT 网站速度不是简单地“换一台服务器”，而是需要从整体架构上进行优化。

二、服务器配置建议

如果 FastGPT 只是用于个人测试，2 核 4G 的服务器也能运行。但如果你希望给团队或外部用户使用，建议配置不要太低。

1. 基础测试环境

适合个人体验、Demo 演示、小规模内部测试。

CPU: 2 核
内存: 4GB
硬盘: 40GB SSD
带宽: 5Mbps

这种配置可以跑起来，但不适合高并发，也不适合大规模知识库。

2. 中小型生产环境

适合企业内部知识库、客服机器人、部门级 AI 应用。

CPU: 4 核或 8 核
内存: 8GB - 16GB
硬盘: 100GB SSD
带宽: 10Mbps 以上

如果知识库文档较多，建议至少 16GB 内存，并使用 SSD 云盘。

3. 较高并发环境

适合对外提供服务、用户访问量较高的网站。

CPU: 8 核以上
内存: 32GB 以上
硬盘: 高性能 SSD
带宽: 20Mbps 以上或接入 CDN

如果模型服务也部署在同一台机器上，需要额外考虑 GPU、显存、推理框架和模型大小，这部分资源消耗会远高于 FastGPT 本身。

三、使用 Nginx 提升访问速度

Nginx 是 FastGPT 部署中非常重要的一环。它不仅可以做反向代理，还可以开启 gzip 压缩、HTTP/2、静态资源缓存、连接复用等优化。

下面是一份适合 FastGPT 的 Nginx 配置示例。

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/fullchain.pem;
    ssl_certificate_key /etc/nginx/ssl/privkey.pem;

    ssl_session_cache shared:SSL:10m;
    ssl_session_timeout 10m;
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_prefer_server_ciphers on;

    client_max_body_size 100m;

    gzip on;
    gzip_comp_level 5;
    gzip_min_length 1k;
    gzip_types
        text/plain
        text/css
        application/json
        application/javascript
        text/xml
        application/xml
        application/xml+rss
        text/javascript
        image/svg+xml;

    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_connect_timeout 60s;
        proxy_send_timeout 300s;
        proxy_read_timeout 300s;

        proxy_buffering off;
    }

    location ~* \.(js|css|png|jpg|jpeg|gif|ico|svg|woff|woff2)$ {
        proxy_pass http://127.0.0.1:3000;
        expires 30d;
        add_header Cache-Control "public, max-age=2592000, immutable";
    }
}

配置说明

这份配置主要做了几件事：

• 强制 HTTP 跳转 HTTPS；
• 开启 HTTP/2，提高多资源加载效率；
• 开启 gzip，减少文本资源传输体积；
• 给静态资源设置缓存；
• 提高接口超时时间，避免大模型流式响应中断；
• 关闭部分代理缓冲，提升流式输出体验。

需要注意的是，FastGPT 的对话结果通常是流式输出，如果 Nginx 缓冲配置不合理，用户可能无法看到“逐字输出”的效果，而是要等完整结果生成后才一次性显示。因此在对话类接口中，proxy_buffering off 通常是比较合适的。

四、优化 Docker Compose 配置

很多用户通过 Docker Compose 部署 FastGPT。默认配置能快速启动，但生产环境通常需要进一步调整。

下面是一份简化版 Docker Compose 优化示例，实际使用时请结合官方配置文件修改。

version: "3.9"

services:
  fastgpt:
    image: ghcr.io/labring/fastgpt:latest
    container_name: fastgpt
    restart: always
    ports:
      - "3000:3000"
    environment:
      - NODE_ENV=production
      - TZ=Asia/Shanghai
      - MONGODB_URI=mongodb://mongo:27017/fastgpt
      - REDIS_URL=redis://redis:6379
    depends_on:
      - mongo
      - redis
    deploy:
      resources:
        limits:
          cpus: "4"
          memory: 8G
        reservations:
          memory: 2G

  mongo:
    image: mongo:6
    container_name: fastgpt-mongo
    restart: always
    command: mongod --wiredTigerCacheSizeGB 2
    volumes:
      - ./data/mongo:/data/db
    environment:
      - TZ=Asia/Shanghai

  redis:
    image: redis:7-alpine
    container_name: fastgpt-redis
    restart: always
    command: redis-server --appendonly yes --maxmemory 1gb --maxmemory-policy allkeys-lru
    volumes:
      - ./data/redis:/data
    environment:
      - TZ=Asia/Shanghai

关键优化点

1. 设置生产环境变量

- NODE_ENV=production

生产环境模式通常会减少开发调试开销，提高运行效率。

2. 给 MongoDB 设置缓存大小

command: mongod --wiredTigerCacheSizeGB 2

MongoDB 默认会根据系统内存自动分配缓存。如果服务器上还有其他服务，建议显式设置缓存大小，避免 MongoDB 占用过多内存导致系统抖动。

3. 使用 Redis 缓存

Redis 可以用于缓存部分高频访问数据，减少数据库压力。对于访问量较高的 FastGPT 站点，Redis 是非常推荐的组件。

4. 设置容器重启策略

restart: always

生产环境中容器异常退出后应自动拉起，保证服务稳定性。

五、优化 MongoDB 查询性能

FastGPT 的用户数据、应用配置、知识库信息等通常会存储在 MongoDB 中。如果 MongoDB 响应慢，整个系统都会变慢。

1. 使用 SSD 存储

数据库最怕慢磁盘。不要把 MongoDB 放在低性能机械盘或 IO 很差的云盘上。推荐使用 SSD 或高性能云盘。

2. 保持索引健康

数据库索引可以显著提升查询速度。如果数据量越来越大，建议定期检查慢查询，并确认常用字段是否有索引。

可以进入 MongoDB 执行：

db.setProfilingLevel(1, { slowms: 100 })

这表示记录超过 100ms 的慢查询。之后可以分析慢查询日志，针对性优化索引。

3. 定期备份和清理无用数据

长期运行后，日志、临时数据、历史记录可能会越来越多。对于不再使用的测试应用、测试知识库、无效数据，可以定期清理。

不过清理数据库前一定要先备份，避免误删重要数据。

六、优化知识库检索速度

FastGPT 的一个核心能力是知识库问答。知识库检索速度会直接影响整体响应时间。

1. 控制单个知识库规模

很多人喜欢把大量文档全部塞进一个知识库，但这不一定是最佳做法。更推荐按照业务场景拆分知识库，例如：

• 产品说明知识库；
• 售后 FAQ 知识库；
• 内部制度知识库；
• 技术文档知识库；
• 销售话术知识库。

这样不仅能提高检索速度，也能提高检索准确率。

2. 合理设置分段长度

文档切分过短，会导致片段数量过多，增加检索压力；切分过长，又可能导致召回不精准。一般可以根据文档类型调整：

普通 FAQ: 300 - 600 字
技术文档: 500 - 1000 字
长篇制度文档: 800 - 1500 字

实际效果需要通过问答测试不断调整。

3. 控制召回数量

召回数量越多，模型上下文越长，响应越慢。不要为了“看起来更全面”而无限增加召回片段。

常见设置建议：

topK: 3 - 8
相似度阈值: 0.4 - 0.7

如果知识库质量较高，topK 可以设置得更小；如果内容复杂，可以适当提高。

4. 避免重复文档

重复文档不仅浪费存储空间，还会干扰检索结果。上传知识库之前，最好先做去重、清洗和格式统一。

七、提升大模型响应速度

用户最终感知最明显的速度，往往来自大模型响应。即使 FastGPT 本身很快，如果模型接口慢，用户依然会觉得系统慢。

1. 选择更近的模型节点

如果你使用第三方模型 API，尽量选择网络延迟较低的服务商或区域。服务器和模型 API 之间的网络延迟越高，首字响应越慢。

可以在服务器上测试接口延迟：

curl -w "@curl-format.txt" -o /dev/null -s https://api.example.com/v1/models

重点关注 DNS 解析、TCP 连接、TLS 握手和首包时间。

2. 使用流式输出

流式输出不能减少总生成时间，但可以显著降低用户的等待感。用户看到内容不断输出，会认为系统响应更快。

在 FastGPT 的对话应用中，建议优先开启流式输出。

3. 控制 Prompt 长度

Prompt 越长，模型处理越慢，费用也越高。应避免在系统提示词中堆积大量重复说明。

优化建议：

• 删除重复规则；
• 使用简洁明确的指令；
• 避免把完整业务文档塞进 Prompt；
• 将知识内容交给知识库检索；
• 控制历史对话轮数。

4. 选择合适模型

不是所有场景都需要最强模型。对于 FAQ、分类、简单客服、表单生成等任务，可以使用响应更快、成本更低的模型。对于复杂推理、长文本分析、专业问答，再切换到更强模型。

八、前端与静态资源优化

FastGPT 页面加载速度还受到前端资源影响。虽然大部分用户不会直接修改 FastGPT 前端代码，但仍可以通过部署层面优化。

1. 使用 CDN

如果用户分布在多个地区，建议使用 CDN 加速静态资源。CDN 可以缓存 JS、CSS、图片、字体等资源，减少源站压力。

2. 开启浏览器缓存

前面 Nginx 配置中已经给静态资源设置了缓存：

expires 30d;
add_header Cache-Control "public, max-age=2592000, immutable";

这样用户第二次访问时，大部分静态资源可以直接从本地缓存读取。

3. 减少跨境访问

如果服务器在海外，而用户主要在国内，访问速度通常会明显变慢。反过来也一样。生产环境应尽量让服务器、数据库、模型接口和用户所在区域保持相对接近。

九、系统级优化建议

除了应用层配置，Linux 系统参数也会影响高并发访问表现。

可以创建 /etc/sysctl.d/99-fastgpt.conf：

net.core.somaxconn = 65535
net.ipv4.tcp_max_syn_backlog = 65535
net.ipv4.ip_local_port_range = 1024 65535
net.ipv4.tcp_fin_timeout = 15
net.ipv4.tcp_tw_reuse = 1
fs.file-max = 1000000

然后执行：

sudo sysctl --system

同时建议提高文件描述符限制。编辑 /etc/security/limits.conf：

* soft nofile 65535
* hard nofile 65535

这些配置适合并发访问较高的环境。如果只是个人测试环境，收益不会特别明显。

十、推荐的完整优化思路

如果你正在排查 FastGPT 速度问题，可以按照以下顺序进行：

1. 先看服务器资源：CPU、内存、磁盘 IO、带宽是否打满；
2. 再看 Nginx 配置：是否开启 gzip、HTTP/2、缓存、合理超时；
3. 检查 MongoDB：是否使用 SSD，是否存在慢查询；
4. 检查知识库：分段是否合理，召回数量是否过高；
5. 检查模型接口：网络延迟、首字时间、是否开启流式输出；
6. 优化 Prompt：减少无效上下文和过长历史记录；
7. 接入 CDN：提升前端静态资源加载速度；
8. 监控与日志：持续观察接口耗时和错误率。

不要一开始就盲目升级服务器。很多时候，真正的问题可能只是 Nginx 没开压缩、模型接口跨境访问、知识库召回太多，或者 MongoDB 使用了低性能磁盘。

十一、常用监控命令

优化性能时，建议通过命令先观察系统状态。

查看 CPU 和内存

htop

查看磁盘 IO

iostat -x 1

如果没有该命令，可以安装：

sudo apt install sysstat

查看 Docker 容器资源占用

docker stats

查看端口监听

ss -lntp

查看 Nginx 日志

tail -f /var/log/nginx/access.log
tail -f /var/log/nginx/error.log

查看 FastGPT 容器日志

docker logs -f fastgpt

这些命令可以帮助你判断问题到底出在系统资源、网络、容器还是应用本身。

十二、总结

FastGPT 网站速度优化是一个系统工程，不能只看单一因素。真正有效的优化，应该围绕“用户请求链路”逐层排查：从浏览器访问、Nginx 代理、Docker 容器、MongoDB、Redis、知识库检索，到最终的大模型接口，每一层都有可能成为瓶颈。

对于大多数 FastGPT 部署场景，优先建议做好以下几件事：

• 使用性能稳定的服务器和 SSD 磁盘；
• 配置 Nginx，开启 gzip、HTTP/2 和静态资源缓存；
• 使用 Redis 缓存，降低数据库压力；
• 优化 MongoDB 存储和慢查询；
• 合理拆分知识库，控制分段和召回数量；
• 使用流式输出，减少用户等待感；
• 控制 Prompt 和历史上下文长度；
• 尽量选择低延迟的大模型接口；
• 有公网访问需求时接入 CDN；
• 建立基础监控，持续观察性能变化。

如果只是个人测试，简单部署即可；如果要用于生产环境，建议从一开始就规划好服务器、数据库、缓存、反向代理和监控体系。这样不仅能提高 FastGPT 的访问速度，也能显著提升系统稳定性和用户体验。