Dify 如何降低成本｜生产环境实测

在企业真正把 AI 应用推向生产环境之后，很多团队会遇到一个非常现实的问题：Demo 阶段看起来成本很低，但一旦接入真实用户、真实业务流量、真实知识库和真实工作流，成本会快速上升。

尤其是使用 Dify 搭建客服机器人、知识库问答、销售助手、运营文案生成、内部流程自动化等应用时，成本通常来自多个方面：

• 大模型调用费用；
• Embedding 向量化费用；
• 知识库检索与重排费用；
• 工作流中多节点多次调用模型的费用；
• 长 Prompt、长上下文带来的 Token 消耗；
• 用户重复提问导致的无效消耗；
• 自建 Dify 的服务器、数据库、向量数据库等基础设施成本；
• 日志、监控、存储与安全合规成本。

本文结合生产环境中的实际优化经验，系统梳理 Dify 在真实业务中如何降低成本。重点不是泛泛而谈“换便宜模型”，而是从架构、模型选择、Prompt、知识库、工作流、缓存、监控和运维等多个层面拆解成本优化方法。

一、生产环境中的成本从哪里来？

在 Dify 中，一个 AI 应用的成本通常不是单一模型 API 费用，而是由多个环节叠加而成。

以一个常见的“企业知识库客服机器人”为例，用户提出一个问题之后，系统可能经历以下流程：

1. 用户输入问题；
2. Dify 接收请求；
3. 调用 Embedding 模型，将问题向量化；
4. 在知识库中进行向量检索；
5. 可选：调用重排模型对检索结果重新排序；
6. 拼接系统 Prompt、用户问题、检索结果；
7. 调用大语言模型生成回答；
8. 将对话记录写入日志；
9. 如果启用了多轮对话，还要把历史消息带入上下文；
10. 如果工作流中有分类、判断、摘要、工具调用等节点，可能还会额外调用模型多次。

也就是说，用户看到的只是“一次回答”，但后端可能已经产生了多次模型调用和多项资源消耗。

在生产环境中，我们观察到成本上升通常来自以下几个原因：

因此，Dify 降本的核心思路不是只盯着单价，而是要做一件事：

让每一次模型调用都变得必要、精准、短小且可控。

二、生产环境实测背景

为了便于说明，本文以一个匿名化的生产场景为例。

该场景是一套企业内部知识问答系统，主要服务于客服、销售、实施和运营团队。系统基于 Dify 搭建，接入了企业内部产品文档、常见问题、售后政策、合同模板、操作手册等资料。

业务规模

• 日均请求量：约 8,000～12,000 次；
• 高峰期 QPS：约 5～15；
• 知识库文档：约 3,000 篇；
• 文档总量：约 800 万中文字符；
• 使用场景：内部问答、客服辅助、销售话术生成、工单处理建议；
• 部署方式：Dify 自建部署；
• 模型来源：同时接入国内外多个模型供应商；
• 使用能力：Chat、Workflow、Knowledge、Embedding、Rerank。

初始问题

系统刚上线时，团队为了追求回答质量，采用了比较“豪华”的配置：

• 默认使用高性能大模型；
• 每次知识库检索召回 8～10 个片段；
• 所有问题都启用 rerank；
• Prompt 中包含大量角色设定、规则、示例；
• 多轮对话保留较长历史；
• 工作流中包含多个 LLM 节点；
• 没有问题缓存；
• 没有按问题类型选择不同模型。

上线后，业务反馈回答效果不错，但成本明显偏高。尤其是在真实用户高频使用之后，月度模型费用增长很快。

经过几轮优化后，在回答质量基本稳定的情况下，整体调用成本下降了约 50%～70%。不同业务场景的降幅不同，最明显的是知识库问答和简单分类场景。

下面展开说明具体优化方法。

三、第一步：建立成本观测，不观测就无法降本

很多团队在 Dify 中做成本优化时，容易直接从“换模型”开始。但实际上，第一步应该是建立观测能力。

