Um padrão comum que observamos é que a criação e a implantação de um modelo de ML para fins de produção são feitas por equipes diferentes, geralmente uma equipe de algoritmo de ML e uma equipe de operação de dispositivo. A equipe de ML cuida do treinamento e avaliação do modelo, enquanto a equipe de dispositivos é responsável por migrar o modelo para o ambiente de produção.

Tal separação se deve em parte ao fato de que o treinamento e a inferência divergiram, tanto em relação às plataformas de hardware quanto às pilhas de software. No passado, usávamos o Caffe em um servidor GPU para treinamento e serviço. Hoje em dia, as pessoas usam ferramentas e servidores poderosos para treinamento e, em seguida, implantam modelos em tempos de execução altamente otimizados e em diversos dispositivos. Os problemas de implantação são frequentemente encontrados devido à complexidade do modelo e às limitações de hardware, e a equipe de ML geralmente precisa contar com o feedback da equipe de operação do dispositivo para resolver esses problemas.

Como resultado, os engenheiros de aprendizado de máquina (MLEs) muitas vezes carecem de insights muito básicos sobre a capacidade de implantação de seus próprios modelos. A implantação do modelo de hoje geralmente é um pipeline interno composto por vários scripts Bash/Python abrangendo diferentes máquinas e ambientes. Também envolve várias bibliotecas de código aberto ou kits de ferramentas específicos do fornecedor para conversão de modelo, quantização, ajuste de desempenho e verificação de precisão. Não é uma experiência agradável, em comparação com o desenvolvimento do modelo em um ambiente Python nativo da nuvem.

Além da complexidade do ferramental, a falta de interpretabilidade do desempenho é outro problema. Os relatórios de criação de perfil de cadeias de ferramentas downstream geralmente exigem conhecimento de domínio para entender e converter em insights de modelo acionáveis, como no exemplo do TensorRT a seguir. Juntamente com o longo pipeline de conversão de modelos, é difícil para os desenvolvedores de ML identificar os gargalos reais de desempenho de seus próprios modelos e fazer as alterações corretas.

Apesar dessas desvantagens, a separação entre projetar e implantar modelos ainda é a norma no setor, pois geralmente exigem habilidades completamente diferentes. “Já é difícil contratar um especialista em ML ou um especialista em dispositivos, muito menos um especialista em ambos”, é o que sempre ouvimos de nossos clientes. Mas isso não significa que devemos continuar tolerando o atual fluxo de trabalho de ML.

No Software 1.0, é difícil imaginar que um programa seja escrito por um engenheiro e compilado por outro engenheiro. Os programadores podem compilar o código sozinhos, com pouco ou nenhum conhecimento dos estágios subjacentes, como montagem e vinculação, enquanto ainda conseguem obter insights significativos para corrigir seus códigos. Sem essas percepções, o processo de depuração pode se tornar um vaivém sem fim entre dois engenheiros que não falam a língua um do outro.

Até agora, os problemas mais comuns que vimos que atrasam a implantação de modelos de ML são:

1. Latência/taxa de transferência intolerável
2. Operadores não suportados
3. Incompatibilidade de precisão

Um fluxo de trabalho simples e compreensível para implantação e diagnóstico de modelos é a solução. Uma interface que os engenheiros de ML possam usar e entender por conta própria aumentará muito a produtividade.

Construir um compilador de ML superpoderoso é apenas parte da solução, porque existem algumas diferenças fundamentais entre o Software 2.0 e o Software 1.0: primeiro, novos operadores são constantemente lançados da academia e muitos deles não podem ser compostos pelos já existentes; em segundo lugar, os modelos de ML podem tolerar a substituição do operador de preservação não funcional e ainda manter uma precisão semelhante, o que fornece mais flexibilidade de personalização para desenvolvedores de ML. No entanto, não entraremos em detalhes, porque provavelmente vale a pena criar um blog separado para falar sobre customização de modelo para implantação.

