Como construir um modelo de roteamento LLM com reconhecimento de custos sem sacrificar a qualidade

O roteamento do modelo LLM com foco nos custos não deve significar o envio de todas as solicitações para o modelo mais barato disponível. Isso cria um modo de falha silencioso: as faturas melhoram por algumas semanas, depois as equipes de produto descobrem esquemas quebrados, raciocínio mais fraco, tom inconsistente ou rascunhos de suporte que exigem uma limpeza mais humana.

O melhor padrão é uma política de roteamento apoiada por avaliação. Classifique a solicitação, defina a qualidade mínima aceitável para essa tarefa, remova as rotas que não podem satisfazer as restrições de capacidade ou governança, estime a economia da rota e, em seguida, escolha o modelo elegível de menor custo. A decisão de roteamento torna-se explicável durante uma revisão de custos porque está vinculada a uma versão da política, e não à preferência do desenvolvedor ou a um vago padrão do provedor.

O que o roteamento com reconhecimento de custos está otimizando

Um roteador prático otimiza a rota mais barata que ainda atende aos requisitos operacionais da tarefa. Isso é diferente de otimizar para o modelo mais barato.

Fatos: os principais provedores de modelos publicam preços de tokens com dimensões separadas, como tokens de entrada, tokens de entrada armazenados em cache, tokens de saída, cache de prompt e processamento em lote. Alguns provedores também expõem campos de uso que relatam o comportamento do token armazenado em cache. Isso significa que a opção de menor custo pode mudar com base no formato do prompt, no comprimento de saída esperado, na elegibilidade do cache e se a carga de trabalho pode ser executada de forma assíncrona.

Recomendação: trate o roteamento como um problema de política dentro de um gatewayAPI de IA multimodelo, não como uma instrução de switch no nível do aplicativo. O gateway vê registros de capacidade do provedor, regras de locatário, API metadados principais, tabelas de preços, telemetria de uso e comportamento de fallback em um só lugar.

Previsão: as equipes que mantêm a lógica de roteamento espalhada pelos repositórios de aplicativos terão dificuldade para explicar as alterações de custos posteriormente. Eles ainda poderão reduzir os gastos, mas terão evidências mais fracas sobre por que uma determinada solicitação usou um determinado modelo.

Comece com classes de tarefas, não com nomes de provedores

O roteador precisa de um rótulo de carga de trabalho antes de poder tomar uma decisão útil. Um único modelo padrão não pode representar o perfil de risco de cada solicitação.

As classes de tarefas úteis incluem:

• Extração: converte texto não estruturado em campos, geralmente com validação de esquema estrita.
• Classificação: atribua rótulos, prioridade, intenção, sentimento ou categorias de roteamento.
• Resumo: comprime entradas longas enquanto preserva fatos e decisões importantes.
• Esboço de suporte ao cliente: gera uma resposta que um ser humano pode revisar ou enviar.
• Síntese de resposta RAG: resposta do contexto recuperado com citação ou requisitos de fundamentação.
• Revisão de código: inspecione diferenças ou arquivos de origem em busca de correção, risco ou problemas de estilo.
• Análise de contexto longo: raciocina sobre contratos, transcrições, registros, políticas ou pacotes de pesquisa.
• Suporte a decisões de alto impacto: qualquer fluxo de trabalho em que uma resposta incorreta possa afetar dinheiro, conformidade, segurança ou confiança do cliente.

A classe de tarefa pode vir de metadados de solicitação explícitos, um API escopo de chave, uma rota de aplicativo ou um classificador leve. Os metadados explícitos geralmente são melhores do que inferir a intenção do texto do prompt, porque os prompts vagos forçam o roteador a adotar padrões conservadores.

Anexar um piso de qualidade a cada tarefa

O roteamento baseado em custos só funciona se cada tarefa tiver um limite mínimo de qualidade. Sem ele, o roteador não tem como rejeitar um modelo mais barato.

Um piso de qualidade pode incluir diversas verificações:

