ホームAIサーバーは、複数のユーザーセッションで1つのモデルを共有できますか？

はい。1台のホームAIサーバーでモデルを1度読み込み、複数のユーザーセッションに対応できます。最新の推論サーバーは、高価なモデルの重みを共有しながら、会話ごとに個別のリクエスト状態を維持するよう設計されています。家族一人ひとりに同じモデルの別コピーを読み込むよりも、はるかにメモリ効率に優れています。

主なスケーリングの制約は、通常、重みではありません。アクティブユーザーによって増加するKVキャッシュ、コンテキスト長、同時トークン生成、キューが制約になります。したがって、マルチユーザーへの提供は、モデルサイズの問題であると同時にスケジューリングの問題でもあります。

ユーザー間で実際に共有されるものは？

                 読み込まれた1つのモデル
                 RAM／VRAM内の重み
                         |
       +-----------------+-----------------+
       |                 |                 |
    セッションA　セッションB　セッションC
   KVキャッシュA　KVキャッシュB　KVキャッシュC
   履歴A　履歴B　履歴C

Transformerの重みは通常の推論中は読み取り専用なので、多数のリクエストで同じコピーを使用できます。ただし、各シーケンスには独自のトークン状態とアテンションキャッシュが必要です。

推論サーバーは同時リクエストをどのように処理するのか？

ランタイムごとに公開されているスケジューリング制御は異なりますが、原則は似ています。複数のシーケンスを受け入れ、可能な場合は処理をバッチ化し、超過したリクエストをキューに入れます。

OllamaのFAQでは、並列リクエストの制御について説明し、並列コンテキストによってメモリ要件が増加することを記載しています。Llama.cppの並列処理の例では、1つのモデルサーバーを使用する複数のシミュレートされたクライアントを示しています。

vLLMなどの高スループットサーバーは、バッチ処理とKVキャッシュを考慮したスケジューリングを使用して、複数の受信シーケンス間でアクセラレーターを効率的に稼働させます。

コンテキスト長が別のユーザーの追加より多くのメモリを消費する理由

モデルの重みがVRAMに十分収まるとします。4人のユーザーがそれぞれ非常に長い会話を開始した場合、重みが4倍になることはありませんが、アクティブな各シーケンスのKVキャッシュは大幅に増加する可能性があります。

VRAMの予算
  |
  +-- モデルの重み　固定
  +-- ユーザーAのKVキャッシュ　コンテキストに応じて増加
  +-- ユーザーBのKVキャッシュ　コンテキストに応じて増加
  +-- ユーザーCのKVキャッシュ　コンテキストに応じて増加
  +-- ランタイムのオーバーヘッド

このため、「モデルが収まる」だけではキャパシティプランニングとして不十分です。マルチユーザーシステムでは、コンテキスト長の最大値、同時実行シーケンス数の最大値、上限を設けたキューを設定する必要があります。

ZimaSpaceの既存ガイドマルチユーザーのホームAI向けアクセラレータースケジューリングでは、同じリソース境界について詳しく説明しています。

Featured

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

ZimaCube2

$799.00 - $2,499.00

Buy Now

ユーザーごとに専用のモデルプロセスを用意すべきか？

通常は不要です。プロセスを分けると重みが重複し、メモリに収容できるモデル数が減ります。ただし、次のような場合には合理的です。

• ユーザーごとに異なるファインチューニングモデルや量子化モデルが必要である。
• 効率よりも強力なプロセス分離が重要である。
• 1つのワークロードでカスタムランタイムを使用する。
• ユーザーごとにGPUを厳格に割り当てたい。
• 1つのモデルで、互換性のないコンテキスト要件やサンプリング要件がある。

同じモデルを使用する家族や小規模チームの場合、認証済みアプリケーションの背後に1つの推論サービスを配置するほうが、通常はシンプルです。

会話メモリはモデルサーバーの外部で管理する

推論サーバーを「誰が何を言ったか」の権威データベースにすべきではありません。明示的なユーザー／セッションIDに基づいて、チャット履歴とユーザー設定をアプリケーション層に保存してください。

ブラウザ／アプリ
    |
    | 認証済みのuser_id
    v
チャットアプリケーション
    |
    +-- 履歴DB（ユーザーごと）
    +-- RAG権限
    |
    v
共有モデルサーバー

生成のたびに、アプリケーションは現在のユーザーが閲覧を許可されている履歴とプライベートな検索コンテキストだけを組み立てます。

これは特に、NAS上のプライベートAIアシスタントにおいて重要です。同じサーバーに、複数の家族メンバーに属する個人文書が保存されている場合があるためです。

共有プレフィックスキャッシュは共有会話メモリではない

