埋め込み処理のジョブで、インタラクティブなホームAIチャットが遅くなるのはなぜですか？

埋め込み処理は、長時間実行されるバックグラウンドバッチがチャットとアクセラレーターの処理時間、CPUによる前処理、メモリ、ストレージアクセスを奪い合うため、インタラクティブなホームAIチャットを遅くします。

個人用ナレッジベースでは、数千件のドキュメントをチャンクに分割し、トークン化し、埋め込みモデルを実行し、ベクトルを正規化して、数分から数時間かけてインデックスを書き込むことがあります。チャットリクエストは予測不能なタイミングで到着し、最初のトークンが返るまでの時間を短くする必要があります。一方、埋め込みパイプラインはスループットを最大化できる大きなバッチを好みます。両方のワークロードが同じGPU、CPU、RAMプール、またはNVMeデバイスを共有している場合、バックグラウンド処理がキューを占有し、ユーザーのプロンプトがモデルに到達する前に待たされることがあります。以下では、それぞれの競合ポイントを追いながら、インタラクティブな応答を保護する方法を説明します。

埋め込みパイプラインは長時間実行されるバッチ処理

ドキュメントの取り込みでは、モデルを1回呼び出すだけではありません。ファイルの列挙、テキストの抽出、コンテンツの分割、バッチのトークン化、ベクトルの計算、メタデータとインデックス構造の保存を行います。

大きなバッチはバッチスループットを向上させますが、レイテンシーに敏感なリクエストがアクセラレーターの処理時間を得るまでの待ち時間を長くする可能性があります。

そのため、最初にライブラリをインポートしたり、完全な再インデックスを実行したりする処理は、保存後に新しいメモを1件だけ埋め込む処理とは大きく異なります。

チャットのプリフィルと埋め込み計算は同じアクセラレーターを奪い合う

インタラクティブチャットは、計算負荷の高いプロンプトのプリフィルから始まります。埋め込みモデルも、トランスフォーマー層を通じて完全なトークン列を処理し、多くの場合、大規模な並列バッチで実行されます。

プリフィル干渉に関する研究は、負荷の高いプロンプト処理が、同時に実行されるデコード処理や最初のトークンの提供を遅らせる理由を示しています。

ランタイムがチャットをプリエンプトしたり優先したりしない場合、チャットモデル自体はすでに読み込まれていても、短い質問が現在の埋め込みバッチの後ろで待たされることがあります。

埋め込みバッチを小さくすると、最長のブロック時間を短縮できますが、取り込み全体のスループットは低下する可能性があります。

モデルを分けるとメモリ負荷が高まる

チャットモデル、埋め込みモデル、リランキングモデル、ベクトルランタイムは、それぞれ重みやアロケータープールをメモリ上に保持することがあります。これらを合計したフットプリントによって、チャットのKVキャッシュや同時利用ユーザーのための空き容量が減少します。

ZimaSpaceの記事アクセラレーターのメモリ競合では、計算リソースの使用率が低くても、インタラクティブなリクエストに十分なメモリが残っているとは限らない理由を説明しています。

メモリが逼迫すると、システムはチャットの同時実行数を減らしたり、モデルを追い出したり、層をオフロードしたり、埋め込み処理の完了後にコールドリロードを発生させたりすることがあります。

検索とチャットで1つの共有エンコーダーを使うことは、一部のアーキテクチャーでは可能です。しかし、タスクごとに異なるモデルを使うほうが、より良い結果が得られ、メモリコストも分離できます。

Featured

ZimaCube 2 パーソナルクラウドホームNAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

CPUとストレージの処理が推論前の検索を遅らせる

トークン化、PDF解析、OCR、ハッシュ計算、ベクトルデータベースへの書き込みは、CPUスレッドを飽和させ、モデルファイルやチャット履歴と同じストレージにランダムI/Oを発生させる可能性があります。

バックグラウンドのインデックス作成は、ユーザー向けのCPUグラフが完全に飽和しているように見えない場合でも、インデックス作成の競合を引き起こします。

その結果、チャットの検索処理は、プロンプトが組み立てられる前に、データベースロック、キャッシュミス、または混雑したNVMeキューによって待たされることがあります。

優先度と受付ルールでチャットを保護する

取り込み処理を一定サイズのバッチに分け、バッチ間に間隔を設け、同時実行数を制限し、インタラクティブなキューが空であるか、しきい値を下回っている場合にのみ新しいバックグラウンド処理を受け付けます。

Llumnixは、レイテンシーとリソース要件が異なるリクエストに対応するために、動的な優先度を使用します。

ホームサーバーでは、より簡単なポリシーを実装できます。チャットと音声にはすぐに処理枠を割り当て、埋め込み処理は低い優先度で実行するか、メンテナンス時間帯に限定します。

推測ではなく干渉を測定する

埋め込みジョブを停止した場合と実行した場合で、チャットの最初のトークンまでの時間、トークン間遅延、検索レイテンシー、1秒あたりの埋め込みチャンク数、GPUメモリ、CPU使用率、ストレージレイテンシーを記録します。

チャットがバッチの境界でのみ待たされるなら、バッチサイズを小さくするか、プリエンプションを有効にします。モデルのリロードが発生するなら、常駐させるモデルを減らすか、ワーカーを分離します。検索処理が停止するなら、インデックスへの書き込みやモデルファイルを別のI/O経路に移します。

目標は、可能な限り速い再インデックスではありません。家庭内のインタラクティブなレイテンシーを通常の範囲に保ちながら、バックグラウンドの取り込み速度を最大化することです。

ライブラリの構築が完了したら、定期的な全件スキャンから差分検出による増分更新に切り替え、バックグラウンドの負荷が新しいコンテンツの量に比例するようにします。

よくある質問

埋め込みモデルを別にすると、必ずチャットが遅くなりますか？

いいえ。別のデバイスでアイドル状態になっていたり、実行されたりする場合があります。速度低下が発生するのは、計算、メモリ、CPU、ストレージ、またはスケジューリングの経路が重複するときです。

埋め込みのバッチサイズを小さくすれば、必ず改善しますか？

個々のブロック時間は短くなりますが、オーバーヘッドと取り込み全体の時間が増える可能性があります。優先度設定とプリエンプションによって、スループットをより維持できる場合があります。

埋め込み処理は夜間に実行すべきですか？

大規模なインポートは、夜間に実行するのが適しています。増分更新は、処理量を制限し、インタラクティブなリクエストに処理枠を譲るようにすれば、日中でも実行できます。