Quais etapas são necessárias para migrar algoritmos de visão de montagem para uma NPU Ascend?-Inspeção visual com Huawei Ascend Atlas-Winge Technology

Artigo técnico

Migrar o algoritmo de visão de montagem para o Ascend NPU não significa copiar os arquivos do modelo original para o dispositivo Atlas, mas completar a adaptação do sistema do formato do modelo, operadores, entrada e saída, interface de tempo de execução e critérios de aceitação. O caminho típico é: corrigir a linha de base do modelo original, exportar ONNX, verificar a estrutura do gráfico e os operadores, usar ATC para gerar o modelo OM para o processador Ascend de destino, acessar a inferência por meio do AscendCL e, em seguida, concluir a verificação da consistência pré e pós-processamento, resultados de detecção, desempenho de execução e entrega de versão.

O software de inspeção visual de montagem e os aplicativos de algoritmo do Winge Technology já estão em execução no Huawei Ascend Atlas 200I DK A2. Para projetos que usam modelos de classificação, detecção de objetos ou segmentação, os links de inferência do modelo Ascend NPU podem ser adicionados com base no acesso à câmera existente, configuração ROI, registro de resultados e implantação local.

Quais insumos precisam ser corrigidos antes da migração?

Antes de iniciar a migração, um pacote de linha de base reproduzível deve ser formado, que inclua pelo menos:

Estrutura de treinamento original, estrutura de modelo, pesos e scripts de exportação;
Nome de entrada, tamanho de entrada, tipo de dados e requisitos de dimensão dinâmica para modelos ONNX;
Métodos de ordenação de cores de imagens, dimensionamento, corte, normalização e arranjo de tensores;
Etiquetas de classificação, decodificação de quadros de detecção, limites de confiança, NMS ou regras de processamento pós-segmentação;
Um conjunto fixo de amostras OK, NG e limite e seus resultados esperados;
Dispositivo Target Atlas, modelo de processador Ascend, sistema operacional, CANN e versão do pacote da operadora;
Indicadores de aceitação do projeto, como precisão, detecções perdidas, alarmes falsos, consumo único, rendimento e memória.

Se essas entradas não forem fixas, mesmo que a conversão do modelo seja bem-sucedida, não será possível determinar se a diferença antes e depois da migração vem do modelo, pré-processamento, pós-processamento ou ambiente de versão.

Etapa 1: Estabelecer uma linha de base dos resultados do modelo original

Use o mesmo conjunto de imagens de aceitação para executar o modelo original e salvar os tensores de entrada, saída original, resultados de pós-processamento e decisões finais de negócios. O projeto de detecção de objetos também deve salvar o quadro de detecção, categoria, confiança e resultados NMS; o projeto de segmentação deve salvar o tamanho da máscara, o mapeamento da categoria e os resultados do contorno.

O papel da linha de base não é fornecer uma taxa de precisão unificada, mas fornecer uma base de comparação amostra por amostra para resultados subsequentes de ONNX e OM. Os indicadores do projeto devem ser determinados com base em amostras do cliente, definições de defeitos e condições da estação de trabalho.

Etapa 2: exportar e inspecionar o modelo ONNX

Depois de exportar o ONNX da estrutura de treinamento, você precisa verificar:

Os nomes dos nós de entrada e saída são estáveis?
Se o tamanho da entrada é fixo ou dinâmico;
Se a versão do operador e a estrutura do gráfico estão em conformidade com o ambiente de conversão alvo;
Se devem ser incluídos nós que são usados apenas durante a fase de treinamento;
Se os resultados de execução do ONNX e os resultados do modelo original estão dentro da faixa de erro acordada.

Nesta etapa, você deve primeiro resolver o problema de exportação do próprio modelo e, em seguida, inserir a conversão do lado Ascend para evitar trazer as diferenças do modelo de origem para o lado do dispositivo.

Etapa 3: verifique a compatibilidade do operador e a estrutura do gráfico

Antes da conversão ATC, devem ser verificados os operadores, atributos, tipos de dados e restrições de forma utilizados pelo modelo. Se houver operadores ou combinações não suportados, você poderá escolher reescrita de gráfico, substituição de operador equivalente, divisão e pós-processamento ou operadores personalizados com base na estrutura do modelo. Você não deve usar apenas "execução do comando de conversão concluída" como critério de conclusão da adaptação.

Para lote dinâmico, tamanho de imagem dinâmico ou dimensões dinâmicas, as engrenagens correspondentes precisam ser configuradas de acordo com a entrada real da estação de trabalho. Estações de montagem com câmeras fixas e dimensões de detecção fixas geralmente podem usar formas fixas primeiro para reduzir ramificações de tempo de execução e facilitar a aceitação.

