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。 优化模型与工作流通过合理的架构设计可以大幅减少不必要的模型调用。分级使用模型并非所有任务都需要顶级模型。根据任务复杂度选择模型是节省成本的关键。任务类型推荐模型理由简单意图识别、文本分类、关键词提取轻量模型 (如 gpt-3.5-turbo, 本地小模型)任务简单无需复杂推理复杂逻辑推理、创意写作高级模型 (如 gpt-4)需要强大的理解和生成能力拆解复杂任务将一个复杂的 Prompt 拆分为多个顺序节点。先由廉价模型完成分类、提取等预处理再交由高级模型处理核心逻辑。这样能显著减少高级模型处理的 Token 量。批量处理将多个独立的简单任务如批量改写、分类合并为一次调用比多次单独调用更节省 Token。使用 Map-Reduce 模式处理超长文本如数千条数据时先用循环/迭代节点将文本分块交由小模型并行处理最后再由主模型汇总。这不仅能避免单次调用 Token 溢出还能大幅降低成本。♻️ 善用缓存机制缓存是减少重复计算的利器能直接降低调用次数。利用 Dify 内置缓存Dify 会对相同输入的节点执行结果进行缓存。在调试时相同的测试输入会直接命中缓存实现“零成本”重复运行。自建高频问答缓存对于 FAQ 等场景可以在工作流中增加一个“缓存查询”分支收到问题后先在本地缓存如 Redis中查询。若命中直接返回缓存答案跳过模型调用。若未命中再执行 RAG 和模型生成并将新结果存入缓存。此方法在高并发 FAQ 场景下可节省 30%-40% 的 Token。 优化 Agent 与上下文如果使用了 Agent 模式需注意其动态调用工具的特性可能导致 Token 消耗不可控。压缩对话历史采用“最近优先 权重递减”的策略只保留最近几轮的关键对话早期内容可进行摘要或直接丢弃。控制工具调用为每个工具设置清晰的触发条件避免 Agent 盲目尝试多个工具。在 Prompt 中明确规定“仅在有某某关键词时才调用某某工具”。优化工具返回工具返回的结果可能非常冗长应在返回给大模型前由代码节点提取关键信息如 JSON 中的特定字段过滤掉无关数据。 监控与持续改进开启日志与统计在 Dify 中开启详细日志记录每次调用的输入/输出及消耗的 Token 数找出成本最高的环节。定期分析与优化定期检查日志重点关注高频调用是否为重复问题能否引入缓存长输入/输出Prompt 或知识库片段是否过长能否精简模型选择高级模型是否用在了简单任务上