ExecuTorch: como rodar IA no app com PyTorch, sem depender da nuvem

A pergunta "onde a IA do meu app vai rodar?" ganhou uma resposta nova: dentro do próprio aparelho, com o mesmo modelo PyTorch que antes só vivia no servidor.

Durante anos, colocar inteligência artificial num aplicativo significou escolher entre uma API na nuvem, com fatura por chamada e dado trafegando, ou um túnel doloroso de conversão de modelo para rodar algo local. O ExecuTorch, runtime de inferência do ecossistema PyTorch, ataca exatamente esse segundo caminho: ele pega o modelo do jeito que o time de dados treinou e o executa dentro do celular, do óculos inteligente ou do sensor. Este artigo explica o que ele é, o que já roda em produção com ele, e como decidir se o seu próximo app deve embarcar IA, ficar na nuvem ou combinar os dois.

Resumo do artigo

• ExecuTorch é o runtime de código aberto do ecossistema PyTorch para rodar modelos de IA dentro de apps e dispositivos: exporta o modelo para um arquivo .pte e executa em iOS, Android, desktop e microcontroladores, com runtime base de 50 KB.
• Está em produção no Instagram, WhatsApp, Messenger e Facebook, e nos óculos Ray-Ban Meta, alcançando bilhões de pessoas segundo a própria Meta.
• A versão 1.0 saiu em outubro de 2025; em agosto de 2026 o projeto está na 1.4.1, com 14 backends de aceleração documentados, de Apple e Qualcomm a Arm e Intel.
• Embarcar IA reduz latência, exposição de dado e custo por chamada, mas cobra modelos compactos, gestão de bateria e versionamento de modelo. Para a maioria dos produtos, o desenho vencedor é híbrido.

O que é o ExecuTorch e onde ele já roda

O ExecuTorch é o runtime de inferência do ecossistema PyTorch para executar modelos de IA diretamente no dispositivo do usuário: celular, óculos inteligente, desktop e até microcontrolador. É um projeto de código aberto sob licença BSD, criado pela Meta e desenvolvido em conjunto com Apple, Arm, Cadence, Intel, MediaTek, NXP, Qualcomm e Samsung, os parceiros de hardware listados no anúncio da versão 1.0.

Quatro números resumem o estágio do projeto:

Fonte: executorch.ai, documentação oficial e releases do projeto no GitHub, leitura de 26/08/2026.

Isso não é tecnologia de laboratório. O post de engenharia da Meta de julho de 2025 detalha recursos que já rodam embarcados nos apps da empresa:

• Instagram: recorte automático de figurinhas a partir de fotos, com o modelo SqueezeSAM;
• WhatsApp: estimativa de banda para ajustar a qualidade das chamadas em tempo real;
• Messenger: identificação de idioma que funciona mesmo com criptografia de ponta a ponta, porque o texto não precisa sair do aparelho;
• Facebook: sugestão de música de fundo a partir das imagens do post, com o modelo SceneX.

No hardware vestível, a Reality Labs declara o runtime em produção na linha de wearables, incluindo os óculos Meta Ray-Ban Display, para reconhecimento de fala, sensores de movimento e visão computacional; o site do projeto também lista o headset Quest 3 entre os usos em produção. A escala de "bilhões de pessoas" alcançadas é declaração da própria Meta sobre os apps dela, mas serve como o teste de estresse mais público que um runtime embarcado já recebeu.

O problema que ele resolve: conversão de modelo era o gargalo

Antes, levar um modelo PyTorch para o celular significava convertê-lo para outro formato, como ONNX ou TFLite, ou reescrevê-lo em C++. Cada conversão perdia semântica de operações, quebrava a depuração e criava divergências numéricas entre o modelo validado no treino e o que rodava no aparelho. O anúncio da versão 1.0 descreve esse atrito como o gargalo clássico do deploy embarcado: times de ML gastando semanas caçando diferenças de resultado que nasceram na tradução, não no modelo.

O peso desse problema cresceu com os modelos multimodais. Reescrever na mão um transformer de texto padrão era trabalhoso, mas viável; reescrever um modelo que combina encoders de imagem, áudio e texto, trocando componentes a cada iteração de pesquisa, deixou de ser. Como o projeto afirma que mais de 90% da pesquisa em IA acontece em PyTorch, a aposta foi eliminar a tradução em vez de acelerá-la.

A promessa central não é ser o runtime mais rápido do mercado: é fidelidade. O que o time de dados validou no treino é o que roda no bolso do usuário.

Como funciona: do modelo PyTorch ao arquivo .pte

O fluxo tem três passos: exportar o modelo com torch.export, otimizar o grafo para o hardware alvo com o particionador do backend escolhido, e embarcar o arquivo .pte resultante no app, onde um runtime em C++ o executa. Trocar de hardware alvo é trocar uma linha de código: o particionador.

