FastGPT 高并发解决方案｜附完整命令

在企业知识库问答、智能客服、内部助理、RAG 检索增强生成等场景中，FastGPT 往往会从“试用阶段”快速进入“多人同时使用阶段”。当用户量上来以后，最常见的问题不是功能不可用，而是系统在高并发下出现响应变慢、请求堆积、接口超时、MongoDB 压力升高、向量检索变慢、模型接口限流、容器资源被打满等现象。

本文将从架构、资源、数据库、向量库、模型服务、队列、网关、容器部署和监控等方面，系统介绍 FastGPT 的高并发优化思路，并附上常用的完整命令，方便你直接参考落地。

一、FastGPT 高并发瓶颈通常在哪里？

FastGPT 本身不是单一组件，它通常依赖以下服务：

• FastGPT 应用服务
• MongoDB 数据库
• 向量数据库，例如 Milvus、PGVector、Qdrant、Weaviate 等
• Redis，常用于缓存、队列、限流或会话管理
• OpenAI、Azure OpenAI、本地大模型或中转模型服务
• Nginx、Traefik、APISIX 等反向代理
• Docker、Docker Compose 或 Kubernetes 运行环境

因此，高并发问题不一定只发生在 FastGPT 应用层，而是可能出现在链路中的任意位置。

常见瓶颈包括：

1. FastGPT 容器 CPU 或内存不足
   并发请求较多时，Node.js 服务需要处理大量 HTTP 请求、知识库检索、上下文拼接、流式响应等逻辑。如果容器资源限制太低，容易出现响应变慢。

2. MongoDB 查询压力过大
   用户、应用、对话、知识库、数据集、权限等信息通常都会落在 MongoDB 中。如果没有合理索引，或者连接数不足，高并发时数据库会成为明显瓶颈。

3. 向量数据库检索变慢
   RAG 场景下，每次问答通常都需要进行向量召回。如果数据量大、索引类型不合理、检索参数过高，查询延迟会显著增加。

4. 模型接口限流或响应慢
   很多时候 FastGPT 本身处理很快，但模型接口返回慢，导致请求长时间占用连接。尤其是使用外部大模型 API 时，限流、排队和网络抖动都可能影响整体并发能力。

5. 网关连接数和超时时间设置不合理
   Nginx 默认连接数、超时时间、缓冲设置不适合长连接或流式输出时，容易出现 499、502、504 等问题。

6. 缺少队列和限流机制
   如果所有请求都直接打到模型服务和数据库，高峰期容易发生雪崩。合理的限流、排队和降级策略是高并发系统的关键。

二、高并发优化的总体思路

FastGPT 高并发优化不能只靠“加机器”。正确做法应该是：

先定位瓶颈，再分层优化，最后横向扩展。

推荐按照以下顺序处理：

1. 确认服务器资源是否足够
2. 优化 Docker 和系统参数
3. 提升 FastGPT 应用实例数量
4. 优化 MongoDB 连接、索引和副本集
5. 优化向量数据库索引和检索参数
6. 增加 Redis 缓存和队列能力
7. 配置 Nginx 长连接、超时和负载均衡
8. 对模型接口做限流、熔断和多 Key 轮询
9. 部署监控系统，持续观察性能指标

三、服务器基础优化

高并发环境下，Linux 默认参数通常偏保守，需要调整文件句柄、连接队列、端口范围等配置。

1. 查看当前资源

free -h
df -h
top
htop
ulimit -n

如果没有安装 htop：

sudo apt update
sudo apt install -y htop

CentOS / Rocky Linux：

sudo yum install -y epel-release
sudo yum install -y htop

2. 提高文件句柄限制

编辑配置文件：

sudo vim /etc/security/limits.conf

添加：

* soft nofile 1048576
* hard nofile 1048576
root soft nofile 1048576
root hard nofile 1048576

再编辑：

sudo vim /etc/systemd/system.conf

设置：

DefaultLimitNOFILE=1048576
DefaultLimitNPROC=1048576

然后执行：

sudo systemctl daemon-reexec
sudo reboot

重启后验证：

ulimit -n

3. 优化内核网络参数

编辑：

sudo vim /etc/sysctl.conf

添加：

