Dify 成本太高？这套配置和优化方法能省不少钱

发布人：慈云数据-客服中心发布时间：5小时前阅读量：2

Dify 如何降低成本｜附配置文件

Dify 是一个非常适合企业和团队快速搭建 AI 应用的平台。无论是知识库问答、智能客服、Agent 工作流，还是内部自动化助手，Dify 都能以较低的开发门槛完成落地。

但在真实使用过程中，很多团队会发现一个问题：Dify 本身部署不难，真正持续产生费用的是模型调用、知识库检索、向量化、服务器资源和调试过程中的无效消耗。

如果不做成本控制，一个看似简单的知识库问答应用，在用户量上来之后，每月模型费用、Embedding 费用、服务器费用和存储费用都会快速增长。

本文将系统介绍如何降低 Dify 使用成本，并附上可直接参考的配置文件，包括：

Dify 成本主要来自哪里；
如何选择更经济的模型；
如何降低 Prompt 和 Token 消耗；
如何优化知识库召回；
如何通过缓存减少重复调用；
如何调整 Docker Compose 配置；
如何用本地模型或国产模型降低费用；
如何配置 Nginx、环境变量和资源限制；
企业团队使用 Dify 时的成本治理建议。

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

在讨论降本之前，首先要明确 Dify 的成本构成。很多人以为 Dify 的成本就是“服务器费用”，但实际上服务器往往不是最大头，真正的大头通常是模型调用费用。

Dify 的成本大致可以分为以下几类。

1. 大模型调用费用

这是最主要的成本来源。

每一次用户对话、工作流节点调用、Agent 推理，本质上都会请求一次或多次大模型 API。

费用通常按照以下方式计算：

费用 = 输入 Token 费用 + 输出 Token 费用

比如用户问一句话，系统会把以下内容一起发给模型：

用户问题；
系统提示词；
应用角色设定；
历史对话；
知识库召回内容；
工作流中间变量；
工具调用结果。

很多团队在调试时发现，用户明明只问了一句“公司报销流程是什么？”，但实际发给模型的上下文可能已经有几千甚至上万 Token。

这就是成本升高的主要原因。

2. Embedding 向量化费用

如果你使用 Dify 的知识库功能，就会涉及 Embedding。

知识库有两个阶段会消耗 Embedding：

文档上传和切分时，需要把文本转成向量；
用户查询时，需要把用户问题也转成向量，再去知识库中检索。

如果知识库内容很多，或者频繁更新文档，Embedding 成本也会明显增加。

虽然单次 Embedding 的价格通常低于大模型对话，但对于文档量大、调用频繁的系统，Embedding 成本也不能忽略。

3. Rerank 重排序费用

Dify 支持在知识库检索后使用 Rerank 模型，对召回结果重新排序。

Rerank 可以提升回答准确性，但也会增加额外成本。

如果每次查询都把大量召回片段交给 Rerank 模型处理，费用和延迟都会增加。

因此，Rerank 应该根据业务场景谨慎开启，而不是默认所有应用都打开。

4. 服务器和数据库成本

如果自部署 Dify，需要服务器承载以下服务：

Dify API；
Dify Web；
Worker；
PostgreSQL；
Redis；
向量数据库；
文件存储；
Sandbox；
Nginx 反向代理。

如果部署方式不合理，比如所有组件无限制占用内存，或者 Worker 数量过多，就会导致服务器配置过高，增加固定成本。

5. 调试和测试成本

很多团队忽略了一个隐性成本：调试成本。

比如：

频繁测试同一个工作流；
每次调试都调用高价模型；
测试阶段使用正式知识库；
Prompt 反复试错但没有缓存；
多人同时调试同一个应用。

这些都会带来大量无效消耗。

所以，Dify 降本不只是“换便宜模型”，而是需要从模型、Prompt、知识库、部署、缓存和权限管理等多个方面一起优化。