一部のランタイムでは、共通するプロンプトのプレフィックスに対してKVキャッシュやその他の処理結果を再利用できます。そのため、共有システム指示や繰り返し使用するドキュメントのプレフィックスを一度だけ計算し、効率的に再利用できる場合があります。

この最適化は、あるユーザーのプライベートコンテキストを別のユーザーのプロンプトに入れることを許可するものと混同してはなりません。キャッシュシステムには、正しい分離とハッシュのセマンティクスが必要です。どのコンテンツをリクエストに供給できるかは、引き続きアプリケーションの権限によって決まります。

公平なスケジューリングを使用して、1人のユーザーがサーバーを占有できないようにする

非常に長い出力を求める1件のリクエストがデコード能力を消費し、他のユーザーを待たせる可能性があります。次のような受付制御を追加します。

• ユーザーごとの同時リクエスト数の上限。
• 出力トークンの最大数。
• コンテキストウィンドウの最大長。
• アクティブなシーケンス数のグローバルな上限。
• キューのタイムアウト。
• 短時間で完了するインタラクティブなリクエストを優先する。
• バックグラウンドジョブ用の個別バッチキュー。

インタラクティブなチャットと夜間のドキュメント要約は、同一のスケジューリングポリシーで競合させるべきではありません。

サーバーのメモリが不足するとどうなりますか？

優れたサービスは、アクセラレーターがクラッシュする前に新しい処理を拒否するか、キューに入れます。容量制御では、楽観的な平均値だけでなく、実際に設定されたコンテキストを使用する必要があります。

サーバーがクラッシュしなくなるまで、すべてのユーザーのコンテキストウィンドウを黙って縮小しないでください。ユーザーがシステムに保持させられる情報を把握できるよう、コンテキストポリシーを明示します。

マルチユーザーモードではプライバシーと認証がより重要

1つのモデルを1人の管理者だけが利用する場合は、localhost限定のエンドポイントで十分なことがあります。複数人が利用するようになったら、アプリケーションでユーザーを認証し、データソースへのアクセスを認可する必要があります。

保護対象：

• チャット履歴。
• RAGコレクションとドキュメントのACL。
• 保存済みプロンプト。
• ツールの認証情報。
• 生成ファイル。
• ログとトレース。

共有モデルプロセスには現在のリクエストのコンテキストだけを渡し、NASの通常の権限モデルを迂回する便利な抜け道にならないようにします。

1台の家庭用AIサーバーで対応できるユーザー数は？

一律に適用できる有用な固定値はありません。アクティブなユーザーが1人か2人だけなら、多数の登録ユーザーに対応できるサーバーでも、長いコンテキストを使うユーザーが2人同時に利用すると、小型GPUの容量を使い切ることがあります。

次の3つのシナリオでベンチマークします。

1. インタラクティブなユーザー1人。
2. 想定される家庭内の同時利用負荷。
3. 負荷の高いユーザー1人と、短いリクエストを複数処理する場合。

初回トークンの生成時間、ユーザーごとの毎秒トークン数、キュー待ち時間、KVキャッシュの使用率、RAM/VRAM使用量、リクエスト失敗率を測定します。

よくある質問

モデルが共有されていることで、ユーザー同士の会話が見えてしまいませんか？

アプリケーションが会話履歴と検索コンテキストを分離して保持している限り、問題ありません。モデルの重みを共有しても、チャット履歴が自動的に共有されるわけではありません。

並列推論によって各ユーザーの処理は速くなりますか？

総スループットは向上する可能性がありますが、複数のシーケンスがアクティブな場合、個々のリクエストに割り当てられる計算リソースは少なくなることがあります。通常の目標は、サービス全体の処理量を増やし、キュー待ち時間を短縮することです。

1台のサーバーで複数のモデルもホストできますか？

メモリに余裕があれば可能です。ランタイムによっては必要に応じてモデルを読み込み・アンロードしますが、1つまたは複数の永続的なサービングプロセスを前提に設計されているものもあります。複数モデルのスケジューリングでは、マルチユーザースケジューリングに加えて、もう1つの容量管理レイヤーが必要になります。

最終結論

1つの読み込み済みモデルは、通常、小規模な家庭用AIサービスが共有すべきリソースそのものです。 モデルの重みは共有し、セッション履歴とKV状態を分離し、すべてのユーザーを認証し、コンテキスト長と同時実行数に上限を設け、バックグラウンド処理はインタラクティブなチャットとは別にスケジュールします。モデルプロセスを増やすのではなく、セッションごとの状態とキューの動作を考慮して設計すれば、マルチユーザーAIは安定して運用できます。