Dify 价格 vs API 按量计费：怎么算更省？（2026）

搜“Dify 价格”，得到的答案经常在比较两个不同层面的东西：有人问 Dify Cloud 一个月多少钱，有人问调用一次模型花多少钱，还有人把自托管的服务器账单当成了全部成本。这三笔钱要分开算，否则很容易得出“云贵”或“自托管免费”的错误结论。

Dify 本身是编排层：它负责提示词、知识库、工作流和 Agent 的组织，不生产模型。无论用 Cloud 还是自托管，模型调用费都单独存在。下面把平台费、模型费和运维费拆开，再给一个可以套用的估算顺序。价格与配额会调整，本文不写死数字，以官方页面和站内模型价格为准。

说明：Dify 为其权利人 LangGenius, Inc. 的商标；本文为独立技术说明，与 Dify 团队无隶属或代理关系。文中提到的其他产品名称归各自权利人所有。

一、先把账单拆成四层

成本层	Dify Cloud	自托管	容易漏算的地方
平台层	订阅，含成员数、功能与配额	社区版无订阅费，但受许可证条件约束	订阅按月或按年，许可证要看商用场景
模型层	内置 AI credits，或自己的供应商 Key	自己的供应商 Key 或统一网关	按 Token、图片或次数计费
基础设施层	包含在订阅内	服务器、数据库、向量库、对象存储、带宽	按云资源账单逐项出现
运维层	平台承担	升级、备份、监控、安全、值班	人力成本最容易被当成零

Cloud 把基础设施和运维打包进订阅，自托管把这两层还给你。比较时要把四层放进同一个口径：要么都算三年总成本，要么都算单月现金支出。只拿订阅价对比服务器价，结论没有意义。

二、Dify Cloud：订阅买的是配额与省心

Cloud 的订阅按工作区计费，决定团队人数上限、功能可用范围和用量配额。按 2026 年 10 月的文档，计划分为 Sandbox、Professional、Team 三档；Sandbox 是免费档，含一次性 AI credits，用完后不按月补充；Professional 与 Team 的成员上限和配额更高。具体数字与价格以 Dify 官方定价页为准。

Cloud 还有两类容易和订阅费混淆的额度：

AI credits：用于平台内置模型。用完后可以换用自己的供应商 Key，费用转到你的模型账户。
知识库存储：按向量占用量计算，不是原文件大小。三档计划的额度依次提高，只有高质量索引会占用存储，经济索引走关键词、不占向量额度。

存储按向量算，意味着同一份文档的占用取决于切块大小、父子分段和 Embedding 维度。父块下的每个子块都是一个向量；高维模型的单块占用可能是低维模型的两倍。文档没变，改一次切块规则也可能让占用上升。配额打满后，新增文档、编辑分块和重建索引都会被阻止，已有知识库仍可被应用检索，但要先删减或升级才能继续写入。

因此 Cloud 适合不想管服务器、团队规模不大、希望把成本固定下来的场景。它的风险不是单价，而是配额：知识库增长、成员增加或 credits 用完，都可能触发升级。

三、自托管：没有订阅费，不等于便宜

社区版可以自托管，软件订阅费为零，但许可证不是无条件的 Apache 2.0。它基于 Apache 2.0 并附加条件：未经书面许可，不能用它运行多租户 SaaS；使用其前端时不能移除或修改 logo 与版权信息；一般商业使用是允许的。如果你打算把 Dify 包装成对外售卖的 SaaS，先做许可证评估，不要只看“开源”两个字。

一次完整的自托管至少包含这些组件：api、worker、web、plugin_daemon、PostgreSQL、Redis、向量数据库、nginx、沙箱服务等。官方给出的最低配置是 2 核 CPU、4 GiB 内存，这只够试用；生产环境要按并发、文档量和索引规模重新选型。

成本项包括：

计算：应用服务、插件服务、沙箱。
数据库：PostgreSQL 的存储、备份与高可用。
向量库：内存和磁盘通常是大头，数据量上来后扩容不便宜。
对象存储与备份：文件、日志、快照。
网络与证书：带宽、负载均衡、HTTPS。
运维人力：版本升级、插件兼容、漏洞修补、监控告警、故障值班。
环境副本：测试、预发、生产各一套。

最后两项最容易被漏掉。自托管的“省”是用人力换来的；如果团队没有明确的运维负责人，省下的订阅费很可能以故障时间和加班的形式还回去。

四、模型调用：真正随用量增长的部分

模型调用是唯一真正随业务量线性增长的部分。Dify 里每一次 LLM 节点执行、Agent 的每一步工具调用、每一次 Rerank 和 Embedding，都会在上游产生费用。

三个放大点：

多步编排：Agent 和工作流会把系统提示词、历史消息和检索片段反复带入后续步骤，步数越多，输入 Token 越陡。
长上下文：把整篇文档或大量召回片段直接塞进提示词，单次成本可能比模型单价的影响更大。
重试与失败：超时、429、5xx 都可能触发重试；是否重复计费取决于上游，预算按最坏情况留余量更稳妥。

控制方法并不复杂：分类、改写、抽取用小模型，最终生成用强模型；限制召回条数和单段长度；给输出设上限；对相同请求做去重。流式输出改善的是等待体验，不会减少输出 Token 的计费。

五、RAG 与知识库：一次性成本加持续成本

知识库的成本分两段：建库和查询。

