Aprendendo ONNX para negociação - página 4

 

Discussão do roteiro ONNX 2020 nº 2 20200909



Discussão do roteiro ONNX 2020 nº 2 20200909

No vídeo "ONNX Roadmap Discussion", os palestrantes discutem vários tópicos relacionados ao roteiro do ONNX, incluindo inferência de forma, definições de operadores, implementações de referência e a especificação do ONNX. Os palestrantes sugerem a construção de uma infraestrutura de inferência de forma genérica para melhorar a otimização de inferência de forma, reduzindo o número de operadores primitivos, adicionando implementações de referência para cada operador e casos de teste mais bem definidos para garantir a implementação e teste adequados do ONNX. O grupo planeja continuar as discussões dentro do operador SIG e no quadro de discussões do GitHub para adicionar um novo operador.

  • 00:00:00 Nesta seção, os palestrantes discutem o roadmap do ONNX e abordam alguns tópicos sugeridos, especificamente inferência de formas, definição de off e IR, todos mencionados anteriormente no documento do roadmap, com comentários de vários indivíduos. Os palestrantes perguntam se Changming ou Buchan estão disponíveis para explicar suas propostas. Buchan discute seu feedback sobre interferência de forma e como ele teve problemas com isso no passado. Ele sugere a construção de uma infraestrutura de influência de forma genérica que recompila a forma sempre que houver uma alteração no IR para garantir que a otimização de inferência de forma ande de mãos dadas e melhore a otimização simultaneamente. Os palestrantes concluem que isso se aplica mais à otimização do que diretamente à inferência de formas.

  • 00:05:00 entender os recursos atuais do ONNX em termos de inferência de forma e passes de otimização. A infraestrutura existente já oferece suporte à inferência de formas com base em valores de entrada conhecidos e pode ser usada para inferir formas de saída. Pode haver frutos fáceis na atualização do verificador de modelo, mas outras alterações podem exigir mais discussão. O grupo discute se essas mudanças pertencem ao ONNX ou a um lugar diferente. Eles também consideram a ideia de chamar métodos de inferência de forma para cada operador em loops consecutivos para alcançar os resultados desejados. Em última análise, a infraestrutura existente já permite passes de otimização e inferência de forma, mas mudanças e melhorias podem aprimorar esses recursos.

  • 00:10:00 Nesta seção, os palestrantes discutem as definições de operadores e sugerem a redução do número de operadores primitivos, pois outros operadores podem ser combinados com operadores de nível inferior. Eles também discutem o tema da implementação de referência e a necessidade da infraestrutura para avaliar uma sequência de operadores. A implementação de referência atual existe na forma de uma implementação Python no gerador de casos de teste, mas não está organizada de forma a facilitar a avaliação de uma sequência de operadores. Os palestrantes sugerem adicionar algum tempo de execução como o tempo de execução ONNX aos CIs para verificar os subgráficos de função, que podem ser usados para validação.

  • 00:15:00 Nesta seção, os palestrantes discutem a necessidade de implementações de referência para cada operador para garantir que os tempos de execução não diverjam das expectativas do autor. Eles sugerem usar a implementação de referência como um teste de unidade para validar a paridade com o tempo de execução e também como um modo de interpretação para verificar a interoperabilidade e validação. Os palestrantes observam que é possível usar o tempo de execução do ONNX para validar a função, assumindo que a função é composta de ops primitivos que existem no ONNX. No entanto, não é possível usar o tempo de execução ONNX para novos operadores em um subgrafo que inclua novas operações primitivas, pois nenhum outro tempo de execução teria essa implementação. Eles reconhecem que criar uma implementação de referência requer muito trabalho, mas é obrigatório para cada operação. Eles também enfatizam a necessidade de conformidade com o ONNX para garantir que o tempo de execução não seja diferente das expectativas do autor.

  • 00:20:00 Nesta seção, os palestrantes discutem o uso de implementações de referência na especificação ONNX e a importância de uma linguagem clara e concisa na especificação. Enquanto alguns defendem o uso de implementações de referência para remover a ambigüidade no texto em inglês da especificação, outros argumentam que a especificação deve ser clara o suficiente para que as implementações de referência sejam desnecessárias. Os palestrantes também discutem a importância de testes de conformidade rigorosos para garantir que todos os possíveis casos extremos sejam testados. Por fim, o consenso parece ser que, embora as implementações de referência possam ser úteis, elas não devem ser exigidas na especificação ONNX.

  • 00:25:00 Nesta seção, há uma discussão sobre os requisitos para implementação de um operador no ONNX, especificamente sobre a necessidade de uma implementação de referência e procedimentos de teste. Enquanto alguns argumentam que uma implementação de referência para o operador deve ser obrigatória para gerar dados de teste, outros discordam, afirmando que basta fornecer uma função Python para gerar dados de teste ou um conjunto de dados fixo. No entanto, observa-se que ter uma implementação de referência é crucial para quem implementa o operador em tempo de execução para testar adequadamente sua implementação, especialmente para operadores complicados com muitos atributos diferentes. A discussão também esclarece que, embora não seja necessário um tempo de execução de referência para ONNX, é necessária uma implementação de referência para cada operador.

  • 00:30:00 Nesta seção do vídeo, os palestrantes discutiram a importância de ter uma implementação de referência e casos de teste mais bem definidos para garantir a implementação e teste adequados do ONNX. Eles observaram que confiar nos dados de teste gerados pode ser insuficiente e que ter um código simples disponível resolve o problema para todos. A conversa também abordou a necessidade de uma especificação completa e a liberdade do tempo de execução para determinar o que fazer em casos de comportamento indefinido. Alguns palestrantes expressaram preocupação em adicionar uma carga aos operadores proponentes adicionando uma implementação de referência. Eles sugeriram minimizar o esforço de engenharia e revisar os requisitos atuais para adicionar operações ao sistema.

  • 00:35:00 Nesta seção do vídeo, os palestrantes discutem a importância de ter uma especificação completa e inequívoca para ONNX e formas de aplicá-la. Eles concordam que uma implementação de referência em Python seria útil para garantir que as pessoas que implementam operadores nos tempos de execução possam verificar todos os casos de teste. No entanto, eles também reconhecem que a implementação de uma especificação não é simples e ainda há problemas a serem resolvidos. Eles discutem maneiras de esclarecer como a especificação pode ser usada e propõem que a prática e o feedback devam orientar a proposta de novos operadores, em vez de propor um operador e implementá-lo em tempo de execução. Eles também observam que um requisito para adicionar uma nova operação é que ela seja implementada em uma estrutura conhecida.

  • 00:40:00 Nesta seção do ONNX Roadmap Discussion, o grupo discute o processo para adicionar novos operadores às especificações do ONNX. A proposta é mudar a política para adicionar um novo operador, que já requer uma implementação de referência em Python. A discussão deles gira em torno de implementações de referência e testes de conformidade, e eles planejam continuar a conversa no operador SIG e no quadro de discussões do GitHub. O grupo planeja continuar as discussões em sua próxima reunião marcada para a semana seguinte.
 

Discussão do roteiro ONNX 2020 nº 3 20200916



Discussão do roteiro ONNX 2020 nº 3 20200916

A discussão neste vídeo gira em torno de vários tópicos relacionados ao ONNX, incluindo a melhoria do tratamento de erros, a adição de um campo de esquema de metadados predefinido para denotar a criação do modelo, a necessidade de otimização física de quantização e a possibilidade de atualizar modelos ONNX de Model Zoo para as versões mais recentes. A equipe planeja priorizar esses tópicos com base em seu impacto e custo e trabalhar neles após o lançamento da versão 1.8. Além disso, o grupo considera a ideia de criar diferentes vínculos de linguagem para o conjunto de ferramentas ONNX, com interesse particular em Java, para oferecer suporte a diferentes plataformas, como Spark. Os palestrantes também discutem a possibilidade de criar um wrapper Java em torno do ONNX Runtime.

  • 00:00:00 Nesta seção, o palestrante sugere discutir três tópicos com a comunidade: tratamento de erros, aprimoramento do zoológico modelo e implementação de mais operações ou operadores para quantização. Eles planejam utilizar as próximas três sessões para falar sobre o custo e o impacto desses tópicos e para definir a priorização com base nos itens de maior impacto e baixo custo. Eles também abordam uma questão sobre o impacto desses tópicos na versão 1.8 e explicam que a maioria dessas mudanças será feita após a versão 1.8. Um membro da comunidade sugere melhorar o tratamento de erros para que, se o tempo de execução encontrar protobufs malformados, ele não seja encerrado e, em vez disso, retorne um código de erro ou lance uma exceção para garantir uma melhor experiência do usuário.

  • 00:05:00 Nesta seção, a discussão se concentra em melhorar o tratamento de erros do código de carregamento no ONNX para evitar travamentos e melhorar a funcionalidade. A equipe realizou fuzzing no código e descobriu que modelos não confiáveis têm o potencial de derrubar todo o processo, tornando-o uma prioridade máxima a ser abordada. O tempo de execução ONNX tem um processo de verificação diferente do verificador ONNX e ainda não está claro se eles podem compartilhar o mesmo verificador. Além disso, é levantado o tópico de melhor tratamento de erros durante as auditorias, e a equipe planeja seguir essa sugestão.

  • 00:10:00 Nesta seção, o palestrante discute sua biblioteca chamada Trivial, que interage com o ecossistema ONNX e atende a modelos ONNX. Eles propõem adicionar um campo de esquema de metadados predefinido no ONNX para denotar o timestamp quando o modelo foi criado, o algoritmo de treinamento usado para o modelo e qual biblioteca de origem foi usada para gerá-lo. Eles sugerem definir nomes de chave padrão para o campo de metadados e digitá-los também. O palestrante acredita que ter um esquema para o campo de metadados seria útil para bibliotecas e outros usuários que atendem modelos ONNX. A conversa então muda para a necessidade de estender o teste de modelo para cobrir todos os modelos no Model Zoo e fornecer bons exemplos com alta qualidade.

  • 00:15:00 Nesta seção, a discussão gira em torno da necessidade de uma otimização física de quantização, bem como da expansão do zoológico de modelos do ONNX para incluir modelos quantizados. Houve vários pedidos para incluir modelos quantizados no zoológico modelo, e a equipe espera encontrar contribuidores. Eles mencionam um blog onde o modelo ONNX quantizado de Hugging Face se saiu bem, mas eles precisariam da permissão de Hugging Face para publicá-lo. Também foi sugerido que o modelo superior da biblioteca do transformador poderia ser um exemplo para quantização, e a Microsoft e o espaço trabalham nisso. Além disso, houve discussão sobre otimização e alguns concordaram que é melhor deixar a otimização para o tempo de execução, pois está além do escopo das especificações do ONNX.

  • 00:20:00 Nesta seção, os participantes discutem a possibilidade de atualizar os modelos ONNX do Model Zoo para as versões mais recentes usando a ferramenta Version Converter. No entanto, eles observam que o Conversor de versão não está totalmente atualizado e há alguma incerteza se a conversão é necessária, pois o ONNX oferece suporte a todas as versões anteriores. O grupo também considera a ideia de diferentes vínculos de linguagem para o conjunto de ferramentas ONNX, com um interesse particular em Java, a fim de oferecer suporte a diferentes plataformas, como Spark. A adição de uma API Java ou ligações facilitaria o carregamento e a validação de arquivos de modelo e a conversão de outras bibliotecas para o formato ONNX.

  • 00:25:00 Nesta seção, os palestrantes discutem a possibilidade de criar um wrapper Java em torno do ONNX Runtime, o que facilitaria as coisas para projetos de aprendizado de máquina baseados em JVM, como o Spark. Embora seja uma tarefa não trivial, usar as predefinições Java CPP para gerar stubs automaticamente pode ser um bom ponto de partida. A compatibilidade com versões anteriores é crucial para grandes projetos como o Spark, e direcionar o Java 8 exigiria um trabalho significativo. No entanto, se houver interesse e disposição suficientes da comunidade para contribuir, pode ser bom explorar.
 

