FastGPT 性能优化教程｜附完整命令

FastGPT 是一款基于大语言模型的知识库问答与 AI 应用编排平台，常见部署方式通常包含 FastGPT 服务、MongoDB、PostgreSQL / PGVector、Redis、OneAPI 或其他模型网关，以及反向代理等组件。随着知识库规模、并发用户、工作流复杂度和模型调用量增加，很多团队会遇到响应变慢、检索延迟高、CPU 飙升、数据库连接过多、向量检索耗时、上传解析卡顿等问题。

本文将从服务器基础优化、Docker 部署优化、数据库优化、向量检索优化、FastGPT 配置优化、模型网关优化、Nginx 反向代理优化、监控与排查几个方面，系统讲解 FastGPT 性能优化方法，并附上完整可执行命令，适合自部署 FastGPT 的团队参考。

---

一、优化前先明确性能瓶颈

FastGPT 的一次完整问答通常包括以下链路：

1. 用户请求进入 FastGPT 服务；
2. FastGPT 读取应用配置、知识库配置、用户权限；
3. 根据问题进行知识库检索；
4. 调用向量数据库或 PGVector 获取相似片段；
5. 组装 Prompt；
6. 调用大模型接口；
7. 返回流式结果；
8. 写入会话、日志、用量统计等数据。

因此，FastGPT 慢不一定是 FastGPT 本身慢，常见瓶颈可能来自：

• 服务器 CPU、内存、磁盘 I/O 不足；
• MongoDB 查询慢；
• PostgreSQL / PGVector 向量检索慢；
• Redis 缓存未启用或连接异常；
• 模型接口响应慢；
• Nginx 超时时间过短；
• Docker 默认日志过大；
• 知识库分块过多或召回数量过大；
• 并发过高导致 Node.js 服务压力过大。

优化时不要盲目修改配置，建议先用命令观察系统状态。

top

查看 CPU 和内存占用。

free -h

查看内存与 Swap 使用情况。

df -h

查看磁盘空间。

iostat -x 1

查看磁盘 I/O，如果系统未安装可执行：

sudo apt update
sudo apt install -y sysstat

查看 Docker 容器资源占用：

docker stats

查看 FastGPT 相关容器日志：

docker logs -f fastgpt

如果你的容器名称不同，可以先查看：

docker ps

---

二、服务器基础性能优化

1. 推荐服务器配置

如果只是个人测试，2 核 4G 可以运行；但如果用于生产，建议至少：

场景	CPU	内存	磁盘
个人测试	2 核	4GB	40GB SSD
小团队	4 核	8GB	100GB SSD
中等并发	8 核	16GB	200GB SSD
大规模知识库	16 核+	32GB+	高性能 SSD

如果知识库较大，磁盘 I/O 和 PostgreSQL 性能非常关键，建议使用 SSD，不建议使用低性能机械盘或超售严重的云盘。

2. 更新系统软件包

Ubuntu / Debian 系统可执行：

sudo apt update
sudo apt upgrade -y

安装常用诊断工具：

sudo apt install -y curl wget vim htop iotop iftop net-tools sysstat lsof unzip

CentOS / Rocky Linux 可执行：

sudo yum update -y
sudo yum install -y curl wget vim htop iotop iftop net-tools sysstat lsof unzip

3. 开启 Swap，避免内存瞬间打满

如果服务器内存较小，例如 4GB 或 8GB，建议开启 Swap，避免构建索引、导入知识库或高并发时进程被系统杀掉。

查看是否已有 Swap：

swapon --show

创建 4GB Swap：

sudo fallocate -l 4G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile

设置开机自动挂载：

echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

调整 Swap 使用倾向：

echo 'vm.swappiness=10' | sudo tee -a /etc/sysctl.conf
sudo sysctl -p

说明：vm.swappiness=10 表示系统尽量少使用 Swap，但在内存紧张时仍可兜底。

4. 调整文件句柄限制

