Concorrência em APIs de IA: como controlar filas, quotas e latência

Porque é que uma integração funcional pode ficar sobrecarregada

Uma integração com um modelo pode funcionar corretamente durante o tráfego habitual e, ainda assim, degradar-se quando chegam muitas solicitações ao mesmo tempo. Se a aplicação enviar cada pedido de imediato, sem controlar quantos estão em curso nem quantos aguardam, um pico pode acumular trabalho mais depressa do que o serviço consegue processá-lo. O resultado visível pode ser mais latência, solicitações que já perderam a utilidade quando são concluídas, respostas de limite atingido ou uma fatura que se afasta do previsto.

A concorrência é importante porque uma solicitação não ocupa recursos durante um período fixo. A geração pode demorar mais ou menos, consoante a tarefa, o tamanho da entrada e a quantidade de saída pedida. Por isso, contar apenas os pedidos por segundo não descreve, por si só, a pressão exercida por uma integração. Duas cargas com a mesma taxa de solicitações podem ter tempos de processamento e consumos diferentes.

O objetivo do controlo da carga não é manter toda a capacidade possível ocupada a qualquer custo. É proteger os objetivos da aplicação: concluir trabalho útil, respeitar prioridades, limitar esperas e evitar que uma procura temporariamente elevada transforme o sistema numa fila sem fim. As decisões de conceção abaixo são recomendações gerais; não descrevem um limite universal nem substituem as condições documentadas para cada API, modelo ou canal de acesso.

Convém separar dois problemas que muitas vezes se confundem. A admissão decide, antes de enviar um pedido, se a aplicação aceita o trabalho, o mantém brevemente em espera ou o rejeita. A política de novas tentativas atua depois de uma falha ou de um resultado incerto. Este guia centra-se sobretudo na primeira decisão e na espera controlada: repetir pedidos automaticamente não corrige uma política de admissão que deixa entrar mais trabalho do que o sistema consegue processar.

O que medir antes de definir limites

Comece por observar uma carga representativa, em vez de escolher um valor de concorrência ao acaso. Registe a taxa de chegada e o número de solicitações simultâneas, mas inclua também o tamanho da entrada e a saída produzida, quando esses dados estiverem disponíveis. Para uma decisão de admissão anterior ao envio, a saída ainda é desconhecida; pode ser medida posteriormente para melhorar as estimativas, mas não deve ser tratada como um dado exato sobre o futuro.

Meça a latência de ponta a ponta e, se conseguir instrumentar as fases separadamente, distinga o tempo em fila do tempo entre o envio e a resposta. Nas respostas geradas progressivamente, registe também o tempo até ao primeiro fragmento e a duração total. Um bom tempo até ao primeiro fragmento não significa que a tarefa completa tenha terminado rapidamente; do mesmo modo, uma duração total elevada não prova, por si só, que a causa seja a fila.

Utilize percentis, como p95 e p99, além das médias. A média resume uma tendência, mas pode ocultar uma minoria de solicitações que espera muito mais tempo. Acompanhe estas medidas com o número de solicitações concluídas, canceladas, expiradas e rejeitadas; os erros devolvidos pelo fornecedor; o uso de tokens, quando disponível; e o custo por tarefa concluída, se o sistema conseguir calculá-lo de forma fiável.

A relação de Little oferece uma forma de verificar a coerência entre o número médio de elementos num sistema, a taxa média de chegada e o tempo médio que cada elemento permanece no sistema: L = λW. Aplicada com cuidado, ajuda a perceber por que razão, se a taxa de chegada se mantiver e o tempo de permanência aumentar, também pode crescer o número médio de trabalhos presentes. Não é uma fórmula que, por si só, permita prever percentis, picos, custos ou o limite de uma API; descreve uma relação entre médias nas condições pertinentes.

Segmente as medições por modelo, endpoint, fornecedor, região ou projeto, quando essas diferenças forem relevantes para a sua configuração. Não misture tarefas curtas e longas numa única série se isso ocultar problemas de uma categoria. Separe também a carga de produção dos testes e registe as alterações de configuração, para poder relacionar uma variação da latência com uma causa plausível.

Não confunda taxa, concorrência, tokens e capacidade própria

