O blog da AWS
Obtenha desempenho 1,85 vezes maior para detecção de objetos baseada em aprendizado profundo com um modelo de YoLoV4 compilado pelo AWS Neuron na AWS Inferentia
Por Fabio Nonato de Paula, Senior Manager dos Arquitetos de Soluções na AWS,
Haichen Li, Engenheiro de desenvolvimento de Software na AWS e
Samuel Jacob, Engenheiro de Software Senior na AWS
Neste post, nós lhe mostraremos como implementar um modelo YoLoV4 baseado no TensorFlow, usando o Keras otimizado para inferência em instâncias Amazon EC2 Inf1 com AWS Inferentia. Você configurará um ambiente de benchmarking para avaliar a taxa de transferência e a precisão, comparando o Inf1 com instâncias comparáveis baseadas em GPU da família Amazon EC2 g4. A implementação do YOLoV4 no AWS Inferentia oferece a taxa de transferência mais alta com a menor latência com mínima variação e menor custo por imagem.
Os gráficos a seguir mostram uma execução de 2 horas, em que o Inf1 oferece menor latência e taxa de transferência maior. As instâncias Inf1 alcançaram uma taxa de transferência até 1,85 vezes maior e custo 37% menor por imagem quando comparadas às instâncias baseadas em GPU do Amazon EC2 G4 mais otimizadas.
Além disso, o gráfico a seguir registra que a latência de inferência P90 é 60% menor em Inf1 e com variância significativamente menor em comparação com as instâncias G4.
Quando você usa o recurso de conversão automática de tipos de dados do AWS Neuron, não há degradação mensurável na precisão do modelo. O compilador converte automaticamente o modelo para precisão mista com tipos de dados BF16 para um desempenho melhor. O modelo atinge a precisão média de 48,7% — graças à implementação do modelo YoLoV4 de última geração.
Sobre o AWS Inferentia e o AWS Neuron SDK
Os chips AWS Inferentia são especialmente desenvolvidos pela AWS para fornecer inferência de alto desempenho, com o menor custo na nuvem, com recursos transparentes como conversão automática de modelos treinados em FP32 para Bfloat16 e uma arquitetura elástica para execução dos modelos de aprendizado de máquina (ML), que suporta uma ampla gama de tipos de modelos, desde reconhecimento de imagem a detecção de objetos, processamento de linguagem natural (PNL) e modelos modernos de recomendação.
O AWS Neuron é um kit de desenvolvimento de software (SDK) que consiste em um compilador, bibliotecas e ferramentas de criação de perfil que otimizam o desempenho de inferência nos chips Inferentia. O Neuron é integrado nativamente a frameworks de ML populares, como TensorFlow e PyTorch e vem pré-instalado nas AMIs do AWS Deep Learning. O AWS Inferentia utiliza o mesmo ambiente já conhecido e usado por outras frameworks para a implementação de modelos de deep learning, e seus aplicativos se beneficiam do aumento de desempenho e menor custo.
Desde o seu lançamento, o Neuron SDK tem visto uma melhoria dramática no número de modelos que oferecem alto desempenho a uma fração dos custos. Isso inclui modelos de NLP como o popular BERT, modelos de classificação de imagem (ResNet, VGG) e modelos de detecção de objetos (OpenPose e SSD). A versão mais recente do Neuron (1.15.1) fornece otimizações que melhoram o desempenho do YOLO v3 e v4, VGG16, SSD300 e BERT. Ele também melhora as implantações operacionais de aplicativos de inferência de grande escala, com um agente de gerenciamento de sessão incorporado em todas os frameworks de ML suportados e uma nova ferramenta do Neuron que lhe permite dimensionar facilmente o monitoramento de grandes frotas de aplicativos de inferência.
Você só olha uma vez
A detecção de objetos se destaca como uma tarefa de visão computacional (CV) que teve grandes melhorias de precisão (precisão média de 50 iOU > 70) devido a arquiteturas de modelos de deep learning. Um modelo de detecção de objetos tenta localizar e classificar objetos em uma imagem, permitindo aplicações que vão desde a inspeção em tempo real de defeitos de fabricação até imagens médicas e para rastrear seu jogador favorito e a bola em uma partida de futebol .
Enfrentar os desafios de inferência em tempo real para tais tarefas de visão computacional é fundamental ao implementar esses modelos em escala.
O YOLO faz parte da família de modelos de detecção de objetos de estágio único de deep learning (DL), que inclui modelos como Single-Shot Detector (SSD) e RetinaNet. Esses modelos geralmente são construídos a partir de um conjunto de modelos de redes neurais que consistem em uma espinha dorsal (backbone), pescoço (neck) e cabeça (head) que juntas executam tarefas de detecção e classificação. As principais previsões são caixas delimitadoras para os objetos identificados e suas associadas classes.
A rede da espinha dorsal extrai os features da imagem usada como entrada, enquanto a rede da cabeça é treinada na tarefa supervisionada para prever as bordas da caixa delimitadora e classificar seu conteúdo. A adição da rede do pescoço permite que a rede da cabeça processe os features a partir de etapas intermediárias da rede da espinha dorsal. Todo o pipeline processa as imagens apenas uma vez, daí o nome You Only Look Once (YOLO).
Por outro lado, modelos com detectores de dois estágios processam outras características das camadas convolucionais anteriores para obter propostas de regiões, antes de gerar uma predição de classe de objeto. Desta forma, a rede se concentra em detectar e classificar objetos em regiões com alta probabilidade de objetos.
O diagrama a seguir ilustra essa arquitetura (de YoLoV4: Optimal Speed and Accuracy of Object Detection, ARXIV:2004.10934v1).
Modelos de estágio único permitem várias previsões do mesmo objeto em uma única imagem. Essas previsões são desambiguadas posteriormente por um processo chamado supressão não-máxima (NMS), que deixa apenas a caixa delimitadora com probabilidade mais alta e rótulo para o objeto. É um fluxo de trabalho computacionalmente menos dispendioso do que a abordagem de dois estágios.
Modelos como o YOLO são focados em alto desempenho. Sua mais recente encarnação, a versão 4, visa melhorar a precisão da predição ainda mais. O artigo de pesquisa YoLoV4: Optimal Speed and Accuracy of Object Detection mostra como a inferência em tempo real pode ser alcançada acima da percepção humana de cerca de 30 quadros por segundo (FPS). Neste post, você explora maneiras de impulsionar ainda mais o desempenho desse modelo e usar a AWS Inferentia como um acelerador de hardware econômico para detecção de objetos em tempo real.
Pré-requisitos
Para este passo a passo, você precisa de uma conta da AWS com acesso ao AWS Management Console e a capacidade de criar instâncias do Amazon Elastic Compute Cloud (Amazon EC2) com um IP voltado para o público.
O conhecimento prático das AMIs do AWS Deep Learning e de Jupyter notebooks com ambientes Conda é benéfico, mas não é necessário.
Construindo um preditor YoLoV4 a partir de um modelo pré-treinado
Para começar a criar o modelo, configure uma instância de EC2 inf1.2xlarge na AWS, com 8 núcleos de vCPU e 16 GB de memória. A instância Inf1 permite otimizar a relação entre CPU e dispositivos Inferentia através da seleção de inf1.xlarge ou inf1.2xlarge. Descobrimos que para YoLoV4, a razão ideal entre vCPU e aceleradores Inferentia é alcançada com a inf.2xlarge. Ir para a instância de segundo tamanho melhora a taxa de transferência com um custo mais baixo por imagem. Use o AWS Deep Learning AMI (Ubuntu 18.04) versão 34.0—ami-06a25ee8966373068— na região US East (N. Virginia). Essa AMI vem pré-carregada com o SDK do Neuron e as bibliotecas necessárias do Neuron para o AWS Inferentia. Para obter mais informações sobre a execução de AMIs do AWS Deep Learning em instâncias do EC2, consulte a documentação Launching and Configuring a DLAMI.
Em seguida, você pode se conectar à instância através de SSH, ativar o ambiente Conda chamado aws_neuron_tensorflow_p36 e atualizar o compilador Neuron para a versão mais recente. O script de compilação depende dos requisitos listados no tutorial YoLoV4 publicado no repositório do Neuron GitHub. Instale-os executando o seguinte código no terminal:
pip install neuron-cc tensorflow-neuron requests pillow matplotlib pycocotools==2.0.1 torch~=1.5.0 --force --extra-index-url=https://pip.repos.neuron.amazonaws.com
Você também pode executar as seguintes etapas diretamente do notebook Jupyter fornecido. Se fizer isso, pule para a seção Executando um benchmark de desempenho no Inferentia para explorar os benefícios de desempenho da execução do YOLOV4 na AWS Inferentia.
O benchmark dos modelos requer um dataset de validação da detecção de objetos. Comece baixando o dataset de validação chamado COCO 2017. O COCO (Common Objects in Context) é um dataset de detecção, segmentação e rotulagem de objetos em larga escala, com mais de 300.000 imagens e 1,5 milhão de instâncias de objetos. A versão 2017 do COCO contém 5.000 imagens para validação.
Para baixar o dataset, insira o seguinte código no terminal:
curl -LO http://images.cocodataset.org/zips/val2017.zip
curl -LO http://images.cocodataset.org/annotations/annotations_trainval2017.zip
unzip -q val2017.zip
unzip annotations_trainval2017.zip
Quando o download estiver concluído, você verá um val2017 e uma pasta chamada annotations disponíveis em seu diretório de trabalho. Nesta fase, você está pronto para construir e compilar o modelo.
O repositório GitHub contém o script yolo_v4_coco_saved_model.py para baixar os pesos pré-treinados de uma implementação PyTorch do YoLoV4 e a definição do modelo para YoLoV4 usando TensorFlow 1.15 e Keras. O código foi adaptado a partir de uma implementação anterior e converte o ponto de verificação PyTorch para um modelo usando Keras h5. Essa implementação do YoLoV4 é otimizada para ser executada no AWS Inferentia. Para obter mais informações sobre otimizações, consulte a documentação Trabalhando com o YOLO v4 usando o AWS Neuron SDK.
Para baixar, converter e salvar seu modelo Keras na pasta yolo_v4_coco_saved_model , use o seguinte código:
python3 yolo_v4_coco_saved_model.py. /yolo_v4_coco_saved_model
Para instanciar uma nova modelo de predição a partir do modelo salvo, use
tf.contrib.predictor.from_saved_model ('. /yolo_v4_coco_saved_model ') em seu script de inferência.
O código a seguir implementa uma única predição em lote e um script de anotação de imagem para que você possa testar o modelo salvo:
import json
import tensorflow as tf
from PIL import Image
import matplotlib.pyplot as plt
import matplotlib.patches as patches
yolo_pred_cpu = tf.contrib.predictor.from_saved_model('./yolo_v4_coco_saved_model')
image_path = './val2017/000000581781.jpg'
with open(image_path, 'rb') as f:
feeds = {'image': [f.read()]}
results = yolo_pred_cpu(feeds)
# load annotations to decode classification result
with open('./annotations/instances_val2017.json') as f:
annotate_json = json.load(f)
label_info = {idx+1: cat['name'] for idx, cat in enumerate(annotate_json['categories'])}
# draw picture and bounding boxes
fig, ax = plt.subplots(figsize=(10, 10))
ax.imshow(Image.open(image_path).convert('RGB'))
wanted = results['scores'][0] > 0.1
for xyxy, label_no_bg in zip(results['boxes'][0][wanted], results['classes'][0][wanted]):
xywh = xyxy[0], xyxy[1], xyxy[2] - xyxy[0], xyxy[3] - xyxy[1]
rect = patches.Rectangle((xywh[0], xywh[1]), xywh[2], xywh[3], linewidth=1, edgecolor='g', facecolor='none')
ax.add_patch(rect)
rx, ry = rect.get_xy()
rx = rx + rect.get_width() / 2.0
ax.annotate(label_info[label_no_bg + 1], (rx, ry), color='w', backgroundcolor='g', fontsize=10,
ha='center', va='center', bbox=dict(boxstyle='square,pad=0.01', fc='g', ec='none', alpha=0.5))
plt.show()
O desempenho nesta configuração não é ideal porque você executou o YOLO somente na CPU. Apesar da paralelização nativa do TensorFlow, os oito núcleos não são suficientes para executar a inferência em tempo real. Para isso, você usa o AWS Inferentia.
Compilação do YOLoV4 para execução na AWS Inferentia
A compilação do YoLoV4 usa a API Tensorflow-Neuron tfn.saved_mode.compile, trabalhando diretamente com o diretório do modelo salvo criado anteriormente. Para reduzir ainda mais a sobrecarga de tempo de execução do Neuron, dois argumentos extras são adicionados à chamada do compilador: no_fuse_ops e minimum_segment_size .
O primeiro argumento, no_fuse_ops, particiona o grafo antes de converter os tensores FP16 rodando no subgrafo de volta para FP32, conforme definido no script do modelo. Isso permite que as operações que são executadas de forma mais eficiente na CPU sejam ignoradas enquanto o compilador Neuron executa seu particionamento automático inteligente. O argumento minimum_segment_size define o número mínimo de operações em um subgrafo, para impor que seções trivialmente compiláveis sejam executadas na CPU. Para obter mais informações, consulte a referência: Tensorflow-Neuron Compilation API.
Para compilar o modelo, insira o seguinte código:
import shutil
import tensorflow as tf
import tensorflow.neuron as tfn
def no_fuse_condition(op):
return any(op.name.startswith(pat) for pat in ['reshape', 'lambda_1/Cast', 'lambda_2/Cast', 'lambda_3/Cast'])
with tf.Session(graph=tf.Graph()) as sess:
tf.saved_model.loader.load(sess, ['serve'], './yolo_v4_coco_saved_model')
no_fuse_ops = [op.name for op in sess.graph.get_operations() if no_fuse_condition(op)]
shutil.rmtree('./yolo_v4_coco_saved_model_neuron', ignore_errors=True)
result = tfn.saved_model.compile('./yolo_v4_coco_saved_model',
'./yolo_v4_coco_saved_model_neuron',
# we partition the graph before casting from float16 to float32, to help reduce the output tensor size by 1/2
no_fuse_ops=no_fuse_ops,
# to enforce trivial compilable subgraphs to run on CPU
minimum_segment_size=100,
batch_size=1,
dynamic_batch_size=True,
)
print(result)
Em uma instância inf1.2xlarge, a compilação leva apenas alguns minutos e gera a proporção das operações de grafo executadas no chip AWS Inferentia. Para o nosso modelo, essa proporção é aproximadamente 79%. Como mencionado anteriormente, para otimizar o desempenho do modelo compilado, o objetivo da compilação não deve ser maximizar as operações no chip AWS Inferentia, mas atingir o equilíbrio entre o uso das CPUs disponíveis e Inferentia, para uma utilização mais eficiente de todo o sistema.
O AWS Inferentia foi projetado para atingir o pico de taxa de transferência em tamanhos de lote pequenos, geralmente com um único dígito. Ao otimizar um modelo específico para taxa de transferência, explore a compilação do modelo com valores diferentes do argumento batch_size e teste qual tamanho do lote produz a taxa de transferência máxima para o seu modelo. No caso do nosso modelo YoLoV4, o melhor tamanho de lote é 1.
Substitua o caminho do modelo na instanciação do modelo preditor para tf.contrib.predictor.from_saved_model ('. /yolo_v4_coco_saved_model_neuron '), para que possa comparar com as predições rodando apenas em CPU. Você obtém precisão de detecção semelhante em uma fração do tempo, aproximadamente 40 milissegundos.
Configuração de um pipeline de medição de desempenho
Para configurar um pipeline de medição de desempenho, crie um loop multi-threaded executando inferência em todas as imagens COCO baixadas. O código disponível no notebook adapta a implementação original da função eval . A seguinte versão adaptada implementa um ThreadPoolExecutor para enviar quatro chamadas de previsão paralelas de cada vez:
from concurrent import futures
def evaluate(yolo_predictor, images, eval_pre_path, anno_file, eval_batch_size, _clsid2catid):
batch_im_id_list, batch_im_name_list, batch_img_bytes_list = get_image_as_bytes(images, eval_pre_path)
# warm up
yolo_predictor({'image': np.array(batch_img_bytes_list[0], dtype=object)})
with futures.ThreadPoolExecutor(4) as exe:
fut_im_list = []
fut_list = []
start_time = time.time()
for batch_im_id, batch_im_name, batch_img_bytes in zip(batch_im_id_list, batch_im_name_list, batch_img_bytes_list):
if len(batch_img_bytes) != eval_batch_size:
continue
fut = exe.submit(yolo_predictor, {'image': np.array(batch_img_bytes, dtype=object)})
fut_im_list.append((batch_im_id, batch_im_name))
fut_list.append(fut)
bbox_list = []
count = 0
for (batch_im_id, batch_im_name), fut in zip(fut_im_list, fut_list):
results = fut.result()
bbox_list.extend(analyze_bbox(results, batch_im_id, _clsid2catid))
for _ in batch_im_id:
count += 1
if count % 100 == 0:
print('Test iter {}'.format(count))
print('==================== Performance Measurement ====================')
print('Finished inference on {} images in {} seconds'.format(len(images), time.time() - start_time))
print('=================================================================')
# start evaluation
box_ap_stats = bbox_eval(anno_file, bbox_list)
return box_ap_stats
Funções auxiliares adicionais são usadas para calcular pontuações médias de precisão do modelo implantado.
Executando um benchmark de desempenho no Inferentia
Para executar a avaliação COCO e medir o desempenho do tempo necessário para inferir sobre as 5.000 imagens, execute a função de avaliação conforme mostrado no código a seguir:
val_coco_root = './val2017'
val_annotate = './annotations/instances_val2017.json'
clsid2catid = {0: 1, 1: 2, 2: 3, 3: 4, 4: 5, 5: 6, 6: 7, 7: 8, 8: 9, 9: 10, 10: 11, 11: 13, 12: 14, 13: 15, 14: 16,
15: 17, 16: 18, 17: 19, 18: 20, 19: 21, 20: 22, 21: 23, 22: 24, 23: 25, 24: 27, 25: 28, 26: 31,
27: 32, 28: 33, 29: 34, 30: 35, 31: 36, 32: 37, 33: 38, 34: 39, 35: 40, 36: 41, 37: 42, 38: 43,
39: 44, 40: 46, 41: 47, 42: 48, 43: 49, 44: 50, 45: 51, 46: 52, 47: 53, 48: 54, 49: 55, 50: 56,
51: 57, 52: 58, 53: 59, 54: 60, 55: 61, 56: 62, 57: 63, 58: 64, 59: 65, 60: 67, 61: 70, 62: 72,
63: 73, 64: 74, 65: 75, 66: 76, 67: 77, 68: 78, 69: 79, 70: 80, 71: 81, 72: 82, 73: 84, 74: 85,
75: 86, 76: 87, 77: 88, 78: 89, 79: 90}
eval_batch_size = 8
with open(val_annotate, 'r', encoding='utf-8') as f2:
for line in f2:
line = line.strip()
dataset = json.loads(line)
images = dataset['images']
box_ap = evaluate(yolo_pred, images, val_coco_root, val_annotate, eval_batch_size, clsid2catid)
Quando a avaliação estiver concluída, você verá logs na tela como o seguinte:
… Test iter 4500 Test iter 4600 Test iter 4700 Test iter 4800 Test iter 4900 ==================== Performance Measurement ==================== Finished inference on 5000 images in 47.50522780418396 seconds ================================================================= … Accumulating evaluation results... DONE (t=6.78s). Average Precision (AP) @[ IoU=0.50:0.95 | area= all | maxDets=100 ] = 0.487 Average Precision (AP) @[ IoU=0.50 | area= all | maxDets=100 ] = 0.741 Average Precision (AP) @[ IoU=0.75 | area= all | maxDets=100 ] = 0.531 Average Precision (AP) @[ IoU=0.50:0.95 | area= small | maxDets=100 ] = 0.330 Average Precision (AP) @[ IoU=0.50:0.95 | area=medium | maxDets=100 ] = 0.546 Average Precision (AP) @[ IoU=0.50:0.95 | area= large | maxDets=100 ] = 0.604 Average Recall (AR) @[ IoU=0.50:0.95 | area= all | maxDets= 1 ] = 0.357 Average Recall (AR) @[ IoU=0.50:0.95 | area= all | maxDets= 10 ] = 0.573 Average Recall (AR) @[ IoU=0.50:0.95 | area= all | maxDets=100 ] = 0.601 Average Recall (AR) @[ IoU=0.50:0.95 | area= small | maxDets=100 ] = 0.430 Average Recall (AR) @[ IoU=0.50:0.95 | area=medium | maxDets=100 ] = 0.657 Average Recall (AR) @[ IoU=0.50:0.95 | area= large | maxDets=100 ] = 0.744
Com 5.000 imagens processadas em 47 segundos, essa implantação alcança 106 FPS, 3,5 vezes mais rápido do que o limite em tempo real de 30 FPS. O artigo de pesquisa YOLoV4: Optimal Speed and Precision of Object Detection lista os resultados para o mesmo dataset COCO 2017 executado em uma GPU NVIDIA Volta, como a V100. A maior taxa de quadros obtida foi de 96 FPS, com 41,2% mP. Nossa arquitetura de modelo e implementação alcança MAP mais alto, 48,7%, com uma taxa de transferência mais alta.
Para ter uma comparação direta entre as arquiteturas AWS Inferentia, NVIDIA Volta e Turing, replicamos o mesmo experimento em duas instâncias baseadas em GPU, g4dn.xlarge e p3.2xlarge, executando exatamente o mesmo modelo antes da compilação, sem outras otimizações no GPU. Desta vez, alcançamos 39 FPS e 111 FPS para o g4dn.xlarge e p3.2xlarge, respectivamente.
Um modelo YOLO implementado em produção geralmente não vê um lote definido de 5.000 imagens por vez. Para medir um desempenho como em produção, configuramos um pipeline multithread somente de previsão que executa inferência por períodos prolongados.
Durante um tempo total de 2 horas, executamos continuamente 8 chamadas de previsão paralelas com um lote de 4 imagens em cada, totalizando 32 imagens de cada vez. Para maximizar a taxa de transferência da GPU e tentar diminuir a diferença de desempenho entre as instâncias Inf1 e G4, usamos o compilador TensorFlow XLA. Essa configuração imita um comportamento de um endpoint ao vivo com execução na taxa de transferência maximisada.
Regulação térmica da GPU
Em contraste com os chips AWS Inferentia, a taxa de transferência da GPU é inversamente proporcional à temperatura da GPU. A temperatura da GPU pode variar nos endpoints que executam predições por longos períodos de tempo sob alta taxa de transferência, o que leva a flutuações de FPS e de latência. Este efeito é conhecido como estrangulamento térmico. Alguns sistemas de produção podem definir uma taxa de transferência limite abaixo do máximo possível para evitar oscilações de desempenho ao longo do tempo. O gráfico a seguir mostra a média de FPS em incrementos de 30 segundos para a duração do teste. Observamos até 12% de variação da média móvel do FPS na instância da GPU. No AWS Inferentia, essa variação é inferior a 3% para uma média de FPS substancialmente maior.
Durante o período de 2 horas, executamos inferência em mais de 856.000 imagens na instância inf1.2xlarge. Na g4dn.xlarge, o número máximo de inferências alcançadas foi de 486.000. Isso equivale a 76% a mais de imagens processadas no mesmo período de tempo usando o AWS Inferentia! As médias de latência para a inferência usando um lote de tamanho 4 também são 60% menores no AWS Inferentia.
Usando a taxa de transferência total coletada durante nosso teste de 2 horas, calculamos que o preço de execução de 1 milhão de inferências é de US$ 1,362 em uma instância inf1.xlarge na região us-east-1. Para uma g4dn.xlarge, o preço é de US$ 2,163 — uma redução de preço de 37% para o pipeline de detecção de objetos YoLoV4 no AWS Inferentia.
Desligando e limpando com segurança
No console do Amazon EC2, escolha as instâncias usadas para executar o benchmark e escolha Encerrar no menu drop-down de Ações. Encerrar a instância descarta os dados armazenados apenas no volume iniciado com a instância. Você pode persistir o modelo compilado em um bucket do Amazon Simple Storage Service (S3) para que ele possa ser reutilizado posteriormente. Se você fez alterações no código dentro das instâncias, lembre-se de persistí-las também.
Conclusão
Nesta publicação, você seguiu as etapas de otimização de um modelo TensorFlow YoLoV4 para ser executado no AWS Inferentia. Você explorou otimizações do AWS Neuron que geram melhor desempenho do modelo com precisão média aprimorada e de uma maneira muito mais econômica. Na produção, o modelo compilado do Neuron é até 37% mais barato no longo prazo, com mínima flutuação de taxa de transferência e latência, quando comparado com a instância de GPU mais otimizada para predições.
Algumas das etapas descritas neste post também se aplicam a outros tipos de modelos e estruturas de ML. Para obter mais informações, consulte o repositório do AWS Neuron SDK GitHub.
Saiba mais sobre o chip AWS Inferentia e as instâncias do Amazon EC2 Inf1 para começar a executar seus próprios pipelines de ML personalizados na AWS Inferentia usando o Neuron SDK.
Este artigo foi traduzido do Blog da AWS em Inglês.
Sobre os autores
Fabio Nonato de Paula é um Senior Manager do time Arquitetos de Soluções para o Laboratório de Annapurna na AWS . Ele ajuda clientes a utilizar o AWS Inferentia e o SDK AWS Neuron para acelerar e escalar cargas de trabalho de Aprendizado de Máquina na AWS. Fabio é apaixonado por democratizar acesso acelerado ao Aprendizado de Máquina e colocar modelos de Deep Learning em produção. Fora do trabalho, você encontrar o Fábio dirigindo sua motocicleta pelas colinas do vale de Livermore ou lendo ComiXology.
Haichen Li é um Engenheiro de desenvolvimento de Software no time do AWS Neuron SDK. Ele trabalha integrando frameworks de Machine Learning com o compilador do AWS Neuron e suas bibliotecas e também desenvolvendo modelos de Deep Learning que se beneficiam particularmente do hardware do Inferentia.
Samuel Jacob é um Engenheiro de Software Senior do time do AWS Neuron. Ele trabalha com o runtime do AWS Neuron para habilitar caminhos de dados de alta performance entre o SDK do AWS Neuron e o hardware do AWS Inferentia. Ele também trabalha com ferramentas para analisar e melhorar a performance do SDK do AWS Neuron. Fora do trabalho, você pode encontrá-lo jogando video games ou brincando com projetos pessoais com placas como RaspberryPi.
Sobre os tradutores
Augusto Toniolo Breowicz é Arquiteto de Soluções para Empresas na AWS.
Fabio Balancin é Arquiteto de Soluções Senior para Startup na AWS.
 |
Explore mais conteúdos sobre Inteligência Artificial na página de Sessions On Demand.Acesse > |