Dify 性能优化教程｜零基础可学

在 AI 应用开发领域，Dify 是一个非常受欢迎的开源大模型应用开发平台。它可以帮助开发者快速搭建 AI 聊天机器人、知识库问答系统、智能客服、工作流自动化应用等。对于很多零基础用户来说，Dify 的优势在于“上手快、功能完整、可视化程度高”。但是，当应用真正投入使用后，很多人会遇到一个共同问题：性能不够理想。

例如：

• 聊天回复速度慢；
• 知识库检索耗时长；
• 多人同时访问时接口卡顿；
• 工作流节点执行时间过长；
• 数据库或向量库负载过高；
• 大模型调用成本持续上升；
• Docker 部署后服务器资源占用异常。

这些问题并不一定说明 Dify 本身“不好用”，更多时候是因为我们没有针对应用场景、部署环境、模型配置、知识库结构和系统资源进行合理优化。

本文将从零基础角度出发，系统讲解 Dify 性能优化的方法。即使你刚接触 Dify，也可以按照本文步骤逐步排查和优化。

一、先理解 Dify 的基本运行结构

在优化性能之前，我们需要先知道 Dify 大致由哪些部分组成。只有知道系统“慢在哪里”，才能有针对性地优化。

Dify 通常包含以下几个核心部分：

1. Web 前端

   • 用户访问的管理后台和应用界面；
   • 负责展示页面、提交请求、显示回复结果。

2. API 服务

   • Dify 的主要后端服务；
   • 负责处理用户请求、调用模型、执行工作流、管理应用配置等。

3. Worker 服务

   • 负责异步任务处理；
   • 例如知识库索引、文档处理、队列任务等。

4. 数据库

   • 通常使用 PostgreSQL；
   • 存储用户、应用、会话、日志、配置等数据。

5. Redis

   • 用于缓存、队列、会话状态等；
   • 对系统响应速度有重要影响。

6. 向量数据库

   • 如 Weaviate、Qdrant、Milvus、Chroma 等；
   • 用于知识库向量检索。

7. 大模型服务

   • 可以是 OpenAI、Claude、Gemini、通义千问、智谱、DeepSeek、Azure OpenAI、本地模型等；
   • 大模型响应速度通常是整体耗时的重要来源。

8. Embedding 模型

   • 用于把文本转换为向量；
   • 主要影响知识库索引速度和检索效果。

一个典型的 Dify 问答请求流程如下：

用户提问
  ↓
Dify API 接收请求
  ↓
判断是否需要知识库检索
  ↓
调用向量库进行召回
  ↓
组装 Prompt
  ↓
调用大模型
  ↓
返回流式响应或完整结果

如果是工作流应用，则还会经过更多节点，例如条件判断、HTTP 请求、代码执行、变量处理、工具调用等。

因此，Dify 性能优化不能只盯着一个地方，而要从整体链路入手。

二、性能优化前必须明确的目标

很多人一上来就问：“Dify 怎么提速？”但这其实是一个很笼统的问题。因为不同场景下，优化目标并不一样。

常见优化目标包括：

在实际优化中，我们应该先回答三个问题：

1. 当前最明显的问题是什么？

   • 是回复慢？
   • 是并发低？
   • 是知识库不准？
   • 是服务器卡死？

2. 问题出现在哪个环节？

   • 模型调用慢？
   • 向量检索慢？
   • 数据库慢？
   • 工作流节点慢？
   • 网络慢？

3. 优化后希望达到什么结果？

   • 首字时间小于 2 秒？
   • 整体响应小于 10 秒？
   • 支持 50 人同时访问？
   • Token 成本降低 30%？

只有目标清晰，优化才不会盲目。

三、第一步：开启流式输出，提高用户感知速度

对于聊天类应用来说，用户最在意的往往不是“完整答案多久生成完”，而是“多久开始回复”。

如果 Dify 应用使用的是非流式输出，用户需要等待模型生成完整答案后才能看到内容。这样即使总耗时只有 8 秒，用户也会觉得很慢。

而开启流式输出后，模型一边生成，Dify 一边返回内容，用户通常在 1～3 秒内就能看到第一段回复。

1. 什么是流式输出？

流式输出可以理解为“边生成边显示”。

非流式输出：

用户提问 → 等待 10 秒 → 一次性显示完整答案

流式输出：