二、模型选择：优先使用“分层模型策略”

降低 Dify 成本最有效的方式，就是不要所有任务都用最贵的大模型。

很多场景其实不需要顶级模型，例如：

文档摘要；
意图识别；
FAQ 问答；
格式转换；
简单分类；
简单代码生成；
数据提取；
固定模板回复。

这些任务可以使用更便宜的模型完成。

建议采用“分层模型策略”。

1. 简单任务使用低成本模型

例如：

意图识别：使用便宜模型
文本分类：使用便宜模型
关键词提取：使用便宜模型
普通 FAQ：使用便宜模型
格式化输出：使用便宜模型

在 Dify 工作流中，可以把这些节点配置为低成本模型。

比如：

OpenAI：GPT-4o mini、GPT-3.5 级别模型；
DeepSeek：deepseek-chat；
Qwen：qwen-turbo、qwen-plus；
Zhipu：glm-4-flash；
Moonshot：moonshot-v1-8k；
本地模型：Qwen2.5、Llama、Yi、InternLM 等。

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

以下场景再使用高能力模型：

复杂推理
多步骤规划
高价值客户问题
专业法律/医学/金融分析
复杂代码生成
长上下文总结

这样可以避免所有请求都走高价模型。

3. 在工作流中做模型路由

Dify 的工作流非常适合做模型路由。

例如：

第一个节点判断问题复杂度；
如果是普通 FAQ，走低成本模型；
如果是复杂问题，走高能力模型；
如果低成本模型置信度不足，再升级到高能力模型。

示例逻辑：

用户问题
  ↓
意图识别节点：判断问题类型
  ↓
如果是 FAQ / 简单咨询 → 低成本模型
如果是复杂分析 / 多轮推理 → 高能力模型
如果无法判断 → 默认低成本模型 + 兜底升级

这种方式可以显著降低平均调用成本。

三、减少 Token：Dify 降本的核心手段

模型费用通常按 Token 计费，因此减少 Token 是最直接的降本方式。

1. 精简系统提示词

很多团队喜欢写非常长的 Prompt，例如：

你是一个专业、严谨、耐心、细致、逻辑清晰、擅长沟通、善于分析、具备多行业经验的 AI 助手……

这类描述看起来很完整，但每次请求都会重复发送，长期使用成本很高。

更好的方式是简洁明确：

你是企业内部知识库助手。请基于检索内容回答问题。
如果资料中没有答案，请回复“当前知识库未提供相关信息”。
回答需简洁、准确、分点说明。

不要为了“风格”堆砌大量形容词，应把 Prompt 聚焦在任务规则上。

2. 控制历史对话长度

多轮对话会带来大量上下文成本。

如果 Dify 应用开启了较长的上下文记忆，每次请求都会携带历史消息。用户聊得越久，成本越高。

建议：

普通客服类应用：保留最近 3～5 轮对话；
知识库问答：通常保留最近 2～3 轮即可；
单轮工具类应用：可以关闭历史上下文；
长对话应用：使用摘要记忆代替完整历史。

在应用设置中，应避免默认保留过多历史消息。

3. 限制输出长度

输出 Token 也会计费，而且很多应用不需要长篇大论。

建议在模型参数中设置：

max_tokens: 512

或者根据业务调整：

场景	建议最大输出 Token
FAQ 问答	300～500
客服回复	300～800
文档摘要	800～1500
报告生成	2000+
代码生成	1000～3000

对于大多数企业知识库问答，512 或 800 已经足够。

4. 降低知识库召回片段数量

知识库召回内容会被放进上下文里，因此召回越多，输入 Token 越多。

例如每次召回 10 个片段，每个片段 500 字，输入成本会非常高。

建议：

top_k: 3～5

对于普通知识库问答，先从 3 开始测试。如果准确率不足，再调整到 5。

不建议一开始就设置为 10 或更多。

5. 优化文档切分大小

