O que são limites de taxa numa API de LLM?

O que é um limite de taxa nesta API

Um limite de taxa aqui é um teto por bucket dentro de uma janela fixa. O limitador conta um pedido dentro do processo da API, deixa passar os primeiros e recusa o seguinte com HTTP 429. Não há token bucket, nem leaky bucket, nem contador partilhado entre um cluster: um bucket é um nome, um limite e uma janela, e todos os números da página de limites são gerados a partir do mesmo objeto que o próprio limitador lê, em vez de escritos à mão num documento.

Os buckets, com os seus números

Os buckets de inferência são os dois que a maioria de quem chama encontra. O key_chat permite 600 chamadas de inferência por chave de API numa janela de um minuto; o org_chat permite 1800 chamadas de inferência em toda uma organização no mesmo minuto. Ambos têm de passar para que uma chamada avance, e isso é deliberado, não redundante: uma chave ruidosa não pode consumir o orçamento inteiro da organização, e uma organização ocupada não pode ficar à fome por causa de uma única chave que só conta contra si própria.

A API da plataforma é contada em separado. O platform permite 300 chamadas por chave por minuto para leituras e escritas da organização — chaves, utilização, traces, políticas. As superfícies públicas têm os seus próprios buckets por IP: o public_chat permite 20 chamadas anónimas ao playground por endereço IP por hora, o public_card_request permite 5 pedidos de cartão de modelo a partir do formulário público por IP por hora, e o auth permite 20 tentativas de início de sessão, registo, recuperação e reposição de palavra-passe por IP numa janela de quinze minutos.

Uma linha dessa tabela é um aviso, e não um controlo. O public_page está definido com um limite de 300 pedidos por hora por IP, e nenhum caminho de pedido nesta implementação o verifica. É apresentado com uma marca de não aplicado, porque um número na documentação que nada aplica não é um limite, e esconder a lacuna tornaria todos os outros números da página menos credíveis.

O que contém realmente uma recusa

Um pedido recusado é HTTP 429 com o tipo rate_limit_error e o código rate_limit_exceeded. Esta implementação não define qualquer cabeçalho retry-after nem cabeçalhos x-ratelimit, pelo que o corpo da resposta é o único relógio de que dispõe. Quando o limitador sabe quando termina a sua janela, a mensagem termina com esse instante em ISO 8601, por exemplo um timestamp Retry after. Para o limite por organização, a mensagem não nomeia tempo nenhum, pelo que o recuo exponencial é a única estratégia honesta aí. Tentar de novo mais cedo não pode resultar: o contador só avança quando a janela roda.

A concorrência também é limitada

No máximo 8 pedidos podem estar em curso numa chave de API ao mesmo tempo. A contagem é mantida por chave e não por organização, é incrementada quando uma chamada entra no handler de chat e reduzida quando termina, e um pedido acima do teto é recusado de imediato com o mesmo 429. Não há fila por trás disso, que é a parte que as pessoas não vêem: um pedido concorrente acima do limite não é abrandado, é rejeitado.

Porque é que as janelas são por processo

As janelas vivem na memória do processo da API. São reescritas na tabela rate_limits a cada 15 segundos e ao encerrar, e restauradas quando o processo arranca, pelo que um reinício continua uma janela em vez de distribuir um orçamento novo. A consequência é declarada em vez de descoberta: o contador é por nó de API, pelo que dois nós de API duplicam todos os limites efetivos. A versão partilhada exigiria um armazenamento que ainda nada lê — o REDIS_URL está reservado para isso e não é usado —, pelo que o conselho prático é correr um único nó de API ou aceitar limites por nó com conhecimento de causa.

O que não é um limite de taxa

Três recusas parecem limitação de tráfego e não são. Um teto de gasto diário da organização responde 402 budget_exceeded antes de qualquer endpoint ser avaliado; isso é dinheiro, não taxa. Um teto de preço por milhão de tokens retira um endpoint do conjunto de candidatos durante o encaminhamento, em vez de rejeitar o pedido, pelo que a chamada continua a ter sucesso num endpoint mais barato. E o 409 no_endpoint_for_policy é o filtro de residência a recusar relaxar-se; tentar de novo não muda nada, porque o mesmo pedido falha da mesma maneira. Só o 429 vale uma nova tentativa com recuo.

Os corpos dos pedidos estão limitados a 1 MB e são validados antes de acontecer mais alguma coisa, o que é um limite de tamanho e não um limite de taxa, e os stack traces são registados em log em vez de devolvidos a quem chama.

Como planear em torno dos limites

Conte o que a sua integração envia realmente por chave e por minuto, e lembre-se de que uma conclusão em streaming ocupa um lugar em curso durante toda a sua duração. Se vários serviços partilharem uma chave, partilham as suas 600 chamadas e os seus 8 lugares concorrentes; chaves separadas na mesma organização continuam a encontrar juntas o teto de 1800 chamadas da organização. Leia a página de limites antes de afinar, uma vez que é gerada a partir da tabela de aplicação, e trate os nomes dos buckets como o vocabulário sobre o qual o seu tratamento de erros deve ramificar: chave, organização, IP e plataforma falham de forma diferente, e só alguns lhe dizem quando voltar.

Se a sua carga de trabalho não cabe dentro destes números, a conclusão honesta é que esta implementação ainda não está dimensionada para ela. A tabela é pública, diz quais as linhas que são aplicadas, e um limite que se pode ler com antecedência vale mais do que um que se descobre em produção.