Um limite de taxa controla quantas solicitações ou unidades contabilizadas podem ser submetidas durante um período. Um limite de concorrência restringe quantas operações a aplicação mantém ativas ao mesmo tempo. Um limite baseado em tokens diz respeito ao volume de texto processado ou solicitado, de acordo com as regras do serviço. Um limite próprio da aplicação é uma decisão adicional: por exemplo, quantos trabalhos a fila local aceita ou durante quanto tempo permite que aguardem.

Estas restrições resolvem problemas diferentes. Um sistema pode respeitar uma taxa média e, ainda assim, acumular um pico breve; pode ter poucas solicitações simultâneas, mas de longa duração; ou pode receber poucas solicitações que envolvem entradas extensas. A aplicação deve conhecer as restrições publicadas para o canal que utiliza e, além disso, definir controlos locais que protejam a experiência do utilizador.

Não se devem transpor quotas de um produto para outro por analogia. A documentação do Vertex AI descreve quotas e limites cujo âmbito pode depender do serviço, do projeto e da região. A referência da API da OpenAI inclui cabeçalhos de resposta relacionados com limites de solicitações e de tokens. Estes exemplos mostram por que razão é necessário consultar a documentação aplicável à conta e à configuração concretas; não estabelecem valores partilhados nem uma regra única para todos os endpoints.

Uma resposta 429 também não identifica sempre uma única causa ou solução. A documentação do Vertex AI distingue situações relacionadas com capacidade partilhada e com capacidade aprovisionada. Por isso, registe o tipo de resposta e consulte a documentação correspondente antes de decidir o que significa. Em particular, não transforme todas as respostas 429 numa ordem para tentar novamente de imediato: esse comportamento pertence à gestão posterior à falha e pode aumentar a pressão se a admissão continuar aberta.

Conceba a admissão: aceitar, esperar ou rejeitar

Uma política de admissão deve prever explicitamente três resultados. Aceitar significa que a solicitação pode começar de acordo com os limites locais e as quotas conhecidas. Esperar significa que é mantida temporariamente numa fila com capacidade e prazo definidos. Rejeitar significa que o sistema não se compromete a processá-la naquele momento e devolve uma resposta que permite à aplicação cliente decidir o que fazer.

Uma fila sem limite não é uma solução segura: pode transformar uma sobrecarga visível em esperas cada vez maiores e em trabalho armazenado que chega demasiado tarde para ser útil. Defina um número máximo de elementos, um orçamento de espera e uma condição de expiração. Se a fila atingir o limite, rejeite o novo trabalho ou aplique uma regra de substituição justificada pelo produto; não esconda o problema acrescentando armazenamento sem um limite operacional.

A resposta de rejeição deve ser coerente com a interface do seu serviço. Explique que a tarefa não foi admitida ou indique que a capacidade está temporariamente ocupada, sem afirmar que o modelo a processou. Quando a aplicação puder tentar novamente mais tarde, forneça um sinal claro e documentado para que o cliente tome essa decisão. Evite prometer um tempo de espera exato se não conseguir sustentá-lo com medições.

A admissão pode combinar várias condições: capacidade de concorrência disponível, fila abaixo do máximo, quota por utilizador e orçamento de espera restante. Avalie as condições antes de reservar recursos e liberte a reserva quando a tarefa for concluída, cancelada ou expirar. Se uma solicitação for cancelada no cliente, mas continuar a ocupar uma posição local, a medição de concorrência deixa de representar o trabalho que está efetivamente ativo.

Defina explicitamente a ordem de prioridade. Por exemplo, pode reservar uma parte da capacidade para tarefas interativas e limitar tarefas em lote, se essas categorias existirem no seu produto e se a política não deixar indefinidamente sem serviço a categoria de prioridade inferior. O objetivo não é inventar uma prioridade universal, mas refletir o valor e o prazo de cada classe de trabalho.

Pondere o trabalho sem fingir que conhece o custo exato

Contar solicitações é uma regra simples, mas trata da mesma forma tarefas que podem ser muito diferentes. Uma alternativa consiste em atribuir um peso estimado a cada solicitação usando sinais disponíveis antes do envio: tokens de entrada estimados, comprimento previsto da saída, classe da tarefa ou medidas históricas de duração para aquele tipo de operação. O peso pode ajudar a definir prioridades, limitar orçamentos ou decidir se a tarefa cabe na fila.

