O LLM do seu agente: quando pagar por token e quando provisionar a GPU

Um agente de atendimento costuma começar respondendo dúvidas simples. Alguns meses depois ele já atende uma base crescente de clientes, consulta políticas internas e prepara ações que dependem de uma resposta dentro do tempo esperado. O modelo continua o mesmo, mas a fatura não.

O motivo é simples: o custo de um LLM cobrado por token acompanha o tráfego, não o valor que o agente entrega. Este artigo evidencia essa curva e mostra quantos usuários simultâneos uma capacidade provisionada realmente atende.

Um agente em produção é mais do que um modelo com um prompt. Ele consiste em um pipeline de componentes orquestrados a cada requisição:

• Memória: o que o agente lembra entre uma interação e outra. No Oracle AI Agent Memory, sobre o Oracle AI Database, esse estado vive junto do dado corporativo, em vez de ocupar mais um armazenamento paralelo para proteger.
• Camada semântica: como o agente encontra a política, o contrato ou o histórico certo. É o papel do Oracle AI Vector Search, que recupera o trecho certo pelo significado, dentro do mesmo banco que já sustenta a transação.
• Modelo de linguagem (LLM): quem interpreta a requisição em linguagem natural e redige a resposta. É o OCI Generative AI.

A diferença econômica entre esses componentes é o ponto deste artigo. Memória e camada semântica são custo de plataforma: escalam com o acervo de dados, de forma previsível. O LLM é o único componente cobrado por uso, contando cada token de entrada e cada token de saída em toda chamada. Se o tráfego dobra, essa linha da fatura dobra junto.

Uma interação do usuário não é uma chamada ao modelo

Quase toda projeção de custo feita no começo do projeto tropeça no mesmo detalhe: o usuário faz uma pergunta, e o agente faz várias chamadas ao modelo.

Um agente com ferramentas trabalha em ciclo. O modelo recebe o pedido e decide chamar uma ferramenta; a orquestração executa; o resultado volta para o contexto; o modelo lê tudo de novo e decide o passo seguinte. Só quando considera o pedido resolvido é que a resposta é apresentada. Somando as múltiplas consultas que uma ferramenta efetua quando invocada, temos ainda o reenvio de todo o contexto acumulado até aquele dado momento.

Sobre esse ciclo se somam quatro fontes de consumo que raramente entram na estimativa inicial:

• Raciocínio. Modelos de reasoning geram tokens de deliberação antes de escrever a resposta. São cobrados como saída, e o usuário nunca os vê. Uma resposta de 200 tokens pode ter custado várias vezes isso em raciocínio.
• Definição das ferramentas. Cada ferramenta disponível ocupa espaço no prompt: nome, descrição e schema de parâmetros. Quando a integração vem via MCP (Model Context Protocol), conectar um servidor traz o catálogo inteiro dele junto. Vinte ferramentas conectadas viram um piso fixo de milhares de tokens de entrada em toda chamada, inclusive nas que não usam ferramenta nenhuma.
• Retorno das ferramentas. O resultado de uma consulta entra no contexto como texto. Uma query que devolve trinta linhas custa mais tokens que a pergunta que a originou.
• Histórico e memória. Conversa multi-turno, memória recuperada e trechos trazidos pela camada semântica são reenviados a cada chamada.

O efeito é multiplicativo. O consumo cresce com usuários × chamadas por interação × tamanho do contexto de cada chamada, e não apenas com o número de pessoas atendidas. A consequência é contraintuitiva: o agente que a empresa mais quer, aquele que consulta, verifica e justifica a resposta, é justamente o mais caro por interação quando se paga por token.

Duas formas de pagar para dois cenários diferentes

No OCI Generative AI, os modos On-Demand e Dedicated atendem momentos diferentes.

On-Demand permite utilizar os modelos da forma habitual, com custo por milhão de tokens consumidos. A capacidade é compartilhada, e o serviço ajusta o limite de requisições de cada tenancy conforme a demanda do modelo — um detalhe que volta a pesar mais adiante. A pergunta financeira é: quantos tokens esperamos processar por mês?

Dedicated entrega capacidade de GPU exclusiva, com o modelo hospedado em um endpoint próprio sobre um Dedicated AI Cluster. O custo passa a ser o da capacidade e do período de uso: fixo, previsível e independente do volume. A pergunta muda de lugar: qual carga concorrente essa capacidade atende dentro da meta de latência?

Essa segunda pergunta parece mais difícil, mas é a única que tem resposta medida.

Então, quantos usuários simultâneos uma GPU suporta?

Duas GPUs H100 rodando gpt-oss-120b atendem 256 pessoas ao mesmo tempo — e cada uma continua recebendo o texto duas vezes mais rápido do que a Oracle considera tempo real para chat.

_{Fonte: benchmark público OCI para gpt-oss-120b na unidade OAI_H100_X2, cenário de chat (100 tokens de entrada, 100 de saída). A Oracle usa 15 tokens/s por usuário como patamar de tempo real para chat, e 5 tokens/s como velocidade média de leitura humana. O formato de hardware da unidade varia por região.}

São 138 mil interações por hora.

A sua carga desloca esse número: um agente que injeta 2.000 tokens de contexto a cada chamada não atende os mesmos 256. Como o benchmark é público e vem quebrado por cenário, dá para dimensionar antes de assinar.

O custo por usuário cai enquanto a fatura fica parada

Essa mesma unidade, ligada o mês inteiro, custa R$ 46.822,24 a preços públicos de referência.

