FastGPT 如何降低成本｜附完整命令

在企业引入 AI 应用的过程中，FastGPT 是一个非常常见的选择。它可以帮助团队快速搭建知识库问答、智能客服、企业内部助手、工作流自动化应用，并且支持对接多种大模型、向量数据库和外部工具。相比从零开发一套完整的 AI 应用平台，FastGPT 的优势非常明显：部署快、功能完整、界面友好、生态成熟。

但是，很多团队在实际使用 FastGPT 一段时间后，会遇到一个非常现实的问题：成本越来越高。

这里的成本并不只是服务器费用，还包括模型调用费用、向量模型费用、知识库索引费用、数据库存储费用、带宽费用、运维成本，以及因为配置不合理导致的“隐性浪费”。尤其是当知识库数据量变大、用户访问量增加、应用数量增多之后，如果没有提前做好成本控制，很容易出现“刚开始很便宜，越用越贵”的情况。

本文将从部署架构、模型选择、知识库配置、向量数据库、Prompt 优化、并发控制、日志清理、缓存策略、监控运维等角度，系统讲解 FastGPT 如何降低成本，并附上常用完整命令，方便你直接参考落地。

一、FastGPT 成本主要花在哪里？

在讨论降本之前，必须先搞清楚成本来源。FastGPT 的成本通常由以下几部分组成。

1. 大模型调用成本

这是最核心、最容易快速增长的成本。

当用户向 FastGPT 应用提问时，系统通常会经历以下流程：

1. 接收用户问题；
2. 检索知识库；
3. 拼接上下文；
4. 调用大语言模型生成回答；
5. 返回结果。

其中，大模型调用一般按照 token 计费。输入 token 越多、输出 token 越多，费用越高。

如果知识库上下文拼接过长，或者 Prompt 写得很冗余，单次请求的 token 消耗就会明显上升。对于高频应用来说，这部分费用会被迅速放大。

2. 向量模型成本

FastGPT 的知识库检索依赖向量化。文档导入知识库时，需要将文本切分成多个片段，然后调用 embedding 模型生成向量。

如果你使用的是商业 embedding API，例如 OpenAI、通义、智谱、火山等服务，每次向量化都会产生费用。文档越多、切分越细、重复导入越频繁，成本越高。

3. 服务器成本

自部署 FastGPT 通常需要运行多个组件，例如：

• FastGPT 主服务；
• MongoDB；
• PostgreSQL；
• pgvector；
• Redis；
• sandbox；
• one-api 或其他模型网关；
• Nginx；
• 监控组件。

如果部署方式不合理，例如所有服务都使用过高配置，或者没有根据访问量动态调整资源，就会造成服务器资源浪费。

4. 数据库存储成本

知识库文档、向量数据、聊天记录、应用配置、用户数据等都会占用数据库空间。

其中，向量数据往往是存储大户。一个知识库如果切分出几十万甚至上百万个 chunk，向量库空间会明显增长。聊天记录如果长期不清理，也会持续占用 MongoDB 存储空间。

5. 运维与排障成本

很多团队初期只关注“能不能跑起来”，忽略了监控、日志、备份和告警。等到服务变慢、磁盘占满、模型费用异常增长时，再去排查问题，就会消耗大量人力。

因此，降本不仅是减少账单，更是让系统变得可控、可观测、可维护。

二、优先选择合适的部署方式

FastGPT 常见部署方式有两种：官方云服务和自部署。

如果你的团队技术能力有限，用户量不大，希望快速上线，可以优先选择云服务。云服务的优点是省运维，但长期大规模使用时，灵活性和成本控制空间相对有限。

如果你有一定运维能力，或者需要私有化部署、内网访问、数据自主可控，那么自部署更适合。自部署虽然初期需要配置服务器，但可以更灵活地选择模型、数据库、缓存和监控方案。

推荐部署思路

小团队或测试环境：

• 2 核 4G 或 4 核 8G 服务器；
• Docker Compose 部署；
• 使用轻量模型；
• 知识库数量控制在合理范围内。

中小企业生产环境：

