Como construir um corretor de limite de taxa neutro para provedor para APIs LLM multimodelo

Quando várias equipes compartilham vários provedores de LLM, a limitação de taxa deixa de ser um detalhe de integração do provedor. Torna-se um problema de capacidade compartilhada. Um provedor pode limitar solicitações e tokens de entrada, outro pode separar tokens de entrada e saída e um terceiro pode aplicar cotas no nível do projeto ou em uma janela contínua de gastos. Um loop de nova tentativa dentro de cada SDK não pode coordenar essas restrições entre locatários, aplicativos, chaves de parceiro e rotas de modelo.

A solução prática é um corretor central de limite de taxa no gateway. O corretor estima a demanda, reserva capacidade antes do envio, enfileira ou rejeita trabalho de acordo com a política e reconcilia a reserva com o uso real após a conclusão. As respostas do provedor então refinam a visão do corretor sobre a capacidade disponível, em vez de desencadear tempestades de novas tentativas independentes.

Essa arquitetura é útil para qualquer LLM empresarial API que precise de rendimento previsível entre equipes internas, aplicativos de produção, agentes de automação ou parceiros externos.

Por que os limites de taxa do provedor não podem ser reduzidos para solicitações por minuto

Fato: as cotas do provedor usam dimensões e escopos diferentes. As dimensões comuns incluem solicitações por minuto, tokens de entrada por minuto, tokens de saída por minuto, total de tokens, solicitações por dia, simultaneidade, janelas de gastos e limites de aceleração ou taxa de rampa. O mesmo provedor pode expor limites diferentes para uma organização, projeto, espaço de trabalho, modelo ou API produto.

Por exemplo, a documentação do provedor descreve combinações como:

• Limites de solicitação e token com capacidade restante e informações de redefinição nos cabeçalhos de resposta.
• Limites separados de token de entrada e de saída para APIs de mensagens.
• Cotas em nível de projeto em vez de cotas anexadas a API chaves individuais.
• Limites de solicitações diárias que são redefinidos em um horário definido pelo provedor.
• Janelas contínuas baseadas em gastos que podem rejeitar tráfego mesmo quando as taxas de solicitação e token parecem aceitáveis.
• Limites de aceleração que reagem a um aumento acentuado no tráfego, mesmo quando o uso em estado estacionário está abaixo da cota publicada.

Um gateway que armazena apenas um número chamado provedor RPM acabará por admitir excesso de tráfego em uma dimensão ou subutilização da capacidade em outra. Também não é possível explicar se uma rejeição veio de uma política de locatário, de uma cota de projeto do fornecedor, de um limite diário ou de uma resposta de sobrecarga.

Arquitetura de referência para uma corretora com limite de taxa

Coloque o corretor no caminho da solicitação antes do adaptador do provedor. Cada solicitação deve passar pelo mesmo fluxo de reserva, independentemente de ter chegado por meio de uma chave SDK, de um serviço interno, de um agente de automação ou de uma chave API do parceiro.

1. Normalizar a identidade. Resolva a organização, locatário, equipe, aplicativo, ambiente, parceiro, API chave, rota do modelo e classe de carga de trabalho.
2. Estimar a demanda. Calcular os tokens de entrada esperados, os tokens de saída máximos, o gasto estimado e qualquer custo de simultaneidade.
3. Avalie a política. Verifique os orçamentos dos inquilinos, os prazos das filas, a elegibilidade da rota, a prioridade e as regras de reserva.
4. Reserve capacidade. Reserve capacidade atomicamente nos buckets internos relevantes e voltados para o provedor.
5. Dispatch. Envie a solicitação somente após a reserva ser bem-sucedida.
6. Reconciliar. Substituir estimativas pelo uso real, liberar reservas não utilizadas e registrar cabeçalhos de provedores e classificação de respostas.
7. Decida a próxima ação. Retorne o resultado, coloque o trabalho na fila, tente novamente centralmente, recue ou rejeite-o de acordo com o contrato de carga de trabalho.

O serviço de reserva deve ser escalonável horizontalmente, mas sua decisão deve ser atômica para cada solicitação. Um contador distribuído que permite que dois trabalhadores observem a mesma capacidade restante pode recriar o problema do provedor 429 dentro do gateway.

Use um modelo de cota canônico sem ocultar diferenças de provedor

Defina um modelo canônico que possa representar restrições específicas do provedor em vez de forçar cada provedor em uma abstração.

Represente cada limite como um intervalo com escopo, capacidade, regra de recarga ou redefinição, unidade e origem. Um bucket de projeto de provedor pode conter solicitações e tokens de entrada. Um bucket do espaço de trabalho pode conter tokens de saída. Uma política interna de parceiros pode adicionar simultaneidade e limites de gastos. A decisão de admissão será bem-sucedida somente se todas as reservas exigidas forem bem-sucedidas.

Não trate os cabeçalhos dos provedores como uma fonte completa de verdade. Use-os para corrigir as estimativas do corretor, mas mantenha um modelo configurado para limites que não são expostos em todas as respostas. Os nomes dos cabeçalhos, a disponibilidade e a semântica de redefinição variam de acordo com o provedor e a rota.