• Conjunto de avaliação reproduzível: exemplos representativos de desenvolvimento e produção, sem dados confidenciais quando necessário.
• Validade do esquema: a saída deve ser analisada, validada em relação ao esquema canônico e evitar campos não suportados.
• Critérios de conteúdo: a resposta deve seguir as regras de estilo, recusa, fundamentação e integridade da tarefa.
• Critérios de segurança: a saída não deve vazar instruções ocultas, ignorar limites de políticas ou executar instruções não confiáveis a partir do conteúdo recuperado.
• Revisão humana: necessária para fluxos de trabalho de alto impacto ou para promoção de uma nova rota.
• Limite de regressão: a rota candidata deve atender ou exceder a rota atual em categorias de falhas críticas, não apenas na pontuação média.

Fato: a documentação do provedor descreve avaliações como uma forma de testar as saídas do modelo em relação a critérios de conteúdo e estilo especificados. Um produto de avaliação hospedado está programado para ser descontinuado, portanto, os sistemas de roteamento devem armazenar conjuntos de dados de avaliação neutros para o provedor, resultados esperados, rubricas de classificação e resultados, em vez de depender de uma superfície de avaliação hospedada pelo provedor.

Recomendação: armazene resultados de avaliação por classe de tarefa, modelo, versão do adaptador do provedor, versão do prompt, versão do esquema e versão de avaliação. Uma rota não deve tornar-se elegível simplesmente porque um modelo é novo ou mais barato. Ele se torna elegível quando passa pelo portão de qualidade atual da tarefa.

Crie um registro de capacidade do provedor

Antes de estimar o custo, remova qualquer rota que não possa satisfazer a solicitação. Esta etapa evita que o roteador selecione um modelo barato que não possua os recursos necessários.

Um registro de capacidade deve incluir:

• Modalidades de entrada e saída suportadas.
• Limites da janela de contexto.
• Saída estruturada e suporte para chamada de ferramentas.
• Suporte para streaming.
• Suporte para cache imediato e disponibilidade de telemetria de cache.
• Suporte ao lote API.
• Opções de processamento regional.
• Termos de retenção de dados e monitoramento de abuso que são importantes para sua política.
• Dimensões de limite de taxa e capacidade atual.
• Diferenças conhecidas de contrato de saída na camada do adaptador.

Este registro deve ser mantido separadamente dos prompts do aplicativo. Ele pertence próximo à camada de roteamento e adaptador de provedor, onde o sistema pode comparar modelos sem vazar suposições específicas do provedor para cada aplicativo.

Estimar o custo da rota antes da seleção

O roteador não pode saber o custo final antes da execução, mas pode estimar bem o suficiente para escolher entre rotas qualificadas. A estimativa deve incluir as variáveis que realmente movimentam a fatura.

estimated_cost =
  input_tokens * input_token_price
  + cached_input_tokens * cached_input_token_price
  + output_tokens_expected * output_token_price
  + tool_call_overhead_expected
  + retry_allowance_expected
  - batch_discount_if_eligible

Use telemetria recente para estimar tokens de saída por classe de tarefa. Por exemplo, as tarefas de extração podem ter comprimento de saída limitado, enquanto a análise de contexto longo pode variar amplamente. Os agentes que usam ferramentas podem ter custos adicionais ocultos no planejamento de chamadas de ferramentas, novas tentativas e mensagens intermediárias.

A estimativa de custo também deve levar em conta a elegibilidade do cache e do lote:

• Elegibilidade do cache: prefixo de prompt estável, instruções de sistema reutilizáveis, contexto recuperado repetido, comportamento do provedor compatível e probabilidade de acerto de cache suficiente.
• Elegibilidade do lote: a carga de trabalho pode esperar, tem tratamento de solicitação idempotente, tem rastreamento de tarefas durável e não precisa de streaming interativo.
• Risco do token de saída: o modelo tende a produzir respostas mais longas ou mais curtas para a mesma tarefa, e o truncamento prejudicaria a qualidade.
• Risco de nova tentativa: o provedor ou modelo apresenta taxas de erros, taxas de reparo de esquema ou falhas de latência elevadas para esta tarefa.

É aqui que o roteamento de custos se conecta ao gerenciamento de custos LLM mais amplo. A tabela de preços por si só não é suficiente. O roteador precisa de metadados de solicitação, estrutura de prompt, medições de ocorrências de cache e dados de uso estabelecidos para saber se as economias esperadas realmente aconteceram.

Use níveis de modelo em vez de um padrão global