如果不知道钱花在哪里，就无法判断优化是否有效。

1. 按应用统计成本

在生产环境中，不同 Dify 应用的成本差异非常大。比如：

• 客服问答应用调用频率高；
• 销售文案应用单次 Token 较多；
• 合同审核应用上下文很长；
• 工单总结应用可能批量调用；
• 内部知识助手可能存在大量重复问题。

因此，需要按应用维度统计：

• 请求次数；
• 输入 Token；
• 输出 Token；
• 平均单次成本；
• 总成本；
• 模型调用次数；
• 平均响应时间；
• 失败率。

只有这样才能判断哪个应用是成本大户。

2. 按节点统计成本

如果使用 Dify Workflow，不能只看整个应用总成本，还要看每个节点的成本。

很多时候，一个工作流中真正昂贵的不是最终回答节点，而是中间的判断、分类、摘要、改写节点。

例如一个工单处理工作流可能包含：

1. 问题分类节点；
2. 情绪识别节点；
3. 知识库检索节点；
4. 工单摘要节点；
5. 解决方案生成节点；
6. 回复润色节点。

如果每个节点都调用高性能模型，那么一次请求可能变成 4～5 次大模型调用。用户只问了一句话，但后端实际消耗远超预期。

3. 按问题类型统计成本

生产环境中，用户问题通常可以分为几类：

• 简单 FAQ；
• 产品操作类问题；
• 复杂业务咨询；
• 多轮追问；
• 文案生成；
• 摘要总结；
• 无效闲聊；
• 越权或敏感问题。

不同问题不应该使用同一种处理方式。

例如“怎么重置密码？”这种问题，根本没有必要调用最强模型。通过意图识别后，使用轻量模型甚至固定模板即可完成。

4. 建议建立成本看板

建议至少做一个基础看板，包含以下指标：

成本优化不是一次性的，而是一个持续工程。没有监控，就容易越改越乱。

四、第二步：模型分层，不要所有问题都用最贵模型

Dify 支持接入多个模型供应商和多种模型，这是降本最重要的基础能力之一。

很多生产环境的典型浪费是：所有任务都走同一个高性能模型。

但真实业务中，并不是所有任务都需要最强模型。

1. 按任务复杂度选择模型

可以把任务分为三层：

第一层：轻量任务

适合使用低成本模型。

典型任务包括：

• 意图分类；
• 关键词提取；
• 简单 FAQ；
• 是否命中某规则；
• 情绪标签；
• 文本格式转换；
• 简单摘要；
• 闲聊识别。

这类任务不需要特别强的推理能力，只要输出稳定即可。

第二层：中等复杂任务

适合使用中等成本模型。

典型任务包括：

• 普通知识库问答；
• 产品操作指导；
• 客服辅助回复；
• 销售话术建议；
• 工单摘要；
• 多轮对话中的普通追问。

这部分是生产环境中的主力流量，成本优化收益最大。

第三层：复杂任务

才需要使用高性能模型。

典型任务包括：

• 复杂逻辑推理；
• 多文档综合分析；
• 合同条款解释；
• 高风险客户回复；
• 复杂技术问题排查；
• 需要高质量结构化输出的场景。

2. 在 Dify Workflow 中做模型路由

可以在工作流前面增加一个“问题分类节点”，先判断问题类型，再路由到不同模型。

示例逻辑：

如果是简单 FAQ → 使用轻量模型或模板回复
如果是普通知识库问答 → 使用中等模型 + 知识库
如果是复杂问题 → 使用高性能模型 + 知识库 + rerank
如果是闲聊或无效问题 → 固定回复或低成本模型
如果是敏感问题 → 拒答模板或人工转接

这种方式在生产环境中非常有效。因为多数企业内部问答并不是复杂推理问题，而是大量重复、简单、明确的操作类问题。

3. 实测效果

在某个知识问答应用中，优化前所有请求都走高性能模型。优化后：

