4,285 讀數

缩放视觉变形金刚 (ViT) 超越拥抱脸

经过 Maziyar PanahiNaN2022/08/25

太長; 讀書

本文的目的是演示如何从 Hugging Face 扩展 Vision Transformer (ViT) 模型，并将它们部署在生产就绪环境中，以实现加速和高性能推理。最后，我们将使用 Databricks、Nvidia 和 Spark NLP 将 Hugging Face 的 ViT 模型扩展 25 倍 (2300%)。

People Mentioned

Companies Mentioned

Coin Mentioned

使用 Databricks、Nvidia 和 Spark NLP 将 Hugging Face 🤗 中最先进的ViT模型加速高达 2300%（快 25 倍）🚀

我是Spark NLP开源项目的贡献者之一，最近这个库开始支持端到端的Vision Transformers (ViT)模型。我每天使用 Spark NLP 和其他 ML/DL 开源库进行工作，我决定部署一个 ViT 管道来执行最先进的图像分类任务，并提供Hugging Face和Spark NLP之间的深入比较。

本文的目的是演示如何从 Hugging Face 扩展 Vision Transformer (ViT) 模型，并将它们部署在生产就绪环境中，以实现加速和高性能推理。最后，我们将使用 Databricks、Nvidia 和 Spark NLP 将 Hugging Face 的 ViT 模型扩展25 倍 (2300%) 。

在本文中，我将：

Vision Transformer (ViT) 简介

戴尔服务器内部 CPU 和 GPU 上的基准拥抱脸

在 CPU 和 GPU 上的戴尔服务器内对 Spark NLP 进行基准测试

CPU 和 GPU 上 Databricks 单节点内的基准拥抱脸

在 CPU 和 GPU 上的 Databricks 单节点内对 Spark NLP 进行基准测试

Databricks 中的 Benchmark Spark NLP 扩展到 10 倍的节点，带有 CPU 和 GPU

总结一切！

本着完全透明的精神，所有笔记本及其日志、屏幕截图，甚至带有数字的 Excel 表都在 GitHub 上提供

Vision Transformer (ViT) 模型简介

早在 2017 年，Google AI 的一组研究人员发表了一篇论文，介绍了一种改变所有自然语言处理 (NLP) 标准的转换器模型架构。该论文描述了一种称为自我注意的新机制，作为一种新的、更有效的语言应用模型。例如，最流行的两个基于变压器的模型系列是 GPT 和 BERT。

一些变形金刚历史https://huggingface.co/course/chapter1/4

如果您有兴趣，我强烈建议您阅读有关“变形金刚如何工作”的精彩章节。

尽管这些新的基于 Transformer 的模型似乎正在彻底改变 NLP 任务，但它们在计算机视觉 (CV) 中的使用仍然非常有限。计算机视觉领域一直以卷积神经网络 (CNN) 的使用为主，并且存在基于 CNN 的流行架构（如 ResNet）。直到 2021 年 6 月，Google Brain 的另一组研究人员在一篇题为“ An Image is Worth 16x16 Words: Transformers for Image Recognition at Scale ”的论文中介绍了“视觉转换器” （ViT），情况一直如此。

本文代表了图像识别方面的突破，它使用了与我们刚刚讨论的基于转换器的模型（例如 BERT 和 GPT）中使用的相同的自注意机制。在像 BERT 这样的基于转换的语言模型中，输入是一个句子（例如单词列表）。然而，在 ViT 模型中，我们首先将图像分割成子图像块的网格，然后我们将每个块嵌入到一个线性项目中，然后将每个嵌入的块变成一个令牌。结果是一系列嵌入补丁，我们将其传递给类似于 BERT 的模型。

Google Research 2021 年原始论文中介绍的 ViT 模型结构概述

Vision Transformer 专注于更高的准确性，但计算时间更少。查看论文中发布的基准，我们可以看到针对Noisy Student数据集（由 Google 于 2020 年 6 月发布）的训练时间减少了 80%，尽管准确度状态或多或少相同。有关今天 ViT 性能的更多信息，您应该访问其关于Papers With Code的页面：

在流行的图像分类基准上与最先进的技术进行比较。（ https://arxiv.org/pdf/2010.11929.pdf ）

同样重要的是要提到，一旦您通过 ViT 架构训练了模型，您就可以像在 NLP 中一样预训练和微调您的转换器。（实际上这很酷！）

如果我们将 ViT 模型与 CNN 进行比较，我们可以看到它们具有更高的准确性和更低的计算成本。您可以将 ViT 模型用于计算机视觉中的各种下游任务，例如图像分类、检测对象和图像分割。这也可以是医疗保健领域的特定领域，您可以针对股骨骨折、肺气肿、乳腺癌、 COVID-19和阿尔茨海默病预训练/微调您的 ViT 模型。¹

我将在本文末尾留下参考资料，以防您想更深入地了解 ViT 模型的工作原理。

[1]: 深入探讨：关于拥抱面部优化 Graphcore 的视觉变换器https://huggingface.co/blog/vision-transformers

一些正在运行的 ViT 模型

Vision Transformer (ViT) 模型 ( vit-base-patch16–224 ) 在 ImageNet-21k（1400 万张图像，21843 个类别）上以 224x224 的分辨率进行预训练，并在 ImageNet 2012（100 万张图像，1000 个类别）上进行了微调分辨率 224x224：

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/ — ViT 模型：https://huggingface.co /julien-c/hotdog-not-hotdog