• 4 核 16G 或 8 核 32G；
• MongoDB、PostgreSQL 单独规划数据卷；
• 接入模型网关；
• 配置 Nginx HTTPS；
• 定期清理日志和历史记录。

高并发或多部门使用：

• FastGPT 服务与数据库分离；
• 模型网关独立部署；
• Redis 缓存独立部署；
• PostgreSQL 调优；
• 增加监控告警；
• 根据业务拆分多个知识库或应用。

三、使用 Docker Compose 部署，降低运维成本

Docker Compose 是部署 FastGPT 最常见、最省心的方式之一。它可以将多个服务统一编排，降低安装和维护复杂度。

以下命令适用于 Ubuntu / Debian 系统。

1. 更新系统

sudo apt update && sudo apt upgrade -y

2. 安装基础工具

sudo apt install -y curl wget git vim ca-certificates gnupg lsb-release

3. 安装 Docker

curl -fsSL https://get.docker.com | sudo bash

4. 启动 Docker 并设置开机自启

sudo systemctl enable docker
sudo systemctl start docker

5. 查看 Docker 版本

docker -v

6. 安装 Docker Compose 插件

sudo apt install -y docker-compose-plugin

7. 查看 Docker Compose 版本

docker compose version

8. 克隆 FastGPT 部署文件

git clone https://github.com/labring/FastGPT.git
cd FastGPT

如果你只需要部署文件，可以进入官方提供的部署目录，具体目录可能会随版本变化，建议以官方仓库文档为准。

cd projects/app

9. 启动服务

docker compose up -d

10. 查看服务状态

docker compose ps

11. 查看日志

docker compose logs -f

使用 Docker Compose 的好处是后续升级、重启、排错都比较方便，不需要手动管理大量进程。

四、模型选择是降本的核心

FastGPT 的成本控制，最重要的一点是：不要所有场景都使用最贵、最强的大模型。

很多企业一开始会直接接入 GPT-4、Claude、DeepSeek-R1、通义千问 Max 等能力较强的模型。它们效果很好，但如果所有请求都走高价模型，费用会非常高。

更合理的方式是按场景分层使用模型。

1. 简单问答使用低成本模型

例如：

• FAQ 问答；
• 内部制度查询；
• 产品说明查询；
• 售后流程咨询；
• 固定格式回复。

这类场景不一定需要最强模型，可以使用低成本模型，例如：

• DeepSeek-V3；
• Qwen-Turbo；
• Qwen-Plus；
• GLM-4-Flash；
• Doubao Lite；
• GPT-4o-mini；
• 本地部署的 Qwen、Llama、ChatGLM 等模型。

2. 复杂推理使用高能力模型

例如：

• 法务合同分析；
• 财务报告解读；
• 多步骤规划；
• 复杂代码生成；
• 高价值客户服务；
• 专业知识咨询。

这类场景可以使用更强模型，但应该控制入口，只让真正需要高能力模型的任务调用。

3. 使用模型网关统一管理

建议通过 One API、New API、LiteLLM 等模型网关统一接入模型。这样可以集中管理 key、额度、模型路由、日志、限速和失败重试。

以 One API 为例，可以使用如下命令部署：

mkdir -p /opt/one-api
cd /opt/one-api

创建 docker-compose.yml：

cat > docker-compose.yml <<'EOF'
version: '3.4'

services:
  one-api:
    image: justsong/one-api:latest
    container_name: one-api
    restart: always
    ports:
      - "3000:3000"
    volumes:
      - ./data:/data
    environment:
      - SQL_DSN=/data/one-api.db
      - SESSION_SECRET=change_this_secret
      - TZ=Asia/Shanghai
EOF

启动 One API：

docker compose up -d

查看日志：

docker compose logs -f

访问地址：

http://服务器IP:3000

通过模型网关，你可以把不同供应商的模型统一封装成 OpenAI 兼容接口，然后在 FastGPT 中配置统一地址。这样后续切换模型时，不需要频繁修改 FastGPT 应用。

五、减少 token 消耗，是最直接的降本方式