Modelo PyTorch, o mesmo que saiu do treino

torch.export, grafo estável e compacto do modelo

Lowering, otimização para o backend de hardware escolhido

Arquivo .pte, empacotado no app ou baixado como asset

Runtime C++, executa no aparelho via Swift, Kotlin, Objective-C ou C++

Para o desenvolvedor de app, o modelo vira um arquivo como outro qualquer: o time mobile carrega o .pte com a API da plataforma (Swift no iOS, Kotlin no Android, C++ e WebAssembly nos demais alvos) e chama a inferência. Para casos de LLM e multimodal, o projeto oferece APIs de mais alto nível, como o multimodal runner, que recebem texto, imagem e áudio e devolvem tokens em streaming, sem o app precisar orquestrar encoder por encoder. A quantização, etapa quase obrigatória para caber modelo em celular, entra no mesmo fluxo via torchao, a biblioteca de otimização do próprio ecossistema PyTorch.

Em que hardware ele acelera: backends de CPU, GPU e NPU

A documentação estável lista 14 backends de aceleração, cobrindo CPU, GPU, NPU e DSP dos principais fabricantes. Na prática, o mesmo modelo pode ser otimizado para o Neural Engine de um iPhone, o NPU Hexagon da Qualcomm ou um microcontrolador Cortex-M de sensor industrial.

Fonte: página de backends da documentação oficial e anúncio da versão 1.0, leitura de 26/08/2026.

Nem tudo tem a mesma maturidade. No anúncio do 1.0, cinco caminhos foram promovidos a prontos para produção: XNNPACK, Core ML, Qualcomm AI Engine, Arm Ethos-U e Vulkan. MediaTek, Apple MPS e Cadence apareciam em estágio alfa ou beta. O denominador comum de qualquer aparelho continua sendo a CPU via XNNPACK; o ganho extra de NPU depende do chip que o usuário tem no bolso, e um app bem projetado precisa funcionar nos dois cenários.

Quais modelos já rodam: LLMs compactos, visão e áudio

O repositório oficial valida LLMs compactos como Llama 3.2, Qwen 3, Phi-4-mini e LFM2 da Liquid AI, modelos multimodais como Llava, Voxtral e Gemma 3, e modelos de visão e fala como Whisper, MobileNetV2, DeepLabV3 e YOLO26. A lista importa menos pelo catálogo e mais pelo padrão: são todos modelos compactos ou quantizáveis, do tamanho que cabe em memória de celular.

A ponte com o resto do ecossistema é a parceria com o Hugging Face: a biblioteca optimum-executorch exporta modelos do transformers direto para o formato do runtime. No anúncio da versão 1.0, o Hugging Face declarou que mais de 80% dos LLMs amigáveis a edge mais baixados da plataforma rodam no ExecuTorch sem ajuste, e a Mistral AI descreveu rodar o Voxtral, seu modelo de áudio e texto, sem conversão de formato.

O limite honesto: modelo de fronteira não cabe. Ninguém roda o equivalente a um GPT ou Claude completo num celular; o jogo embarcado é dos modelos compactos e quantizados, escolhidos para uma tarefa específica. A boa notícia é que essa classe de modelo melhorou muito, e tarefas como transcrição, classificação, detecção e resposta curta já são território dela.

O que muda para quem constrói app: a decisão de arquitetura

Embarcar inferência muda quatro contas de uma vez: latência (a resposta não faz ida e volta à rede), privacidade (o dado não sai do aparelho), disponibilidade (funciona offline e em rede ruim) e custo (inferência local não gera fatura por chamada). Nenhuma dessas vantagens é automática: elas valem para os recursos que couberem num modelo compacto rodando no hardware real da sua base de usuários.

Para produtos brasileiros, o argumento de privacidade tem um desdobramento prático: processar dado sensível localmente reduz a superfície de tratamento e simplifica a conversa de LGPD com o jurídico e com as lojas, embora não substitua política de privacidade nem desenho de consentimento. Voz, imagem da câmera, texto digitado e saúde são exatamente os dados que mais pesam num formulário de Data Safety e App Privacy, e que a inferência local permite manter no aparelho.

A decisão de arquitetura fica mais clara cruzando dois eixos: quão sensível é o dado e quão pesada é a IA que o recurso exige.

A maioria dos produtos reais cai no quadrante híbrido: o app embarca o que é sensível, frequente e precisa responder na hora, e manda para a nuvem o que exige modelo grande. É o mesmo raciocínio de custo que aplicamos ao comparar assinatura de IA com API sob demanda: a pergunta nunca é qual tecnologia é melhor em abstrato, é onde cada chamada custa menos e entrega mais.

Os limites que entram na conta