Uma estimativa não é uma garantia. A resposta gerada pode ser mais curta ou mais longa do que o previsto; a duração pode variar mesmo quando as entradas têm tamanhos semelhantes. Por isso, ajuste a estimativa comparando-a com resultados observados, mantenha margens e reveja os erros de previsão. Se a saída real for registada, utilize-a para melhorar políticas futuras, não para apresentar como conhecido um dado que não estava disponível no momento da admissão.

Uma opção prática consiste em atribuir limites separados por classe ou reservar uma quantidade de trabalho prevista por período. Outra é utilizar um sistema interno de créditos, em que cada solicitação consome um peso estimado e a capacidade é reposta de acordo com a política local. Em ambos os casos, documente como o peso é calculado, como é corrigido e o que acontece quando um pedido excede o previsto. Não apresente uma contabilização local de tokens como se fosse idêntica à quota do fornecedor.

Compare as políticas com o mesmo conjunto de solicitações e a mesma carga. Se uma política ponderada reduzir os picos de espera para trabalhos pequenos, verifique também o que acontece às tarefas grandes: podem ser continuamente adiadas. O critério de sucesso deve considerar o desempenho agregado, a latência por classe e a proporção de tarefas concluídas dentro do prazo, não apenas uma métrica favorável às solicitações mais curtas.

Prioridade, equidade e proteção contra bloqueios

Uma única fila pode ser suficiente para um produto com tarefas equivalentes, mas apresenta riscos quando combina trabalhos urgentes e tarefas longas. Uma tarefa demorada no início da fila pode fazer com que outras esperem, mesmo sendo breves. Além disso, se um cliente gerar uma parte desproporcionada da procura, pode consumir a capacidade partilhada e prejudicar os restantes.

Pode separar filas por classe de serviço, estabelecer quotas por utilizador ou limitar o número de tarefas simultâneas por cliente. Também pode reservar capacidade para o tráfego interativo e processar trabalho em lote com a margem restante. Estas são opções de conceção, não uma garantia de equidade: a prioridade, o tamanho das reservas e a regra de seleção devem ser testados com padrões de utilização reais.

Defina o que significa equidade no seu caso. Pode significar que cada cliente tem oportunidade de avançar, que as tarefas interativas cumprem um prazo ou que nenhum utilizador consome todo o orçamento local. Uma quota muito rígida por utilizador pode proteger contra a concentração da capacidade, mas também pode deixá-la por utilizar quando os outros utilizadores estão inativos. Uma quota demasiado flexível pode não proteger os clientes pequenos durante um pico.

Para evitar que uma prioridade baixa seja adiada indefinidamente, considere limites máximos de espera, aumento gradual da prioridade com o tempo ou oportunidades mínimas de serviço. Meça o tempo em fila por classe e cliente, e não apenas a média global. Se as categorias tiverem prazos diferentes, registe quantas tarefas são concluídas a tempo e quantas expiram. Uma política que melhora a latência de uma classe à custa de tornar outra inútil deve ser apresentada como uma decisão explícita do produto.

Orçamentos de espera, cancelamento e expiração

Cada tarefa deve ter um prazo de utilidade definido pelo produto, mesmo que esse prazo não seja apresentado diretamente ao utilizador. Se um pedido permanecer na fila para além do momento em que ainda pode ter valor, mantê-lo apenas acumula trabalho atrasado. Atribua um tempo máximo de espera e volte a verificá-lo antes de enviar a tarefa ao fornecedor.

A expiração na fila e o cancelamento depois do envio não são a mesma coisa. Antes do envio, retirar uma tarefa pode evitar iniciar trabalho que já não é necessário. Depois do envio, o efeito do cancelamento depende das capacidades da integração e do comportamento documentado do endpoint. Não presuma que fechar uma ligação interrompe o processamento remoto ou reverte o consumo. Instrumente aquilo que o sistema consegue observar e descreva as limitações.

Registe quantas solicitações expiram antes de começar e quantas são canceladas durante o processamento. Se muitas expirarem na fila, reveja o tamanho da fila, a taxa de admissão e o orçamento de espera. Se forem canceladas depois de enviadas, investigue se uma política de expiração mais precoce ou uma interface que permita ao utilizador retirar o trabalho reduziria tarefas inúteis. Não conclua que houve uma poupança de custos sem uma medição que sustente essa conclusão.

