モダンなCPU上でのBERTライクモデルの推論のスケーリングアップ – パート2

モダンなCPU上でのBERTライクモデルの推論のスケーリングアップ - Part 2

イントロダクション：CPU上でのAI効率を最適化するためのIntelソフトウェアの使用

前のブログ記事で詳細に説明したように、Intel Xeon CPUは、AVX512やVNNI（Vector Neural Network Instructions）などのAIワークロードに特に設計された機能を提供しており、整数量子化されたニューラルネットワークを使用した効率的な推論をサポートするための追加のシステムツールも提供しています。このブログ記事では、ソフトウェアの最適化に焦点を当て、Intelの新しいIce Lake世代のXeon CPUのパフォーマンスについて紹介します。私たちの目標は、Intelのハードウェアを最大限に活用するためにソフトウェア側で利用可能なものをすべて紹介することです。前のブログ記事と同様に、ベンチマークの結果とグラフとともに、これらのツールと機能を簡単に使用できるようにします。

4月にIntelは最新のIntel Xeonプロセッサ、コードネームIce Lakeを発売しました。これはより効率的で高性能なAIワークロードをターゲットにしています。具体的には、Ice Lake Xeon CPUは、以前のCascade Lake Xeonプロセッサと比較して、さまざまなNLPタスクで最大75%高速な推論が可能です。これは、新しいSunny Coveアーキテクチャ上での新しい命令やPCIe 4.0のようなハードウェアおよびソフトウェアの改善の組み合わせによって実現されています。最後になりますが、Intelは、IntelのExtension for Scikit Learn、Intel TensorFlow、Intel PyTorch Extensionなどのように、さまざまなフレームワークに対して特化した最適化を行っています。

これらの機能は、データサイエンティストや機械学習エンジニアが日常的に使用するツールセットのスタックの非常に低いレベルにあります。ほとんどの場合、PyTorchやTensorFlowなどの高レベルのフレームワークやライブラリを使用して多次元配列の操作を処理し、BLAS（Basic Linear Algebra Subroutines）などの高度にチューニングされた数学演算子を使用することが一般的です。

この領域では、IntelはoneAPIの下でソフトウェアコンポーネントを提供することで重要な役割を果たしており、Intel oneMKL（Math Kernel Library）を介して高効率な線形代数ルーチンを非常に簡単に使用できるようにしています。さらに、Intel OpenMPやThreading Building Blocks（oneTBB）を使用した高レベルの並列化フレームワークや、Intel oneDNNを使用したディープニューラルネットワークプリミティブ（ReLU、完全接続など）やoneCCLを使用した集合通信など、一部の特定のドメイン向けライブラリも提供しています。特に複数のホスト上で効率的なオールリデュース操作にアクセスする際に特に有用です。

• 🤗 Transformersを使用して、低リソースASRのためにXLSR-Wav2Vec2を微調整する
• IPUを使用したHugging Face Transformersの始め方と最適化について
• スノーボールファイト ☃️をご紹介しますこれは私たちの最初のML-Agents環境です

MKLやoneDNNなどのこれらのライブラリは、PyTorchやTensorFlow（2.5.0以降）などのフレームワークにネイティブに組み込まれており、パフォーマンスの改善がユーザーに提供されています。特定のハードウェア機能をターゲットにしたい場合、Intelは最も一般的なソフトウェアのカスタムバージョンを提供しており、Intelプラットフォーム向けに特化した高度にチューニングされたフレームワークやIntel PyTorch Extension（IPEX）フレームワークなどがあります。

詳細：高度なIntelの機能を活用してAIのパフォーマンスを向上させる

パフォーマンスチューニングツール

上記で強調したように、AIアプリケーションのパフォーマンスを向上させるための新しい調整可能な項目セットについて説明します。高レベルの視点から見ると、すべての機械学習およびディープラーニングフレームワークは、同じ要素で構成されています：

1. メモリ内でデータを構造化する方法（ベクトル、行列など）
2. 数学演算子の実装
3. ターゲットハードウェア上での計算の効率的な並列化

