Open WebUI 社群回報 Redis 串流寫入放大，長回覆反覆儲存累積全文

Open WebUI 於 10 月 15 日出現一份針對 Redis 串流路徑的效能回報。作者 Classic298 指出，用來支援頁面重新整理後接續顯示的即時副本，會在每個 token 到達時重寫累積回覆；另一條供即時觀看使用的廣播路徑，也會反覆傳送完整內容。這使長回覆的成本隨內容長度與持續時間增加。GitHub 回報

作者以目前開發分支、單一實例、Redis 與穩定輸出的模擬模型測量：一則耗時 241 秒、大小 387 KB 的回覆，累計向 Redis 寫入 23.6 GB，另產生 307 MB 廣播資料。這些是特定測試條件下的累計傳輸量，不能解讀為 Redis 同時占用的記憶體，也不能直接套用至所有模型與部署。測量與重現步驟

這條路徑對擴充部署尤其重要。官方擴充指南要求多實例共用 Redis，以協調 WebSocket 與應用狀態；因此，增加應用副本時，也須評估共享通訊服務的負載。從工程角度推論，若更新持續攜帶累積全文，模型輸出更快或代理執行更久，都可能提高序列化與網路成本，單看推論 tokens/s 無法掌握整體瓶頸。擴充指南

部署者目前可先觀察 Redis 輸入流量、慢查詢與 Pub/Sub 用戶端斷線計數，並以長回覆及多輪工具任務重現。官方環境設定文件已提醒，大型串流事件可能造成訂閱端緩衝區超限；提高上限能容忍暫時較慢的接收端，也會容許更多記憶體占用。依此機制判斷，調大緩衝區無法消除重複傳送全文的成本。後續應追蹤更新是否改傳增量、是否降低快照頻率，以及修補後重新整理與多人觀看能否維持一致；截至查核時，尚未確認正式修補版本。環境設定文件