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

在企业或个人项目中使用 Dify 搭建 AI 应用时，很多人一开始关注的是“能不能跑起来”“效果好不好”，但真正上线之后，很快就会遇到另一个现实问题：成本。

Dify 本身是一个非常优秀的开源 LLM 应用开发平台，可以快速构建 Chatbot、Agent、Workflow、RAG 知识库应用，也支持接入 OpenAI、Anthropic、Azure OpenAI、通义千问、智谱、DeepSeek、Ollama、本地模型等多种模型服务。但如果使用方式不当，尤其是大量调用高价大模型、知识库频繁重建、无缓存、无监控，很容易导致 token 成本快速上涨。

本文将从实际部署和使用角度，系统介绍 Dify 如何降低成本，并附上尽可能完整的命令，帮助你在保证效果的前提下，显著降低 AI 应用运行费用。

一、Dify 成本主要来自哪里？

在优化成本之前，必须先知道钱花在哪里。Dify 的成本通常主要来自以下几个方面：

1. 大模型调用成本

   • 对话模型调用费用
   • Agent 推理费用
   • Workflow 中多个节点调用费用
   • 长上下文输入导致的 token 成本

2. Embedding 向量模型成本

   • 上传知识库时，需要调用 Embedding 模型
   • 文档更新越频繁，费用越高
   • 文档切分过细，也会增加向量化次数

3. Rerank 重排模型成本

   • 为了提高 RAG 检索质量，可能会接入 rerank 模型
   • 每次问答都可能调用一次

4. 服务器成本

   • Dify 服务端
   • PostgreSQL
   • Redis
   • 向量数据库
   • 本地大模型推理服务器

5. 运维与带宽成本

   • 日志
   • 监控
   • 备份
   • 文件存储
   • API 网关

如果你使用 Dify 云服务，主要成本集中在平台订阅和模型调用；如果你选择自部署，则可以在服务器、模型供应商、调用策略等方面获得更大优化空间。

二、成本优化的核心思路

Dify 降低成本的核心不是简单地“换成便宜模型”，而是要建立一套分层策略：

一句话总结：

便宜模型处理大多数请求，贵模型只处理真正需要它的请求。

三、优先选择自部署 Dify

如果你对成本敏感，建议优先考虑自部署 Dify。自部署可以让你灵活选择模型服务商、本地模型、数据库、向量库以及缓存方案。

下面以 Docker Compose 方式部署 Dify 为例。

四、安装 Docker 和 Docker Compose

以下命令适用于 Ubuntu 20.04 / 22.04 / 24.04。

1. 更新系统

sudo apt update
sudo apt upgrade -y

2. 安装基础依赖

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

3. 安装 Docker 官方 GPG Key

sudo install -m 0755 -d /etc/apt/keyrings

curl -fsSL https://download.docker.com/linux/ubuntu/gpg \
  | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg

sudo chmod a+r /etc/apt/keyrings/docker.gpg

4. 添加 Docker 软件源

echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] \
  https://download.docker.com/linux/ubuntu \
  $(lsb_release -cs) stable" \
  | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

5. 安装 Docker

sudo apt update

sudo apt install -y docker-ce docker-ce-cli containerd.io \
  docker-buildx-plugin docker-compose-plugin

6. 验证 Docker

docker --version
docker compose version

7. 将当前用户加入 Docker 用户组

sudo usermod -aG docker $USER

执行后建议重新登录服务器，或者运行：

newgrp docker

五、部署 Dify

1. 拉取 Dify 源码

git clone https://github.com/langgenius/dify.git
cd dify/docker

2. 复制环境变量文件

cp .env.example .env

3. 编辑配置文件

nano .env

你可以重点关注以下配置：

CONSOLE_WEB_URL=http://你的服务器IP
APP_WEB_URL=http://你的服务器IP
SERVICE_API_URL=http://你的服务器IP

如果你使用域名，可以配置为：

CONSOLE_WEB_URL=https://dify.example.com
APP_WEB_URL=https://dify.example.com
SERVICE_API_URL=https://dify.example.com

4. 启动 Dify

docker compose up -d

5. 查看容器状态

docker compose ps

6. 查看日志

docker compose logs -f

7. 停止服务

docker compose down

8. 更新 Dify

cd dify
git pull
cd docker
docker compose pull
docker compose up -d

六、使用更便宜的模型服务商

降低 Dify 成本最直接的方法，就是选择性价比更高的模型。