上記のポイントに加えて、ディープラーニングフレームワークでは、勾配を計算するためにデータフローや依存関係を表現する方法も提供されています。これはこのブログ記事の範囲外であり、上記でリストアップしたコンポーネントと同じものを活用しています！

図1. oneAPIアンブレラの下でのIntelライブラリの概要

1. メモリ割り当てと管理のためのライブラリ

このブログ記事では、データの表現については特定のフレームワークに依存するため、意図的にスキップします。参考までに、PyTorchはATenと呼ばれる独自の実装を使用しています。一方、TensorFlowはこの目的にオープンソースライブラリEigenを使用しています。

異なるオブジェクト構造やレイアウトに対して一般的な最適化を適用するのは非常に複雑ですが、影響を与えることができる領域があります：メモリ割り当てです。ここでのメモリ割り当ては、mallocやC++のnew演算子など、プログラムによってオペレーティングシステムに動的な（事前には分からない）領域を要求し、そこにアイテムを保存できるようにするプロセスを指します。メモリの効率性は、速度だけでなく断片化の観点でも大きな科学的およびエンジニアリングの課題であり、タスクと基盤となるハードウェアによって異なる複数の解決策が存在します。過去数年間、この領域でさまざまな取り組みが行われており、特に次のようなものがあります：

• jemalloc（Facebook – 2005）
• mimalloc（Microsoft – 2019）
• tcmalloc（Google – 2020）

それぞれがさまざまなソフトウェアのメモリ割り当てと管理の改善を目指して異なるアプローチを進めています。

2. 計算の効率的な並列化

データを効率的に表現する方法があることを考えると、私たちは利用可能な計算ハードウェアの最大限の利用をする方法が必要です。興味深いことに、推論に関しては、CPUはどこにでも存在し、特定のアプリケーションコンポーネントや管理スタッフを必要としません。

現代のCPUには多くのコアとソフトウェアの全般的な性能を向上させるための複雑なメカニズムが備わっています。しかし、最初のブログ記事でも強調したように、それらはターゲットとするワークロードの種類（CPUボンドまたはI/Oボンド）に応じて調整できる機能も持っており、アプリケーションのパフォーマンスをさらに向上させることができます。

ただし、並列アルゴリズムを実装することは、単により多くのコアを投入して作業を行うことほど簡単ではありません。使用されるデータ構造、並列データアクセス、CPUキャッシュの無効化など、多くの要因があり、これらがアルゴリズムの効果的な高速化を妨げる可能性があります。関連するトークとして、興味がある場合はScott Meyersの「CPUキャッシュとなぜ気にする必要があるのか」をおすすめします。

幸いなことに、このような並列アルゴリズムの開発プロセスを容易かつエラーの少ないものにするためのライブラリがあります。最も一般的な並列ライブラリには、OpenMPとTBB（Threading Building Blocks）があります。これらは、C/C++のプログラミングAPIから環境変数の調整や動的スケジューリングまで、さまざまなレベルで機能します。Intelハードウェアでは、Intel oneAPIツールキットの一部として提供されるIntelのOpenMP仕様の実装である”IOMP”を使用することをお勧めします。

図2. OpenMPを使用した並列計算を示すコードスニペット

3. 最適化された数学演算子

効率的なデータ構造と並列アルゴリズムの設計に必要な構成要素をすでにカバーしましたが、残る最後の要素は計算を実行する要素です。これは、さまざまな数学演算子とニューラルネットワークレイヤーを実装し、私たちが最も好きなこと、ニューラルネットワークの設計を行うものです！ 😊

プログラマのツールキットには、数学演算のサポートをもたらす複数のレベルがあります。これらは、使用されているデータストレージレイアウト（連続メモリ、チャンク、パックなど）、各スカラー要素を表すデータ形式（Float32、Integer、Long、Bfloat16など）、そしてもちろん、プロセッサがサポートしているさまざまな命令など、さまざまな要因に応じて異なる最適化方法があります。

現在では、ほとんどのプロセッサがスカラーアイテム（一度に1つのアイテム）またはベクトル化モード（同じCPU命令内で複数のアイテムで操作することを意味するSIMD「Single Instruction Multiple Data」）で基本的な数学演算をサポートしています。有名なSIMD命令セットには、SSE2、AVX、AVX2があり、最新世代のIntel CPUでは1つのCPUクロック内で16バイトのコンテンツを操作できます。

