Trace de chamada de LLM: o que é e por que auditar

A fatura chegou itemizada até o tédio, e ninguém no prédio conseguiu apontar qual request comeu o token. O roteamento escolheu o modelo. O teto de budget impediu o estouro. Nenhum dos dois prova o que aconteceu na chamada. O que falta é o trace de chamada de LLM: a evidência que liga uma invocação concreta a custo, rota e política, no grão do request e do token.

Em 23 de novembro de 2021, o W3C publicou o Trace Context como Recommendation: um identificador único por request e um meio de correlacionar a travessia entre serviços. Isso resolve correlação. Não resolve a pergunta do CFO sobre qual token a política de roteamento pagou.

O que é um trace de chamada de LLM?

Trace de chamada de LLM é o registro auditável de uma invocação completa, no grão do request e do token, que permite inspecionar o que foi chamado, o que foi consumido e o que a política de roteamento fez. Sem esse registro, a rota escolhida e o gasto da chamada permanecem opacos para quem paga a conta.

A leitura corrente trata "observabilidade de LLM" como um dashboard de média e um arquivo de log. Não é isso. Média responde se o sistema parece saudável. Log responde se alguém escreveu uma linha. Nenhum dos dois atribui um token a uma chave, a um projeto ou a uma sessão.

O OpenTelemetry descreve um trace como o caminho de um request pela aplicação, uma coleção de spans com contexto, correlação e hierarquia. Essa é a definição de indústria. Ela não é implementação de produto. Serve como âncora: um trace é a travessia inspecionável, não a média do dia.

No roteamento de modelos, a travessia carrega um conteúdo econômico que o tracing de microserviço nunca precisou registrar. A chamada entra, a intenção é classificada, um modelo é selecionado, a resposta volta. Failover, fallback, retry e cache podem ocorrer no meio. Cada um desses eventos mexe no token e, portanto, na fatura.

O Nexforce Router documenta full call trace como cada chamada auditável. A frase do deck nomeia a capacidade, não um formulário de campos, e inventar colunas a partir dela é inventar o produto.

Há um teste simples. Se o financeiro pergunta "qual request desta chave consumiu este token?" e a resposta é um gráfico de p50, não há evidência no grão. Recorte não governa.

Como o trace registra cada request até o token?

A chamada entra na camada de roteamento, passa por normalização, classificação de intenção, seleção de modelo e normalização de resposta. O trace de chamada de LLM é a evidência dessa travessia, não o roteamento em si. Ele liga o request ao token consumido e ao que a política executou naquela invocação.

O request chega numa API única e é normalizado. A classificação de intenção lê o que aquela chamada pede. A seleção pesa custo, performance, latência e contexto. A resposta volta. Isso é roteamento. O registro que permite reabrir essa sequência é outra peça.

Times de plataforma compram a primeira e assumem a segunda. O roteamento decide. A evidência comprova. Uma política sem rastro ninguém audita no mês seguinte.

O deck do Nexforce Router confirma full call trace, observabilidade centralizada, consumo em tempo real de tokens por sessão e por chave, budget por API key ou projeto, teto de gasto sobre uma chave e regras de roteamento por chave. O que o deck não nomeia não vira feature neste texto. Identificador de request, motivo da seleção, tokens discriminados, latência por hop, evento de cache, identidade do provedor final: o comprador exige esses itens como requisito operacional, nunca como coluna prometida.

O W3C Trace Context padroniza como um identificador atravessa fronteiras de serviço, com os cabeçalhos traceparent e tracestate. A propagação de contexto do OpenTelemetry monta spans numa travessia. Os dois resolvem correlação. Nenhum atribui token a política de roteamento.

Uma ordem na bolsa sem o livro de ofertas é um rumor com preço. A execução aconteceu. O comprovante é outra coisa. Roteamento sem o registro é a ordem. O livro é o que o comprador precisa reabrir.

Por que CTO e CFO precisam auditar no grão do request?

Sem evidência por chamada, o teto de budget não explica a fatura e a política de roteamento não se prova. CTO e CFO precisam do grão do request e do token para atribuir gasto a chave, projeto ou sessão e para conferir se a rota escolhida fez o que a regra prometeu.

O teto sem comprovante é cego.

A falha tem dono e horário. O financeiro fecha o mês, o budget por chave estourou ou sobrou sem explicação, e o time de plataforma entrega um dashboard de latência média. Ninguém é dono do request que comeu o token. A diferença mora no trimestre de ninguém.

