動的形状 API が適用できない場合¶
ここでは、動的形状をエミュレートするいくつかのアプローチを検討します。ネイティブの動的形状 API が機能しない場合、または期待どおりに動作しない場合にのみ、次の方法を適用します。
パディング¶
モデルは、部分的に満たされたテンソルをサポートするように設計できます。BERT モデルの場合、モデルへの特別な入力を使用して、未使用の要素をマスクします。したがって、事前定義された大きなシーケンス長に合わせてモデルを 1 回再形成し、1 回コンパイルすることができます。次に、入力テンソルは、有効なトークンを指定するマスクで部分的にのみ使用されます。このアプローチは、パディングと呼ばれます。
ただし、パディングはすべてのモデルとユースケースに適用できるわけではありません。パディングを適用する前に、モデルの内部に注意してください。そうしないと、パディング領域でダミー要素を適切に処理するようにモデルが設計されていない場合、推論の結果が完全にスクランブルされるか、精度が大幅に影響を受ける可能性があります。また、モデルは推論中にクラッシュすることもあります。
パディングの主な欠点は、開発者のエクスペリエンスへの影響以外に、パフォーマンスが低下することです。モデルがパディングに適している場合でも、パディング領域内のダミー要素で時間を要する処理が連続して発生するように設計されているため、結果には影響しませんが、推論速度が低下します。
複数の事前コンパイル済みモデル¶
任意のサイズ入力を処理するアプローチは、さまざまな入力形状に合わせて再形成されたいくつかのモデルを事前コンパイルすることで利用できます。この方法は、異なる形状の数が少なく、複数の再形状やコンパイルにかかる時間や、消費されるメモリー量の増加を許容できる場合にうまく機能します。この方法は適切にスケーリングできないため、パディングと組み合わせて使用されます。したがって、再形状前のモデルの中から最も適切な入力形状を持つモデルが選択されます。単一モデルと比較して、パディング領域が小さくなります。
次元のパーティショニング¶
もう 1 つの実用的なアプローチは、入力テンソルを動的次元に沿って複数のチャンクに分割することですが、若干複雑です。例えば、単一のテンソルとして独立した入力のバッチがある場合が挙げられます。次元バッチに沿った任意の分割が可能であり、次元の目的によって可能である場合は、複数の推論を実行します。いくつかの事前コンパイルされたモデルでこのアプローチを使用し、推論の数が最小限になるようにサイズ設定された入力を選択して、入力テンソルで特定のバッチサイズを持つようにします。
例えば、バッチサイズ 1、2、4 および 8 用に事前コンパイルされたモデルがある場合、バッチ 5 の入力テンソルは、バッチサイズ 1 と 4 の 2 つの推論呼び出しで処理できます (この時点では、パフォーマンス上の理由からバッチ処理が必要であると想定されています。他の場合は、バッチ内の画像をループし、単一のコンパイル済みモデルを使用して画像ごとに処理します。)