Decompor o custo de uma execução e pôr teto em cada parte

Com o protótipo acertando 94 das 120 perguntas de Helena, a conversa na Veredas mudou de assunto. A primeira versão custava em média US$ 0,86 por pergunta, levava 3 min 40 s na mediana e teve uma execução de 19 minutos. Helena não tinha como prometer prazo a um cliente com esse último número na planilha.

Deixar o custo solto cobra duas vezes. A consultoria estimou 400 perguntas por mês quando o sistema entrasse na rotina, o que dá US$ 344 mensais pela média (400 × 0,86). O problema maior mora na cauda: uma pergunta ambígua leva o modelo a repetir a exploração até o limite, e sem teto ninguém sabe quanto essa pergunta vai custar antes de ela terminar.

Ao fim, você consegue abrir uma execução e dizer quanto do gasto veio do modelo raiz, quanto das subchamadas e quanto do histórico que cresce a cada volta. Também sabe qual parâmetro limita cada parte no DSPy e na biblioteca rlms, o que acontece quando o limite é atingido e como registrar esse evento para não confundir resposta cortada com resposta completa.

De onde vem o gasto de uma execução recursiva

Uma execução de RLM paga três contas diferentes. A primeira é a do modelo raiz, que a cada iteração relê as instruções, os metadados do contexto e todo o histórico de código e saídas anteriores. Iteração: uma volta completa do laço, em que o modelo escreve código, o REPL executa e o resultado volta ao histórico, como uma rodada de conversa com uma calculadora. Como o histórico cresce, a décima iteração custa mais que a primeira.

Subchamadas formam a segunda conta. Cada llm_query paga a entrada que o código montou, em geral um trecho do acervo, e a saída que o submodelo escreve. Token: o pedaço de palavra que o provedor usa para medir e cobrar texto. Nos dois modelos do artigo, a saída custa oito vezes a entrada: US$ 1,25 contra US$ 10 por milhão de tokens no GPT-5 e US$ 0,25 contra US$ 2 no GPT-5-mini. O raiz caro, por escrever e reler mais, pode pesar mais que a leitura barata de muitos documentos.

Tempo é a terceira conta, e ela não aparece na fatura. No artigo de Zhang, Kraska e Khattab, todas as chamadas eram bloqueantes e sequenciais: o raiz espera cada subchamada terminar antes de seguir. Uma execução com 40 subchamadas de 6 segundos passa 4 minutos só esperando. Na reprodução de Daren Wang, com DeepSeek v3.2 no S-NIAH, a mesma pergunta levou 3,6 s sem RLM, 89,3 s com profundidade 1 e 344,5 s com profundidade 2.

Somadas, essas contas produzem uma distribuição com cauda comprida. O artigo mede o custo em quatro benchmarks e descreve as trajetórias como de cauda longa e alta variância. A execução mediana do RLM sai mais barata que a mediana do modelo base, e a média sai mais cara por causa de poucas execuções fora da curva. O desvio-padrão muitas vezes passa da própria média: com GPT-5 na profundidade 2, o OOLONG custou US$ 1,10 ± 3,25 por pergunta.

Quantas subchamadas uma execução faz depende mais do modelo raiz que do problema. Com o mesmo prompt de sistema, o GPT-5 fazia algo na ordem de dez subchamadas, e o Qwen3-Coder-480B fazia centenas ou milhares numa pergunta simples; os autores precisaram acrescentar uma linha ao prompt só para ele. No OOLONG, as trajetórias corretas do Qwen3-Coder tiveram cerca de 500 subchamadas em média. Trocar o modelo raiz sem medir de novo muda a conta inteira.

Estimar o gasto pelo tamanho do acervo leva ao erro oposto. Ler 10 milhões de tokens uma vez, só de entrada, custaria cerca de US$ 40 no Opus 5.5 e US$ 2,50 no GPT-5-mini. O RLM não lê tudo, e também não lê só uma vez: relê o histórico a cada iteração e paga saída em cada subchamada. Armadilha comum: multiplicar os tokens do acervo pelo preço de entrada e chamar isso de orçamento. A conta certa sai do rastro de execuções reais, somada por modelo, com entrada e saída separadas.

Desde o primeiro texto o autor avisou do problema. No post de outubro de 2025, Alex Zhang escreveu que cada consulta levava de alguns segundos a vários minutos e que não havia garantias fortes sobre o custo total nem sobre o tempo total. A OWASP tem nome de catálogo para esse risco em aplicações com LLM: LLM10, consumo sem limite. Em RLM, ele aparece como explosão de subchamadas, que os autores do artigo citam como efeito colateral do desenho.

Os limites que cada implementação oferece

Limite é o parâmetro que interrompe a execução antes que ela gaste mais que o combinado. As implementações oferecem tetos diferentes, com comportamentos diferentes quando o teto chega, e essa segunda parte pesa tanto quanto a primeira. Um limite que corta em silêncio devolve uma resposta com cara de completa, e quem lê o relatório não tem como saber que a exploração parou no meio.

No dspy.RLM, a partir da versão 3.3.0, de agosto de 2026, os tetos são três. max_iters, com padrão 20, conta as voltas do laço; antes dessa versão o nome era max_iterations, e código antigo ainda usa o nome velho. max_llm_calls, com padrão 50, conta as chamadas a llm_query e llm_query_batched numa execução. max_output_chars, com padrão 10.000, define quanto da saída do REPL entra no histórico, e por isso controla o crescimento da conta do raiz.

Cada um dos dois primeiros reage de um jeito. Quando max_iters chega, o DSPy faz uma extração de fallback: pede ao modelo que monte a resposta com o que já existe nas variáveis e no histórico. Quando o código tenta passar de max_llm_calls, a chamada falha dentro do sandbox com erro de limite, e o modelo vê o erro na saída da iteração. O DSPy não traz teto em dólar nem em tempo; quem precisa deles embrulha a chamada no próprio código.