• 约 35% 的问题被识别为简单问题，走轻量模型或模板；
• 约 50% 的问题走中等模型；
• 约 15% 的问题走高性能模型。

最终该应用的大模型调用成本下降约 45%，而用户满意度没有明显下降。对于简单 FAQ，响应速度反而更快。

五、第三步：减少 Token，Token 是最直接的成本

大模型成本通常与 Token 数量强相关。输入 Token 和输出 Token 都会影响费用。

在 Dify 应用中，Token 消耗主要来自：

• 系统 Prompt；
• 用户输入；
• 历史对话；
• 知识库召回片段；
• 工具返回结果；
• 模型输出。

其中最容易被忽视的是系统 Prompt 和知识库召回内容。

1. 压缩系统 Prompt

很多团队写 Prompt 时，会把大量背景、规则、示例、风格要求都塞进去。Demo 阶段无所谓，但生产环境每次调用都会重复发送这些内容。

优化 Prompt 时，应遵循以下原则：

• 删除重复规则；
• 删除无效寒暄；
• 删除模型已经知道的常识；
• 用结构化规则替代长篇描述；
• 把少数必要示例保留，其他移除；
• 尽量用短句；
• 明确输出格式，减少模型自由发挥。

例如原始 Prompt：

你是一个非常专业、耐心、友好并且熟悉我们公司所有产品知识的客服助手。
你需要尽可能详细地回答用户问题，并且回答时需要考虑用户可能并不了解我们的产品。
你要使用礼貌、温和、积极的语气，不要让用户感到被冒犯。
如果你不知道答案，请不要编造，而是告诉用户可以联系人工客服。
回答时请结合知识库内容，不要脱离知识库回答。

可以压缩为：

你是企业客服助手。仅基于知识库回答。
要求：
1. 准确、简洁、礼貌；
2. 不确定时说明无法确认，并建议转人工；
3. 不编造知识库没有的信息。

语义基本一致，但 Token 明显减少。

2. 控制历史对话长度

多轮对话很容易导致上下文越来越长。尤其是 Dify Chat 应用中，如果保留过多历史消息，后续每次调用都会携带大量上下文。

建议：

• 设置合理的历史轮数；
• 对长对话进行摘要；
• 对无关历史进行丢弃；
• 只保留与当前问题相关的上下文；
• 对客服场景，通常保留最近 3～5 轮即可。

在生产环境中，我们发现很多用户并不是连续进行复杂多轮推理，而是不断提出独立问题。如果盲目携带全部历史，会造成大量浪费。

3. 限制输出长度

输出 Token 也会计费。很多回答没有必要生成长篇内容。

可以根据应用场景设置输出约束：

• FAQ：100～200 字；
• 操作步骤：分点回答，最多 5 步；
• 客服建议：不超过 300 字；
• 摘要任务：按指定字段输出；
• 文案生成：根据业务需要设定长度。

在 Prompt 中明确告诉模型：

请用不超过 200 字回答。
如需步骤说明，最多列出 5 步。
不要输出与问题无关的背景介绍。

这种约束不仅降低成本，还能提高用户体验。

六、第四步：优化知识库，避免“召回越多越好”的误区

Dify 知识库能力很强，但知识库配置不当会显著增加成本。

很多团队认为召回越多，回答越准确。实际上，召回过多会带来三个问题：

1. 输入 Token 增加；
2. 无关内容干扰模型；
3. 回答速度变慢。

1. 优化文档分段

知识库分段是影响 RAG 效果和成本的关键。

如果分段太长：

• 单个片段 Token 多；
• 召回后上下文巨大；
• 容易包含无关信息。

如果分段太短：

• 语义不完整；
• 检索结果碎片化；
• 需要召回更多片段才能回答。

生产环境中更推荐根据文档类型设置不同分段策略。

例如：

不要把未经整理的长文档直接导入知识库，否则后期成本和效果都会受影响。

2. 控制召回数量

对于多数知识问答场景，召回 3～5 个高质量片段通常已经足够。召回 8～10 个片段不一定提升准确率，反而会增加 Token。