用户提问 → 1 秒后显示第一句话 → 持续显示后续内容

2. 优化建议

在 Dify 应用配置中，尽量开启：

• Streaming；
• 流式响应；
• 边生成边输出。

不同版本和不同模型服务商的设置位置可能略有不同，但一般在模型配置或应用发布设置中可以找到。

3. 注意事项

流式输出并不会让大模型“真实生成速度”变快，但会显著提升用户体验。对于智能客服、聊天助手、知识库问答应用，强烈建议开启。

四、第二步：选择更合适的大模型

Dify 的性能很大程度取决于你选择的大模型。很多时候，系统慢不是 Dify 慢，而是模型服务慢。

1. 大模型影响哪些性能？

大模型主要影响：

• 首字响应时间；
• 总生成时间；
• 并发能力；
• Token 成本；
• 输出质量；
• 长上下文处理能力。

2. 不同模型的使用建议

如果你的应用是普通问答、客服回复、摘要、简单分类，不一定要使用最强模型。可以优先考虑速度更快、价格更低的模型。

例如：

3. 不要所有节点都用最强模型

很多人在 Dify 工作流中，每个 LLM 节点都使用同一个强模型，比如所有节点都使用高成本模型。这样会导致：

• 响应速度慢；
• 成本高；
• 并发压力大；
• 某个节点超时后影响整个流程。

更合理的做法是：

• 信息抽取节点：使用轻量模型；
• 意图识别节点：使用轻量模型；
• 简单判断节点：使用轻量模型或规则；
• 复杂推理节点：使用强模型；
• 最终输出节点：根据业务质量要求选择模型。

4. 控制模型输出长度

模型输出越长，生成时间越长，Token 成本越高。

在 Dify 中可以通过以下方式控制输出：

• 设置最大输出 Token；
• 在 Prompt 中明确要求简洁回答；
• 避免让模型输出无意义长篇内容；
• 对工作流中间节点要求返回 JSON 或短文本；
• 对用户端答案设置合理长度。

例如：

请用不超过 300 字回答用户问题，语言清晰、直接，不要展开无关内容。

这类提示词可以有效减少输出冗余。

五、第三步：优化 Prompt，减少无效 Token

Prompt 是影响 Dify 性能和成本的重要因素。很多应用慢，不是因为模型弱，而是 Prompt 太长、上下文太多、规则太复杂。

1. Prompt 过长会带来什么问题？

Prompt 太长会导致：

• 请求 Token 增加；
• 模型处理时间变长；
• 成本上升；
• 重点信息被稀释；
• 模型更容易偏离任务。

尤其是知识库问答应用，如果每次都塞入大量文档片段，再加上复杂系统提示词，整体 Token 会迅速增加。

2. 优化 Prompt 的原则

好的 Prompt 应该满足：

• 目标明确；
• 规则清晰；
• 结构简单；
• 尽量短；
• 不包含重复要求；
• 不包含无关背景；
• 对输出格式有明确约束。

3. 示例：低效 Prompt

你是一个非常专业、非常优秀、非常聪明、非常有耐心的客服机器人。
你需要根据用户的问题进行回答。
请注意，你一定要认真回答，并且要礼貌、专业、准确。
如果用户问的问题和知识库有关，你需要结合知识库回答。
如果用户问的问题不清楚，你需要询问用户。
如果用户问的问题比较复杂，你需要一步一步思考。
请尽可能详细地回答用户的问题。

这个 Prompt 问题是：重复、空泛、缺乏具体约束。

4. 优化后的 Prompt

你是企业客服助手。请根据知识库内容回答用户问题。

要求：
1. 优先使用知识库信息；
2. 如果知识库没有相关内容，请说明“暂未找到相关信息”；
3. 回答不超过 300 字；
4. 语气专业、简洁、友好。

优化后更短、更清晰，也更利于模型稳定输出。

六、第四步：优化知识库切分策略

如果你使用 Dify 搭建知识库问答系统，知识库性能是必须重点优化的部分。

知识库性能主要涉及两个方面：

1. 检索速度
2. 检索准确率

如果文档切分不合理，可能会出现：

• 检索慢；
• 召回内容太多；
• 召回内容不相关；
• 回答不准确；
• Token 消耗过高。

1. 什么是文本切分？

文本切分就是把一篇长文档拆成多个小片段，然后分别向量化存入向量数据库。