Na biblioteca rlms, versão 0.1.3, o construtor do RLM traz mais tetos. max_depth (padrão 1) define até onde a recursão desce; na profundidade máxima, a subchamada vira uma chamada comum ao modelo. max_iterations (padrão 30) conta as voltas. max_budget corta por dólar e depende de um backend que informe custo, como o OpenRouter. max_timeout corta por segundos, max_tokens pela soma de entrada e saída, e max_errors por erros seguidos.

Esses quatro últimos encerram a execução com uma exceção que carrega a melhor resposta parcial disponível, quando existe. O código que chama o RLM precisa capturar a exceção e decidir o que fazer com o parcial: descartar, marcar para revisão ou entregar com aviso. Já max_concurrent_subcalls (padrão 4) limita quantas subchamadas recursivas rodam em paralelo, o que protege o limite de requisições por minuto do provedor.

Para escolher o valor de cada teto, o ponto de partida é a distribuição das execuções que já aconteceram. Percentil 95: o valor abaixo do qual ficam 95 de cada 100 execuções, a borda de cima do que é normal. Um teto abaixo da mediana corta perguntas comuns; um teto muito acima do percentil 95 não corta nada. A Prime Intellect usou 120 segundos por chamada ao REPL e 8.192 caracteres de saída por turno no ambiente de treino: limites por passo, escolhidos para o caso comum caber com folga.

Há um caminho diferente, com garantia em vez de teto. O λ-RLM, de pesquisadores do IIT Delhi e do Huawei Noah's Ark, troca o código livre por combinadores tipados e prova término e limite de custo em forma fechada. A prova vale para o runtime dele, com modelos abertos e contextos de até 128 mil tokens; a trilha sobre perspectivas para 2027 volta a esse desenho e às condições da garantia.

Como a Veredas separou os US$ 0,86 em partes

Caio partiu da conta que já tinha fechado no protótipo. O dspy.RLM rodava com os padrões da biblioteca, o GPT-5 no raiz e o GPT-5-mini como sub_lm. Na média por pergunta, o raiz fez 12 turnos, leu 180 mil tokens e escreveu 24 mil; as 30 subchamadas leram 1,2 milhão de tokens e escreveram 45 mil. O raiz lia menos de um sexto do que as subchamadas liam e, mesmo assim, custava mais.

Duas leituras saíram da tabela. O raiz respondia por 54% do gasto (0,465 de 0,855), e mais da metade disso era saída, a US$ 10 por milhão. E a entrada do raiz crescia a cada turno porque o max_output_chars padrão deixava até 10 mil caracteres de saída do REPL entrarem no histórico. Nas perguntas de agregação, o código do raiz imprimia listas inteiras de documentos, e essas listas voltavam a ser lidas em todos os turnos seguintes.

Separadas as 20 perguntas mais caras, a cauda apareceu inteira. Elas custaram em média US$ 2,10 e somaram US$ 42,00 dos US$ 102,60 da rodada, 41%, acima do terço que Caio tinha fixado como gatilho. As outras 100 custaram US$ 0,606 em média ((102,60 − 42,00) ÷ 100). Nas 20 caras, o raiz rodou 19,5 turnos em média, contra 10,5 nas comuns, e sete delas pararam no teto de 20 turnos, terminando em extração de fallback.

O histórico explicava a diferença. Nas execuções comuns, cada turno do raiz lia cerca de 10 mil tokens; nas caras, 28 mil, porque cada volta relia as listas impressas nas anteriores. Numa pergunta cara, o raiz custava US$ 1,41 (540 mil tokens lidos e 73,5 mil escritos) e as subchamadas, US$ 0,69 (2,2 milhões lidos e 70 mil escritos). O modelo caro relendo o próprio rastro pesava o dobro da leitura dos documentos.

Caio mudou três coisas. Baixou max_output_chars para 4.000, o que cortou cerca de 28 mil tokens da entrada do raiz nas execuções comuns, US$ 0,035 a menos em cada uma (0,028 × 1,25). Baixou max_iters para 14, acima do que 95 de cada 100 execuções comuns usavam, e manteve max_llm_calls em 50. E pôs um tempo-limite de 8 minutos por pergunta, com registro de qual teto parou cada execução.

No cenário da Veredas, o efeito apareceu nas duas pontas. As 100 execuções comuns caíram para US$ 0,571 em média. As 20 caras pararam em no máximo 14 turnos: o raiz delas foi de US$ 1,41 para US$ 0,775, as subchamadas ficaram em US$ 0,69, e o custo médio caiu para US$ 1,465; três bateram o tempo-limite e voltaram como pendência. A média geral foi para US$ 0,72 ((100 × 0,571 + 20 × 1,465) ÷ 120), e a pior execução passou de 19 para 8 minutos.

Houve um preço em acurácia, e ele foi pequeno: de 94 para 93 de 120. A pergunta perdida era de cruzamento, e o protótipo só a acertava no 17º turno, depois de duas explorações erradas; com 14 turnos, a extração de fallback devolveu uma resposta incompleta. Helena aceitou a troca por uma razão prática: a resposta cortada agora saía marcada, e uma pergunta marcada vai para revisão em vez de ir para o cliente.

A cauda encolheu e passou a deixar rastro. A execução comum, agora a US$ 0,571, divide o gasto entre turnos do raiz e leitura das subchamadas. Abra o rastro das 100 execuções comuns e conte quantos turnos do raiz servem só para espiar e refiltrar e quantos documentos lidos não aparecem na resposta; o critério é achar pelo menos um terço de turnos ou de leitura que um filtro feito por código evitaria.