常见模型选择策略如下：

在 Dify 中配置模型时，建议不要只添加一个“最强模型”，而是至少配置两类模型：

1. 低成本默认模型
2. 高能力兜底模型

例如：

• 默认对话使用 DeepSeek Chat、Qwen Turbo、GPT-4o mini
• 复杂推理使用 DeepSeek Reasoner、Claude Sonnet、GPT-4o
• Embedding 使用便宜或本地 Embedding 模型
• 内部测试使用 Ollama 本地模型

七、通过 LiteLLM 做模型网关，统一管理成本

如果你同时使用多个模型供应商，建议在 Dify 前面加一层 LiteLLM Proxy。

LiteLLM 的作用包括：

• 统一 OpenAI API 格式
• 多模型路由
• 设置预算
• 设置调用日志
• 配置 fallback 模型
• 控制不同应用的 API Key
• 统计每个模型的 token 消耗

1. 创建 LiteLLM 目录

mkdir -p ~/litellm
cd ~/litellm

2. 创建配置文件

nano config.yaml

示例配置如下：

model_list:
  - model_name: cheap-chat
    litellm_params:
      model: deepseek/deepseek-chat
      api_key: os.environ/DEEPSEEK_API_KEY

  - model_name: reasoning-model
    litellm_params:
      model: deepseek/deepseek-reasoner
      api_key: os.environ/DEEPSEEK_API_KEY

  - model_name: openai-mini
    litellm_params:
      model: openai/gpt-4o-mini
      api_key: os.environ/OPENAI_API_KEY

  - model_name: premium-chat
    litellm_params:
      model: openai/gpt-4o
      api_key: os.environ/OPENAI_API_KEY

general_settings:
  master_key: sk-litellm-master-key

3. 创建 Docker Compose 文件

nano docker-compose.yml

内容如下：

services:
  litellm:
    image: ghcr.io/berriai/litellm:main-latest
    container_name: litellm
    ports:
      - "4000:4000"
    environment:
      DEEPSEEK_API_KEY: "你的DeepSeek API Key"
      OPENAI_API_KEY: "你的OpenAI API Key"
    volumes:
      - ./config.yaml:/app/config.yaml
    command: ["--config", "/app/config.yaml", "--port", "4000"]
    restart: always

4. 启动 LiteLLM

docker compose up -d

5. 查看日志

docker logs -f litellm

6. 测试模型接口

curl http://localhost:4000/v1/chat/completions \
  -H "Authorization: Bearer sk-litellm-master-key" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "cheap-chat",
    "messages": [
      {
        "role": "user",
        "content": "请用一句话介绍 Dify。"
      }
    ]
  }'

7. 在 Dify 中接入 LiteLLM

在 Dify 后台添加模型供应商时，可以选择 OpenAI-compatible 类型：

Base URL: http://你的服务器IP:4000/v1
API Key: sk-litellm-master-key
Model Name: cheap-chat

这样，Dify 以为自己在调用 OpenAI 兼容接口，实际由 LiteLLM 转发到不同模型供应商。

八、使用 Ollama 本地模型降低高频调用成本

如果你的应用以内部使用、知识库问答、简单分类、摘要、改写为主，可以考虑接入本地模型。虽然本地模型需要服务器资源，但当调用量较高时，长期成本可能低于持续调用商业 API。

1. 安装 Ollama

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

2. 启动 Ollama

ollama serve

如果已经作为 systemd 服务运行，可以使用：

sudo systemctl status ollama

3. 拉取模型

例如拉取 Qwen2.5：

ollama pull qwen2.5:7b

或者拉取 Llama：

ollama pull llama3.1:8b

4. 测试本地模型

ollama run qwen2.5:7b

输入：

请用中文介绍一下 Dify。

5. 查看 Ollama 模型列表

ollama list

6. 开放 Ollama 服务地址

如果 Dify 与 Ollama 不在同一容器网络，可能需要设置监听地址。

sudo systemctl edit ollama

加入：

[Service]
Environment="OLLAMA_HOST=0.0.0.0:11434"

重新加载并重启：

sudo systemctl daemon-reload
sudo systemctl restart ollama

测试接口：

curl http://localhost:11434/api/generate \
  -d '{
    "model": "qwen2.5:7b",
    "prompt": "请介绍 Dify",
    "stream": false
  }'

7. 在 Dify 中配置 Ollama

在 Dify 后台添加模型供应商，选择 Ollama，配置：

