Sua IA funciona na nuvem. E onde o usuário precisa dela?

Latência, operação offline e controle dos dados podem justificar a inferência local. Mas distribuir modelos também significa assumir atualização, segurança e suporte fora do data center.

Press enter or click to view image in full size

Imagine um técnico de manutenção usando um aplicativo para fotografar um equipamento, identificar o componente com ajuda 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 → e preencher o relatório do atendimento. Na demonstração, a imagem chega ao serviço na nuvem, o modelo responde e a sugestão aparece na tela. Tudo como planejado.

Coloque o mesmo técnico em um local sem sinal. Ele consegue tirar a foto, mas não consegue usar o recurso que deveria ajudá-lo a fazer o trabalho. O aplicativo continua abrindo, mas justamente o recurso que deveria ajudar no atendimento deixa de funcionar.

O exemplo é hipotético, mas ajuda a separar duas coisas que às vezes tratamos como se fossem iguais: ter um modelo funcionando e entregar uma funcionalidade nas condições em que ela será usada.

Antes de escolher onde executar a IA, eu começaria por aí: o que precisa continuar funcionando onde o trabalho acontece?

Para mim, é aí que edge computing deixa de ser uma discussão abstrata e vira uma decisão de produto. Há tarefas que podem esperar por uma conexão e outras que perdem o sentido se a resposta chegar depois. Em alguns casos, o problema nem é a espera: o dado não pode ser enviado àquele serviço remoto.

Isso não torna a nuvem uma escolha errada. Mas exige justificar a dependência. Da mesma forma, levar o processamento para perto do usuário só faz sentido se resolver uma restrição real. Caso contrário, a equipe pode trocar uma API que atendia ao produto por uma operação mais difícil de manter.

A novidade não é descobrir que computadores locais existem

Já existem ferramentas para avaliar essa alternativa na prática. O LiteRT, do Google, oferece uma base para executar modelos de machine learning e IA generativa em plataformas de borda, com recursos de otimização e aceleração por hardware.[1] A Apple disponibiliza o Foundation Models framework para acesso ao modelo de linguagem no dispositivo, com funcionamento offline em equipamentos compatíveis e com Apple Intelligence habilitado.[2]

Ter essas ferramentas à disposição não faz com que qualquer modelo rode bem em qualquer aparelho. Mas, quando o produto realmente precisa de processamento local, já existem caminhos de implementação que dão para testar.

O foco aqui é inferência: executar um modelo para classificar uma entrada, transcrever, extrair informações ou produzir uma resposta. Não estamos falando de transferir todo o treinamento e toda a infraestrutura de IA para o telefone do usuário.

Também não começaria pela premissa de embarcar um LLM. Para algumas tarefas, um classificador, um modelo de visão ou uma regra determinística pode ser suficiente. Eu avaliaria essas alternativas antes de assumir o consumo de recursos e o comportamento de um modelo generativo.

“Perto” pode significar lugares bem diferentes

Na discussão sobre edge, precisamos deixar claro de qual lugar estamos falando.

No dispositivo: o processamento acontece no celular, computador ou equipamento que produz ou recebe os dados. É uma alternativa quando a funcionalidade precisa operar sem conexão externa, desde que o modelo, o runtime e as demais dependências já estejam disponíveis ali.

Na infraestrutura do local: um servidor ou gateway atende os equipamentos de uma loja, fábrica ou outra unidade. Ainda pode haver dependência da rede local, mas a inferência pode ser desenhada para funcionar sem internet. A documentação do AWS↳AWS20 conteúdosE-mails de verificação com AWS SES + Lambda (Node.js) e Terraform: do zero ao envioDevSecOps · out 2025Codex na AWS: chegada do agente da OpenAI à nuvem da AmazonDevSecOps · abr 2026Salesforce e AWS ampliam colaboração em IA, CRM e marketplaceDevSecOps · nov 2023Ver tudo em DevSecOps → IoT Greengrass descreve possibilidades de processamento local, predições com modelos e filtragem ou agregação dos dados gerados por dispositivos.[4]

Na borda do provedor: a execução acontece na infraestrutura distribuída do fornecedor. Isso pode reduzir parte do percurso de rede, mas o processamento continua fora do dispositivo e depende de conectividade até esse ambiente.

A diferença importa. Contratar um serviço anunciado como edge não significa que a imagem ficará no celular. Instalar um servidor na unidade também não resolve o uso offline se o aplicativo exige autenticação online antes de cada atendimento.

Por isso eu olharia o fluxo inteiro, e não apenas o endereço onde o modelo está rodando.

Press enter or click to view image in full size

Latência: meça a tarefa, não apenas o modelo

O usuário não separa o tempo de rede do tempo de inferência. Ele pede uma ação e espera conseguir seguir com o trabalho.