我们可以使用 Hugging Face 中的这些模型或微调新的 ViT 模型并将它们用于实际生产中的推理吗？我们如何通过使用用于分布式计算的托管服务（例如 AWS EMR、Azure Insight、GCP Dataproc 或 Databricks）来扩展它们？

希望其中一些问题将在本文结尾得到解答。

让基准测试开始！

关于我们的基准测试的一些细节：

1- 数据集： ImageNet mini：样本(>3K) —完整(>34K)

我已经从 Kaggle 下载了 ImageNet 1000 (mini) 数据集： https ://www.kaggle.com/datasets/ifigotin/imagenetmini-1000

我选择了包含超过34K 图像的 train 目录并将其命名为imagenet-mini ，因为我只需要足够的图像来进行需要更长时间的基准测试。此外，我随机选择了不到 10% 的完整数据集并将其命名为imagenet-mini-sample ，它包含3544 张图像，用于我较小的基准测试并微调正确的参数，如批量大小。

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 型号

什么是裸机服务器？裸机服务器只是一台仅由一个用户使用的物理计算机。这台机器上没有安装管理程序，没有虚拟化，一切都直接在主操作系统（Linux - Ubuntu）上执行——这台机器的 CPU、GPU 和内存的详细规格都在笔记本电脑中。

正如我的初始测试以及 Hugging Face 工程团队撰写的几乎所有比较 DL 引擎之间推理速度的博客文章所揭示的那样，Hugging Face 库（Transformer）中推理的最佳性能是通过在 TensorFlow 上使用 PyTorch 实现的。我不确定这是否是由于 TensorFlow 成为 Hugging Face 中的二等公民，因为支持的功能更少，支持的模型更少，示例更少，教程过时，以及过去 2 年的年度调查，用户对 TensorFlow 的要求更高或者 PyTorch 在 CPU 和 GPU 上的推理延迟较低。

TensorFlow 仍然是最常用的深度学习框架

不管出于什么原因，我都选择了 Hugging Face 库中的 PyTorch，以便为我们的图像分类基准测试获得最佳结果。这是在 Hugging Face 中使用 ViT 模型（当然是 PyTorch）的简单代码片段：

 from transformers import ViTFeatureExtractor, ViTForImageClassification from PIL import Image import requests 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 via Pipelines中是可能的。不用说，您可以通过扩展 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 检查点）下载/加载了google/vit-base-patch16–224 ，以便在管道中使用它们，并将图像分类作为任务。此管道中有 3 件事对我们的基准测试很重要：

> 设备：如果它是 -1（默认），它将只使用 CPU，而如果它是一个正整数，它将在相关的 CUDA 设备 ID 上运行模型。（最好隐藏 GPU 并强制 PyTorch 使用 CPU 而不仅仅是在这里依靠这个数字）。

> batch_size：当管道将使用DataLoader时（传递数据集时，在 GPU 上用于 Pytorch 模型），用于推理的批次大小并不总是有益的。

>您必须使用 DataLoader 或 PyTorch Dataset 才能充分利用 GPU 上 Hugging Face 管道中的批处理。

在我们继续进行基准测试之前，您需要了解关于 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 上的 Hugging Face 图像分类管道——预测 3544 张图像

可以看出，完成处理来自样本数据集的大约3544 张图像大约需要 3 分钟（ 188 秒） 。现在我知道哪种批量大小 (8) 最适合我的管道/数据集/硬件，我可以在具有此批量大小的更大数据集（ 34K 图像）上使用相同的管道：

CPU 上的 Hugging Face 图像分类管道——预测 34745 张图像

这次在 CPU 上完成对34745 个图像的类别预测大约需要 31 分钟（ 1,879 秒）。

要改进大多数深度学习模型，尤其是这些基于转换器的新模型，应该使用 GPU 等加速硬件。让我们看看如何在相同的数据集上对相同的管道进行基准测试，但这次是在GPU设备上。如前所述，我们需要将设备更改为 CUDA 设备 ID，例如 0（第一个 GPU）：

 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' ) model = model.to(device) 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，以找到最佳结果。

让我们看看我们在 GPU 设备上对样本 ImageNet 数据集 (3K) 的 Hugging Face 图像分类管道：

GPU 上的 Hugging Face 图像分类管道——预测 3544 张图像

可以看出，在GPU 设备上完成处理来自我们的 imagenet-mini-sample 数据集的大约3544 张图像大约需要50 秒。批处理提高了速度，特别是与来自 CPU 的结果相比，但是，改进在批处理大小 32 附近停止。虽然批处理大小 32 后结果相同，但我选择了批处理大小256作为我更大的基准测试使用足够的GPU内存也是如此。

GPU 上的 Hugging Face 图像分类管道——预测 34745 张图像

这次我们的基准测试用了大约 8 分 17 分（ 497 秒）来完成对GPU设备上34745 个图像的类别的预测。如果我们比较我们在 CPU 和 GPU 设备上的基准测试结果，我们可以看到 GPU 是赢家：

Hugging Face (PyTorch) 在 GPU 上的速度比 CPU 快 3.9 倍

我使用 Hugging Face Pipelines 加载 ViT PyTorch 检查点，将我的数据加载到 Torch 数据集中，并在 CPU 和 GPU 上使用开箱即用提供的批处理模型。与在 CPU 上运行相同的流水线相比， GPU的速度提高了约 3.9 倍。