Etapa 4: Use ATC para gerar o modelo OM

A documentação oficial do Ascend da Huawei afirma que o ATC é usado para converter modelos de estrutura de código aberto, como ONNX, em modelos OM offline que podem ser reconhecidos pelo processador Ascend AI. Uma estrutura de comando típica é a seguinte:

atc --model=modelo.onnx 
--framework=5 
--saída=modelo_atlas 
--input_shape="imagens:1,3,H,W" 
--soc_version=<modelo de processador Ascend alvo>

Os parâmetros reais devem ser consistentes com a entrada do modelo, o processador de destino e o ambiente do projeto. Durante a conversão, o SHA-256 do comando ATC, versão do ambiente, log de conversão, relatório de inspeção e arquivo gerado devem ser salvos para rastrear e reproduzir o processo de construção do modelo OM.

Etapa 5: Conecte-se ao link de inferência AscendCL

Depois que o modelo OM é gerado, a inicialização de recursos, a seleção de dispositivos, o carregamento do modelo, o gerenciamento de memória de entrada e saída, a execução do modelo, a leitura de resultados e a liberação de recursos precisam ser concluídos no aplicativo do lado do dispositivo. O caminho de dados completo para um sistema de visão de montagem normalmente é:

Câmera industrial ou arquivos de imagem
-> Decodificação, corte e verificação de qualidade de imagem
-> redimensionamento, conversão de cores, normalização e arranjo de tensores
-> Raciocínio do modelo OM
-> Classificação, quadro de detecção ou decodificação de resultado de segmentação
-> ROI com regras de negócios de montagem
->PASS/FAIL/UNKNOWN
-> Diagrama de evidências, registro de resultados e interface da estação de trabalho

A interface de inferência é responsável apenas pelo cálculo do modelo, e a determinação final da estação de trabalho também lida com desduplicação de gatilho, qualidade de imagem, evidência de resultado, status anormal, interface PLC ou I/O e rastreamento de dados.

Etapa 6: Verifique a consistência do pré-processamento e pós-processamento

As diferenças comuns nos projectos de migração não provêm necessariamente do próprio modelo. Ordem de cores, método de interpolação, coeficiente de normalização, método de quantização, layout de tensor, escala de coordenadas e parâmetros NMS podem alterar a saída.

Recomenda-se comparar de acordo com os seguintes níveis:

Camada de entrada: compare os tensores que entram no modelo original e no modelo OM;
Camada de saída: compare a forma, intervalo de valores e ordem dos nós da saída original do modelo;
Camada de algoritmo: compare categorias, caixas de detecção, máscaras e confiança;
Camada de negócios: Compare os resultados PASS, FAIL ou UNKNOWN de cada amostra;
Camada de evidências: compare locais de defeitos, mapas de anotações e registros de resultados para ver se eles correspondem à mesma peça de trabalho.

Somente localizando as diferenças camada por camada podemos avaliar se a conversão do modelo, o processamento de dados ou as regras de negócios precisam ser ajustadas.

Etapa 7: Conclua a verificação de desempenho e estabilidade do dispositivo

Os testes de desempenho devem ser realizados em dispositivos Atlas alvo, tamanhos formais de imagem e links de processamento reais, distinguindo entre:

Tempo de aquisição ou decodificação da imagem;
Tempo de pré-processamento;
Tempo de inferência de modelo único;
Tempo de pós-processamento e regras de negócio;
imagem de evidência e tempo de gravação do arquivo de resultados;
Tempo de resposta ponta a ponta da estação de trabalho.

Os resultados do teste também devem registrar a versão do modelo, hash do arquivo OM, versão CANN, modelo do processador, tamanho de entrada, lote, modo de precisão, número de aquecimentos e número de amostras. A precisão, o tempo do ciclo de produção e a estabilidade a longo prazo são confirmados por inspeções independentes de projetos específicos e condições operacionais contínuas.

Etapa 8: Forme uma entrega de versão rolável

A entrega formal deve conter pelo menos:

Modelo original ou arquivos fonte do modelo dentro do escopo acordado;
Modelo ONNX e instruções de exportação;
Modelo OM, comando ATC, log de conversão e valor de verificação;
Pré-processamento, inferência, pós-processamento e código de interface de negócios;
Sistema operacional, CANN, pacote do operador e lista de versões dependentes;
Resultados de verificação de amostras, registros de diferenças e relatórios de testes de desempenho;
Instruções de configuração, inicialização de serviço, registro, atualização, backup e reversão.