A medição deveria acompanhar esse percurso: captura, preparação da entrada, carregamento do modelo, processamento, validação e apresentação do resultado. No caminho remoto, entram também a transmissão e a espera pelo serviço. No local, pesam as limitações do equipamento e a disputa de recursos com o restante do aplicativo.

Eu compararia o mesmo fluxo nos dispositivos que o produto pretende suportar, incluindo os mais limitados. Separaria a primeira execução das seguintes e observaria a mediana e a cauda da distribuição, como p95: o tempo abaixo do qual ficam 95% das execuções medidas.

Na geração de texto, o primeiro token ajuda a avaliar a percepção de resposta, mas não mostra quanto demora para concluir a tarefa. Na análise de uma imagem, tokens por segundo nem sequer é a métrica central.

O teste também precisa durar mais do que a demonstração. Eu observaria memória disponível, consumo de energia e comportamento sob aquecimento durante o uso prolongado. São condições que precisam entrar na avaliação antes do recurso chegar ao usuário.

Quantizar o modelo não dispensa esse trabalho. A quantização pode reduzir sua representação numérica, mas não é uma transformação sem perdas: a documentação do ONNX Runtime alerta para possíveis efeitos na precisão e explica que o ganho de desempenho depende do modelo e do hardware, podendo até haver piora em dispositivos antigos.[3]

Na prática, eu não usaria apenas o fato do modelo caber no aparelho como critério. A funcionalidade inteira precisa funcionar bem naquele equipamento.

Qualidade é requisito, não compensação silenciosa

No exemplo da manutenção, sugerir a família de um equipamento ou ajudar a preencher o relatório pode ser uma tarefa adequada para avaliação local. Uma orientação de reparo com consequência operacional exige outra análise de risco.

Para avaliar o recurso, eu usaria entradas que representem o trabalho: fotos ruins, componentes parecidos, descrições incompletas e situações nas quais o modelo não deveria tentar responder. As imagens escolhidas para uma demonstração não bastam.

Antes do piloto, a equipe precisa definir o que conta como acerto, quais erros são toleráveis e quando a saída exige revisão. E precisa testar a versão que será entregue ao dispositivo. O resultado de outro modelo ou de outra configuração não deve ser herdado automaticamente.

Uma resposta em que o modelo diz “estou confiante” também não deveria autorizar uma ação. Essa decisão precisa de critérios externos, como validação dos campos, limites do caso de uso, regras do produto e revisão humana quando necessária.

Se a execução local não atingir a qualidade exigida, o produto deve lidar com esse limite. Pode pedir uma nova entrada, restringir o recurso ou adiar o processamento. Não há motivo para tratar qualquer resposta como melhor do que admitir que aquela tarefa não pode ser concluída nas condições disponíveis.

Privacidade depende também do que acontece quando dá errado

É possível desenhar uma inferência local sem enviar a entrada a um serviço remoto. Ainda assim, isso não basta para dizer como o aplicativo inteiro trata os dados.

Logs, analytics, relatórios de erro, sincronização e chamadas auxiliares também precisam ser examinados. A imagem que não foi para o modelo remoto pode acabar em um mecanismo de diagnóstico mal configurado.

Um dos pontos mais delicados é o fallback. A regra “se o aparelho não suportar o modelo, use a API na nuvem” parece uma saída prática. Mas, se o dado não pode sair do ambiente, essa saída viola justamente a condição que motivou a execução local.

Eu trataria separadamente duas verificações: o processamento remoto está disponível? E ele é permitido para esta entrada? Ter acesso à API não responde à segunda pergunta.

Em uma solução híbrida, a classificação poderia acontecer localmente, os casos ambíguos poderiam pedir confirmação do usuário e apenas as entradas com envio autorizado seguiriam para a nuvem. Quando o envio não for permitido, o aplicativo precisa oferecer uma alternativa local limitada, uma etapa manual ou uma mensagem clara de indisponibilidade.

Isso, sozinho, não encerra uma análise de conformidade. Mas a implementação precisa respeitar a restrição sobre os dados também quando o caminho principal falha.

Press enter or click to view image in full size

Depois do deploy, você tem uma frota

Ao consumir uma API, a equipe concentra boa parte da execução em um ambiente remoto. Quando distribui a inferência, passa a lidar com as combinações de versões e equipamentos que estarão em uso.

É preciso saber qual aplicativo está usando qual modelo e se o runtime é compatível com o hardware. Durante uma atualização, também importa saber se o download terminou, se há espaço para manter a versão anterior até a instalação terminar e o que acontece com o equipamento que ficou desconectado durante o rollout.

Eu incluiria na operação um manifesto de versões compatíveis, verificação de integridade e autenticidade dos artefatos, distribuição gradual e um mecanismo de recuperação testado. O rollback deve considerar o aplicativo, o modelo e o formato dos dados. Voltar a um único arquivo pode não recuperar o comportamento anterior.