A expiração também ajuda a gerir prioridades: uma tarefa urgente que já perdeu o prazo não deve continuar em primeiro lugar apenas por ter chegado antes. No entanto, descartar trabalho automaticamente pode ter consequências funcionais. Defina se o vencimento será comunicado, se a tarefa será preservada para execução posterior ou se será eliminada; o comportamento deve ser previsível para quem integra o serviço.

Teste de carga reproduzível e operação

Teste a política antes de a aplicar de forma generalizada. Crie um conjunto representativo de tarefas que inclua entradas e saídas de comprimentos diferentes e as classes de prioridade que o produto utilizará efetivamente. Execute uma carga de base, aumente depois a concorrência por etapas e acrescente picos controlados. Mantenha constante o conjunto de solicitações ao comparar variantes, para que as diferenças não dependam de ter testado tarefas distintas.

Defina antecipadamente os critérios de paragem e reversão. Por exemplo, pode interromper o aumento se o p99 ultrapassar o objetivo acordado, se as expirações ou os erros aumentarem ou se o tempo em fila exceder o orçamento do produto. Os valores concretos devem resultar dos seus objetivos, medições e condições da API, não de um valor universal. Registe a configuração, a data, a versão do cliente e os parâmetros do teste para poder repeti-lo.

Separe as componentes da latência: tempo de espera local, tempo até à primeira resposta, quando for relevante, e duração total. Compare também o número de solicitações concluídas, as respostas de limite atingido, os cancelamentos, os percentis por classe e o custo por tarefa concluída. Se observar apenas o desempenho total, pode não detetar que uma classe está a falhar; se observar apenas uma resposta de erro, pode não perceber que o problema foi uma fila local que começou a crescer antes da chamada ao fornecedor.

Em operação, consulte as quotas publicadas para o canal específico e monitorize os cabeçalhos ou campos de resposta documentados por esse serviço. Estes sinais ajudam a identificar limites e a informar o sistema de observabilidade, mas a sua disponibilidade e significado dependem da API. Não presuma que um cabeçalho existe em todas as respostas ou que permanece inalterado. Registe a data em que a documentação foi consultada e confirme eventuais alterações antes de atualizar os controlos.

Uma implementação prudente começa com limites locais conservadores, observabilidade e uma forma de voltar à configuração anterior. Depois, aumenta-se gradualmente a admissão se os resultados justificarem essa decisão. Se as métricas piorarem, reduza a entrada, encurte a fila ou ajuste as classes de trabalho; não responda automaticamente ao aumento da latência alargando a fila, porque isso pode ocultar a sobrecarga e prolongar as esperas.

Limites da abordagem e critérios práticos

Não existe um valor de concorrência que possa ser transferido em segurança para todas as integrações. As quotas e condições podem variar por serviço, modelo, projeto, região e canal. Além disso, as quotas podem mudar, e uma resposta observada num teste não demonstra que a mesma capacidade estará disponível noutra configuração ou momento. Consulte as fontes oficiais aplicáveis e confirme os limites antes de os transformar em regras permanentes.

Também não existe uma fórmula única que converta tokens ou solicitações por segundo numa latência garantida. A relação entre chegada, permanência e número médio de elementos ajuda a raciocinar sobre o crescimento de uma fila, mas não substitui um teste representativo nem prevê cada resposta. Os tamanhos de saída e as durações observadas fornecem informação; as estimativas prévias servem para admitir com prudência, não para assegurar um resultado exato.

Antes de aprovar uma política, confirme que sabe quantas solicitações estão em curso e à espera; que a fila tem um limite e uma expiração; que a admissão considera os tamanhos de trabalho relevantes; e que existe uma resposta clara quando uma tarefa não é aceite. Confirme também que as prioridades não deixam uma classe sem serviço, que os cancelamentos são medidos no estado correto e que as métricas distinguem a espera local do processamento remoto.

Por último, mantenha a distinção entre controlo da carga e recuperação de erros. A admissão decide quanta procura entra e quanto trabalho espera. As novas tentativas definem como reagir depois de uma falha ou de um resultado incerto. Um sistema robusto precisa de políticas compatíveis para ambas as fases, mas uma não substitui a outra: primeiro, evite aceitar mais trabalho do que consegue gerir; depois, defina separadamente como responder às falhas.

Continue a explorar

Correções e transparência

Se encontrar informação incorreta ou desatualizada, envie-nos a página e a fonte que devemos rever.