文档切分也会影响成本。

切分太大：

每个召回片段 Token 很多；
模型输入成本升高；
可能包含大量无关内容。

切分太小：

语义不完整；
需要召回更多片段；
容易丢失上下文。

推荐初始配置：

chunk_size: 500～800 tokens
chunk_overlap: 50～100 tokens

中文文档可以按段落和标题结构切分，而不是粗暴按字符数切分。

四、知识库降本：不是召回越多越好

Dify 的知识库功能非常强大，但如果配置不合理，也会带来高成本和低质量。

1. 区分高频知识库和低频知识库

不要把所有文档都堆进一个知识库。

建议拆分为：

通用制度知识库
产品说明知识库
售后 FAQ 知识库
技术文档知识库
销售话术知识库

这样可以让不同应用只绑定必要知识库，减少无关召回。

2. 建立 FAQ 优先机制

对于大量高频问题，没必要每次都走完整 RAG。

例如：

上班时间；
报销流程；
Wi-Fi 密码；
请假规则；
售后联系方式；
发票开具方式。

可以建立 FAQ 数据集或工作流判断：

先匹配 FAQ；
命中则直接返回；
未命中再走知识库检索；
检索失败再调用大模型生成兜底回答。

这样能显著减少大模型调用次数。

3. 谨慎开启 Rerank

Rerank 对提升准确率有帮助，但不是所有场景都必须开启。

建议：

高价值问答：开启 Rerank；
普通 FAQ：不开启；
简单客服：不开启；
技术文档问答：可以开启；
法律、金融、医疗等严肃场景：建议开启。

如果开启 Rerank，也要控制候选数量，例如先召回 10 条，再重排取前 3 条，而不是把大量文本直接输入模型。

五、缓存：减少重复调用的关键

如果用户经常问重复问题，缓存是非常有效的降本手段。

例如：

“怎么申请报销？”
“报销流程是什么？”
“发票怎么报销？”

这些问题本质上可能是同一类问题。

可以通过以下方式降低调用：

FAQ 缓存；
Redis 缓存；
语义相似问题缓存；
工作流节点结果缓存；
对固定输出结果做静态化。

Redis 缓存思路

可以把用户问题标准化后作为 key：

cache_key = app_id + normalized_question

然后缓存模型输出结果。

对于知识库问答，可以设置较短 TTL，例如 1 小时或 1 天。

对于制度类固定问答，可以设置更长 TTL，例如 7 天或 30 天。

六、Dify 自部署降本配置文件

下面给出一套适合中小团队的 Dify 自部署参考配置。

说明：以下配置用于降本思路参考，具体版本和参数需要结合你的 Dify 版本调整。

1. `.env` 环境变量配置示例

# =========================
# Basic
# =========================
CONSOLE_API_URL=https://dify.example.com
CONSOLE_WEB_URL=https://dify.example.com
SERVICE_API_URL=https://dify.example.com
APP_API_URL=https://dify.example.com
APP_WEB_URL=https://dify.example.com

# 建议生产环境关闭调试
DEBUG=false

# =========================
# Security
# =========================
SECRET_KEY=please-change-this-to-a-random-secret-key
INIT_EMAIL=admin@example.com
INIT_PASSWORD=Change_This_Strong_Password

# =========================
# Database
# =========================
DB_USERNAME=postgres
DB_PASSWORD=please-change-db-password
DB_HOST=db
DB_PORT=5432
DB_DATABASE=dify

# 限制数据库连接池，避免小服务器被连接打满
SQLALCHEMY_POOL_SIZE=10
SQLALCHEMY_MAX_OVERFLOW=5
SQLALCHEMY_POOL_RECYCLE=1800

# =========================
# Redis
# =========================
REDIS_HOST=redis
REDIS_PORT=6379
REDIS_PASSWORD=please-change-redis-password
REDIS_DB=0
REDIS_USE_SSL=false