用户提问时，系统会把问题向量化，再到向量库中查找最相似的文本片段。

2. 切分太大有什么问题？

如果单个文本块太大：

• 每次召回内容占用 Token 多；
• 可能包含大量无关信息；
• 模型处理时间增加；
• 回答容易混入错误上下文。

3. 切分太小有什么问题？

如果单个文本块太小：

• 语义不完整；
• 缺少上下文；
• 召回内容碎片化；
• 模型难以理解完整含义。

4. 推荐切分策略

对于零基础用户，可以先使用以下经验值：

同时建议设置适当的重叠长度，例如 50～150 字。重叠的作用是避免上下文断裂，但重叠过多也会增加索引量和检索成本。

5. 实用建议

• 文档标题要保留；
• 小节标题要保留；
• 不要把大量无关内容放在同一个知识库；
• 不同业务主题建议拆分成不同知识库；
• 删除重复文档；
• 删除无意义文本，例如页眉、页脚、目录、版权声明；
• 对表格数据进行结构化处理；
• 对 FAQ 使用“问题 + 答案”的格式。

七、第五步：控制知识库召回数量

知识库应用中，一个常见错误是召回太多片段。

很多用户认为：召回越多，答案越准确。实际上并不是这样。

召回过多会导致：

• Prompt 变长；
• 模型处理变慢；
• Token 成本上升；
• 无关信息干扰模型；
• 回答质量下降。

1. Top-K 是什么？

Top-K 指的是每次从知识库中召回最相关的前 K 个片段。

例如 Top-K = 5，就表示召回最相似的 5 个文本片段。

2. Top-K 怎么设置？

一般建议：

对于大多数应用，Top-K 不建议一开始设置太高。可以从 3 或 5 开始测试。

3. 设置相似度阈值

除了 Top-K，还可以设置相似度阈值。相似度低于阈值的内容不召回。

这样可以避免模型拿到不相关资料后胡乱回答。

建议：

• 如果知识库内容质量高，可以适当提高阈值；
• 如果用户问题表达多样，可以适当降低阈值；
• 如果经常答非所问，尝试提高阈值；
• 如果经常找不到答案，尝试降低阈值。

八、第六步：合理使用 Rerank 重排序

Rerank，即重排序，是知识库检索优化的重要手段。

普通向量检索会根据语义相似度召回文本，但有时召回结果并不精准。Rerank 模型可以对召回结果进行二次排序，把更相关的内容排到前面。

1. Rerank 的优点

• 提高知识库命中率；
• 减少无关片段进入 Prompt；
• 提升回答准确性；
• 对复杂问题更友好。

2. Rerank 的缺点

• 增加一次模型调用；
• 增加延迟；
• 增加成本；
• 并发较高时可能成为瓶颈。

3. 什么时候建议使用 Rerank？

建议使用：

• 知识库内容较多；
• 文档相似度较高；
• 用户问题复杂；
• 召回准确率不稳定；
• 对答案准确率要求高。

不一定需要使用：

• FAQ 数量很少；
• 知识库结构清晰；
• 召回已经很准；
• 应用更关注速度而非极致准确。

4. 性能优化建议

如果启用 Rerank，可以考虑：

• 先向量召回较多片段，例如 Top-K = 10；
• 再通过 Rerank 选出前 3～5 个；
• 最终只把少量高相关片段传给大模型；
• 不要把 Rerank 后所有结果都塞进 Prompt。

这样可以在准确率和性能之间取得平衡。

九、第七步：优化工作流节点

Dify 的工作流功能非常强大，但工作流设计不合理也很容易导致性能问题。

1. 常见低效工作流

以下工作流容易变慢：

• LLM 节点过多；
• 每个节点都调用大模型；
• 节点串行执行过长；
• HTTP 请求节点访问慢接口；
• 代码节点处理大量数据；
• 条件分支设计复杂；
• 中间变量传递大量文本；
• 每一步都进行知识库检索。

2. 优化原则

减少不必要的 LLM 调用

如果一个判断可以用规则完成，就不要调用大模型。

例如判断用户是否输入手机号，可以用正则表达式，而不是让 LLM 判断。

中间节点使用短输出

工作流中间节点不要生成长篇自然语言，可以要求输出结构化内容。

例如：

{
  "intent": "售后咨询",
  "priority": "normal"
}

