OpenWebUI的响应速度竟然与任务模型有关

[xiniah]

任务模型是指openwebui中进行标题标签生成的模型。在设置的界面中的外部模型中设置
话说今天突然遇到 OpenWebUI 输出需要 10s + 以上，

去看 newapi 后台首字也才零点几秒，也没有出现渠道重试。然后又去渠道提供商那里看，也是首字时间很低。

接下来就是漫漫的 DEBUG 之旅…

1. 网络

首先看浏览器的开发者工具发现 **/completions** 的请求等待时间极长

然后用 curl 测试了以下几个内容

本地 -> 服务器  0.5s
服务器 -> 供应商 0.5s
本地 - > 供应商 0.5s

都没出现问题… 说明不是网络出现的问题

2. 日志

通过 1panel 的容器日志查看，我观察了生成对话时日志的反应，发现在发送对话请求后，日志会在这里卡一会（下图的红色箭头）

难道是获取模型时比较慢？
我又在 newapi 中将它对应 key 的模型限制为只有 4ol 与 4o-mini
速度也是没变…
又用 curl 测试了 /models 的速度，照样正常…(就不贴图了)

3. 搜索

在翻遍了论坛，GitHub 的 issues 以及各种搜索引擎后，都没有关于此的明显的答案

决心还是要靠自己解决。

4. 于回顾中发现

在回看这段折腾过程中，newapi 的日志又引起了我的注意

任务模型调用 gpt-4o-mini 在正常情况下是会被忽视的，但这一次，他的响应时间却引起了我的兴趣
由于渠道的问题，他竟然有足足的 10s，这与 ow 的响应时间是巧合吗？

我在 newapi 中重新调整了 gpt-4o-mini 模型所对应的第一响应渠道，将其重新调回正常的 1s 水平。

** 再次测试 OpenWebUI 时，就已经回归正常 **

5. 反思

可见，OpenWebUI 的响应速度与任务模型也有关 (在界面的设置中，我设置的是 gpt-4o-mini)

由于之前使用过 lobechat 等其他的 webui，也就自然的以为这些关于生成标题与标签的任务是异步的请求

建议佬友们在使用 openwebui 的时候保证外部模型的稳定性，追求速度可以换成更快速的模型.

果然还是应了那句话

时间就是金钱，稳定压倒一切

如果稳定的话，也没了这次折腾了… 是吧

解决方案：

@fl0w1nd

前往管理员设置->界面设置部分，将其中的“启用检索查询生成”给关掉就可以

[nob]

openwebui怎么看响应时间跟token？哪里设置？

[xiniah]

用的是这个函数

Chat Metrics Function | Open WebUI Community

[nob]

感谢佬友。。

[ageg]

oi的定义，内部模型是指本地跑的模型，调openai api的是外部模型。chatgpt-4o-latest 是外部模型。你说chatgpt的速度和外部模型有关，我看不太懂了。看了三遍才看懂原来外部模型指的是4omini。你直接说生成标题的模型就好了，或者叫任务模型
0.4 的 oi 改了代码，导致每次回复前会调用 get_all_models，并且cache ttl 设置得太短
已经有人提修复了

Time to first response degraded by 2 -4 seconds since 0.4, SOLUTION

[xiniah]

好的，我改一下标题。原谅我不怎么理解外部模型与内部模型的区别。感谢佬的回答

[handsome (大帅哥)]

原来还有这种说法，我以为openwebui本身卡

[The.one (看到我请叫我去学习)]

mini 响应慢的很可能是逆向，或者中转了n次的供应商

[xiniah]

我用的是中转，现在我把gpt-4o-mini切到正价渠道了，稳多了…

[ggsmida]

az的api很快很稳

[obrook]

4.0版本后之后就每次回复就迟钝几秒，没有3.5顺畅

除了issue，Discussions中搜response，也有人提出了这个问题，也是改ttl

默认是1，我改成10，也并没有改善。改成1800没试过

[ageg]

我改成1800了，也不行，还是等官方修复吧。这个bug真蛋疼

[obrook]

对，GitHub有个open webui 的maintainer 回复了那个问题。感觉官方也是知道和承认这个问题的，只是还没找到原因

[obrook]

我还发现了个环境变量的问题，之前我用0.35没有这个问题。也可能是我网络配置的问题，我是部署在本地

Open WebUI 为啥verify_connection不加 trust_env=True

https://github.com/open-webui/open-webui/blob/main/backend/open_webui/apps/openai/main.py v0.42最新中的代码： 可以对比这个三个函数： 1 async def aiohttp_get(url, key=None): …

[fl0w1nd]

似乎已经在v0.4.4修复，不用关了

终于有人问到这个问题了，我来解答吧

前往管理员设置->界面设置部分，将其中的“启用检索查询生成”给关掉就可以

原因：这是新版本（0.4.0开始）增加的一个新的任务模型的任务，它会在每次聊天请求之前先执行这个任务，等这个任务完成了之后才开始发送你的聊天请求。
如果你的任务模型速度慢，通常会导致每次聊天都要等3-5秒，这还算好的了，如果任务模型出错了，直接就卡半天。

个人认为这就是潜在的BUG，在聊天请求之前预先执行任务模型本就不可靠，会严重影响体验，建议大家关了。

另外，这个功能具体干什么的我也不太清楚，但是我给下大家oui源码里的这个任务模型功能提示词，有大佬知道的可以说说：

### Task:
Based on the chat history, determine whether a search is necessary, and if so, generate a 1-3 broad search queries to retrieve comprehensive and updated information. If no search is required, return an empty list.
### Guidelines:
- Respond exclusively with a JSON object.
- If a search query is needed, return an object like: { "queries": ["query1", "query2"] } where each query is distinct and concise.
- If no search query is necessary, output should be: { "queries": [] }
- Default to suggesting a search query to ensure accurate and updated information, unless it is definitively clear no search is required.
- Be concise, focusing strictly on composing search queries with no additional commentary or text.
- When in doubt, prefer to suggest a search for comprehensiveness.
- Today's date is: {{CURRENT_DATE}}
### Output:
JSON format: {
  "queries": ["query1", "query2"]
}
### Chat History:
<chat_history>
{{MESSAGES:END:6}}
</chat_history>

[tutrabbit]

感谢，现在快多了，我还以为是我服务器网速不行

[bbb]

之前的版本也会有这个问题吗？还是说0.4新出现的问题？

[Vincent.liu]

感谢，一会去设置看看，之前也是觉得更新完毕后慢了一些

[ageg]

可以的。果然正常了
我去看了以下oi的源码，就是按照最近几条聊天记录，用任务模型生成query，拿这个query去做rag。如果关闭这个选项，会用最后一条消息当query做rag

[Kerrry (Kerry)]

快多了，但感觉还是没3.5快