net.core.somaxconn = 65535
net.core.netdev_max_backlog = 250000
net.ipv4.tcp_max_syn_backlog = 65535
net.ipv4.ip_local_port_range = 1024 65535
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_fin_timeout = 15
net.ipv4.tcp_keepalive_time = 600
net.ipv4.tcp_keepalive_intvl = 30
net.ipv4.tcp_keepalive_probes = 5
fs.file-max = 2097152
vm.max_map_count = 262144

应用配置：

sudo sysctl -p

四、Docker 部署层优化

如果 FastGPT 使用 Docker Compose 部署，建议明确设置容器重启策略、资源限制、日志大小和网络配置。

1. 查看容器状态

docker ps
docker stats

如果发现 FastGPT、MongoDB 或向量数据库容器 CPU 长期接近 100%，说明需要扩容或优化。

2. 设置 Docker 日志轮转

编辑：

sudo vim /etc/docker/daemon.json

写入：

{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "200m",
    "max-file": "5"
  }
}

重启 Docker：

sudo systemctl restart docker

3. 给 FastGPT 服务扩容

如果你的 docker-compose.yml 支持多实例，可以通过以下方式扩容：

docker compose up -d --scale fastgpt=3

需要注意，扩容 FastGPT 应用实例时，前面必须有反向代理或负载均衡，否则请求不会自动分发到多个实例。

查看扩容结果：

docker compose ps

查看资源占用：

docker stats

五、Nginx 反向代理与负载均衡配置

FastGPT 常见问答接口可能会使用流式响应，因此 Nginx 的超时、缓冲和连接配置非常重要。

1. 基础负载均衡配置

新建配置：

sudo vim /etc/nginx/conf.d/fastgpt.conf

示例：

upstream fastgpt_backend {
    least_conn;
    server 127.0.0.1:3000 max_fails=3 fail_timeout=30s;
    server 127.0.0.1:3001 max_fails=3 fail_timeout=30s;
    server 127.0.0.1:3002 max_fails=3 fail_timeout=30s;
    keepalive 128;
}

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

    client_max_body_size 100m;

    location / {
        proxy_pass http://fastgpt_backend;
        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 Connection "";

        proxy_connect_timeout 60s;
        proxy_send_timeout 600s;
        proxy_read_timeout 600s;

        proxy_buffering off;
        proxy_cache off;
    }
}

测试配置：

sudo nginx -t

重载 Nginx：

sudo systemctl reload nginx

2. 增加 Nginx worker 连接数

编辑：

sudo vim /etc/nginx/nginx.conf

推荐配置：

worker_processes auto;

events {
    worker_connections 65535;
    multi_accept on;
    use epoll;
}

再次检查并重载：

sudo nginx -t
sudo systemctl reload nginx

六、MongoDB 高并发优化

MongoDB 是 FastGPT 的核心依赖之一。高并发场景下，MongoDB 需要重点关注连接数、索引、慢查询和磁盘性能。

1. 查看 MongoDB 容器日志

docker logs -f mongo

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

docker ps

2. 进入 MongoDB

docker exec -it mongo mongosh

如果使用账号密码：

docker exec -it mongo mongosh -u root -p your_password --authenticationDatabase admin

3. 查看连接数

db.serverStatus().connections

输出通常包含：

{
  current: 120,
  available: 838740,
  totalCreated: 5000
}

如果 current 持续很高，说明应用连接池或请求量较大，需要观察是否存在连接泄露或慢查询堆积。

4. 查看慢查询

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

关闭 profiling：

db.setProfilingLevel(0)

5. 创建常用索引

具体索引要根据实际集合字段确定。一般可以先查看集合：

show dbs
use fastgpt
show collections

查看已有索引：

db.getCollectionNames().forEach(function(collection) {
  print("Collection: " + collection);
  printjson(db[collection].getIndexes());
});

创建索引示例：

db.chats.createIndex({ userId: 1, updateTime: -1 })
db.chats.createIndex({ appId: 1, updateTime: -1 })
db.datasets.createIndex({ teamId: 1, updateTime: -1 })
db.dataset_datas.createIndex({ datasetId: 1 })
db.dataset_datas.createIndex({ collectionId: 1 })

注意：索引不是越多越好。索引会提升查询性能，但会增加写入成本和磁盘占用。建议结合慢查询结果精准创建。

6. MongoDB 副本集部署建议

生产环境不建议单节点 MongoDB。至少应该使用副本集，提高可用性。