Reserve tokens antes do envio e reconcilie-os

A reserva de token é a diferença mais importante entre um corretor e um wrapper de nova tentativa. O corretor precisa de uma estimativa de demanda antes de enviar a solicitação.

Para tokens de entrada, faça uma estimativa a partir de mensagens serializadas, definições de ferramentas, esquema de saída estruturado e qualquer contexto recuperado. Para tokens de saída, use o máximo de solicitação quando disponível ou uma estimativa específica do modelo e da carga de trabalho quando o cliente não fornecer uma. Mantenha a estimativa anexada à reserva para que ela possa ser comparada com o uso real posteriormente.

Um registro de reserva simples pode conter:

• Uma solicitação exclusiva e um ID de reserva.
• Locatário, aplicativo, API chave, rota e classe de carga de trabalho.
• Tokens de entrada, tokens de saída, tokens totais e gastos estimados.
• Cada intervalo cobrado pela reserva.
• Hora de criação, hora de expiração, prazo da fila e chave de idempotência.
• Uso real final e o valor liberado ou cobrado durante a reconciliação.

Estimativas conservadoras reduzem as respostas do provedor 429, mas podem limitar a capacidade. Meça o erro de estimativa por modelo, rota, família de prompts, comprimento do contexto e modo de saída estruturada. Em seguida, ajuste as estimativas usando correções limitadas em vez de permitir que uma única solicitação incomum distorça todo o modelo.

O streaming requer uma política específica. Você pode reservar a permissão máxima de saída e liberar a parte não utilizada quando o fluxo terminar ou reservar a capacidade de saída em incrementos menores à medida que os tokens chegam. A primeira abordagem é mais fácil de raciocinar; o segundo pode melhorar a utilização, mas requer cancelamento confiável, tempo limite e tratamento de desconexão.

Aplicar cotas hierarquicamente

A capacidade deve ser verificada desde a política mais restrita até o recurso compartilhado mais amplo. Uma hierarquia típica é:

1. API chave ou identidade de serviço.
2. Aplicativo e ambiente.
3. Inquilino da equipe ou do cliente.
4. Conta de parceiro ou revendedor.
5. Espaço de trabalho ou subconta do provedor.
6. Projeto ou organização do fornecedor.
7. Modelo e rota.

Uma solicitação de um aplicativo de parceiro pode, portanto, precisar de quatro reservas bem-sucedidas: a política de simultaneidade do parceiro, o orçamento de token do locatário do cliente, a alocação de rota do gateway e a cota disponível do projeto do provedor. Se alguma reserva falhar, libere as reservas já adquiridas e aplique a decisão do bucket com falha.

Para ser justo, use filas justas ponderadas ou round-robin de déficit em vez de permitir que o trabalhador que chegar primeiro consuma o pool compartilhado. Atribua pesos mais altos ao tráfego de produção e pesos mais baixos aos trabalhos em segundo plano, preservando ao mesmo tempo os créditos de explosão para cada inquilino. O particionamento rígido é mais fácil de explicar, mas pode deixar a capacidade ociosa quando um locatário está quieto. O compartilhamento ponderado geralmente usa a capacidade com mais eficiência, desde que locatários barulhentos tenham limites de intermitência limitados.

Projetar filas em torno de contratos de carga de trabalho

Uma fila não é automaticamente um recurso de confiabilidade. Pode transformar um 429 visível em um atraso invisível de dez minutos. Cada classe de fila precisa de um prazo, comportamento de cancelamento, profundidade máxima e ação de sobrecarga.

• Interativo: Prazo curto, fila pequena, rejeição previsível ou degradação do modelo quando a capacidade não está disponível.
• Histórico de produção: Prazo mais longo, fila durável, chave de idempotência e orçamento de novas tentativas controlado.
• Parceiro: cotas específicas do locatário, metadados de resposta publicados e nenhum acesso ao estado da fila de outro locatário.
• Batchable: Execução atrasada, fila maior e roteamento opcional para um lote de provedor API quando a carga de trabalho permitir.

A admissão na fila deve retornar uma decisão clara. Dependendo do contrato API, exponha uma resposta de sobrecarga 429 ou específica do gateway com um valor de nova tentativa, identificador de fila e código de razão. Não prometa um prazo de conclusão, a menos que o sistema possa cumprir essa promessa.

O processamento em lote pode remover o trabalho não interativo da capacidade síncrona, mas altera o tempo dos resultados, o comportamento de novas tentativas, o cancelamento e a reconciliação. Trate-o como um caminho de execução separado, em vez de simplesmente colocar solicitações síncronas em uma fila muito longa. Para cargas de trabalho em segundo plano, compare as compensações operacionais com as políticas de controle de custos da IA API e as operações em lote existentes.

Centralizar o tratamento de novas tentativas e sobrecargas

Fato: As respostas temporárias de limite de taxa geralmente usam HTTP 429, enquanto as condições de sobrecarga do provedor podem usar 503 ou um código de erro específico do provedor. Alguns provedores retornam um cabeçalho Retry-After, e a documentação do provedor recomenda honrá-lo quando presente. Uma rampa de tráfego rápida também pode produzir comportamento de aceleração ou desaceleração sem o esgotamento normal do balde.

