Model Explorer do Google passa a debugar compiladores customizados de IA on-device com adaptadores da Arm

Quem otimiza modelos de IA↳Inteligência artificial440 conteúdosUX e IA: Transformando Experiências Digitais com Inteligência ArtificialProduto & UX · jan 2025MCP: O que é e por que você vai ouvir falar disso em breve?AI · jul 2025IA generativa e a urgência de reconstruir nossa relação com a verdadeAI · jun 2025Ver tudo em AI → para rodar em hardware limitado conhece o problema: o modelo que funciona bem no notebook passa por quantização, lowering de grafo, fusão de operadores e delegação de hardware antes de chegar ao dispositivo final, e qualquer uma dessas etapas pode introduzir uma regressão silenciosa. Até agora, depurar esse pipeline significava ler flatbuffers brutos ou vasculhar logs de texto, um processo lento especialmente em modelos grandes.

O Google publicou em 20 de outubro de 2026, em post assinado por Eric Yang e Alan Ma no Google Developers Blog, como a Arm usou o Google AI Edge Model Explorer, ferramenta gratuita de visualização de grafos de modelos, para resolver esse problema. A Arm construiu adaptadores open-source que plugam formatos intermediários próprios da empresa direto na interface do Model Explorer, abrindo a caixa-preta da compilação para hardware edge.

O problema que a Arm tentava resolver

Segundo o post, toda vez que um framework muda ou uma operação encontra uma restrição de hardware, o grafo de execução exportado pode mudar de forma inesperada. Isso deixa três perguntas em aberto para quem está otimizando o deploy:

• Integridade estrutural: o lowering do grafo introduziu operadores indesejados, como transposições de layout extras?
• Delegação de hardware: o modelo está totalmente delegado à NPU ou GPU, ou subgrafos não suportados caem de volta para a CPU?
• Gargalos em nível de ciclo: quais nós do grafo compilado consomem mais ciclos de computação?

Responder essas perguntas lendo flatbuffers ou logs textuais funciona, mas não escala para LLMs e redes neurais grandes. Foi esse o motivador para a Arm construir uma camada visual específica em cima do Model Explorer.

Três formatos, um só visualizador

A Arm desenvolveu adaptadores para três formatos de representação intermediária usados em seus próprios pipelines de compilação: TOSA, VGF e PTE. Cada um ataca uma etapa diferente do caminho entre o modelo treinado e o binário que roda no silício.

Os três adaptadores são built-in (LiteRT, PyTorch e Hugging Face Transformers) ou plugins da Arm (TOSA, VGF e PTE), e ficam disponíveis via PyPI ou GitHub, segundo a documentação linkada no post original.

Caso 1: a regressão que só aparecia no grafo exportado

O primeiro exemplo prático do post é de um modelo de Neural Super Sampling (NSS) treinado em PyTorch e exportado pelo backend↳Back-end49 conteúdosIntegração front-end com backend: 7 decisões que evitam caos entre APIs, BFF e GraphQLDev (Back & Front) · abr 2026Como criar uma FAKE API REST para testes — JSONPlaceholderDev (Back & Front) · set 2025Construindo um aplicativo de bate-papo de IA simples com Spring AI e AngularDev (Back & Front) · jul 2025Ver tudo em Dev (Back & Front) → Arm do ExecuTorch como arquivo VGF para Vulkan ML Extensions. Ao inspecionar o grafo no Model Explorer, a equipe da Arm encontrou operadores TRANSPOSE que não deveriam estar ali, introduzidos por uma mudança no próprio backend Arm do ExecuTorch.

O ponto relevante aqui não é o bug em si, mas como ele foi encontrado: clicando no nó do grafo (no exemplo, um operador de rescale), o Model Explorer mostra atributos e as conexões de tensor SPIR-V daquele nó específico. Isso elimina a etapa de abrir o arquivo bruto e cruzar offsets manualmente, que é como esse tipo de regressão costuma ser caçado hoje em pipelines sem visualização.

Caso 2: NPU ou fallback para CPU, lado a lado

O segundo caso usa a split-pane view do Model Explorer, que compara dois grafos simultaneamente. A Arm usou esse recurso para colocar lado a lado o grafo de um modelo Ultralytics YOLO rodando em CPU e o mesmo modelo delegado à NPU Arm Ethos-U85.

A diferença estrutural aparece de forma imediata: o grafo de CPU mostra cada camada individualmente, enquanto o grafo delegado à NPU agrupa a rede inteira num único bloco EthosUBackend, entre nós de quantize e dequantize. Para modelos parcialmente suportados em LiteRT ou ExecuTorch, essa visão identifica exatamente quais operadores ficaram de fora da delegação e onde o subgrafo foi fragmentado, algo que normalmente exige rastrear logs de compilação separados para CPU e NPU.

Caso 3: o heatmap que aponta o gargalo real

O terceiro exemplo é o mais interessante para quem lida com performance em hardware de baixo consumo. A Arm rodou o modelo no simulador Fixed Virtual Platform (FVP) da Ethos-U e usou o plugin de node data do Model Explorer para sobrepor o trace de execução ciclo a ciclo diretamente no grafo, como um heatmap colorido por nó.

O resultado, segundo o post, apontou um único nó TRANSPOSE como o principal gargalo de latência do pipeline inteiro. É o tipo de achado que profiling tradicional entrega como número isolado numa tabela, mas que só faz sentido de verdade quando visualizado em cima da topologia do grafo, mostrando exatamente onde aquele nó está posicionado em relação ao resto da execução.

Como instalar e testar

O processo descrito no post segue poucos passos:

1. Instalar o Google AI Edge Model Explorer.
2. Instalar o adaptador correspondente ao formato do seu modelo (LiteRT, PyTorch e Hugging Face Transformers já vêm built-in; TOSA, VGF e PTE são plugins da Arm).
3. Abrir o Model Explorer apontando para o arquivo do modelo.
4. Usar a navegação de grafo e a split view para comparar versões ou backends.

Os adaptadores e o próprio Model Explorer estão disponíveis via PyPI e GitHub, e a documentação cobre navegação de grafo e comparação lado a lado com mais detalhe do que o post resume.

O que muda para quem otimiza IA on-device no Brasil

Para times brasileiros que trabalham com inferência em dispositivos de borda, seja em visão computacional embarcada, automação industrial ou produtos de consumo com NPU dedicada, o ganho prático está em reduzir o tempo entre "o modelo ficou lento" e "sei exatamente qual nó é o culpado". Isso importa especialmente em times pequenos, que não têm engenheiro dedicado a ler flatbuffer e já usam ExecuTorch ou LiteRT como caminho de deploy.

Vale a ressalva de escopo: os adaptadores de TOSA, VGF e PTE são úteis sobretudo para quem já está no ecossistema Arm (Ethos-U, Cortex-M com aceleração) ou usa Vulkan ML Extensions como alvo de export. Quem trabalha só com TFLite puro ou roda tudo em CPU genérica de servidor não ganha muito com essa parte específica do anúncio, embora os adaptadores built-in de LiteRT, PyTorch e Hugging Face Transformers continuem valendo a pena para qualquer pipeline de IA on-device que já exporte modelos nesses formatos.

Fonte: Google Developers Blog