初始化副本集示例：

docker exec -it mongo mongosh

执行：

rs.initiate({
  _id: "rs0",
  members: [
    { _id: 0, host: "mongo1:27017" },
    { _id: 1, host: "mongo2:27017" },
    { _id: 2, host: "mongo3:27017" }
  ]
})

查看状态：

rs.status()

应用连接串示例：

mongodb://user:password@mongo1:27017,mongo2:27017,mongo3:27017/fastgpt?replicaSet=rs0&authSource=admin

七、Redis 缓存与队列优化

Redis 在高并发系统中非常重要，可以承担缓存、限流、会话、任务队列等职责。

1. 查看 Redis 状态

docker exec -it redis redis-cli

执行：

INFO memory
INFO clients
INFO stats

2. 设置 Redis 最大内存策略

进入 Redis：

docker exec -it redis redis-cli

执行：

CONFIG SET maxmemory 2gb
CONFIG SET maxmemory-policy allkeys-lru

如果希望持久化配置，应修改 Redis 配置文件：

maxmemory 2gb
maxmemory-policy allkeys-lru

3. Redis 连接测试

docker exec -it redis redis-cli ping

正常返回：

PONG

4. 高并发下 Redis 建议

推荐使用：

• 单机小规模：Redis 单节点即可
• 中等规模：Redis 主从 + Sentinel
• 大规模：Redis Cluster
• 对话限流：基于用户、团队、应用或 API Key 做限流
• 热点配置：缓存应用配置、模型配置、权限信息和系统参数

八、向量数据库优化

FastGPT 的知识库问答性能，很大程度取决于向量数据库。高并发场景下，需要关注数据规模、索引类型、召回数量和过滤条件。

1. 常见优化方向

• 降低单次检索的 topK
• 避免过大的知识库一次性检索
• 给元数据过滤字段建立索引
• 合理选择向量索引类型
• 将大知识库拆分为多个集合
• 区分热知识库和冷知识库
• 使用更快的 embedding 模型
• 对常见问题做缓存

2. Milvus 查看集合

进入 Milvus Attu 或使用 SDK 查看集合信息。若使用 Docker，可以先查看容器：

docker ps

查看 Milvus 日志：

docker logs -f milvus-standalone

3. Qdrant 查看集合

curl http://127.0.0.1:6333/collections

查看指定集合：

curl http://127.0.0.1:6333/collections/your_collection_name

4. PGVector 索引示例

如果使用 PostgreSQL + PGVector，可以创建 HNSW 索引：

CREATE INDEX ON dataset_vectors
USING hnsw (embedding vector_cosine_ops)
WITH (m = 16, ef_construction = 64);

查询时可以设置：

SET hnsw.ef_search = 80;

如果数据量较大，HNSW 通常比精确搜索更适合高并发检索。

九、模型服务高并发策略

FastGPT 的最终响应速度，很大程度由模型服务决定。即使 FastGPT、数据库和向量库都很快，如果模型接口慢，用户仍然会感受到卡顿。

1. 使用多模型 Key 轮询

如果使用第三方模型 API，可以配置多个 API Key，并在网关层或模型代理层做轮询。

示例思路：

key1 -> 请求 1
key2 -> 请求 2
key3 -> 请求 3
key1 -> 请求 4

这样可以分散单个 Key 的限流压力。

2. 部署模型中转服务

如果你有多个模型供应商，可以在 FastGPT 与模型之间加一层模型代理，例如：

• One API
• New API
• LiteLLM
• 自研模型网关

LiteLLM Docker 示例：

docker run -d \
  --name litellm \
  -p 4000:4000 \
  -e OPENAI_API_KEY=your_openai_key \
  ghcr.io/berriai/litellm:main-latest \
  --port 4000

测试：

curl http://127.0.0.1:4000/v1/models \
  -H "Authorization: Bearer your_openai_key"

3. 本地大模型并发建议

如果使用 vLLM 部署本地模型，可以参考：

python -m vllm.entrypoints.openai.api_server \
  --model /data/models/Qwen2.5-14B-Instruct \
  --host 0.0.0.0 \
  --port 8000 \
  --tensor-parallel-size 2 \
  --max-model-len 8192 \
  --gpu-memory-utilization 0.9

测试接口：