# =========================
# Celery
# =========================
CELERY_BROKER_URL=redis://:please-change-redis-password@redis:6379/1

# 限制 Worker 并发，降低服务器资源占用
CELERY_WORKER_CONCURRENCY=2

# =========================
# Upload
# =========================
UPLOAD_FILE_SIZE_LIMIT=15
UPLOAD_FILE_BATCH_LIMIT=5

# 如果不是必须，限制大文件上传，防止知识库处理成本失控
ETL_TYPE=dify

# =========================
# Vector Store
# =========================
VECTOR_STORE=weaviate

# =========================
# Token / Logging
# =========================
LOG_LEVEL=INFO

# =========================
# Sandbox
# =========================
CODE_EXECUTION_ENDPOINT=http://sandbox:8194
CODE_EXECUTION_API_KEY=please-change-sandbox-key

# =========================
# Cost Control
# =========================
# 建议在应用层配置 max_tokens、temperature、top_k 等参数
# 这里保留成本控制说明，便于团队维护

2. `docker-compose.override.yml` 降本资源限制示例

如果使用 Docker Compose 部署，可以增加一个 docker-compose.override.yml，对服务资源进行限制，避免容器无限占用 CPU 和内存。

version: "3.8"

services:
  api:
    deploy:
      resources:
        limits:
          cpus: "1.00"
          memory: 1024M
        reservations:
          memory: 512M
    environment:
      LOG_LEVEL: INFO
      DEBUG: "false"

  worker:
    deploy:
      resources:
        limits:
          cpus: "1.00"
          memory: 1536M
        reservations:
          memory: 768M
    environment:
      CELERY_WORKER_CONCURRENCY: 2
      LOG_LEVEL: INFO

  web:
    deploy:
      resources:
        limits:
          cpus: "0.50"
          memory: 512M
        reservations:
          memory: 256M

  db:
    deploy:
      resources:
        limits:
          cpus: "1.00"
          memory: 1536M
        reservations:
          memory: 768M

  redis:
    deploy:
      resources:
        limits:
          cpus: "0.50"
          memory: 512M
        reservations:
          memory: 256M

  weaviate:
    deploy:
      resources:
        limits:
          cpus: "1.00"
          memory: 2048M
        reservations:
          memory: 1024M
    environment:
      LIMIT_RESOURCES: "true"
      QUERY_DEFAULTS_LIMIT: 10

需要注意，deploy.resources 在普通 docker compose up 下并非所有字段都会完全生效，如果你使用的是非 Swarm 模式，也可以通过 mem_limit 等方式控制。

示例：

services:
  api:
    mem_limit: 1024m
    cpus: 1.0

  worker:
    mem_limit: 1536m
    cpus: 1.0

  db:
    mem_limit: 1536m
    cpus: 1.0

3. Nginx 反向代理配置示例

Nginx 可以帮助限制请求大小、请求频率，避免恶意或误操作造成成本暴涨。

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

    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl http2;
    server_name dify.example.com;

    ssl_certificate /etc/nginx/ssl/dify.example.com.crt;
    ssl_certificate_key /etc/nginx/ssl/dify.example.com.key;

    client_max_body_size 15m;

    # 简单限流：同一 IP 每秒最多 5 个请求
    limit_req_zone $binary_remote_addr zone=dify_limit:10m rate=5r/s;

    location / {
        limit_req zone=dify_limit burst=20 nodelay;

        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;

        proxy_read_timeout 300s;
        proxy_send_timeout 300s;
    }
}

如果你对外开放 Dify 应用接口，建议一定要做限流，否则可能出现以下问题：

用户频繁刷新；
脚本误调用；
外部恶意请求；
工作流被重复触发；
模型费用异常增长。

七、模型配置建议

下面给出几类常见场景的推荐配置。

1. 企业知识库问答

model:
  name: low-cost-chat-model
  temperature: 0.2
  max_tokens: 600

