Limites de taxa dos LLMs: tokens por minuto, pedidos por minuto e o que acontece quando os atinges

As APIs dos modelos de linguagem limitam o seu tráfego de duas formas ao mesmo tempo: quantos pedidos envia por minuto (RPM) e quantos tokens usa por minuto (TPM). Podes manter-te bem abaixo do limite de pedidos e ainda assim ser limitado porque alguns prompts longos gastaram o teu orçamento de tokens. Quando atinges qualquer um dos limites, a API responde com 429 Too Many Requests e a tua aplicação tem de esperar.

Como contam OpenAI, Azure OpenAI e Anthropic

Provider O que está limitado O que saber
OpenAI RPM, requisições por dia, TPM, tokens por dia e mais, por organização e projeto, por modelo Atinges o limite que for atingido primeiro. Para o limite do token, um pedido conta como o maior de max_tokens e uma estimativa baseada nos seus caracteres. As requisições falhadas também contam.
Azure OpenAI TPM que atribuis a cada implementação, mais um limite de RPM definido proporcionalmente a ele O RPM é verificado em janelas de 1 ou 10 segundos, por isso uma rajada chega a 429 mesmo quando o total por minuto está correto. A estimativa de tokens inclui max_tokens.
Anthropic RPM, tokens de entrada por minuto (ITPM) e tokens de saída por minuto (OTPM), por modelo A capacidade recarrega-se continuamente, e 60 pedidos por minuto podem ser aplicados como 1 pedido por segundo. Para a maioria dos modelos, os tokens de entrada em cache não contam para o ITPM, nem max_tokens para o OTPM.

Se definires max_tokens para 4.000 e receberes 200 tokens de volta, a OpenAI e a Azure OpenAI continuam a contar os 4.000 para o teu limite. É assim que consegues obter 429s enquanto as tuas métricas de utilização parecem muito abaixo da tua quota.

O que significa um 429 para cada fornecedor

Nem todos os erros 429 desaparecem se esperares.

Provider Aguarde e tente novamente Para e diz a alguém
OpenAI 429 para pedidos ou tokens, 429 slow_down (o teu tráfego cresceu demasiado rápido, mesmo dentro dos teus limites), e 503 server_is_overloaded. Espera por Retry-After até estar presente. 429 com credit_balance_exhausted, organization_spend_limit_exceeded, project_spend_limit_exceeded, ou organization_usage_limit_exceeded em error.code. Voltar a tentar não vai restaurar o acesso.
Azure OpenAI 429 para o TPM ou RPM da implementação, para a capacidade do sistema, ou para uma redução temporária do seu limite de pedidos. Aguarde retry-after-ms. Erros 429 persistentes em produção, apesar de estares abaixo da tua quota aprovada. Verifique a alocação de TPM da implementação e depois abra um pedido de suporte.
Anthropic 429 rate_limit_error com um cabeçalho retry-after, incluindo limites de aumento após um aumento acentuado da utilização, e 529 overloaded_error. 429 do limite mensal de despesas. Não tem cabeçalho retry-after, error.details.error_code está enforced_spend_limit_reached, e continua a falhar até o acesso ser restabelecido.

Como lidar com limites de taxa de LLM

  1. Vê qual dos 429 que tens. Erros de faturação, despesa e quotas precisam de uma pessoa, não de uma nova tentativa.
  2. Esperar o tempo indicado pela API. OpenAI e Anthropic enviam retry-after em segundos. O Azure OpenAI envia retry-after-ms em milissegundos. Na ausência de qualquer indicação, aumenta exponencialmente o intervalo de espera com variação aleatória e define um limite tanto para o número de tentativas como para o tempo total.
  3. Saiba o que o seu SDK já faz. Os SDKs Python da OpenAI e da Anthropic repetem erros de ligação e respostas 408, 409, 429 e 5xx 2 vezes por defeito. Se adicionares o teu próprio ciclo de retentativa, desativa as tentativas do SDK, por exemplo com max_retries=0 em Python, como recomenda o Azure OpenAI, ou as tentativas multiplicam-se.
  4. Reduz o que importa. No OpenAI e no Azure OpenAI, defina max_tokens para um valor próximo do tamanho de resposta esperado. No Anthropic, armazene em cache conteúdos repetidos como instruções do sistema.
  5. Aumente gradualmente. Um aumento acentuado no tráfego ativa os limites de taxa da slow_down OpenAI e da Anthropic, mesmo dentro dos seus limites. A OpenAI sugere que, ao atingir 1 milhão de tokens de entrada por minuto, não deverá aumentar mais de 50% a cada 15 minutos.
  6. Não reproduzas um stream que já consumiste. Um erro após o início de um stream pode aparecer como um evento de streaming, e a OpenAI aconselha a não reproduzir automaticamente um pedido depois de consumir o resultado.
  7. Informe o utilizador quando um pedido fica pendente devido a um 429, em vez de mostrar um spinner.