Base URL: http://你的服务器IP:11434
Model: qwen2.5:7b

如果 Dify 和 Ollama 在同一台服务器上但容器访问宿主机，可以尝试：

http://host.docker.internal:11434

Linux 下如不可用，可以在 docker-compose.yml 中加入：

extra_hosts:
  - "host.docker.internal:host-gateway"

九、Embedding 模型成本优化

很多人只关注聊天模型费用，却忽略了 Embedding 成本。对于知识库应用来说，上传文档时会对文本分段并生成向量。如果文档量很大，Embedding 成本也不低。

优化方式包括：

1. 选择低成本 Embedding 模型
2. 使用本地 Embedding 模型
3. 减少重复上传
4. 合理设置文档切分长度
5. 避免过小 chunk
6. 只对有效内容建库

例如，很多文档中有大量页眉、页脚、版权声明、目录、无意义表格，这些内容进入知识库后，不仅浪费 Embedding 成本，还会降低检索质量。

建议在上传前先清洗文档。

十、使用本地 Embedding 模型

如果知识库文档较多，可以考虑使用本地 Embedding 模型，例如 nomic-embed-text。

1. 使用 Ollama 拉取 Embedding 模型

ollama pull nomic-embed-text

2. 测试 Embedding 接口

curl http://localhost:11434/api/embeddings \
  -d '{
    "model": "nomic-embed-text",
    "prompt": "Dify 是一个 AI 应用开发平台"
  }'

3. 在 Dify 中配置

在 Dify 后台添加 Ollama Embedding 模型：

Provider: Ollama
Model Type: Text Embedding
Model Name: nomic-embed-text
Base URL: http://你的服务器IP:11434

这样知识库向量化就可以使用本地模型，减少 API 成本。

十一、优化知识库切分策略

知识库问答成本高，往往不是模型本身贵，而是每次检索后塞给模型的上下文太长。

例如用户问一个简单问题，系统检索出 10 个片段，每个片段 1000 字，最终可能把上万字发送给模型。即使输出很短，输入 token 成本也会很高。

建议：

不要盲目设置：

Top K = 10
Chunk Size = 2000
Overlap = 500

这种配置会让每次请求携带大量上下文，成本很容易失控。

更推荐：

Top K = 4
Chunk Size = 800
Overlap = 100
Score Threshold = 0.4～0.6

当然，具体参数需要结合文档类型调试。

十二、在 Prompt 中限制输出长度

输出 token 也是成本的重要组成部分。很多应用明明只需要简洁答案，却让模型长篇大论。

可以在系统提示词中加入约束：

请优先使用简洁中文回答。
除非用户明确要求详细解释，否则回答控制在 300 字以内。
如果问题可以用列表表达，请使用要点列表。
不要输出与问题无关的背景介绍。

对于客服类应用，可以这样写：

你是企业客服助手。
请根据知识库内容回答用户问题。
回答必须简洁、准确，不超过 200 字。
如果知识库中没有相关信息，请回复“暂未查询到相关信息”，不要编造。

对于摘要应用：

请将以下内容总结为 5 条以内要点。
每条不超过 30 字。
不要添加原文不存在的信息。

这些看似简单的 Prompt 约束，能够直接减少输出 token。

十三、减少 Workflow 中不必要的大模型节点

Dify Workflow 很强大，但也容易被滥用。有些流程中每一步都调用大模型：

1. 判断用户意图
2. 改写问题
3. 检索知识库
4. 总结检索结果
5. 生成最终回答
6. 再润色一次

如果每次请求都调用 3～5 次模型，成本自然会上涨。

优化建议：

• 简单规则判断不要用大模型
• 能用代码节点解决的，不用 LLM 节点
• 能用条件分支解决的，不用 Agent 推理
• 问题改写只在长问题或多轮对话中启用
• 润色节点不是必须的
• 对高频固定问题使用 FAQ 或缓存

例如，判断用户是否输入手机号，不需要调用模型，可以使用正则：

import re

def main(text: str) -> dict:
    pattern = r"^1[3-9]\d{9}$"
    return {
        "is_phone": bool(re.match(pattern, text))
    }

判断邮箱也是一样：

import re

def main(email: str) -> dict:
    pattern = r"^[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,}$"
    return {
        "is_email": bool(re.match(pattern, email))
    }

这种规则类任务如果交给大模型，既慢又贵。

十四、使用缓存减少重复调用

很多 AI 应用中，用户问题具有高度重复性，例如：

