Hugging Face で最先端の モデルをスピードアップ 🤗 Databricks、Nvidia、Spark NLP で最大 2300% (25 倍高速) 🚀 ViT 私は オープンソース プロジェクトの貢献者の 1 人であり、つい最近、このライブラリがエンド ツー エンドの モデルのサポートを開始しました。私は毎日の仕事で Spark NLP やその他の ML/DL オープンソース ライブラリを使用しており、最先端の画像分類タスク用に ViT パイプラインを展開し、Hugging と の詳細な比較を提供することにしました。 Spark NLP Vision Transformers (ViT) Face Spark NLP この記事の目的は、Hugging Face から Vision Transformer (ViT) モデルをスケールアウトし、高速で高性能な推論のために実稼働環境にデプロイする方法を示すことです。最後に、Databricks、Nvidia、Spark NLP を使用して、Hugging Face の ViT モデルを スケーリングします。 25 倍 (2300%) この記事では、次のことを行います。 Vision Transformer (ViT) の簡単な紹介 CPU および GPU 上の Dell サーバー内のベンチマーク Hugging Face CPU および GPU 上の Dell サーバー内の Spark NLP のベンチマーク CPU および GPU 上の Databricks 単一ノード内のベンチマーク Hugging Face CPU および GPU 上の Databricks 単一ノード内の Spark NLP のベンチマーク CPU と GPU を使用して 10 倍のノードにスケーリングされた Databricks 内の Benchmark Spark NLP すべてをまとめてください！ 完全な透明性の精神で、ログ、スクリーンショット、さらには数値を含む Excel シートを含むすべてのノートブックが 提供されています。 GitHub で ビジョン トランスフォーマー (ViT) モデルの紹介 さかのぼること 2017 年、Google AI の研究者グループは、すべての自然言語処理 (NLP) 標準を変更する変換モデル アーキテクチャを紹介する論文を発表しました。この論文では、言語アプリケーションの新しいより効率的なモデルとして、自己注意と呼ばれる新しいメカニズムについて説明しています。たとえば、変圧器ベースのモデルで最も人気のある 2 つのファミリは、GPT と BERT です。 ちょっとしたトランスフォーマーの歴史 https://huggingface.co/course/chapter1/4 「 に関する素晴らしい章があります。興味がある場合は読むことを強くお勧めします。 トランスフォーマーの仕組み 」 これらの新しい Transformer ベースのモデルは NLP タスクに革命をもたらしているように見えますが、コンピューター ビジョン (CV) での使用はかなり制限されたままです。コンピューター ビジョンの分野は、畳み込みニューラル ネットワーク (CNN) の使用によって支配されており、CNN に基づく一般的なアーキテクチャ (ResNet など) があります。これは、今回 Google Brain の別の研究者チームが 2021 年 6 月に 」というタイトルの論文で (ViT) を紹介するまで当てはまりました 「 画像は 16x16 の言葉に値する: 大規模な画像認識のための変換器 「Vision Transformer」 。 このホワイト ペーパーは、先ほど説明した BERT や GPT などの変換器ベースのモデルで使用されているのと同じ自己注意メカニズムを使用することによる、画像認識に関するブレークスルーを表しています。 BERT のような Transformed ベースの言語モデルでは、入力は文 (単語のリストなど) です。ただし、ViT モデルでは、最初に画像をサブ画像パッチのグリッドに分割し、次に各パッチを線形プロジェクトに埋め込んでから、埋め込まれた各パッチをトークンにします。結果は、BERT と同様にモデルに渡す一連の埋め込みパッチです。 で紹介された ViT モデル構造の概要 Google Research の 2021 年のオリジナル論文 Vision Transformer は、より高い精度に重点を置いていますが、計算時間は短縮されています。この論文で公開されているベンチマークを見ると、精度の状態はほぼ同じであるにもかかわらず、 データセット (Google が 2020 年 6 月に公開) に対するトレーニング時間が 80% 短縮されていることがわかります。今日の ViT パフォーマンスの詳細については、 のページにアクセスして Noisy Student Papers With Code ください。 一般的な画像分類ベンチマークの最新技術との比較。 ( ) https://arxiv.org/pdf/2010.11929.pdf また、ViT アーキテクチャを介してモデルをトレーニングしたら、NLP で行うのと同じように、トランスフォーマーを事前トレーニングして微調整できることにも言及することが重要です。 （それは実際にはかなりクールです！） ViT モデルを CNN と比較すると、計算コストがはるかに低く、精度が高いことがわかります。画像の分類、オブジェクトの検出、画像のセグメンテーションなど、Computer Vision のさまざまなダウンストリーム タスクに ViT モデルを使用できます。これはヘルスケアのドメイン固有でもあり、 、 、 、 、 ViT モデルを事前トレーニング/微調整できます¹。 大腿骨骨折 肺気腫 乳がん COVID-19 アルツハイマー病の ViT モデルがどのように機能するかを深く掘り下げたい場合に備えて、この記事の最後に参考文献を残しておきます。 [1]: ディープ ダイブ: ハグ フェイス オプティマム グラフコアのビジョン トランスフォーマー https://huggingface.co/blog/vision-transformers 一部の ViT モデルの動作 ビジョン トランスフォーマー (ViT) モデル ( ) は、解像度 224x224 で ImageNet-21k (1400 万の画像、21,843 クラス) で事前トレーニングされ、ImageNet 2012 (100 万の画像、1,000 クラス) で微調整されています。解像度 224x224: vit-base-patch16–224 https://huggingface.co/google/vit-base-patch16-224 食品分類に使用される微調整された ViT モデル: — https://huggingface.co/nateraw/food https://huggingface.co/julien-c/hotdog-not-hotdog ただし、予測に関しては、DL/ML モデルには制限と制限があります。 100% の精度を持つモデルは存在しないため、ヘルスケアなどの重要な目的でモデルを使用する場合は注意してください。 https://www.akc.org/expert-advice/lifestyle/do-you-live-in-dog-state-or-cat-state/ — : https://huggingface.co /julien-c/hotdog-not-hotdog 画像は以下から取得: ViT モデル Hugging Face のこれらのモデルを使用したり、新しい ViT モデルを微調整して実際の生産での推論に使用したりできますか? AWS EMR、Azure Insight、GCP Dataproc、Databricks などの分散計算用のマネージド サービスを使用して、それらをどのようにスケーリングできますか? うまくいけば、これらのいくつかは、この記事の終わりまでに答えられるでしょう. ベンチマークを始めましょう！ ベンチマークに関する詳細: ImageNet mini: (>3K) — (>34K) 1- データセット: サンプル フル Kaggle から ImageNet 1000 (ミニ) データセットをダウンロードしました: https://www.kaggle.com/datasets/ifigotin/imagenetmini-1000 を含むトレイン ディレクトリを選択し、それを と呼びました。これは、時間がかかるベンチマークを実行するのに十分な画像が必要だったからです。さらに、全データセットの 10% 未満をランダムに選択し、それを と呼びました。これには、小規模なベンチマーク用の があり、バッチ サイズなどの適切なパラメーターを微調整することもできます。 34K を超える画像 imagenet-mini imagenet-mini-sample 3544 枚の画像 Google の「 」 2- モデル: vit-base-patch16–224 Hugging Face でホストされている Google のこのモデルを使用します: https://huggingface.co/google/vit-base-patch16-224 🤗 & 🚀 3- ライブラリ: Transformers Spark NLP ベアメタルサーバーでのHugging Faceのベンチマーク Dell PowerEdge C4130 の ViT モデル ベアメタル サーバーとは何ですか? は、1 人のユーザーのみが使用する単なる物理コンピューターです。このマシンにはハイパーバイザーはインストールされておらず、仮想化も行われておらず、すべてがメインの OS (Linux — Ubuntu) で直接実行されています。このマシンの CPU、GPU、およびメモリの詳細な仕様は、ノートブックの中にあります。 ベア メタル サーバー 私の最初のテストと、DL エンジン間の推論速度を比較した Hugging Face エンジニアリング チームによって書かれたほぼすべてのブログ投稿で明らかになったように、Hugging Face ライブラリ (Transformer) での推論の最高のパフォーマンスは、TensorFlow で PyTorch を使用することによって達成されます。これが、TensorFlow が Hugging Face の二流市民であることが原因かどうかはわかりません。これは、サポートされている機能、サポートされているモデルが少ない、例が少ない、チュートリアルが古い、および TensorFlow をもっと求めているユーザーから回答された過去 2 年間の年次調査のためです。または PyTorch は、CPU と GPU の両方で推論のレイテンシが低いだけです。 TensorFlow は依然として最も使用されているディープ ラーニング フレームワークです 理由はどうあれ、Hugging Face ライブラリの PyTorch を選択して、画像分類ベンチマークで最高の結果を得ることができました。これは、Hugging Face で ViT モデル (もちろん PyTorch) を使用するための単純なコード スニペットです。 from PIL import Image import requests from transformers import ViTFeatureExtractor, ViTForImageClassification url = 'http://images.cocodataset.org/val2017/000000039769.jpg' image = Image.open(requests.get(url, stream= True ).raw) feature_extractor = ViTFeatureExtractor.from_pretrained( 'google/vit-base-patch16-224' ) model = ViTForImageClassification.from_pretrained( 'google/vit-base-patch16-224' ) inputs = feature_extractor(images=image, return_tensors= "pt" ) outputs = model(**inputs) logits = outputs.logits # model predicts one of the 1000 ImageNet classes predicted_class_idx = logits.argmax(- 1 ).item() print("Predicted class:", model.config.id2label [predicted_class_idx] ) これは、画像を入力として予測するのは簡単に見えるかもしれませんが、大量の画像、特に GPU では適していません。画像を連続して予測することを避け、GPU などの高速化されたハードウェアを利用するには、Hugging Face で 経由で可能な画像のバッチをモデルに供給するのが最善です。言うまでもなく、Hugging Face のパイプラインを拡張するか、独自に行うことで、バッチ処理手法を実装できます。 パイプライン の単純なパイプラインは次のようになります。 画像分類 from transformers import ViTFeatureExtractor, ViTForImageClassification from transformers import pipeline feature_extractor = ViTFeatureExtractor.from_pretrained( 'google/vit-base-patch16-224' ) model = ViTForImageClassification.from_pretrained( 'google/vit-base-patch16-224' ) pipe = pipeline( "image-classification" , model=model, feature_extractor=feature_extractor, device=- 1 ) ドキュメントに従って、機能エクストラクタとモデル (もちろん PyTorch チェックポイント) 用に をダウンロード/ロードして、画像分類をタスクとしてパイプラインで使用しました。このパイプラインには、ベンチマークにとって重要な 3 つの要素があります。 google/vit-base-patch16–224 : -1 (デフォルト) の場合、CPU のみを使用しますが、正の整数の場合、関連付けられた CUDA デバイス ID でモデルを実行します (GPU を非表示にして、PyTorch に強制的に CPU を使用させるのではなく、CPU を使用させるのが最善です)ここではこの数に依存します)。 > device パイプラインが を使用する場合 (Pytorch モデルの GPU でデータセットを渡す場合)、推論に使用するバッチのサイズは必ずしも有益ではありません。 > batch_size: DataLoader GPU 上の Hugging Face パイプラインでバッチ処理を最大限に活用するには、DataLoader または PyTorch Dataset のいずれかを使用する必要があります。 > ベンチマークを進める前に、Hugging Face Pipelines の推論用バッチ処理に関して、常に機能するとは限らないことを知っておく必要があります。 Hugging Face のドキュメントに記載されているように、 を設定しても、パイプラインのパフォーマンスがまったく向上しない場合があります。パイプラインが遅くなる可能性があります。 batch_size https://huggingface.co/docs/transformers/main_classes/pipelines#pipeline-batching 公平を期すために、私のベンチマークでは、1 から始まる一連のバッチ サイズを使用して、その中から最良の結果を見つけられるようにしました。これは、CPU で Hugging Face パイプラインのベンチマークを行った方法です。 from transformers import pipeline pipe = pipeline( "image-classification" , model=model, feature_extractor=feature_extractor, device=- 1 ) for batch_size in [ 1 , 8 , 32 , 64 , 128 ]: print ( "-" * 30 ) print ( f"Streaming batch_size= {batch_size} " ) for out in tqdm(pipe(dataset, batch_size=batch_size), total= len (dataset)): pass サンプル (3K) ImageNet データセットに対する、CPU 上の Hugging Face 画像分類パイプラインの最初のベンチマークの結果を見てみましょう。 CPU 上のハグ顔画像分類パイプライン — 3544 画像を予測 ご覧のとおり、サンプル データセットから約 の処理を完了するのに約 3 分 ( かかりました。パイプライン/データセット/ハードウェアに最適なバッチ サイズ (8) がわかったので、このバッチ サイズでより大きなデータセット ( ) に対して同じパイプラインを使用できます。 3544 枚の画像 188 秒) 34K images CPU 上のハグ顔画像分類パイプライン - 34745 枚の画像を予測 今回は、CPU 上の のクラスの予測を完了するのに約 31 分 ( ) かかりました。 34745 枚の画像 1,879 秒 ほとんどのディープ ラーニング モデル、特にこれらの新しいトランスフォーマー ベースのモデルを改善するには、GPU などの高速化されたハードウェアを使用する必要があります。まったく同じデータセットでまったく同じパイプラインをベンチマークする方法を見てみましょうが、今回は デバイスで行います。前述のように、デバイスを 0 (最初の GPU) などの CUDA ID に変更する必要があります。 GPU デバイス model = model.to(device) from transformers import ViTFeatureExtractor, ViTForImageClassification from transformers import pipeline import torch device = "cuda:0" if torch.cuda.is_available() else "cpu" print (device) feature_extractor = ViTFeatureExtractor.from_pretrained( 'google/vit-base-patch16-224' ) model = ViTForImageClassification.from_pretrained( 'google/vit-base-patch16-224' ) pipe = pipeline( "image-classification" , model=model, feature_extractor=feature_extractor, device= 0 ) for batch_size in [ 1 , 8 , 32 , 64 , 128 , 256 , 512 , 1024 ]: print ( "-" * 30 ) print ( f"Streaming batch_size= {batch_size} " ) for out in tqdm(pipe(dataset, batch_size=batch_size), total= len (dataset)): pass device=0 の設定に加えて、.to(device) を介して GPU デバイスで PyTorch モデルを実行する推奨方法にも従いました。高速ハードウェア (GPU) を使用しているため、テストの最大バッチ サイズを 1024 に増やして、最良の結果を見つけました。 サンプルの ImageNet データセット (3K) に対する GPU デバイスでのハグ顔画像分類パイプラインを見てみましょう。 GPU でのハグ顔画像分類パイプライン — 3544 枚の画像を予測 ご覧のとおり、 で imagenet-mini-sample データセットから約 の処理を完了するのに約 かかりました。バッチ処理は特に CPU からの結果と比較して速度を改善しましたが、改善はバッチ サイズ 32 付近で止まりました。結果はバッチ サイズ 32 以降は同じですが、より大きなベンチマークを利用するためにバッチ サイズ を選択しました。 GPUメモリも十分。 GPU デバイス 3544 枚の画像 50 秒 256 GPU でのハグ顔画像分類パイプライン - 34745 枚の画像を予測 今回のベンチマークでは、 デバイス上の のクラスの予測を完了するのに約 8:17 分 ( ) かかりました。 CPU と GPU デバイスでのベンチマークの結果を比較すると、ここの GPU が勝者であることがわかります。 GPU 34745 枚の画像 497 秒 Hugging Face (PyTorch) は、CPU と比較して GPU で最大 3.9 倍高速です Hugging Face Pipelines を使用して ViT PyTorch チェックポイントをロードし、データをトーチ データセットにロードし、CPU と GPU の両方でモデルにすぐに使用できるバッチ処理を使用しました。 CPU で同じパイプラインを実行する場合と比較して、 は最大 高速です。 GPU 3.9 倍 CPU の代わりに を使用して画像分類を実行するように ViT パイプラインを しましたが、複数のマシンにスケールアウトする前に、単一のマシンで と の両方でパイプラインをさらに改善できますか? Spark NLP ライブラリを見てみましょう。 GPU デバイス 改善 CPU GPU Spark NLP: 最先端の自然言語処理 Spark NLP は、オープンソースの最先端の自然言語処理ライブラリです ( ) https://github.com/JohnSnowLabs/spark-nlp Spark NLP は、Apache Spark 上に構築された最先端の自然言語処理ライブラリです。分散環境で簡単に拡張できる機械学習パイプラインに、シンプルでパフォーマンスが高く正確な NLP アノテーションを提供します。 Spark NLP には、 による 7000 以上の トレーニング済み と が付属しています。また、トークン化、単語のセグメンテーション、品詞のタグ付け、単語と文の埋め込み、名前付きエンティティの認識、依存関係の解析、スペル チェック、テキストの分類、感情分析、トークンの分類、機械翻訳 (+180 言語)、要約と質問応答、テキスト生成、画像分類 (ViT)、その他多数の 。 200 以上の言語 事前 パイプライン モデル NLP タスク Spark NLP は、 、 、 、 、 、 、 、 、 、 、 、 などの最先端のトランスフォーマーを提供する、本番環境で唯一のオープンソース NLP ライブラリです。 、Google 、 、 、および Vision Transformer ( ) は、 および だけでなく、Apache Spark をネイティブに拡張することにより、大規模な JVM エコシステム ( 、 、および ) にも適用されます。 BERT CamemBERT ALBERT ELECTRA XLNet DistilBERT RoBERTa DeBERTa XLM-RoBERTa Longformer ELMO Universal Sentence Encoder T5 MarianMT GPT2 ViT Python R Java Scala Kotlin ベアメタル サーバーでの Spark NLP のベンチマーク Dell PowerEdge C4130 上の ViT モデル Spark NLP には、最近の リリースで追加された Hugging Face と同じ 用の ViT 機能があります。この機能は と呼ばれ、240 おり Spark NLP でこの機能を使用する簡単なコードは次のようになります。 4.1.0 画像分類 ViTForImageClassification を超える 事前トレーニング済みのモデル が用意されて 、 imageAssembler = ImageAssembler() \ imageClassifier = ViTForImageClassification \ pipeline = Pipeline(stages=[ imageAssembler, imageClassifier ]) from sparknlp.annotator import * from sparknlp.base import * from pyspark.ml import Pipeline .setInputCol( "image" ) \ .setOutputCol( "image_assembler" ) .pretrained( "image_classifier_vit_base_patch16_224" ) \ .setInputCols( "image_assembler" ) \ .setOutputCol( "class" ) \ .setBatchSize( 8 ) Spark NLP と Hugging Face を比較して、画像分類予測用の事前トレーニング済み ViT モデルのダウンロードと読み込みについて、画像の読み込みと Hugging Face ライブラリ外での argmax などの事後計算の使用を除けば、どちらも非常に単純です。また、両方を保存して、後でパイプラインとして機能させ、これらの行を 1 行のコードに減らすこともできます。 Spark NLP (左) と Hugging Face (右) での画像分類のための ViT モデルの読み込みと使用 Apache Spark には と呼ばれる概念があるため、 が呼び出されるまでプロセスの実行は開始されません。 Apache Spark のアクションは、.count()、.show()、または .write() などの多くの RDD ベースの操作であり、ここでは説明しません。この記事ではそれらについて知る必要はありません。私は通常、ターゲット列の count() またはディスク上の結果の write() のいずれかを選択して、DataFrame 内のすべての行の実行をトリガーします。また、Hugging Face ベンチマークと同様に、選択したバッチ サイズをループして、最良の結果を見逃さずにすべての可能な結果を得られるようにします。 Lazy Evaluation ACTION これで、Spark NLP で ViT モデルをロードする方法がわかりました。また、アクションをトリガーして、DataFrame のすべての行の計算をベンチマークに強制する方法もわかりました。あとは、 から oneDNN を学習するだけです。 。 Spark NLP の DL エンジンは TensorFlow であるため、oneDNN を有効にして CPU の速度を向上させることもできます (他のすべてと同様に、これをテストして、速度が向上し、逆ではないことを確認する必要があります)。 oneDNN が有効になっていない通常の CPU に加えて、このフラグも使用します。 oneAPI Deep Neural ネットワーク ライブラリ (oneDNN) Hugging Face のすべての ViT モデルが Spark NLP でも利用可能であり、パイプラインでそれらを使用する方法がわかったので、ベアメタルの Dell サーバーで以前のベンチマークを繰り返して、CPU と GPU を比較します。サンプル (3K) ImageNet データセットに対する、Spark NLP の画像分類パイプラインの CPU での結果を見てみましょう。 oneDNN を使用しない CPU での Spark NLP 画像分類パイプライン — 3544 枚の画像を予測 サンプル データセットから約 の処理を完了するのに、約 2.1 分 ( かかりました。より小さなデータセットでさまざまなバッチ サイズを試すことは、タスク、データセット、およびマシンに適したバッチ サイズを選択するのに役立ちます。ここで、 が、パイプラインが最良の結果を提供するための最適なサイズであることは明らかです。 3544 枚の画像 130 秒) バッチ サイズ 16 また、 を有効にして、この特定の状況で、oneDNN を使用しない CPU と比較してベンチマークが改善されるかどうかを確認したいと思います。 TF_ENABLE_ONEDNN_OPTS の環境変数を に設定することで、Spark NLP で を有効にできます。このフラグを有効にして、CPU で前のベンチマークを再実行し、最適なバッチ サイズを見つけるとどうなるか見てみましょう。 oneDNN 1 oneDNN oneDNN を使用した CPU 上の Spark NLP 画像分類パイプライン — 3544 枚の画像を予測 この特定の状況で TensorFlow に対して oneDNN を有効にすると、明らかに結果が少なくとも 14% 向上しました。何も変更する必要はなく、export TF_ENABLE_ONEDNN_OPTS=1 と言うだけなので、違いを確認するために、より大きなデータセットのベンチマークにも使用します。これは約数秒速いですが、より大きなデータセットの 14% で結果の数分を削減できます。 oneDNN を使用しない CPU のバッチ サイズ 16 と、oneDNN を有効にした CPU のバッチ サイズ 2 が最良の結果であることがわかったので、より大きなデータセット ( ) に対して同じパイプラインを使用し続けることができます。 34K images oneDNN を使用しない CPU での Spark NLP 画像分類パイプライン — 34745 枚の画像を予測 今回のベンチマークでは、oneDNN が有効になっていない デバイスで のクラスの予測を完了するのに約 24 分 ( ) かかりました。次に、TensorFlow に対して oneDNN を有効にし、バッチ サイズ 2 を使用するとどうなるかを見てみましょう (最良の結果)。 CPU 34745 枚の画像 1423 秒 oneDNN を使用した CPU での Spark NLP 画像分類パイプライン — 34745 枚の画像を予測 今回は約21分( )かかりました。サンプル ベンチマークから予想されるように、oneDNN を有効にしない場合と比較して、結果が約 されていることがわかります。 1278秒 11% 改善 GPU デバイスでまったく同じパイプラインをベンチマークする方法を見てみましょう。 Spark NLP で GPU を使用する必要があるのは、Spark NLP セッションを開始するときに gpu=True で開始することだけです。 火花 = sparknlp.start(gpu=True) # ここでもメモリを設定できます spark = sparknlp.start(gpu=True, memory="16g") それでおしまい！パイプラインに GPU で実行できるものがあれば、明示的に何もする必要なく自動的に実行されます。 サンプルの ImageNet データセット (3K) に対する GPU デバイス上の Spark NLP 画像分類パイプラインを見てみましょう。 GPU での Spark NLP 画像分類パイプライン — 3544 枚の画像を予測 小さなデータセットで適切なバッチ サイズを見つけるという私の十字軍が正しいかどうかを知りたいという好奇心から、大きなデータセットで GPU を使用して同じパイプラインを実行し、バッチ サイズ 32 が最良の結果をもたらすかどうかを確認しました。 GPU での Spark NLP 画像分類パイプライン — 34745 枚の画像を予測 ありがたいことに、バッチ サイズ 32 で最適な時間が得られます。つまり、約 4 分半 ( 277 秒) かかりました。 の結果の方が高速だったので、その結果を選び、それらを の結果と比較します。 oneDNN を使用した CPU GPU Spark NLP (TensorFlow) は GPU と CPU で最大 4.6 倍高速 (oneDNN) これは素晴らしい！ GPU 上の Spark NLP は、oneDNN が有効になっている場合でも、CPU よりも最大 であることがわかります。 4.6 倍高速 これらの結果が Hugging Face ベンチマークとどのように比較されるかを見てみましょう。 Spark NLP は、CPU 上の Hugging Face よりも、3K 画像を含むサンプル データセットの画像クラスを予測する際に 65% 高速であり、34K 画像を含むより大きなデータセットでは 47% 高速です。また、Spark NLP は、34K 画像を含む単一の GPU 推論のより大きなデータセットで Hugging Face よりも 79% 高速であり、より小さなデータセットでは最大 35% 高速です。 Spark NLP は、CPU または GPU のいずれかを使用して単一のマシンで Hugging Face よりも高速でした — Vision Transformer (ViT) を使用した画像分類 Databricks での Spark NLP と Hugging Face すべてのデータ、分析、AI を 1 つのプラットフォームに Databricks とは何ですか? Databricks は、大量のデータを処理および変換するために多くの企業で広く使用されている一連のデータ エンジニアリングおよびデータ サイエンス ツールを備えたクラウドベースのプラットフォームです。ユーザーは、大量のデータの処理と変換から、多くの ML/DL パイプラインを実行してデータを探索するまで、さまざまな目的で Databricks を使用します。 これは Databricks の私の解釈であり、他にも多くの機能が付属しており、それらを確認する必要があります: 免責事項: https://www.databricks.com/product/data-lakehouse Databricks は、AWS、Azure、および GCP クラウドをサポートしています: https://www.databricks.com/product/data-lakehouse AWS 上の CPU を使用した Databricks 単一ノードで顔を抱きしめる Databricks は、1 台のマシンのみで Apache Spark を使用するか、非 Spark アプリケーション、特に ML および DL ベースの Python ライブラリを使用する場合に適したクラスターを作成する場合に、 クラスター タイプを提供します。 Databricks 11.1 ML ランタイムを選択すると、Hugging Face が既にインストールされています。ベンチマークを開始する前の単一ノード Databricks (CPU のみ) のクラスター構成は次のようになります。 「単一ノード」 Databricks 単一ノード クラスター — CPU ランタイム で インスタンスを使用するこのクラスターの概要は、1 つのドライバー (1 つのノードのみ)、 のメモリ、 の CPU があり、1 時間あたり のコストがかかるということです。 AWS の「DBU」については、 ://www.databricks.com/product/aws-pricing でお読みいただけます。 AWS m5n.8xlarge 128 GB 32 コア 5.71 DBU https Databricks 単一クラスター — AWS インスタンス プロファイル 単一ノードの Databricks (CPU のみ) で、前のセクション (ベアメタル Dell サーバー) のベンチマークを複製してみましょう。 Hugging Face と ImageNet のサンプルサイズのデータセットから始めて、以前のベンチマークでたまたま実証済みのプラクティスであったため、より大きなデータセットに使用できる適切なバッチ サイズを見つけます。 Databricks シングルノード CPU での Hugging Face 画像分類パイプライン — 3544 枚の画像を予測 のみを使用する単一ノードの Databricks で、サンプル データセットから約 の処理を完了するのに、約 2 分半 ( ) かかりました。 CPU のみを使用するこのマシンでの最適なバッチ サイズは であるため、これを使用してより大きなデータセットでベンチマークを実行します。 CPU 3544 枚の画像 149 秒 8 Databricks シングルノード CPU での Hugging Face 画像分類パイプライン - 34745 枚の画像を予測 34K を超える画像を含む大規模なデータセットでは、これらの画像のクラスの予測を完了するのに約 20 分半 ( ) かかりました。次のベンチマークでは、単一ノードの Databricks クラスターが必要ですが、今回は GPU ベースのランタイムが必要で、GPU ベースの AWS インスタンスを選択する必要があります。 1233 秒 AWS で GPU を使用した Databricks 単一ノードで顔を抱きしめる 新しいクラスターを作成してみましょう。今回は GPU を備えたランタイムを選択します。この場合は 11.1 ML (Apache Spark 3.3.0、GPU、Scala 2.12 を含む) と呼ばれ、必要なすべての CUDA および NVIDIA ソフトウェアがインストールされています。次に必要なことは、GPU を備えた AWS インスタンスも選択することです。私は、1 つの GPU を備え、他のクラスターと同様の数のコア/メモリを備えた を選択しました。この GPU インスタンスには、 と 15 GB 使用可能な GPU メモリ)。 g4dn.8xlarge Tesla T4 16 GB メモリ ( Databricks 単一ノード クラスター — GPU ランタイム これは、前のクラスターと同様に、単一ノード クラスターの概要です。コア数とメモリ量は同じですが、Tesla T4 GPU が付属しています。 Databricks 単一ノード クラスター — AWS インスタンス プロファイル GPU を備えた単一ノード クラスターができたので、ベンチマークを続行して、Hugging Face が Databricks のこのマシンでどのように機能するかを確認できます。より小さいデータセットでベンチマークを実行して、どのバッチ サイズが GPU ベースのマシンにより適しているかを確認します。 Databricks 単一ノード CPU 上のハグ顔画像分類パイプライン - 3544 画像を予測 GPU デバイスを使用した単一ノードの Databricks クラスターで、サンプル データセットから約 の処理を完了するのに、約 1 分 ( ) かかりました。バッチ サイズ 1 の結果を見ると、バッチ処理によって速度が改善されましたが、バッチ サイズ 8 の後、結果はほとんど同じままでした。バッチ サイズ 8 の後も結果は同じですが、より多くの GPU メモリを利用するために、より大きなベンチマークではバッチ サイズ を選択しました。 (正直なところ、8 と 256 はどちらもほとんど同じパフォーマンスでした) 3544 枚の画像 64 秒 256 より大きなデータセットでベンチマークを実行し、バッチ サイズ 256 で何が起こるか見てみましょう。 Databricks シングルノード CPU でのハグ顔画像分類パイプライン - 34745 枚の画像を予測 大規模なデータセットでは、34K を超える画像のクラスの予測を完了するのに約 11 分 ( ) かかりました。 CPU を搭載した単一ノードと 1 つの GPU を搭載した単一ノードでのベンチマークの結果を比較すると、ここの GPU ノードが勝者であることがわかります。 659 秒 Hugging Face (PyTorch) は GPU と CPU で最大 2.3 倍高速 は、Hugging Face on Databricks Single Node の CPU で同じパイプラインを実行する場合と比較して、最大 高速です GPU 2.3 倍 今度は、同じクラスターで同じデータセットに対して Spark NLP を使用して同じベンチマークを実行し、Hugging Face と比較します。 単一ノード Databricks での Spark NLP のベンチマーク まず、Single Node Databricks CPU に Spark NLP をインストールしましょう。 クラスター内の [ ] タブで、次の手順に従う必要があります。 — 新規インストール -> PyPI -> -> インストール — 新規インストール -> Maven -> 座標 -> -> インストール — oneDNN を有効にするために、` を `Cluster->Advacend Options->Spark->Environment variables` に追加します Libraries spark-nlp==4.1.0 com.johnsnowlabs.nlp:spark-nlp_2.12:4.1.0 TF_ENABLE_ONEDNN_OPTS=1` Python、Scala、および Java の CPU 上の Databricks に Spark NLP をインストールする方法 AWS 上の CPU を使用した Databricks 単一ノードでの Spark NLP Databricks の単一ノード クラスターに Spark NLP がインストールされたので、CPU と GPU の両方でサンプルと完全なデータセットのベンチマークを繰り返すことができます。まず、サンプル データセットに対する CPU のベンチマークから始めましょう。 Databricks シングルノード CPU (oneDNN) での Spark NLP 画像分類パイプライン — 3544 枚の画像を予測 Hugging Face に使用した CPU を備えた同じ単一ノードの Databricks クラスターで、 の処理とそれらのクラスの予測を完了するのに約 2 分 ( ) かかりました。 16 のバッチ サイズが最良の結果であることがわかるので、これを次の大きなデータセットのベンチマークで使用します。 3544 枚の画像 111 秒 Databricks シングルノード CPU (oneDNN) での Spark NLP 画像分類パイプライン — 34742 画像を予測 を含む大規模なデータセットでは、これらの画像のクラスの予測を完了するのに約 18 分 ( ) かかりました。次に、GPU を使用したクラスターで同じベンチマークを繰り返します。 34K を超える画像 1072 秒 AWS で GPU を使用する Databricks 単一ノード まず、Single Node Databricks に Spark NLP をインストールします (唯一の違いは、Maven の「 を使用することです)。 GPU spark-nlp-gpu」 に をインストールする — クラスタ内の [ ] タブで、次の手順に従う必要があります。 — 新規インストール -> PyPI -> -> インストール — 新規インストール -> Maven -> 座標 -> -> インストール Databricks クラスター Spark NLP Libraries spark-nlp==4.1.0 com.johnsnowlabs.nlp:spark-nlp-gpu_2.12:4.1.0 Python、Scala、および Java の GPU 上の Databricks に Spark NLP をインストールする方法 より小さいデータセットでベンチマークを実行して、どのバッチ サイズが GPU ベースのマシンにより適しているかを確認します。 Databricks 単一ノード GPU での Spark NLP 画像分類パイプライン — 3544 枚の画像を予測 GPU デバイスを使用した単一ノードの Databricks で、サンプル データセットから約 の処理を完了するのに 1 分もかかりませんでした ( )。この特定のユース ケースでは、 が最高のパフォーマンスを発揮したことがわかるので、より大きなデータセットでベンチマークを実行します。 3544 枚の画像 47 秒 バッチ サイズ 8 Databricks 単一ノード GPU での Spark NLP 画像分類パイプライン — 34742 画像を予測 大規模なデータセットでは、 のクラスの予測を完了するのに約 7 分半 ( ) かかりました。 CPU を搭載した単一ノードと 1 つの GPU を搭載した単一ノードでのベンチマークの結果を比較すると、ここの GPU ノードが勝者であることがわかります。 34K を超える画像 435 秒 Spark NLP は、GPU と Databricks 単一ノードの CPU で最大 2.5 倍高速です これは素晴らしい！ GPU 上の Spark NLP は、oneDNN が有効になっている場合でも、CPU よりも最大 であることがわかります (oneDNN は、CPU での結果を 10% から 20% 改善します)。 2.5 倍高速 これらの結果が、同じ Databricks 単一ノード クラスターの Hugging Face ベンチマークとどのように比較されるかを見てみましょう。 は、 上の Hugging Face よりも、3K 画像を含むサンプル データセットの画像クラスを予測する際に最大 高速であり、34K 画像を含むより大きなデータセットでは最大 高速です。また、 は、単一の で 34K 画像を含む大規模なデータセットで Hugging Face よりも であり、3K 画像を含む小規模なデータセットで最大 です。 Spark NLP CPU 15% 34% Spark NLP GPU 51% 高速 36% 高速 は、 と の両方で、Databricks の単一ノードでの Hugging よりも高速です Spark NLP CPU GPU Face 単一のマシンを超えたスケーリング これまでのところ、 上の Hugging は、ベアメタル サーバーと Databricks シングル ノード上の 上の Hugging よりも高速であることを確認しました。これは、これらの新しいトランスフォーマー ベースのモデルで GPU と CPU を比較すると予想されることです。 GPU Face CPU Face また、 は、ベアメタル サーバーと Databricks シングル ノード クラスターの両方で、まったく同じパイプライン (ViT モデル) の Hugging よりも優れており、CPU と GPU デバイスの両方でパフォーマンスが優れていることも確認しています。一方、これは私が期待したものではありませんでした。この記事を準備していたとき、Spark NLP での TensorFlow の推論は、PyTorch を使用した Hugging Face での推論よりもわずかに遅いか、少なくとも互角であると予想していました。私はこのセクションを目指し 。しかし、Spark NLP は、 と の両方で、 なデータセットと データセットの両方で、単一のマシンでも Hugging Face よりも高速であるようです。 Spark NLP Face 、単一のマシンを超えてパイプラインをスケーリングしました CPU GPU 小規模 大規模な ViT パイプラインをさらに高速化するにはどうすればよいですか?さらに大きなデータセットがあり、それらを 1 台のマシンに収めることができない場合や、結果を返すのに時間がかかりすぎる場合はどうすればよいでしょうか? 質問: スケールアウト！これは、同じマシンのサイズを変更する代わりに、クラスターにマシンを追加することを意味します。これらすべてのジョブ/タスク/DAG のスケジューリング/失敗したタスクの管理などを管理するために何かが必要です。それらにはオーバーヘッドがありますが、何かをより高速にしたり、(単一のマシンを超えて) 可能にしたりする必要がある場合は、ある種の分散システムを使用する必要があります。 回答： より多くの負荷を処理できるように、マシンを大きくまたは高速にします。 スケールアップ = 並列にマシンを追加して負荷を分散します。 スケールアウト = Hugging Face のスケールアウト: Hugging Face の公式 Web サイトのページを見ると、スケーリングの推論はマルチ GPU を使用することによってのみ可能であることがわかります。スケール アウトとは何かを説明していますが、これはまだ 1 台のマシンにとどまっています。 https://huggingface.co/docs/transformers/performance また、Hugging Face での のための ソリューションは現時点では存在しないことは言うまでもありません。 推論 マルチ GPU https://huggingface.co/docs/transformers/perf_infer_gpu_many そのため、Hugging Face パイプラインを ためのネイティブまたは公式の方法はないようです。ジョブ キュー、メッセージング プロトコル、RESTful API バックエンド、および各要求を異なるマシンに分散するために必要なその他のコンポーネントなどのマイクロサービスで構成されるアーキテクチャを実装できますが、これは実際のシステムをスケールアウトするのではなく、個々のユーザーによる要求をスケーリングします。自体。 スケールアウトする さらに、このようなシステムのレイテンシーは、Apache Spark などのネイティブ分散システムとは比較になりません (gRPC はこのレイテンシーを下げる可能性がありますが、それでも競争力はありません)。単一障害点の問題は言うまでもなく、失敗したジョブ/タスク/入力の管理、および Apache Spark からすぐに使用できる何百もの他の機能を自分で実装/維持する必要があります。 Face の Web サイトには、REST エンドポイントをスケーリングしてより多くのユーザーにサービスを提供することでまったく同じアーキテクチャを描写したブログ投稿があります。 、それらはすべて、推論 REST エンドポイントにヒットするユーザー/リクエストの数をスケーリングしています。さらに、Databricks でこの方法で Hugging Hugging Face をスケーリングすることはできません。 たとえば、fastAPI 内の推論は、ローカルの推論よりも 10 倍遅くなります: https://towardsdatascience.com/hugging-face-transformer-inference-under-1-millisecond-latency-e1be0057a51c Hugging Face がスケールアウトするためのネイティブ ソリューションを提供したら、もう一度ベンチマークを実行します。それまでは、ラウンド ロビン アルゴリズムで REST エンドポイントに到達するために 1 台のマシンからデータセットをループ処理する必要がある場合のスケールアウトはありません。 (行/シーケンス/画像をバッチ処理して一度に GPU に供給した部分についてもう一度考えてみてください。そうすれば、それが得られます) Spark NLP のスケールアウト: Spark NLP は Spark ML の拡張機能であるため、Databricks、AWS EMR、Azure Insight、GCP Dataproc、Cloudera、SageMaker、Kubernetes など (およびこれらに限定されない) Apache Spark がサポートするすべてのプラットフォームでネイティブかつシームレスにスケーリングします。 コードの変更は必要ありません。 Spark NLP は、コードを変更することなく、1 台のマシンから無数のマシンにスケーリングできます。 また、Spark NLP からモデルをエクスポートして、まったく別のライブラリで使用し、推論を高速化またはスケーリングする必要もありません。 Spark NLP エコシステム: 最適化、テスト、およびサポートされている統合 AWS 上の CPU を使用した Databricks マルチノード クラスターを作成しましょう。今回は 内の を選択します。これは、クラスター内に複数のノードを持つことができることを意味します。これは、Apache Spark 用語では、1 つのドライバーと N 個のワーカー (エグゼキューター) を意味します。 クラスター モード 標準 また、[ライブラリ] タブを使用して、この新しいクラスターに Spark NLP をインストールする必要があります。 CPU を使用した単一ノード Databricks の前のセクションで説明した手順に従うことができます。ご覧のとおり、Hugging Face と Spark NLP の両方のベンチマークに使用したのと同じ CPU ベースの AWS インスタンスを選択したので、ノードを追加したときにどのようにスケールアウトするかを確認できます。 これは、クラスター構成がどのように見えるかです。 CPU のみの Databricks マルチノード (標準) クラスター 以前のベンチマークで使用したものと同じ Spark NLP パイプラインを再利用し 、34K 画像を含むより大きなデータセットのみを使用します。さぁ、始めよう！ (コードを変更する必要はありません) 2x ノードの CPU で Spark NLP をスケーリングする 2x ノードの Databricks — CPU のみ ノードをもう 1 つ追加して、処理を行うマシンの合計を 2 台にしましょう。単一マシンのセットアップ (Colab、Kaggle、Databricks の単一ノード、またはローカルの Jupyter ノートブック) からマルチノード クラスターのセットアップ (Databricks、EMR、GCP、Azure、Cloudera) に移行するときに、Spark NLP の美しさを忘れないでください。 、YARN、Kubernetes など)、ゼロコード変更が必要です!そして、私はゼロを意味します！それを念頭に置いて、34K 画像を含むより大きなデータセットで、この新しいクラスター内で同じベンチマークを実行します。 CPU を備えた 2 つの での Spark NLP 画像分類パイプライン (oneDNN) — 34742 画像を予測 ノード 34K 画像のクラスの予測が完了するまでに約 ( ) かかりました。 Spark NLP を使用した でのこの結果と、Databricks の単一ノードでの Hugging Face の結果を比較してみましょう (特に Databricks では、Hugging Face は複数のマシンでスケールアウトできなかったため、参照として単一ノードでの Hugging Face の結果を繰り返します)。 : 9 分 550 秒 2x ノード は、 の Hugging Face よりも です Spark NLP 2x ノード 124% 高速 以前は、Spark NLP は、CPU のみを使用して、単一ノードの Databricks クラスターで Hugging Face を 上回っていました。 15% 今回は、1 つのノードではなく 2 つのノードのみを使用することで、Spark NLP は Hugging Face よりも 124% 速く 34K を超える画像のプロセスを完了しました。4 つのノードを備えた CPU で Spark NLP をスケーリングします。 前のようにクラスターのサイズを 2 倍にして、 から これは、クラスターが 4x ノードでどのように見えるかです: 2x ノード 4x ノードにしましょう。 4x ノードの Databricks — CPU のみ 34K の画像を含む大規模なデータセットで、この新しいクラスターで同じベンチマークを実行します。 CPU (oneDNN) を備えた 4 つの での Spark NLP 画像分類パイプライン — 34742 画像を予測 ノード 34K 画像のクラスの予測が完了するまでに約 ( ) かかりました。 Spark NLP を使用した でのこの結果と、Databricks の CPU での Hugging Face を比較してみましょう。 5 分 289 秒 4x ノード は、 の Hugging Face よりも です Spark NLP 4x ノード 327% 高速 ご覧のとおり、Spark NLP は、Databricks で のみを使用しながら、CPU で Hugging Face よりも です。 4x ノード 327% 高速 8x ノードの CPU で Spark NLP をスケーリングする ここで、4 倍のノードを追加して前のクラスターを 2 倍にし、合計 にします。ちなみに、このクラスターのサイズ変更は非常に簡単です。クラスター構成でワーカーの数を増やすだけです。 8 倍のノード Databricks で Spark クラスターのサイズを変更する 8x ノードの Databricks — CPU のみ 今回は で同じベンチマークを実行してみましょう。 8x ノード CPU を備えた 上の Spark NLP 画像分類パイプライン (oneDNN) — 34742 画像を予測 8x ノード 34K 画像のクラスの予測を完了するのに 2 分半 ( ) 以上かかりました。 Spark NLP を使用した でのこの結果と、Databricks の CPU での Hugging Face を比較してみましょう。 161 秒 8x ノード は、 の Hugging Face よりも です Spark NLP 8x ノード 666% 高速 ご覧のとおり、Spark NLP は、Databricks で のみを使用しながら、CPU で Hugging Face よりも です。 8x ノード 666% 高速 ここで 6 の数は無視しましょう。 （気分が良くなった場合は665.8％でした） 10x ノードの CPU で Spark NLP をスケーリングする Spark NLP を使用して Databricks の CPU で ViT モデルの予測をスケールアウトするために、クラスターのサイズをもう一度変更し、 に増やします。 ノードを 10 倍 10x ノードの Databricks — CPU のみ 今度は で同じベンチマークを実行してみましょう。 10x ノード CPU を備えた 上の Spark NLP 画像分類パイプライン (oneDNN) — 34742 画像を予測 10x ノード 34K 画像のクラスの予測を完了するのに 未満 ( ) かかりました。 でのこの結果を、Databricks の CPU での Spark NLP と Hugging Face の以前のすべての結果と比較してみましょう。 2 分 112 秒 10x ノード は、 の Hugging Face よりも です Spark NLP 10x ノード 1000% 高速 これは、Databricks で を使用して、Hugging Face からの Vision Transformer モデルを で 方法です!私たちのパイプラインは、CPU 上の Hugging Face よりも になりました。 Spark NLP 10x ノード スケールアウトする 1000% 高速 Spark NLP を使用するだけで、1 つのノードでスタックしている Hugging Face よりも パイプラインを することができましたが、使用したのは のみでした。 でパイプラインをスケールアウトして、同じ改善が得られるかどうか見てみましょう。 ViT 1000% 高速化 CPU GPU クラスター AWS で GPU を使用した Databricks マルチノード GPU ベースのマルチノード Databricks クラスターを持つことは、単一ノード クラスターを持つこととほとんど同じです。唯一の違いは、 を選択し、単一ノードの GPU のベンチマークで選択した同じ AWS インスタンス仕様で同じ ML/GPU ランタイムを維持することです。 標準 また、[ ] タブを使用して、この新しいクラスターに Spark NLP をインストールする必要があります。前と同じように、GPU を使用した単一ノード Databricks で説明した手順に従うことができます。 ライブラリ GPU を使用した Databricks マルチノード (標準) クラスター 2x ノードの GPU で Spark NLP をスケーリングする マルチノードの Databricks GPU クラスターは、単一ノードの Databricks クラスターで Spark NLP と Hugging Face を比較するために、以前にベンチマークを実行するために使用した の同じ AWS GPU インスタンスを使用します。 g4dn.8xlarge 今回はノードが 2 つある場合の概要を以下に示します。 2x ノードの Databricks — ノードあたり 1 つの GPU 2 つの を持つこの GPU クラスターで同じパイプラインを実行します。 ノード GPU を使用した 2 つの での Spark NLP 画像分類パイプライン — 34742 枚の画像を予測 ノード のクラス予測を完了するのに 4 分 ( ) かかりました。 Spark NLP を使用した でのこの結果と、Databricks の GPU での Hugging Face を比較してみましょう。 34K 画像 231 秒 2x ノード は、 の Hugging Face よりも です Spark NLP 2x ノード 185% 高速 の Spark NLP はほぼ ( ) 2x ノード 3 倍高速 185% GPU を使用している場合、1 つの単一ノードでの Hugging Face よりも優れています。 4x ノードの GPU で Spark NLP をスケーリングする GPU クラスターのサイズを 2x ノードから これは、GPU を使用した での今回の外観の概要です。 4x ノードに変更しましょう。 4x Nodes 4x ノードの Databricks — ノードあたり 1 つの GPU 4x ノードで同じベンチマークを実行して、何が起こるか見てみましょう。 GPU を使用した での Spark NLP 画像分類パイプライン — 34742 画像を予測 4x ノード 今回は、データセット内のすべての の分類を完了するのに約 2 分 ( ) かかりました。単一ノードでの Hugging Face とマルチノード クラスターでの Spark NLP の観点から、これが何を意味するかをよりよく理解するために、これを視覚化してみましょう。 34K 画像 118 秒 は、 の Hugging Face よりも です Spark NLP 4x ノード 458% 高速 これは、Hugging Face と比較して です。 で Spark NLP を使用して、パイプラインを しました。 458% のパフォーマンス向上 4x ノード 5.6 倍高速化 8x ノードの GPU で Spark NLP をスケーリングする 次に、クラスターのサイズを変更して、Databricks に 8 つの が含まれるようにします。概要は次のとおりです。 ノード 8x ノードの Databricks — ノードあたり 1 つの GPU 各 AWS インスタンス ( ) には 1 つの (15 GB の使用可能メモリ) があります。ベンチマークを再実行して、分散システムでのスケールアウトにはオーバーヘッドがあり、マシンを追加し続けることはできないため、改善点を見つけられるかどうかを確認してみましょう。 g4dn.8xlarge NVIDIA T4 GPU 16 GB GPU を使用した での Spark NLP 画像分類パイプライン — 34742 画像を予測 8x ノード Databricks クラスターで を使用して の分類を完了するのに、ほぼ 1 分 ( ) かかりました。それでもパフォーマンスを向上させることができたようです。この結果を、単一ノードの Hugging Face とマルチノード クラスターの Spark NLP の前の結果の次に並べてみましょう。 8x ノード 34K 画像 61 秒 は、 の Hugging Face よりも です Spark NLP 8x ノード 980% 高速 を使用した Spark NLP は、GPU 上の Hugging Face よりもほぼ です。 8x ノード 11 倍 (980%) 高速 10x ノードの GPU で Spark NLP をスケーリングする CPU のマルチノード ベンチマークと同様に、GPU クラスターのサイズをもう一度変更して にし、最終的なノード数を一致させたいと思います。このクラスターの最終的な要約は次のとおりです。 10x ノード 10x ノードの Databricks — ノードあたり 1 つの GPU この特定の GPU クラスターで最後のベンチマークを実行してみましょう (コードの変更はありません)。 GPU を使用した での Spark NLP 画像分類パイプライン — 34742 画像を予測 10x ノード のクラスの予測を完了するのに 1 分もかかりませんでした ( )。それらをすべて並べて、Databricks の Spark NLP パイプラインの Hugging Face からの Vision Transformer モデルのスケールアウトがどのように進んだかを見てみましょう。 34743 を超える画像 51 秒 は、 の Hugging Face よりも です Spark NLP 10x ノード 1200% 高速 これで完了です。 Databricks で を使用して、Hugging Face の モデルを で ができました。私たちのパイプラインは、GPU の Hugging Face と比較して で になりました。 Spark NLP Vision Transformer 10x ノード スケールアウトすること 1200% のパフォーマンス向上 13 倍高速 最初に CPU と GPU 間の改善を比較し、次に GPU で Spark NLP を使用して Hugging Face CPU から Databricks の 10x ノードに移行することで、パイプラインがどれだけ高速になるかを比較して、これらすべてのベンチマークをまとめてみましょう。 すべてをまとめる: Databricks: 単一ノードと複数ノード CPU を搭載した 10x ノードでの Spark NLP 🚀 は、Hugging Face 🤗 CPU を搭載した単一ノードでスタックした場合よりも 1000% (11 倍) 高速です GPU を使用した 10x ノードでの Spark NLP 🚀 は、Hugging Face 🤗 GPU を使用した単一ノードでスタックした場合よりも 1192% (13 倍) 高速です AWS CPU インスタンスと AWS GPU インスタンスの価格差はどうですか? （つまり、お金を払えばもっともらえるということですよね？） CPU を搭載した と 1 つの GPU と同様の仕様を搭載した g4dn.8xlarge の比較 AWS m5d.8xlarge AWS わかりました、価格はほとんど同じようです！それを念頭に置いて、1 台のマシンにスタックされた での から、 を備えた での に移行すると、どのような改善が得られるでしょうか? CPU Hugging Face 10x GPU 10x Nodes Spark NLP GPU 上の は、CPU 上の Hugging Face よりも です Spark NLP 25 倍 (2366%) 高速 GPU を使用した 10x ノードでの Spark NLP 🚀 は、CPU を使用した単一ノードでの Hugging Face 🤗 よりも 2366% (25 倍) 高速です 最後の言葉 完全な透明性の精神で、ログ、スクリーンショット、さらには数値を含む Excel シートを含むすべてのノートブックが 提供されています。 GitHub で Spark NLP のスケーリングでは、コードを変更する必要はありません。単一ノード Databricks から 10 ノードまでのベンチマークを実行することは、同じノートブックで同じコード ブロックを再実行することを意味しました これら 2 つのライブラリには、さまざまなユース ケースのさまざまな環境で速度と効率を最適化するための多くのベスト プラクティスが付属していることに注意してください。たとえば、パーティションと、それらと並列処理および Apache Spark のディストリビューションとの関係については説明しませんでした。クラスターを微調整するための多くの Spark 構成があり、特に CPU と GPU 間のタスク数のバランスを取ります。問題は、ベンチマークに使用したのとまったく同じ環境内でそれらのいずれかを高速化できるかということです。答えは100%です！大多数のユーザーにとってシンプルであることを優先して、デフォルト値とすぐに使える機能を備えた両方のライブラリのすべてを維持しようとしました。 Hugging Face やその他の DL ベースの Python ライブラリを Spark UDF にラップしてスケーリングすることができます。これは、私が自分でこれを行ったので、ある程度機能します(ネイティブソリューションがない場合)。このようなトランスフォーマー ベースのモデルを UDF でラップする場合の過剰なメモリ使用量、シリアライゼーションの問題、レイテンシの増加、およびその他の問題の詳細については説明しません。 Apache Spark を使用している場合は、必要な機能を Apache Spark でネイティブに拡張するライブラリを使用してください。 この記事全体を通して、PyTorch の Hugging Face と TensorFlow の Spark NLP について言及するのに苦労しました。 PyTorch と TensorFlow の間で Hugging Face によって行われたすべてのベンチマークで、PyTorch が推論の勝者であったという事実を考えると、これは大きな違いです。 Hugging Face では、PyTorch のレイテンシがはるかに低く、Transformers の TensorFlow よりもはるかに高速であるように見えます。 Spark NLP がまったく同じ TensorFlow を使用し、Hugging Face の PyTorch と比較してすべてのベンチマークで優れているという事実は大きな問題です。 Hugging Face の TensorFlow が無視されているか、PyTorch は TensorFlow と比較して推論が高速です。いずれにせよ、Spark NLP が TensorFlow に加えて TorchScript と ONNX ランタイムのサポートを開始したときに何が起こるかを見るのが待ちきれません。 ML および ML GPU Databricks ランタイムには、Hugging Face がインストールされています。これは非常に優れています。ただし、Hugging Face が Databricks で使いやすいというわけではありません。 Hugging Face による Transformer ライブラリは、DBFS (Databricks のネイティブ分散ファイル システム) または Amazon S3 をサポートしていません。ノートブックにあるように、データセットの圧縮バージョンをダウンロードして展開し、それらを使用する必要がありました。これは、Databricks のユーザーや、運用環境の他のプラットフォームの実際のやり方ではありません。データは分散ファイル システム内に保持され、セキュリティ対策が実装されており、それらのほとんどは十分に大きいため、パーソナル コンピューターではダウンロードできません。 DBFS に既にあるデータセットをダウンロードして圧縮し、S3 にアップロードして公開し、ノートブックに再度ダウンロードする必要がありました。 Hugging Face が DBFS/S3 をサポートしていれば、かなり面倒なプロセスを回避できたはずです。 参考文献 ViT https://arxiv.org/pdf/2010.11929.pdf https://github.com/google-research/vision_transformer 画像認識におけるビジョン トランスフォーマー (ViT) — 2022 ガイド https://github.com/lucidrains/vit-pytorch https://medium.com/mlearning-ai/an-image-is-worth-16x16-words-transformers-for-image-recognition-at-scale-51f3561a9f96 https://medium.com/nerd-for-tech/an-image-is-worth-16x16-words-transformers-for-image-recognition-at-scale-paper-summary-3a387e71880a https://gareemadhingra11.medium.com/summary-of-paper-an-image-is-worth-16x16-words-3f7f3aca941 https://medium.com/analytics-vidhya/vision-transformers-bye-bye-convolutions-e929d022e4ab https://medium.com/syncedreview/google-brain-uncovers-representation-structure-differences-between-cnns-and-vision-transformers-83b6835dbbac 抱きしめる顔 https://huggingface.co/docs/transformers/main_classes/pipelines https://huggingface.co/blog/fine-tune-vit https://huggingface.co/blog/vision-transformers https://huggingface.co/blog/tf-serving-vision https://huggingface.co/blog/deploy-tfserving-kubernetes https://huggingface.co/google/vit-base-patch16-224 https://huggingface.co/blog/deploy-vertex-ai https://huggingface.co/models?other=vit データブリック https://www.databricks.com/spark/getting-started-with-apache-spark https://docs.databricks.com/getting-started/index.html https://docs.databricks.com/getting-started/quick-start.html の見どころをご覧ください DATA+AI SUMMIT 2022 https://www.databricks.com/blog/2020/05/15/shrink-training-time-and-cost-using-nvidia-gpu-accelerated-xgboost-and-apache-spark-on-databricks.html スパークNLP スパーク NLP GitHub (Spark NLP の例) Spark NLP ワークショップ Spark NLP トランスフォーマー Spark NLP モデル ハブ ウェア ハード に活用する Spark NLP 3 の速度の最適化とベンチマーク: Spark NLP で最新のハード ウェア アクセラレーションを最大限 API を介した Spark NLP の提供: Spring および LightPipelines API 経由で Spark NLP を提供する (1/3): Microsoft の Synapse ML API 経由で Spark NLP を提供する (2/3): FastAPI と LightPipelines API を介した Spark NLP の提供 (3/3): Databricks ジョブと MLFlow サーブ API Spark 3.0 で GPU を使用して Scala で深層学習を活用する GPU で高速化された Apache Spark 3 の使用を開始する Apache Spark のパフォーマンス チューニング GPU で可能な追加の最適化: RAPIDS Accelerator for Apache Spark Configuration
