TensorFlow 2.22候補版、重要度別のバッチ待機とウォームアップ用スレッドプールを追加

TensorFlowは9月24日、GitHubで2.22.0-rc0のリリースノートを公開し、BatchFunctionに重要度別のバッチ待機時間と、独立したウォームアップ用スレッドプールの設定を追加した。これはリリース候補版の告知だ。PyPIパッケージは22日に先行して公開され、プラットフォーム別のファイルも23日にアップロードされており、告知日とパッケージが初めて利用可能になった日にはずれがある。[リリースノート](https://github.com/tensorflow/tensorflow/releases/tag/v2.22.0-rc0)、[PyPIの記録](https://pypi.org/project/tensorflow/2.22.0rc0/)

BatchFunctionは、並行して呼び出された複数の入力を第1軸に沿って結合し、指定された関数を実行する。モデル推論に適した機能だ。従来から、最大バッチサイズ、待機時間、キュー容量などを設定できる。バッチを大きくするほど計算リソースの利用率を高められる可能性がある一方、ほかのリクエストを待つことでレイテンシも増える。そのため、低トラフィック時とトラフィックが急増する場合では、異なるトレードオフが必要になる。[オペレーターのドキュメント](https://www.tensorflow.org/mlir/tf_ops#tfbatchfunction)

新たに追加された `per_criticality_batch_timeout_micros` では、重要度の異なるリクエストに別々の待機時間を設定できる。公式ドキュメントでは整数配列として定義されている。サービス設計の観点からは、チームはインタラクティブなリクエストを早く処理に回し、緊急性の低い処理にはバッチをまとめる余地を残せると考えられる。ただし、その効果はリクエストの重要度の分類方法や、実行経路が対応するスケジューラーを使っているかどうかに左右される。この変更はバッチ関数を利用するサービスに直接影響するため、既存アプリケーションでは設定が実際の実行ノードまで伝わることを確認する必要がある。[インターフェース定義](https://www.tensorflow.org/mlir/tf_ops#tfbatchfunction)

もう一つの属性 `num_warmup_batch_threads` は、ウォームアップリクエスト用に独立したスレッドプールを割り当てられる。スケジューラーのソースコードによると、この設計はグローバルスケジューラーを使う際に、ウォームアップ処理が通常のバッチ処理用スレッドを占有する問題を対象としている。継続的にトラフィックを受けながらモデルをロードするサービスでは、ウォームアップ処理とオンライン処理を分けて管理する手段となる。[スケジューラーのソースコード](https://github.com/tensorflow/tensorflow/blob/master/tensorflow/core/kernels/batching_util/shared_batch_scheduler.h)

これらの制御項目が扱うのは、スケジューリング資源とバッチをまとめるタイミングだ。スケジューラーの動作上、待機期限に達しても、未充足のバッチを送出するには利用可能なスレッドが必要となる。そのため、設定値をエンドツーエンドのレイテンシ保証とみなすことはできない。また、スレッドプールが独立していても、ハードウェア資源が分離されているとは限らない。[スケジューラーの動作](https://github.com/tensorflow/tensorflow/blob/master/tensorflow/core/kernels/batching_util/shared_batch_scheduler.h)

公式リリースノートでは、これら2つの設定によるスループットやテールレイテンシのテスト結果は公開されていない。エンジニアリングチームはまず混合トラフィックをリプレイし、オペレーターの属性、重要度の分類、ウォームアップ経路を確認したうえで、リクエスト種別ごとの高パーセンタイルレイテンシ、平均バッチサイズ、モデルのレディ時間を比較できる。特にモデルのロード中に発生する資源競合をテストし、ウォームアップの高速化にオンラインレイテンシの悪化が伴わないか確認したうえで、正式版でインターフェースと動作が確定するのを待つ必要がある。[候補版のリリースノート](https://github.com/tensorflow/tensorflow/releases/tag/v2.22.0-rc0)