curl http://127.0.0.1:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "/data/models/Qwen2.5-14B-Instruct",
    "messages": [{"role": "user", "content": "你好"}],
    "stream": false
  }'

高并发下，本地模型重点关注：

• GPU 显存是否足够
• 最大上下文长度是否过大
• 单次请求 token 是否过多
• 是否开启连续批处理
• 是否需要多实例部署
• 是否需要按模型大小分流

十、FastGPT 应用层优化建议

1. 控制知识库召回数量

知识库召回并不是越多越好。召回过多会带来三个问题：

1. 向量检索更慢
2. 上下文更长
3. 模型推理更贵、更慢

建议根据业务设置合理的 topK，例如：

普通问答：topK = 3 ~ 5
复杂文档问答：topK = 5 ~ 10
长文档分析：根据场景单独处理

2. 控制上下文长度

高并发系统中，过长上下文会导致模型响应慢、费用高、吞吐下降。建议：

• 限制历史对话轮数
• 限制单次输入长度
• 对超长文档先摘要再入库
• 对知识库内容进行合理切分
• 避免把无关上下文全部塞给模型

3. 使用缓存

以下内容适合缓存：

• 应用配置
• 模型配置
• 团队权限
• 热门知识库查询结果
• 常见问题答案
• embedding 结果
• 用户限流状态

对于热门问题，可以将最终答案缓存一段时间，避免每次都重新检索和调用模型。

4. 做请求限流

可以按以下维度限流：

• IP
• 用户
• 团队
• 应用
• API Key
• 模型供应商
• 知识库

Nginx 简单限流示例：

limit_req_zone $binary_remote_addr zone=fastgpt_limit:10m rate=10r/s;

server {
    location / {
        limit_req zone=fastgpt_limit burst=20 nodelay;
        proxy_pass http://fastgpt_backend;
    }
}

重载：

sudo nginx -t
sudo systemctl reload nginx

十一、完整 Docker Compose 优化示例

下面是一个简化示例，重点体现资源、重启策略、日志限制和网络配置。实际使用时，需要结合你已有的 FastGPT 官方配置进行调整。

services:
  fastgpt:
    image: ghcr.io/labring/fastgpt:latest
    restart: always
    ports:
      - "3000:3000"
    environment:
      - MONGODB_URI=mongodb://root:password@mongo:27017/fastgpt?authSource=admin
      - REDIS_URL=redis://redis:6379
    deploy:
      resources:
        limits:
          cpus: "2"
          memory: 4G
        reservations:
          memory: 1G
    logging:
      driver: json-file
      options:
        max-size: "200m"
        max-file: "5"
    depends_on:
      - mongo
      - redis

  mongo:
    image: mongo:6
    restart: always
    command: mongod --wiredTigerCacheSizeGB 2
    ports:
      - "27017:27017"
    volumes:
      - ./mongo_data:/data/db
    environment:
      - MONGO_INITDB_ROOT_USERNAME=root
      - MONGO_INITDB_ROOT_PASSWORD=password
    logging:
      driver: json-file
      options:
        max-size: "200m"
        max-file: "5"

  redis:
    image: redis:7
    restart: always
    command: redis-server --maxmemory 2gb --maxmemory-policy allkeys-lru
    ports:
      - "6379:6379"
    volumes:
      - ./redis_data:/data
    logging:
      driver: json-file
      options:
        max-size: "100m"
        max-file: "3"

启动：

docker compose up -d

查看日志：

docker compose logs -f fastgpt

查看资源：

docker stats

十二、监控与压测

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

• CPU 使用率
• 内存使用率
• 磁盘 IO
• 网络带宽
• FastGPT 请求耗时
• MongoDB 慢查询
• Redis 连接数和内存
• 向量数据库检索耗时
• 模型接口平均响应时间
• 5xx 错误率
• 请求排队数量

1. 使用 wrk 压测

安装：

sudo apt install -y wrk

压测示例：

wrk -t8 -c200 -d60s http://fastgpt.example.com

参数说明：

• -t8：使用 8 个线程
• -c200：保持 200 个并发连接
• -d60s：持续压测 60 秒

2. 使用 hey 压测 API

安装：

wget https://hey-release.s3.us-east-2.amazonaws.com/hey_linux_amd64
chmod +x hey_linux_amd64
sudo mv hey_linux_amd64 /usr/local/bin/hey

压测：

hey -n 1000 -c 100 http://fastgpt.example.com

