なぜホームAIサーバーは一人のユーザーには高速に感じられても、家族全員にはそう感じられないのでしょうか？

ホームAIサーバーは一人のユーザーには高速に感じられても、複数の家族が同時にリクエストを共有すると計算、メモリ、スケジューリング時間を分け合うため遅く感じられます。

違いは、一人がアイドル期間中に短いチャットプロンプトを送信し、その後複数の家族メンバーが同時に長い会話、文書要約、画像解析、音声タスク、またはエージェントワークフローを開始するときに現れます。単一ユーザーテストは主にウォームモデルのレイテンシを明らかにしますが、家族利用はキューイング、混在するプロンプト長、別々の会話キャッシュ、競合するプレフィルとデコードフェーズ、予測不可能な出力長を追加します。以下のセクションでは、サービング層がこれらの違いをどのようにして遅い最初のトークン、不均一な生成、そして高いメモリ負荷に変換するかを説明します。

スケジューラはファミリーリクエストの背後にある制御層です

ローカルモデルは、ハードウェアの新しいコピーから独立してすべてのユーザーに応答するわけではありません。1つのサービングプロセスがリクエストを受け取り、各プロンプトがモデルに入るタイミングを決定し、互換性のある作業をグループ化し、限られたアクセラレータの時間とメモリをアクティブな会話に割り当てます。

最新のシステムは、リクエストスケジューリングを使用して異種プロンプトのバランスを取り、作業を移行し、レイテンシの優先順位を区別します。GPUが1つのホームサーバーや共有システムメモリでは、そのスケジューラは新しい容量を作り出すことはできず、既存の容量をどのように分配するかを決定するだけです。

これが、同じモデルに接続された二つのインターフェースが同じネットワーク上でも異なる感覚を与える理由です。空のキューに到着したリクエストはすぐに開始されますが、同じくらい短いリクエストでも、長いプロンプト、大きな画像、または他のユーザーの長い応答の後ろで待つことがあります。

なぜ一人のユーザーがサーバーを実際より速く見せるのか

単一ユーザーテストは通常、好条件下で実行されます：モデルはすでにロードされており、アクセラレータはアイドル状態で、他のコンテキストがキャッシュメモリを占有しておらず、リクエストはキューイングなしで開始されます。目に見える結果は、最初のトークンまでの時間が短く、トークン生成が安定していることです。

LLMサービングには、スループットとレイテンシのトレードオフが文書化されています。バッチ処理は総完了作業量を向上させることができますが、負荷が増加すると、特にサーバーがプロンプト処理と継続的な生成を混在させている場合、個々のリクエストが経験する遅延も増加します。

したがって、このベンチマークは「ほぼすべてのリソースが1つのリクエストに属するとき、このモデルはどれほど応答性が高いか？」に答えますが、「同じ応答時間目標を満たせるファミリーのリクエスト数はいくつか？」には答えません。

有用な容量テストはユーザーを徐々に増やし、最初のトークンの遅延、トークン間の時間、キュー時間、メモリ使用量、完了率を測定し、単一の最良ケースのトークン毎秒数を報告するだけではありません。

プリフィルとデコードは異なる方法で競合します。

各リクエストはプリフィルから始まり、入力プロンプトを処理して生成に必要な状態を構築します。デコードはその後、出力トークンを1つずつ生成します。長い文書や会話はプリフィルの計算負荷を高め、複数のアクティブな応答は繰り返しデコードに戻ります。

プリフィルとデコードに関する研究では、両フェーズを同じ場所で行うと干渉が生じ、レイテンシが連動することが示されています。家庭内では、長い文書を貼り付ける一人のユーザーが、すでに応答を受け取っている別のユーザーの遅延を引き起こすことがありますが、リクエストの形状は異なります。

このファミリーには2つの症状が見られます。新しいユーザーは最初のトークンの待ち時間が長くなることがあり、アクティブなユーザーは後のトークン間で不均一な一時停止を感じることがあります。平均スループットは許容範囲内でも、インタラクティブな体験は一貫しなくなることがあります。

-15% OFF

ZimaBoard 2 - あなたの大きなアイデアのためのミニホームサーバー

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

各会話はそれぞれ独自のKVキャッシュ容量を消費します。

プリフィル後、サーバーは以前のトークンを表すキーとバリューテンソルを保持し、新しい出力トークンごとに会話全体を再計算しません。会話が長くなり、同時ユーザー数が増えると、この作業セットが拡大します。