我们已经改进了 ViT 管道，通过使用GPU 设备而不是 CPU 来执行图像分类，但是在将其扩展到多台机器之前，我们能否在单台机器上进一步改进CPU和GPU上的管道？让我们看一下 Spark NLP 库。

Spark NLP：最先进的自然语言处理

Spark NLP 是一个开源的最先进的自然语言处理库 ( https://github.com/JohnSnowLabs/spark-nlp )

Spark NLP 是建立在 Apache Spark 之上的最先进的自然语言处理库。它为在分布式环境中轻松扩展的机器学习管道提供简单、高性能和准确的 NLP 注释。 Spark NLP 附带7000多个预训练管道和模型，支持200 多种语言。它还提供诸如标记化、分词、词性标记、词和句子嵌入、命名实体识别、依赖解析、拼写检查、文本分类、情感分析、标记分类、机器翻译（+180 种语言）等任务，总结和问答、文本生成、图像分类 (ViT) 以及更多NLP 任务。

Spark NLP 是唯一一个在生产中提供最先进转换器的开源 NLP 库，例如BERT 、 CamemBERT 、 ALBERT 、 ELECTRA 、 XLNet 、 DistilBERT 、 RoBERTa 、 DeBERTa 、 XLM-RoBERTa 、 Longformer 、 ELMO 、 Universal Sentence Encoder 、Google T5 、 MarianMT 、 GPT2和 Vision Transformer ( ViT ) 不仅适用于Python和R ，还适用于 JVM 生态系统（ Java 、 Scala和Kotlin ），通过原生扩展 Apache Spark。

在裸机服务器上对 Spark NLP 进行基准测试

Dell PowerEdge C4130 上的 ViT 型号

Spark NLP 具有与最近4.1.0版本中添加的 Hugging Face 相同的图像分类ViT 功能。该功能称为ViTForImageClassification，它有240 多个预训练模型可供使用，在 Spark NLP 中使用此功能的简单代码如下所示：

 from sparknlp.annotator import * from sparknlp.base import * from pyspark.ml import Pipeline imageAssembler = ImageAssembler() \ .setInputCol( "image" ) \ .setOutputCol( "image_assembler" ) imageClassifier = ViTForImageClassification \ .pretrained( "image_classifier_vit_base_patch16_224" ) \ .setInputCols( "image_assembler" ) \ .setOutputCol( "class" ) \ .setBatchSize( 8 ) pipeline = Pipeline(stages=[ imageAssembler, imageClassifier ])

如果我们并排比较 Spark NLP 和 Hugging Face 以下载和加载预训练的 ViT 模型以进行图像分类预测，除了加载图像和使用 Hugging Face 库之外的 argmax 等后期计算之外，它们都非常简单。此外，它们都可以保存并在以后用作管道，以将这些行减少为仅 1 行代码：

在 Spark NLP（左）和 Hugging Face（右）中加载和使用 ViT 模型进行图像分类

由于 Apache Spark 有一个名为Lazy Evaluation的概念，因此在调用ACTION之前它不会开始执行流程。 Apache Spark 中的操作可以是 .count() 或 .show() 或 .write() 以及许多其他基于 RDD 的操作，我现在不会介绍，您也不需要在本文中了解它们。我通常选择 count() 目标列或 write() 磁盘上的结果来触发执行 DataFrame 中的所有行。此外，就像 Hugging Face 基准测试一样，我将遍历选定的批量大小，以确保我可以获得所有可能的结果而不会错过最佳结果。

现在，我们知道如何在 Spark NLP 中加载 ViT 模型，我们也知道如何触发一个动作来强制计算 DataFrame 中的所有行以进行基准测试，剩下的就是学习 oneAPI 中的oneDNN 深度神经网络库（oneDNN）。由于 Spark NLP 中的 DL 引擎是 TensorFlow，因此您还可以启用 oneDNN 来提高 CPU 上的速度（与其他一切一样，您需要对此进行测试以确保它提高了速度，而不是相反）。除了没有启用 oneDNN 的普通 CPU 之外，我还将使用此标志

既然我们知道 Hugging Face 的所有 ViT 模型也可用于 Spark NLP 以及如何在管道中使用它们，我们将在裸机戴尔服务器上重复我们之前的基准测试，以比较 CPU 与 GPU。让我们看看我们的样本 (3K) ImageNet 数据集上 Spark NLP 的图像分类管道在 CPU 上的结果：

在没有 oneDNN 的 CPU 上 Spark NLP 图像分类管道——预测 3544 张图像

从我们的样本数据集中完成大约3544 张图像的处理大约需要 2.1 分钟（ 130 秒） 。使用较小的数据集来尝试不同的批量大小有助于为您的任务、数据集和机器选择正确的批量大小。很明显，批量大小 16是我们的管道提供最佳结果的最佳大小。

我还想启用oneDNN以查看在这种特定情况下，与没有 oneDNN 的 CPU 相比，它是否能改进我的基准测试。您可以通过将TF_ENABLE_ONEDNN_OPTS的环境变量设置为1在 Spark NLP 中启用 oneDNN。让我们看看如果我启用此标志并在 CPU 上重新运行之前的基准测试以找到最佳批量大小会发生什么：

在带有 oneDNN 的 CPU 上 Spark NLP 图像分类管道——预测 3544 张图像

好的，很明显，在这种特定情况下为 TensorFlow 启用 oneDNN 使我们的结果至少提高了 14%。因为我们不需要做/改变任何事情，只需要说 export TF_ENABLE_ONEDNN_OPTS=1 我将把它用于更大数据集的基准测试，以查看差异。这里大约快几秒钟，但在更大的数据集上 14% 可以缩短我们几分钟的结果。

现在我知道没有 oneDNN 的 CPU 的批量大小为 16，启用 oneDNN 的 CPU 的批量大小为 2 具有最佳结果，我可以继续在更大的数据集（ 34K 图像）上使用相同的管道：

没有oneDNN的CPU上的Spark NLP图像分类管道——预测34745张图像

这次我们的基准测试用了大约 24 分钟（ 1423 秒）来完成在未启用 oneDNN 的CPU设备上对34745 个图像的类别进行预测。现在让我们看看如果我为 TensorFlow 启用 oneDNN 并使用批量大小为 2（最好的结果）会发生什么：

带有 oneDNN 的 CPU 上的 Spark NLP 图像分类管道——预测 34745 个图像

这次花了大约 21 分钟（ 1278 秒）。正如我们的示例基准所预期的那样，与未启用 oneDNN 相比，我们可以看到结果的改进时间约为 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 (oneDNN) 快 4.6 倍

这很棒！我们可以看到，即使启用了 oneDNN，GPU 上的 Spark NLP 也比 CPU快 4.6 倍。

让我们看看这些结果如何与 Hugging Face 基准进行比较：

Spark NLP 在预测具有 3K 图像的样本数据集的图像类别时比 CPU 上的 Hugging Face 快 65%，在具有 34K 图像的较大数据集上快 47%。在具有 34K 图像的单个 GPU 推理大型数据集上，Spark NLP 的速度也比 Hugging Face 快 79%，而在较小的数据集上则快 35%。

Spark NLP 在单台机器上使用 CPU 或 GPU 比 Hugging Face 更快——使用 Vision Transformer (ViT) 进行图像分类

在 Databricks 上 Spark NLP 和拥抱脸

什么是数据块？一个平台上的所有数据、分析和 AI

Databricks 是一个基于云的平台，具有一组数据工程和数据科学工具，被许多公司广泛用于处理和转换大量数据。用户将 Databricks 用于多种用途，从处理和转换大量数据到运行许多 ML/DL 管道以探索数据。

免责声明：这是我对 Databricks 的解释，它确实具有许多其他功能，您应该查看它们： https ://www.databricks.com/product/data-lakehouse

Databricks 支持 AWS、Azure 和 GCP 云： https ://www.databricks.com/product/data-lakehouse

在 AWS 上使用 CPU 的 Databricks 单节点拥抱脸

当您创建一个集群时，Databricks 提供了一种“单节点”集群类型，该集群适合那些只想在一台机器上使用 Apache Spark 或使用非 Spark 应用程序的人，尤其是基于 ML 和 DL 的 Python 库。当您选择 Databricks 11.1 ML 运行时时，Hugging Face 已经安装。在开始基准测试之前，我的单节点 Databricks（仅 CPU）的集群配置如下所示：

Databricks 单节点集群——CPU 运行时

这个在AWS上使用m5n.8xlarge实例的集群的总结是它有 1 个 Driver（只有 1 个节点）， 128 GB内存， 32 个 CPU 核，每小时花费5.71 DBU 。您可以在此处阅读 AWS 上的“DBU”： https ://www.databricks.com/product/aws-pricing

Databricks 单集群 — AWS 实例配置文件

让我们在我们的单节点 Databricks（仅限 CPU）上复制上一节（裸机戴尔服务器）的基准测试。我们从 Hugging Face 和我们的 ImageNet 样本大小的数据集开始，找出合适的批量大小，以便我们可以将其用于更大的数据集，因为这恰好是之前基准测试中经过验证的实践：

Databricks 单节点 CPU 上的 Hugging Face 图像分类管道——预测 3544 张图像

在仅使用CPU的单节点 Databricks 上完成处理来自我们的样本数据集的大约3544 张图像大约需要 2 分半钟（ 149 秒）。这台机器上仅使用 CPU 的最佳批量大小是8 ，所以我将使用它在更大的数据集上运行基准测试：

Databricks 单节点 CPU 上的 Hugging Face 图像分类管道——预测 34745 个图像

在包含超过 34K 图像的较大数据集上，完成这些图像的类别预测大约需要 20 分半（ 1233 秒）。对于我们的下一个基准测试，我们需要一个单节点 Databricks 集群，但这次我们需要一个基于 GPU 的运行时并选择一个基于 GPU 的 AWS 实例。

在 AWS 上使用 GPU 在 Databricks 单节点中拥抱脸

让我们创建一个新的集群，这次我们将选择一个带有 GPU 的运行时，在这种情况下称为 11.1 ML（包括 Apache Spark 3.3.0、GPU、Scala 2.12），它安装了所有必需的 CUDA 和 NVIDIA 软件。接下来我们需要选择一个具有 GPU 的 AWS 实例，我选择了 g4dn.8xlarge ，它具有 1 个 GPU 和与另一个集群相似数量的内核/内存。此 GPU 实例配备Tesla T4和16 GB 内存（ 15 GB 可用的 GPU 内存）。

Databricks 单节点集群——GPU 运行时

这是我们的单节点集群和上一个集群的总结，在核心数量和内存量方面都相同，但它配备了 Tesla T4 GPU：

Databricks 单节点集群 — AWS 实例配置文件

现在我们有了一个带有 GPU 的单节点集群，我们可以继续我们的基准测试，看看 Hugging Face 在 Databricks 中的这台机器上的表现如何。我将在较小的数据集上运行基准测试，以查看哪种批量大小更适合我们基于 GPU 的机器：

Databricks 单节点 CPU 上的 Hugging Face 图像分类管道——预测 3544 张图像

在我们使用 GPU 设备的单节点 Databricks 集群上，大约需要一分钟（ 64 秒）来处理来自样本数据集的大约3544 张图像。如果我们查看批处理大小 1 的结果，批处理提高了速度，但是，在批处理大小 8 之后，结果几乎保持不变。尽管批处理大小为 8 后的结果相同，但我选择了批处理大小256来进行更大的基准测试，以利用更多的 GPU 内存。（老实说，8 和 256 的表现都差不多）

让我们在更大的数据集上运行基准测试，看看批量大小为 256 会发生什么：

Databricks 单节点 CPU 上的 Hugging Face 图像分类管道——预测 34745 个图像

在更大的数据集上，完成超过 34K 图像的类别预测需要将近 11 分钟（ 659 秒）。如果我们将我们的基准测试结果在具有 CPU 的单个节点和带有 1 个 GPU 的单个节点上进行比较，我们可以看到这里的 GPU 节点是赢家：

Hugging Face (PyTorch) 在 GPU 上的速度比 CPU 快 2.3 倍

与在 Databricks Single Node 上的 Hugging Face 中的 CPU 上运行相同的管道相比， GPU的速度提高了约 2.3 倍

现在我们将在相同的集群和相同的数据集上使用 Spark NLP 运行相同的基准测试，以将其与 Hugging Face 进行比较。

在单节点 Databricks 上对 Spark NLP 进行基准测试

首先，让我们在单节点 Databricks CPU 中安装 Spark NLP：

在集群内的库选项卡中，您需要执行以下步骤：
— 安装新的 -> PyPI -> spark-nlp==4.1.0 -> 安装
— 安装新 -> Maven -> 坐标 -> com.johnsnowlabs.nlp:spark-nlp_2.12:4.1.0 -> 安装
— 将 ` TF_ENABLE_ONEDNN_OPTS=1`添加到 `Cluster->Advacend Options->Spark->Environment variables` 以启用 oneDNN

如何在 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 集群上完成处理3544 张图像并预测它们的类别大约需要 2 分钟（ 111 秒）。我们可以看到批量大小为 16 的结果最好，所以我将在下一个更大数据集的基准测试中使用它：

Databricks 单节点 CPU (oneDNN) 上的 Spark NLP 图像分类管道——预测 34742 张图像

在包含超过34K 图像的较大数据集上，完成这些图像的类别预测大约需要 18 分钟（ 1072 秒）。接下来，我将使用 GPU 在集群上重复相同的基准测试。

在 AWS 上使用 GPU 的 Databricks 单节点

首先，在单节点 Databricks GPU中安装 Spark NLP（唯一的区别是使用 Maven 中的“ spark-nlp-gpu” ）：

在Databricks 集群中安装Spark NLP
— 在集群内的库选项卡中，您需要执行以下步骤：
— 安装新的 -> PyPI -> spark-nlp==4.1.0 -> 安装
— 安装新的 -> Maven -> 坐标 -> 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 上完成对来自样本数据集的大约3544 张图像的处理不到一分钟（ 47 秒）。我们可以看到批量大小 8在这个特定用例中表现最好，所以我将在更大的数据集上运行基准测试：

Databricks 单节点 GPU 上的 Spark NLP 图像分类管道——预测 34742 张图像

在更大的数据集上，完成超过34K 图像的类别预测需要将近 7 分半（ 435 秒）。如果我们将我们的基准测试结果在具有 CPU 的单个节点和带有 1 个 GPU 的单个节点上进行比较，我们可以看到这里的 GPU 节点是赢家：

Spark NLP 在 GPU 上的速度比在 Databricks 单节点中的 CPU 快 2.5 倍

这很棒！我们可以看到 GPU 上的 Spark NLP 比 CPU快 2.5 倍，即使启用了 oneDNN（oneDNN 将 CPU 上的结果提高了 10% 到 20%）。

让我们看看这些结果如何与同一个 Databricks 单节点集群中的 Hugging Face 基准进行比较：

在预测具有 3K 图像的样本数据集的图像类别时， Spark NLP比CPU上的 Hugging Face 快15% ，而在具有 34K 图像的较大数据集上则快34% 。对于具有 34K 图像的较大数据集， Spark NLP在单个GPU上的速度也比 Hugging Face快 51%，在具有 3K 图像的较小数据集上速度快36% 。

Spark NLP在CPU和GPU上都比 Databricks 单节点中的Hugging Face更快

超越单台机器

到目前为止，我们确定GPU上的 Hugging Face比裸机服务器和 Databricks 单节点上的CPU上的Hugging Face更快。当您将 GPU 与 CPU 与这些新的基于转换器的模型进行比较时，这就是您所期望的。

我们还确定，在裸机服务器和 Databricks 单节点集群中，对于相同的管道（ViT 模型）、相同的数据集， Spark NLP的性能优于Hugging Face ，并且它在 CPU 和 GPU 设备上的性能更好。另一方面，这不是我所期望的。当我准备这篇文章时，我预计 Spark NLP 中的 TensorFlow 推理比使用 PyTorch 的 Hugging Face 推理要慢一些，或者至少是并驾齐驱。我的目标是这部分，将管道扩展到单台机器之外。但似乎 Spark NLP 比 Hugging Face 更快，即使在单台机器上，在CPU和GPU上，在小型和大型数据集上。

问题：如果您想让您的 ViT 管道更快怎么办？如果您有更大的数据集，但无法将它们放入一台机器中，或者返回结果需要太长时间，该怎么办？

答案：向外扩展！这意味着无需调整同一台机器的大小，而是将更多机器添加到您的集群中。您需要一些东西来管理所有这些作业/任务/调度 DAG/管理失败的任务/等等。并且那些有它们的开销，但是如果您需要更快或可能的东西（超越单台机器），您必须使用某种分布式系统。

扩大规模=使您的机器更大或更快，以便它可以处理更多负载。
横向扩展=并行添加更多机器以分散负载。

扩大拥抱脸：

查看 Hugging Face 官方网站上的页面表明，只有使用多 GPU 才能进行扩展推理。正如我们所描述的向外扩展是什么，这仍然停留在一台机器上：

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 中获得的数百个其他功能，现在您必须自己实现/维护。

Hugging Face 网站上有一篇博文，通过扩展 REST 端点为更多用户提供了相同的架构：“在 Kubernetes 上部署 🤗 ViT 并使用 TF Serving ”——我相信其他公司正在使用类似的方法来扩展 Hugging Face ，他们都在扩展到达推理 REST 端点的用户/请求的数量。此外，您无法在Databricks 上以这种方式缩放 Hugging Face。

例如，fastAPI 中的推理比本地推理慢 10 倍： https ://towardsdatascience.com/hugging-face-transformer-inference-under-1-millisecond-latency-e1be0057a51c

一旦 Hugging Face 提供了一些本地解决方案来横向扩展，我将再次重新运行基准测试。在那之前，当您必须从单台机器循环访问数据集以在循环算法中命中 REST 端点时，没有横向扩展。（再想一想我们批量处理行/序列/图像以一次性提供给 GPU 的部分，然后你就会明白了）

扩展 Spark NLP：

Spark NLP 是 Spark ML 的扩展，因此它可以在 Apache Spark 支持的所有平台上本地无缝扩展，例如（但不限于）Databricks、AWS EMR、Azure Insight、GCP Dataproc、Cloudera、SageMaker、Kubernetes 等等。

需要零代码更改！ Spark NLP 可以从单台机器扩展到无限数量的机器，而无需更改代码中的任何内容！

您也无需从 Spark NLP 中导出任何模型，即可在完全不同的库中使用它来加速或扩展推理。

Spark NLP 生态系统：优化、测试和支持的集成

在 AWS 上使用 CPU 的 Databricks 多节点

让我们创建一个集群，这次我们在集群模式中选择标准。这意味着我们的集群中可以有超过 1 个节点，在 Apache Spark 术语中，这意味着 1 个驱动程序和 N 个工作程序（执行程序）。

我们还需要通过 Libraries 选项卡在这个新集群中安装 Spark NLP。您可以按照我在上一节中提到的带有 CPU 的单节点 Databricks 的步骤进行操作。如您所见，我选择了用于对 Hugging Face 和 Spark NLP 进行基准测试的基于 CPU 的 AWS 实例，因此我们可以看到当我们添加更多节点时它是如何扩展的。

这是我们的集群配置的样子：

只有 CPU 的 Databricks 多节点（标准）集群

我将重用我在之前的基准测试中使用的相同 Spark NLP 管道（无需更改任何代码） ，并且我只会使用具有 34K 图像的更大数据集。让我们开始！

在具有 2 个节点的 CPU 上扩展 Spark NLP

具有 2 个节点的 Databricks — 仅限 CPU

让我们再添加 1 个节点，并将执行处理的机器总数设为 2 台机器。当您从单机设置（您的 Colab、Kaggle、Databricks 单节点，甚至您的本地 Jupyter 笔记本）到多节点集群设置（Databricks、EMR、GCP、Azure、Cloudera）时，我们不要忘记 Spark NLP 的美妙之处, YARN, Kubernetes 等），需要零代码更改！我的意思是零！考虑到这一点，我将在这个新集群中对具有 34K 图像的较大数据集运行相同的基准测试：

Spark NLP 图像分类管道在2 个具有 CPU 的节点上 (oneDNN) — 预测 34742 张图像

完成 34K 图像的类别预测大约需要9 分钟（ 550 秒）。让我们将2x 节点上的结果与 Spark NLP 和 Databricks 单节点上的 Hugging Face 结果进行比较（我将继续在单个节点上重复 Hugging Face 结果作为参考，因为 Hugging Face 无法在多台机器上横向扩展，尤其是在 Databricks 上）：

Spark NLP比 Hugging Face with 2x Nodes快 124%

此前，Spark NLP 在单节点 Databricks 集群上仅使用 CPU 15%就击败了 Hugging Face。

这一次，由于只有 2 个节点而不是 1 个节点，Spark NLP 完成了超过 34K 图像的处理，比 Hugging Face 快 124%。在具有 4 个节点的 CPU 上扩展 Spark NLP

让我们像以前一样将集群的大小翻倍，从2x 节点变为4x 节点。这是具有 4 个节点的集群的样子：

具有 4 个节点的 Databricks — 仅限 CPU

我将在具有 34K 图像的更大数据集上在这个新集群上运行相同的基准测试：

Spark NLP 图像分类管道在具有 CPU 的4x 节点上 (oneDNN) — 预测 34742 张图像

完成 34K 图像的类别预测大约需要5 分钟（ 289 秒）。让我们比较一下在4x 节点上使用 Spark NLP 与 Hugging Face 在 Databricks 上的 CPU 上的结果：

Spark NLP比 Hugging Face with 4x Nodes快 327%

可以看出，Spark NLP 现在在 CPU 上比 Hugging Face快 327% ，而在 Databricks 中仅使用4 个节点。

在具有 8 个节点的 CPU 上扩展 Spark NLP

现在让我们通过添加 4 倍以上的 Nodes 使之前的集群翻倍，并使总数为8x Nodes 。顺便说一下，调整集群大小非常容易，您只需增加集群配置中的工作人员数量：

在 Databricks 中调整 Spark 集群的大小

具有 8 个节点的 Databricks — 仅限 CPU

这次让我们在8x 节点上运行相同的基准测试：

Spark NLP 图像分类管道在8x 节点上使用 CPU (oneDNN)——预测 34742 张图像

完成 34K 图像的类别预测需要 2 分半钟（ 161 秒）。让我们比较一下在8x 节点上使用 Spark NLP 与 Hugging Face 在 Databricks 上的 CPU 上的结果：

Spark NLP比 Hugging Face with 8x Nodes快 666%

可以看出，Spark NLP 现在在 CPU 上比 Hugging Face快 666% ，而在 Databricks 中仅使用8 个节点。

让我们在这里忽略 6 的数量！（如果它让你感觉更好，那就是 665.8%）

在具有 10 个节点的 CPU 上扩展 Spark NLP

为了使用 Spark NLP 完成我们在 Databricks 中对 CPU 的 ViT 模型预测，我将再次调整集群大小并将其增加到10 倍节点：

具有 10 个节点的 Databricks — 仅限 CPU

这次让我们在10 个节点上运行相同的基准测试：

Spark NLP 图像分类管道在10x 节点上使用 CPU (oneDNN) — 预测 34742 张图像

完成 34K 图像的类别预测只用了不到2 分钟（ 112 秒）。让我们将10x 节点上的这个结果与 Spark NLP 与 Databricks 上 CPU 上 Hugging Face 的所有先前结果进行比较：

Spark NLP比 Hugging Face with 10x Nodes快 1000%

这就是您如何通过在 Databricks 中使用Spark NLP来扩展来自 Hugging Face on 10x Nodes的Vision Transformer 模型！我们的管道现在比 CPU 上的 Hugging Face快 1000% 。

我们设法使我们的ViT管道比 Hugging Face快 1000%，而 Hugging Face 仅通过使用 Spark NLP 就卡在了一个单节点中，但我们只使用了CPU 。让我们看看是否可以通过在GPU 集群上扩展我们的管道来获得相同的改进。

在 AWS 上使用 GPU 的 Databricks 多节点

拥有基于 GPU 的多节点 Databricks 集群与拥有单节点集群几乎相同。唯一的区别是选择标准并保持相同的 ML/GPU 运行时和我们在单个节点上的 GPU 基准测试中选择的相同 AWS 实例规格。

我们还需要通过Libraries选项卡在这个新集群中安装 Spark NLP。和以前一样，您可以按照我在单节点 Databricks 中提到的步骤使用 GPU。

带 GPU 的 Databricks 多节点（标准）集群

在具有 2 个节点的 GPU 上扩展 Spark NLP

我们的多节点 Databricks GPU 集群使用相同的g4dn.8xlarge的 AWS GPU 实例，我们之前使用它来运行我们的基准测试，以在单节点 Databricks 集群上比较 Spark NLP 与 Hugging Face。

这是这次有 2 个节点的情况的摘要：

具有 2 个节点的 Databricks — 每个节点有 1 个 GPU

我将在这个具有2 个节点的 GPU 集群中运行相同的管道：

使用 GPU 的2 个节点上的 Spark NLP 图像分类管道——预测 34742 张图像

完成34K 图像的类别预测需要 4 分钟（ 231 秒）。让我们比较一下使用 Spark NLP 的2x 节点上的结果与 Databricks 中 GPU 上的 Hugging Face：

Spark NLP比 Hugging Face with 2x Nodes快 185%

具有2 个节点的 Spark NLP 几乎快3 倍（ 185% ）比使用GPU 时在 1 个单节点上拥抱脸。

在具有 4 个节点的 GPU 上扩展 Spark NLP

让我们将 GPU 集群的大小从 2x 节点调整为4x 节点。这是这次使用 GPU 的4x 节点的情况总结：

具有 4 个节点的 Databricks — 每个节点有 1 个 GPU

让我们在 4x 节点上运行相同的基准测试，看看会发生什么：

Spark NLP 图像分类管道在4x 节点上使用 GPU — 预测 34742 张图像

这次花了将近 2 分钟（ 118 秒）来完成对我们数据集中所有34K 图像的分类。让我们将其可视化，以便更好地了解单节点中的 Hugging Face 与多节点集群中的 Spark NLP 的含义：

Spark NLP比 Hugging Face with 4x Nodes快 458%

与 Hugging Face 相比，性能提高了 458% 。我们刚刚通过使用具有4 个节点的 Spark NLP 使我们的管道速度提高了5.6 倍。

在具有 8 个节点的 GPU 上扩展 Spark NLP

接下来，我将调整集群的大小，使其在我的 Databricks 中有8 个节点，总结如下：

具有 8 个节点的 Databricks — 每个节点有 1 个 GPU

提醒一下，每个 AWS 实例 ( g4dn.8xlarge ) 都有 1 个NVIDIA T4 GPU 16GB （15GB 可用内存）。让我们重新运行基准测试，看看我们是否可以发现任何改进，因为在任何分布式系统中横向扩展都有其开销，并且您不能只是继续添加机器：

使用 GPU 的8x 节点上的 Spark NLP 图像分类管道——预测 34742 张图像

在我们的 Databricks 集群中，使用8x 节点完成对34K 图像的分类花了将近一分钟（ 61 秒）。看来我们仍然设法提高了性能。让我们将这个结果放在单节点中 Hugging Face 与多节点集群中 Spark NLP 的先前结果旁边：

Spark NLP比 Hugging Face with 8x Nodes快 980%

具有8 个节点的 Spark NLP 在 GPU 上的速度几乎是 Hugging Face 的11 倍 (980%) 。

在具有 10 个节点的 GPU 上扩展 Spark NLP

与我们在 CPU 上的多节点基准测试类似，我想再调整一次 GPU 集群的大小以拥有10 个节点并根据最终节点数匹配它们。这个集群的最终总结如下：

具有 10 个节点的 Databricks — 每个节点有 1 个 GPU

让我们在这个特定的 GPU 集群中运行我们的最后一个基准测试（零代码更改）：

Spark NLP 图像分类管道在10x 节点上使用 GPU — 预测 34742 张图像

完成对超过34743 张图像的类别预测只用了不到一分钟（ 51 秒）。让我们将它们放在一起，看看我们如何扩展来自 Databricks 中 Spark NLP 管道中 Hugging Face 的 Vision Transformer 模型：

Spark NLP比 Hugging Face with 10x Nodes快 1200%

我们完成了！

通过在 Databricks 中使用Spark NLP ，我们设法扩展了来自 Hugging Face on 10x Nodes的Vision Transformer模型！与 GPU 上的 Hugging Face 相比，我们的管道现在速度提高了13 倍，性能提高了 1200% 。

让我们通过首先比较 CPU 和 GPU 之间的改进来总结所有这些基准测试，然后通过在 GPU 上使用 Spark NLP 从 Hugging Face CPU 到 Databricks 上的 10 倍节点，我们的流水线速度可以提高多少。

把它们放在一起：

Databricks：单节点和多节点

Spark NLP 🚀 在具有 CPU 的 10 个节点上比 Hugging Face 🤗 卡在具有 CPU 的单个节点上快 1000%（11 倍）

Spark NLP 🚀 在具有 GPU 的 10 个节点上比 Hugging Face 🤗 卡在具有 GPU 的单个节点上快 1192%（13 倍）

我们的 AWS CPU 实例和 AWS GPU 实例之间的价格差异如何？（我的意思是，如果你付出更多，你会得到更多，对吧？）

具有 CPU 的AWS m5d.8xlarge与具有 1 个 GPU 和类似规格的 AWS g4dn.8xlarge

好的，所以价格似乎几乎相同！考虑到这一点，如果从卡在单台机器上的CPU上的Hugging Face转变为在10 个节点和10 个 GPU上的Spark NLP ，你会得到什么改进？

GPU 上的Spark NLP比 CPU 上的 Hugging Face快 25 倍 (2366%)

Spark NLP 🚀 在具有 GPU 的 10 个节点上比 Hugging Face 🤗 在具有 CPU 的单个节点上快 2366%（25 倍）

最后的话

本着完全透明的精神，所有笔记本及其日志、屏幕截图，甚至带有数字的 Excel 表都在 GitHub 上提供
扩展 Spark NLP 需要零代码更改。从单个节点 Databricks 运行基准测试到 10 个节点意味着只需在同一个笔记本中重新运行相同的代码块
请记住，这两个库带有许多最佳实践，可以针对不同的用例在不同的环境中优化它们的速度和效率。例如，我没有谈论分区及其与 Apache Spark 中的并行性和分布的关系。有许多 Spark 配置可以微调集群，尤其是平衡 CPU 和 GPU 之间的任务数量。现在的问题是，是否有可能在我们用于基准测试的相同环境中加速它们中的任何一个？答案是100%！我试图为这两个库保留默认值和开箱即用功能的所有内容，以便为大多数用户提供简单性。
您可能希望将 Hugging Face 和其他基于 DL 的 Pythonish 库包装在 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 开始支持 TorchScript 和 ONNX Runtime 以及 TensorFlow 时会发生什么。
ML 和 ML GPU Databricks 运行时安装了 Hugging Face，这非常好。但这并不意味着 Hugging Face 在 Databricks 中很容易使用。 Hugging Face 的 Transformer 库不支持 DBFS（Databricks 的本机分布式文件系统）或 Amazon S3。正如您在笔记本中看到的，我必须下载数据集的压缩版本并提取它们以使用它们。这并不是 Databricks 和其他制作平台中的用户真正做事的方式。我们将数据保存在分布式文件系统中，实施了安全措施，其中大多数都足够大，无法通过个人计算机下载。我必须下载我已经在 DBFS 上拥有的数据集，压缩它们，将它们上传到 S3，将它们公开，然后在笔记本中重新下载它们。如果 Hugging Face 可以支持 DBFS/S3，则可以避免一个相当乏味的过程。