1台のホームAIモデルで、レイテンシーが不安定になる前に何人の同時ユーザーに対応できますか？

エヴァ・ウォン

IceWhale author

エヴァ・ウォン は テクニカルライター であり ZimaSpaceの常駐ティンカーでもあります。 生涯のオタクであり、 ホームラボとオープンソースソフトウェアに情熱を持っています。彼女は複雑な技術的概念をわかりやすく、 実践的なガイドに翻訳することを専門としています。エヴァはセルフホスティングは楽しくあるべきで、怖がるものではないと信じています。彼女のチュートリアルを通じて、コミュニティが ハードウェアのセットアップを解明する手助けをしています。初めてのNAS構築からDockerコンテナの習得まで。

How Many Concurrent Users Can One Home AI Model Serve Before Latency Becomes Unstable? - Zima Store Online

1台の家庭用AIモデルは、1人から数人のインタラクティブユーザーに安定して対応できますが、安定稼働の上限はトークン需要、バッチ処理、レイテンシ目標によって異なります。

毎秒30トークンを生成するモデルは、短いチャットを1人で行う場合は高速に感じられても、4人が同時に長いプロンプトを送信すると処理が滞ることがあります。同時実行ではKVキャッシュメモリを消費し、デコード容量を共有し、キューの急増を引き起こします。適切な上限とは、通常の家庭利用において、定義したp95の初回トークンレイテンシとトークン生成速度の目標を満たせる最大の負荷です。

同時実行数によってスループットは待ち時間に変わる

おおまかな容量は、持続的な生成スループットを、アクティブなセッション全体で1秒あたりに要求される平均トークン数で割ることで見積もれます。需要が処理容量に近づくと、小さなバーストでも長いキューが発生します。ユーザーは同じ単位ではありません。50トークンの回答と2,000トークンの回答では、サーバーへの負荷が異なります。

レイテンシとスループットの分析では、バッチ処理によって全体のスループットが向上する一方、個々の応答レイテンシとはトレードオフになることが説明されています。このバランスによって、セッションを追加したときに安定して感じられるかどうかが決まります。

スケジューラーによっては、プロンプトのプリフィル処理がデコード処理を妨げることもあります。2人のユーザーが大きな文書を貼り付けると、短い質問をする6人のユーザーよりも全体に大きな影響を与える場合があります。そのため、プロンプトと出力の分布を考慮しないユーザー数は、別の環境にそのまま適用できません。

KVキャッシュとスケジューリングが別の上限を生む

アクティブな各シーケンスは、コンテキストに対応するアテンションのキーとバリューを保存します。履歴が長くなったりバッチが大きくなったりすると、KVキャッシュの使用量が増え、リクエストが拒否されたり、スワップされたり、遅延したりします。連続バッチ処理では、デコード反復の間に新しい処理を受け入れられるため使用効率は向上しますが、空きメモリが生まれるわけではありません。

連続バッチ処理に関する技術解説では、反復単位のスケジューリングによって、通常はアイドル状態になるバッチ枠を埋める方法が示されています。効果はワークロードに左右され、リクエストごとの競合がわずかに増えることもあります。

飽和状態に近づくと、到着間隔のばらつきにキューの長さが敏感に反応するため、レイテンシが不安定になります。平均レイテンシは徐々に増加しても、p95や最大レイテンシは急上昇することがあります。安定した容量は、ベンチマークで最高の毎秒トークン数を記録した地点ではなく、その急上昇点より下に設定すべきです。

ユーザー数だけでは体感を予測できなくなる場面

同じサーバーでも、RAG、ツール利用、長文生成より、オートコンプリートのほうが多くのユーザーに対応できます。コールドスタート、サーマルスロットリング、検索、音声合成など、モデル提供以外の段階も存在します。モデル単体の同時実行数では、アプリケーション全体の応答性を保証できません。

サービングメモリに関するガイドでは、メモリ、コンテキスト、バッチ処理、並列処理が相互に影響する制約として説明されています。いずれか1つを変更するだけで、容量の急上昇点が移動する可能性があります。

また、家庭内のリクエストが独立して到着するのではなく、同期したバーストとして到着する場合も予測は外れます。ほとんど重ならない4人のユーザーには簡単に対応できても、2つの自動エージェントがモデルを継続的に飽和させることがあります。登録アカウント数ではなく、実際に提供される処理量を測定してください。

Featured

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

ZimaCube2

負荷テストで同時実行数の急上昇点を見つける

短いリクエスト、中央値のリクエスト、長いリクエストを現実的に再現し、同時実行セッション数を1、2、4、8と変えてテストします。モデル、量子化方式、コンテキスト上限、サンプリング設定は固定してください。キュー時間、初回トークンレイテンシ、トークン間レイテンシ、完了率、KVキャッシュ使用量、p50、p95、最大値を記録します。

複数の家庭内セッションが1つのモデルを共有する場合は、共有モデルセッションのアーキテクチャをテスト条件として使用します。RAGとツールの処理段階は無効にするか、別々に計測してください。

安定した上限は、キューが増加する傾向やメモリエラーがなく、p95の初回トークンレイテンシが家庭内利用の目標範囲に収まる最大同時実行数とします。バーストに備えて、スループットには20～30％の余裕を確保してください。コンテキスト長、モデル、スケジューラーを変更するたびに再テストします。