高并发场景下，文件句柄不足会导致连接失败、请求异常。

查看当前限制：

ulimit -n

临时提升：

ulimit -n 65535

永久配置：

sudo vim /etc/security/limits.conf

追加：

* soft nofile 65535
* hard nofile 65535
root soft nofile 65535
root hard nofile 65535

同时修改 systemd 配置：

sudo vim /etc/systemd/system.conf

设置：

DefaultLimitNOFILE=65535

重新加载：

sudo systemctl daemon-reexec

---

三、Docker 部署优化

FastGPT 通常使用 Docker Compose 部署，因此 Docker 的日志、资源限制、网络和镜像管理都会影响稳定性。

1. 设置 Docker 日志限制

如果不限制 Docker 日志，容器日志可能持续膨胀，占满磁盘，最终导致数据库写入失败、服务异常。

编辑 Docker 配置：

sudo vim /etc/docker/daemon.json

写入：

{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "100m",
    "max-file": "3"
  }
}

重启 Docker：

sudo systemctl restart docker

查看配置是否生效：

docker info | grep -A 5 "Logging Driver"

2. 清理无用镜像和日志

查看磁盘占用：

docker system df

清理无用镜像、容器、缓存：

docker system prune -af

如果确认不再需要未使用的数据卷，可执行：

docker volume prune -f

注意：不要随意删除 FastGPT 正在使用的数据库卷，否则可能造成数据丢失。生产环境执行前一定要备份。

3. 为核心容器设置自动重启

在 docker-compose.yml 中为 FastGPT、MongoDB、PostgreSQL、Redis、OneAPI 等服务添加：

restart: always

示例：

services:
  fastgpt:
    image: registry.cn-hangzhou.aliyuncs.com/fastgpt/fastgpt:latest
    restart: always

修改后重启：

docker compose down
docker compose up -d

查看服务状态：

docker compose ps

---

四、MongoDB 性能优化

FastGPT 会使用 MongoDB 存储大量业务数据，例如用户、应用、对话、知识库元数据等。MongoDB 慢会直接影响后台页面加载、会话查询和权限判断。

1. 进入 MongoDB 容器

先查看容器名称：

docker ps | grep mongo

进入容器：

docker exec -it mongo bash

进入 Mongo Shell：

mongosh

如果设置了账号密码：

mongosh -u root -p your_password --authenticationDatabase admin

2. 查看数据库状态

db.stats()

查看集合大小：

show collections

对某个集合查看统计信息：

db.getCollection('chats').stats()

3. 开启慢查询分析

进入目标数据库，例如：

use fastgpt

设置记录超过 100ms 的慢查询：

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

查看慢查询：

db.system.profile.find().sort({ ts: -1 }).limit(10).pretty()

关闭分析：

db.setProfilingLevel(0)

4. 为 MongoDB 分配足够内存

MongoDB 很依赖内存缓存。如果服务器内存不足，频繁从磁盘读取数据，会明显拖慢 FastGPT 后台操作。建议生产环境 MongoDB 至少保留 2GB 以上可用内存，大规模数据建议 4GB 以上。

如果 MongoDB 与 FastGPT、PostgreSQL 部署在同一台机器，建议至少 8GB 内存起步。

---

五、PostgreSQL / PGVector 优化

FastGPT 知识库检索常依赖 PostgreSQL 和 PGVector。如果向量数据量很大，检索速度主要取决于索引、参数、磁盘和内存。

1. 进入 PostgreSQL 容器

查看容器：

docker ps | grep postgres

进入容器：

docker exec -it postgres bash

登录数据库：

psql -U postgres

如果数据库名不是默认值，使用：

psql -U postgres -d fastgpt

2. 查看数据库大小

SELECT pg_size_pretty(pg_database_size('fastgpt'));

查看所有表大小：

SELECT
  relname AS table_name,
  pg_size_pretty(pg_total_relation_size(relid)) AS size