建议根据问题类型动态设置召回数量：

• 简单 FAQ：召回 1～2 个；
• 普通知识问答：召回 3～5 个；
• 复杂问题：召回 5～8 个；
• 高风险问题：召回后加 rerank 或人工确认。

3. 谨慎使用 Rerank

Rerank 可以提升检索质量，但它也会带来额外成本和延迟。

建议不要对所有问题默认开启 rerank，而是按条件启用：

• 用户问题较长；
• 初始检索相似度较低；
• 召回结果较多；
• 涉及复杂业务；
• 需要高准确率的场景。

如果是简单 FAQ 或命中明确的问题，可以跳过 rerank。

4. 清理低质量知识

知识库质量直接影响成本。低质量文档会导致：

• 检索命中不准确；
• 模型需要消耗更多 Token 判断；
• 用户反复追问；
• 人工干预增加。

建议定期清理：

• 重复文档；
• 过期文档；
• 无标题文档；
• 结构混乱文档；
• 与业务无关内容；
• 大段营销废话；
• 与现行规则冲突的旧资料。

一次知识库治理，往往比单纯换模型更有效。

七、第五步：使用缓存，重复问题不要重复花钱

在企业知识问答场景中，重复问题非常多。

例如：

• 怎么重置密码？
• 发票怎么开？
• 客户如何申请退款？
• 某个产品怎么配置？
• 某个功能在哪里打开？
• 售后政策是什么？

如果每次都完整走一遍知识库检索和模型生成，就会造成明显浪费。

1. 精确缓存

对于完全相同的问题，可以直接缓存答案。

缓存内容包括：

• 用户问题；
• 命中的知识库片段；
• 模型答案；
• 时间戳；
• 适用业务线；
• 版本号。

当用户再次提出相同问题时，直接返回缓存结果。

2. 语义缓存

精确缓存命中率有限，因为用户表达方式不同。

例如：

怎么重置密码？
密码忘了怎么办？
如何找回登录密码？
账号密码无法登录怎么处理？

这些问题语义接近，可以通过向量相似度做语义缓存。

当新问题与历史问题相似度高于阈值时，可以复用答案，或者进入轻量确认流程。

3. 缓存失效机制

缓存不能无限期有效，尤其是涉及政策、价格、产品功能时。

建议设置：

• 普通 FAQ：7～30 天；
• 产品操作类：随版本更新失效；
• 政策类：按政策版本失效；
• 价格类：短周期缓存或不缓存；
• 高风险问题：不直接缓存，或缓存后需人工审核。

4. 实测效果

在客服辅助场景中，启用缓存后：

• 精确缓存命中率约 8%～15%；
• 语义缓存命中率约 15%～30%；
• 高频问题成本下降明显；
• 平均响应时间降低。

缓存带来的降本幅度取决于业务重复度。对于 FAQ 密集型场景，收益非常可观。

八、第六步：简化 Workflow，减少不必要的 LLM 节点

Dify Workflow 很适合构建复杂业务流程，但也容易被过度设计。

有些团队为了让流程看起来“智能”，在每个步骤都加一个 LLM 节点：

• 用 LLM 判断是否需要知识库；
• 用 LLM 判断问题类型；
• 用 LLM 提取关键词；
• 用 LLM 改写问题；
• 用 LLM 总结检索内容；
• 用 LLM 生成答案；
• 用 LLM 润色答案。

结果一次请求消耗多次模型调用。

1. 能用规则就不要用模型

以下任务可以优先使用规则：

• 是否为空输入；
• 是否包含敏感词；
• 是否命中固定关键词；
• 是否为特定格式；
• 是否超过长度限制；
• 是否属于固定业务线；
• 是否需要转人工。

例如，如果用户问题包含“投诉”“退款失败”“合同纠纷”等关键词，可以直接进入高优先级流程，不一定需要模型判断。

2. 能用代码节点就不要用 LLM

Dify Workflow 支持代码节点。对于结构化处理任务，代码往往更稳定、更便宜。

