Dify使用大模型的时候，如何可以节省token

在 Dify 中节省 Token 的核心思路是：减少输入长度、优化检索内容、复用计算结果、精简模型调用。以下是具体的实操建议。

📝 精简 Prompt 与输入

Prompt 是 Token 消耗的大头，优化效果立竿见影。

• 压缩 System Prompt

  只保留核心指令、角色定义和必要约束，删除所有解释性、重复性的“废话”。将长示例移至知识库，仅在需要时由模型检索。

• 缩短用户输入

  在传入大模型前，对用户输入进行预处理：

  • 去噪：移除多余空格、特殊符号、HTML 标签。

  • 截断：设定最大长度，丢弃过长的输入。

  • 改写：将口语化、啰嗦的问题改写为精简的 query。

• 控制对话历史

  在多轮对话中，不要无限制地携带历史记录。

  • 限制轮数：仅保留最近 N 轮（如前 3-5 轮）。

  • 关键信息摘要：将早期对话压缩成一条“摘要”，而非携带全部原始记录。

🎯 优化知识库 (RAG) 检索

RAG 场景下，检索到的文档片段会全部计入输入 Token，必须精打细算。

• 精选片段数量

  不要一次性塞入 Top-5 或 Top-10 的结果。从 Top-1 或 Top-3 开始测试，找到准确率与 Token 消耗的最佳平衡点。

• 优化文档切片

  切片不宜过大。在保证语义完整的前提下，尽量切分得小且精准，避免将整篇文章塞入上下文。

• 压缩检索内容

  在拼接上下文时，可以只保留核心内容：

  • 只保留标题和关键段落。

  • 删除检索片段中的冗余格式、注释或示例代码。

• 空结果判断

  如果检索结果为空或不相关，就不要将“无结果”的提示或空文本拼接到 Prompt 中，直接节省这部分 Token。

💡 优化模型与工作流

通过合理的架构设计，可以大幅减少不必要的模型调用。

• 分级使用模型

  并非所有任务都需要顶级模型。根据任务复杂度选择模型，是节省成本的关键。

• 拆解复杂任务

  将一个复杂的 Prompt 拆分为多个顺序节点。先由廉价模型完成分类、提取等预处理，再交由高级模型处理核心逻辑。这样能显著减少高级模型处理的 Token 量。

• 批量处理

  将多个独立的简单任务（如批量改写、分类）合并为一次调用，比多次单独调用更节省 Token。

• 使用 Map-Reduce 模式

  处理超长文本（如数千条数据）时，先用循环/迭代节点将文本分块，交由小模型并行处理，最后再由主模型汇总。这不仅能避免单次调用 Token 溢出，还能大幅降低成本。

♻️ 善用缓存机制

缓存是减少重复计算的利器，能直接降低调用次数。

• 利用 Dify 内置缓存

  Dify 会对相同输入的节点执行结果进行缓存。在调试时，相同的测试输入会直接命中缓存，实现“零成本”重复运行。

• 自建高频问答缓存

  对于 FAQ 等场景，可以在工作流中增加一个“缓存查询”分支：

  1. 收到问题后，先在本地缓存（如 Redis）中查询。

  2. 若命中，直接返回缓存答案，跳过模型调用。

  3. 若未命中，再执行 RAG 和模型生成，并将新结果存入缓存。

     此方法在高并发 FAQ 场景下可节省 30%-40% 的 Token。

🧠 优化 Agent 与上下文

如果使用了 Agent 模式，需注意其动态调用工具的特性可能导致 Token 消耗不可控。

• 压缩对话历史

  采用“最近优先 + 权重递减”的策略，只保留最近几轮的关键对话，早期内容可进行摘要或直接丢弃。

• 控制工具调用

  为每个工具设置清晰的触发条件，避免 Agent 盲目尝试多个工具。在 Prompt 中明确规定“仅在有某某关键词时才调用某某工具”。

• 优化工具返回

  工具返回的结果可能非常冗长，应在返回给大模型前，由代码节点提取关键信息（如 JSON 中的特定字段），过滤掉无关数据。

📊 监控与持续改进

• 开启日志与统计

  在 Dify 中开启详细日志，记录每次调用的输入/输出及消耗的 Token 数，找出成本最高的环节。

• 定期分析与优化

  定期检查日志，重点关注：

  • 高频调用：是否为重复问题？能否引入缓存？

  • 长输入/输出：Prompt 或知识库片段是否过长？能否精简？

  • 模型选择：高级模型是否用在了简单任务上？