CPU上でのBERT推論のスケーリング (Part 1)

Hugging Faceは、最新のCPU上でBERTのようなモデルの推論をスケーリングするための手法を詳細に説明しており、特定の物理CPUコアにバインドされた複数の独立したモデルインスタンスをデプロイすることで、最大のスループットが達成されることを示しています。このアプローチは、同時マルチスレッディング (SMT) やソケット間通信のオーバーヘッドを回避し、スループットにおけるほぼ線形なスケーラビリティを実現します。

フレームワークの標準的なパフォーマンス

AWS c5.metal インスタンス (Intel Xeon Platinum 8275 CPU, 48 cores/96 threads) で実施された初期ベンチマークでは、さまざまな構成において、PyTorch (1.8.1) が Google TensorFlow (2.4.1) よりも BERT 推論において一般的に優れたパフォーマンスを発揮することが示されています。このパフォーマンスの差は、基盤となる実行技術に起因します。PyTorch は OpenMP と Intel MKL (oneDNN) を利用し、TensorFlow は Eigen と独自の threading 実装に依存しています。

CPU アーキテクチャとスレッドアフィニティ

主に汎用行列乗算 (GEMMs) で構成される BERT 推論のような CPU 負荷の高いタスクを最適化するには、特定のハードウェアに関する考慮事項が必要です。

Simultaneous Multi-Threading (SMT)

SMT (または Hyper-Threading) は、2つのソフトウェアスレッドが単一の物理コアを共有することを可能にします。しかし、BERT 推論は CPU 負荷が高いため、論理コアが同じ実行リソースを奪い合います。つまり、SMT はパフォーマンスの向上をもたらさず、物理コアのみを使用するように回避すべきです。

NUMA とソケット管理

最新のマルチソケットサーバーは Non-Uniform Memory Access (NUMA) を使用しており、各 CPU ソケットは独自のメモリサブセットを管理しています。ソケット間通信のオーバーヘッドによるパフォーマンス低下を防ぐために、プロセスは numactl のようなツールを使用して、特定のコアとメモリプールにバインドする必要があります。

主要な構成戦略:

  • Thread Affinity: プロセスを特定の物理コアのセットにバインドすること (例: numactl -C 0-47)。
  • Memory Allocation: 計算を実行するコアに最も近いソケットにメモリが割り当てられるようにすること (例: numactl -m 0,1)。

コア数スケーリング vs. マルチストリーム推論

推論のリソースをスケーリングするための主な方法は 2 つあり、それぞれレイテンシとスループットに異なる影響を与えます。

コア数スケーリング (Strong Scaling)

これは、レイテンシを低減するために単一のタスクに割り当てられるコアの数を増やすことを含みます。このアプローチの有効性は、問題のサイズに依存します:

  • 小規模から中規模の問題: 単一のソケットを使用するのが、多くの場合、最高のパフォーマンスをもたらします。
  • 大規模な問題: ソケット間通信のオーバーヘッドは計算コストによって相殺されるため、両方のソケットにわたる利用可能なすべてのコアを使用することが有益です。

マルチストリーム推論 (Instance Parallelism)

1つのインスタンスに多くのコアを割り当てる代わりに、この方法は、それぞれが物理コアの重複しないサブセットにバインドされた複数の独立したモデルインスタンスを割り当てます。

例えば、4 つの独立したインスタンスをそれぞれ 12 コアにバインドして実行すると、単一のインスタンスに 24 コアを割り当てる場合と比較して、個々のレイテンシはわずかに増加しますが、全体の スループットは 4 倍に増加します。これにより、異なるシーケンス長に合わせて調整された特定のインスタンスにリクエストをルーティングする「スマートディスパッチング」が可能になります (例: 短いシーケンスには 8 コア、長いシーケンスには 24 コア)。

バッチサイズスケーリングとスループット

バッチサイズスケーリングは、グローバルバッチ $B$ を $N$ 個のインスタンスに分割し、各インスタンスが $C/N$ コア上で $B/N$ のサブバッチを処理することを指します。

レイテンシとスループットのトレードオフ

  • Latency: バッチ全体のレイテンシは、プール内の最も遅いインスタンスによって決定されます。レイテンシを最小限にするための最適なインスタンス数は、問題のサイズによって異なります。バッチサイズ 8、シーケンス長 128 の場合、4 つのインスタンス (各々がバッチサイズ 2、12 コアを使用) が最良の結果をもたらしました。
  • Throughput: インスタンスを増やし続ける限り、ワークロードが各インスタンスに比例して削減されるのであれば、スループットはほぼ線形にスケールします。これは、最適なハードウェア利用率を示しています。

ハードウェア最適化の影響のまとめ

スレッドアフィニティとインスタンス割り当てを正しく調整することで、組織はインフラストラクチャのコストを大幅に削減できます。Hugging Face は、特定のワークロードにおいて、48 コアのマシン ($4.848/h) から 8 コアのインスタンス ($0.808/h) に移行することで、問題のサイズが最適なレイテンシのために追加のコアを必要としない場合、6 倍のコスト削減が可能であることを指摘しています。

Sources