Scale Vision Transformers (ViT) além de abraçar o rosto

Acelere modelos de última geração em Hugging Face 🤗 até 2300% (25x vezes mais rápido) com Databricks, Nvidia e Spark NLP 🚀 ViT Sou um dos colaboradores do projeto de código aberto e, recentemente, esta biblioteca começou a oferecer suporte a modelos de de ponta a ponta. Eu uso Spark NLP e outras bibliotecas de código aberto ML/DL para trabalhar diariamente e decidi implantar um pipeline ViT para uma tarefa de classificação de imagem de última geração e fornecer comparações detalhadas entre e . Spark NLP Vision Transformers (ViT) Hugging Face Spark NLP O objetivo deste artigo é demonstrar como expandir os modelos do Vision Transformer (ViT) do Hugging Face e implantá-los em ambientes prontos para produção para inferência acelerada e de alto desempenho. No final, escalaremos um modelo ViT de Hugging Face em usando Databricks, Nvidia e Spark NLP. 25 vezes (2300%) Neste artigo irei: Uma breve introdução ao Vision Transformer (ViT) Benchmark Hugging Face dentro do servidor Dell em CPUs e GPUs Benchmark Spark NLP dentro do servidor Dell em CPUs e GPUs Benchmark abraçando o rosto dentro do Databricks Single Node em CPUs e GPUs Benchmark Spark NLP dentro do Databricks Single Node em CPUs e GPUs Benchmark Spark NLP dentro de Databricks dimensionado para 10x nós com CPUs e GPUs resuma tudo! No espírito de total transparência, todos os notebooks com seus logs, capturas de tela e até a planilha do Excel com números são fornecidos aqui no GitHub Introdução aos modelos do Vision Transformer (ViT) Em 2017, um grupo de pesquisadores do Google AI publicou um artigo que introduziu uma arquitetura de modelo de transformador que mudou todos os padrões de processamento de linguagem natural (NLP). O artigo descreve um novo mecanismo chamado auto-atenção como um modelo novo e mais eficiente para aplicações de linguagem. Por exemplo, as duas famílias mais populares de modelos baseados em transformadores são GPT e BERT. Um pouco da história do Transformer https://huggingface.co/course/chapter1/4 Há um ótimo capítulo sobre “ que eu recomendo para ler se você estiver interessado. Como funcionam os transformadores ” Embora esses novos modelos baseados no Transformer pareçam estar revolucionando as tarefas de PNL, seu uso em Visão Computacional (CV) permaneceu bastante limitado. O campo da Visão Computacional tem sido dominado pelo uso de redes neurais convolucionais (CNNs) e existem arquiteturas populares baseadas em CNNs (como ResNet). Esse era o caso até que outra equipe de pesquisadores, desta vez no Google Brain, apresentou o (ViT) em junho de 2021 em um artigo intitulado: “Vision Transformer” “ An Image vale 16x16 Words: Transformers for Image Recognition at Scale ” Este artigo representa um avanço quando se trata de reconhecimento de imagem usando o mesmo mecanismo de auto-atenção usado em modelos baseados em transformadores, como BERT e GPT, como acabamos de discutir. Em modelos de linguagem baseados em transformação como BERT, a entrada é uma frase (por exemplo, uma lista de palavras). No entanto, nos modelos ViT, primeiro dividimos uma imagem em uma grade de patches de sub-imagem, então incorporamos cada patch com um projeto linear antes de cada patch incorporado se tornar um token. O resultado é uma sequência de patches de embeddings que passamos para o modelo semelhante ao BERT. Uma visão geral da estrutura do modelo ViT, conforme apresentado no artigo original de 2021 do Google Research O Vision Transformer se concentra em maior precisão, mas com menos tempo de computação. Olhando para os benchmarks publicados no artigo, podemos ver que o tempo de treinamento em relação ao conjunto de dados (publicado pelo Google em junho de 2020) foi reduzido em 80%, embora o estado de precisão seja mais ou menos o mesmo. Para mais informações sobre o desempenho do ViT hoje, você deve visitar sua página em Noisy Student Papers With Code : Comparação com o estado da arte em benchmarks populares de classificação de imagens. ( ) https://arxiv.org/pdf/2010.11929.pdf Também é importante mencionar que, depois de treinar um modelo por meio da arquitetura ViT, você pode pré-treinar e ajustar seu transformador da mesma forma que faz no NLP. (isso é muito legal na verdade!) Se compararmos modelos de ViT com CNNs, podemos ver que eles têm maior precisão com custos de computação muito menores. Você pode usar modelos ViT para uma variedade de tarefas downstream em Visão Computacional, como classificação de imagens, detecção de objetos e segmentação de imagens. Isso também pode ser específico do domínio em Saúde. Você pode pré-treinar/ajustar seus modelos de ViT para , , , e .¹ fraturas de fêmur enfisema câncer de mama COVID-19 doença de Alzheimer Deixarei as referências no final deste artigo caso você queira se aprofundar em como os modelos ViT funcionam. [1]: Mergulho Profundo: Vision Transformers On Hugging Face Optimum Graphcore https://huggingface.co/blog/vision-transformers Alguns modelos ViT em ação Modelo Vision Transformer (ViT) ( ) pré-treinado no ImageNet-21k (14 milhões de imagens, 21.843 classes) com resolução de 224x224 e ajustado no ImageNet 2012 (1 milhão de imagens, 1.000 classes) em resolução 224x224: vit-base-patch16–224 https://huggingface.co/google/vit-base-patch16-224 Modelos de ViT ajustados usados para classificação de alimentos: — https://huggingface.co/nateraw/food https://huggingface.co/julien-c/hotdog-not-hotdog No entanto, existem limitações e restrições para qualquer modelo DL/ML quando se trata de previsão. Não existe um modelo com 100% de precisão, portanto, lembre-se de usá-los para algo importante como Saúde: A https://www.akc.org/expert-advice/lifestyle/do-you-live-in-dog-state-or-cat-state/ — : https://huggingface.co /julien-c/cachorro-quente-não-cachorro-quente imagem foi retirada de: modelo ViT Podemos usar esses modelos do Hugging Face ou ajustar novos modelos ViT e usá-los para inferência na produção real? Como podemos dimensioná-los usando serviços gerenciados para cálculos distribuídos, como AWS EMR, Azure Insight, GCP Dataproc ou Databricks? Esperançosamente, algumas delas serão respondidas até o final deste artigo. Que comecem os benchmarks! Alguns detalhes sobre nossos benchmarks: ImageNet mini: (>3K) — (>34K) 1- Conjunto de dados: amostra completo Baixei o conjunto de dados ImageNet 1000 (mini) do Kaggle: https://www.kaggle.com/datasets/ifigotin/imagenetmini-1000 Eu escolhi o diretório train com mais de e o chamei pois tudo que eu precisava era de imagens suficientes para fazer benchmarks que demoram mais. Além disso, selecionei aleatoriamente menos de 10% do conjunto de dados completo e o chamei , que possui para meus benchmarks menores e também para ajustar os parâmetros corretos, como o tamanho do lote. 34K de imagens de imagenet-mini, de imagenet-mini-sample 3544 imagens O “ ” do Google 2- Modelo: vit-base-patch16–224 Estaremos usando este modelo do Google hospedado no Hugging Face: https://huggingface.co/google/vit-base-patch16-224 🤗 & 🚀 3- Bibliotecas: Transformers Spark NLP Comparação de rosto abraçado em um servidor Bare Metal Modelo ViT em um Dell PowerEdge C4130 O que é um servidor bare-metal? Um servidor - é apenas um computador físico que está sendo usado apenas por um usuário. Não há hipervisor instalado nesta máquina, não há virtualizações e tudo está sendo executado diretamente no sistema operacional principal (Linux — Ubuntu) — as especificações detalhadas de CPUs, GPUs e a memória desta máquina estão dentro dos notebooks. bare metal Como meus testes iniciais e quase todas as postagens de blog escritas pela equipe de engenharia do Hugging Face comparando a velocidade de inferência entre os mecanismos DL revelaram, o melhor desempenho para inferência na biblioteca Hugging Face (Transformer) é obtido usando o PyTorch sobre o TensorFlow. Não tenho certeza se isso se deve ao TensorFlow ser um cidadão de segunda classe em Hugging Face devido a menos recursos suportados, menos modelos suportados, menos exemplos, tutoriais desatualizados e pesquisas anuais nos últimos 2 anos respondidas por usuários que perguntam mais sobre o TensorFlow ou o PyTorch apenas tem uma latência menor na inferência na CPU e na GPU. O TensorFlow continua sendo a estrutura de aprendizado profundo mais usada Independentemente do motivo, escolhi o PyTorch na biblioteca Hugging Face para obter os melhores resultados para nossos benchmarks de classificação de imagem. Este é um trecho de código simples para usar um modelo ViT (PyTorch, é claro) em Hugging Face: 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] ) Isso pode parecer simples prever uma imagem como uma entrada, mas não é adequado para grandes quantidades de imagens, especialmente em uma GPU. Para evitar a previsão de imagens sequencialmente e aproveitar hardware acelerado, como GPU, é melhor alimentar o modelo com lotes de imagens, o que é possível em Hugging Face via . Desnecessário dizer que você pode implementar sua técnica de lote estendendo os Pipelines do Hugging Face ou fazendo isso por conta própria. Pipelines Um pipeline simples para ficará assim: classificação de imagens 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 ) De acordo com a documentação, baixei/carreguei para o extrator e modelo de recurso (pontos de verificação PyTorch, é claro) para usá-los no pipeline com classificação de imagem como tarefa. Há três coisas neste pipeline que são importantes para nossos benchmarks: google/vit-base-patch16–224 : Se for -1 (padrão), ele usará apenas CPUs, enquanto se for um número int positivo, executará o modelo no ID do dispositivo CUDA associado. (é melhor ocultar as GPUs e forçar o PyTorch a usar a CPU e não apenas confie neste número aqui). > dispositivo Quando o pipeline vai usar o (ao passar um conjunto de dados, na GPU para um modelo Pytorch), o tamanho do lote a ser usado, para inferência nem sempre é benéfico. > batch_size: DataLoader Você precisa usar DataLoader ou PyTorch Dataset para aproveitar ao máximo o agrupamento em pipelines Hugging Face em uma GPU. > Antes de avançarmos com os benchmarks, você precisa saber uma coisa sobre o agrupamento em Hugging Face Pipelines para inferência, que nem sempre funciona. Conforme declarado na documentação do Hugging Face, definir pode não aumentar o desempenho do seu pipeline. Isso pode desacelerar seu pipeline: batch_size https://huggingface.co/docs/transformers/main_classes/pipelines#pipeline-batching Para ser justo, em meus benchmarks usei uma variedade de tamanhos de lote começando em 1 para garantir que encontraria o melhor resultado entre eles. Foi assim que comparei o pipeline Hugging Face na CPU: 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 Vamos dar uma olhada nos resultados de nosso primeiro benchmark para o pipeline de classificação de imagem Hugging Face em CPUs sobre o conjunto de dados ImageNet de amostra (3K): Envolvendo o pipeline de classificação de imagem facial em CPUs — prevendo 3.544 imagens Como pode ser visto, demorou cerca de 3 minutos ( para concluir o processamento de cerca de do conjunto de dados de amostra. Agora que sei qual tamanho de lote (8) é o melhor para meu pipeline/conjunto de dados/hardware, posso usar o mesmo pipeline em um conjunto de dados maior ( ) com este tamanho de lote: 188 segundos) 3.544 imagens imagens de 34K Abraçando o pipeline de classificação de imagem facial em CPUs — prevendo 34.745 imagens Desta vez, demorou cerca de 31 minutos ( ) para concluir a previsão de classes para nas CPUs. 1.879 segundos 34.745 imagens Para melhorar a maioria dos modelos de aprendizado profundo, especialmente esses novos modelos baseados em transformadores, deve-se usar hardware acelerado, como GPU. Vamos dar uma olhada em como comparar o mesmo pipeline nos mesmos conjuntos de dados, mas desta vez em um dispositivo . Conforme mencionado anteriormente, precisamos alterar o para um ID de dispositivo CUDA como 0 (a primeira GPU): GPU dispositivo 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 Além de definir device=0, também segui a maneira recomendada de executar um modelo PyTorch em um dispositivo GPU via .to(device). Como estamos usando hardware acelerado (GPU), também aumentei o tamanho máximo do lote para meus testes para 1024 para encontrar o melhor resultado. Vamos dar uma olhada em nosso pipeline de classificação de imagem Hugging Face em um dispositivo GPU sobre o conjunto de dados ImageNet de amostra (3K): Envolvendo o pipeline de classificação de imagem facial em uma GPU — prevendo 3.544 imagens Como pode ser visto, demorou cerca de para concluir o processamento de cerca de 3.544 de nosso conjunto de dados imagenet-mini-sample em um . O lote melhorou a velocidade, especialmente em comparação com os resultados provenientes das CPUs, no entanto, as melhorias pararam em torno do tamanho do lote de 32. Embora os resultados sejam os mesmos após o tamanho do lote 32, escolhi o tamanho do lote para meu benchmark maior utilizar memória GPU suficiente também. 50 segundos imagens dispositivo GPU 256 Envolvendo o pipeline de classificação de imagem facial em uma GPU — prevendo 34.745 imagens Desta vez, nosso benchmark levou cerca de 8:17 minutos ( ) para concluir a previsão de classes para em um dispositivo . Se compararmos os resultados de nossos benchmarks em CPUs e um dispositivo GPU, podemos ver que a GPU aqui é a vencedora: 497 segundos 34.745 imagens GPU Hugging Face (PyTorch) é até 3,9 vezes mais rápido em GPU versus CPU Usei o Hugging Face Pipelines para carregar os pontos de verificação do ViT PyTorch, carregar meus dados no conjunto de dados da tocha e usar o lote fornecido pronto para uso no modelo na CPU e na GPU. A é até mais rápida em comparação com a execução dos mesmos pipelines nas CPUs. GPU aproximadamente 3,9 vezes Melhoramos nosso pipeline ViT para executar a classificação de imagem usando um em vez de CPUs, mas podemos ainda mais nosso pipeline em e em uma única máquina antes de escalá-lo para várias máquinas? Vamos dar uma olhada na biblioteca Spark NLP. dispositivo GPU melhorar CPU GPU Spark NLP: processamento de linguagem natural de última geração Spark NLP é uma biblioteca de processamento de linguagem natural de última geração de código aberto ( ) https://github.com/JohnSnowLabs/spark-nlp O Spark NLP é uma biblioteca de processamento de linguagem natural de última geração construída sobre o Apache Spark. Ele fornece anotações NLP simples, de alto desempenho e precisas para pipelines de aprendizado de máquina que escalam facilmente em um ambiente distribuído. O Spark vem com mais de 7.000 e pré-treinados em mais de . Ele também oferece tarefas como tokenização, segmentação de palavras, marcação de parte da fala, incorporação de palavras e frases, reconhecimento de entidade nomeada, análise de dependência, verificação ortográfica, classificação de texto, análise de sentimento, classificação de token, tradução automática (mais de 180 idiomas), Resumo e resposta a perguntas, geração de texto, classificação de imagens (ViT) e muitas outras . NLP pipelines modelos 200 idiomas tarefas de PNL Spark NLP é a única biblioteca NLP de código aberto em produção que oferece transformadores de última geração, como , , , , , , , , , , , , Google , , e Vision Transformer ( ) não apenas para e , mas também para o ecossistema JVM ( , e ) em escala, estendendo o Apache Spark nativamente. BERT CamemBERT ALBERT ELECTRA XLNet DistilBERT RoBERTa DeBERTa XLM-RoBERTa Longformer ELMO Universal Sentence Encoder T5 MarianMT GPT2 ViT Python R Java Scala Kotlin Comparando o Spark NLP em um servidor Bare Metal Modelos ViT em um Dell PowerEdge C4130 O Spark NLP tem os mesmos recursos ViT para de imagem como Hugging Face que foram adicionados na recente versão . O recurso é chamado uso um código simples para usar esse recurso no Spark NLP é assim: classificação 4.1.0 de ViTForImageClassification, tem mais de 240 modelos pré-treinados prontos para e 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 ) Se compararmos o Spark NLP e o Hugging Face lado a lado para baixar e carregar um modelo ViT pré-treinado para uma previsão de classificação de imagens, além de carregar imagens e usar cálculos posteriores como argmax fora da biblioteca Hugging Face, ambos são bastante diretos. Além disso, ambos podem ser salvos e servir posteriormente como um pipeline para reduzir essas linhas a apenas 1 linha de código: Carregando e usando modelos ViT para classificação de imagens no Spark NLP (à esquerda) e Hugging Face (à direita) Como o Apache Spark possui um conceito chamado , ele não inicia a execução do processo até que uma seja chamada. As ações no Apache Spark podem ser .count() ou .show() ou .write() e muitas outras operações baseadas em RDD que não abordarei agora e você não precisará conhecê-las para este artigo. Normalmente, escolho count() a coluna de destino ou write() os resultados em discos para acionar a execução de todas as linhas no DataFrame. Além disso, como os benchmarks Hugging Face, farei um loop pelos tamanhos de lote selecionados para garantir que posso ter todos os resultados possíveis sem perder o melhor resultado. Lazy Evaluation ACTION Agora, sabemos como carregar o(s) modelo(s) ViT no Spark NLP, também sabemos como acionar uma ação para forçar a computação em todas as linhas em nosso DataFrame para benchmark, e tudo o que resta aprender é oneDNN de . Como o mecanismo DL no Spark NLP é o TensorFlow, você também pode habilitar o oneDNN para melhorar a velocidade nas CPUs (como tudo mais, você precisa testar isso para ter certeza de que melhora a velocidade e não o contrário). Também usarei esse sinalizador além das CPUs normais sem o oneDNN ativado oneAPI Deep Neural Biblioteca de rede (oneDNN) Agora que sabemos que todos os modelos ViT da Hugging Face também estão disponíveis no Spark NLP e como usá-los em um pipeline, repetiremos nossos benchmarks anteriores no servidor bare-metal Dell para comparar CPU x GPU. Vamos dar uma olhada nos resultados do pipeline de classificação de imagem do Spark NLP em CPUs em nosso conjunto de dados ImageNet de amostra (3K): Pipeline de classificação de imagem Spark NLP em uma CPU sem oneDNN — prevendo 3.544 imagens Demorou cerca de 2,1 minutos ( para concluir o processamento de cerca de de nosso conjunto de dados de amostra. Ter um conjunto de dados menor para experimentar diferentes tamanhos de lote é útil para escolher o tamanho de lote certo para sua tarefa, seu conjunto de dados e sua máquina. Aqui está claro que o é o melhor tamanho para nosso pipeline entregar o melhor resultado. 130 segundos) 3.544 imagens tamanho do lote 16 Eu também gostaria de habilitar o para ver se nesta situação específica ele melhora meu benchmark comparando com as CPUs sem oneDNN. Você pode habilitar o oneDNN no Spark NLP definindo a variável de ambiente como Vamos ver o que acontece se eu habilitar esse sinalizador e executar novamente o benchmark anterior na CPU para encontrar o melhor tamanho de lote: oneDNN TF_ENABLE_ONEDNN_OPTS 1. Pipeline de classificação de imagens Spark NLP em uma CPU com oneDNN — prevendo 3.544 imagens OK, habilitar claramente o oneDNN para o TensorFlow nessa situação específica melhorou nossos resultados em pelo menos 14%. Como não precisamos fazer/alterar nada e basta dizer export TF_ENABLE_ONEDNN_OPTS=1, vou usar isso para o benchmark com um conjunto de dados maior também para ver a diferença. Aqui é cerca de segundos mais rápido, mas 14% no conjunto de dados maior pode reduzir minutos de nossos resultados. Agora que sei que o tamanho do lote de 16 para CPU sem oneDNN e o tamanho do lote de 2 para CPU com oneDNN ativado têm os melhores resultados, posso continuar usando o mesmo pipeline em um conjunto de dados maior ( ): imagens de 34K Pipeline de classificação de imagens Spark NLP em CPUs sem oneDNN — prevendo 34745 imagens Desta vez, nosso benchmark levou cerca de 24 minutos ( ) para concluir a previsão de classes para em um dispositivo de sem o oneDNN habilitado. Agora vamos ver o que acontece se eu habilitar oneDNN para TensorFlow e usar o tamanho do lote de 2 (os melhores resultados): 1423 segundos 34745 imagens CPU Pipeline de classificação de imagem Spark NLP em CPUs com oneDNN — prevendo 34745 imagens Desta vez demorou cerca de 21 minutos ( ). Conforme esperado de nossos benchmarks de amostra, podemos ver cerca nos resultados que economizaram minutos em comparação com a não ativação do oneDNN. 1278 segundos de 11% de melhorias Vamos dar uma olhada em como comparar o mesmo pipeline em um dispositivo GPU. No Spark NLP, tudo o que você precisa para usar a GPU é iniciá-la com gpu=True ao iniciar a sessão Spark NLP: faísca = sparknlp.start(gpu=Verdadeiro) # você pode definir a memória aqui também spark = sparknlp.start(gpu=True, memory="16g") É isso! Se você tiver algo em seu pipeline que possa ser executado na GPU, ele o fará automaticamente, sem a necessidade de fazer nada explicitamente. Vamos dar uma olhada em nosso pipeline de classificação de imagem Spark NLP em um dispositivo GPU sobre o conjunto de dados ImageNet de amostra (3K): Pipeline de classificação de imagens Spark NLP em uma GPU — prevendo 3.544 imagens Por curiosidade para ver se minha cruzada para encontrar um bom tamanho de lote em um conjunto de dados menor estava correta, executei o mesmo pipeline com GPU em um conjunto de dados maior para ver se o tamanho do lote 32 teria o melhor resultado: Pipeline de classificação de imagens Spark NLP em uma GPU — prevendo 34.745 imagens Felizmente, é o tamanho do lote 32 que produz o melhor tempo. Demorou cerca de 4 minutos e meio ( 277 segundos). Vou pegar os resultados das , pois foram mais rápidos e vou compará-los com os resultados da : CPUs com oneDNN GPU Spark NLP (TensorFlow) é até 4,6 vezes mais rápido em GPU versus CPU (oneDNN) Isso é ótimo! Podemos ver que o Spark NLP na GPU é até que as CPUs, mesmo com o oneDNN ativado. 4,6 vezes mais rápido Vamos dar uma olhada em como esses resultados são comparados aos benchmarks Hugging Face: O Spark NLP é 65% mais rápido do que Hugging Face em CPUs na previsão de classes de imagem para o conjunto de dados de amostra com imagens de 3K e 47% no conjunto de dados maior com imagens de 34K. O Spark NLP também é 79% mais rápido que o Hugging Face em um único conjunto de dados maior de inferência de GPU com imagens de 34K e até 35% mais rápido em um conjunto de dados menor. O Spark NLP foi mais rápido do que o Hugging Face em uma única máquina usando CPU ou GPU — classificação de imagens usando o Vision Transformer (ViT) Spark NLP & Hugging Face no Databricks Todos os seus dados, análises e IA em uma plataforma O que é Databricks? Databricks é uma plataforma baseada em nuvem com um conjunto de ferramentas de engenharia de dados e ciência de dados que são amplamente utilizadas por muitas empresas para processar e transformar grandes quantidades de dados. Os usuários usam o Databricks para muitas finalidades, desde o processamento e transformação de grandes quantidades de dados até a execução de muitos pipelines ML/DL para explorar os dados. esta foi minha interpretação do Databricks, ele vem com muitos outros recursos e você deve dar uma olhada: Isenção de responsabilidade: https://www.databricks.com/product/data-lakehouse Databricks suporta nuvens AWS, Azure e GCP: https://www.databricks.com/product/data-lakehouse Abraçando o rosto no nó único do Databricks com CPUs na AWS O Databricks oferece um tipo de cluster quando você está criando um cluster adequado para quem deseja usar o Apache Spark com apenas 1 máquina ou usar aplicativos não Spark, especialmente bibliotecas Python baseadas em ML e DL. Hugging Face já vem instalado quando você escolhe o tempo de execução do Databricks 11.1 ML. Aqui está a aparência das configurações de cluster para meus Databricks de nó único (somente CPUs) antes de iniciarmos nossos benchmarks: “Single Node” Cluster de nó único Databricks — tempo de execução da CPU O resumo deste cluster que usa a instância na é que ele possui 1 driver (apenas 1 nó), de memória, de CPU e custa por hora. Você pode ler sobre “DBU” na AWS aqui: m5n.8xlarge AWS 128 GB 32 núcleos 5,71 DBU https://www.databricks.com/product/aws-pricing Cluster único do Databricks — perfil de instância da AWS Vamos replicar nossos benchmarks da seção anterior (servidor Dell bare-metal) aqui em nossos Databricks de nó único (somente CPUs). Começamos com Hugging Face e nosso conjunto de dados de tamanho de amostra do ImageNet para descobrir qual tamanho de lote é bom para que possamos usá-lo para o conjunto de dados maior, já que isso foi uma prática comprovada nos benchmarks anteriores: Abraçando o pipeline de classificação de imagem facial em CPUs de nó único do Databricks — prevendo 3544 imagens Demorou cerca de 2 minutos e meio ( ) para concluir o processamento de cerca de de nosso conjunto de dados de amostra em um Databricks de nó único que usa apenas . O melhor tamanho de lote nesta máquina usando apenas CPUs é , então vou usá-lo para executar o benchmark no conjunto de dados maior: 149 segundos 3.544 imagens CPUs 8 Abraçando o pipeline de classificação de imagem facial em CPUs de nó único do Databricks — prevendo 34745 imagens No conjunto de dados maior com mais de 34 mil imagens, demorou cerca de 20 minutos e meio ( ) para concluir a previsão de classes para essas imagens. Para nosso próximo benchmark, precisamos ter um cluster Databricks de nó único, mas desta vez precisamos ter um tempo de execução baseado em GPU e escolher uma instância AWS baseada em GPU. 1233 segundos Abraçando o rosto no nó único do Databricks com uma GPU na AWS Vamos criar um novo cluster e desta vez vamos escolher um runtime com GPU que neste caso é chamado de 11.1 ML (inclui Apache Spark 3.3.0, GPU, Scala 2.12) e vem com todos os softwares CUDA e NVIDIA necessários instalados. A próxima coisa que precisamos é selecionar também uma instância da AWS que tenha uma GPU e eu escolhi que tem 1 GPU e um número semelhante de núcleos/memória como o outro cluster. Esta instância de GPU vem com um e 15 GB memória GPU utilizável). g4dn.8xlarge Tesla T4 16 GB de memória ( Cluster de nó único Databricks — tempo de execução da GPU Este é o resumo do nosso cluster de nó único como o anterior e é o mesmo em termos de número de núcleos e quantidade de memória, mas vem com uma GPU Tesla T4: Cluster de nó único do Databricks — perfil de instância da AWS Agora que temos um cluster de nó único com uma GPU, podemos continuar nossos benchmarks para ver o desempenho do Hugging Face nesta máquina no Databricks. Vou executar o benchmark no conjunto de dados menor para ver qual tamanho de lote é mais adequado para nossa máquina baseada em GPU: Abraçando o pipeline de classificação de imagem facial na CPU de nó único do Databricks — prevendo 3.544 imagens Demorou cerca de um minuto ( ) para concluir o processamento de cerca de de nosso conjunto de dados de exemplo em nosso cluster Databricks de nó único com um dispositivo GPU. O lote melhorou a velocidade se observarmos o resultado do tamanho do lote 1, no entanto, após o tamanho do lote 8, os resultados praticamente permaneceram os mesmos. Embora os resultados sejam os mesmos após o tamanho do lote 8, escolhi o tamanho do lote para meu benchmark maior para utilizar mais memória da GPU também. (para ser honesto, 8 e 256 tiveram praticamente o mesmo desempenho) 64 segundos 3.544 imagens 256 Vamos executar o benchmark no conjunto de dados maior e ver o que acontece com o tamanho do lote 256: Abraçando o pipeline de classificação de imagem facial na CPU de nó único do Databricks — prevendo 34745 imagens Em um conjunto de dados maior, levou quase 11 minutos ( ) para concluir a previsão de classes para mais de 34 mil imagens. Se compararmos os resultados de nossos benchmarks em um único nó com CPUs e um único nó que vem com 1 GPU, podemos ver que o nó GPU aqui é o vencedor: 659 segundos Hugging Face (PyTorch) é até 2,3 vezes mais rápido em GPU versus CPU A é até mais rápida em comparação com a execução do mesmo pipeline em CPUs em Hugging Face em Databricks Single Node GPU aproximadamente 2,3 vezes Agora vamos executar os mesmos benchmarks usando o Spark NLP nos mesmos clusters e nos mesmos conjuntos de dados para compará-lo com o Hugging Face. Comparando o Spark NLP em um único nó Databricks Primeiro, vamos instalar o Spark NLP em suas CPUs Databricks de nó único: Na guia dentro do seu cluster, você precisa seguir estas etapas: — Instalar Novo -> PyPI -> -> Instalar — Instalar Novo -> Maven -> Coordenadas -> -> Instalar — Adicionará ` ` a `Cluster->Advacend Options->Spark->Environment variables` para habilitar oneDNN Bibliotecas spark-nlp==4.1.0 com.johnsnowlabs.nlp:spark-nlp_2.12:4.1.0 TF_ENABLE_ONEDNN_OPTS=1 Como instalar o Spark NLP no Databricks em CPUs para Python, Scala e Java Spark NLP em Databricks Single Node com CPUs na AWS Agora que temos o Spark NLP instalado em nosso cluster de nó único Databricks, podemos repetir os benchmarks para uma amostra e conjuntos de dados completos na CPU e na GPU. Vamos começar com o benchmark em CPUs primeiro sobre o conjunto de dados de amostra: Pipeline de classificação de imagem Spark NLP em CPUs de nó único Databricks (oneDNN) — prevendo 3544 imagens Demorou cerca de 2 minutos ( ) para concluir o processamento de e prever suas classes no mesmo cluster Databricks de nó único com CPUs que usamos para Hugging Face. Podemos ver que o tamanho do lote de 16 tem o melhor resultado, então usarei isso no próximo benchmark no conjunto de dados maior: 111 segundos 3.544 imagens Pipeline de classificação de imagem Spark NLP em CPUs de nó único Databricks (oneDNN) — prevendo 34742 imagens No conjunto de dados maior com mais de , demorou cerca de 18 minutos ( ) para concluir a previsão de classes para essas imagens. Em seguida, repetirei os mesmos benchmarks no cluster com GPU. 34 mil imagens 1.072 segundos Databricks Single Node com uma GPU na AWS Primeiro, instale o Spark NLP em sua Single Node Databricks (a única diferença é o uso de “ do Maven): GPU spark-nlp-gpu” Instale o em seu — Na guia dentro do cluster, você precisa seguir estas etapas: — Instalar Novo -> PyPI -> -> Instalar — Instalar Novo -> Maven -> Coordenadas -> -> Instalar Spark NLP cluster Databricks Bibliotecas spark-nlp==4.1.0 com.johnsnowlabs.nlp:spark-nlp-gpu_2.12:4.1.0 Como instalar o Spark NLP no Databricks em GPUs para Python, Scala e Java Vou executar o benchmark no conjunto de dados menor para ver qual tamanho de lote é mais adequado para nossa máquina baseada em GPU: Pipeline de classificação de imagem Spark NLP na GPU de nó único do Databricks — prevendo 3544 imagens Demorou menos de um minuto ( ) para concluir o processamento de cerca de de nosso conjunto de dados de amostra em nossos Databricks de nó único com um dispositivo GPU. Podemos ver que o teve o melhor desempenho neste caso de uso específico, então executarei o benchmark no conjunto de dados maior: 47 segundos 3.544 imagens tamanho do lote 8 Pipeline de classificação de imagem Spark NLP na GPU de nó único Databricks — prevendo 34742 imagens Em um conjunto de dados maior, levou quase 7 minutos e meio ( ) para concluir a previsão de classes para mais de . Se compararmos os resultados de nossos benchmarks em um único nó com CPUs e um único nó que vem com 1 GPU, podemos ver que o nó GPU aqui é o vencedor: 435 segundos 34 mil imagens O Spark NLP é até 2,5 vezes mais rápido em GPU versus CPU em Databricks Single Node Isso é ótimo! Podemos ver que o Spark NLP na GPU é até que as CPUs, mesmo com oneDNN ativado (oneDNN melhora os resultados em CPUs entre 10% a 20%). 2,5 vezes mais rápido Vamos dar uma olhada em como esses resultados são comparados aos benchmarks Hugging Face no mesmo cluster Databricks Single Node: é até mais rápido do que Hugging Face em na previsão de classes de imagem para o conjunto de dados de amostra com imagens 3K e até no conjunto de dados maior com imagens 34K. também é do que Hugging Face em uma única para um conjunto de dados maior com imagens de 34K e até em um conjunto de dados menor com imagens de 3K. O Spark NLP 15% CPUs 34% O Spark NLP 51% mais rápido GPU 36% mais rápido é mais rápido em e vs. Hugging em Databricks Single Node Spark NLP CPUs GPUs Face Dimensionamento além de uma única máquina Até agora, estabelecemos que o na é mais rápido do que o nas em um servidor bare-metal e Databricks Single Node. Isso é o que você espera ao comparar GPU x CPU com esses novos modelos baseados em transformador. Hugging Face GPU Hugging Face CPUs Também estabelecemos que o supera o para o mesmo pipeline (modelo ViT), nos mesmos conjuntos de dados, tanto no servidor bare-metal quanto no cluster de nó único Databricks, e tem melhor desempenho em dispositivos de CPU e GPU. Por outro lado, isso não era algo que eu esperava. Quando eu estava preparando este artigo, esperava que a inferência do TensorFlow no Spark NLP fosse um pouco mais lenta do que a inferência no Hugging Face usando PyTorch ou pelo menos pescoço a pescoço. Eu estava mirando nesta seção, . Mas parece que o Spark NLP é mais rápido que o Hugging Face, mesmo em uma única máquina, tanto na quanto na , em conjuntos de dados e . Spark NLP Hugging Face dimensionando o pipeline além de uma única máquina CPU GPU pequenos grandes E se você quiser tornar seu pipeline de ViT ainda mais rápido? E se você tiver conjuntos de dados ainda maiores e simplesmente não conseguir encaixá-los em uma máquina ou se demorar muito para obter os resultados de volta? Pergunta: Expansão! Isso significa que, em vez de redimensionar a mesma máquina, adicione mais máquinas ao seu cluster. Você precisa de algo para gerenciar todos esses trabalhos/tarefas/agendamento de DAGs/gerenciar tarefas com falha/etc. e esses têm suas despesas gerais, mas se você precisa que algo seja mais rápido ou possível (além de uma única máquina), você deve usar algum tipo de sistema distribuído. Resposta: tornar sua máquina maior ou mais rápida para que ela possa lidar com mais carga. Ampliação = adicionar mais máquinas em paralelo para distribuir uma carga. Expansão = Ampliando o Rosto de Abraço: Observar a página no site oficial do Hugging Face sugere que a inferência de escala só é possível usando Multi-GPUs. Conforme descrevemos o que é o escalonamento horizontal, ele ainda está preso em uma única máquina: https://huggingface.co/docs/transformers/performance Além disso, sem contar que a solução para em Hugging Face não existe no momento: Multi-GPUs inferência https://huggingface.co/docs/transformers/perf_infer_gpu_many Portanto, parece que não há uma maneira nativa/oficial de pipelines do Hugging Face. Você pode implementar sua arquitetura consistindo em alguns microsserviços, como uma fila de tarefas, protocolos de mensagens, back-end de APIs RESTful e alguns outros componentes necessários para distribuir cada solicitação em diferentes máquinas, mas isso dimensiona as solicitações de usuários individuais em vez de dimensionar o sistema real em si. expandir os Além disso, a latência desses sistemas não é comparável com sistemas distribuídos nativamente, como o Apache Spark (o gRPC pode diminuir essa latência, mas ainda não é competitivo). Sem mencionar o problema de ponto único de falha, gerenciamento de trabalhos/tarefas/entradas com falha e centenas de outros recursos que você obtém imediatamente do Apache Spark que agora você precisa implementar/manter sozinho. Há uma postagem de blog no site do Hugging Face retratando a mesma arquitetura, dimensionando os endpoints REST para atender a mais usuários: “ ” - acredito que outras empresas estão usando abordagens semelhantes para expandir o Hugging Face, no entanto , todos estão dimensionando o número de usuários/solicitações que atingem os terminais REST de inferência. Além disso, você não pode dimensionar Hugging Face dessa maneira no Implantando 🤗 ViT no Kubernetes com TF Servindo Databricks. Por exemplo, a inferência dentro do fastAPI é 10 vezes mais lenta que a inferência local: https://towardsdatascience.com/hugging-face-transformer-inference-under-1-millisecond-latency-e1be0057a51c Depois que o Hugging Face oferecer algumas soluções nativas para escalar, executarei novamente os benchmarks. Até então, não há escalonamento quando você precisa percorrer o conjunto de dados de uma única máquina para atingir os pontos de extremidade REST em um algoritmo round-robin. (pense novamente sobre a parte em que agrupamos linhas/sequências/imagens para alimentar a GPU de uma só vez, então você entenderá) Escalando o Spark NLP: O Spark NLP é uma extensão do Spark ML, portanto, escala nativamente e perfeitamente em todas as plataformas suportadas pelo Apache Spark, como (e não limitado) Databricks, AWS EMR, Azure Insight, GCP Dataproc, Cloudera, SageMaker, Kubernetes e muitos mais. Zero alterações de código são necessárias! O Spark NLP pode escalar de uma única máquina para um número infinito de máquinas sem alterar nada no código! Você também não precisa exportar nenhum modelo do Spark NLP para usá-lo em uma biblioteca totalmente diferente para acelerar ou dimensionar a inferência. Ecossistema Spark NLP: integrações otimizadas, testadas e suportadas Databricks Multi-Node com CPUs na AWS Vamos criar um cluster e desta vez escolhemos dentro do . Isso significa que podemos ter mais de 1 nó em nosso cluster, o que na terminologia do Apache Spark significa 1 Driver e N número de Trabalhadores (Executores). Standard modo Cluster Também precisamos instalar o Spark NLP neste novo cluster por meio da guia Bibliotecas. Você pode seguir as etapas que mencionei na seção anterior para Databricks de nó único com CPUs. Como você pode ver, escolhi a mesma instância da AWS baseada em CPU que usei para comparar Hugging Face e Spark NLP para que possamos ver como ela se expande quando adicionamos mais nós. É assim que nossas configurações de Cluster se parecem: Databricks cluster de vários nós (padrão) com apenas CPUs Vou reutilizar o mesmo pipeline Spark NLP que usei em benchmarks anteriores e também usarei apenas o conjunto de dados maior com imagens de 34K. Vamos começar! (sem necessidade de alterar nenhum código) Escale o Spark NLP em CPUs com 2x nós Databricks com 2x nós — apenas CPUs Vamos apenas adicionar mais 1 nó e fazer o total das máquinas que farão o processamento para 2 máquinas. Não vamos esquecer a beleza do Spark NLP quando você passa de uma configuração de máquina única (seu Colab, Kaggle, Databricks Single Node ou até mesmo seu notebook Jupyter local) para uma configuração de cluster de vários nós (Databricks, EMR, GCP, Azure, Cloudera , YARN, Kubernetes, etc.), a alteração do código zero é necessária! E eu quero dizer zero! Com isso em mente, executarei o mesmo benchmark dentro deste novo cluster nos conjuntos de dados maiores com imagens de 34K: Pipeline de classificação de imagens Spark NLP em com CPUs (oneDNN) — prevendo 34742 imagens nós 2x Demorou cerca ( ) para concluir a previsão de classes para imagens de 34K. Vamos comparar este resultado em com Spark NLP e Hugging Face resultados no nó único do Databricks (continuarei repetindo os resultados do Hugging Face em um único nó como referência, pois o Hugging Face não pode ser dimensionado em várias máquinas, especialmente em Databricks) : de 9 minutos 550 segundos 2x Nodes é que o Hugging Face com O Spark NLP 124% mais rápido 2x Nodes Anteriormente, o Spark NLP vencia o Hugging Face em um cluster Databricks de nó único usando apenas CPUs em . 15% Desta vez, por ter apenas 2x nós em vez de 1 nó, o Spark NLP finalizou o processo de mais de 34 mil imagens 124% mais rápido do que Hugging Face. Dimensione o Spark NLP em CPUs com 4x nós Vamos dobrar o tamanho do nosso cluster como antes e passar de para É assim que o cluster ficaria com nós 4x: 2x nós 4x nós. Databricks com 4x nós — apenas CPUs Executarei o mesmo benchmark neste novo cluster nos conjuntos de dados maiores com imagens de 34K: Pipeline de classificação de imagens Spark NLP em com CPUs (oneDNN) — prevendo 34742 imagens nós 4x Demorou cerca ( ) para concluir a previsão de classes para imagens de 34K. Vamos comparar este resultado em com Spark NLP vs. Hugging Face em CPUs em Databricks: de 5 minutos 289 segundos 4x Nodes é que o Hugging Face com O Spark NLP 327% mais rápido 4x Nodes Como pode ser visto, o Spark NLP agora é do que o Hugging Face em CPUs enquanto usa apenas em Databricks. 327% mais rápido 4x Nodes Escale o Spark NLP em CPUs com 8x nós Agora vamos dobrar o cluster anterior adicionando 4x mais nós e fazer o total de . A propósito, esse redimensionamento do cluster é bem fácil, basta aumentar o número de workers nas configurações do cluster: 8x nós Redimensionando o Spark Cluster no Databricks Databricks com 8x nós — apenas CPUs Vamos executar o mesmo benchmark desta vez em 8x Nodes: Pipeline de classificação de imagens Spark NLP em com CPUs (oneDNN) — prevendo 34742 imagens nós 8x Demorou mais de 2 minutos e meio ( ) para concluir a previsão de classes para imagens de 34K. Vamos comparar este resultado em com Spark NLP vs. Hugging Face em CPUs em Databricks: 161 segundos 8x Nodes é que o Hugging Face com O Spark NLP 666% mais rápido 8x Nodes Como pode ser visto, o Spark NLP agora é do que o Hugging Face em CPUs enquanto usa apenas em Databricks. 666% mais rápido 8x nós Vamos apenas ignorar o número de 6s aqui! (foi 665,8% se te faz sentir melhor) Escale o Spark NLP em CPUs com 10x nós Para concluir nossas previsões de dimensionamento de modelos ViT em CPUs em Databricks usando o Spark NLP, redimensionarei o cluster mais uma vez e o aumentarei para 10x nós: Databricks com 10x nós — apenas CPUs Vamos executar o mesmo benchmark desta vez em 10x Nodes: Pipeline de classificação de imagens Spark NLP em com CPUs (oneDNN) — prevendo 34742 imagens nós 10x Levou menos de ( ) para concluir a previsão de classes para imagens de 34K. Vamos comparar este resultado em com todos os resultados anteriores do Spark NLP vs. Hugging Face em CPUs em Databricks: 2 minutos 112 segundos 10x Nodes é que o Hugging Face com O Spark NLP 1000% mais rápido 10x Nodes E é assim que você modelo do Vision Transformer vindo do Hugging Face em usando o no Databricks! Nosso pipeline agora é do que o Hugging Face nas CPUs. dimensiona o 10x Nodes Spark NLP 1000% mais rápido Conseguimos tornar nosso pipeline do que o Hugging Face, que fica preso em um único nó, simplesmente usando o Spark NLP, mas usamos apenas . Vamos ver se podemos obter as mesmas melhorias escalando nosso pipeline em um . ViT 1000% mais rápido CPUs cluster de GPU Databricks Multi-Node com GPUs na AWS Ter um cluster Databricks de vários nós baseado em GPU é praticamente o mesmo que ter um cluster de nó único. A única diferença é escolher e manter o mesmo ML/GPU Runtime com as mesmas especificações de instância da AWS que escolhemos em nossos benchmarks para GPU em um único nó. Standard Também precisamos instalar o Spark NLP neste novo cluster por meio da guia . Assim como antes, você pode seguir as etapas que mencionei em Databricks de nó único com uma GPU. Bibliotecas Databricks cluster de vários nós (padrão) com GPUs Escale o Spark NLP em GPUs com 2x nós Nosso cluster de GPU Databricks de vários nós usa a mesma instância de GPU da AWS de que usamos anteriormente para executar nossos benchmarks para comparar Spark NLP vs. Hugging Face em um cluster Databricks de nó único. g4dn.8xlarge Este é um resumo do que parece desta vez com 2 nós: Databricks com 2x nós — com 1 GPU por nó Vou executar o mesmo pipeline neste cluster de GPU com 2x nós: Pipeline de classificação de imagens Spark NLP em com GPUs — prevendo 34742 imagens nós 2x Levou 4 minutos ( ) para concluir a previsão de classes para . Vamos comparar este resultado em com Spark NLP vs. Hugging Face em GPUs em Databricks: 231 segundos imagens de 34K 2x Nodes é que o Hugging Face com O Spark NLP 185% mais rápido 2x Nodes Spark NLP com é quase ( ) do que Hugging Face em 1 único nó enquanto usa 2x Nodes 3x vezes mais rápido 185% GPU. Escale o Spark NLP em GPUs com 4x nós Vamos redimensionar nosso cluster de GPU de 2x nós para Este é um resumo da aparência desta vez com usando uma GPU: 4x nós. 4x Nodes Databricks com 4x nós — com 1 GPU por nó Vamos executar o mesmo benchmark em 4x Nodes e ver o que acontece: Pipeline de classificação de imagens Spark NLP em com GPUs — prevendo 34742 imagens nós 4x Desta vez, levou quase 2 minutos ( ) para terminar de classificar todas em nosso conjunto de dados. Vamos visualizar isso apenas para ter uma visão melhor do que isso significa em termos de Hugging Face em um único nó versus Spark NLP em um cluster de vários nós: 118 segundos as imagens de 34K é que o Hugging Face com O Spark NLP 458% mais rápido 4x Nodes Isso representa um em comparação com o Hugging Face. Acabamos de tornar nosso pipeline usando o Spark NLP com aumento de 458% no desempenho 5,6 vezes mais rápido 4x nós. Escale o Spark NLP em GPUs com 8x nós Em seguida, redimensionarei o cluster para ter em meus Databricks com o seguinte resumo: 8x Nodes Databricks com 8x nós — com 1 GPU por nó Só para lembrar, cada instância da AWS ( ) tem 1 de 16 GB (15 GB de memória utilizável). Vamos executar novamente o benchmark e ver se podemos identificar melhorias, pois a expansão em qualquer sistema distribuído tem suas despesas gerais e você não pode simplesmente continuar adicionando máquinas: g4dn.8xlarge GPU NVIDIA T4 Pipeline de classificação de imagens Spark NLP em com GPUs — prevendo 34742 imagens nós 8x Demorou quase um minuto ( ) para concluir a classificação com em nosso cluster Databricks. Parece que ainda conseguimos melhorar o desempenho. Vamos colocar este resultado ao lado dos resultados anteriores de Hugging Face em um único nó versus Spark NLP em um cluster de vários nós: 61 segundos de imagens de 34K 8x nós é que o Hugging Face com O Spark NLP 980% mais rápido 8x Nodes O Spark NLP com é quase do que o Hugging Face em GPUs. 8x Nodes 11x vezes mais rápido (980%) Escale o Spark NLP em GPUs com 10x nós Semelhante aos nossos benchmarks de vários nós em CPUs, gostaria de redimensionar o cluster de GPU mais uma vez para ter e combiná-los em termos do número final de nós. O resumo final deste cluster é o seguinte: 10x nós Databricks com 10x nós — com 1 GPU por nó Vamos executar nosso último benchmark neste cluster de GPU específico (sem alterações de código): Pipeline de classificação de imagens Spark NLP em com GPUs — prevendo 34742 imagens nós 10x Levou menos de um minuto ( ) para concluir a previsão de classes para mais de . Vamos colocá-los um ao lado do outro e ver como progredimos ao expandir nosso modelo Vision Transformer vindo de Hugging Face no pipeline Spark NLP em Databricks: 51 segundos 34.743 imagens é que o Hugging Face com O Spark NLP 1200% mais rápido 10x Nodes E terminamos! Conseguimos nosso modelo vindo de Hugging Face em usando em Databricks! Nosso pipeline agora é com comparação com Hugging Face na GPU. escalar Vision Transformer 10x Nodes Spark NLP 13 vezes mais rápido, melhorias de desempenho de 1200% em Vamos resumir todos esses benchmarks comparando primeiro as melhorias entre CPUs e GPUs e, em seguida, quão mais rápido nosso pipeline pode ser indo de Hugging Face CPUs para 10x Nodes em Databricks usando Spark NLP em GPUs. Juntando tudo: Databricks: nó único e vários nós O Spark NLP 🚀 em 10x Nodes com CPUs é 1000% (11x vezes) mais rápido que o Hugging Face 🤗 preso em um único node com CPUs O Spark NLP 🚀 em 10x nós com GPUs é 1192% (13x vezes) mais rápido que o Hugging Face 🤗 preso em um único nó com GPU E quanto às diferenças de preço entre nossa instância de CPU da AWS e a instância de GPU da AWS? (Quero dizer, você ganha mais se pagar mais, certo?) com CPUs vs. com 1 GPU e especificações semelhantes AWS m5d.8xlarge AWS g4dn.8xlarge OK, então o preço parece praticamente o mesmo! Com isso em mente, quais melhorias você obtém se mudar de em presas em uma única máquina para em com ? Hugging Face CPUs Spark NLP 10x Nodes 10x GPUs em GPUs é que Hugging Face em CPUs Spark NLP 25x vezes (2366%) mais rápido O Spark NLP 🚀 em 10x nós com GPUs é 2366% (25x vezes) mais rápido que o Hugging Face 🤗 em um único nó com CPUs palavras finais No espírito de total transparência, todos os notebooks com seus logs, capturas de tela e até a planilha do Excel com números são fornecidos aqui no GitHub O escalonamento do Spark NLP requer zero alteração de código. Executar os benchmarks de um único nó Databricks para os 10 nós significava apenas executar novamente o mesmo bloco de código no mesmo notebook Lembre-se de que essas duas bibliotecas vêm com muitas práticas recomendadas para otimizar sua velocidade e eficiência em diferentes ambientes para diferentes casos de uso. Por exemplo, não falei sobre partições e sua relação com paralelismo e distribuições no Apache Spark. Existem muitas configurações do Spark para ajustar um cluster, especialmente equilibrando o número de tarefas entre CPUs e GPUs. Agora a questão é, seria possível acelerar qualquer um deles dentro dos mesmos ambientes que usamos para nossos benchmarks? A resposta é 100%! Tentei manter tudo para ambas as bibliotecas com valores padrão e recursos prontos para uso em favor da simplicidade para a maioria dos usuários. Talvez você queira agrupar Hugging Face e outras bibliotecas Pythonish baseadas em DL em um Spark UDF para escalá-las. Isso funciona até certo ponto, como eu mesmo fiz e ainda faço (quando não há solução nativa). Não entrarei em detalhes sobre uso excessivo de memória, possíveis problemas de serialização, latência mais alta e outros problemas quando se agrupa tais modelos baseados em transformadores em uma UDF. Eu diria apenas que se você estiver usando o Apache Spark, use a biblioteca que está estendendo nativamente seus recursos necessários no Apache Spark. Ao longo deste artigo, fiz o possível para mencionar o Hugging Face no PyTorch e o Spark NLP no TensorFlow. Essa é uma grande diferença, visto que em todos os benchmarks feitos pelo Hugging Face entre PyTorch e TensorFlow, o PyTorch foi e ainda é o vencedor em inferência. No Hugging Face, o PyTorch tem uma latência muito menor e parece ser muito mais rápido que o TensorFlow nos Transformers. O fato de o Spark NLP usar o mesmo TensorFlow e ficar à frente em todos os benchmarks em comparação com o PyTorch em Hugging Face é um grande negócio. O TensorFlow em Hugging Face é negligenciado ou o PyTorch é apenas mais rápido na inferência em comparação com o TensorFlow. De qualquer forma, mal posso esperar para ver o que acontecerá quando o Spark NLP começar a suportar TorchScript e ONNX Runtime, além do TensorFlow. Os tempos de execução ML e ML GPU Databricks vêm com o Hugging Face instalado, isso é muito bom. Mas isso não significa que o Hugging Face seja fácil de usar no Databricks. A biblioteca Transformer da Hugging Face não oferece suporte a DBFS (o sistema de arquivos distribuído nativo do Databricks) ou Amazon S3. Como você vê nos notebooks, tive que baixar uma versão compactada dos conjuntos de dados e extraí-los para usá-los. Não é assim que os usuários no Databricks e outras plataformas em produções fazem as coisas. Mantemos nossos dados em sistemas de arquivos distribuídos, existem medidas de segurança implementadas e a maioria delas é grande o suficiente para não ser baixada por um computador pessoal. Tive que baixar os conjuntos de dados que já tinha no DBFS, compactá-los, carregá-los no S3, torná-los públicos e baixá-los novamente nos notebooks. Um processo bastante tedioso que poderia ter sido evitado se o Hugging Face pudesse suportar DBFS/S3. Referências ViT https://arxiv.org/pdf/2010.11929.pdf https://github.com/google-research/vision_transformer Transformadores de visão (ViT) em reconhecimento de imagem — Guia 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 rosto abraçado 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-servindo-vision https://huggingface.co/blog/deploy-tfservindo-kubernetes https://huggingface.co/google/vit-base-patch16-224 https://huggingface.co/blog/deploy-vertex-ai https://huggingface.co/models?other=vit Databricks 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 Veja o melhor do 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 Spark PNL Spark PNL GitHub (exemplos Spark NLP) Spark NLP Workshop Transformadores Spark NLP Centro de Modelos Spark NLP Otimização de velocidade e benchmarks no Spark NLP 3: aproveitando ao máximo a aceleração de hardware de hardware moderno no Spark NLP Servindo Spark NLP via API: Spring e LightPipelines Servindo Spark NLP via API (1/3): Synapse ML da Microsoft Servindo Spark NLP via API (2/3): FastAPI e LightPipelines Servindo Spark NLP via API (3/3): Databricks Jobs e MLFlow Serve APIs Aproveite o aprendizado profundo em Scala com GPU no Spark 3.0 Introdução ao Apache Spark 3 acelerado por GPU Ajuste de desempenho do Apache Spark Possíveis otimizações extras em GPUs: RAPIDS Accelerator for Apache Spark Configuration