なぜホームAIサーバーには個別の作業キューが必要なのか？

家庭用AIサーバーには、対話型リクエストとバックグラウンドジョブでレイテンシー、メモリ、リトライ、完了要件が異なるため、別々の処理キューが必要です。

1台のマシンで、チャット、音声操作、ドキュメント取り込み、埋め込み、写真分析、モデルのダウンロード、エージェントワークフロー、定期サマリーなどを処理できます。単一の先着順キューでは、これらのジョブを同じものとして扱います。しかし、インデックス作成では5秒の遅延が許容されても、音声コマンドでは大きな支障になります。さらに、短いリクエストが到着する前に、長時間ジョブがメモリやストレージ帯域幅を確保してしまうこともあります。キューを分けることでワークロードの種類が見えるようになり、受付制御、優先度、同時実行数、復旧ポリシーによって、まず応答すべき家庭内機能を保護できます。

単一のFIFOキューはヘッドオブラインブロッキングを引き起こす

1つのキューの先頭に長いプロンプト、画像リクエスト、モデルの読み込み、埋め込みバッチがあると、その後ろに並ぶ多くの短いリクエストが遅延します。

FastServeは、処理を完了まで実行する方式ではなく、プリエンプティブスケジューリングと複数の優先度レベルによって、ヘッドオブラインブロッキングに対処します。

家庭用サーバーで同じ分散設計を採用する必要はありませんが、この原則は取り入れられます。短い対話型処理は、到着が後だったというだけで、長さの分からないバックグラウンドリクエストの後ろで待たされるべきではありません。

対話型ジョブとバックグラウンドジョブではサービス目標が異なる

音声、チャット、自動化の呼び出しでは、キューでの待ち時間と最初のトークンが返るまでの時間が重要です。一方、埋め込み、インデックス作成、夜間のサマリーでは、総スループットと最終的な完了のほうが重要です。

JITServeは、エンドツーエンドのワークフローや期限が同じではないリクエストについて、異なるレイテンシー目標を研究しています。

対話型処理は、同時実行数を制限した低レイテンシーキューに入れます。バルクジョブは、家庭内の需要が高まったときに一時停止、バッチ処理、または処理の譲渡ができるスループット重視のキューに入れます。

優先度にはエージングも含めるべきです。チャットサービスが常に混雑していても、メンテナンスが永遠に後回しにならないようにするためです。

プレフィル、デコード、モデル準備は互いにブロックする可能性がある

長いプレフィルはトークンデコードとは異なる形でコンピュートリソースを使用します。また、モデルの読み込みやキャッシュの準備では、ストレージやメモリ間の転送を待つことがあります。

DistServeは、プレフィルとデコードを分離します。両者を同じ場所に配置すると、全体の使用率が高く見えてもレイテンシーが悪化する可能性があるためです。

キューを分ければ、大きなドキュメントプロンプトを制御されたプレフィル経路に通しながら、アクティブなチャットにデコードの機会を確保できます。

モデル読み込み用のキューを設ければ、コールド状態のモデルが一度にディスク帯域幅やアクセラレータメモリを奪い合う数も制限できます。

Featured

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

ZimaCube2

$799.00 - $2,499.00

Buy Now

実行可能な処理を準備中の処理の後ろで待たせない

モデルとキャッシュの状態が常駐しているため、すぐに実行できるリクエストがあります。一方で、低速なストレージからデータを復元したり、先にモデルを読み込んだりする必要があるリクエストもあります。

Bidawは、状態の準備が必要なリクエストの後ろで実行可能な処理が待たされないよう、2つのリクエストキューを使用します。

家庭用サーバーで同等の仕組みを実現するには、10GBのモデルのダウンロードやキャッシュの復元が終わるまで実行できないリクエストで、対話型キューを占有しないようにします。

ストレージとCPUのキューも同じように分離する必要がある

AI処理が競合するのはアクセラレータだけではありません。OCR、PDF解析、トークン化、ベクトル書き込み、サムネイル作成、バックアップ、モデルの読み込みによって、CPUやストレージのキューが飽和することがあります。

ZimaSpaceによるストレージキューの競合の分析は、GPUスケジューリングを考慮する前であっても、継続的なバルク処理によって対話型のセルフホストアプリケーションが遅延する理由を示しています。

バックグラウンドI/Oの深さを制限し、可能であればモデル用とデータベース用の経路を分離し、家庭内の利用がピークになる時間帯にはライブラリ全体のスキャンを一時停止します。

GPU時間を保護するキューポリシーでも、バックグラウンドのOCRがすべてのCPUコアを使い切れば、チャットの検索レイテンシーを保護できません。

キューポリシーには受付制御、クォータ、可観測性が必要

キューに別々の名前を付けるだけでは、分離は実現しません。各キューには、同時実行数の上限、メモリ予算、優先度、リトライポリシー、タイムアウト、アイドル状態のリソースを借用するルールが必要です。

Agentixは、後続のステップを開始させる短い呼び出しに適切なサービスを提供できるよう、ワークフローの依存関係をスケジューリング情報として扱います。

キューの深さ、最も長く待っている処理の待ち時間、実行中のジョブ数、確保済みメモリ、プリエンプション回数、リトライ回数、ワークロードの種類ごとのレイテンシーを測定します。アラートでは、どのキューが目標を満たしていないかを特定できるようにします。

実用的な設計はワーク保存型です。バックグラウンドキューは余剰キャパシティを利用しますが、対話型リクエストが到着したときには、実行中のジョブを不安定にすることなく、そのキャパシティを取り戻せるようにします。

FAQ

家庭用AIサーバーでは、キューごとに別の物理マシンが必要ですか？

いいえ。キューはスケジューリング上の境界です。1台のマシンを共有しながら、異なる優先度、同時実行数の上限、リソース予算を適用できます。

チャットが始まったら、バックグラウンドジョブは必ず停止すべきですか？

必ずしもそうではありません。CPU、メモリ、ストレージ、アクセラレータに十分な余裕が残っている場合は、同時実行数を減らして継続できます。

コンテナで別々のキューを置き換えられますか？

コンテナはプロセスを分離しますが、複数のAIワークロード間で公平なスケジューリングや受付制御を自動的に提供するわけではありません。