Seu Dispositivo de Borda Foi Avaliado em uma Passagem Direta. Seu Agente Executará um Loop.

A conversa sobre hardware de IA de borda se tornou muito mais honesta no último ano. Um artigo recente neste site argumentou que a antiga hierarquia de design — “maximizar o throughput, então gerenciar energia e térmicos ao redor dele” — se inverteu, e que para implantações industriais a energia agora tem prioridade máxima, com o throughput bruto ficando por último. Isso segue um argumento que esta publicação tem defendido há algum tempo: que os dispositivos de borda são limitados termicamente, não por MIPS/computação, e que os smartphones já operam nesses limites. Ambos são correções reais e já estavam atrasados.

Mas ainda carrega uma suposição do mundo que está corrigindo. Cada item nessa hierarquia é orçado contra uma carga de trabalho presumida, e a carga de trabalho que quase todo mundo ainda está orçando é uma única passagem direta: um modelo recebe uma entrada, produz uma saída, e o silício tem um momento para esfriar.

Isso não é o que um agente faz. Um agente decide, chama uma ferramenta, lê o que volta e decide novamente. Quantas vezes ele percorre esse loop não é uma propriedade do seu hardware, nem realmente uma propriedade do seu modelo. É uma propriedade do problema que alguém entregou a ele naquela manhã. Tenho agentes rodando em hardware de borda, e o que mais demorou para eu aceitar não foi que eles eram lentos. Foi que o custo de uma execução estava sendo definido em algum lugar ao qual eu não tinha visibilidade no momento do design.

O Loop É Ilimitado Até Alguém Digitar um Número

Isso não é uma formulação retórica; é assim que os frameworks são realmente construídos. No SDK de Agentes da OpenAI, o executor “executa um loop”, e quando o modelo produz chamadas de ferramenta, o runtime “executa essas chamadas de ferramenta, anexa os resultados e reexecuta o loop”. A única coisa que o interrompe é um limite de turnos — exceda max_turns e você recebe uma exceção — e a documentação observa que você pode passar max_turns=None para desativar o limite totalmente.

Em um servidor, esse número é uma decisão de faturamento. Alguém percebe a fatura.

Em um dispositivo, esse número é uma decisão térmica, porque o comprimento do loop é o ciclo de trabalho. E o ciclo de trabalho é a única variável que o resfriamento passivo não pode contestar.

Carga Sustentada Faz Algo Diferente em um Telefone do que um Benchmark Faz

Um benchmark de março de 2026 colocou quatro plataformas sob exatamente esse tipo de carga: um modelo quantizado de 1,5 bilhão de parâmetros, um prompt fixo de 258 tokens, vinte execuções consecutivas, medindo throughput, potência e temperatura em cada uma. É um preprint, e ele avalia um modelo em quatro dispositivos, portanto trate os números específicos como uma caracterização dessas plataformas, e não como uma lei da natureza. O formato do resultado é o que importa.

Um iPhone 16 Pro atingiu pico de 40,35 tokens por segundo e não conseguiu mantê‑lo. A degradação apareceu dentro de duas inferências. Estabilizou em 22,56 tokens por segundo — uma redução de 44 % — e permaneceu limitado por 65 % do benchmark. O escalonamento dinâmico de voltagem e frequência, o mecanismo que reduz a frequência do clock quando a temperatura da junção sobe, fez exatamente o que existe para fazer.

O Galaxy S24 Ultra falhou de forma diferente, e pior. Em vez de degradar, o governador térmico Android impôs um piso rígido de frequência da GPU na sexta iteração, a 78,3 °C, e a inferência parou. Os autores apontam, melhor do que eu poderia, que para implantações de agentes isso é “mais disruptivo que degradação graciosa”, porque o sistema não fica mais lento; ele se torna inutilizável.

Agora segure o detalhe que torna isso condenatório e não apenas interessante. Cada uma das vinte execuções usou o mesmo prompt. Essa é a carga de trabalho mais amigável que o hardware de um agente jamais verá, e dois telefones flagship não conseguiram sustentá‑la por vinte repetições. Isso também não é uma descoberta nova — ponto MELTing, apresentado no MobiCom em 2024, concluiu que por razões de energia e térmicas “a execução contínua de LLMs permanece elusiva”. Dois anos e vários nós de processo depois, a mesma barreira.

Duas Curvas Se Aproximam, e Seu Produto Falha Onde Elas Se Cruzam

O loop de um agente é pior que um prompt repetido de maneira específica e mecânica.

A decodificação é limitada pela largura de banda da memória: o throughput é governado por quão rápido o modelo pode ler seu cache de chave‑valor, não por quantas operações o chip pode teoricamente executar. Esse cache cresce com o contexto. Cada passo do loop anexa um resultado de ferramenta, uma observação, um plano parcial — então o décimo passo gera tokens contra um cache materialmente maior que o primeiro passo.