ほとんどの場合、ベクトル間の要素ごとの単純な加算を実行するために生成されるアセンブリについて心配する必要はありませんが、もし心配なら、CPU固有のイントリンシックを呼び出すコードを記述するよりもさらに高いレベルに進むことができるライブラリもあります。これは、例えばIntelのMKL（Math Kernel Library）が提供しているものであり、基本的な線形代数のためのすべての基本演算を実装するための有名なBLAS（Basic Linear Algebra Subroutines）インターフェースとともに提供されています。

さらに、ドメイン固有のライブラリとして、IntelのoneDNNがあります。これは、ニューラルネットワークレイヤーを実装するために必要な最も一般的で基本的なブロックを提供します。 Intel MKLとoneDNNは、PyTorchフレームワークにネイティブに統合されており、Linear + ReLUやConvolutionなどの特定の操作のパフォーマンスを向上させることができます。 TensorFlowの場合、oneDNNは環境変数TF_ENABLE_ONEDNN_OPTS=1（TensorFlow>= 2.5.0）を設定することで、同様の機能を利用できます。

最新のIntel Ice Lake CPUにおけるより効率的なAI処理

Ice Lake製品ラインアップのパフォーマンスを報告するために、このシリーズの最初のブログ記事で使用した方法論を厳密に追います。リマインダーとして、この2番目のブログ記事を通じて強調するさまざまなセットアップをベンチマークするために、まったく同じスキーマを採用します。具体的には、以下のセクションで紹介される結果は、次のものに基づいています：

• PyTorch: 1.9.0
• TensorFlow: 2.5.0
• バッチサイズ: 1, 4, 8, 16, 32, 128
• シーケンス長: 8, 16, 32, 64, 128, 384, 512

提案された最適化のパフォーマンスを確立するために、フィールドで受け入れられているメトリクスによって結果を示します：

• レイテンシ: モデルを介して単一の推論リクエスト（つまり、「フォワードコール」）を実行するのにかかる時間（ミリ秒で表される）。
• スループット: 定義された期間内にシステムが維持できる推論リクエスト（つまり、「フォワードコール」）の数（コール/秒で表される）。

また、最初のブログ記事で強調した異なる最適化をすべて適用した初期ベースラインと、ボックスから出力される結果を示します。すべては、Ubuntu 20.04.2 LTS上で動作するIce Lake Xeon Platinum 8380 CPUを搭載したIntelの提供するクラウドインスタンスで実行されました。

同じプロセッサは、さまざまなクラウドプロバイダーにもあります：

• AWS m6i / c6i インスタンス
• Azure Ev5 / Dv5 シリーズ

図3. Intel Ice Lake Xeon 8380 の仕様

ベースラインの確立

先に述べたように、ベースラインは2つの異なるセットアップで構成されます： – ボックスから出力: チューニングなしでワークロードを実行しています。 – 最適化: ブログ記事1で強調したさまざまなツマミを適用します。

また、前のブログ記事へのコメントから、ベンチマーク結果内でフレームワークを表示する方法を変更したいと考えました。したがって、この2番目のブログ記事の残りの部分では、次のようにフレームワークのベンチマーク結果を分割します：

• 計算に「イーガーモード」を使用するフレームワーク（PyTorch、TensorFlow）
• 計算に「グラフモード」を使用するフレームワーク（TorchScript、TensorFlow Graph、Intel Tensorflow）

ベースライン：イーガーフレームワークのレイテンシ

イーガーモードで動作するフレームワークは、実際のグラフを実行しながらそのグラフを発見します。具体的には、実際の計算グラフは事前にはわかっておらず、次のオペレータを順次（イーガーモードで）実行し、次のオペレータの入力になるなどの手順を進めていきます。これにより、出力ノードに到達するまで続けられます。

これらのフレームワークは、実装するアルゴリズムにより柔軟性を提供しますが、実行時のオーバーヘッドが増加し、バックワードパスのために必要なすべての要素を追跡するためにわずかに多くのメモリ使用量が発生する可能性があります。