• 如何修改密码？
• 如何开票？
• 如何联系客服？
• 产品价格是多少？
• 是否支持退款？

这些问题没有必要每次都调用大模型。可以使用缓存或 FAQ 优先返回。

Dify 本身可以通过工作流设计实现类似缓存逻辑，也可以结合 Redis 在外部 API 层做缓存。

Redis 安装命令

sudo apt install -y redis-server

启动 Redis：

sudo systemctl enable redis-server
sudo systemctl start redis-server

检查状态：

sudo systemctl status redis-server

测试 Redis：

redis-cli ping

返回：

PONG

简单缓存思路

你可以在应用入口层对用户问题做归一化，例如：

• 去掉空格
• 转小写
• 去掉标点
• 对常见问题做映射

然后将问题 hash 作为 key，答案作为 value。

示例 Python 代码：

import redis
import hashlib

r = redis.Redis(host="localhost", port=6379, db=0)

def normalize_question(q: str) -> str:
    return q.strip().lower().replace(" ", "")

def cache_key(q: str) -> str:
    normalized = normalize_question(q)
    return "dify:qa:" + hashlib.md5(normalized.encode("utf-8")).hexdigest()

def get_answer(q: str):
    key = cache_key(q)
    value = r.get(key)
    if value:
        return value.decode("utf-8")
    return None

def set_answer(q: str, answer: str, ttl: int = 86400):
    key = cache_key(q)
    r.setex(key, ttl, answer)

缓存命中后，就不用再请求 Dify 或模型 API。

十五、限制最大 token 和上下文长度

在 Dify 应用配置中，应合理限制模型参数：

Max Tokens: 512 或 1024
Temperature: 0.2～0.7
Top P: 0.8～1.0

对于客服问答：

Max Tokens: 300～500
Temperature: 0.2

对于创作类应用：

Max Tokens: 1000～2000
Temperature: 0.7

对于分类、抽取任务：

Max Tokens: 100～300
Temperature: 0

分类任务尤其不应该使用很大的输出长度。例如只需要输出 JSON：

{
  "category": "售后",
  "priority": "高"
}

就不要允许模型输出几千 token。

十六、Agent 成本优化

Agent 的成本通常比普通 Chatbot 更高，因为 Agent 可能会多轮思考、多次调用工具、多次请求模型。

优化 Agent 成本，可以从以下方面入手：

1. 限制最大迭代次数
2. 减少可用工具数量
3. 工具描述写清楚，避免误调用
4. 简单任务不要使用 Agent
5. 对工具参数做校验
6. 让模型直接回答可回答的问题
7. 复杂任务才启用高性能模型

例如系统提示词可以写：

如果用户问题可以直接回答，请不要调用工具。
只有当用户明确要求查询实时数据、订单状态、库存、数据库信息时，才调用工具。
最多调用 2 次工具。
如果工具返回结果为空，请直接说明未查询到结果，不要重复调用。

这样可以有效避免 Agent 陷入反复调用工具的情况。

十七、为不同应用设置不同模型

不要让所有 Dify 应用共用同一个高价模型。应根据应用类型选择模型：

例如：

• “官网客服机器人”使用 cheap-chat
• “合同审查助手”使用 premium-chat
• “SQL 分析助手”使用 reasoning-model
• “内部知识库问答”使用本地 Qwen

这比所有应用统一使用最贵模型要合理得多。

十八、监控 token 消耗

没有监控，就无法控制成本。建议至少做到：

1. 统计每天调用量
2. 统计每个应用调用量
3. 统计每个模型 token 消耗
4. 统计失败请求
5. 统计高频问题
6. 统计高成本用户或接口

如果使用 LiteLLM，可以通过其日志和管理能力进行统计。如果使用云模型平台，也要定期查看控制台账单。

你还可以用 Docker 查看 Dify 服务日志：

cd dify/docker
docker compose logs -f api
docker compose logs -f worker
docker compose logs -f web

查看资源占用：

docker stats

查看磁盘占用：

docker system df

清理无用 Docker 资源：

docker system prune -f

清理无用镜像：

docker image prune -a -f

注意：清理前请确认不会误删仍需使用的镜像和数据。

十九、通过 Nginx 做访问控制

如果你的 Dify 暴露在公网，建议加上访问控制，避免被恶意调用造成费用损失。

1. 安装 Nginx

sudo apt install -y nginx

2. 创建站点配置