FROM pg_catalog.pg_statio_user_tables
ORDER BY pg_total_relation_size(relid) DESC;

3. 执行 VACUUM 和 ANALYZE

长期写入、删除知识库数据后，PostgreSQL 中可能产生膨胀，影响查询速度。可以定期执行：

VACUUM ANALYZE;

如果某张表特别大，可以单独执行：

VACUUM ANALYZE table_name;

生产环境不要频繁执行 VACUUM FULL，因为它会锁表。只有在确认低峰期且需要回收大量空间时再使用：

VACUUM FULL;

4. 调整 PostgreSQL 参数

查看配置文件位置：

SHOW config_file;

也可以在容器中查找：

find / -name postgresql.conf 2>/dev/null

常见优化参数如下，适合 8GB 内存服务器作为参考：

shared_buffers = 2GB
effective_cache_size = 6GB
maintenance_work_mem = 512MB
work_mem = 32MB
max_connections = 200
checkpoint_completion_target = 0.9
random_page_cost = 1.1

如果是 16GB 内存服务器，可参考：

shared_buffers = 4GB
effective_cache_size = 12GB
maintenance_work_mem = 1GB
work_mem = 64MB
max_connections = 300
checkpoint_completion_target = 0.9
random_page_cost = 1.1

修改后重启 PostgreSQL 容器：

docker restart postgres

验证参数：

SHOW shared_buffers;
SHOW effective_cache_size;
SHOW work_mem;

5. 检查 PGVector 扩展

进入数据库后执行：

SELECT * FROM pg_extension WHERE extname = 'vector';

如果未启用：

CREATE EXTENSION IF NOT EXISTS vector;

6. 为向量表建立索引

不同 FastGPT 版本和部署方式中，向量表名称可能不同，请先查看表结构：

\dt

查看包含向量字段的表：

SELECT table_name, column_name, data_type
FROM information_schema.columns
WHERE data_type = 'USER-DEFINED';

如果你的向量字段名为 embedding，表名为 modeldata，可以参考创建 HNSW 索引：

CREATE INDEX CONCURRENTLY IF NOT EXISTS modeldata_embedding_hnsw_idx
ON modeldata
USING hnsw (embedding vector_cosine_ops);

如果使用 IVFFLAT：

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

创建索引后执行：

ANALYZE modeldata;

注意：实际表名和字段名必须以你的数据库为准。创建索引前建议备份数据库，并在低峰期执行。

---

六、FastGPT 应用层优化

1. 控制知识库召回数量

很多人为了提高回答准确率，会把知识库召回数量设置得很大，例如 20、30、50。这样会导致：

• 向量检索耗时增加；
• Prompt 变长；
• 模型输入 Token 增加；
• 响应速度变慢；
• 调用成本变高。

一般建议：

场景	推荐召回数量
简单 FAQ	3 - 5
普通知识库问答	5 - 8
复杂文档问答	8 - 12
高精度场景	10 - 15

如果召回数量超过 15，建议优先优化分块质量，而不是继续增加召回数量。

2. 优化知识库分块

知识库分块太小，会产生过多向量，导致检索变慢；分块太大，会降低命中精度，并增加 Prompt Token。

推荐分块策略：

• 普通说明文档：每段 500 - 800 字；
• 技术文档：每段 300 - 600 字；
• FAQ 问答：按问题独立分块；
• 合同、制度类文档：按标题层级分块；
• 表格数据：尽量转换为结构化文本。

如果文档质量较差，建议先清洗 Markdown、页眉页脚、重复目录、无意义空格，再导入知识库。

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

FastGPT 的工作流功能很强，但节点越多，执行链路越长。常见性能问题包括：

• 多个 HTTP 节点串行请求；
• 多个大模型节点重复改写；
• 每次都调用知识库检索；
• 每次都写入额外日志；
• 节点条件判断过于复杂。

建议将高频应用的工作流做精简：