IA embarcada cobra em quatro moedas: tamanho de modelo, energia, fragmentação e ciclo de atualização. A primeira já apareceu: qualidade de modelo compacto precisa ser validada por caso de uso, não assumida.

A segunda é física. Inferência sustentada gera calor, e celular não tem ventoinha: o próprio material do projeto lista consumo e limitação térmica entre as restrições centrais do edge, com aparelhos reduzindo desempenho quando esquentam. Recurso de IA que roda o tempo todo precisa de orçamento de bateria, não só de memória.

A terceira é a diversidade de aparelhos, especialmente no Android brasileiro: o NPU do lançamento premium não existe no celular de entrada que boa parte da base usa. O caminho de CPU funciona em todos, mas o desempenho varia, e o produto precisa definir o que degradar em aparelho fraco.

A quarta é operacional: modelo embarcado versiona junto com o app. Corrigir um modelo na nuvem é um deploy; corrigir um modelo embarcado é release nas lojas ou um mecanismo próprio de download de asset, com gestão de versão que a nuvem não pede. E vale registrar a maturidade: a versão 1.0 tem menos de um ano, os backends têm estágios distintos e a cadência de release está intensa: a série foi da 1.0 à 1.4.1 em dez meses, entre outubro de 2025 e agosto de 2026. É saudável para o projeto, mas pede acompanhamento de quem o adota.

ExecuTorch, LiteRT, Core ML ou ONNX Runtime: qual runtime para qual caso

Não existe vencedor único: a escolha acompanha o ecossistema onde o modelo nasce e as plataformas do produto. A regra prática está na tabela.

Fonte: sites e documentação oficiais dos quatro projetos, leitura de 26/08/2026.

Os quatro são maduros e gratuitos; o custo real da escolha está na conversão e na depuração quando o modelo sai do formato de origem. LiteRT e Core ML aceitam modelos convertidos de PyTorch, e para muitos times isso funciona bem: se o seu app é Android com stack Google consolidada, ou 100% Apple com um modelo estável que raramente muda, os caminhos nativos seguem ótimas escolhas. O diferencial do ExecuTorch é eliminar a etapa de conversão para quem itera modelo com frequência em PyTorch, que é onde a maior parte da pesquisa e do fine-tuning acontece hoje.

Como começar sem reescrever o aplicativo

O caminho de menor risco começa com um recurso pequeno e um modelo pronto, não com o LLM dos sonhos. O runtime entra no app como uma biblioteca e o modelo entra como arquivo; nenhuma tela precisa ser reescrita.

1. Escolha um recurso de borda, algo pequeno e frequente: classificar imagem, transcrever voz, detectar objeto, sugerir resposta curta.
2. Parta de modelo validado, os exemplos oficiais e o optimum-executorch cobrem os casos comuns antes de você treinar qualquer coisa.
3. Exporte e meça no aparelho real, latência, memória e bateria se avaliam no dispositivo da sua base de usuários, não no simulador.
4. Defina o fallback, o que acontece em aparelho fraco ou sem o modelo baixado: degradar o recurso, usar modelo menor ou chamar a nuvem.
5. Só então escale o escopo, LLM e multimodal embarcados entram depois que o ciclo de exportar, medir e atualizar estiver rodando redondo.

Para apps React Native, a Software Mansion mantém o React Native ExecuTorch, citado pelo projeto entre as integrações do ecossistema, o que abre o caminho embarcado também para times que não escrevem Swift ou Kotlin no dia a dia. E se o seu produto ainda não tem IA nenhuma, essa decisão de arquitetura é exatamente o tipo de conversa que vale ter antes da primeira linha de código.

Perguntas frequentes

Fontes e método

Este artigo foi apurado em 26 de agosto de 2026, com fontes primárias do projeto e dos fabricantes. Versões, números e recursos citados vêm dos materiais abaixo; declarações de escala e de cobertura de modelos aparecem sempre atribuídas a quem as publicou. A X-Apps não tem vínculo comercial com a Meta nem com os demais projetos citados.

• Site oficial do ExecuTorch, visão geral, números de runtime e ecossistema de backends
• Repositório pytorch/executorch no GitHub, README, releases e licença
• Introducing ExecuTorch 1.0, blog do PyTorch, outubro de 2025, backends, parceiros e depoimentos
• ExecuTorch nos apps da Meta, blog de engenharia da Meta, julho de 2025, recursos em produção
• Documentação de backends do ExecuTorch, lista e alvos de hardware
• Sites oficiais do LiteRT (Google), Core ML (Apple) e ONNX Runtime (Microsoft)

Leia também

• LLM local para Direito: rodar modelos no Mac com Apple Silicon
• Assinatura de IA ou API sob demanda: como decidir com ChatGPT e Claude
• Política de Privacidade do app: o que preparar antes de publicar