Uma política em níveis é mais fácil de explicar do que uma grande lista de exceções específicas do provedor. Cada camada deve conter um ou mais modelos qualificados que passaram por portas específicas de tarefa.

Não deixe o nível substituir as avaliações. Um modelo pode ser econômico para classificação, mas inadequado para elaboração de apoio. Outro modelo pode ser forte para resumo, mas muito caro para marcação determinística curta.

Rota com uma sequência de decisão explícita

Um roteador com reconhecimento de custos deve ser determinístico o suficiente para ser depurado. A implementação exata varia, mas a sequência de decisão deve ser estável.

1. Leia os metadados do locatário, API da chave, do ambiente e do aplicativo.
2. Identifique a classe de tarefa a partir de metadados explícitos ou saída do classificador.
3. Carregue a versão da política de roteamento para esse locatário ou espaço de trabalho.
4. Aplique restrições de governança, como retenção de dados, região, lista de permissões de modelo e restrições de recursos.
5. Filtre por recursos necessários: duração do contexto, ferramentas, saída estruturada, streaming, modalidade e suporte em lote.
6. Filtre por nível de qualidade apoiado pela avaliação para a classe de tarefa.
7. Estime o custo usando tokens de entrada, tokens de saída esperados, qualificação de cache, qualificação de lote e risco de novas tentativas.
8. Aplique a política de orçamento e as preferências do locatário.
9. Selecione a rota qualificada de menor custo.
10. Anexar política de rota substituta, tempo limite, nova tentativa e reparo.
11. Registre a decisão com um código de motivo estável.

Em pseudocódigo, o roteador deve se parecer mais com uma avaliação de política do que com uma preferência de provedor codificada:

function selectRoute(request):
  context = buildRoutingContext(request)
  task = classifyTask(context)
  policy = loadPolicy(context.tenant_id, task)

  candidates = modelRegistry.models
    .filter(model => policy.allows(model))
    .filter(model => model.supports(context.required_capabilities))
    .filter(model => evalStore.passes(task, model, policy.quality_floor))

  priced = candidates.map(model => ({
    model,
    estimated_cost: estimateCost(model, context),
    expected_latency: estimateLatency(model, context),
    risk_flags: estimateRisk(model, context)
  }))

  eligible = priced.filter(route => route.risk_flags.noneBlocking())
  return minBy(eligible, route => route.estimated_cost)

Registre todas as decisões de roteamento

Se o setor financeiro perguntar por que um modelo premium foi usado ou a engenharia perguntar por que a qualidade caiu, o roteador deverá responder a partir dos registros. Não confie na reconstrução da intenção a partir de prompts após o fato.

Registre estes campos para cada solicitação:

• ID da solicitação, ID do locatário, API ID da chave, ID do aplicativo e ambiente.
• Resultado e confiança do classificador de tarefas.
• Versão da política de roteamento.
• Versão do conjunto de dados de avaliação e portão de qualidade usados.
• Modelos qualificados e modelos rejeitados.
• Motivo pelo qual cada modelo rejeitado foi excluído.
• Entrada estimada, entrada em cache e tokens de saída.
• Custo estimado da rota e custo final liquidado, quando disponível.
• Provedor, modelo, versão do adaptador e nível selecionados.
• Política de rota substituta e nova tentativa.
• Armazena em cache a telemetria de acertos ou erros quando disponível.
• Modo de execução em lote versus modo de execução síncrona.
• Validação de esquema, tentativas de reparo, status de recusa e sinalizadores de segurança.

Esses registros também suportam LLM API atribuição de custos, porque a seleção do modelo é apenas uma parte dos gastos. As equipes ainda precisam alocar custos por inquilino, espaço de trabalho, chave, produto, fluxo de trabalho ou cliente.

Adicione controles de desvio antes de promover rotas mais baratas

Mudanças no comportamento do modelo, nos preços, nas solicitações e no mix de cargas de trabalho. Uma rota que era segura no mês passado pode ficar fraca após uma revisão imediata ou atualização de modelo.

Um loop básico de controle de desvio deve incluir:

• Exemplos de solicitações de produção recentes por classe de tarefa.
• Remova ou transforme dados confidenciais de acordo com a política.
• Reproduza amostras por meio de rotas atuais e candidatas.
• Compare qualidade, validade do esquema, comportamento de recusa, custo e latência.
• Analise as falhas por categoria, não apenas pela pontuação agregada.
• Promova a rota mais barata somente se ela atender ao piso de qualidade e às restrições operacionais.
• Canary a nova rota para uma pequena porcentagem de tráfego.
• Reverter automaticamente em caso de falha de esquema, excesso de custos, violação de latência ou escalonamento de revisão humana.

Recomendação: faça da promoção de rotas um evento de gerenciamento de mudanças. Registre quem o aprovou, qual conjunto de avaliação foi aprovado, qual porcentagem de tráfego ele afeta, quando expira ou precisa de revisão e como funciona a reversão.

Ofereça substituições às equipes, mas faça com que elas expirem

Existem motivos legítimos para substituir o roteamento: incidente do fornecedor, emergência orçamentária, revisão de conformidade, escalonamento do cliente ou regressão de modelo. O problema não é a substituição. O problema é uma substituição que se torna uma política permanente invisível.

Cada substituição deve incluir:

• Escopo: locatário, aplicativo, API chave, classe de tarefa, modelo, provedor ou região.
• Motivo: incidente, orçamento, qualidade, conformidade, latência ou solicitação do cliente.
• Aprovador.
• Hora de início e hora de expiração.
• Impacto esperado no custo, na latência e na qualidade.
• Condição de reversão.

As substituições expiradas devem falhar no fechamento da política de roteamento normal ou exigir renovação. Isso evita que decisões emergenciais se tornem riscos ocultos de custo ou qualidade.

Compensações a serem explicitadas

O roteamento com reconhecimento de custos tem custos operacionais reais. Ainda vale a pena fazer isso quando os gastos com LLM são significativos, mas as compensações devem ser visíveis.

• Dependência de metadados: a qualidade do roteamento depende de rótulos de tarefas e metadados de carga de trabalho precisos. Rótulos ausentes direcionam o tráfego para padrões conservadores.
• Manutenção de avaliação: as avaliações de tarefas precisam de atualizações à medida que os prompts, os produtos e o comportamento do usuário mudam.
• Complexidade do provedor: descontos em cache e em lote podem melhorar a economia, mas tornam a lógica de roteamento mais complexa.
• Risco de portabilidade: recursos específicos do provedor devem residir em adaptadores e registros de capacidade, não no código do produto.
• Incerteza da estimativa: comprimento final da saída, chamadas de ferramentas, novas tentativas e ocorrências de cache não são totalmente conhecidos antes da execução.
• Carga de explicabilidade: a otimização agressiva pode dificultar a explicação do comportamento do produto, a menos que cada decisão seja registrada com a versão da política e os códigos de motivo.

Lista de verificação de implementação

• Defina classes de tarefas para os principais fluxos de trabalho do LLM por gastos e impacto nos negócios.
• Crie conjuntos de avaliações e limites de qualidade para cada classe de tarefa.
• Crie um registro de capacidade de provedor e modelo.
• Armazene tabelas de preços atuais e modificadores de preços por provedor, modelo e modo de execução.
• Estimar tokens de entrada, tokens de saída esperados, elegibilidade de cache, elegibilidade de lote e risco de novas tentativas.
• Filtre os candidatos por restrições de governança antes da otimização de custos.
• Selecione o modelo de menor custo somente após a passagem dos portões de capacidade e qualidade.
• Registre rotas selecionadas e rejeitadas com códigos de motivo.
• Compare o custo estimado com o uso liquidado e os dados da fatura.
• Execute avaliações periódicas antes de promover rotas mais baratas.
• Alterações de rota canário e definição de gatilhos de reversão.
• Exige datas de expiração para substituições manuais.

Conclusão

O objetivo prático não é encaminhar todas as solicitações para um modelo mais barato. O objetivo é parar de pagar caro pelo trabalho rotineiro e, ao mesmo tempo, proteger a qualidade, os contratos, as regras de governança e a explicabilidade.

Construa o roteador com base em classes de tarefas, níveis de qualidade, recursos do provedor, estimativas de custos e registros de políticas. Em seguida, escolha a rota elegível de menor custo. Essa palavra, elegível, é o que separa o roteamento com foco no custo do roteamento do modelo mais barato.

Leitura relacionada

• limites de gastos no nível do gateway