retrieval:
  top_k: 3
  score_threshold: 0.55
  rerank: false

memory:
  enabled: true
  window: 3

适用场景：

公司制度；
产品文档；
售后问题；
内部流程问答。

特点：

温度低，减少胡编；
输出短，降低 Token；
召回少，减少上下文；
历史轮次少，降低成本。

2. 技术文档问答

model:
  name: medium-capability-chat-model
  temperature: 0.1
  max_tokens: 1000

retrieval:
  top_k: 5
  score_threshold: 0.5
  rerank: true
  rerank_top_n: 3

memory:
  enabled: true
  window: 4

适用场景：

API 文档；
SDK 文档；
运维手册；
错误排查。

技术文档对准确性要求更高，可以适当开启 Rerank，但要控制最终输入片段数量。

3. 简单客服机器人

model:
  name: cheapest-chat-model
  temperature: 0.3
  max_tokens: 400

retrieval:
  top_k: 3
  score_threshold: 0.6
  rerank: false

memory:
  enabled: true
  window: 2

适用场景：

售前咨询；
物流查询说明；
常见问题；
引导人工客服。

客服机器人不应输出过长内容，回答越短越可控。

4. 工作流分类节点

model:
  name: cheapest-chat-model
  temperature: 0
  max_tokens: 100

prompt: |
  请判断用户问题属于以下哪一类：
  1. faq
  2. technical
  3. billing
  4. complaint
  5. other

  只返回类别英文，不要解释。

分类节点一定要便宜、短输出、低温度。

这种节点如果用高价模型，会造成很大浪费。

八、使用本地模型降低成本

如果团队请求量较大，可以考虑接入本地模型。

Dify 支持通过 OpenAI-API-Compatible 方式接入很多本地推理服务，例如：

Ollama；
Xinference；
vLLM；
LM Studio；
LocalAI；
FastChat。

本地模型的优点是：

单次调用成本低；
数据不出内网；
适合高频简单任务；
可以用于分类、摘要、改写、FAQ 等场景。

缺点是：

需要 GPU 或较强 CPU；
运维成本更高；
模型效果可能不如商业大模型；
并发能力需要调优。

Ollama 配置示例

假设本地部署 Ollama：

ollama run qwen2.5:7b

在 Dify 模型供应商中选择 OpenAI-API-Compatible，配置：

provider: openai-compatible
base_url: http://ollama:11434/v1
api_key: ollama
model: qwen2.5:7b

如果是 Docker 环境，需要确保 Dify API 容器可以访问 Ollama 服务。

vLLM 配置示例

vLLM 适合更高并发的本地推理。

启动示例：

python -m vllm.entrypoints.openai.api_server \
  --model Qwen/Qwen2.5-7B-Instruct \
  --host 0.0.0.0 \
  --port 8000 \
  --served-model-name qwen2.5-7b

Dify 中配置：

provider: openai-compatible
base_url: http://your-vllm-server:8000/v1
api_key: dummy-key
model: qwen2.5-7b

本地模型建议优先承担以下任务：

意图分类；
文本改写；
关键词提取；
轻量问答；
文档摘要初稿；
工作流中间节点。

复杂问题仍可路由到商业大模型。

九、Embedding 模型降本方案

Embedding 是知识库成本的重要组成部分。

建议优先选择性价比高的 Embedding 模型：

bge-small-zh；
bge-base-zh；
bge-m3；
text-embedding-3-small；
qwen text embedding；
nomic-embed-text；
m3e-base。

如果数据量大，可以考虑本地 Embedding。

例如使用 Ollama：

ollama pull bge-m3

Dify 配置：

embedding:
  provider: openai-compatible
  base_url: http://ollama:11434/v1
  api_key: ollama
  model: bge-m3

对于中文企业知识库，bge-m3、bge-base-zh 等模型通常有不错表现。

