Um dos blocos do palco Plenária Tecnologia & Inovação tratou de um tema cada vez mais presente no dia a dia de quem constrói aplicações com LLMs: como decidir, de forma automática, quando uma chamada deve ir para um modelo local (rodando na própria infraestrutura, sem GPU dedicada) e quando ela realmente precisa de um modelo de fronteira, mais caro e mais lento.
O palestrante citou o uso do Phoenix, ferramenta que funciona como banco de dados e coletor de traces das chamadas feitas pelos agentes. Segundo a explicação no palco, o Phoenix permite algumas análises estatísticas sobre o uso de tokens e, principalmente, viabiliza um tipo de cache que não depende de LLM nem de GPU:
"Ele consegue fazer um caching, não é um caching baseado em LLM, isso aqui também não precisa de GPU. Você consegue fazer um cache estatístico para otimizar algumas chamadas que o seu agente pode estar fazendo."
Na prática, isso significa reduzir chamadas redundantes a modelos caros analisando padrões estatísticos de uso, em vez de depender de embeddings ou de outro LLM para decidir o que pode ser reaproveitado — uma técnica de baixo custo computacional que pode ser interessante para times que ainda não têm orçamento para infraestrutura de GPU.
Políticas de roteamento no nível do prompt
O segundo ponto abordado foi uma ferramenta de código aberto mantida ativamente pela NVIDIA, citada no palco como "Nemo Switchyards", voltada à divisão de responsabilidades entre agentes. A ideia central não é resolver o particionamento dos agentes dentro da aplicação, mas sim expor um endpoint que funciona como camada de decisão:
"A chamada de agente no nível do prompt. Você constrói as políticas, você faz elas do jeito que você acha melhor. Ele vira um endpoint para o seu agente chamar e as suas políticas vão guiar qual modelo vai ser ativado para determinadas funções."
A lógica descrita é relativamente simples de entender: o sistema detecta a complexidade da chamada — por exemplo, se envolve tool calling mais elaborado — e só nesse caso aciona um agente de fronteira (modelos maiores, geralmente via API paga). Perguntas mais simples continuam sendo respondidas por um modelo local, mais barato e rápido.
"Ele detecta uma chamada complexa, um tool calling, pode chamar um agente de fronteira. Perguntas mais simples, com o modelo local."
Por que isso importa para quem desenvolve
Para equipes brasileiras que estão colocando agentes de IA em produção, o recado prático é que existe um ecossistema crescente de ferramentas open source pensadas especificamente para reduzir custo de inferência sem abrir mão de capacidade — via observabilidade, cache estatístico e políticas de roteamento configuráveis. Vale acompanhar projetos como o citado no palco antes de assumir que toda chamada de agente precisa passar por um modelo de fronteira.