_{Cálculo: 12,02 AI units × 744 h × R$ 5,2357/h (2 GPUs H100 a US$ 6,01/GPU-hora), dividido pela concorrência do benchmark. Preços públicos, sem descontos nem impostos.}

O mesmo valor atende 1 ou 256 pessoas. O que muda é o custo unitário, que cai de R$ 46.822,24 para R$ 182,90. No modo por token o movimento é o oposto, porque cada usuário novo acrescenta custo permanentemente. É essa inversão que transforma o LLM de linha de despesa variável em ativo de capacidade.

Onde fica o ponto de inflexão

A preços públicos, os dois modos se cruzam em 23,85 bilhões de tokens por mês. Para um chatbot de respostas curtas, isso são 119 milhões de interações — longe da realidade da maioria dos projetos.

Mas quem consome token é o contexto que cada chamada carrega. Um agente que recupera política e histórico a cada pergunta chega ao mesmo ponto com 11× menos interações. Um que injeta 7.800 tokens de contexto chega com 40× menos, cerca de 99 mil interações por dia.

Os componentes que tornam o agente realmente útil são os mesmos que antecipam a decisão de provisionar.

O que a capacidade dedicada entrega

Até aqui a conversa foi de dinheiro, e o dinheiro raramente é o que decide o caso em produção. A documentação da Oracle é direta ao descrever os Dedicated AI Clusters: eles “entregam performance previsível e são adequados para cargas de produção”. Essa previsibilidade é o que se está comprando, e ela vem de quatro coisas concretas.

A primeira é a exclusividade. As GPUs são suas pelo período contratado, isoladas dos experimentos da própria empresa e das demais cargas. O comportamento que você mediu na sexta-feira é o mesmo que você encontra na segunda.

A segunda é a ausência de throttling dinâmico. No On-Demand, o serviço ajusta o limite de requisições de cada tenancy conforme a demanda do modelo e a capacidade disponível. A documentação da Oracle registra que esses limites “não são documentados e podem mudar conforme a demanda do sistema”, e orienta tratar as rejeições com back-off. Isso impede dimensionar a operação contra um número firme. No Dedicated esse ajuste não existe: a vazão é a da GPU provisionada.

A terceira é o fato de a capacidade ser medida. O benchmark existe, é público e vem quebrado por cenário e por nível de concorrência, como a tabela algumas seções acima. No On-Demand o limite não é publicado; aqui ele está na mesa antes de você assinar. Isso permite dimensionar antes de provisionar, em vez de descobrir o teto quando o tráfego chega.

A quarta é a governança e a soberania do dado. A inferência acontece dentro de capacidade que é sua, sob a mesma identidade, a mesma rede e a mesma auditoria da OCI que já cobrem o resto do ambiente — com o processamento em uma região que você escolhe, o que costuma ser o ponto que destrava setor regulado e requisito de residência de dado. Para quem tem essa exigência, esse é o argumento que abre a conversa, antes de qualquer planilha.

Nenhuma das quatro aparece em planilha de custo por token, e são elas que costumam sustentar o caso. Uma meta de latência acordada com a área de negócio, um pico que não pode ser rejeitado por um limite que ninguém publica, um requisito de isolamento ou uma exigência de soberania não se resolvem com preço melhor. O custo confirma a escolha depois.

Como dimensionar sem chutar

Vale avaliar Dedicated quando:

• há tráfego recorrente e uma projeção de crescimento defensável;
• o agente precisa atender uma concorrência de pico conhecida;
• o tempo de resposta afeta atendimento, conversão ou operação;
• o serviço não pode depender de um limite de taxa que não é publicado e muda sem aviso;
• há exigência de soberania, residência de dado ou requisito setorial sobre onde a inferência acontece;
• o workload precisa de isolamento em relação a experimentos e outras cargas;
• FinOps precisa planejar a capacidade antes do lançamento.

Onde a Oracle ajuda

A transição entre os dois modos é uma decisão de negócio, e não um projeto de reescrita. No OCI Generative AI, o agente que hoje consome o modo On-Demand passa a consumir um endpoint dedicado sem trocar de API, de SDK ou de modelo: muda o endpoint, não a aplicação. Dá para começar barato, medir com tráfego real e provisionar quando a evidência aparecer.

O ganho não fica só na inferência. O mesmo Oracle AI Database que sustenta a transação sustenta também a memória do agente e a busca vetorial da camada semântica, sob a mesma identidade, a mesma rede e a mesma auditoria da OCI. São menos integrações para construir e menos cópias de dado para proteger.

Os dois modos têm lugar

O On-Demand é o caminho certo para começar: validar a ideia, ajustar prompts, atender demanda esporádica e alternar entre modelos sem provisionar nada. Boa parte dos projetos deveria nascer ali, e alguns nunca precisam sair.

O Dedicated entra quando a experiência passa a ter compromisso — quando existe uma concorrência de pico para sustentar, uma meta de latência acordada com a área de negócio, um limite de taxa que não pode ser surpresa ou uma exigência de isolamento e soberania. É aí que a capacidade reservada deixa de ser custo fixo e passa a ser previsibilidade comprada.

Na prática, a maioria das arquiteturas maduras usa os dois ao mesmo tempo: capacidade dedicada para o que está em produção e On-Demand para o que ainda está sendo descoberto, ou para modelos que só aparecem de vez em quando no fluxo. Como muda o endpoint e não a aplicação, essa combinação é uma decisão de arquitetura, não um caminho sem volta.