• 能合并的提示词尽量合并；
• 能并行的外部接口尽量并行；
• 不必要的大模型改写节点可以移除；
• 固定知识可放入系统提示词；
• 低价值日志不要无限写入。

4. 启用流式输出

如果模型服务支持流式输出，建议在 FastGPT 应用中开启流式返回。流式输出不会缩短模型完整生成时间，但能显著改善用户体感，用户会更早看到首字响应。

---

七、模型网关与大模型接口优化

FastGPT 的整体响应速度很大程度取决于模型接口。即使 FastGPT、数据库都很快，如果模型首字延迟高，用户仍会觉得系统慢。

1. 区分任务模型

不要所有任务都使用最强模型。建议按任务类型拆分：

任务	推荐模型策略
问题改写	使用轻量模型
意图识别	使用轻量模型
知识库问答	使用中高质量模型
长文总结	使用长上下文模型
代码生成	使用代码能力强的模型

这样可以减少等待时间和调用成本。

2. 设置合理超时时间

如果使用 OneAPI 或类似模型网关，建议给上游模型设置合理超时。Nginx、FastGPT、模型网关三处超时时间要协调，避免某一层提前断开。

Nginx 可参考：

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

如果使用 Docker Compose 部署 Nginx，修改配置后重载：

docker exec -it nginx nginx -s reload

或：

docker restart nginx

3. 优化模型网关并发

如果 OneAPI 数据库或网关容器压力过高，可以查看日志：

docker logs -f oneapi

查看资源：

docker stats oneapi

如果 OneAPI 和 FastGPT 在同一台机器，且并发较高，建议将模型网关独立部署，避免互相抢占 CPU 和内存。

---

八、Nginx 反向代理优化

如果 FastGPT 前面有 Nginx，合理配置反向代理可以提升稳定性，尤其是流式输出场景。

示例配置：

server {
    listen 80;
    server_name your-domain.com;

    client_max_body_size 100m;

    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_buffering off;
        proxy_cache off;

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

检查配置：

sudo nginx -t

重载 Nginx：

sudo systemctl reload nginx

如果 Nginx 运行在 Docker 中：

docker exec -it nginx nginx -t
docker exec -it nginx nginx -s reload

这里尤其要注意 proxy_buffering off;，它对流式输出体验很重要。否则用户可能无法及时看到模型逐字输出。

---

九、Redis 缓存优化

Redis 通常用于缓存、会话、队列或临时数据。虽然 FastGPT 的核心数据不一定都在 Redis，但 Redis 异常会影响部分高频访问链路。

查看 Redis 容器：

docker ps | grep redis

进入 Redis：

docker exec -it redis redis-cli

测试连接：

PING

返回：

PONG

查看内存：

INFO memory

查看客户端连接：

INFO clients

如果 Redis 没有持久化要求，可以设置内存淘汰策略，例如：

CONFIG SET maxmemory-policy allkeys-lru

如果要永久生效，需要修改 Redis 配置文件：

maxmemory-policy allkeys-lru

生产环境建议为 Redis 设置密码，并限制外网访问，不要将 Redis 直接暴露到公网。

---

十、备份与恢复：优化前必须做

任何数据库优化、索引调整、容器清理前，都应先备份。

1. 备份 MongoDB

docker exec -it mongo mongodump \
  --username root \
  --password your_password \
  --authenticationDatabase admin \
  --out /backup/mongo-$(date +%F)

如果容器内没有 /backup 目录，可先创建：

docker exec -it mongo mkdir -p /backup

从容器复制到宿主机：

docker cp mongo:/backup ./mongo-backup

2. 备份 PostgreSQL

docker exec -t postgres pg_dump -U postgres fastgpt > fastgpt-$(date +%F).sql

压缩备份：

gzip fastgpt-$(date +%F).sql

恢复：

gunzip fastgpt-2025-01-01.sql.gz
docker exec -i postgres psql -U postgres fastgpt < fastgpt-2025-01-01.sql

3. 备份 Docker Compose 配置

mkdir -p ~/fastgpt-backup
cp docker-compose.yml ~/fastgpt-backup/docker-compose.yml.$(date +%F)
cp .env ~/fastgpt-backup/.env.$(date +%F)

---

十一、常见问题排查命令

1. FastGPT 页面打开慢

查看容器状态：

docker compose ps

查看 FastGPT 日志：

docker logs -f fastgpt

查看 MongoDB 日志：

docker logs -f mongo

查看系统资源：

docker stats

2. 知识库检索慢

进入 PostgreSQL：

docker exec -it postgres psql -U postgres -d fastgpt

查看大表：

SELECT
  relname,
  pg_size_pretty(pg_total_relation_size(relid))
FROM pg_catalog.pg_statio_user_tables
ORDER BY pg_total_relation_size(relid) DESC;

执行统计更新：

ANALYZE;

查看是否存在索引：

SELECT indexname, indexdef
FROM pg_indexes
WHERE schemaname = 'public';

3. 模型回复慢

测试模型接口延迟：

curl -X POST https://your-model-api/v1/chat/completions \
  -H "Authorization: Bearer your_api_key" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "your-model",
    "messages": [
      {
        "role": "user",
        "content": "你好，请简单介绍一下你自己。"
      }
    ],
    "stream": false
  }'