大模型按 token 计费，所以减少 token 是降低成本最直接的方法。

1. 精简系统 Prompt

很多 FastGPT 应用的 Prompt 写得非常长，甚至把大量重复规则写进系统提示词里。这样每次请求都会携带这些内容，长期来看成本非常高。

低成本 Prompt 原则：

• 去掉重复表达；
• 不写无意义客套话；
• 不把知识库内容硬编码进 Prompt；
• 规则尽量短；
• 输出格式明确；
• 不要求模型输出过长解释。

例如，可以将冗长提示词改成：

你是企业知识库助手。请仅基于检索到的资料回答问题。
如果资料不足，请回答“当前资料中未找到相关信息”。
回答应简洁、准确、分点说明。

这比写几百字角色设定更省 token，也更稳定。

2. 控制知识库引用数量

FastGPT 在回答时会检索知识库片段。如果召回片段过多，每次都会拼接大量上下文，输入 token 会明显增加。

建议配置：

• 简单知识库：召回 3 到 5 条；
• 中等复杂知识库：召回 5 到 8 条；
• 复杂专业知识库：召回 8 到 12 条；
• 不建议默认拉满。

如果回答质量不够，优先优化文档切分和检索质量，而不是盲目增加召回数量。

3. 控制单个 chunk 长度

知识库切分太大，会导致每次召回带入大量无关内容；切分太小，又可能导致语义不完整，召回数量增加。

常见建议：

• FAQ 类文档：300 到 600 字；
• 产品文档：500 到 1000 字；
• 技术文档：800 到 1500 字；
• 法律合同：1000 到 2000 字，并结合标题层级切分。

切分策略不是越细越好，而是要让每个片段具备完整语义。

4. 限制最大输出长度

有些应用默认允许模型输出很长内容，用户问一个简单问题，模型却回答上千字。这不仅影响体验，也增加费用。

建议：

• 客服问答：300 到 600 字；
• 内部知识查询：500 到 800 字；
• 报告生成：根据业务单独配置；
• 不要所有应用都设置超高输出上限。

六、Embedding 模型也要降本

很多团队只关注聊天模型费用，却忽略 embedding 成本。知识库频繁导入、更新、重建时，embedding 费用也会明显增加。

1. 选择低成本 embedding 模型

可以根据需求选择：

• OpenAI text-embedding-3-small；
• 通义 text-embedding-v2；
• 智谱 embedding；
• BGE 系列本地 embedding；
• M3E；
• GTE；
• Jina Embeddings。

如果数据安全要求较高，或者文档量非常大，可以考虑本地部署 embedding 模型。

2. 本地部署 embedding 服务

使用 Ollama 可以快速部署部分本地模型。先安装 Ollama：

curl -fsSL https://ollama.com/install.sh | sh

启动服务：

sudo systemctl enable ollama
sudo systemctl start ollama

拉取模型：

ollama pull bge-m3

测试模型：

ollama run bge-m3

查看已安装模型：

ollama list

如果你使用支持 OpenAI 兼容接口的本地 embedding 服务，可以将其配置到模型网关，再提供给 FastGPT 使用。

3. 避免重复导入知识库

重复导入同一批文档，会造成重复向量化和重复存储。

建议建立文档管理规范：

• 每个文档保留版本号；
• 更新前先确认是否已有旧版本；
• 删除无效文档后再重新导入；
• 不要把临时文件、重复文件、测试文件放入生产知识库；
• 大批量导入前先用小样本验证切分效果。

七、向量数据库优化：少存无效数据

FastGPT 常见使用 PostgreSQL + pgvector 存储向量。向量数据越多，检索成本和存储成本越高。

1. 定期检查数据库大小

进入 PostgreSQL 容器：

docker exec -it pg bash

进入数据库：

psql -U postgres

查看数据库大小：

SELECT pg_database.datname,
       pg_size_pretty(pg_database_size(pg_database.datname)) AS size
FROM pg_database
ORDER BY pg_database_size(pg_database.datname) DESC;

查看表大小：

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

退出：

\q

2. 清理无用知识库