sudo nano /etc/nginx/sites-available/dify.conf

示例：

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

    client_max_body_size 50M;

    location / {
        proxy_pass http://127.0.0.1:80;
        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/dify.conf /etc/nginx/sites-enabled/
sudo nginx -t
sudo systemctl reload nginx

如果需要 HTTPS，可以使用 Certbot：

sudo apt install -y certbot python3-certbot-nginx
sudo certbot --nginx -d dify.example.com

二十、设置防火墙，减少风险

使用 UFW：

sudo apt install -y ufw

允许 SSH：

sudo ufw allow OpenSSH

允许 HTTP 和 HTTPS：

sudo ufw allow 80
sudo ufw allow 443

启用防火墙：

sudo ufw enable

查看状态：

sudo ufw status

如果 LiteLLM、Ollama 等服务不需要公网访问，不要开放端口。可以只允许本机或内网访问。

二十一、推荐的低成本架构

对于个人开发者或小团队，可以采用以下架构：

用户
 ↓
Nginx
 ↓
Dify
 ↓
LiteLLM Proxy
 ↓
低成本云模型 / 高性能模型 / 本地 Ollama
 ↓
PostgreSQL + Redis + 向量库

推荐策略：

1. Dify 自部署
2. LiteLLM 统一模型入口
3. 默认使用 cheap-chat
4. 复杂任务切换 premium-chat
5. Embedding 尽量使用低成本或本地模型
6. 高频问题走缓存
7. 知识库控制 Top K 和 Chunk Size
8. Workflow 减少 LLM 节点
9. Agent 限制迭代次数
10. 每周查看 token 消耗

二十二、成本优化检查清单

上线前可以按下面清单逐项检查：

[ ] 是否所有应用都在使用同一个昂贵模型？
[ ] 是否为简单任务配置了低成本模型？
[ ] 是否限制了 Max Tokens？
[ ] 是否优化了 Prompt，避免长篇输出？
[ ] 知识库 Top K 是否过大？
[ ] Chunk Size 是否合理？
[ ] 是否开启了 Score Threshold？
[ ] 是否重复上传了大量文档？
[ ] 是否使用了低成本 Embedding？
[ ] Workflow 是否存在不必要的 LLM 节点？
[ ] Agent 是否限制了最大迭代次数？
[ ] 是否对高频问题做了缓存？
[ ] 是否监控每个应用的 token 消耗？
[ ] 是否避免 LiteLLM、Ollama 暴露公网？
[ ] 是否设置了 API Key 权限和访问控制？

二十三、一个实用的低成本配置示例

假设你要做一个企业内部知识库问答系统，可以这样配置：

模型选择

Chat Model: deepseek-chat 或 qwen-turbo
Embedding Model: nomic-embed-text
Rerank: 默认关闭，必要时开启

知识库参数

Chunk Size: 800
Chunk Overlap: 100
Top K: 4
Score Threshold: 0.5

Prompt

你是企业内部知识库助手。
请只根据知识库内容回答问题。
如果知识库没有相关内容，请回答“知识库中未找到相关信息”。
回答请简洁清晰，不超过 300 字。
如果涉及步骤，请使用编号列表。
不要编造制度、日期、金额和联系人。

模型参数

Temperature: 0.2
Max Tokens: 500

成本策略

普通问题：低成本模型
复杂总结：中等模型
重要审查：高性能模型
重复问题：缓存
内部测试：本地模型

这种配置通常比默认使用最强模型便宜很多，同时效果也能满足大多数内部问答场景。

二十四、总结

Dify 降低成本的关键，不是单纯压缩预算，而是建立合理的 AI 应用成本控制体系。

最有效的做法包括：

1. 自部署 Dify，获得更高可控性
2. 使用低成本模型作为默认模型
3. 通过 LiteLLM 管理多模型与预算
4. 用 Ollama 承担内部高频低难度任务
5. 优化知识库切分、Top K 和上下文长度
6. 限制输出 token，避免无意义长回答
7. 减少 Workflow 中不必要的 LLM 调用
8. 限制 Agent 工具调用次数
9. 使用缓存处理高频重复问题
10. 持续监控 token 消耗和账单

真正成熟的 Dify 应用，不应该是“所有请求都交给最强模型”，而应该是：让每一个请求都用刚好合适的模型和资源处理。

这样既能保证用户体验，又能让成本长期可控。对于企业来说，这也是 AI 应用从 Demo 走向生产环境的关键一步。