Roteamento confiável de API LLM: tempos limite, novas tentativas e substitutos de modelo sem regressões semânticas
Uma arquitetura prática para classificar falhas de API LLM, impor um orçamento de latência, selecionar modelos de fallback compatíveis, proteger efeitos colaterais e validar cada resposta aceita.
Uma solicitação de fallback não é bem-sucedida apenas porque outro modelo retornou HTTP 200. A substituição pode exceder o orçamento de latência original, omitir campos JSON obrigatórios, chamar uma ferramenta diferente ou produzir uma resposta com semântica materialmente diferente. O roteamento confiável da API LLM, portanto, requer mais do que uma lista ordenada de modelos: requer um contrato, um classificador de falhas, uma política de tentativa limitada e validação antes da aceitação.
A regra central é simples: tente novamente somente quando a falha for plausivelmente temporária e recue apenas quando a próxima rota ainda puder satisfazer o contrato de solicitação original.
Defina o contrato de roteamento antes de escolher os modelos
Comece descrevendo o que uma resposta bem-sucedida deve fornecer. Esse contrato de roteamento deve ser legível por máquina e anexado a cada carga de trabalho ou classe de solicitação.
O contrato deve cobrir modalidades necessárias, capacidade de contexto, suporte de ferramentas, comportamento de saída estruturado, classes de modelo aceitáveis, custo máximo e prazo final. Adicione restrições específicas do aplicativo quando necessário, como regiões permitidas, comprimento mínimo de saída ou um motivo de conclusão obrigatório.
Recomendação: mantenha grupos de rotas testados e separados para texto simples, saída restrita por esquema, uso de ferramentas, visão e solicitações de contexto longo. Um modelo que é um substituto de texto aceitável não é automaticamente um substituto aceitável para chamada de ferramenta ou entrada de imagem.
Classifique a falha antes de agir
Erros de autenticação, solicitações malformadas, limites de taxa e falhas de servidor exigem respostas diferentes. Tratar cada resposta sem sucesso como uma nova tentativa desperdiça capacidade e pode ocultar defeitos.
Fato: solicitações malsucedidas com taxa limitada ainda podem ser contabilizadas nos limites do provedor. Novas tentativas imediatas agressivas podem, portanto, aprofundar a limitação em vez de resolvê-la. As novas tentativas também consomem capacidade adicional durante uma interrupção, e as políticas de repetição em diversas camadas do aplicativo podem multiplicar a carga resultante.
Recomendação: deixe que uma camada possua novas tentativas de geração de modelo. Em uma arquitetura típica, o gateway da API de IA é o proprietário certo porque vê a integridade da rota, o histórico de tentativas, a latência e o custo. Desative as novas tentativas automáticas em clientes de nível inferior sempre que possível ou conte-as explicitamente no mesmo orçamento de tentativas.
Gaste um orçamento de latência de ponta a ponta
Os tempos limite por tentativa são insuficientes. Três tentativas com um tempo limite de cinco segundos podem transformar uma operação pretendida de cinco segundos em uma resposta de quinze segundos, antes que a espera e a validação sejam incluídas.
Registre um prazo absoluto quando a solicitação entrar no gateway. Antes de cada tentativa, calcule o tempo restante:
restante = prazo - horário_atual
obrigatório = permissão_conectada + permissão_geração + permissão_validação
se restante < obrigatório:
stop_without_launching_another_attemptPara um prazo de oito segundos, uma alocação inicial razoável pode reservar 300 ms para trabalho de gateway e validação final, permitir até 4,5 segundos para a rota primária e reter aproximadamente 3,2 segundos para um substituto. Esses valores são um exemplo, não uma referência. Eles devem ser derivados de distribuições de latência medidas para os provedores, modelos, regiões e tamanhos de saída reais.
Use espera exponencial limitada com jitter para novas tentativas transitórias:
atraso = aleatório(0, min(cap, base * 2^retry_index))As dicas de nova tentativa do provedor, como um valor de nova tentativa, devem ter precedência quando se enquadram no prazo restante. Pare após um pequeno número de tentativas. Uma política comum é uma tentativa primária mais um substituto, com uma nova tentativa opcional na mesma rota apenas para uma falha de conexão antecipada que não poderia ter gerado uma saída faturável.
Compensação: o fallback sequencial melhora a disponibilidade, mas aumenta a latência final. Solicitações paralelas ou protegidas podem reduzir a latência durante lentidão, mas consomem mais capacidade e podem incorrer em cobranças por várias gerações bem-sucedidas. O hedge deve ser restrito a cargas de trabalho com latência crítica e sem efeitos colaterais, com cancelamento e controles de custos.
Selecione substitutos por capacidade, não por classificação
Uma tabela substituta deve codificar a compatibilidade em vez de uma ordem de preferência global. Filtre as rotas candidatas em relação ao contrato antes de considerar a integridade, a latência ou o preço.
candidatos = rotas
.filter(supports_required_modalities)
.filter(limite_de_contexto >= tamanho_de_entrada estimado)
.filter(supports_required_tools)
.filter(supports_requested_schema_mode)
.filter(model_class em permitido_model_classes)
.filter(custo_estimado <= custo_restante_orçamento)
.filter(não_temporariamente_suprimido)
selecionado = classificação(candidatos, saúde, latência, custo)O suporte à saída estruturada merece testes explícitos. Mesmo quando duas rotas anunciam geração restrita por esquema, elas podem suportar diferentes subconjuntos de esquema JSON ou interpretar casos extremos de maneira diferente. Os modelos compatíveis com ferramentas também podem diferir na seleção de ferramentas, na construção de argumentos e no comportamento de chamada paralela.
Fato: a troca de famílias de modelos pode preservar a disponibilidade de transporte enquanto altera o estilo, a qualidade do raciocínio, o comportamento de segurança, a tokenização e a seleção de ferramentas. O sucesso do HTTP não é evidência de equivalência semântica.
Previsão: à medida que os catálogos de modelos se expandem, as políticas de roteamento de produção usarão cada vez mais perfis de recursos versionados e testes de aceitação específicos de carga de trabalho em vez de listas de modelos estáticos. Trate isso como uma orientação de design, não como uma garantia sobre o comportamento do fornecedor.
Valide a resposta antes de aceitá-la
Execute todas as respostas, incluindo a resposta primária, por meio do mesmo pipeline de aceitação. A validação deve ocorrer antes que o resultado seja armazenado em cache, faturado internamente como bem-sucedido ou passado para um executor de ferramenta.
- Confirme se o transporte foi concluído e se o envelope de resposta pode ser analisado.
- Verifique o motivo do término e rejeite o truncamento quando a saída completa for necessária.
- Valide a saída estruturada em relação ao esquema original.
- Verifique os campos obrigatórios, os valores de enumeração e as invariantes do aplicativo.
- Permitir apenas nomes de ferramentas registrados e validar argumentos em cada esquema de ferramenta.
- Aplique verificações semânticas específicas da carga de trabalho onde a falsa aceitação custaria caro.
Para extração de faturas, as verificações semânticas podem exigir um total não negativo, um código de moeda compatível e totais de itens de linha dentro de uma tolerância definida explicitamente. Para classificação, exija uma etiqueta do conjunto permitido. Para geração de código, análise ou compilação podem ser apropriadas. Essas verificações não comprovam a qualidade, mas evitam que violações previsíveis de contrato sejam tratadas como sucesso.
Não repare silenciosamente todas as respostas malformadas. A normalização determinística, como a remoção de espaços em branco circundantes inofensivos, pode ser aceitável. Adivinhar campos financeiros ausentes ou reescrever argumentos de ferramentas altera o significado do modelo e deve desencadear rejeição ou revisão humana.
Tentativas de geração separadas dos efeitos colaterais
As solicitações LLM geralmente usam HTTP POST, que não é inerentemente idempotente. Mais importante ainda, uma resposta modelo pode iniciar uma ação externa, como cobrar um método de pagamento, enviar uma mensagem, criar um ticket ou modificar a infraestrutura. Tentar gerar novamente e reproduzir essa ação são decisões separadas.
Atribuir um ID de operação no limite do aplicativo e um ID de tentativa para cada chamada de modelo. Persistir o estado de execução da ferramenta em relação a uma chave determinística, como:
chave_de_execução = ID_de_operação + nome_da_ferramenta + hash_de_argumentos_canônicosAntes de executar uma ferramenta, verifique se a chave está pendente, concluída ou com falha. Retorne o resultado armazenado para uma execução concluída em vez de executá-la novamente. Para operações cujos argumentos podem ser alterados legitimamente, exija aprovação no nível do aplicativo ou um novo ID de operação.
Um tempo limite ambíguo requer tratamento especial. Se a conexão falhar após a transmissão de uma solicitação, o gateway poderá não saber se ocorreu a geração. Uma chave de idempotência suportada pelo provedor pode ajudar quando disponível. Caso contrário, registre o resultado como desconhecido e aplique uma política de reprodução específica da carga de trabalho em vez de presumir que nada aconteceu.
Suprima rotas não saudáveis e exponha todas as tentativas
Um disjuntor ou supressão temporária de integridade impede que cada nova solicitação redescubra a mesma rota com falha. Abra o circuito após uma taxa de erro definida ou limite de falha consecutiva e, em seguida, admita sondas limitadas em um estado semiaberto. Ajuste os limites por rota e classe de falha para que uma solicitação de cliente malformada não possa fazer com que um modelo íntegro pareça indisponível.
Registre um evento em nível de solicitação e um evento por tentativa. Os campos úteis incluem ID da operação, ID da tentativa, provedor e modelo selecionados, classe de falha, código de status, latência, contagens de tokens, custo estimado, motivo de fallback, resultado de validação, estado do circuito e resultado final. Edite ou faça hash de prompts, resultados e argumentos de ferramentas de acordo com seus requisitos de sensibilidade e retenção.
Métricas operacionais úteis incluem taxa de fallback, tentativas por solicitação concluída, taxa de esgotamento de prazos, taxa de rejeição de validação, resultados ambíguos, custo por resposta aceita e latência por rota final. Uma taxa crescente de sucesso de HTTP juntamente com uma taxa crescente de rejeição de validação é um aviso de que a disponibilidade de transporte está mascarando falhas contratuais.
Lista de verificação de implementação de produção
- Defina um contrato de roteamento com versão para cada classe de carga de trabalho.
- Mapeie os erros do provedor em categorias permanentes, transitórias, incompatíveis, de resposta inválida e ambíguas.
- Escolha um proprietário de nova tentativa e limite o total de tentativas.
- Propague um prazo absoluto por meio de gateway, cliente provedor, validação e execução de ferramenta.
- Crie grupos substitutos com capacidade testada em vez de uma cadeia de modelo global.
- Valide esquemas, chamadas de ferramentas, motivos de conclusão e invariantes de domínio.
- Desduplicar efeitos colaterais com chaves de operação e execução.
- Adicione supressão de rotas com sondagens semiabertas limitadas.
- Registre latência em nível de tentativa, tokens, custos, falhas e resultados de aceitação.
- Injete tempos limite, 429s, erros 5xx selecionados, JSON malformado, estouro de contexto e sucessos lentos na preparação.
Comece com uma rota primária e um substituto compatível para uma única carga de trabalho de baixo risco. Compare a qualidade, a latência e o custo da resposta aceita antes de expandir a política. O objetivo não é a taxa de recuperação mais elevada possível. É um sistema limitado que retorna uma resposta que satisfaz o contrato original ou falha claramente antes de causar trabalho duplicado ou dano semântico.