如果你的知识库不是特别复杂，没必要一开始就使用最贵的 Embedding 服务。

十、工作流降本技巧

Dify 工作流非常灵活，但也容易因为节点过多导致成本增加。

1. 避免每个节点都调用大模型

有些逻辑不需要 LLM，例如：

判断字段是否为空；
拼接文本；
正则提取；
数值计算；
简单条件分支；
固定模板输出。

这些应该使用代码节点、条件节点或模板节点完成。

不要把所有问题都交给大模型。

2. 使用条件节点提前结束

例如用户问题命中 FAQ 后，直接返回，不再进入后续 LLM 节点。

用户输入
  ↓
FAQ 匹配
  ↓
命中 → 直接返回
未命中 → 知识库检索
  ↓
模型回答

提前结束流程，可以减少不必要的调用。

3. 对失败路径做限制

有些工作流在失败后会反复重试，导致调用次数增加。

建议：

限制最大重试次数；
工具调用失败后直接提示用户；
不要无限循环调用 Agent；
对外部 API 超时进行保护；
对复杂任务设置人工确认。

十一、团队成本治理建议

如果是团队或企业使用 Dify，建议建立基础成本治理机制。

1. 不同环境使用不同模型

建议区分：

开发环境：便宜模型
测试环境：便宜模型
预生产环境：中等模型
生产环境：按场景分层

不要让测试人员在开发阶段频繁调用高价模型。

2. 设置应用级预算

每个 Dify 应用都应该有预算意识：

客服机器人：每月预算 500 元
内部知识库：每月预算 300 元
销售助手：每月预算 1000 元
技术支持助手：每月预算 800 元

当成本异常时，及时排查：

是否有人批量测试；
是否某个工作流循环调用；
是否召回内容过多；
是否输出长度失控；
是否遭遇恶意请求。

3. 建立 Prompt 审核机制

Prompt 不是越长越好。

团队可以约定：

系统 Prompt 不超过 500 字；
分类 Prompt 不超过 150 字；
输出格式尽量固定；
不在 Prompt 中堆砌无关背景；
不把整篇文档直接塞进 Prompt。

4. 定期分析调用日志

建议每周分析：

哪些应用调用最多；
哪些用户消耗最多；
哪些问题最常见；
哪些工作流节点成本最高；
哪些知识库召回片段过长；
哪些模型调用失败率高。

成本优化不是一次性动作，而是持续运营过程。

十二、推荐的低成本落地架构

对于中小团队，可以采用以下架构：

用户
 ↓
Nginx 限流
 ↓
Dify 应用
 ↓
FAQ / 缓存判断
 ↓
知识库检索
 ↓
低成本模型回答
 ↓
复杂问题路由到高能力模型

模型策略：

分类节点：本地模型或低价模型
FAQ 问答：低价模型
知识库问答：低价或中等模型
复杂推理：高能力模型
Embedding：本地或低价 Embedding
Rerank：仅高价值场景开启

部署策略：

小团队：2 核 4G 起步
中等团队：4 核 8G 或 8 核 16G
高并发团队：API、Worker、DB、向量库分离部署

如果知识库数据量不大，完全没必要一开始就上高规格服务器。

十三、Dify 降本检查清单

最后给出一份实用检查清单。

模型方面

[ ] 是否所有节点都使用了高价模型？
[ ] 是否区分了简单任务和复杂任务？
[ ] 是否使用低价模型做分类、摘要、改写？
[ ] 是否设置了合理的 max_tokens？
[ ] 是否降低了不必要的 temperature？

Prompt 方面

[ ] 系统提示词是否过长？
[ ] 是否包含大量无关说明？
[ ] 是否可以用规则替代长描述？
[ ] 是否限制了输出格式？
[ ] 是否减少了重复上下文？

知识库方面

