[Question] 聊天界面LLM输出比直接调用输出慢很多

[ShiShuyang]

What happened? / 实际发生了什么？

在聊天的界面的流式输出情况下，同一个模型每秒输出的token数比直接用python的openai库调用慢很多，目测这个webui输出的速度是直接调用的一半到三分之一。为什么？

Expected behavior / 预期行为

每秒token数和直接openai.OpenAI.chat.completions.create的流式输出速度应该相当。

Steps to reproduce / 复现步骤

直接聊天……

Desktop version / 桌面端版本

v4.23.1

Installation channel / 安装来源

GitHub Release installer

OS / 操作系统

Windows

Architecture / 架构

amd64

Upstream AstrBot ref used by desktop build (optional) / 桌面构建使用的上游 AstrBot Ref（可选）

No response

Logs, screenshots, and additional context / 日志、截图与补充信息

无……

Willing to submit a PR? / 是否愿意提交 PR？

• I am willing to submit a PR to fix this issue. / 我愿意提交 PR 修复此问题。

Code of Conduct

• I agree to follow the project's Code of Conduct. / 我同意遵守项目行为准则。

[zouyonghe]

这个问题更像上游存在的性能bug，需要进一步分析测试

[zouyonghe]

感谢反馈。我们这边顺着链路查了一下，结论先说：

这个现象更像是上游 AstrBot ChatUI 的流式传输/渲染开销，不是 desktop 壳层单独把 token 输出“限速”了。

目前定位到两处比较明显的影响点：

1. 上游 v4.23.1 的聊天页默认走 SSE；
2. SSE 聊天路由在每次把流式结果推给前端后，会额外 await asyncio.sleep(0.05)，也就是每个流式片段固定再等 50ms。

另外，前端这边每收到一个片段，还会把整段消息重新拼接后再走一遍 Markdown 渲染，并触发自动滚动。和直接用 openai Python SDK 在终端打印 chunk 相比，这条链路的“可见输出速度”确实会慢不少，尤其是在 chunk 很碎的时候会更明显。

所以目前看，这个问题的主要原因在 AstrBot 上游聊天链路本身，而不是桌面端多套了一层 Tauri 就变慢了。

后续我们会优先从上游这几个方向看：

• 去掉或降低 SSE 路由里固定的 50ms 延迟
• 评估默认改走 websocket
• 降低流式阶段的 Markdown 实时重渲染开销

如果你方便，也可以帮忙补一个对比结果：

• 同一台机器、同一模型、同一提示词
• 浏览器直接访问本地 WebUI
• Desktop 版
• 直接 Python SDK

如果 源码部署 和 Desktop 一样慢，那就更能说明问题主要在上游聊天链路；如果只有 Desktop 慢，我们再继续往桌面端方向细查。

[Soulter]

切换为 WebSockets 模式再试试

[ShiShuyang]

非常感谢反馈！
确实改成websockets模式后速度正常了，和直接python调用肉眼看不出速度差距。
我也在网页端（localhost:6185）和客户端均进行了测试，得到了一致的结果，即SEE模式下速度明显慢，websocket模式下速度正常。
由于我之前写过SEE模式，自己写的时候速度没有影响，因此之前没有往这个方向去想，也想不到会有一个await asyncio.sleep(0.05)。对于我提的issue，确实可以从去掉或降低 SSE 路由里固定的 50ms 延迟或评估默认改走 websocket两个方向去改。以我个人的经验，markdown渲染不那么耗时。
对于一般用户而言，可能没有“标准输出速度”的经验，可能也感觉到慢但是不确定是不是外部模型慢，更不懂什么SEE和socket。如果有机会改进就好了。（不过这个issue是不是提到AstrBot而不是desktop下会更好呢(=･ω･=)）
再次感谢回复，也感谢Astrbot和astrbot-desktop的工作！（题外话，几年元旦刚去了下北泽巡礼来着的。）