GitHub Repo
Open WebUI 社群回報記憶重建繞過併發限制，嵌入端點可能遭遇突發請求
10 月 11 日的 Open WebUI 社群回報指出，記憶向量重建可能忽略嵌入請求的併發上限，並附上大量 429 回應紀錄。隔日另一位參與者補上函式層級重現，但尚無正式修補或完整部署驗證。
Open WebUI 的記憶向量重建流程出現併發控制缺口。10 月 11 日提交的回報涵蓋 v0.12.0、Docker 與 Ubuntu Server 24.04：使用者將嵌入併發上限設為 2，執行「Reindex Knowledge and Memory Vectors」後，記憶資料仍產生密集請求；附上的推論端點紀錄顯示，多筆請求在同一秒收到 HTTP 429。回報稱知識文件會遵守限制，記憶重建則沒有。社群回報
官方文件將 RAG_EMBEDDING_CONCURRENT_REQUESTS 定義為非同步嵌入 API 的同時請求上限，正整數應透過 semaphore 節流，0 才代表不限併發。它與每次請求包含多少文字的批次大小設定不同；因此，管理員即使限制單批資料量，仍需另外確認實際同時發出的請求數。設定文件
10 月 12 日，另一位參與者在開發分支提交函式層級重現：以一位使用者的 10 筆記憶、OpenAI 嵌入路徑及批次大小 1 測試，上限設為 1 或 2 時，記憶重建的峰值併發仍為 10；將相同文字整批傳入包裝函式，則分別維持在 1 與 2。其分析指向記憶流程透過 asyncio.gather 傳入個別字串，而包裝函式只對列表輸入套用限流。這仍是參與者的原因分析，尚待維護者確認。重現與分析
技術上，這意味著限流是否生效可能取決於呼叫方式。對共用嵌入服務的部署而言，重建作業可能形成突發負載；不過，目前不能據此推定所有後端皆受影響，也沒有證據證明既有向量已損毀。補充測試使用模擬端點與資料庫替身，並非完整 Docker 或介面測試。測試限制
截至查核，修正方向是讓記憶文字使用既有列表／批次路徑，議題尚未連結修補 PR。工程團隊應觀察重建時的實際併發與 429 比例；後續驗證則需涵蓋向量順序、內容前綴、使用者脈絡，以及受限與不限併發兩種設定。修正提議