
issue: Side-by-side chat with identical model IDs may cause message_ids collision
快速结论:在 Open WebUI 的并排聊天(side-by-side)功能中,如果左右两个面板选择了完全相同的模型(model ID),可能会导致消息 ID 冲突,表现为只有一个面板正常输出响应,另一个面板一直“等待响应”,刷新页面后两个面板显示相同内容。优先排查是否使用了重复的 model ID。
问题场景
用户在 Open WebUI v0.9.6(Docker 部署,CUDA 版本)中,使用并排聊天功能时,在左右两个聊天面板中选择同一个本地 Ollama 模型(例如 gemma3:270m),然后发送对话请求。只有其中一个面板会正常接收流式响应,另一个面板卡在“waiting for response”状态,停止按钮也失效。刷新页面后,两个面板显示完全相同的响应内容(即成功生成的那一个)。
报错原文
Frontend does not show explicit error in browser console.
Docker logs do not show explicit error.
This is a logical state management issue, not an error thrown by the backend.
Payload evidence: message_ids may collide because the model ID is used as the key. When the exact same model ID is specified for both panes, a key collision occurs, causing the latter message ID to overwrite the former.
原因分析
这是 Open WebUI 前端状态管理机制的逻辑缺陷。当并排聊天的两个面板使用相同的模型 ID 时,系统可能用 model ID 作为消息 ID(message_ids)的键值,导致后一个面板的请求覆盖前一个面板的消息 ID,前端从而丢失对其中一个消息流的追踪。因此表现为一个面板正常响应,另一个一直等待,且刷新后两者的响应内容相同(被覆盖为成功的那一个)。
注意:如果使用两个不同的模型 ID,或者只调用单个模型,则不会出现此问题。
环境排查
- Open WebUI 版本:v0.9.6(以及早期版本都可能存在此问题)
- 安装方式:Docker(
ghcr.io/open-webui/open-webui:cuda) - 操作系统:Fedora Linux 43 (Workstation Edition) x86_64
- 后端模型提供:Ollama(本地模型)
- 注意:本问题与浏览器、Ollama 版本无关,是前端状态管理问题
解决步骤
- 确认问题:在并排聊天中,确保左右两个面板选择了完全相同的 model ID(例如
gemma3:270m和gemma3:270m),并发送消息。 - 如果你遇到此问题(面板卡住、停止按钮失效),无需重启服务,可以直接刷新页面,刷新后两个面板会显示相同的成功响应内容。
- 可优先尝试:升级到 Open WebUI 的最新开发版(dev branch)或包含 PR #25987 修复的版本。Issue 评论中已经确认此问题在 dev 分支上已修复,并且测试通过(问题无法复现)。
- 临时规避:在并排聊天中使用不同的模型 ID(例如一个用
gemma3:270m,另一个用gemma3:4b或其他模型),可以绕过此问题。 - 如果无法升级或无法更换模型,可以暂时避免使用并排聊天功能,每次只与一个模型对话。
验证方法
在最新的开发版(dev)上按照复现步骤操作:打开并排聊天,左右均选择同一个模型(如 gemma3:270m),发送消息,观察两个面板是否能独立、正常地接收并显示流式响应。如果两个面板都能正常工作,不再出现卡死或内容覆盖现象,则问题已解决。
参考来源
open-webui/open-webui #25982
修复 PR:open-webui/open-webui #25987