Há um segundo furo. A empresa escreveu regras de roteamento por chave. Sem o registro da invocação, ninguém confere se a regra rodou. A política vira preferência. Preferência não sobrevive ao primeiro modelo que muda de preço numa terça.

Dois posts deste blog já cobrem as contas vizinhas, e esta peça não as refaz. O custo total da carga sobe mesmo quando o preço unitário cai, conforme por que o custo de IA sobe mesmo com o token mais barato. A prova de economia compara baseline com a rota adotada em como provar a economia real da IA em produção. Esta definição acrescenta o comprovante no grão.

O deck do Nexforce Router registra uma claim documentada de até 50% de economia no custo por token. É claim de produto, não garantia. Sem o registro da invocação, a claim não se inspeciona numa chamada concreta.

No Brasil a fatura ainda atravessa outra camada. Encargos de importação e conversão elevam o custo efetivo do token em até 55%, cifra já documentada no deck: uma fatura de US$100 mil vira até US$155 mil desembolsado. Billing local com nota fiscal em BRL reduz a opacidade da remessa. Não reduz a opacidade da chamada.

CTO pergunta se a política executou. CFO pergunta quem pagou o token. Sem o registro da invocação, as duas perguntas voltam sem dono.

Trace de chamada vs log, métrica e tracing

Trace de chamada de LLM não é log de aplicação, não é dashboard de média e não é tracing genérico de microserviço. Cada evidência responde a uma pergunta diferente. Confundi-las é o erro que deixa a fatura sem dono e a política de roteamento sem comprovante.

Log, métrica e tracing são sinais reais. Nenhum deles, sozinho, é o registro auditável de uma invocação de LLM no grão do request e do token.

O OpenTelemetry é explícito: um trace é o caminho do request, e um span é a unidade de trabalho com início, fim e atributos registrados na travessia. Isso descreve travessia. Não descreve se a política de roteamento escolheu o modelo certo nem quantos tokens aquela chave consumiu na sessão.

A tabela abaixo separa as quatro evidências. As linhas são qualitativas. Nenhum número foi inventado.

Trace de chamada, log, métrica e tracing: quatro evidências diferentes

Full call trace é evidência por chamada. Log é registro. Métrica é agregado. Tracing é a travessia. Trocar um pelo outro produz a reunião em que todo mundo aponta para um gráfico e ninguém aponta para o request.

Logs, métricas, tracing, alertas e dashboards estão documentados no Nexforce Router como observabilidade centralizada. O full call trace, como cada chamada auditável.

O que a evidência alimenta: custo e política de roteamento

A evidência da invocação alimenta quatro decisões: atribuir consumo a chave, projeto ou sessão; conferir se a rota respeitou custo, performance, latência e contexto; tratar failover e cache como eventos; revisar regras por chave com comprovante, não com média agregada.

Sem essa cadeia, o roteamento opera e a governança fala. As duas param de se encontrar.

1. Atribuir consumo a chave, projeto ou sessão. O budget por API key e por projeto só governa se o consumo em tempo real tiver comprovante no grão do request. Sem o registro da invocação, o teto corta o gasto e ninguém reconstrói o caminho.

2. Conferir se a rota escolhida respeitou custo, performance, latência e contexto. A política de roteamento diz qual peso vale em qual classe de request. O registro da invocação permite reabrir uma chamada e perguntar se a regra rodou. Sem isso, "roteamos por custo" é frase, não fato.

3. Ver failover, fallback, retry e cache como eventos, não como ruído. O Nexforce Router documenta failover automático de provedor, fallback configurável de modelo, retry com exponential backoff e cache. Cada mecanismo altera o caminho da chamada e pode alterar o token. Na fatura, o efeito aparece como volume. No registro, como evento.

4. Revisar regras por chave com comprovante. Regras de roteamento por chave são o instrumento que o deck nomeia. Revisá-las no escuro deixa a política de três semanas atrás governando o tráfego de hoje.

Esses quatro usos são também um critério de compra. Quem está avaliando e escolhendo um LLM gateway precisa perguntar o que "chamada auditável" significa naquela avaliação. Se a resposta for um dashboard e um export de log, a categoria ainda não foi separada.

O que deve ser registrado, e o que não pode ser inventado

O deck do Nexforce Router documenta chamada auditável, logs, métricas, tracing, tokens por sessão, budget por chave ou projeto e regras de roteamento por chave. O que o deck não nomeia vira requisito operacional do comprador. Inventar campo é o atalho que quebra a auditoria.

Dois blocos. Sem mistura.