[ ] top_k 是否过大？
[ ] chunk_size 是否过大？
[ ] 是否开启了不必要的 Rerank？
[ ] 是否拆分了不同知识库？
[ ] 是否有 FAQ 优先机制？

工作流方面

[ ] 是否存在重复调用模型的节点？
[ ] 是否可以用代码节点替代 LLM？
[ ] 是否有提前结束条件？
[ ] 是否限制了失败重试？
[ ] 是否避免了 Agent 无限循环？

部署方面

[ ] 是否限制了上传文件大小？
[ ] 是否配置了 Nginx 限流？
[ ] 是否关闭了 Debug？
[ ] 是否限制了 Worker 并发？
[ ] 是否定期清理无用数据？

总结

Dify 降低成本的关键，不是单纯寻找一个“最便宜的模型”，而是建立一套完整的成本控制体系。

核心思路可以总结为五句话：

简单任务用便宜模型，复杂任务才用高能力模型。
减少 Prompt、历史对话和知识库召回带来的 Token 消耗。
FAQ、缓存和条件分支可以大幅减少重复调用。
Rerank、本地模型、Embedding 要按场景选择，不要默认全开。
自部署时通过资源限制、限流、日志分析和预算机制控制长期成本。

如果你刚开始使用 Dify，建议先从以下配置入手：

model:
  temperature: 0.2
  max_tokens: 600

retrieval:
  top_k: 3
  rerank: false

memory:
  window: 3

deployment:
  debug: false
  worker_concurrency: 2
  upload_file_size_limit: 15MB

这套配置虽然简单，但已经能避免大部分常见成本浪费。

当业务增长后，再逐步引入模型路由、本地模型、语义缓存、Rerank 优化和分布式部署。这样既能保证应用效果，也能让 Dify 的使用成本始终处于可控范围内。

文章标签： Dify降本模型路由 Token优化知识库检索

上一篇：Dify 上线后账单太高？这套降本方案和网关源码可以直接用

下一篇：Dify 用着越来越贵？这份降本指南新手也能照着做

更多栏目

新闻动态

文档中心

下载中心

目录结构

全文

产品与服务

新闻帮助

生态合作

了解我们

Dify 成本太高？这套配置和优化方法能省不少钱

Dify 如何降低成本｜附配置文件

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

1. 大模型调用费用

2. Embedding 向量化费用

3. Rerank 重排序费用

4. 服务器和数据库成本

5. 调试和测试成本

二、模型选择：优先使用“分层模型策略”

1. 简单任务使用低成本模型

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

3. 在工作流中做模型路由

三、减少 Token：Dify 降本的核心手段

1. 精简系统提示词

2. 控制历史对话长度

3. 限制输出长度

4. 降低知识库召回片段数量

5. 优化文档切分大小

四、知识库降本：不是召回越多越好

1. 区分高频知识库和低频知识库

2. 建立 FAQ 优先机制

3. 谨慎开启 Rerank

五、缓存：减少重复调用的关键

Redis 缓存思路

六、Dify 自部署降本配置文件

1. .env 环境变量配置示例

2. docker-compose.override.yml 降本资源限制示例

3. Nginx 反向代理配置示例

七、模型配置建议

1. 企业知识库问答

2. 技术文档问答

3. 简单客服机器人

4. 工作流分类节点

八、使用本地模型降低成本

Ollama 配置示例

vLLM 配置示例

九、Embedding 模型降本方案

十、工作流降本技巧

1. 避免每个节点都调用大模型

2. 使用条件节点提前结束

3. 对失败路径做限制

十一、团队成本治理建议

1. 不同环境使用不同模型

2. 设置应用级预算

3. 建立 Prompt 审核机制

4. 定期分析调用日志

十二、推荐的低成本落地架构

十三、Dify 降本检查清单

模型方面

Prompt 方面

知识库方面

工作流方面

部署方面

总结

1. `.env` 环境变量配置示例

2. `docker-compose.override.yml` 降本资源限制示例