Discussão do roteiro ONNX 2020 nº 3 20200916



Discussão do roteiro ONNX 2020 nº 3 20200916

A discussão neste vídeo gira em torno de vários tópicos relacionados ao ONNX, incluindo a melhoria do tratamento de erros, a adição de um campo de esquema de metadados predefinido para denotar a criação do modelo, a necessidade de otimização física de quantização e a possibilidade de atualizar modelos ONNX de Model Zoo para as versões mais recentes. A equipe planeja priorizar esses tópicos com base em seu impacto e custo e trabalhar neles após o lançamento da versão 1.8. Além disso, o grupo considera a ideia de criar diferentes vínculos de linguagem para o conjunto de ferramentas ONNX, com interesse particular em Java, para oferecer suporte a diferentes plataformas, como Spark. Os palestrantes também discutem a possibilidade de criar um wrapper Java em torno do ONNX Runtime.

  • 00:00:00 Nesta seção, o palestrante sugere discutir três tópicos com a comunidade: tratamento de erros, aprimoramento do zoológico modelo e implementação de mais operações ou operadores para quantização. Eles planejam utilizar as próximas três sessões para falar sobre o custo e o impacto desses tópicos e para definir a priorização com base nos itens de maior impacto e baixo custo. Eles também abordam uma questão sobre o impacto desses tópicos na versão 1.8 e explicam que a maioria dessas mudanças será feita após a versão 1.8. Um membro da comunidade sugere melhorar o tratamento de erros para que, se o tempo de execução encontrar protobufs malformados, ele não seja encerrado e, em vez disso, retorne um código de erro ou lance uma exceção para garantir uma melhor experiência do usuário.

  • 00:05:00 Nesta seção, a discussão se concentra em melhorar o tratamento de erros do código de carregamento no ONNX para evitar travamentos e melhorar a funcionalidade. A equipe realizou fuzzing no código e descobriu que modelos não confiáveis têm o potencial de derrubar todo o processo, tornando-o uma prioridade máxima a ser abordada. O tempo de execução ONNX tem um processo de verificação diferente do verificador ONNX e ainda não está claro se eles podem compartilhar o mesmo verificador. Além disso, é levantado o tópico de melhor tratamento de erros durante as auditorias, e a equipe planeja seguir essa sugestão.

  • 00:10:00 Nesta seção, o palestrante discute sua biblioteca chamada Trivial, que interage com o ecossistema ONNX e atende a modelos ONNX. Eles propõem adicionar um campo de esquema de metadados predefinido no ONNX para denotar o timestamp quando o modelo foi criado, o algoritmo de treinamento usado para o modelo e qual biblioteca de origem foi usada para gerá-lo. Eles sugerem definir nomes de chave padrão para o campo de metadados e digitá-los também. O palestrante acredita que ter um esquema para o campo de metadados seria útil para bibliotecas e outros usuários que atendem modelos ONNX. A conversa então muda para a necessidade de estender o teste de modelo para cobrir todos os modelos no Model Zoo e fornecer bons exemplos com alta qualidade.

  • 00:15:00 Nesta seção, a discussão gira em torno da necessidade de uma otimização física de quantização, bem como da expansão do zoológico de modelos do ONNX para incluir modelos quantizados. Houve vários pedidos para incluir modelos quantizados no zoológico modelo, e a equipe espera encontrar contribuidores. Eles mencionam um blog onde o modelo ONNX quantizado de Hugging Face se saiu bem, mas eles precisariam da permissão de Hugging Face para publicá-lo. Também foi sugerido que o modelo superior da biblioteca do transformador poderia ser um exemplo para quantização, e a Microsoft e o espaço trabalham nisso. Além disso, houve discussão sobre otimização e alguns concordaram que é melhor deixar a otimização para o tempo de execução, pois está além do escopo das especificações do ONNX.

  • 00:20:00 Nesta seção, os participantes discutem a possibilidade de atualizar os modelos ONNX do Model Zoo para as versões mais recentes usando a ferramenta Version Converter. No entanto, eles observam que o Conversor de versão não está totalmente atualizado e há alguma incerteza se a conversão é necessária, pois o ONNX oferece suporte a todas as versões anteriores. O grupo também considera a ideia de diferentes vínculos de linguagem para o conjunto de ferramentas ONNX, com um interesse particular em Java, a fim de oferecer suporte a diferentes plataformas, como Spark. A adição de uma API Java ou ligações facilitaria o carregamento e a validação de arquivos de modelo e a conversão de outras bibliotecas para o formato ONNX.

  • 00:25:00 Nesta seção, os palestrantes discutem a possibilidade de criar um wrapper Java em torno do ONNX Runtime, o que facilitaria as coisas para projetos de aprendizado de máquina baseados em JVM, como o Spark. Embora seja uma tarefa não trivial, usar as predefinições Java CPP para gerar stubs automaticamente pode ser um bom ponto de partida. A compatibilidade com versões anteriores é crucial para grandes projetos como o Spark, e direcionar o Java 8 exigiria um trabalho significativo. No entanto, se houver interesse e disposição suficientes da comunidade para contribuir, pode ser bom explorar.
 

Discussão do roteiro ONNX 2020 nº 4 20200923



Discussão do roteiro ONNX 2020 nº 4 20200923

A quarta parte da discussão do roteiro ONNX abrange os tópicos de suporte a quadros de dados, pré-processamento, padronização, pipeline de aprendizado de máquina de ponta a ponta e recomendações de ferramentas. O suporte a quadros de dados é avaliado como valioso para modelos clássicos de aprendizado de máquina e pode eliminar a necessidade de pré-processamento. A necessidade de captura de pré-processamento no modelo ONNX é destacada para melhorar o desempenho, com foco na padronização de categorias de alto nível, como processamento de imagem. O pipeline de ponta a ponta é classificado como de baixa prioridade, mas a adição gradual de componentes ao pipeline é sugerida. A discussão termina com uma recomendação para usar uma ferramenta para auxiliar na discussão e análise dos itens da agenda.

  • 00:00:00 Nesta seção, os palestrantes discutem o roteiro do ONNX e as funcionalidades que foram sugeridas pela comunidade. Eles cobriram três seções até agora, incluindo o pipeline de ML e processamento de dados, definição operacional ou IRS e robótica principal. O documento do roadmap inclui uma tabela dos recursos sugeridos, que são classificados como prioridade alta, média e baixa. No entanto, alguns dos tópicos são muito genéricos, dificultando a avaliação de sua importância. Os palestrantes planejam passar os próximos 30 minutos discutindo por que alguns desses recursos foram avaliados como altos e coletando feedback da comunidade sobre quais recursos são mais importantes.

  • 00:05:00 queria saber como o roteiro ONNX está sendo priorizado, esta seção do vídeo discute a importância de um recurso de suporte de quadro de dados e como ele poderia resolver outros problemas dentro da plataforma. O palestrante explica que esse recurso seria valioso para cientistas de dados e poderia potencialmente negar a necessidade de um recurso de pré-processamento. Eles também mencionam a necessidade de obter uma estimativa de custo de engenharia para cada item do roteiro, a fim de priorizar as tarefas de maneira eficaz. Sugestões são bem-vindas, pois é a primeira vez que o roteiro é apresentado dessa forma.

  • 00:10:00 Nesta seção do ONNX Roadmap Discussion, é discutida a importância do suporte do quadro de dados para modelos de aprendizado de máquina. Acredita-se que o suporte a quadros de dados seja principalmente para modelos clássicos de aprendizado de máquina, em vez de DNNs ou outros modelos. O quadro de dados é diferente da sequência porque é uma coleção heterogênea de tensores ou uma tabela relacional com colunas que podem ter tipos diferentes. A importância de cada recurso é avaliada com base no impacto que terá e os custos de engenharia serão considerados. Sugere-se que seja fornecido um comentário por caixa para destacar por que um recurso é de alta ou baixa importância.

  • 00:15:00 Nesta seção, é discutida a importância do pré-processamento em um modelo ONNX. A conversa destaca a necessidade de ter todas as etapas necessárias capturadas no modelo ONNX, em vez de depender de bibliotecas externas, especialmente no contexto de treinamento, onde o pré-processamento pode ter um impacto significativo no desempenho. Além disso, o pré-processamento pode ser útil no lado da inferência, especialmente se não estiver em um ambiente baseado em Python. A discussão também aborda os desafios de padronizar o pré-processamento devido à natureza heterogênea dos tipos de dados. Embora o pré-processamento seja um tema amplo e complexo, a conversa conclui que é necessário considerar operadores e tipos ausentes no ONNX para padronizar o pré-processamento.

  • 00:20:00 Nesta seção, os palestrantes discutem o amplo escopo do pré-processamento e como ele pode incluir não apenas o processamento relacionado à visão, mas também dados de áudio. Embora seja importante considerar o pré-processamento, os palestrantes observam que pode não ser necessário oferecer suporte a todos os tipos de dados e, em vez disso, a padronização em categorias de alto nível, como processamento de imagens, pode ser mais benéfica para os desenvolvedores. No entanto, os palestrantes advertem que mesmo tarefas de pré-processamento aparentemente simples, como redimensionamento de imagem, podem ter diferenças sutis entre as bibliotecas, tornando a padronização um desafio de engenharia. No entanto, padronizar as tarefas de pré-processamento pode ser útil, e os palestrantes sugerem coletar etapas comuns de pré-processamento para consideração futura.

  • 00:25:00 Nesta seção, os palestrantes discutem a prioridade de incluir o pipeline de aprendizado de máquina de ponta a ponta no ONNX, com alguns afirmando que é uma prioridade baixa devido aos outros itens que precisam ser abordados. No entanto, eles reconhecem a utilidade de ter um exemplo completo e uma ilustração de como o ONNX pode ser aplicado, especialmente quando o ONNX Runtime é incluído. Sugere-se a ideia de adicionar gradualmente componentes ao pipeline, com foco na parte de treinamento, ajuste fino do ONNX e, eventualmente, adicionar pré-processamento ao mix. A discussão termina com a recomendação de usar uma ferramenta para facilitar a discussão e análise de impacto dos itens da agenda.

  • 00:30:00 Nesta seção, o palestrante agradece a participação de todos e informa ao público que tentará divulgar a discussão nas redes sociais e no site do ONNX.
 