Winge Technology pode implementar trabalho de migração de modelo junto com câmeras, óptica, ROI, I/O, interfaces, rastreabilidade de resultados e implantação local, tornando a inferência de modelo parte de um sistema completo de inspeção de montagem, em vez de uma demonstração de modelo isolada.

Quais questões têm maior probabilidade de afetar os resultados da migração?

pergunta	Sintomas comuns	direção de processamento
As definições de entrada são inconsistentes	Mudança geral nos resultados ou nível de confiança anormal	Cor fixa, tamanho, normalização e layout de tensor
O operador ou forma é incompatível	A conversão ATC falha ou a estrutura de saída muda	Reescrita de gráficos, substituição de operadores, engrenagens dinâmicas ou operadores personalizados
Pós-processamento inconsistente	O número, localização ou categoria dos quadros de detecção são diferentes	Decodificação unificada, limiarização, NMS e restauração de coordenadas
A combinação de versões não foi corrigida	O mesmo modelo funciona de maneira diferente em ambientes diferentes	Sistema fixo, CANN, pacote de operador e registro de construção OM
Apenas testar o modelo leva tempo	A batida ao vivo ainda não atende aos requisitos	Link completo desde a aquisição da medição até a saída do resultado
Falta de coleta de validação independente	Não é possível determinar se a migração mantém os resultados do negócio	Use amostras OK, NG e limite que não estão envolvidas no ajuste de parâmetros

Perguntas frequentes

Os modelos ONNX podem ser executados diretamente no Ascend NPU?

Geralmente é necessário usar o ATC para converter o modelo ONNX em um modelo OM offline baseado no processador Ascend de destino e no ambiente CANN e, em seguida, carregá-lo e executá-lo por meio de interfaces do lado do dispositivo, como AscendCL.

A conversão para gerar arquivos OM significa que a migração foi concluída?

Não é igual a. Também é necessário completar o acoplamento de entrada e saída, consistência pré e pós-processamento, comparação de resultados amostra por amostra, testes de desempenho do lado do dispositivo, tratamento de exceções e verificação de entrega de versão.

Todas as regras tradicionais de visão precisam ser alteradas para redes neurais?

Não há necessidade. As regras ROI com posições fixas e limites claros podem continuar a ser mantidas; modelos de classificação, detecção de objetos ou segmentação são usados para lidar com mudanças de categoria, planos de fundo complexos e tarefas de reconhecimento semântico, e os dois podem ser combinados no mesmo aplicativo Atlas.

O mesmo modelo de OM pode ser usado diretamente para todos os dispositivos Atlas?

Os parâmetros de conversão do modelo OM estão relacionados ao processador Ascend alvo e ao ambiente de software. Ao implementar o projeto, o modelo do processador, CANN e a versão do pacote da operadora devem ser confirmados de acordo com o dispositivo alvo, e os registros de construção correspondentes devem ser mantidos.

Como avaliar se os resultados antes e depois da migração são consistentes?

Amostras fixas devem ser usadas para comparar o tensor de entrada, a saída original do modelo, os resultados do algoritmo e o julgamento final do negócio, camada por camada, e a aceitação deve ser baseada no erro, na precisão e nas regras da estação de trabalho confirmadas por ambas as partes. Você não pode comparar apenas um pequeno número de imagens de demonstração.

fontes oficiais

Huawei Ascend: modelo ONNX convertido para modelo OM

https://www.hiascend.com/document/detail/zh/CANNCommunityEdition/81RC1beta1/quickstart/quickstart/quickstart_18_0010.html

Huawei Ascend: parâmetros de linha de comando ATC e restrições do operador

https://www.hiascend.com/document/detail/en/canncommercial/850/devaids/atctool/atlasatc_16_0039.html

Huawei Ascend: construção de modelo AscendCL e desenvolvimento de aplicativos

https://www.hiascend.com/document/detail/zh/canncommercial/850/appdevg/acldevg/aclcppdevg_000027.html

Atlas, Ascend, CANN, AscendCL e nomes relacionados pertencem aos seus detentores de direitos. Este artigo explica os métodos de adaptação fornecidos por Winge Technology para projetos de visão de montagem e não significa que os detentores de direitos relevantes participem ou endossem o projeto específico. As capacidades dos equipamentos e ferramentas estão sujeitas aos documentos da versão oficial correspondente, e os resultados do projeto estão sujeitos ao modelo real, amostras, equipamentos e condições de aceitação.