Recomendação: trate Retry-After como um limite inferior, não como uma sugestão opcional. Pause o escopo do provedor afetado até esse momento, adicione jitter limitado para evitar ativações sincronizadas e deixe o corretor decidir quais solicitações enfileiradas podem usar a capacidade recuperada.

Quando Retry-After estiver ausente ou inválido, use espera exponencial limitada com jitter. Mantenha o orçamento de nova tentativa no corretor, e não separadamente em cada SDK e adaptador de provedor. Caso contrário, uma solicitação lógica pode produzir uma nova tentativa de gateway, uma nova tentativa SDK, uma nova tentativa de cliente HTTP e uma repetição no lado do provedor.

Classifique os erros antes de tentar novamente:

• Capacidade repetível: 429 temporário ou resposta de cota transitória documentada.
• Sobrecarga repetível: Sinal temporário de sobrecarga do provedor 503 ou equivalente.
• Falha na política que não pode ser repetida: cota diária, limite de gastos, projeto desativado ou limite de locatário.
• Falha na solicitação que não pode ser repetida: Esquema inválido, parâmetro não suportado, falha de autenticação ou entrada malformada.
• Falha no prazo: uma solicitação cujo prazo restante do usuário ou do fluxo de trabalho é menor que a próxima tentativa segura.

O substituto é uma decisão separada. Um provedor diferente pode ter comportamento de saída, preços, latência, residência ou limites de contexto diferentes. Use o substituto somente quando a política de rota confirmar que o contrato de carga de trabalho pode tolerar essas diferenças.

Expor decisões e medir a saturação

As equipes não poderão solucionar problemas de limitação se o gateway retornar apenas um 429 genérico. Retornar metadados seguros, como limite aplicável, capacidade restante, tempo de redefinição, decisão de fila, classe de carga de trabalho e motivo de rejeição. Evite expor o uso de outro locatário ou credenciais brutas de provedor.

No mínimo, monitore:

• Taxa de sucesso e rejeição de reservas por inquilino, rota e intervalo.
• Profundidade da fila, tempo de espera da fila, vencimento de prazos e cancelamentos.
• Taxas dos provedores 429 e 503, frequência de novas tentativas e rejeições de taxa de aumento.
• Uso de token estimado versus real e capacidade desperdiçada por reservas excessivas.
• Saturação de simultaneidade e parcela da capacidade consumida por cada locatário.
• Repetidas tentativas por solicitação lógica e frequência de fallback.
• Cota diária e margem de janela de gastos.

Os testes de carga devem incluir tráfego intermitente, solicitações de contexto longo, solicitações de saída máxima, desconexões de streaming, esgotamento diário da cota, respostas dos provedores 429 e 503 e um locatário barulhento competindo com o tráfego de produção. Valide não apenas se as solicitações serão concluídas, mas também se os prazos de fila, a imparcialidade e os orçamentos para novas tentativas permanecem intactos.

Lista de verificação de implementação

• Defina dimensões canônicas sem descartar limites específicos do provedor.
• Atribua a cada solicitação um inquilino normalizado, uma rota, uma classe de carga de trabalho e uma chave de idempotência.
• Estimar e reservar entrada, saída, total de tokens, gastos, solicitações e simultaneidade antes do envio.
• Torne as reservas de vários intervalos atômicas e expire as reservas abandonadas com segurança.
• Reconcilie o uso real do provedor e os cabeçalhos de resposta após cada tentativa.
• Use imparcialidade ponderada, créditos contínuos e classes de prioridade explícitas.
• Dê a cada fila um prazo, profundidade máxima e ação de sobrecarga.
• Centralizar novas tentativas e honrar os valores Retry-After do provedor.
• Separe os erros temporários de capacidade dos erros permanentes de política e solicitação.
• Publique metadados de limitação e monitore a saturação por locatário e rota.
• Teste o esgotamento da cota do provedor, limites de rampa, streaming, fallback e comportamento de vizinhos barulhentos.

Conclusão

Um gateway multimodelo deve gerenciar a cota do provedor como capacidade de infraestrutura compartilhada, não como uma coleção de SDK configurações independentes. Um corretor de limite de taxa neutro em termos de provedor oferece às equipes de plataforma um caminho de admissão, uma política de justiça, um orçamento para novas tentativas e um local para reconciliar as estimativas com a realidade.

O design exige mais do que um depósito de token genérico. Deve representar solicitações, tokens de entrada e saída, cotas diárias, janelas de gastos, simultaneidade, escopo do provedor e taxa de rampa. Uma vez que essas dimensões sejam explícitas, o gateway pode fazer escolhas previsíveis: despachar agora, entrar na fila com um prazo, dispensar trabalho, tentar novamente de forma centralizada ou usar um substituto seguro para o contrato. É assim que o controle de rendimento se torna uma capacidade operacional em vez de uma fonte recorrente de incidentes de produção 429 e 503.

Leitura relacionada

• processamento em lote para cargas de trabalho LLM não interativas