私は TF Serving を GKE にデプロイする実験を行っており、高可用性のオンライン予測システムを作ろうとしています。複数のリクエストをまとめてバッチ処理することで、レイテンシを最適化しようとしていました。ただし、レイテンシーは改善されるどころか、むしろ悪化しているようです。
- モデルは CNN で、長さ約 50 の入力ベクトルです。
- TF Serving は、6 つの標準ノードを備えた Kubernetes クラスターで実行されます
- サイズ 5 と 10 のバッチを試しました。TF Servingのバッチ処理の実装
(batch_size, input_size)は使用しませんでした。(1, input_size)
私の直感では、GPU を使用してスループットを使用する場合にバッチ処理が最大のメリットをもたらしますが、CPU で使用しても速度が低下することはありません。スローダウンは以下のチャートに示されています - req/s はむしろ予測/秒です。つまり、20 はサーバーへの 4 つまたは 2 つのリクエストに分割されます。
リクエスト数が少ない場合、これがクラスター全体にワークロードを均等に分散しないことを理解していますが、60 または 120 を見ても、レイテンシーは単に高くなります。
なぜそうなのか、何か考えはありますか？
