実行プログラムと拡張機能
Continuous Batchingと一人で使うときの速度
サーバーが1秒あたり数百トークンを生成するにもかかわらず、私の回答はそれよりもはるかに遅い速度で出てきています。これは誤った記録でしょうか？複数のユーザーのトークンを合計した処理量である可能性があります。連続バッチを理解するには、サーバー全体の1作業と1人のユーザーが待ち時間の比を確認する必要があります。
まず、終了したリクエストの場所を活用します
短い回答と長い回答を一括で処理すると、短い方の処理が先に終了します。固定されたバッチでは、残りのリクエストを待つ間、十分なリソースを消費できなくなる可能性があります。Continuous Batchingは、完了したリクエストを除き、待機中のリクエストを新たに実行することで処理を継続します。
GPUの空き時間の削減を目的とするサーバーにおいて、単一の質問を送ったときに必ず高速化されるスイッチではなく、複数のタスクを同時に行う環境において最初に検討すべき機能です。
全体100トークンと私の100トークンは異なります
仮説として、各リクエストが1秒間に10トークンずつ受信すると、総計100トークン/秒になります。1人のユーザーが1秒間に100トークンを受け取る状況とは異なります。実際のサーバーでは、各リクエストの処理速度が異なる可能性がありますが、この2つの指標を区別する原理は同じです。
多くの仕事を完了するバッチサーバーであれば、総処理量が重要です。人間と会話をするツールであれば、最初のトークンまでの時間とトークン間の間隔も重要です。総tok/sが高くても、チャットが不快に感じられた場合は、目的に合った改善かどうかを再検討すべきです。
共有モデルと別途必要なキャッシュ
複数のリクエストが同じモデルの重みを使用しても、各会話ごとにKV状態は必要です。長い入力を持つリクエストを同時に受けると、メモリが急速に消費される可能性があります。最大リクエスト数および文脈長をそれぞれ最大に設定するのは、良い出発点とは言えません。
ページ型キャッシュ管理と共通接頭辞の再使用は、余裕を活かすのに役立ちますが、メモリを生成することはできません。ピーク使用量と待ち行列をもとに、実際のリクエストに応じて制限を調整する必要があります。
1人の最適設定をそのままコピーすることは
MTPまたは草案モデルは候補を生成し検証しながらKVキャッシュを更新します。単一のリクエストで正常に動作していた実装が、異なる長さの複数のリクエストにおいても同じ経路をサポートするかを確認する必要があります。設定画面にオンになっていても、バッチ処理では別の経路で実行される可能性があります。
チャットとバックグラウンドドキュメント処理を同じサーバーに同時に実行すると、両方のタスクが競合する状況を試してみてください。単独で測定した最高速度だけでは、家族や同僚が一緒に使う際の体験を説明することはできません。
ユーザーが最も長く待った場面を見る
サーバー評価では、平均だけでなく、遅延が大きいリクエストも残す必要があります。ほとんどの場合、速いが、たまに一時停止するツールは、会話に使うには不向きである可能性があります。入力長と出力長、同時リクエスト数を記録することで、その瞬間を再現できます。
ローカルAIを単独で使う場合、同時に要求する数を小さく始めても問題ありません。複数のエージェントが実際に協力する際には、その制限を拡大し、結果を確認してください。GPUを最大限に活用するよりも、ユーザーが必要な答えを適切なタイミングで受け取ることがサーバーの役割です。