Enquanto isso, o dispositivo esquenta, e o governador reduz os clocks.

Assim, o custo por passo aumenta exatamente no momento em que a capacidade do dispositivo de pagá‑lo diminui. As duas curvas convergem, e onde quer que se encontrem é onde seu produto falha. Nunca é no passo um. O passo um é onde você testou.

Há também um problema de escala por trás disso. O trabalho generativo é simplesmente uma ordem de despesa diferente da que o silício de borda gastou durante uma década: medido em 88 modelos, o custo de classificação de texto fica em torno de 0,002 kWh por mil inferências contra 0,047 kWh para geração de texto — aproximadamente vinte vezes mais, antes de qualquer loop multiplicá‑lo. Essas medições foram feitas em uma GPU de data‑center, não em um celular, portanto leia‑as como uma razão entre tipos de trabalho e não como um valor de potência para seu dispositivo. Para escala, o mesmo estudo coloca uma carga completa de smartphone em 0,022 kWh.

Compre Baseado em Joules por Tarefa Concluída, Não em Tokens por Segundo

O resultado mais útil naquele benchmark de 2026 é o que parece menos impressionante.

Um NPU Hailo‑10H gerenciou 6,9 tokens por segundo com menos de 2 watts. Lento — genuinamente lento, e os autores afirmam isso. Mas seu coeficiente de variação de throughput foi de 0,04 %, duas ordens de magnitude mais estável que qualquer outro testado. A GPU de laptop no mesmo estudo entregou 131,7 tokens por segundo a 34,1 watts.

Então compare os dois em energia ao invés de velocidade: 270,5 mJ por token no pequeno NPU contra 297,3 mJ na GPU. Apesar de uma diferença de dezenove vezes no throughput, a pequena peça fez um pouco mais de computação por joule — e o fez com essencialmente nenhuma variação.

Se você seleciona hardware por tokens por segundo, compra o mais rápido. Se você seleciona pela capacidade de completar um loop limitado a um custo previsível, que é o que um agente realmente precisa, a classificação muda. A unidade que deve aparecer na ficha técnica é joules por tarefa concluída, com um valor de variância ao lado. Um benchmark que relata throughput de pico está falando sobre a primeira inferência do dia.

A Objeção Honesta, e o Que Ela Não Resolve

A resposta óbvia é que isso é um problema transitório: o silício melhora, os NPUs amadurecem, e qualquer coisa escrita sobre um telefone de 2026 parecerá antiquada. Ou, mais pragmaticamente, descarregar as etapas caras para um servidor.

Eu mesmo faria a aposta no hardware. Mas o offloading é a viagem de ida‑e‑volta que você moveu para a borda para evitar, e um agente não paga isso uma vez — paga a cada passo do loop, e o comprimento do loop é a coisa que você não pode prever. Designs híbridos não removem a variância; eles a realocam para a rede.

A assimetria mais profunda não se move com os nós de processo. O orçamento de um dispositivo é fixo no momento do design. A demanda de um agente é decidida em tempo de execução, por aquilo que o usuário solicitou. Silício melhor eleva o teto. Não informa ao agente onde está o teto.

Portanto, informe‑o. Defina o limite de turnos na especificação do produto ao invés de descobri‑lo em uma revisão de código, e escolha o número a partir da margem térmica: decida quantos passos cabem, então projete o agente para produzir sua melhor resposta disponível naquele limite, ao invés de sua resposta ideal em um ponto arbitrário. Trate‑o como um prazo, não como um alvo.

Depois, forneça ao agente o orçamento como entrada. Folga restante, estado da bateria, se a plataforma já começou a fazer throttling — isso pertence ao contexto, da mesma forma que o horário atual. Um agente que sabe que está no passo oito de dez pode resumir e confirmar. Um agente que não sabe continuará explorando até que o sistema operacional decida por ele.

E teste a cauda, não a mediana, o que em um dispositivo físico significa testar em simulação. O caso de falha nunca é a execução limpa. É a execução que levou catorze passos porque uma ferramenta retornou algo ambíguo no passo três, e você não pode enumerar esses casos manualmente em um telefone que precisa esfriar entre as tentativas. Meus próprios sistemas treinam contra simulações em grande parte por esse motivo: o comportamento interessante está nas execuções longas, e execuções longas são exatamente o que o hardware não permitirá que você amostre manualmente.

Nada disso requer um chip mais rápido. Requer admitir que a carga de trabalho mudou de forma. Ninguém lança um dispositivo cuja bateria seja dimensionada para uma única fotografia. Ainda estamos lançando dispositivos cujo orçamento térmico é dimensionado para uma única inferência.