さらに、イーガーフレームワークでは、オペレータの融合などのグラフ最適化を有効にすることが通常はより困難です。たとえば、Convolution + ReLUの最適化されたカーネルを持つoneDNNなどの多くのディープラーニングライブラリでは、実際にグラフを実行する前に、このパターンが操作のシーケンス内に発生することを事前に知る必要がありますが、イーガーフレームワークではデザイン上不可能なことです。

図4. PyTorch のレイテンシ（コア数に対する）

図5. GoogleのTensorFlowのレイテンシ（コア数に対する）

図6. oneDNNを有効にしたGoogleのTensorFlowのレイテンシ（コア数に対する）

図7. IntelのTensorFlowのレイテンシ（コア数に対する）

全体的な傾向は、コア数が観測されるレイテンシに与えるポジティブな影響を示しています。ほとんどの場合、コア数を増やすと、さまざまなワークロードサイズにおいて計算時間が減少します。ただし、タスクによっては、コア数を増やすことによるレイテンシの低下が一貫してではなく、常にジョブの実行に割り当てるリソースの数とのトレードオフが存在します。

上記のグラフでわかるように、CPUが1つ以上（1つ以上のソケット）あるシステムで利用可能なすべてのコアを使用すると、非常に一般的なパターンが現れる傾向があります。ソケット間の通信は、大幅なレイテンシのオーバーヘッドを導入し、全体的なレイテンシの改善に対してほとんどの利益をもたらしません。

また、このソケット間の通信オーバーヘッドは、ワークロードが大きくなるにつれて感じられにくくなる傾向があり、すべての計算リソースの利用は、すべての利用可能なコアを使用することで利益をもたらします。この領域では、PyTorch（図1）とIntel TensorFlow（図4）がわずかに優れた並列性サポートを持っているように思われます。シーケンス長384および512では、すべてのコアを使用すると観測されるレイテンシがまだ低下します。

ベースライン：グラフフレームワークの遅延

今回は、グラフが事前に完全に分かっており、グラフの剪定や演算子の統合などの割り当てと最適化が行える「グラフ」モードでフレームワークを使用した場合のパフォーマンスを比較します。

図8. TorchScriptの遅延と関与するコアの数に関するもの

図9. GoogleのTensorFlowの遅延と関与するコアの数に関するもの

図10. oneDNNを有効にしたGoogleのTensorFlowの遅延と関与するコアの数に関するもの

図11. IntelのTensorFlowの遅延と関与するコアの数に関するもの

これは一般的に「グラフのトレーシング」と呼ばれ、ここで見られるように、結果はTorchScript（PyTorchのグラフ実行モード）vs TensorFlow(s)とはそれほど異ならないことがわかります。すべてのTensorFlowの実装は、並列化が制限されている場合（演算間の計算に関与するコアの数が少ない場合）、TorchScriptよりも優れたパフォーマンスを発揮するようですが、計算リソースを増やすと効率的にスケーリングされないようです。一方、TorchScriptはモダンなCPUのパワーをより効果的に活用できるようです。

それにもかかわらず、これらのフレームワーク間の差はほとんどの場合非常に限られています。

メモリアロケータの調整：観測される遅延に影響を与える可能性がありますか？

メモリを動的に割り当てるすべてのプログラムが依存する重要なコンポーネントは、メモリアロケータです。C/C++プログラミングに精通していれば、このコンポーネントはmalloc/freeやnew/deleteの下位ビットを提供します。ほとんどの場合、あまり心配する必要はなく、デフォルトのもの（たとえばほとんどのLinuxディストリビューションでのglibc）は、初期設定で優れたパフォーマンスを提供します。それにもかかわらず、いくつかの状況では、最も効率的なパフォーマンスを提供しない場合があります。これらのデフォルトのアロケータは、ほとんどの場合、ほとんどの場合に「良い」ものであるように設計されており、特定のワークロードや並行性に合わせて細かく調整されていません。