如果 FastGPT 中有长期不用的测试知识库、临时知识库，应及时删除。删除前要确认是否仍有应用依赖，避免误删生产数据。

建议每月做一次知识库审计：

• 哪些知识库仍在使用；
• 哪些知识库访问量极低；
• 哪些知识库是测试数据；
• 哪些知识库内容重复；
• 哪些知识库可以合并。

3. 控制知识库数量

很多企业会为每个小场景单独建知识库，导致碎片化严重。更合理的方式是按照业务域组织知识库，例如：

• 公司制度知识库；
• 产品文档知识库；
• 售后服务知识库；
• 技术支持知识库；
• 销售资料知识库。

这样既方便维护，也能减少重复内容。

八、聊天记录和日志要定期清理

FastGPT 使用过程中会产生大量聊天记录、运行日志和容器日志。如果不清理，磁盘可能被慢慢占满。

1. 查看磁盘使用情况

df -h

查看当前目录大小：

du -sh *

查看 Docker 占用：

docker system df

2. 清理无用 Docker 资源

谨慎执行以下命令，确保不会删除仍需使用的镜像或容器。

清理停止的容器：

docker container prune -f

清理无用镜像：

docker image prune -f

清理无用网络：

docker network prune -f

清理无用构建缓存：

docker builder prune -f

清理所有未使用资源：

docker system prune -f

如果需要清理未使用镜像、容器、网络和缓存，可以执行：

docker system prune -a -f

注意：docker system prune -a -f 会删除未被容器使用的镜像，生产环境执行前必须确认。

3. 限制容器日志大小

Docker 默认日志如果不限制，可能持续增长。建议配置 Docker 日志轮转。

编辑 Docker 配置：

sudo mkdir -p /etc/docker
sudo vim /etc/docker/daemon.json

写入以下内容：

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

重启 Docker：

sudo systemctl daemon-reload
sudo systemctl restart docker

重新启动 FastGPT：

cd /path/to/FastGPT
docker compose up -d

这样可以避免单个容器日志无限增长。

九、用缓存减少重复请求

如果你的应用中有大量重复问题，例如“怎么重置密码”“发票怎么开”“售后流程是什么”，可以考虑引入缓存策略。

缓存的核心思路是：对于高频、标准化问题，不必每次都调用大模型。

可以从三个层面做缓存：

1. 前端缓存：常见问题直接展示；
2. 应用层缓存：相同问题命中后直接返回历史答案；
3. 模型网关缓存：对重复请求做缓存或限流。

如果使用 Redis，可以先部署 Redis：

docker run -d \
  --name redis \
  --restart always \
  -p 6379:6379 \
  redis:7-alpine \
  redis-server --appendonly yes

查看 Redis 状态：

docker ps | grep redis

进入 Redis：

docker exec -it redis redis-cli

测试：

ping

返回：

PONG

缓存并不是所有场景都适用。对于个性化强、上下文变化大的对话，不建议简单缓存完整答案。但对于 FAQ、固定流程说明、政策查询，缓存可以显著降低模型调用次数。

十、并发与限流：防止费用失控

如果 FastGPT 对外开放，尤其是开放给客户、代理商、公众用户使用，一定要做限流。否则一旦出现恶意请求、爬虫请求、循环调用或内部误操作，模型费用可能在短时间内快速上涨。

1. Nginx 简单限流配置

安装 Nginx：

sudo apt install -y nginx

创建站点配置：

sudo vim /etc/nginx/sites-available/fastgpt.conf

示例配置：

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

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

    location / {
        limit_req zone=fastgpt_limit burst=20 nodelay;
        proxy_pass http://127.0.0.1:3000;
        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;
    }
}

启用配置：

sudo ln -s /etc/nginx/sites-available/fastgpt.conf /etc/nginx/sites-enabled/fastgpt.conf

检查配置：

sudo nginx -t

重启 Nginx：

sudo systemctl restart nginx

2. 按用户设置额度

如果是企业内部使用，建议按部门、成员或应用设置额度。例如：

