Como devem as APIs de LLM limitar pedidos, tokens e concorrência?
Tradução automática
Este artigo foi traduzido automaticamente a partir da versão original em inglês.
Uma API de LLM precisa de limites separados para o número de pedidos, o volume de tokens e o trabalho concorrente. Os pedidos por minuto, por si só, não protegem um serviço quando o comprimento dos prompts e das saídas geradas varia. Acrescente limites de entrada e saída por pedido e depois teste os limites de admissão face ao objetivo de latência.
Porque a contagem de pedidos não basta
Um prompt de 10 tokens e um prompt de 100,000 tokens diferem no comprimento de entrada por um fator de 10,000. Os seus custos totais também dependem do comprimento da saída, do modelo e da utilização de cache. Um limite que os trate de igual forma pode admitir mais trabalho do que o serviço consegue processar.
Combine vários controlos:
| Limite | O que controla |
|---|---|
| Pedidos por minuto | Volume de chamadas, incluindo muitos pedidos pequenos |
| Tokens de entrada e saída | Volume de processamento e custos variáveis |
| Pedidos concorrentes | Trabalho ativo que consome capacidade de descodificação e memória KV |
| Tokens por pedido | Prompts ou saídas individuais que ultrapassam os limites testados |
Aplique os limites de cada cliente antes de um limite partilhado por todo o serviço, para que um cliente não possa consumir toda a capacidade disponível.
Como funciona a reserva de tokens
Uma possível política da aplicação reserva, na admissão, os tokens de entrada estimados mais a saída máxima permitida. Um pedido com 2,000 tokens de entrada e um limite de saída de 1,000 reserva 3,000 tokens. Se produzir 200 tokens de saída, a utilização real é de 2,200; a aplicação devolve 800.
Distinga este exemplo da contabilização do fornecedor. A OpenAI documenta as suas próprias estimativas de quotas de pedidos e tokens. A Anthropic documenta limites separados para tokens de entrada e saída. Uma reserva local não prevê que quota do fornecedor um pedido consome. Reconcilie os pedidos interrompidos quando os dados de utilização estiverem disponíveis e limite as reservas que não possam ser reconciliadas.
O que verificar sob carga
Combine prompts curtos e longos, saídas curtas e longas e clientes em simultâneo. Registe o tempo em fila, os pedidos rejeitados, TTFT, TPOT e a utilização de KV cache. Mantenha os pedidos em fila apenas durante um tempo limitado; caso contrário, rejeite-os com uma política clara de novas tentativas. Um orçamento de tokens por minuto pode ainda admitir um aumento súbito de tráfego que ultrapasse a capacidade de memória para pedidos concorrentes.
Para um desenho mais abrangente, leia a limitação da frequência de pedidos no guia de engenharia de LLM.