Open WebUIコミュニティ、メモリー再構築が同時実行数の制限を回避し、埋め込みエンドポイントに突発的なリクエストが発生する可能性を報告

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は同時実行数を制限しないことを意味します。この設定は、1回のリクエストに含めるテキスト量を決めるバッチサイズ設定とは異なります。そのため、管理者が1バッチあたりのデータ量を制限していても、実際に同時送信されるリクエスト数を別途確認する必要があります。設定ドキュメント

10月12日、別の参加者が開発ブランチで関数レベルの再現テストを行いました。1ユーザー分の10件のメモリー、OpenAIの埋め込み経路、バッチサイズ1でテストしたところ、上限を1または2に設定しても、メモリー再構築時のピーク同時実行数は10でした。同じテキストをまとめてラッパー関数に渡した場合は、それぞれ1と2に保たれました。参加者の分析では、メモリーフローがasyncio.gatherを通じて個別の文字列を渡す一方、ラッパー関数はリスト入力に対してのみレート制限を適用していることが原因とされています。ただし、これは参加者による原因分析であり、メンテナーの確認はまだ取れていません。再現と分析

技術的には、レート制限が機能するかどうかは呼び出し方に左右される可能性があります。埋め込みサービスを共有するデプロイ環境では、再構築処理によって負荷が急増するおそれがあります。ただし、これをもってすべてのバックエンドが影響を受けるとは言えず、既存のベクトルが破損したという証拠もありません。追加テストにはモックのエンドポイントとデータベースの代替実装が使われており、Dockerやインターフェースを含む一連のテストではありません。テストの制約

確認時点では、メモリーのテキストを既存のリスト／バッチ処理経路に通す修正案が示されていますが、このIssueには修正PRがまだリンクされていません。エンジニアリングチームは再構築中の実際の同時実行数と429の発生率を監視する必要があります。今後の検証では、ベクトルの順序、内容のプレフィックス、ユーザーのコンテキストに加え、同時実行数を制限する設定と制限しない設定の両方を対象にする必要があります。修正案