Na observabilidade, começaria pelos dados necessários para acompanhar o funcionamento: versão do modelo, duração da tarefa, falhas de carregamento, recusas e uso de fallback. Não coletaria a entrada bruta por padrão. Qualquer captura de conteúdo precisaria de justificativa e controles próprios, coerentes com a decisão de processar perto do dado.

A telemetria dos equipamentos offline pode chegar depois. Por isso, os registros locais precisam de limites, proteção e critérios de descarte. A sincronização do trabalho também exige identificação das operações, deduplicação e tratamento de conflitos.

Há uma situação que merece ser discutida antes do lançamento: como retirar uma versão problemática de um dispositivo que não está conectado?

Não dá para depender de uma ordem remota imediata. A equipe precisa definir o que aquela versão pode continuar fazendo, por quanto tempo as informações locais são aceitáveis e em que condições o recurso deve se limitar ou parar. Usos críticos exigem análise específica de segurança; executar a inferência no local, por si só, não garante tempo real nem operação segura.

Eu também não consideraria suficiente testar offline ligando o modo avião depois que tudo já foi carregado. O teste precisa incluir reinicialização sem rede, dependências indisponíveis e recuperação depois de uma interrupção.

Press enter or click to view image in full size

A conta não termina quando desaparece a cobrança por chamada

Para comparar custos, eu olharia o ciclo completo do produto. Na execução centralizada, entram processamento, tráfego, armazenamento e operação do serviço. Na distribuída, entram distribuição e atualização dos modelos, desenvolvimento para diferentes plataformas, testes e suporte. Se houver infraestrutura própria, a conta inclui compra, manutenção e substituição dos equipamentos.

Memória, energia e armazenamento do usuário também são consumidos. Mesmo quando não aparecem na fatura da equipe, esses custos afetam a experiência e a lista de dispositivos que o produto consegue atender.

Um filtro local que evita enviar continuamente dados sem utilidade pode gerar economia; é uma hipótese a medir. Já embarcar e manter um modelo grande para uma tarefa rara pode tornar a alternativa local menos atraente.

Antes de chamar uma opção mais barata, é preciso conhecer frequência de uso, volume transferido, hardware e esforço operacional.

Uma régua para decidir

Eu começaria por uma tarefa delimitada, com a execução centralizada como baseline e critérios de aceitação definidos antes da comparação.

Condição observada Caminho a avaliar Evidência necessária A tarefa precisa funcionar sem internet Dispositivo ou infraestrutura local Fluxo completo executado sem dependência externa O dado não pode sair do ambiente definido Inferência dentro dessa fronteira Mapeamento de chamadas, logs, sincronização e fallback A rede compromete o tempo de resposta Aproximar a etapa crítica Medição ponta a ponta nos equipamentos e redes relevantes Vários equipamentos compartilham uma unidade Servidor ou gateway local Capacidade, disponibilidade da rede local e plano de manutenção A qualidade exigida não é atendida localmente Nuvem, infraestrutura mais capaz ou restrição do escopo Avaliação comparável da tarefa e dos erros Uso é esporádico e a rede já atende ao requisito Manter a centralização como baseline Custo total e ausência de ganho relevante ao distribuir

Ao final do piloto, a decisão deveria ser compreensível para quem não participou do teste: qual etapa será local, qual problema isso resolve, em quais equipamentos ela funcionará e quais limites de qualidade serão aceitos. Também precisa ficar claro quem responde por sua operação.

Se a escolha for híbrida, o critério de encaminhamento deve estar documentado e testado. Não pode ficar escondido em um tratamento genérico de exceção que envia tudo à nuvem quando algo dá errado.

A responsabilidade continua quando a conexão acaba

Volte ao técnico diante do equipamento. Para ele, a discussão sobre nuvem ou edge só faz diferença se mudar o que consegue fazer naquele atendimento.

A inferência local pode permitir que a tarefa continue sem internet, manter o dado dentro da fronteira prevista ou entregar a resposta no tempo necessário. Mas esses ganhos precisam sobreviver ao dispositivo mais simples, à atualização interrompida e à entrada que o modelo não consegue resolver.

Eu começaria pela menor etapa que realmente precisa estar perto do usuário ou dos dados. Mediria o resultado e ampliaria o uso local apenas quando houvesse evidência para isso. O restante do sistema pode continuar na nuvem, se ela atender melhor aos requisitos.

Depois do deploy, a equipe ainda precisa sustentar essa escolha, inclusive quando não consegue se conectar ao equipamento para corrigir um problema.

No seu produto, qual tarefa de IA realmente precisa continuar funcionando sem conexão? E, depois do deploy, quem vai manter essa inferência funcionando nos equipamentos que ficaram no campo?