适合代码处理的任务包括：

• JSON 字段提取；
• 日期转换；
• 正则匹配；
• 文本截断；
• 字符串清洗；
• 表格格式转换；
• 参数校验。

3. 合并相似 LLM 节点

如果多个 LLM 节点都在处理相似任务，可以考虑合并。

例如，原流程：

1. 判断问题类型；
2. 判断是否需要知识库；
3. 判断是否需要人工；
4. 判断优先级。

可以合并为一个分类节点，输出结构化 JSON：

{
  "intent": "product_usage",
  "need_knowledge": true,
  "need_human": false,
  "priority": "normal"
}

这样可以减少调用次数。

4. 节点使用轻量模型

即使必须使用 LLM，也不一定使用高性能模型。分类、判断、格式化节点通常可以使用低成本模型。

最终生成答案的节点再根据复杂度选择中高性能模型。

九、第七步：Embedding 与知识库构建成本优化

很多团队只关注在线推理成本，忽略了知识库构建成本。

当文档频繁更新时，Embedding 费用也可能不低。

1. 避免重复向量化

如果文档没有变化，不应该重复生成向量。

建议在文档入库前计算：

• 文档 ID；
• 内容 Hash；
• 更新时间；
• 版本号。

只有内容变化时才重新向量化。

2. 增量更新知识库

不要每次更新都重建整个知识库。生产环境中应尽量使用增量更新：

• 新增文档只处理新增部分；
• 修改文档只处理变更片段；
• 删除文档只删除对应向量；
• 大版本更新再考虑重建。

3. 选择合适的 Embedding 模型

Embedding 模型不一定越贵越好。对于中文知识库，建议重点评估：

• 中文语义检索效果；
• 向量维度；
• 单价；
• 延迟；
• 与向量数据库兼容性；
• 长文本处理能力。

在一些业务场景中，低成本中文 Embedding 模型已经足够满足需求。

十、第八步：自建 Dify 的基础设施降本

如果使用自建 Dify，还需要关注基础设施成本。

典型组件包括：

• Dify API 服务；
• Web 服务；
• Worker；
• PostgreSQL；
• Redis；
• 向量数据库；
• 对象存储；
• Nginx 或网关；
• 日志系统；
• 监控系统。

1. 不要一开始就过度配置

很多团队刚上线时会给 Dify 配置很高规格服务器，但实际 CPU 和内存使用率长期偏低。

建议先根据业务量选择适中配置，再通过监控逐步扩容。

2. Worker 单独扩展

Dify 中一些耗时任务可以由 Worker 处理，例如文档处理、索引构建等。建议将在线服务与后台任务解耦，避免为了后台任务给整体系统加大配置。

3. 向量数据库按规模选择

小规模知识库不一定需要复杂昂贵的向量数据库集群。可以根据数据量和并发需求选择：

• 小规模：轻量方案即可；
• 中规模：使用稳定的向量数据库；
• 大规模：再考虑集群、高可用、分片等能力。

4. 日志存储要设置保留周期

生产环境中对话日志增长很快。如果长期保存所有日志，会产生额外存储成本和合规风险。

建议：

• 普通日志设置保留周期；
• 敏感信息脱敏；
• 高价值对话用于质检；
• 低价值日志定期归档或删除；
• 成本统计数据保留，原始文本不一定长期保存。

十一、第九步：降低无效请求成本

生产环境中有不少请求其实不应该进入大模型。

例如：

• 空输入；
• 乱码；
• 超长无意义文本；
• 恶意刷接口；
• 重复点击；
• 与业务无关闲聊；
• 用户测试性输入；
• 高频机器人请求。

1. 接入前置网关

建议在 Dify 前面增加网关或应用层控制：

• 限流；
• 鉴权；
• IP 黑名单；
• 用户级请求配额；
• 防重复提交；
• 请求长度限制；
• 敏感词过滤。

这些措施可以显著降低无效成本。

2. 对无效问题使用固定回复