Discussão do roteiro ONNX 2020 nº 5 20201001



Discussão do roteiro ONNX 2020 nº 5 20201001

Durante o ONNX Roadmap Discussion, a equipe do ONNX discutiu vários recursos que foram sugeridos pelos membros da comunidade e pontuados por diferentes pessoas, incluindo o comitê gestor. Enquanto alguns recursos foram unanimemente acordados, outros dividiram a comunidade. A equipe discutiu a possibilidade de mudar o ONNX IR para vários IRs e bibliotecas centralizadas de otimização de IR. Eles também discutiram a ideia de centralizar as bibliotecas de otimização no ONNX e o requisito para que as operações implementem uma interface padrão e um estilo de codificação. A equipe também debateu a possibilidade de ter um tempo de execução simples para modelos ONNX e o uso de operações Python personalizadas para casos em que o tempo de execução ONNX não está disponível. Além disso, a equipe explorou a relação entre as operações de pré-processamento e o uso de quadros de dados, planejando transformar suas ideias em propostas acionáveis para trabalhos futuros.

  • 00:00:00 Nesta seção, a equipe ONNX discute a planilha de análise de impacto que foi criada para capturar o pensamento de diferentes pessoas sobre o que é importante para o projeto. Eles listaram todos os diferentes recursos que foram sugeridos e obtiveram pontuações de diferentes pessoas, incluindo o comitê gestor e outros membros da comunidade. Eles perceberam que havia alguns recursos em que todos pareciam concordar que era realmente importante ou nada importante, e outros em que a comunidade estava dividida. Eles discutiram os que foram divididos e os próximos passos para aqueles que eles concordaram serem importantes. Eles também falaram sobre a definição de critérios para o que é considerado de alta prioridade e como isso depende de quem está disposto a dedicar tempo para implementar um recurso.

  • 00:05:00 Nesta seção do ONNX Roadmap Discussion, os participantes discutem a ideia de mudar o ONNX IR para vários IRs e bibliotecas centralizadas de otimização de IR. Há algum debate sobre se essas duas ideias devem ser agrupadas, já que otimização e IR são questões separadas. O objetivo de ter vários IRs é simplificar e concatenar operações mais simples, enquanto as bibliotecas de otimização melhorariam o núcleo do ONNX. Há uma discussão mais aprofundada sobre o que significa ONNX IR e esclarecimentos são necessários. Os participantes também discutem como essas possíveis mudanças podem afetar suas pontuações atuais no roteiro ONNX.

  • 00:10:00 Nesta seção, a equipe discute a possibilidade de centralizar as bibliotecas de otimização no ONNX, mas finalmente concorda que a otimização deve fazer parte do tempo de execução e que é de menor prioridade em comparação com outras questões. Eles também discutem o requisito para que as operações sejam implementadas de maneira específica, com uma interface padrão e estilo de codificação, o que já é um requisito, mas pode precisar de ajustes. Eles sugerem que se alguém propõe um estilo específico, ele pode ser aceito se parecer aceitável.

  • 00:15:00 Nesta seção, os palestrantes discutem a ideia de ter um tempo de execução simples para modelos ONNX, o que levanta preocupações sobre a complexidade de exigir um fluxo de execução e IR interno para processar o modelo. No entanto, há um valor em ser capaz de executar e avaliar os modelos ONNX para testar e estabelecer a exatidão, especialmente para revelar quaisquer lacunas nos testes de unidade para os operadores. Embora possa ser discutível quanto esforço e custo seriam necessários para implementar um tempo de execução simples, o tempo de execução ONNX tem a capacidade de conectar operações do Python, que podem ser usadas para essa finalidade.

  • 00:20:00 Nesta seção, os participantes do ONNX Roadmap Discussion falaram sobre a possibilidade de usar uma operação Python personalizada para casos específicos em que o tempo de execução do ONNX não está disponível . Eles discutiram as limitações da operação do Python e a necessidade de uma interface padrão para garantir a viabilidade. Além disso, o grupo discutiu a necessidade de mais recursos de pré-processamento dentro do gráfico ONNX para tornar os modelos mais independentes e portáteis, especialmente para pré-processamento baseado em imagem, como dimensionamento e manipulação de caixas delimitadoras. O grupo observou que o pré-processamento de texto, especificamente a tokenização, é uma questão mais complicada e abrangente, mas eles podem abstrair alguns cenários comuns de pré-processamento.

  • 00:25:00 Nesta seção, os participantes discutem a relação entre as operações de pré-processamento e o uso de quadros de dados. Embora concordem que o pré-processamento e os quadros de dados estão vinculados, eles os veem como entidades separadas que requerem diferentes tipos de trabalho. O pré-processamento é visto como um operador que funciona em linha em uma coluna de um quadro de dados, enquanto a própria extração do quadro de dados mapeia o operador de pré-processamento nas linhas de uma coluna. O grupo vê os dois como intimamente ligados e planeja transformar suas ideias em propostas acionáveis para trabalhos futuros.
 

Discussão do Roteiro ONNX 2021 # 1 20210908


Discussão do Roteiro ONNX 2021 # 1 20210908

Durante a ONNX Roadmap Discussion, a IBM Research apresentou sua proposta para uma nova estrutura de pipeline de aprendizado de máquina que converte padrões típicos de pré-processamento de dados no Pandas Dataframe no formato ONNX. A estrutura, chamada Data Frame Pipeline, é de código aberto no GitHub e pode ser definida usando sua API fornecida, que é executada em Python durante a fase de treinamento. Os palestrantes também discutiram a necessidade de tornar o ONNX visível em outras linguagens além do Python, como Java, C# e C++, e a exportação de modelos ONNX e sua emissão a partir de outras linguagens. Além disso, eles discutiram as funcionalidades atuais dos conversores ONNX Python e C++ e a necessidade de escopo, nomenclatura e correções de funcionalidades ao escrever modelos ONNX.

  • 00:00:00 Nesta seção, Takuya da IBM Research apresenta sua proposta para uma nova estrutura de pipeline de aprendizado de máquina com novos operadores ONNX. A motivação para a proposta deveu-se à incapacidade dos frameworks de pipeline existentes de representar um padrão típico de pré-processamento de dados. Eles criaram um protótipo de uma nova estrutura de pipeline chamada Data Frame Pipeline em Python, que converte padrões típicos de pré-processamento de dados no Pandas Dataframe no formato ONNX. Eles protegeram três novos operadores ONNX, incluindo um operador de data e dois operadores simples, concatenadores de strings e divisores de strings. A estrutura do pipeline é de código aberto no GitHub e pode ser definida usando a API fornecida, que é executada no Python durante a fase de treinamento. O modelo é treinado usando os dados que são gerados do pipeline de quadro de dados e sua estrutura pode consumir modelos de aprendizado de máquina ONNX já convertidos.

  • 00:05:00 Nesta seção, o palestrante discute o formato ONNX e como ele pode ser usado com o tempo de execução ONNX, fornecido pela Microsoft. Eles mencionam que em seu protótipo, eles implementaram 11 transformadores de quadro de dados em Python e os mapearam para operadores ONNX, sendo a maioria mapeamentos simples, mas alguns exigindo análise e conversão, como o transformador de função. Eles também discutem sua abordagem para gerar operadores ONNX com propriedades de corpo carregadas, em vez de realizar operadores de agregação em ONNX. O palestrante compartilha resultados experimentais preliminares que mostram uma aceleração significativa ao aprender o pré-processamento no ONNX, com uma melhoria de desempenho de 300 vezes para codificação categórica. Eles também comparam a acurácia das previsões e citam sua proposta, abrindo espaço para perguntas e comentários sobre as operadoras apresentadas.

  • 00:10:00 Nesta seção, Adam Pogba do Oracle Labs sugere que o ONNX deve ser tornado visível em linguagens diferentes do Python, já que a funcionalidade atual é toda agrupada em Python e não está claro se C++ é um destino válido para vinculação. Pogba explica que o model checker deve estar visível em outras linguagens para que os usuários possam interagir com ele sem precisar de um ambiente Python válido. Além disso, Pogba menciona que o ONNX Runtime ocasionalmente falha ao consumir modelos devido a problemas de análise, e o verificador de modelo pode ser usado para validar e corrigir facilmente esse problema.

  • 00:15:00 Nesta seção, o palestrante discute a funcionalidade principal da verificação de modelo e como seria útil ser exposto em outros idiomas. Embora eles gostariam de tê-lo em Java, eles entendem que nem todos escreveriam uma API Java, portanto, uma API C é uma opção melhor para a maioria dos idiomas se vincularem facilmente. No entanto, é preciso haver um destino estável e apropriado para as pessoas vincularem, e não está imediatamente claro se a API C++ de qualquer uma dessas ferramentas é considerada um destino apropriado para vinculação. O orador está disposto a participar desse esforço, mas não vale a pena tentar galvanizar um grande esforço a menos que haja interesse da comunidade.

  • 00:20:00 Nesta seção, o palestrante aborda a exportação de modelos ONNX e sua emissão de outras linguagens além do Python, como C# e Java, com foco específico em ML.NET e Trivial Library. O palestrante alerta para a necessidade de uma API comum que todos os projetos possam usar para gerar modelos ONNX, especialmente considerando as três implementações diferentes atualmente presentes sem código compartilhado e sujeitas a bugs. A API comum garantiria apenas um local para atualizar e validar os nós e gráficos, proporcionando uma oportunidade de compartilhar força e facilitar a emissão de modelos ONNX por outras bibliotecas de aprendizado de máquina. O palestrante reconhece que, embora isso possa dar muito trabalho, o esforço compartilhado pode fazer o ecossistema ONNX crescer além do Python.

  • 00:25:00 Nesta seção, os palestrantes discutem os conversores ONNX Python e C++ e suas funcionalidades atuais. Eles observam que a documentação do ONNX não é específica o suficiente, o que dificulta o entendimento de certas funcionalidades. No entanto, eles afirmam que muitas das funcionalidades necessárias para a exportação ONNX já existem nesses conversores, mas precisam ser expostas da maneira certa para outros projetos. Além disso, eles discutem a necessidade de escopo, nomenclatura e correções de funcionalidades ao escrever modelos ONNX. Por fim, eles sugerem que os conversores poderiam se beneficiar de estarem vinculados ao sinal de infraestrutura de arquitetura para que possam ser usados facilmente por diferentes pessoas.
 