比输出一大段解释更高效。

能并行就不要串行

如果两个任务之间没有依赖关系，可以考虑并行处理。串行节点越多，总耗时越长。

慎用外部 HTTP 请求

HTTP 节点调用外部接口时，性能取决于外部服务。如果接口慢，整个工作流都会慢。

建议：

• 设置合理超时时间；
• 避免调用不稳定接口；
• 对频繁查询的数据做缓存；
• 只请求必要字段；
• 避免返回超大 JSON。

控制变量大小

不要在节点之间传递过大的全文内容。变量越大，后续 Prompt 越长，模型处理越慢。

十、第八步：优化数据库和 Redis

对于自部署 Dify 的用户，数据库和 Redis 也是性能关键。

1. PostgreSQL 优化建议

PostgreSQL 存储了大量应用数据、日志、会话记录等。如果长期运行，数据量增加后可能影响性能。

建议：

• 使用独立数据库服务，不要和所有服务挤在同一个低配容器中；
• 定期备份数据库；
• 定期清理无用日志；
• 避免无限制保存大量历史会话；
• 给数据库分配足够内存；
• 使用 SSD 磁盘；
• 监控数据库连接数；
• 避免连接数耗尽。

如果你的 Dify 应用访问量较大，建议不要使用极低配置服务器，例如 1 核 1G 或 1 核 2G。这样的配置只能用于测试，不适合正式生产。

2. Redis 优化建议

Redis 常用于缓存和队列。如果 Redis 内存不足或连接异常，可能导致任务变慢或失败。

建议：

• 给 Redis 分配足够内存；
• 避免 Redis 与其他高负载服务抢资源；
• 开启合理的内存淘汰策略；
• 监控 Redis 内存使用率；
• 关注队列是否堆积；
• 生产环境不要随意清空 Redis。

3. 日志清理

Dify 运行过程中会产生日志，包括应用日志、容器日志、会话日志等。

如果日志长期不清理，可能导致：

• 磁盘被占满；
• 数据库变大；
• 查询变慢；
• 服务异常。

建议定期检查：

docker system df

查看 Docker 占用情况。

也可以清理无用镜像、容器和缓存：

docker system prune

但注意：执行清理命令前要确认不会误删重要数据。

十一、第九步：优化向量数据库

知识库应用的性能很大程度依赖向量数据库。

1. 向量数据库常见问题

• 检索慢；
• 索引构建慢；
• 文档导入失败；
• 内存占用高；
• 数据量变大后性能下降；
• 召回结果不稳定。

2. 优化建议

选择合适的向量库

如果只是小规模测试，默认配置通常够用。但如果生产环境中有大量文档，建议选择更成熟、性能更好的向量数据库。

常见选择包括：

• Qdrant；
• Milvus；
• Weaviate；
• Elasticsearch 向量检索；
• pgvector。

不同向量库适合不同规模和部署方式。零基础用户可以先使用 Dify 官方推荐方案，后续根据数据量再迁移。

控制知识库规模

不要把所有资料都塞进一个知识库。可以按照业务、产品、部门、语言拆分。

例如：

• 产品 A 知识库；
• 产品 B 知识库；
• 售后 FAQ 知识库；
• 内部制度知识库；
• 技术文档知识库。

这样既能提高检索速度，也能提升检索准确率。

删除低质量数据

向量库不是垃圾桶。低质量数据越多，检索越容易混乱。

建议删除：

• 重复文档；
• 无关内容；
• 自动抓取的脏数据；
• 乱码文本；
• 目录页；
• 空文本；
• 太短且无语义的片段。

十二、第十步：优化服务器配置

如果你是自部署 Dify，服务器资源直接决定系统上限。

1. 测试环境与生产环境不同

很多教程会说 Dify 可以在较低配置服务器上运行，但那通常是“能跑起来”，不是“跑得流畅”。

如果只是个人测试：

2 核 CPU / 4GB 内存

勉强可以体验。

如果是小团队使用：

4 核 CPU / 8GB 内存

会更合适。

如果是生产环境，并且有知识库、工作流、多用户访问：

8 核 CPU / 16GB 内存或更高

更稳妥。

如果还部署本地大模型，则需要额外考虑 GPU、显存和推理框架性能。

2. 磁盘建议

建议使用 SSD，而不是机械硬盘。

原因：