例如用户输入：

哈哈
你是谁
随便聊聊
测试一下
123

这类问题不需要进入完整知识库问答流程，可以直接返回固定回复或低成本模型回答。

3. 设置用户配额

对于内部系统，可以按部门、账号、角色设置使用配额：

• 普通用户每日请求上限；
• 高级用户更高额度；
• 批量任务单独审批；
• 高成本应用单独授权。

配额不是为了限制业务，而是为了防止异常使用导致成本失控。

十二、生产环境优化前后对比

以下是某知识问答应用优化前后的典型变化，数据经过脱敏和简化，仅用于说明优化方向。

从结果看，真正有效的不是某一个单点优化，而是组合拳：

1. 模型分层；
2. Prompt 压缩；
3. 知识库治理；
4. 召回数量控制；
5. 条件 rerank；
6. 缓存；
7. Workflow 简化；
8. 成本监控。

十三、推荐的 Dify 降本实施路线

如果你的团队正在使用 Dify，并且已经感受到成本压力，可以按下面顺序推进。

第一阶段：看清成本

• 建立应用级成本统计；
• 建立节点级成本统计；
• 找出 Top 高成本应用；
• 找出 Top 高成本 Prompt；
• 统计平均 Token 和调用次数。

第二阶段：快速止血

• 压缩系统 Prompt；
• 限制输出长度；
• 减少历史对话轮数；
• 降低默认召回片段数量；
• 关闭非必要 rerank；
• 对无效请求做前置过滤。

第三阶段：结构性优化

• 建立模型分层策略；
• 在 Workflow 中加入意图识别和路由；
• 简化多余 LLM 节点；
• 引入缓存；
• 优化知识库分段；
• 清理低质量文档。

第四阶段：长期治理

• 建立成本看板；
• 设置预算告警；
• 定期评估模型性价比；
• 定期清理知识库；
• 统计用户满意度；
• 建立高成本请求复盘机制；
• 对批量任务和高风险任务单独管理。

十四、常见误区

误区一：只换便宜模型

换便宜模型当然可能降本，但如果 Prompt 很长、知识库召回过多、Workflow 调用次数过多，即使换了模型，成本仍然可能偏高，而且效果可能下降。

正确做法是：先减少不必要调用和 Token，再选择合适模型。

误区二：召回越多越准确

RAG 的关键是召回质量，不是召回数量。过多无关上下文会增加成本，还可能让模型回答跑偏。

误区三：所有节点都需要 LLM

很多判断、校验、格式化任务可以用规则或代码完成。LLM 应该用在真正需要语言理解和生成的地方。

误区四：降本一定会牺牲效果

不一定。很多降本动作反而会提升效果，比如：

• 清理知识库；
• 缩短 Prompt；
• 减少无关上下文；
• 控制输出长度；
• 优化工作流；
• 对简单问题快速回复。

这些措施既能降低成本，也能改善响应速度和稳定性。

十五、总结

Dify 是一个非常适合快速构建 AI 应用的平台，但当应用进入生产环境后，成本治理会变得非常重要。

从生产环境实测来看，Dify 降本不能只靠“选择便宜模型”，而应该从整体链路入手：

• 看清成本：建立应用、节点、Token 级别的观测；
• 模型分层：不同任务使用不同模型；
• 减少 Token：压缩 Prompt、控制历史、限制输出；
• 优化知识库：合理分段、减少召回、清理低质文档；
• 条件使用 rerank：不要所有问题都走重排；
• 引入缓存：重复问题不要重复调用模型；
• 简化 Workflow：减少不必要的 LLM 节点；
• 基础设施优化：自建部署要按需配置；
• 过滤无效请求：避免异常流量和低价值请求消耗成本。

一句话总结：

Dify 降本的本质，是把“每次请求都完整调用大模型”，改造成“根据问题价值和复杂度，选择最低成本但足够可靠的处理路径”。

当团队真正建立起这套机制后，AI 应用才能从 Demo 走向可持续的生产系统。