如果模型接口本身耗时很长，应优先优化模型供应商、模型网关或模型选择。

4. 上传文件失败

检查 Nginx 上传限制：

client_max_body_size 100m;

检查 FastGPT 日志：

docker logs -f fastgpt

检查磁盘：

df -h

检查内存：

free -h

---

十二、推荐的生产优化清单

如果你想快速完成一轮基础优化，可以按以下顺序执行：

sudo apt update
sudo apt install -y htop iotop iftop sysstat lsof

设置 Docker 日志限制：

sudo tee /etc/docker/daemon.json > /dev/null <<'EOF'
{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "100m",
    "max-file": "3"
  }
}
EOF

重启 Docker：

sudo systemctl restart docker

开启 4GB Swap：

sudo fallocate -l 4G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab
echo 'vm.swappiness=10' | sudo tee -a /etc/sysctl.conf
sudo sysctl -p

查看容器资源：

docker stats

清理无用 Docker 缓存：

docker system prune -af

备份 PostgreSQL：

docker exec -t postgres pg_dump -U postgres fastgpt > fastgpt-$(date +%F).sql

进入 PostgreSQL 执行维护：

docker exec -it postgres psql -U postgres -d fastgpt

VACUUM ANALYZE;

进入 MongoDB 查看状态：

docker exec -it mongo mongosh

db.stats()

重启服务：

docker compose down
docker compose up -d

---

十三、优化建议总结

FastGPT 性能优化的核心不是单点调参，而是全链路优化。对于大多数自部署用户，优先级建议如下：

1. 先看资源：CPU、内存、磁盘 I/O、Docker 容器占用是否正常；
2. 再看数据库：MongoDB 和 PostgreSQL 是否存在慢查询、大表膨胀、索引缺失；
3. 再看知识库：分块是否合理，召回数量是否过大，是否存在大量低质量文本；
4. 再看模型：模型接口延迟是否过高，是否所有任务都用了重模型；
5. 最后看代理层：Nginx 是否支持流式输出，超时时间是否合理。

如果你的 FastGPT 部署在单台服务器上，最有效的优化通常是：升级到 SSD、增加内存、限制 Docker 日志、优化 PostgreSQL 参数、控制知识库召回数量、使用更快的模型接口。对于中大型团队，建议将 FastGPT、MongoDB、PostgreSQL、Redis、模型网关拆分部署，并配合监控系统持续观察。

性能优化不是一次性工作，而是随着用户量、知识库规模和业务复杂度持续演进的过程。建议每次优化后记录修改项、执行时间、性能变化和回滚方案，这样才能在稳定性和速度之间取得最佳平衡。