建库阶段，Embedding 按输入 Token 计费。切块重叠、页眉页脚、重复模板都会被计费；换模型、改维度、改切块规则通常要全量重嵌入，这是一次性但可能很大的支出。查询阶段，每次提问至少涉及查询向量化、向量检索，可能还有 Rerank 和生成模型的长输入。

降本顺序应该是：先清洗文本，再按语义切块并把重叠控制在够用范围，然后做增量索引，最后才考虑换更便宜的 Embedding 模型。顺序反了，常见结果是模型便宜了一点，但脏文本和重复索引没变，账单几乎不动，召回还变差。

另外，经济索引不占向量存储，但检索方式不同，效果要用自己的问题集验证；不要为了省存储直接切换，尤其是客服、合同、法规这类对召回精度敏感的场景。

六、工作流、缓存与预算上限

不要按“运行次数”做预算。两次工作流运行的模型调用量可能差几十倍：一次只走分类和模板回复，另一次可能触发多轮检索、Rerank 和长文生成。估算单位应该是“每次运行的平均 Token”和“每月运行次数”的乘积。

缓存能省的钱通常比换模型更直接：

完全相同的问题复用答案，设置合理的过期时间。
高频查询的检索结果缓存，文档更新时按知识库失效。
相同文本的 Embedding 结果缓存，避免重复向量化。
对时效性强、个性化或含敏感信息的回答不要缓存。

预算上限要放在三个位置：Dify Cloud 的配额与账单提醒、模型供应商侧的用量限额（如果提供）、以及网关侧的按 Key 用量统计与告警。给每个应用或环境分配独立 Key，账单才能归因到具体业务；否则月底只能看到一个大数字。阈值可以设在 50%、80%、90%，到达后先降级非关键工作流，再考虑切换模型。

七、一个可复用的估算框架

按下面的顺序估，比拍脑袋可靠。

列出所有应用与工作流，标出哪些会调用模型、哪些只做检索。
从日志里取最近两周的真实 Token 用量，算每次运行的平均输入与输出。
估算每月运行次数，区分工作日高峰与低谷。
单独列建库与重嵌入计划，不要混进月度推理成本。
填入基础设施账单：服务器、数据库、向量库、存储、带宽。
加上运维人力与至少两成的缓冲，再用第一个月真实账单校正。

# 估算框架：单价留空，从价格页和云账单填入，数字仅作结构示例
runs_per_month = 30_000
input_tokens_per_run = 3_000
output_tokens_per_run = 500
embed_tokens_per_index = 20_000_000
reindex_times_per_month = 1

input_price_per_1k = 0.0   # 填入每千输入 Token 单价
output_price_per_1k = 0.0  # 填入每千输出 Token 单价
embed_price_per_1k = 0.0   # 填入 Embedding 每千 Token 单价

model_cost = (
    runs_per_month * input_tokens_per_run / 1000 * input_price_per_1k
    + runs_per_month * output_tokens_per_run / 1000 * output_price_per_1k
)
embed_cost = embed_tokens_per_index * reindex_times_per_month / 1000 * embed_price_per_1k
print(model_cost + embed_cost)

这个框架只算模型与 Embedding，基础设施和人力另加。单价不要抄宣传页上的示例，直接从站内模型价格和你自己的云账单取数。

八、三种典型场景怎么选

小团队快速验证：Cloud 起步，先用 Sandbox 或低档订阅验证需求，Key 用自己的供应商账户，重点关注 credits 和知识库配额。等调用量稳定后再比较自托管。
数据合规、稳定高用量：自托管加统一网关。把模型调用集中到网关，按应用发 Key，成本可归因；预算里必须包含运维人力。
混合部署：开发测试用 Cloud，生产用自托管或网关；或者平台用 Cloud、模型走自己的网关。关键是日志和账单口径统一。

没有一种方案在所有场景都更省。Cloud 省的是运维和启动时间，自托管省的是可控性和规模化后的边际成本；模型费用两者都躲不掉。

常见问题

Dify 本身收模型调用费吗？

Dify 是编排平台，模型调用由供应商计费。Cloud 可能提供内置模型 credits，超出后用自己的 Key 或按平台规则处理；自托管则完全走你自己的模型账户。以账单页面为准。

自托管 Dify 是不是完全免费？

社区版没有订阅费，但软件受附加条件的许可证约束，服务器、数据库、向量库、带宽、备份和运维人力都要自己承担。把人力算进去后，小规模场景未必比 Cloud 便宜。

Dify Cloud 的订阅费能抵扣模型 API 费用吗？

通常不能直接抵扣。订阅覆盖平台功能与配额，模型费用由供应商账户结算；内置 credits 的适用范围也有限。采购前分别确认两张账单。

知识库存储为什么比原文件大很多？

因为按向量数量计费，不按文件大小。切块越细、父子分段越多、Embedding 维度越高，占用越大；经济索引不占向量存储，但检索效果不同。

预算有限，先砍哪一项？

先砍无效上下文和重复调用：压缩提示词、限制召回条数、给输出设上限、做去重和缓存；然后才是换小模型或调整订阅档位。直接降模型质量通常最伤体验。

下一步

算清四层账单后，选择就清楚了：先用真实日志估出每月 Token，再比较 Cloud 订阅、自托管运维和网关按量计费的总和。需要统一入口和按量计费，可以先注册中商起航 AI 网关，模型范围与当前价格以模型价格为准。