Dify 企业级实验（05）：Token 成本控制——AI 应用省钱改造怎么做？

Dify 企业级实验（05）：Token 成本控制——AI 应用省钱改造怎么做？

Dify 实验系列 · 企业级 05/12 | 实验编号：DIFY-104-05
基于 Dify 1.16.1 实测（2026-08）

1. 业务场景

先讲一个我们实际遇到的场景。

AI 应用上线后，老板每个月都要看一张账单：客服问答工作流每月 5 万次调用，单次平均消耗 2.8 万 Token——Token 是持续支出，不是一次性开发成本，调用量越大，账单越吓人。

我们第一次接这类需求时，第一反应也是「省钱不就是压缩 prompt 字数嘛」。真正动手才发现——prompt 省那 1000 Token，杯水车薪；真正烧钱的是「用错了工具」：规则能算的用 LLM 生成，分类器能判的用 LLM 生成。省钱不是抠门，是把每个环节放到它该在的位置上。

同一个结果，用 LLM 生成要花钱，用规则算一分钱不花；用 LLM 生成要花钱，用分类器判只要零头。区别只在于「这个环节值不值得用 LLM」。

这不是个例。任何「LLM 调用量大、跑在真实业务上」的应用都是这个模式：能省的环节没省，钱就在看不见的地方流走。

2. 场景痛点

这个流程的痛点，在每个月看账单的老板身上体现得最直接：

• 每月固定支出：5 万次 × 2.8 万 Token，月消耗千万级 Token，成本随调用量线性上涨，业务增长反而变成成本负担。
• 杀鸡用牛刀：情感分析用 LLM 生成，关键词评分表就能算；意图识别用 LLM 生成，分类器判得更便宜——贵在「用错了工具」。
• 隐性浪费：回答生成的 prompt 又长又固定，每轮固定消耗 1000+ Token，省不出来。
• 降本怕伤质量：改了规则怕回答质量下降、用户投诉，于是一动不敢动。

本质上，成本不是「省」出来的，是「这个环节值不值得用 LLM」设计出来的。

3. 方案：为什么是逐节点审计 + 结构化替代

Dify 的 code 节点、Question Classifier 与 LLM 节点并存，正好支持「先审计、再分类改造」。选它的理由：

• 先审计再动手：逐节点统计 Token 消耗，先找到「烧钱」的节点，再决定改谁；
• 结构化替代：规则能算的（情感）用 code、分类能判的（意图）用 Question Classifier，LLM 只保留核心生成——三次 LLM 调用压成一次；
• 质量回归兜底：改造后跑四层用例回归，降本不降质，敢改也敢验。

这篇文章我们就用它把客服问答工作流做一次「省钱改造」：从 3 次 LLM 调用压到 1 次。

4. 整体架构

改造前是 3 次 LLM 串行；改造后情感分析与意图识别并行执行，结果合并进回答生成的 prompt，全程只有 1 次 LLM 调用。

链路设计的要点：先把「值不值得用 LLM」的判断做在结构上，再谈 prompt 细节。

5. 模块设计

5.1 开始变量

start 变量：user_message（段落，必填，max_length 10000），两个应用完全一致，方便 A/B 对比。

5.2 改造前（基线）

改造前：三个 LLM 节点串行，各自带独立 system prompt（回答生成的 prompt 很长，每轮固定消耗 1000+ Token）。

5.3 改造后：三个核心节点

改造后核心节点：

情感分析改为 code 节点，关键词评分表零成本：

def main(user_message: str) -> dict:
    text = user_message or ""
    pos = ["满意", "好", "赞", "喜欢", "感谢", "棒", "不错"]
    neg = ["差", "坏", "烂", "投诉", "生气", "失望", "退款", "垃圾"]
    score = sum(1 for k in pos if k in text) - sum(1 for k in neg if k in text)
    sentiment = "positive" if score > 0 else ("negative" if score < 0 else "neutral")
    return {"sentiment": sentiment, "score": str(score)}

意图识别改为问题分类器（Question Classifier），四类意图的指令必须带定义与示例：

instruction: |
  对用户消息的意图进行分类，只能归为以下四类之一：
  - 咨询（inquiry）：产品咨询、价格、功能、使用方法
  - 购买（purchase）：下单、购买、优惠、活动
  - 售后（after_sale）：退换货、维修、保修、发票
  - 投诉（complaint）：质量差、损坏、服务态度差、表达不满
  按意图判断，无法归入前三类的归入最接近的一类。
classes: [咨询 inquiry, 购买 purchase, 售后 after_sale, 投诉 complaint]
completion_params: {max_tokens: 2000, temperature: 0.1}

回答生成 LLM 精简 prompt，把前面两个节点的结果作为上下文喂进去，不再让模型重复理解原文：

prompt_template:
  - role: system
    text: 你是电商客服。基于已知信息直接回答，不超过 100 字。
  - role: user
    text: |
      用户消息：{{#start.user_message#}}
      情感：{{#cd_senti.sentiment#}}
      意图：{{#qc_intent.class_name#}}

6. 运行验证

环境：Dify 1.16.1（Docker Compose），模型 DeepSeek deepseek-v4-flash。两个 DSL 均导入发布通过，用 Service API 冒烟验证。

7. 实战坑

8. 实验文档及源码获取

• 实验文档：DIFY-104-05：Token成本控制——AI应用省钱改造.md
• 源码一（改造前）：dify104_05_01_成本控制-改造前.yml
• 源码二（改造后）：dify104_05_02_成本控制-改造后.yml
• 源码目录：dify-104/dsl

文章聚焦核心配置与采坑点，完整分步操作与回归用例见实验文档原文。

下一篇：Dify 企业级实验（06）：可观测性体系——日志埋点与监控告警如何落地？

💬 你在这个实验的场景里踩过什么坑？欢迎评论区分享你的实战经验。