Discussão do roteiro ONNX 2021 nº 2 20210917



Discussão do roteiro ONNX 2021 nº 2 20210917

No ONNX Roadmap Discussion # 2 20210917, vários palestrantes discutiram várias áreas-chave em que o ONNX precisa ser aprimorado, incluindo quantização e facilidade de fusão, otimização de kernels para plataformas de hardware específicas e adição de funções locais de modelo ao ONNX. Outros tópicos incluíram comentários sobre suporte de pipeline de ponta a ponta, desafios enfrentados por clientes em diferentes plataformas e problemas com a conversão de gráficos GRU e LSTM. Algumas soluções sugeridas incluem fornecer mais informações para back-ends para executar gráficos pré-quantizados, melhorar a interoperabilidade de diferentes estruturas e incluir um namespace relacionado ao gráfico original para permitir uma solução geral e otimizada. Além disso, os palestrantes discutiram a necessidade de uma melhor implantação de pacotes para adoção mais ampla e o potencial de mais conversores a serem desenvolvidos para oferecer suporte a modelos multimodais.

  • 00:00:00 Nesta seção, Martin da Green Waves Technologies discute as duas áreas onde o ONNX precisa de melhorias, quantização e facilidade de fusão. Para quantização, Martin sugere fornecer mais informações para os back-ends executarem gráficos pré-quantizados, pois é impossível para o ONNX seguir todas as maneiras diferentes que os clientes desejam implementar coisas especializadas. Para ajudar nisso, Martin sugere adicionar informações de min max, desvio padrão e média aos tensores, com informações adicionais como estatísticas de outlier, informações de canal por canal e informações de distribuição como possíveis complementos. Para facilidade de fusão, Martin sugere melhorar a interoperabilidade de diferentes estruturas, fornecendo melhores recursos de importação/exportação, o que tornaria mais fácil para o ONNX identificar os conversores corretos a serem usados ao importar/exportar gráficos diferentes.

  • 00:05:00 Nesta seção, o palestrante discute o uso atual de funções para operadores compostos e a dificuldade em otimizar kernels para plataformas de hardware específicas quando os operadores são divididos. Sugere-se a ideia de agrupar funções exportadas em um contêiner de nível superior, possivelmente uma função, e mapear esse contêiner para um kernel otimizado em um back-end específico. O palestrante também sugere a inclusão de um namespace relacionado ao grafo original, permitindo tanto uma solução geral quanto uma solução otimizada. A adição de uma capacidade de importar funções locais de modelo na versão mais recente do ONNX também é mencionada.

  • 00:10:00 Nesta seção, os palestrantes discutem a adição de funções locais de modelo ao ONNX, o que permite que os operadores conversores incluam um corpo de função no proto do módulo como um espaço reservado para operadores que não são definidos no padrão ONNX. No entanto, os palestrantes também observam que deve ser uma prática recomendada para os conversores rotular e comentar sobre o que estão exportando de uma forma que seja legível por máquina. Eles também abordam como a otimização pode afetar as convenções de nomenclatura e sugerem continuar a discussão sobre o tema no canal do Slack ou em uma reunião extra. A próxima apresentação, que é sobre o perfil ONNX, é apresentada.

  • 00:15:00 Nesta seção, é discutido um feedback sobre o suporte de pipeline de ponta a ponta, com o ONNX sendo visto como uma ótima opção para implantações leves em diferentes sistemas operacionais que não exigem requisitos pesados de ecossistema. Os palestrantes expressam esperança na direção de permitir que operadores ONNX em ONNX e ONNX ML executem não apenas modelos, mas também estágios de preparação de dados, incluindo cobrir outros tipos de operações de produção de dados. Eles afirmam que um artefato ou modelo de implantação simplificado ou comum poderia agregar valor, juntamente com a capacidade de economizar esforço e consistência, concentrando-se em frutos mais fáceis de encontrar em torno de conversões padrão.

  • 00:20:00 Nesta seção, o palestrante discute alguns dos desafios enfrentados pelos clientes em diferentes plataformas e observa o valor potencial em continuar desenvolvendo e ampliando a plataforma ONNX. Eles abordam a questão do silo e a necessidade de simplificar a implantação de pacotes para uma melhor adoção. A conversa também inclui comentários de um participante que confirma enfrentar problemas semelhantes e propõe opções para mesclar o servidor Linux ONNX ou encontrar melhores maneiras de ajudar os usuários a converter código personalizado em ONNX. O palestrante também aborda o tema do suporte multimodal e a necessidade de um conjunto de modelos ser representado como um único grafo ONNX. Eles discutem a necessidade potencial de mais conversores e sugerem um movimento geral na direção certa.

  • 00:25:00 Nesta seção do ONNX Roadmap Discussion, a equipe discute exemplos de proxies para modelos de proxy para mostrar os tipos de coisas que os clientes estão usando em ambientes corporativos para tipos de casos de uso sem imagem. Um membro da equipe menciona um exemplo de proxy para um modelo de detecção de fraude que usa alguns dados abertos e é um modelo LSTM de duas camadas relativamente simples. A equipe está investigando mais o assunto e tentando obter mais exemplos de modelos de proxy para apresentar. Eles também discutem problemas com GRU e LSTM não sendo convertidos corretamente e mencionam que gostariam de adicionar suporte para todos os casos.

  • 00:30:00 Nesta seção, os palestrantes discutem os desafios de converter gráficos GRU (gated recurrent unit) em um formato que possa ser lido pelo conversor de um back-end. Eles mencionam que existem certos casos em que a quebra já ocorre no TensorFlow, mas é um desafio transformá-la novamente em GRU. Eles sugerem usar o sinalizador `--custom ops` e criar um kernel que funcione para ele, antes de passar para a ideia de torná-lo uma função ou preservá-lo em termos de semântica. Eles observam que a melhor opção é denotar explicitamente se o usuário deseja que seja dividido ou não, e que o uso de operações personalizadas pode ser a única maneira de fazer isso de forma robusta.

  • 00:35:00 Nesta seção, os palestrantes discutem se é melhor ter o corpo funcional completo tanto no ONNX quanto em alto nível ou apenas ter uma base TF. Para eles, a base TF seria suficiente, pois o ONNX poderia ser usado como prova de resultado ao longo da cadeia. No entanto, eles advertem contra tornar o ONNX centrado no TensorFlow, pois o ONNX deve vir de lugares diferentes. Eles também tocaram na atratividade de ter um subgrafo nomeado com um significado semântico, pensando nele quase como um operador, que precisa ser definido e gerado por vários front-ends diferentes. Finalmente, eles concordaram em fazer apresentações mais profundas para continuar a discussão com pessoas mais experientes.
 

Discussão do Roteiro ONNX 2021 #3 20210922



Discussão do Roteiro ONNX 2021 #3 20210922