では、代替案は何であり、デフォルトのものよりも適しているのはいつでしょうか？まあ、やはり、ソフトウェアの周りの文脈に依存します。

可能な状況には、時間の経過に伴って断片化を引き起こす多数の割り当て/解放、ソフトウェアを実行している特定のハードウェアやアーキテクチャ、およびアプリケーションの並列性のレベルがあります。

ここまで来ましたね。ディープラーニングやそれに伴う重い計算を行うアプリケーションは、非常にマルチスレッドです。これは、PyTorch、TensorFlow、および他の機械学習ワークロードを対象としたソフトウェアライブラリの場合も同様です。

デフォルトのメモリアロケータ戦略は、しばしば同期プリミティブの使用を必要とするグローバルメモリプールに依存しており、システム全体の負荷を増加させ、アプリケーションのパフォーマンスを低下させます。Google、Facebook、Microsoftなどの企業による最近の研究では、カスタムメモリアロケータライブラリに実装された代替のメモリアロケーション戦略が提供されており、ソフトウェアコンポーネントに直接統合するか、動的共有ライブラリのプリロードを使用してアロケーション/解除のために使用されるライブラリを切り替えることができます。

これらのライブラリの中には、tcmalloc、jemalloc、mimallocなどがあります。

図12. 異なるタスクでベンチマークされたさまざまなメモリアロケータ

このブログ投稿では、tcmallocとjemallocをメモリアロケータの候補としてベンチマークすることに焦点を当てます。結果の範囲では、Ubuntuディストリビューションのバージョン2.9で利用可能なgperftoolsパッケージの一部としてtcmallocを使用し、jemalloc 5.1.0-1を使用しました。

メモリアロケータのベンチマーク

再び、イーガーモードで実行するフレームワークとのパフォーマンスを比較します。これは、アロケータが最も大きな役割を果たす可能性のある使用ケースです：グラフが実行前には不明であり、各フレームワークは実際のノードの実行時に必要なメモリを管理する必要があります。事前に計画することはできません。この文脈では、アロケータはメモリを割り当てて回収するためのすべてのシステムコールに対して主要なコンポーネントです。

図13. PyTorchのメモリアロケータとコアのスケーリング遅延

図14. GoogleのTensorFlowのメモリアロケータとコアのスケーリング遅延

図15. oneDNNを有効にしたGoogleのTensorFlowのメモリアロケータとコアのスケーリング遅延

図16. IntelのTensorFlowのメモリアロケータとコアのスケーリング遅延

上記のグラフからわかるように、標準ライブラリのアロケータ（glibc）は、パフォーマンスの面ではしばしば遅れていますが、合理的なパフォーマンスを提供しています。jemallocアロケータは、特定の状況では最速ですが、その理由はこのブログの範囲外ですが、Facebook Engineeringブログを読んで詳細を知ることができます。

最後に、ここでベンチマークされた全てのワークロードに対して、一般的に最も優れたパフォーマンスを提供するのはtcmallocのようです。再び、tcmallocはJemallocとは異なるアプローチを取っており、特に各スレッドごとにメモリセグメントのプールをローカルに維持することで、グローバルで排他的なクリティカルパスを持つ必要性を低減しています。

詳細については、Google Abseilチームによるフルブログをご覧いただくことをおすすめします。

さて、全体の計算グラフを全知的に持つベンチマークフレームワークであるグラフモードに戻りましょう。

図17. TorchScriptメモリアロケータとコアスケーリングレイテンシ

図18. GoogleのTensorFlowメモリアロケータとコアスケーリングレイテンシ

図19. GoogleのTensorFlowのoneDNNを有効にしたメモリアロケータとコアスケーリングレイテンシ

図20. Intel TensorFlowメモリアロケータとコアスケーリングレイテンシ

今回は、演算子フローと関与する行列の形状の基礎構造を知ることで、フレームワークは必要なリソースを事前に計画・予約することができます。この文脈では、上記のチャートに示されているように、フレームワーク間の違いは非常に小さく、jemallocとtcmallocの間には明確な勝者はありません。もちろん、glibcは汎用のメモリアロケータとしてはまだわずかに遅れていますが、それはイーガーセットアップよりも有意義なマージンではありません。まとめると、メモリアロケータのチューニングは、トレースされた計算グラフを既に使用している場合に特に、最適化プロセスの最後のミリ秒の改善を手に入れるための興味深いアイテムを提供することができます。