Na OmniML , começamos criando uma ferramenta interna para nossos engenheiros implantarem e criarem o perfil de seus modelos de ML sem o incômodo de estudar o hardware e sua cadeia de ferramentas de ML. Logo percebemos o aumento de desempenho de tal ferramenta. Além disso, essa interface unificada e rica em informações permite que humanos e algoritmos desbloqueiem grandes oportunidades de otimização de modelo. Portanto, esses recursos agora estão formalmente disponíveis nos produtos OmniML: Omnimizer e Omnimizer Enterprise .

Omnimizer — uma plataforma unificada de otimização e implantação de modelos

O Omnimizer foi projetado principalmente para engenheiros de ML que projetam e treinam modelos PyTorch. Isso os ajuda a identificar as falhas de design e reduzir o tempo de produção.

O Omnimizer fornece uma interface nativa do PyTorch e da nuvem para testar rapidamente um modelo no hardware de destino. Os usuários só precisam especificar uma configuração de implantação de alto nível e, em seguida, enviar a solicitação para a nuvem do dispositivo hospedado em OmniML. As principais informações de implantação, incluindo latência geral, latência em camadas e erros de implantação (se houver), serão relatadas da maneira mais simples que um especialista não especializado em hardware possa entender.

O Omnimizer permite que os usuários comparem facilmente a precisão do dispositivo com o modelo original. Ele elimina as dificuldades de transferir o modelo e os dados para um dispositivo diferente, familiarizando-se com diferentes sistemas operacionais e cadeias de ferramentas e mantendo um monte de scripts desorganizados e cheios de bugs. No exemplo a seguir, os usuários podem obter a saída do modelo em uma interface do tipo PyTorch, enquanto a inferência real ocorre em um dispositivo remoto, por exemplo, uma GPU de classe de servidor ou um smartphone.

O Omnimizer não é apenas uma biblioteca de software, mas também uma plataforma MLOps que fornece uma interface amigável para navegar pelos detalhes de desempenho, compartilhar insights de modelo e reproduzir ambientes de implantação. Os usuários podem visualizar as etapas de implantação, obter a latência comparada e entender melhor seu modelo no hardware.

Omnimizer Enterprise — Libere todo o potencial do hardware de IA

Em comparação com a versão da comunidade que auxilia na implantação e otimização do modelo, a versão corporativa oferece otimização automatizada do modelo com base em anos de pesquisa em Neural Architecture Search (NAS) e ampla personalização para as necessidades da empresa.

O NAS sempre foi considerado um processo caro que requer profundo conhecimento em espaço de pesquisa e design de tarefa de proxy. Com o Omnimizer, cada usuário pode aplicar o NAS para personalizar seus modelos para o hardware de destino. Esse processo requer apenas algumas linhas de alteração de código, baixos custos de treinamento e, o mais importante, nenhum requisito para ser um especialista em design de modelo e desempenho de hardware.

O Omnimizer pode se integrar facilmente a repositórios de código aberto e acelerar modelos prontos para uso com pouca otimização manual. Até agora, a OmniML e seus clientes demonstraram aumentos de velocidade de 1,2 a 6,8x nas plataformas NVIDIA e Qualcomm. Esses repositórios serão abertos para usuários corporativos como exemplos:

• YOLO-X (detecção de objetos)
• EfficientDet (detecção de objetos)
• YOLO-P (modelo multitarefa para direção autônoma)
• DDRNet (segmentação semântica)
• ResNet (classificação de imagem)
• DD3D (detecção de objetos 3D)
• RAFT (fluxo óptico)
• DistilBERT (tradução automática)

Experimente o Omnimizer!

O Omnimizer Beta acaba de ser lançado. Cadastre-se agora no site da OmniML e comece a otimizar seu fluxo de trabalho!

Di Wu, Song Han, Lucas Liebenwein, Riyad Islam, Keval Morabia, 
Asma K.T. Beevi, Henry Guo and Shengliang Xu also contributed to this article.