• 普通员工每天 100 次；
• 客服部门每天 1000 次；
• 管理员不限或单独审批；
• 测试应用设置低额度；
• 生产应用设置独立额度。

额度管理的目标不是限制创新，而是避免误用和滥用。

3. 设置模型网关限额

如果使用 One API 或 New API，可以在网关中为不同渠道、令牌、用户设置额度和倍率。这样即使 FastGPT 应用配置错误，也可以在模型网关层面兜底。

十一、用本地模型降低高频场景成本

如果你的业务对响应质量要求不是极端高，或者有大量内部知识库问答，可以考虑本地部署开源模型。

本地模型的优势：

• 单次调用没有 API 费用；
• 数据不出内网；
• 可控性更强；
• 适合高频简单任务。

缺点是：

• 需要 GPU 或较高 CPU 资源；
• 运维复杂度更高；
• 模型效果需要评估；
• 并发能力受硬件限制。

使用 Ollama 部署本地大模型

安装 Ollama：

curl -fsSL https://ollama.com/install.sh | sh

启动服务：

sudo systemctl enable ollama
sudo systemctl start ollama

拉取 Qwen 模型：

ollama pull qwen2.5:7b

运行模型：

ollama run qwen2.5:7b

测试 API：

curl http://localhost:11434/api/generate \
  -d '{
    "model": "qwen2.5:7b",
    "prompt": "请用一句话介绍 FastGPT"
  }'

如果需要 OpenAI 兼容接口，可以使用支持转换的网关工具，将 Ollama 接入 FastGPT。

本地模型适合承担以下任务：

• 问题改写；
• 意图识别；
• 简单分类；
• FAQ 问答；
• 摘要生成；
• 内部低风险问答。

高风险、高价值、高复杂度任务仍然可以交给商业模型。

十二、优化工作流，减少不必要节点

FastGPT 支持工作流，这非常强大，但也可能带来额外成本。很多用户在设计工作流时，会把每一步都交给大模型判断，例如：

• 第一步判断用户意图；
• 第二步改写问题；
• 第三步检索知识库；
• 第四步总结资料；
• 第五步生成答案；
• 第六步再润色；
• 第七步再分类归档。

如果每个节点都调用模型，一次用户请求可能触发多次模型调用，成本自然升高。

优化建议：

1. 能用规则判断的，不用模型；
2. 能用关键词匹配的，不用模型；
3. 能合并的模型节点尽量合并；
4. 对低价值请求提前拦截；
5. 对无效问题直接返回固定提示；
6. 对高成本节点设置触发条件。

例如，用户输入为空、过短、明显无意义时，可以直接返回：

请补充更完整的问题，我会根据知识库为你查询。

不必调用大模型。

十三、监控费用和调用量

降本不能只靠感觉，必须用数据说话。建议至少监控以下指标：

• 每日请求量；
• 每日 token 消耗；
• 每个应用调用次数；
• 每个用户调用次数；
• 每个模型调用次数；
• 平均响应时间；
• 错误率；
• 知识库命中率；
• 无答案比例。

如果使用模型网关，可以从网关后台查看调用统计。如果需要系统级监控，可以使用 Prometheus + Grafana。

查看服务器资源

安装 htop：

sudo apt install -y htop

运行：

htop

查看内存：

free -h

查看磁盘：

df -h

查看端口：

ss -tulnp

查看容器资源：

docker stats

这些命令可以帮助你判断服务器是否资源过剩或资源不足。资源过剩可以降配，资源不足则需要优化或扩容。

十四、备份也能降低长期成本

很多人认为备份只和安全有关，其实备份也和成本有关。如果没有备份，一旦误删知识库、数据库损坏或服务器故障，恢复成本可能远高于日常服务器费用。

1. 备份 MongoDB

进入备份目录：

mkdir -p /opt/backup/mongo
cd /opt/backup/mongo

执行备份：

docker exec mongo mongodump --archive=/tmp/fastgpt-mongo.archive
docker cp mongo:/tmp/fastgpt-mongo.archive ./fastgpt-mongo-$(date +%F).archive

2. 恢复 MongoDB