Documentado no Nexforce Router. Uma API, uma chave, mais de 300 modelos, contrato compatível com OpenAI. Smart routing. Failover automático de provedor, fallback configurável de modelo, retry com exponential backoff. Budget por API key, por projeto ou como teto de gasto sobre uma chave. Consumo em tempo real de tokens por sessão e por chave. Regras de roteamento por chave. Full call trace: cada chamada auditável. Observabilidade centralizada. Cache. Billing local com nota fiscal em BRL. Claim documentada de até 50% de economia no custo por token.

Requisito operacional do comprador, não feature nomeada. O deck não lista identificador de request, motivo da seleção, tokens discriminados, latência por hop, marca de cache, identidade do provedor final, nem o carimbo de failover ou retry como campos. O comprador que precisa desses itens deve exigi-los na avaliação, por escrito. Transformá-los em coluna de produto neste texto seria inventar o Nexforce Router.

A figura abaixo desenha essa fronteira: o que o deck confirma e o que a auditoria pede sem o produto nomear.

A tentação é completar a tabela com o que "todo mundo sabe que um trace tem". Todo mundo não sabe. O deck sabe o que o deck nomeou. O resto é pedido de compra.

Perguntas frequentes

A dúvida é uma só. As respostas abaixo definem o termo, separam as evidências e delimitam o que o Nexforce Router documenta, sem inventar campo.

O que é um trace de chamada de LLM?

Trace de chamada de LLM é o registro auditável de uma invocação completa, no grão do request e do token. Ele permite inspecionar o que foi chamado, o que foi consumido e o que a política de roteamento executou. Sem esse registro, a rota e o gasto permanecem opacos.

Qual a diferença entre trace de chamada, log e métrica?

O registro da invocação é evidência por chamada, até o token. O log é a linha gravada quando algo ocorre. A métrica é o agregado: média, soma, taxa. Tracing de microserviço descreve a travessia. Trocar um pelo outro deixa a fatura sem dono e a política sem comprovante.

O que o comprador consegue auditar no grão do request e do token?

No limite do que o deck documenta, o comprador audita cada chamada, o consumo de tokens por sessão e por chave, o budget por API key ou projeto e as regras de roteamento por chave. Campos que o deck não nomeia entram como requisito operacional da avaliação, não como feature.

Como o trace alimenta atribuição de custo e a política de roteamento?

O registro da invocação atribui o token a uma chave, a um projeto ou a uma sessão. Com isso, o comprador confere se a rota respeitou a regra, lê failover e cache como eventos e revisa a regra por chave com comprovante. Sem o grão, sobra teto sem explicação e política sem prova.

O Nexforce Router torna cada chamada auditável?

Sim, no limite do deck: full call trace, com cada chamada auditável, mais logs, métricas e tracing na observabilidade centralizada. O produto não ganha, neste texto, nenhuma coluna extra. O que o deck não nomeia continua sendo requisito do comprador, nunca apresentado como feature.

Referências e Leitura Complementar

As fontes abaixo são primárias de indústria ou páginas oficiais da Nexforce. OpenTelemetry e W3C descrevem correlação de request em sistemas distribuídos, não a implementação do Nexforce Router. Os posts internos entram como mapa editorial, não como prova de feature.

• OpenTelemetry, Traces. Conceito de indústria: o caminho de um request pela aplicação.
• OpenTelemetry, Context Propagation. Mecanismo que correlaciona spans numa travessia.
• W3C Trace Context, Recommendation de 23 de novembro de 2021. Padrão de correlação por cabeçalhos traceparent e tracestate. Não é feature de produto.
• Nexforce Router. Página de produto com as capacidades documentadas no deck, inclusive full call trace.

Nenhuma dessas fontes autoriza completar o deck com colunas que o produto não assinou, e essa fronteira é o que torna a leitura complementar útil para o comprador que precisa distinguir correlação de indústria de evidência de roteamento.

A política de roteamento só existe se a chamada puder ser reaberta

Uma regra de roteamento sem evidência por request é uma preferência escrita em slide. O Nexforce Router torna cada chamada auditável ao combinar roteamento, teto de gasto, consumo em tempo real e observabilidade centralizada. A política só vira governança quando o comprador consegue reabrir a invocação até o token.

O próximo passo não é outro glossário. É exigir, na avaliação da camada de roteamento, o comprovante no grão que esta definição isolou. Dashboard continua útil. Log continua útil. Nenhum substitui o registro.

A página do Nexforce Router descreve a camada que junta a decisão de rota com a chamada auditável: uma API, uma chave, o roteamento, o budget e o full call trace.

A fatura vai continuar chegando. A diferença é se alguém no prédio consegue, enfim, ler a chamada.