元のvLLM研究では、KVキャッシュメモリがバッチサイズと同時サービングの大きな制限要因であると特定しています。効率的なページングは無駄を減らしますが、すべてのアクティブなコンテキストは推論経路のどこかで実メモリを必要とします。

利用可能なGPUメモリ、共有RAM、またはアクセラレータメモリが逼迫すると、サーバーはリクエスト数を制限したり、作業をプリエンプトしたり、コンテキスト制限を短縮したり、キャッシュ状態をオフロードしたり、別のモデルを追い出したりすることがあります。これらのフォールバックは、スムーズな単一会話を家族全体の遅延急増に変える可能性があります。

関連するZimaSpaceのモデル追い出しの説明は、1つの深刻なケースを扱っています：アクティブなワークロードが常駐モデルを追い出し、次のリクエストが再読み込みとウォームアップのコストを支払ってから通常の生成が再開されます。

家族のワークロードは単に数が多いだけでなく不均一です

2人のユーザーが必ずしもパフォーマンスを正確に半分にするわけではありません。1人は短い事実質問をし、もう1人は長いPDFを提供したり、大きな応答を要求したり、画像認識を実行したり、繰り返しモデル呼び出しを行うエージェントを起動したりするかもしれません。

LLMスケジューラーは、不均等なリクエストコストを処理しなければなりません。なぜなら、プロンプトと出力の長さが予測不可能に変動するためです。制限や公平なスケジューリングがなければ、1つの重いセッションがキュー、計算、キャッシュリソースを複数の軽量チャットよりもはるかに長く占有する可能性があります。

以下の表は、ユーザー数だけでは容量の指標として不完全である理由を示しています。

したがって、家族テストは実際のチャット、検索、ビジョン、音声、自動化の混合を再現する必要があります。5つの同一の短いプロンプトは健康的に見えるかもしれませんが、1つの長いコンテキスト要求と2つのアクティブな会話は実際の限界を明らかにします。

家族の応答性を改善するには？

まずは適切なモデルを1つ常駐させ、不要な最大コンテキストを減らし、長い出力を制限し、公平な同時実行やキューのルールを割り当てましょう。小さいモデルは、アクティブコンテキスト用のメモリがほとんど残らない大きいモデルよりも家族に適している場合があります。

同時AIユーザーのZimaSpace展開境界は同じ原則の大規模版です：モデル重み、アクティブコンテキスト、バッチサイズ、サービング戦略がすべてハードウェアに収まる必要があります。ストレージはチェックポイントを保持できますが、高速な対話型推論は使用中の重みとアクティブ状態の配置に依存します。

連続バッチ処理、プレフィックス再利用、ページ化KVキャッシュ、リクエスト優先度、別々のワーカーレプリカは利用率や公平性を改善できます。これらの効果は条件付きで、スループット重視の設定ではサーバーがより多くのトークンを処理しつつ、1人のユーザーがより長く待つことを許容する場合があります。

ハードウェアが限界を決めます。家族の負荷がアクセラレータメモリ、計算帯域、CPU前処理、利用可能なモデルレプリカを使い果たすと、スケジューリングは不足をより公平に分配できますが、解消はできません。

よくある質問

2人のユーザーがいるとホームAIサーバーは常に2倍遅くなりますか？

いいえ。結果はプロンプトの長さ、出力の長さ、バッチ処理、モデルサイズ、キャッシュ使用、リクエストの重なりに依存します。2つの短いリクエストは効率的にバッチ処理できる一方、1つの長いリクエストは複数の軽いセッションに干渉することがあります。

家族の各メンバーに別々のモデルインスタンスが必要ですか？

通常はしません。1つのマルチユーザーサービングプロセスはモデルの重みを共有し、別々のリクエストをスケジュールできます。別々のインスタンスは分離を改善するかもしれませんが、メモリを複製または分割し、小型ハードウェアでは総容量を減らす可能性があります。

高速なネットワークでマルチユーザーAIの遅延は解消しますか？

入力転送、リモートストレージ、クライアント接続がボトルネックの場合のみです。家族の負荷下でのほとんどのローカルテキスト生成の遅延は、キューイング、計算、モデルメモリ、KVキャッシュの圧迫によるものです。

家族で使うなら小さいモデルのほうが良いですか？

そうかもしれません。小さいモデルは同時実行コンテキストにより多くのメモリを残し、より高速に生成できる場合がありますが、品質のトレードオフは家族のタスクに合致している必要があります。