Open WebUI 接 LM Studio 做流式输出时，卡顿通常不是网络问题，而是模型服务的计算节奏问题：首字延迟过长，或者生成中途出现周期性停滞。前者多与会话上下文太长有关，后者多与并发请求同时抢占本地算力有关。下文给出调整并发数和会话窗口的基本顺序，以及如何判断调整是否有效。
整体判断：流式输出卡顿先查两处——LM Studio 侧是否同时接收多个推理请求，Open WebUI 发往后端的上下文是否超过当前硬件轻松处理的范围。建议先把并发数调到 1，并将历史消息/上下文长度降到 4096 或更保守的水平，再逐项观察首字延迟和生成期间是否还有停顿。这两项都存在硬件边界，调整后需要结合本机显存和 CPU 负载确认。
先区分慢在“开头”还是“中间”
新建一个空会话，只发一句短问题。如果短会话也卡，问题大概率出在 LM Studio 的模型加载、服务端口或本机资源占用上，和会话窗口关系不大。如果短会话正常，回到原来的长对话框，把历史消息清短后再试一次，会明显感到首字更快，说明上下文预填充是主要瓶颈。如果同时在多个浏览器标签页或客户端发起请求，而流式输出变成一顿一顿的，就要把并发数放在第一位去查。
这里不用急着两边一起改。先选择一个变量改动，观察 10 到 20 条消息，再动另一项，否则很难判断哪一步起效。
| 现象 | 优先调整 | 观察点 |
|---|---|---|
| 第一次打开长对话，首字要等很久 | 会话窗口 / 上下文长度 | 请求发出到第一个字出现的耗时 |
| 短对话正常，多个对话同时打开后卡顿 | 并发数 | LM Studio 的进程占用和输出间隔 |
| 一句话的前半段正常，后半段越来越慢 | 并发数 + 上下文长度 | 是否还有周期性停顿 |
并发数：先让模型每次只服务一个请求
LM Studio 作为本地服务端，默认并发能力并不适合多人或密集调用。Open WebUI 自身也可能在前端保持连接，甚至因浏览器预取行为产生多余请求。优先在 LM Studio 服务设置里寻找并发请求或类似选项；如果可调，先设为 1，然后重新加载模型。没有该选项时，就保证同一时间段只有一个客户端实际发送请求，浏览器里不用打开的对话页尽量关闭。
并发数降到 1 的代价是吞吐量下降：多窗口同时使用体验必然变差。如果本机是独立显卡且显存有富余，适合把并发定在 2 左右；如果是核显或轻薄本，1 更稳。总之先降低到能稳定跑完一次完整流式输出，再考虑放大。
会话窗口：控制每次请求要处理的 token 总量
Open WebUI 在每次调用 LM Studio 时都会携带当前会话的上下文。上下文越长，模型生成首个 token 之前的预填充计算就越重。可以在 Open WebUI 的模型参数或对话设置里找到上下文长度、历史消息数一类的项目，把它们调节到模型上下文上限以内，但不要顶着上限跑。例如模型支持 8192，先设成 4096；同时把平时不用的系统提示词精简，避免每轮请求都带着大段固定文字。
这也会带来副作用：模型不再记得较早的对话内容，多轮任务的连贯性会下降。所以只建议在流式卡顿出现时调低，不要过度压缩到模型连最近几轮都记不住。
按这个顺序验证
- 调整 LM Studio 并发数后重启服务，单独开一个 Open WebUI 页面发一句长一点的问题，观察流式输出是否完整。
- 将 Open WebUI 的上下文/历史限制改小后，重新开启一个新会话，不要沿用旧会话。
- 对比调整前后的首字等待时间：只靠人工体感即可，不需要抓包或统计工具。
- 观察一轮输出的后半段是否还有停顿；若仍停顿，把并发数继续往下调，或检查模型是否在 CPU/GPU 之间来回切换。
- 恢复到原来的会话后如果又卡，就能确认瓶颈在会话长度；如果回到 1 个并发还卡，要检查 LM Studio 的加载设置和硬件状况。
这两个参数的调整方向不是越极端越好。并发数和上下文长度的最优值取决于你的显卡、内存和模型大小；如果改动后首字变快但多轮对话明显失忆，就说明窗口被压得太多，需要放回一个中间值。关键是把每项调整串成可对比的测试流程，而不是一次改完多个变量。