OpenMP

前のセクションでは、主にCPUバウンドのワークロードを含む機械学習ソフトウェア内のメモリ管理について話しました。このようなソフトウェアは、一般的にPyTorchやTensorFlowなどの中間フレームワークに依存しており、これらは通常、下層の高度に並列化された演算子の実装を抽象化しています。

このような高度に並列化され最適化されたアルゴリズムを記述することは、真のエンジニアリングの課題であり、CPUによって操作される実際の要素すべての非常に低レベルな理解を必要とします（同期、メモリキャッシュ、キャッシュの有効性など）。この文脈では、強力なアルゴリズムを実装するためのプリミティブを活用できることが非常に重要です。これにより、全てをゼロから実装する場合と比べて、デリバリータイムと計算時間を大幅に短縮することができます。

アルゴリズムの開発を加速するためのこのような高レベルの機能を提供する多くのライブラリが利用可能です。最も一般的なものの中には、OpenMP、Thread Building Blocks、および最新バージョンのC++をターゲットにして直接使用する方法があります。このブログ記事の以下の部分では、OpenMPに制限して、GNUのオープンソースでコミュニティベースの実装と、インテルのOpenMPを特に比較します。後者は特にインテルCPUを対象としており、GNU OpenMPとの置き換えとして最高のパフォーマンスを提供するように最適化されています。

OpenMPは、計算に関与する基盤リソースを自動的に構成するために多くの環境変数を公開しています。これには、計算をディスパッチするために使用するスレッド数（イントラスレッド）、システムスケジューラが各スレッドをCPUリソースに関連付ける方法（スレッド、コア、ソケット）などが含まれます。インテルのOpenMPは、より多くの環境変数を公開して、ユーザーがソフトウェアのパフォーマンスを調整するためのさらなる柔軟性を提供します。

図21. OpenMP vs Intel OpenMPのPyTorch実行時のレイテンシ

図22. OpenMP vs Intel OpenMPのPyTorch実行時のレイテンシ

上記のように、OpenMPのチューニングは、他のシステム関連のチューニングツールをすべて試してみた後に微調整を始めることができるものです。単一の環境変数の設定だけでモデルの最終的な高速化をもたらすことができます。

また、OpenMPライブラリのチューニングは、内部でOpenMP APIを使用するソフトウェア内でのみ機能します。具体的には、現時点ではPyTorchとTorchScriptのみがOpenMPを使用しており、OpenMPバックエンドのチューニングの恩恵を受けています。

これが、私たちがこれらの2つのフレームワークに対してのみレイテンシを報告した理由です。

自動パフォーマンスチューニング：Intel SigOptによるベイジアン最適化

前述のように、Intel CPU上でのレイテンシとスループットを改善するためには多くのツマミがありますが、最適なパフォーマンスを得るためにはすべてを調整するのは手間がかかります。例えば、私たちの実験では、次のツマミを調整しました：

• コアの数：持っているだけ多くのコアを使用することは良いアイデアですが、常に最高のパフォーマンスを提供するわけではありません。なぜなら、それは異なるスレッド間のより多くの通信を意味するからです。さらに、より少ないコアでより良いパフォーマンスを実現することは非常に便利であり、複数のインスタンスを同時に実行することができるため、レイテンシとスループットの両方が向上します。
• メモリアロケータ：デフォルトのmalloc、Googleのtcmalloc、Facebookのjemallocのうち、どのメモリアロケータが最高のパフォーマンスを提供するのか？
• 並列処理ライブラリ：GNU OpenMPとIntel OpenMPのうち、どの並列処理ライブラリが最高のパフォーマンスを提供するのか？
• Transparent Huge Pages：システムでTransparent Huge Pages（THP）を有効にすることで、パフォーマンスが向上するのか？
• KMPブロック時間パラメータ：並列領域の実行が完了した後、スレッドが待機する時間（ミリ秒単位）を設定します。