Durante o ONNX Roadmap Discussion, os palestrantes abordaram a necessidade de corrigir problemas com a ferramenta de conversão de offset do ONNX para melhorar a adoção do ONNX com a pilha otimizada mais recente para determinados casos de uso. Os palestrantes propuseram uma melhor cobertura de modelos para testar a conversão de offset e resolução de etapas intermediárias que estão faltando atualmente em testes de operador ou camada. Eles também discutiram a importância dos metadados e da infraestrutura de aprendizado federado, incluindo a necessidade de incluir metadados na especificação ONNX para anotações de aprendizado de transferência e o conceito de aprendizado federado para permitir privacidade, eficiência e uso de recursos computacionais. Os palestrantes incentivaram a colaboração da comunidade e solicitaram feedback para discutir e implementar essas ideias. A próxima sessão está marcada para 1º de outubro.

  • 00:00:00 Nesta seção, Manoj da Intel aborda as lacunas nas conversões de offset para modelos ONNX que têm causado problemas para muitos clientes. O problema básico está na conversão de offset, já que muitos clientes não vão e continuam atualizando o offset depois de implantar um modelo em produção. Os clientes estão enfrentando vários problemas com a conversão de offset, como passar de 7 para 10 para 13 para quantização ou não conseguir converter offsets mais antigos para os mais novos para aproveitar o desempenho e a boa precisão. Além disso, o teste de unidade ou todos os testes relacionados a cada operador ou camada não chegam ao ponto em que os ISVs estão satisfeitos e, portanto, a maioria dos clientes ainda está no deslocamento 10 ou 9.

  • 00:05:00 Nesta seção, os palestrantes discutem a necessidade de resolver problemas com a ferramenta de conversão de offset do ONNX, pois ela está dificultando a adoção do ONNX com a pilha otimizada mais recente para determinados casos de uso. Os desenvolvedores que estão integrando a IA e enviando-a em seus aplicativos estão fornecendo feedback sobre a necessidade de corrigir as ferramentas de conversão e garantir que sejam perfeitas. Eles compartilham exemplos de problemas que enfrentaram, como etapas intermediárias ausentes e implementações de adaptadores ausentes, que estão impedindo a transição para modelos de desempenho que são quantizados. Os palestrantes enfatizam a necessidade de uma melhor cobertura e mais modelos a serem testados para garantir uma melhor adoção do ONNX.

  • 00:10:00 Nesta seção do vídeo, os palestrantes discutem a necessidade de aprovação de pelo menos um modelo reprovado de uma das principais empresas de criação para melhorias adicionais no ONNX. A discussão segue para a melhoria na conversão fp16, que era uma das lacunas entre diferentes ecossistemas como mobile e Windows, e como foi corrigida recentemente com as ferramentas de conversão da Microsoft. A responsabilidade pela conversão não é clara, mas a discussão segue para a próxima apresentação sobre o zoológico modelo, onde a inclusão de operadores fonéticos para treinamento ajudará a cobrir todos os modelos em todas as categorias. Eles propõem começar com amostras de treinamento de transformador ou PNL e passar para mais modelos para mostrar a infraestrutura de treinamento distribuído e as técnicas aplicáveis ao ONNX.

  • 00:15:00 Nesta seção, os palestrantes discutem o envolvimento dos modelos ONNX no treinamento, incluindo a importância do treinamento com reconhecimento de quantização e uso de precisão mista. Eles solicitam o modelo fp32 original para comparar melhor a precisão e mostrar o uso de precisão mista para treinamento com modelos ONNX. Eles priorizam a contribuição para amostras de transformadores, mas solicitam ajuda da comunidade para contribuir com outras categorias populares. Eles também discutem propostas futuras para refletir melhor o uso de precisão mista em um modelo como parte dos metadados. Por fim, Gabe Stevens apresenta uma configuração de implantação que a Intel está começando a examinar.

  • 00:20:00 Nesta seção, o palestrante discute o conceito de aprendizado distribuído e federado e suas vantagens em termos de privacidade, latência, eficiência e uso de recursos computacionais. A ideia é implantar modelos em uma frota de dispositivos, onde alguns dos dispositivos possuem um grupo de treinamento que enriquece o modelo usando os dados que eles veem. As modificações propostas para o ONNX permitiriam que ele facilitasse o aprendizado federado, tornando mais provável que os desenvolvedores usassem o ONNX. O conjunto mínimo de adições à API inclui uma maneira de consultar a peça para obter os parâmetros do modelo local, atualizar esses parâmetros e notificar o servidor sobre como o modelo foi alterado para consolidar em um novo modelo que inclua as descobertas do dispositivos.

  • 00:25:00 Nesta seção do vídeo, o palestrante discute a ideia de incluir metadados na especificação ONNX para permitir anotações de aprendizado de transferência e facilitar o treinamento de um conjunto de dados menor com um modelo treinado em um conjunto de dados maior. No entanto, a implementação de tal sistema envolve várias decisões de design que precisam ser deixadas para os implementadores. O palestrante sugere três itens que podem facilitar a infraestrutura básica de tal sistema sem limitar a flexibilidade necessária para desenvolvedores de aplicativos. Eles também mencionam a necessidade de consistência na implantação da versão do modelo em uma frota de dispositivos e a importância de não exigir que apenas os modelos ONNX possam participar de um sistema de aprendizado federado. O palestrante solicita feedback sobre se os projetistas de especificações estão interessados em prestar atenção a esse tipo de configuração de aprendizado e se eles estariam abertos a uma discussão mais aprofundada. Outro palestrante sugere tentar fazer isso com o tempo de execução ONNX, pois ele oferece suporte ao treinamento e algumas provas de conceitos foram criadas para fazer o aprendizado federado usando-o.

  • 00:30:00 Nesta seção, o palestrante expressa seu agradecimento pelo tremendo esforço colocado na apresentação e agradece a comunidade por suas perguntas. O objetivo da apresentação é apresentar ideias ao SIG relevante para discussão posterior e eventuais implementações. A última sessão será realizada no dia 1º de outubro, e o palestrante espera continuar envolvido com essas ideias.
 

Encontro virtual da comunidade ONNX – março de 2021



000 ONNX 20211021 ONNX SC Welcome Progress Roadmap Release

O workshop ONNX começou com uma introdução, onde os organizadores enfatizaram a importância da participação da comunidade no crescimento do ecossistema ONNX. Eles também forneceram uma visão geral da agenda, que incluiu atualizações sobre as estatísticas do ONNX, apresentações da comunidade e as discussões do roteiro do Comitê Diretor do ONNX. As propostas de roteiro visam melhorar o suporte, robustez e usabilidade do framework ONNX, e incluem operadores de pré-processamento, APIs C, aprendizado federado e melhor integração de processamento e inferência de dados. O recente lançamento da versão 1.10 das especificações do ONNX também foi discutido, e os participantes foram incentivados a fazer perguntas e participar do canal ONNX Slack para continuar a conversa.

  • 00:00:00 Nesta seção do workshop, os organizadores fornecem uma visão geral e dão as boas-vindas a todos os participantes. Eles mencionam a vasta gama de produtos disponíveis para IA e incentivam os participantes a conferir. Os objetivos gerais do workshop são obter as atualizações mais recentes sobre o ONNX, seus processos, roteiro e lançamentos, bem como aprender com os participantes da comunidade sobre como o ONNX está sendo usado. Eles incentivam os participantes a compartilhar seus comentários, envolver-se mais com o Comitê Diretor do ONNX, SIGs e Grupos de Trabalho. Eles fornecem uma visão geral da agenda, que inclui a logística do Grupo de Trabalho ONNX, a apresentação do Estado do Estado por Wenming Yi, seguida por Alex, e apresentações da comunidade. Por fim, eles apresentam atualizações interessantes sobre as estatísticas do ONNX, incluindo um aumento de quase 400% nos downloads mensais para 1,6 milhão por mês, mostrando um crescimento saudável no ecossistema.

  • 00:05:00 Nesta seção, o palestrante discute o progresso e crescimento do ecossistema ONNX, enfatizando a importância das contribuições das empresas da comunidade. O palestrante menciona o projeto deep java library da Amazon, que construiu uma boa experiência para a comunidade Java e tem visto muito crescimento. Várias empresas comerciais, como IBM, AMD e Sony, estão fornecendo suporte para o ecossistema e ajudando o ONNX a se tornar o padrão do setor. O palestrante também fala sobre a governança da comunidade e os novos membros do comitê gestor, e convida a participação nas discussões do roteiro, canal Slack, perguntas e respostas no GitHub e contribuição para a documentação e blogs. O próximo palestrante segue com o roteiro, que é crucial para seguir na direção certa e reduzir os modelos ONNX a baterias para CPU e aceleradores.

  • 00:10:00 Nesta seção, o palestrante discute as discussões do roteiro do Comitê Diretor do ONNX, que ocorreu durante o verão. As propostas recebidas de diferentes membros são divididas em quatro grupos de três propostas cada, e cada grupo é apresentado aos respectivos Sigs para aprovação e implementação. As propostas vão desde operadores de pré-processamento, APIs C, verificação de modelos, suporte para emissão de modelos em outras linguagens, adição de informações de metadados em tensores, melhor integração de processamento de dados e inferência, definição de conceitos para aprendizado federado, definição de propriedades de processamento de metadados para melhorar a integridade de dados, modelos e muito mais. O objetivo é permitir melhor suporte, robustez e usabilidade do framework ONNX para todos os usuários.

  • 00:15:00 Nesta seção, o palestrante discute o recente lançamento da versão 1.10 das especificações do ONNX e agradece aos colaboradores por seu trabalho árduo. Haverá mais discussões e detalhes sobre esta última mudança no site next.ai. O palestrante convida o público a postar qualquer dúvida no chat ou no canal geral do ONNX no Slack para continuar a conversa.
 

Dia da Comunidade ONNX! Transmitido ao vivo em 24 de junho de 2022

Este evento está sendo realizado pessoalmente no novíssimo Microsoft Silicon Valley Campus na sexta-feira, 24 de junho.

O evento cobrirá as atualizações da comunidade ONNX, histórias de parceiros e usuários e muitas redes da comunidade.



Dia da Comunidade ONNX!