如果是 POST 接口：

hey -n 1000 -c 50 \
  -m POST \
  -H "Content-Type: application/json" \
  -d '{"message":"你好"}' \
  http://fastgpt.example.com/api/your-endpoint

注意：真实问答接口会调用模型，压测时要避免直接打爆模型供应商接口，否则可能产生费用或触发封禁。

十三、推荐生产架构

中小规模生产环境可以采用：

Nginx
  ↓
FastGPT x 2~4
  ↓
MongoDB 副本集
Redis
向量数据库
模型代理服务
  ↓
多个模型供应商或本地模型

较大规模建议采用：

负载均衡 SLB
  ↓
Ingress / API Gateway
  ↓
FastGPT 多副本
  ↓
Redis Cluster
MongoDB Replica Set / Sharding
Vector DB Cluster
Model Gateway
  ↓
OpenAI / Azure / Local LLM / Multi Provider

如果使用 Kubernetes，可以通过 HPA 自动扩缩容：

kubectl autoscale deployment fastgpt \
  --cpu-percent=70 \
  --min=2 \
  --max=10

查看扩缩容状态：

kubectl get hpa
kubectl get pods -o wide

十四、排查问题的实用命令

1. 查看端口监听

ss -lntp

2. 查看连接数量

ss -ant | wc -l

3. 查看某端口连接数

ss -ant | grep ':3000' | wc -l

4. 查看 CPU 和内存

top
free -h

5. 查看磁盘 IO

iostat -x 1

安装：

sudo apt install -y sysstat

6. 查看 Docker 容器资源

docker stats

7. 查看 FastGPT 日志

docker compose logs -f fastgpt

8. 查看最近错误日志

docker compose logs fastgpt --tail=200 | grep -i error

9. 查看 Nginx 错误日志

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

10. 查看 Nginx 访问日志

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

十五、落地建议：不要一开始就过度复杂化

很多团队在优化 FastGPT 高并发时，容易一上来就想上 Kubernetes、分布式 MongoDB、向量数据库集群和复杂模型网关。实际上，如果当前并发量不大，过度复杂化会增加维护成本。

推荐分阶段演进：

第一阶段：单机优化

适合内部试用、小团队使用。

• 提高服务器配置
• 优化 Linux 参数
• 优化 Docker 日志
• 配置 Nginx 超时
• 控制知识库召回数量
• 限制上下文长度

第二阶段：应用多实例

适合几十到几百人使用。

• FastGPT 多副本
• Nginx 负载均衡
• MongoDB 增加索引
• Redis 做缓存和限流
• 模型 API 多 Key 轮询

第三阶段：核心组件集群化

适合企业级生产环境。

• MongoDB 副本集
• Redis Sentinel 或 Cluster
• 向量数据库集群
• 模型代理服务
• Prometheus + Grafana 监控
• 日志采集和告警

第四阶段：平台化治理

适合多业务线、多团队、多租户场景。

• API 网关
• 用户级限流
• 团队级配额
• 模型成本统计
• 请求审计
• 灰度发布
• 自动扩缩容
• 故障熔断与降级

十六、总结

FastGPT 高并发优化的核心不是简单地“把配置调大”，而是要从完整链路出发：入口网关、FastGPT 应用、MongoDB、Redis、向量数据库、模型服务以及系统资源都需要协同优化。

如果只扩容 FastGPT，但 MongoDB 没有索引，数据库仍然会慢；如果数据库很快，但模型接口限流，用户仍然会等待；如果模型能力充足，但 Nginx 超时时间太短，仍然会出现 504；如果没有限流，高峰期请求瞬间涌入，也可能拖垮整个系统。

一套稳定的 FastGPT 高并发方案，通常应该具备以下能力：

• 多实例部署，支持横向扩容
• Nginx 或网关负载均衡
• MongoDB 索引和副本集
• Redis 缓存、限流和队列
• 向量数据库索引优化
• 模型接口多 Key、多供应商或本地模型分流
• 合理控制 topK、上下文长度和 token 消耗
• 完整监控、日志和告警体系
• 压测验证，而不是凭感觉上线

最终建议是：先用监控找到瓶颈，再逐层优化；先解决最明显的问题，再考虑架构升级。这样既能快速提升 FastGPT 的并发能力，也能避免不必要的复杂度和维护成本。