docker cp ./fastgpt-mongo-2025-01-01.archive mongo:/tmp/fastgpt-mongo.archive
docker exec mongo mongorestore --archive=/tmp/fastgpt-mongo.archive --drop

3. 备份 PostgreSQL

mkdir -p /opt/backup/postgres
cd /opt/backup/postgres
docker exec pg pg_dump -U postgres -d postgres > fastgpt-postgres-$(date +%F).sql

4. 恢复 PostgreSQL

cat fastgpt-postgres-2025-01-01.sql | docker exec -i pg psql -U postgres -d postgres

注意：容器名称、数据库名、用户名可能与你的实际环境不同，执行前需要根据 docker compose ps 结果调整。

十五、推荐的低成本配置方案

如果你是个人开发者、小团队或企业试点，可以参考以下方案。

方案一：最低成本测试环境

适合验证功能，不建议承载正式业务。

• 服务器：2 核 4G；
• 部署方式：Docker Compose；
• 模型：低价 API 模型；
• Embedding：低价 API 或本地 embedding；
• 知识库：少量文档；
• 日志：限制 Docker 日志大小；
• 适用场景：Demo、内部测试、方案验证。

方案二：中小企业生产环境

适合正式内部使用。

• 服务器：4 核 16G 或 8 核 16G；
• 数据库：MongoDB + PostgreSQL；
• 模型：模型网关统一管理；
• 常规问答：低成本模型；
• 复杂任务：高能力模型；
• Embedding：低成本商业模型或本地模型；
• 限流：Nginx + 模型网关；
• 监控：基础资源监控；
• 备份：每日自动备份。

方案三：高频知识库问答环境

适合客服、售前、内部助手等高频场景。

• 服务器：根据并发扩容；
• 模型：本地模型 + 商业模型混合；
• FAQ：缓存或固定回复；
• 知识库：严格清理重复内容；
• 工作流：减少不必要模型节点；
• 限流：用户级、应用级、IP 级；
• 监控：调用量、token、命中率；
• 运维：定期审计成本。

十六、FastGPT 降本清单

最后给你一份可以直接执行的降本检查清单。

模型层面

• 是否所有应用都使用了高价模型？
• 是否可以把简单任务切换到低成本模型？
• 是否通过模型网关统一管理调用？
• 是否设置了模型调用额度？
• 是否监控了每日 token 消耗？

Prompt 层面

• 系统提示词是否过长？
• 是否存在重复规则？
• 是否限制了输出长度？
• 是否要求模型输出不必要的长篇解释？
• 是否把知识库内容硬写进 Prompt？

知识库层面

• 文档是否重复？
• chunk 是否过大或过小？
• 召回数量是否过高？
• 测试知识库是否及时删除？
• 是否频繁重复导入文档？

数据库层面

• MongoDB 是否积累大量聊天记录？
• PostgreSQL 向量数据是否过大？
• 是否定期备份？
• 是否清理过期数据？
• 是否监控磁盘空间？

运维层面

• Docker 日志是否限制大小？
• 是否配置 Nginx 限流？
• 是否查看过 docker stats？
• 是否有基础监控和告警？
• 是否有灾备恢复流程？

结语

FastGPT 的成本控制不是单点优化，而是一套系统工程。真正有效的降本，并不是简单地换一个便宜模型，而是从模型选择、Prompt 设计、知识库切分、向量存储、工作流节点、并发限流、日志清理、监控告警等多个环节共同优化。

如果只做一件事，建议你先从 模型分层 和 减少 token 消耗 开始。因为这两项通常见效最快，也最容易量化。接着再逐步优化 embedding、知识库、数据库和运维配置。

对于大多数团队来说，理想方案不是完全使用最便宜的模型，也不是所有任务都使用最强模型，而是建立一套“按任务价值分配模型能力”的机制：简单问题用低成本模型，高价值任务用高能力模型，重复问题走缓存，无效请求提前拦截，所有调用都有监控和额度。

这样，FastGPT 不仅能跑得起来，还能跑得稳定、跑得便宜、跑得长期可持续。