Sumário breve:

  • 00:00:00 - 01:00:00 O vídeo do YouTube "ONNX Community Day!" discute atualizações e melhorias no trabalho da comunidade ONNX sobre interoperabilidade e flexibilidade para desenvolvedores que trabalham com modelos de aprendizado de máquina. A comunidade ONNX funciona sob governança aberta, e as três categorias de ferramentas, criação, execução e visualização, suportam o envolvimento da comunidade e o uso do ONNX. O vídeo fornece relatórios de progresso em diferentes aspectos, como atualizações nas especificações do ONNX, novos operadores e melhorias nos conversores. O palestrante também destaca os benefícios do ONNX, incluindo uma gama mais ampla de clientes para fornecedores de hardware e acesso a vários frameworks e aceleradores de hardware para usuários. O futuro do ONNX inclui a noção de funções ONNX para fornecer uma especificação executável.

  • 01:00:00 - 02:00:00 O evento ONNX Community Day discute vários tópicos relacionados ao ONNX, incluindo ONNX Model Zoo e ONNX Tutorials, que fornecem modelos de aprendizado de máquina pré-treinados e demonstrações para usar com modelos ONNX. O vídeo destaca o trabalho do ONNX Preprocessing Working Group, que visa padronizar as operações de pré-processamento de dados para melhorar a implantação do modelo. Os palestrantes também discutem os fundamentos da quantização de redes neurais e como o TensorRT oferece suporte a redes quantizadas por meio de várias fusões, incluindo quantização pós-treinamento e treinamento consciente de quantização. Eles também se aprofundam nas limitações do ONNX em representar quantização de baixa precisão e sugerem uma estratégia para estender seu poder de representação usando recorte para induzir precisão entre os nós quantizados e desquantizados. Por fim, o vídeo investiga um estudo de caso sobre a precisão de um modelo salvo do TensorFlow quantizado e ajustado.

  • 02:00:00 - 03:00:00 O ONNX Community Day apresentou vários palestrantes discutindo a importância dos metadados em modelos de aprendizado de máquina e suporte a Java Virtual Machine (JVM) no ONNX. Os palestrantes enfatizaram o uso de tecnologias baseadas em hardware para proteger dados e destacaram a compatibilidade do ONNX com várias bibliotecas de aprendizado de máquina, incluindo DeepJ e Deep Java Library. Eles demonstraram o uso de buffers de bytes para melhor eficiência e discutiram a importância da padronização de metadados para uma IA responsável e explicável. As apresentações também apresentaram histórias de sucesso, incluindo o tempo de execução de um banco chinês aprimorado usando o ONNX e o tempo de execução do ONNX. A comunidade ONNX está trabalhando na criação, consulta e filtragem de metadados do fluxo de trabalho de hubs com suporte para metadados legíveis por máquina no ONNX. No geral, as apresentações destacaram os pontos fortes da plataforma ONNX e o compromisso da comunidade com seu desenvolvimento.

  • 03:00:00 - 04:00:00 O "Dia da Comunidade ONNX!" O vídeo cobre várias atualizações e recursos relacionados ao ecossistema ONNX. Isso inclui discussão sobre simulação de quantização para reduzir a queda de precisão entre modelos quantizados e pré-treinados, implantação de modelos TensorFlow treinados com o kit de ferramentas da NVIDIA em um gráfico ONNX usando TensorRT e melhorias feitas no ONNX Runtime, como forma de tensor otimizada, provedores de execução e suporte para plataformas móveis. Além disso, as atualizações do próprio ONNX foram discutidas, incluindo suporte para a biblioteca XNNpack e a criação de extensões de tempo de execução do ONNX para tarefas de pré/pós-processamento. O vídeo também apresenta a biblioteca Optimum, que se concentra na aceleração de modelos de transformadores desde o treinamento até a inferência.

  • 04:00:00 - 05:00:00 O ONNX Community Day incluiu discussões sobre vários tópicos relacionados ao tempo de execução do ONNX e seus casos de uso. Os palestrantes descreveram os recursos do pacote de tempo de execução ONNX, o conversor PiTorch ONNX e as operações personalizadas no PyTorch. Eles também discutiram casos de uso, como monitoramento de processos e digitalização de comércio, bem como desafios associados à implantação de modelos e testes de compatibilidade. Durante o evento, foi enfatizado que o tempo de execução do ONNX pode ajudar a melhorar o desempenho e reduzir o tamanho da implantação, mas compatibilidade e seleção são essenciais para garantir qualidade e velocidade consistentes.

  • 05:00:00 - 06:00:00 O ONNX Community Day contou com vários palestrantes discutindo várias ferramentas e técnicas usadas para otimizar e implantar modelos de aprendizado de máquina usando a estrutura ONNX. A NVIDIA discutiu sua abordagem para melhorar a qualidade da imagem e a compatibilidade do modelo usando a divisão de blocos para inferência, bem como suas ferramentas específicas do ONNX para depuração e modificação de modelos. A Qualcomm explicou como integrou aceleradores de IA em seus projetos usando ONNX como um formato de intercâmbio e apresentou sua pilha de software que inclui o tempo de execução ONNX e várias ferramentas para otimização e implantação. Além disso, vários palestrantes discutiram a otimização de modelos ONNX usando técnicas como otimização de módulo, ponto de verificação e inferência de forma. O evento destacou a versatilidade e escalabilidade do ONNX para vários casos de uso de dispositivos e incentivou contribuições para continuar crescendo o projeto ONNX. A última parte é focada em simplificar o processo de implantação de modelos de aprendizado de máquina no Spark usando a proposta do SPIP, que visa ocultar as complexidades da conversão do processamento de guias e inicialização do modelo para desenvolvedores. O ecossistema Ascend AI e seus processadores foram introduzidos, incluindo a camada de software "Kung" que fornece APIs para a construção de aplicativos e serviços de IA. A pilha de software Khan foi discutida e o roteiro para adicioná-lo como um novo provedor de execução para o tempo de execução ONNX foi apresentado. O evento terminou com mesas redondas sobre tópicos como ONNX para Mobile e Edge, implantação de modelo, treinamento e operações, conversões e operadores, seguido de um happy hour e feedback da pesquisa.

