![[Model provider]Can't remove model](https://www.chat-gpts.plus/wp-content/uploads/2026/07/38388-fd7a407f.jpg)
[Model provider]Can’t remove model
快速结论:该问题出现在 Dify 自托管环境下,删除模型后模型仍然在列表中显示。优先排查是否已合并 PR #38348 的修复,或手动清理数据库中残留的 ProviderModelCredential 记录。
问题场景
用户在 Dify 自托管(Source 方式部署)的 main 分支版本中,通过管理界面尝试删除一个模型(例如 Xinference 提供的 rerank 模型),但刷新后模型依然出现在列表中。Issue 中附有三张截图显示删除操作未见报错但模型未移除。
报错原文
# 虽然前端无明显报错,但后端日志显示 DELETE 请求返回 204,模型仍存在。
2026-07-03 16:55:18,993 INFO [_client.py:1025] HTTP Request: POST http://192.168.0.188:5002/plugin/.../fetch/batch "HTTP/1.1 200 OK"
# 关键行为:删除后模型列表仍可通过 credentials 重建
原因分析
该问题已由社区确认为 Bug,并在 PR #38348 中修复。根本原因在于:删除流程只移除了 ProviderModel 记录,但没有同步删除关联的 ProviderModelCredential 记录。由于模型列表可以从残留的凭证记录中重建,导致删除的模型“复活”。
环境排查
- Dify 版本:
main(需检查是否包含 PR #38348 的提交) - 部署方式:Self Hosted (Source)
- 数据库类型:本问题涉及 PostgreSQL(或 Dify 默认使用的 DB,需确认)
- 受影响模型提供方:Xinference(但理论上其他 provider 也可能触发)
解决步骤
- 推荐方案(更新代码):拉取
main分支最新代码,确保合并了 PR #38348。该 PR 增加了后备凭据查找机制,并修复了前端在删除请求时正确传递model和model_type字段。 - 临时手动修复(如果你无法立即更新):登录数据库,手动清理孤儿凭证记录(可优先尝试):
# 第一步:查找受影响 provider 的残留凭证 SELECT * FROM provider_model_credentials WHERE provider_name LIKE '%xinference%'; # 第二步:删除对应的凭证记录(替换为实际 id) DELETE FROM provider_model_credentials WHERE id = '<the_credential_id>';注意:谨慎操作,建议先备份相关数据。
- 验证修复:执行上述操作后重启 Dify 服务,再次尝试删除模型。
验证方法
在 Dify 管理界面中执行删除模型操作后,刷新页面确认模型不再显示。同时可通过数据库查询确认对应的 ProviderModel 和 ProviderModelCredential 记录均已被删除。
参考来源
langgenius/dify #38388 — 包含完整讨论及修复引用
langgenius/dify PR #38348 — 该问题的修复补丁