Como testar se a sua aplicação lida com os limites de taxa dos LLMs

Approach O que encontra Do que sentes falta
Simula o cliente SDK nos teus testes, ou deixa o teu agente de programação escrever o mock Se a sua ramificação de erro é executada Os códigos de estado reais do fornecedor, códigos de erro e cabeçalhos, e as tentativas do seu próprio SDK. A tua aplicação também precisa de um switch só de teste para aceder ao mock.
Faz pedidos à API real até que te limite Comportamento real Pagas por cada token, e não podes ativar slow_downuma sobrecarga ou um limite de gasto a pedido
Intercete o tráfego real da sua aplicação e devolva os erros do fornecedor, ou limite com base nos tokens que a sua aplicação utiliza URLs reais, a política de retentativas do seu SDK e os corpos de erro do fornecedor, com um limite à sua escolha O teu código isoladamente. Guarda os testes unitários para isso.

Experimente na sua app

O Dev Proxy interceta os pedidos da sua aplicação para a API do modelo de linguagem e devolve os próprios erros do fornecedor, enquanto a sua aplicação continua a chamar o URL real. Para OpenAI, descarregue a predefinição e inicie o Dev Proxy com ela:

devproxy config get openai-throttling
devproxy --config-file "~dataFolder/configs/openai-throttling/.devproxy/devproxyrc.json"

O openai-throttling preset falha em 90% das solicitações a https://api.openai.com/* com um erro aleatório: rate_limit_exceeded para TPM ou RPM, slow_down, credit_balance_exhausted ou 503 server_is_overloaded. O preset anthropic-throttling faz o mesmo para https://api.anthropic.com/* com RPM, token de entrada, token de saída e aceleração 429s e 529 overloaded_error. Ambos os predefinidos incluem o RetryAfterPlugin, que indica quando a sua aplicação volta a chamar a API antes de expirar o tempo retry-after de uma resposta 429. Não verifica as respostas 503 e 529.

Para limitar os tokens que a sua aplicação realmente utiliza, use o LanguageModelRateLimitingPlugin. Conta os tokens de prompt e de completion que cada resposta reporta e devolve 429 com retry-after quando a tua aplicação ultrapassa os limites que definiste. Funciona com APIs compatíveis com OpenAI, incluindo Azure OpenAI e modelos locais:

{
  "$schema": "https://raw.githubusercontent.com/dotnet/dev-proxy/main/schemas/v3.3.1/rc.schema.json",
  "plugins": [
    {
      "name": "LanguageModelRateLimitingPlugin",
      "enabled": true,
      "pluginPath": "~appFolder/plugins/DevProxy.Plugins.dll",
      "configSection": "languageModelRateLimitingPlugin"
    }
  ],
  "urlsToWatch": [
    "https://api.openai.com/*",
    "https://*.openai.azure.com/openai/deployments/*/chat/completions*"
  ],
  "languageModelRateLimitingPlugin": {
    "$schema": "https://raw.githubusercontent.com/dotnet/dev-proxy/main/schemas/v3.3.1/languagemodelratelimitingplugin.schema.json",
    "promptTokenLimit": 1000,
    "completionTokenLimit": 500,
    "resetTimeWindowSeconds": 60
  }
}

O plugin não reproduz a max_tokens estimativa. O seu corpo padrão 429 usa o insufficient_quota código. Para devolver o corpo de erro que a sua aplicação espera para um limite de taxa, defina whenLimitExceeded como Custom e aponte customResponseFile para a sua própria resposta. Para instalar Dev Proxy, consulte Configurar Dev Proxy.

Passos seguintes

Testa como a tua aplicação lida com os limites de taxa do OpenAI

Ver também

  • Última atualização a