• 数据库读写更快；
• 向量库索引更快；
• 日志写入更稳定；
• 容器启动更快。

3. 网络建议

如果 Dify 调用的是外部大模型 API，网络延迟非常关键。

建议：

• 选择网络质量好的服务器区域；
• 尽量靠近模型服务商节点；
• 避免跨境网络不稳定；
• 使用稳定的 API 网关；
• 监控 DNS、TLS 握手和请求耗时。

很多时候，Dify 响应慢并不是代码问题，而是服务器到模型 API 的网络延迟太高。

十三、第十一步：使用缓存减少重复计算

缓存是提升性能的重要方法，尤其适合重复问题较多的场景。

1. 哪些内容适合缓存？

适合缓存：

• 高频 FAQ 的答案；
• 外部接口查询结果；
• 固定知识库检索结果；
• 用户意图识别结果；
• 不经常变化的配置数据；
• 常见问题的标准回复。

不适合缓存：

• 用户隐私数据；
• 强实时数据；
• 每次都不同的生成结果；
• 需要严格个性化的内容。

2. 缓存的好处

• 减少模型调用；
• 降低 Token 成本；
• 提高响应速度；
• 降低外部接口压力；
• 提升并发能力。

3. 简单缓存思路

对于常见问题，可以在工作流前面增加判断：

用户问题
  ↓
是否命中常见问题？
  ↓ 是：直接返回标准答案
  ↓ 否：进入知识库检索和大模型生成

这样可以避免每次都走完整 RAG 流程。

十四、第十二步：减少历史上下文长度

聊天应用通常会保留历史对话，以便模型理解上下文。但历史记录越多，Prompt 越长，响应越慢。

1. 历史上下文过长的问题

• Token 成本增加；
• 模型响应变慢；
• 容易引入无关信息；
• 模型可能误解当前问题；
• 长对话后质量下降。

2. 优化方式

建议：

• 限制历史对话轮数；
• 只保留最近几轮对话；
• 对长期对话进行摘要；
• 对不相关历史进行裁剪；
• 对客服场景可只保留用户关键信息。

例如：

只保留最近 3～5 轮对话

对于大多数客服和问答场景已经足够。

如果是复杂任务助手，可以使用“对话摘要”替代完整历史，把多轮对话压缩成短文本。

十五、第十三步：监控性能指标

优化不是凭感觉，而是要看数据。

1. 需要关注的指标

建议至少关注：

2. 如何定位慢点？

可以按以下顺序排查：

总响应慢
  ↓
是否模型慢？
  ↓
是否知识库检索慢？
  ↓
是否工作流节点慢？
  ↓
是否外部接口慢？
  ↓
是否服务器资源不足？
  ↓
是否数据库/Redis/向量库异常？

不要一开始就盲目升级服务器。很多性能问题可能是 Prompt 太长、Top-K 太高、工作流设计不合理造成的。

十六、第十四步：并发优化思路

当用户量增加时，Dify 可能会出现并发压力。

1. 并发瓶颈可能来自哪里？

• 大模型 API 限流；
• Dify API 服务资源不足；
• Worker 数量不足；
• 数据库连接不足；
• Redis 队列堆积；
• 向量库查询慢；
• 外部 HTTP 接口限流；
• 服务器 CPU 或内存不足。

2. 优化建议

升级模型 API 配额

如果模型服务商限制 QPS 或 TPM，即使 Dify 服务器很强，也无法突破模型 API 限制。

需要关注：

• RPM：每分钟请求数；
• TPM：每分钟 Token 数；
• 并发连接数；
• 单请求超时时间。

增加服务副本

生产环境中可以考虑横向扩展 API 和 Worker 服务，让更多实例处理请求。

合理设置超时

不要让一个请求无限等待。对于外部接口、大模型调用、工作流节点，应设置合理超时时间。

限制单用户频率

如果没有访问频率限制，少数用户可能占用大量资源。

可以考虑：

• 用户限流；
• IP 限流；
• 应用级限流；
• 队列机制；
• 超额提示。

十七、第十五步：降低成本也是性能优化的一部分

很多人把性能优化只理解为“变快”，但在 AI 应用里，成本优化同样重要。

1. 成本来自哪里？

主要来自：

• LLM 输入 Token；
• LLM 输出 Token；
• Embedding 调用；
• Rerank 调用；
• 外部工具调用；
• 服务器资源；
• 数据库存储；
• 向量库存储。