O resumo detalhado da linha do tempo:
  • 00:15:00 Crie o modo no framework que você preferir e depois exporte seu modelo para um formato comum que possa ser usado por outros frameworks e ferramentas. Isso permite maior interoperabilidade e flexibilidade para desenvolvedores que trabalham com modelos de aprendizado de máquina. Além disso, o ONNX é benéfico para fornecedores de hardware que desejam criar tempos de execução otimizados para modelos de aprendizado de máquina, pois agora eles podem se concentrar no suporte ao conjunto comum de operadores definido pelo ONNX, em vez de suportar várias estruturas diferentes.

  • 00:20:00 Nesta seção, o palestrante discute os benefícios do uso do ONNX, que permite acesso a vários frameworks e aceleradores de hardware para usuários, bem como uma gama mais ampla de clientes para fornecedores de hardware. O desenvolvimento do ONNX é feito pela comunidade sob governança aberta, ou seja, não há uma única empresa controlando. O orador destaca ainda os grupos de trabalho que incluem arquitetura e infra, conversores de operadores, zona de modelo, tutoriais e um novo grupo de trabalho de pré-processamento. O palestrante descreve as três categorias de ferramentas, criação, execução e visualização de modelos ONNX, e fornece algumas estatísticas dos últimos seis meses, como aumento no número de PRs, colaboradores, estrelas e downloads mensais, reforçando o envolvimento da comunidade e o uso do ONNX.

  • 00:25:00 Nesta seção, o palestrante discute os lançamentos e atualizações que aconteceram na comunidade ONNX desde a última atualização da comunidade. ONNX 1.11 foi lançado no início deste ano, que introduziu novos operadores e atualizou alguns operadores, incluindo o hub modelo ONNX, que permite aos usuários puxar modelos pré-treinados de diferentes zoológicos modelo. Além disso, foram introduzidos utilitários como o utilitário de composição e o construtor de funções, juntamente com correções de bugs e melhorias na infraestrutura. O ONNX 1.12 foi introduzido recentemente com mais novos operadores, aprimoramentos de forma e inferência e suporte para python 3.10. O palestrante também discute o processo de roadmap do ONNX e 12 solicitações de roadmap que foram selecionadas para posterior andamento e atribuídas aos grupos de trabalho. Essas solicitações incluem a implementação de novos operadores para pré-processamento de dados, uma API C para ONNX e muito mais.

  • 00:30:00 Nesta seção do vídeo, o palestrante discute o progresso feito ao abordar a necessidade de informações quantizadas mais estruturadas para fluir através do modelo e dos tensores. A proposta de pipeline end-to-end com operadoras ONNX está sendo refinada, pois é identificada como uma interceptação de longo prazo. Houve algum progresso com os conversores até agora, com operações de funcionamento mais altas recebendo suporte. O orador também aborda várias áreas, como a necessidade de mais voluntários por se tratar de um projeto comunitário e um pedido para que as empresas tenham mais pessoas a juntarem-se ao esforço. O palestrante lista diferentes recursos, como site, GitHub, canais Slack e o calendário ONNX.

  • 00:35:00 Nesta seção, o palestrante discute atualizações e melhorias recentes no ONNX. Houve dois lançamentos recentes com várias atualizações, como influência de chip aprimorada para operadores e tratamento mais estável de entradas incorretas e opcionais. Além disso, o palestrante destaca a adição de dois importantes lançamentos: o Model Composer e o Function Builder. O Model Converter também se tornou mais estável e a equipe planeja fornecer melhor suporte para lançamentos mistos no futuro. No geral, é impossível listar todas as melhorias feitas pelos colaboradores, mas eles continuam trabalhando para melhorar o ONNX.

  • 00:40:00 Rama da Operadora SIG fez um resumo das mudanças e atualizações recentes na especificação ONNX. O foco do Operator SIG é evoluir o conjunto de operadoras que compõem a especificação ONNX, agregando novas operadoras e esclarecendo suas especificações. Nas duas últimas versões, novos operadores, como amostra de grade e normalização de camada, foram introduzidos. Operadores existentes, como op de dispersão, foram atualizados para oferecer suporte a índices duplicados, enquanto alguns ops foram estendidos para fornecer suporte a tipos como b float 16 e tipos opcionais. Rama também mencionou planos para promover alguns dos novos operadores para se tornarem funções em breve.

  • 00:45:00 Nesta seção, o palestrante discute os planos para o futuro do ONNX e a compensação entre ter uma especificação compacta e suportar novos tipos de modelos que exigem mais operações na especificação. A solução para esse desafio é a noção de funções ONNX, que fornecem uma especificação executável para uma operação e permitem um equilíbrio entre requisitos conflitantes. O palestrante menciona planos para reduzir o conjunto de operadores primitivos, promovendo-os em funções e permitindo a autoria em Python usando um subconjunto chamado ONNX-Crypt. Exemplos de funções, como a função de ativação do Jello e a operação de abandono, são fornecidos para ilustrar como o uso do fluxo de controle facilita a especificação natural e compacta de sua semântica.

  • 00:50:00 Nesta seção, Kevin Chen atualiza o sinal do conversor e o trabalho feito desde a última reunião. Ele discute as atualizações do conversor front-end, incluindo os conversores PyTorch, TensorFlow e sk-learn para ONNX. Para o conversor PyTorch, a versão mais recente suporta exportações ONNX até ONNX offset 16, e novos recursos foram adicionados, como a capacidade de exportar módulos de rede neural especificamente como funções locais ONNX. Chen também analisa as atualizações do conversor de back-end, como a centralidade ONNX e o conversor ONNX TensorFlow. Por fim, Chen apresenta o roteiro para o sinal do conversor e incentiva as pessoas a se envolverem.

  • 00:55:00 Nesta seção, o palestrante discute atualizações e melhorias para o conversor SK para ONNX, o conversor de chave do detector ONNX e o conversor ONNX TensorFlow. Recomenda-se que os usuários atualizem para as versões mais recentes para melhorar a experiência do usuário ao converter modelos. O roteiro para o stick conversor inclui objetivos como melhorar o ferramental voltado para a comunidade, padronizar as funções de utilidade e melhorar o suporte ao operador e ao deslocamento. Os usuários são incentivados a ingressar no canal de conversores ONNX no Slack ou se inscrever na lista de discussão ONNX Converter SIG para se envolver com a comunidade e fornecer feedback.

  • 01:00:00 Jackie da Microsoft apresenta ONNX Model Zoo e ONNX Tutorials. O ONNX Model Zoo é uma coleção de modelos de aprendizado de máquina de última geração pré-treinados, principalmente contribuídos pela comunidade ONNX. Existem atualmente 168 modelos no zoológico, incluindo 40 modelos ONNX e 35 modelos ONNX baseados em visão para classificação de imagens e detecção de objetos. Os Tutoriais ONNX fornecem documentos e notebooks demonstrando o ONNX na prática para diferentes cenários e plataformas. O Model Zoo teve várias melhorias desde o último workshop, incluindo novos modelos quantizados da Intel e maior cobertura de teste com testes de CI de rotina, corrigindo conjuntos de dados de teste quebrados e colaborando com a equipe Hugging Face para criar uma interface web para modelos de demonstração.

  • 01:05:00 Os palestrantes discutem a disponibilidade de tutoriais e demos para usar o ONNX, incluindo um site que permite o processamento fácil de imagens e modelos ONNX escrevendo apenas algumas linhas de código Python. Eles também discutem o roteiro futuro para o ONNX Model Zoo, com planos para permitir que mais modelos sejam executados pelo ORT e para incorporar mais contribuições, incluindo modelos quantizados e modelos de exemplo de treinamento. Além disso, eles destacam o trabalho do ONNX Preprocessing Working Group, que se concentra em facilitar o pré-processamento de dados para uso com modelos ONNX.

  • 01:10:00 Nesta seção do vídeo, o palestrante discute a falta de padronização nos pipelines de pré-processamento de dados, destacando as diferenças entre bibliotecas populares como Pillow e OpenCV no pré-processamento de imagens. Essas disparidades podem levar a problemas de precisão ao implantar modelos em diferentes plataformas. O palestrante apresenta o objetivo do grupo ONNX de padronizar as operações de pré-processamento de dados para evitar ambiguidade e melhorar a implantação do modelo. O grupo vem trabalhando no desenvolvimento de infraestrutura para incluir o pré-processamento de dados nos modelos, como o desenvolvimento de utilitários de composição e o operador de mapa de sequência para processamento em lote. O grupo ONNX também está investigando maneiras de marcar a parte de pré-processamento de um modelo para identificação por back-ends. Além disso, o grupo está propondo extensões para o operador de redimensionamento, incluindo um filtro anti-aliasing opcional e uma política de manter a proporção.

  • 01:15:00 Os palestrantes discutem a implementação de uma proposta de colheita central ou operação de caminho, que oferece um nível mais alto de abstração e depende de operadores de bloco e corte existentes. Eles incentivam os espectadores a entrar no canal Slack e nas reuniões mensais para compartilhar ideias. A apresentação a seguir é feita por Joaquin Anton, que recapitula o objetivo do grupo de trabalho de pré-processamento ONNX e compartilha o trabalho recente que eles vêm fazendo. Marvin, da Itália, também apresenta a si mesmo e seu trabalho como desenvolvedor e cientista de dados na área de processamento de linguagem natural.

  • 01:20:00 O palestrante fala sobre a importância de verificar a documentação do ONNX antes de começar a trabalhar em um projeto. Eles explicam que nem todos os modelos podem ser facilmente convertidos ou otimizados para ONNX, e é importante garantir que as funções de operação necessárias para o projeto sejam implementadas na estrutura em uso. Além disso, o palestrante desaconselha a suposição de que as melhores opções de desempenho sempre otimizarão um modelo, pois às vezes essas opções podem reduzir a precisão. No geral, é importante considerar cuidadosamente a arquitetura do projeto e verificar a documentação e as ferramentas do ONNX, como o otimizador do ONNX, para evitar erros e garantir uma implantação bem-sucedida na nuvem ou nos dispositivos.

  • 01:25:00 Nesta seção, Jiraj Perry, da Nvidia, discute os fundamentos da quantização de redes neurais e como o TensorRT oferece suporte a redes quantizadas por meio de várias fusões. Ele explica que a quantização é o processo de conversão de valores contínuos em um conjunto discreto de valores usando técnicas de escala linear ou não linear, que podem oferecer inferência mais rápida e menor consumo de memória. No entanto, pode haver trade-offs com precisão. Jiraj também menciona os diferentes esquemas de quantização e a importância dos parâmetros de quantização ou q params. Em seguida, ele apresenta a quantização pós-treinamento (PTQ) e o treinamento consciente de quantização (QAT) e como eles podem determinar parâmetros q.

  • 01:30:00 Nesta seção, o vídeo discute a quantização pós-treinamento (PTQ) e o treinamento consciente de quantização (QAT). O PTQ envolve a execução de um modelo pré-treinado em um conjunto de dados de calibração e a coleta de estatísticas por camada para determinar a faixa dinâmica de cada camada para calcular os parâmetros de quantização. O QAT introduz nós qdq nas camadas desejadas e ajusta o gráfico para um pequeno número de épocas para aprender o modelo ou os parâmetros de quantização. O PTQ é geralmente mais rápido e tem menos controle sobre a precisão final, enquanto o QAT é mais lento, mas oferece mais controle de precisão. O vídeo também destaca as diferenças nas abordagens entre o kit de ferramentas TF Mod do Google e o kit de ferramentas de quantização TF2 da NVIDIA construído sobre o TF Mod.

  • 01:35:00 Nesta seção, o palestrante discute as diferenças entre o kit de ferramentas de quantização da Nvidia e o tf mod em termos de onde os nós qdq são colocados. O kit de ferramentas da Nvidia coloca nós qdq nas entradas e pesos de uma camada na rede, enquanto tf mod recomenda colocá-los nos pesos e saídas de uma camada. O palestrante também descreve como o TensorRT otimiza modelos por meio de fusões de camadas, como convolução de fusão pontual e fusão de pooling, juntamente com fusões dedicadas para nós qdq. Além disso, o otimizador de gráfico do TensorRT executa a propagação qdq para mover os nós q e dq para garantir que a parte máxima do gráfico seja executada na entrada. Os exemplos de fusão apresentados incluem quantização de pool médio e fusão de adição elementar. Finalmente, o palestrante examina a fusão de quantização em um bloco residual.

  • 01:40:00 Nesta seção, o palestrante explica a importância de adicionar nós qdq na ramificação de identidade para obter o melhor desempenho do Tensor RT ao recarregar as operações. As fusões resultantes parecem nós dq dos pesos e entradas sendo propagados além do anúncio e fundidos com nós q após a camada de adição. O palestrante reforça a necessidade de qdq nodes no grafo original para obter o melhor desempenho para o seu modelo e alerta que não usá-los corretamente pode levar a um desempenho ruim no modelo. O palestrante conclui convidando para uma discussão sobre como inserir nós qdq no kit de ferramentas TensorFlow.

  • 01:45:00 Nesta seção, o palestrante reconhece uma dificuldade técnica na navegação dos slides e garante ao público que em breve ela será corrigida. Em seguida, eles passam a discutir um estudo de caso sobre precisão após obter um modelo salvo do TensorFlow quantizado e ajustado. O público é convidado a fazer qualquer pergunta antes de fazer uma pequena pausa.

  • 01:50:00 Nesta seção, o palestrante discute o conceito de quantização e como ela pode ser usada para representar baixa precisão na quantização de redes neurais. A quantização é uma combinação de duas funções: a função quantizada que mapeia valores de ponto flutuante para valores inteiros e a função quantizada que mapeia valores inteiros de volta para uma representação de ponto flutuante. A combinação dessas duas funções é chamada de quantização falsa. Esse processo permite o mapeamento de representações para uma representação somente inteira. O uso de quantização uniforme, particularmente com precisão reduzida, permitiu 1,7 bilhão de amostras por segundo com menos de três microssegundos de latência na plataforma de futebol de rf.

  • 01:55:00 Nesta seção, o palestrante discute as limitações do ONNX na representação de quantização de baixa precisão, especialmente abaixo de oito bits, e sugere uma estratégia para estender o poder de representação do ONNX aproveitando o corte para induzir precisão entre os nós quantizados e desquantizados . Essa estratégia adiciona uma função de recorte extra que é suportada em limites inteiros e não afeta a retrocompatibilidade com bibliotecas e ferramentas existentes. No entanto, essa estratégia se estende apenas até onde o linear quantizado permite ir como um operador e tem algumas limitações em relação a diferentes tipos de arredondamento. O palestrante também menciona seus esforços com a quantização no dialeto de exponenciação (tuonex), que representa quantização falsa em apenas um nó, estendendo-se a um conjunto mais amplo de cenários com transmissões de entrada, opções de quantização binária e muito mais. Esse formato é aproveitado como parte de seus esforços de implantação no fpgas, e suas ferramentas, como q ONNX e nqcdq, integram-se às bibliotecas de quantização existentes e ganharam adoção na comunidade fpga.

  • 02:00:00 Nesta seção, Daniel da Mithril discute como eles desenvolveram uma solução chamada "Blind AI" que permite a implantação de modelos ONNX em enclaves seguros que utilizam hardware para proteger dados. Ao usar tecnologias baseadas em hardware, esta solução fornece isolamento e criptografia do conteúdo da memória do enclave, o que evita qualquer tentativa de despejo de fora. Os dados são descriptografados dentro do enclave e qualquer pessoa mal-intencionada não pode acessar os dados, o que é uma grande vantagem para o proprietário dos dados quando se trata de privacidade e segurança. O Blind AI é uma solução de código aberto fácil de integrar, e é fácil para o provedor de IA manter e vender essa solução.

  • 02:05:00 Nesta seção, o palestrante discute a capacidade de implantar modelos de IA com garantias de progresso, usando o Python SDK para carregar os modelos com segurança e enviar dados para análise sem dar acesso a terceiros aos dados. Destaca-se também a expressividade do ONNX, que permite cobrir diversos casos de uso, incluindo triagem de bagagem, análise de documentos médicos e reconhecimento facial. O alto-falante também apresenta diferentes modelos utilizados na prática e suas velocidades dentro e fora do enclave, com latência adicional razoável devido à proteção que oferece. Além disso, o ONNX requer uma base de código mínima, tornando-o melhor por motivos de segurança e capaz de reforçar cada operador, garantindo o uso seguro do enclave. A apresentação termina com informações sobre o GitHub e como eles podem cobrir vários cenários, além da oportunidade de se aprofundar nos detalhes técnicos de segurança.

  • 02:10:00 Nesta seção, o palestrante discute a proposta de habilitar metadados de IA legíveis por máquina no ONNX, que envolve o rastreamento da proveniência e outras características relevantes de um modelo para identificar como ele se move ao longo do tempo e evolui em um caso de uso específico. A proposta foi inicialmente apresentada ao comitê diretor do ONNX em outubro de 2020 e agora a equipe deseja estender a proposta ainda mais para incluir a criação, consulta e visualização de metadados como parte de um design de ponta a ponta para hubs de modelo e zoológicos. O palestrante enfatiza a importância dos metadados como um facilitador chave de uma IA responsável e explicável e destaca sua utilidade em reduzir os modos de falha e identificar pontos problemáticos para sistemas de IA.

  • 02:15:00 Nesta seção da apresentação do ONNX Community Day, os palestrantes discutem a importância dos metadados em modelos e o potencial de usar RDF para uma abordagem padronizada e mais legível por máquina para representar metadados. Eles explicam como essa abordagem pode ajudar a estabelecer relacionamentos entre entidades, manter a transparência e rastrear a proveniência, respondendo a perguntas sobre o que fez com que um modelo tivesse uma precisão menor do que o esperado. Os palestrantes também discutem o poder de consultar metadados usando SPARQL e explicam como modelos com metadados formatados em RDF podem fornecer informações além do que um cartão de modelo simples pode oferecer.

  • 02:20:00 Nesta seção, o palestrante discute o vocabulário de controle do Furnace, um conjunto de princípios orientadores para tornar os dados e ativos digitais acessíveis, interoperáveis e reutilizáveis. Os princípios do Furnace foram identificados pela comunidade da web semântica e incluem justiça, confiabilidade e sustentabilidade. Os metadados codificados em RDF podem ser consultados usando a ontologia Furnace para descobrir modelos adequados para tarefas NLP, identificar os criadores e o tamanho dos modelos e rastrear a pegada de carbono dos modelos para classificá-los e classificá-los. A extensibilidade do RDF e sua linguagem de consulta, Sparkle, permitem uma extensibilidade infinita além do vocabulário selecionado pelas autoridades do exame. Isso pode permitir o rastreamento de IA responsável e corrente de precisão mista.

  • 02:25:00 Nesta seção, os apresentadores discutem os recursos de consulta e filtragem do ONNX Community Day. Eles mostram como o autor de metadados pode identificar modelos treinados com conjuntos de dados contendo informações privadas ou pessoais usando tags de metadados. Os apresentadores também demonstram como os recursos de filtragem estendidos permitem que os usuários consultem modelos com precisão mista. Eles destacam a visualização de perfis de modelo e técnicas de IA explicáveis para exibir metadados com eficiência. Os apresentadores pedem ação para considerar um design concreto em torno da criação e consumo de modelo que abrange toda a criação, consulta e filtragem de metadados do fluxo de trabalho dos hubs com suporte para metadados legíveis por máquina no ONNX. Eles estão atualmente preparando uma implementação de espantalho e explorando tecnologias para criação de metadados.

  • 02:30:00 Nesta seção, Adam Pocock, do Oracle Labs, discute a importância de oferecer suporte à Java Virtual Machine (JVM) com ONNX. Embora a maioria dos aplicativos de ML seja escrita em linguagens diferentes do Python, como Java, é crucial trazer o aprendizado de máquina para essas linguagens. A API Java de tempo de execução ONNX foi desenvolvida pela Oracle Labs para incorporar aprendizado de máquina em Java e outras linguagens, com recursos como impacto mínimo no desempenho e facilidade de implantação. Adam também fornece um exemplo de código para demonstrar as semelhanças entre a API Java e outras APIs.

  • 02:35:00 Nesta seção, o palestrante discute como alimentar dados e executar um modelo usando o tensor ONNX, uma representação de buffer de bytes para um fluxo de bytes. Embora seja possível usar arrays regulares em Java, o palestrante recomenda o uso de buffers de bytes devido ao seu caminho de cópia zero, o que permite maior eficiência na manipulação dos dados. O palestrante também observa que os arrays multidimensionais de Java não são ideais para aprendizado de máquina porque não são planos e envolvem muita busca de ponteiros. O palestrante discute ainda os planos de atualização para uma versão mais recente do Java, adicionando novos recursos e desenvolvendo para corresponder à árvore de tempo de execução ONNX. Além disso, o palestrante apresenta uma biblioteca de código aberto que grava modelos ONNX de Java, que está disponível em qualquer lugar na JVM.

  • 02:40:00 Nesta seção, os palestrantes discutem a compatibilidade do conjunto de ferramentas ONNX com novas bibliotecas de aprendizado de máquina, como o DeepJ, e como ele se integra ao tempo de execução do ONNX para fornecer desempenho de alto nível. O DeepJ cria uma camada de abstração sobre várias bibliotecas de aprendizado profundo, abstraindo todas as bibliotecas necessárias e fornecendo vários back-ends de operador para os mecanismos de aprendizado de máquina usarem, como Apache MixTape, Tensorflow, PyTorch, ONNX, Pedal e muito mais. Eles também estão explorando maneiras de padronizar os metadados neste conjunto de ferramentas para emitir formatos de metadados padrão enquanto continuam a expandir a enumeração do operador.

  • 02:45:00 Nesta seção, o palestrante discute os benefícios da Deep Java Library, que inclui um conjunto de modelos pré-treinados que cobrem tarefas como classificação de imagens, detecção de objetos, análise de sentimentos e reconhecimento de ações. A biblioteca está pronta para o serviço e passou por testes rigorosos para funcionar com a melhor velocidade possível e controle de memória, conforme demonstrado por seu uso bem-sucedido com a DHL por mais de meio ano sem erros. Além disso, o alto-falante compartilha vários casos de uso em que o tempo de execução ONNX e ONNX foram usados para obter ganhos significativos de desempenho e reduzir a latência. Uma história de sucesso é a de um banco chinês que conseguiu reduzir o tempo de execução de seus modelos OCR de um segundo para menos de 400 milissegundos em uma única imagem. Além disso, o palestrante apresenta o conceito Hybrid Engine, que permite carregar dois motores ao mesmo tempo e proporciona uma transição suave entre eles.

  • 02:50:00 Nesta seção, o palestrante explica um método usando o buffer direto para enviar ponteiros do Python diretamente para o tempo de execução ONNX, o que evita a cópia de dados e fornece um aumento de desempenho. Eles também apresentam o ND Manager, uma arquitetura semelhante a uma árvore implementada na biblioteca DeepDraw para fornecer coleções de memória mais econômicas. O palestrante discute como os clientes podem fazer a transição do uso do PyTorch para o tempo de execução ONNX sem alterar uma única linha de código. Mais tarde, o palestrante da Hype Factors fala sobre sua empresa de inteligência de mídia e como eles escolheram basear sua infraestrutura em torno da JVM para sua experiência de desenvolvedor, ecossistema de componentes reutilizáveis e alta escalabilidade.

  • 02:55:00 Nesta seção, o palestrante discute os aspectos técnicos de seu site de análise de mídia, incluindo o uso da JVM para alimentar a maior parte da funcionalidade do site e a migração para um sistema que enriquece principalmente todos os dados que chegam. Com alguns bilhões de inferências de GPU por dia, os recursos do produto dependem muito do aprendizado de máquina e do gerenciamento de modelo, que se tornou uma parte essencial para manter tudo em funcionamento, levando à criticidade do processo. Os dados abrangem todos os tipos de formatos, incluindo HTML e PDFs, e rastreiam seu tempo de execução para enriquecer os dados em tempo real, incluindo reconhecimento de entidade nomeada, saliência, sentimento e muito mais. Houve muitos desafios ao longo do caminho, incluindo erros de conversão e um raro vazamento de memória no DTL, que demorou um pouco para ser resolvido.
Razão: