スループットとレイテンシー
単位時間あたりに処理できるデータ数
イメージ：バッチ処理で水平スケール
モデルにデータ入力してから返ってくるまでの時間
イメージ：ひとりのユーザの推論サーバのリクエストレスポンス時間
反比例の関係にあると言われる。なぜ？
たとえばバッチ処理するとスループットあがる。けどバッチ処理たまるまで待つから、とか。これは効率的なバッチ処理使えば解決。例えばある程度バッチがたまれば処理するdynamic batchingとか vLLMとかでは1トークン生成ごとにバッチ組み直したりして最適化 もちろんGPU盛れば並列にできるのでレイテンシー気にせずスループット上がる
全く同じことを書いている。
Improving Inference latency: The speed with which the model returns the tokens per second Improving Inference throughput: The total number of requests that the model can serve in parallel では、先ほど説明した単純なバッチ処理方法よりも改善できる点はあるのでしょうか? はい、確かに方法はあります。vLLM の登場です。 GPU のメモリ全体が、ブロックと呼ばれる小さなメモリ チャンクに分割されていると仮定します。 https://scrapbox.io/files/670c402ef0cab3001d417f2d.png
KVキャッシュの再利用: 異なるリクエストに対してKVキャッシュを再利用することで、新しいリクエストは共通トークンのアテンションスコアの計算をスキップできます。これにより、レイテンシが短縮されます。ただし、これはこの論文の貢献ではありません。KVキャッシュは、LLMサービング中に使用される一般的な手法です。 単一プロンプト、複数世代: vLLM は共通のプロンプトまたはプレフィックスをキャッシュし、それを複数世代で使用できます。これは上記と同様であり、レイテンシの削減に役立ちます。
並列サンプリングとビーム検索: 上記に続き、vLLM は並列サンプリングとビーム検索のための KV キャッシュの再利用も実装します。 世界を一時停止: バッチ内の進行中のリクエストのデコード段階の間に新しいリクエストが入ると、vLLM はバッチ内のリクエストの生成を一時停止し、新しいリクエストの KV キャッシュを計算します。KV キャッシュが計算されると、それをバッチに追加し、新しいバッチのデコードを続行します。
リクエストが連続して多すぎると、レイテンシが高くなります。
vLLMはこの動作を更新するために取り組んでいます
キュー: vLLMはバックエンド上にFastAPIサーバーも提供します。GPUメモリがいっぱいの場合にvLLMが対応できないリクエストを格納するキューを実装します。