2. 降低成本的方法

• 使用更短 Prompt；
• 控制输出长度；
• 减少历史上下文；
• 减少知识库召回片段；
• 对简单任务使用小模型；
• 高频问题走缓存；
• 减少不必要工作流节点；
• 定期清理无效知识库文档；
• 避免重复索引；
• 根据业务场景选择合适模型。

3. 典型优化案例

假设一个知识库问答应用原来每次请求：

• 系统 Prompt：1000 Token；
• 历史对话：2000 Token；
• 知识库召回：5000 Token；
• 用户问题：50 Token；
• 输出：1000 Token。

一次请求可能消耗约 8050 Token。

优化后：

• 系统 Prompt：300 Token；
• 历史对话：500 Token；
• 知识库召回：1500 Token；
• 用户问题：50 Token；
• 输出：500 Token。

一次请求约 2850 Token。

这样不仅速度会更快，成本也可能降低一半以上。

十八、Dify 性能优化实战检查清单

如果你不知道从哪里开始，可以直接按照下面清单逐项检查。

1. 应用配置

• [ ] 是否开启流式输出？
• [ ] 是否限制最大输出 Token？
• [ ] 是否减少无效 Prompt？
• [ ] 是否限制历史对话轮数？
• [ ] 是否使用了合适模型？
• [ ] 是否所有节点都用了过强模型？

2. 知识库配置

• [ ] 文档是否合理切分？
• [ ] 是否删除重复和无效内容？
• [ ] Top-K 是否过高？
• [ ] 相似度阈值是否合理？
• [ ] 是否需要 Rerank？
• [ ] Rerank 后是否只保留少量高相关内容？
• [ ] 是否按业务拆分知识库？

3. 工作流配置

• [ ] 是否存在过多 LLM 节点？
• [ ] 是否可以用规则替代模型？
• [ ] 是否有慢速 HTTP 请求？
• [ ] 是否设置超时时间？
• [ ] 中间节点输出是否过长？
• [ ] 是否有不必要的串行流程？

4. 部署环境

• [ ] CPU 和内存是否足够？
• [ ] 是否使用 SSD？
• [ ] 数据库是否压力过高？
• [ ] Redis 是否内存不足？
• [ ] Worker 是否堆积？
• [ ] 向量库检索是否变慢？
• [ ] Docker 日志是否过大？
• [ ] 磁盘是否快满？

5. 模型服务

• [ ] 模型 API 是否限流？
• [ ] 模型服务是否稳定？
• [ ] 网络延迟是否过高？
• [ ] 是否可切换更快模型？
• [ ] 是否可使用本地或区域更近的模型服务？

十九、推荐的优化顺序

对于零基础用户，不建议一开始就做复杂架构调整。可以按照以下顺序来：

1. 开启流式输出
2. 控制输出长度
3. 缩短 Prompt
4. 减少历史上下文
5. 调整知识库 Top-K
6. 优化文档切分
7. 删除低质量知识库内容
8. 检查模型是否过慢
9. 优化工作流节点
10. 检查服务器资源
11. 监控数据库、Redis、向量库
12. 根据并发情况扩容

这个顺序的好处是：前几步成本最低、见效最快，适合新手优先操作。

二十、总结

Dify 性能优化并不是单纯“升级服务器”或者“换一个模型”就能解决的事情。它涉及应用配置、Prompt 设计、模型选择、知识库结构、工作流设计、数据库、Redis、向量数据库、服务器资源和网络环境等多个方面。

对于零基础用户来说，最重要的是建立一个清晰思路：

先定位问题，再选择优化手段。
先做低成本优化，再考虑架构扩容。
先减少无效消耗，再提升系统上限。

如果你的 Dify 应用回复慢，可以先检查流式输出、模型速度、Prompt 长度和知识库召回数量；如果知识库问答不准，可以重点优化文档切分、Top-K、相似度阈值和 Rerank；如果多人访问时卡顿，则需要关注模型 API 限流、Worker、数据库、Redis、向量库和服务器资源。

一句话总结：

Dify 性能优化的核心，不是让系统“盲目变强”，而是让每一次请求都更短、更准、更少浪费。

只要你按照本文的方法逐步检查和调整，即使是零基础用户，也可以明显提升 Dify 应用的响应速度、稳定性和使用体验。