もちろん、すべての可能性を試して最適な性能を得るためのツマミの値を提供する、ブルートフォースアプローチは最適ですが、検索空間のサイズがN x 3 x 2 x 2 x 2 = 24Nであるため、時間がかかることがあります。例えば、80個の物理コアを持つマシンでは、最大24 x 80 = 1920の異なるセットアップを試すことになります！ 😱

幸いにも、IntelのSigOptはベイジアン最適化を通じて、これらのチューニング実験をより速く、より便利に分析できるようにしてくれます。また、ブルートフォースアプローチと同様の性能を提供します。

SigOptが提供する最適なレイテンシーと絶対的に最高のレイテンシーとの相対的な差を分析すると、ブルートフォースよりも優れた性能であることがわかります（特定のケースではシーケンス長=512を除いて）。この図では、最大のギャップは8.6%です。

図23. SigOpt自動チューニングによる絶対最高のレイテンシーとブルートフォース

図24. SigOpt自動チューニングによる相対最高のレイテンシーとブルートフォース

SigOptは分析にも非常に便利です。最も優れた値、対応するツマミ、トライアルの履歴、およびトライアルが進むにつれてどのように改善されたかといった情報を提供してくれます。例えば、シーケンス長=20の場合：

図25. SigOptの最適な値レポート

図26. SigOptの最適な値レポート

この特定の設定では、16個のコアとその他のツマミが最良の結果をもたらしました。これは非常に重要なことです。なぜなら、モデルの複数のインスタンスを並列に実行しても、それぞれの最適なレイテンシーを得ることができるからです。

また、約20回のトライアルで収束したことも示しています。つまり、40回ではなく25回のトライアルでも十分だったかもしれません。パラメータの重要度など、さまざまな貴重な情報が利用可能です。

予想通り、コアの数が最も重要なパラメータであることがわかりますが、他のパラメータも重要な役割を果たし、実験に依存します。例えば、シーケンス長=512の実験では、次のようなパラメータの重要度がありました：

図27. バッチサイズ=1、シーケンス長=20のSigOpt最適値

図28. バッチサイズ=1、シーケンス長=512のSigOpt最適値

ここでは、アロケータの影響よりもOpenMP vs Intel OpenMPの影響が大きかったです。また、シーケンス長=20の実験よりも、各ツマミの相対的な重要性がバランスしています。SigOptでは、対話型を含むさまざまな図が利用可能です。たとえば：

• ツマミ対ツマミまたはツマミ対目的といった2Dの実験履歴
• ツマミ/目的に対して1つ以上のツマミを使用した2Dの実験履歴と同様のことを行う3Dの実験履歴

結論 – トランスフォーマーの本番向け高速化

この記事では、新しいIntel Ice Lake Xeon CPUがAIワークロードを大規模に実行するために適していることを示しました。また、ハードウェアのフルポテンシャルを引き出すために、前のブログで詳細に説明したさまざまな下位レベルのツマミの設定後に考慮する必要があるソフトウェア要素についても説明しました。

Hugging Faceでは、最先端の機械学習を民主化する使命を掲げており、その一環として、これらの最先端モデルを可能な限り効率的にし、スケールでのエネルギーとメモリの使用量を減らし、すべての企業がより手頃な価格で実行できるようにすることが重要です。

🤗ハードウェアパートナープログラムを通じたIntelとの協力により、新しい🤗Optimumオープンソースライブラリを通じて、高効率化と最適化の技術をコミュニティに簡単に提供することが可能になりました。

トランスフォーマーモデルの推論を加速したい企業向けに、新しい🤗Infinity製品は、GPUで1ms、Intel Xeon Ice Lake CPUで2msのレイテンシーを実現するプラグアンドプレイのコンテナ化されたソリューションを提供しています。

もし、この投稿が興味深かったり、仕事に役立つと思われる場合は、Optimumにスターを与えることを検討してください。また、もし、この投稿があなたの耳にとっての音楽だった場合は、私たちの機械学習最適化チームへの参加を考えてみてください！

We will continue to update VoAGI; if you have any questions or suggestions, please contact us!