Dify 该买哪一档：先数共建成员，再算模型账单

团队第一次购买 Dify，容易先比较模型数量，真正决定套餐的却往往是：谁需要进入工作区维护应用，以及一次业务请求会调用几次模型。若只是一个人验证内部问答流程，先用 Sandbox；若四名同事都要共同维护，不应把三人版 Professional 当成长久方案。

以下判断依据 2026 年 11 月 3 日查阅的官方价格页与文档，不是负载测试，也不保证某档套餐能支撑你的实际并发。

官方价格页列出的工作区成员配额分别为：Sandbox 一人、Professional 三人、Team 五十人。它们不应直接被理解为应用每天只能服务这么多访客。采购时先写下需要登录工作区、修改流程或维护知识资料的人，再单独验证应用交付方式的访问要求。

例如，业务负责人、流程维护者和知识库维护者恰好是三人，可以把 Professional 纳入候选；若还需要第四人长期参与工作区维护，就应评估 Team，而不是让多人共用一个管理账号。若只是老板偶尔查看输出，先确认交付方式，不要仅因多了一位读者就升级。

当前月付标价为 Professional 每工作区 59 美元、Team 每工作区 159 美元，均未含适用税费。两档月付差额为 100 美元。这个差额值不值，首先看新增协作者是否确实需要工作区席位，而不是把成员数当作性能指标。

Dify 的信用点按模型响应扣除，一次响应指一次模型调用，不等同于业务人员提交的一次完整请求。较复杂的流程可能先分类、再检索后生成、最后检查格式：如果三个步骤各调用一次模型，一个请求就包含三次调用。这里是用于核算的示例，不代表每条 Dify 流程都固定调用三次。

自有模型 API key 的费用记到对应供应商账户。因而预算至少分两栏：Dify 的工作区订阅，以及自有 key 产生的模型开支。供应商的速率限制也需要另行核对；升级 Dify 套餐，不能据此认定所有模型调用都无限量。

选一个低风险流程，例如依据已经获准使用的产品说明生成客服答复草稿。准备二十个有标准答案的问题，其中包含资料缺失、措辞模糊和超出范围的问题。这个数量是试运行建议，不是官方测试标准。

让同一套流程逐条运行，记录答案能否被采用、每条触发多少次模型调用、是否需要人工修订，以及失败发生在哪一步。试运行的目标不是得到一个漂亮的平均值，而是分清两类问题：如果经常引用错误资料，应先修知识库和检索逻辑；如果答案已可用，却因协作人数或资源配额受阻，再评估付费升级。升级套餐不能代替内容质量修复。

官方 Docker Compose 文档给出的最低硬件为两核 CPU、4 GiB 内存。这只是最低部署要求，不能当成生产容量承诺。文档还要求升级时对照新增或变化的环境变量，说明自部署并非安装完就不再维护。

如果团队不能明确由谁负责升级、备份验证和故障处理，先买云端服务通常更容易估算责任和投入。若有运维能力，再按实际数据流和控制要求评估自部署；还需核对所选模型与外部服务的数据去向，不能仅凭应用部署在自家服务器，就推断所有数据都留在内部。

对刚起步的团队，最稳妥的购买顺序是：用小样本证明流程有用，确认实际共建人数，再将平台订阅与模型账单分别纳入预算。只有当明确的配额挡住了已经可用的工作流，升级才是在购买可辨认的收益。