Uma função de inteligência artificial pode ser útil e, ainda assim, lenta ou cara demais para uma operação específica. O risco aparece quando cada chamada é tratada como se tivesse as mesmas necessidades: resumir um texto em segundo plano não tem o mesmo impacto que responder a uma consulta durante o checkout. Para controlar o custo e a latência de IA no PHP, convém definir um orçamento operacional para cada caso de uso e decidir antecipadamente o que acontecerá quando ele for atingido.
Esse orçamento não é uma promessa de qualidade nem uma garantia de que o provedor responderá dentro de um prazo. É um conjunto de limites e decisões de produto que permite conter o impacto, informar o usuário e manter o comportamento da aplicação sob controle.
Um orçamento diferente para cada operação
Um orçamento operacional reúne os recursos que uma função pode consumir e o tempo pelo qual faz sentido esperar. Pode incluir uma duração máxima, um limite de gasto estimado, um número de tentativas, uma quantidade de texto processado ou uma combinação desses controles. Ele deve estar vinculado a uma operação reconhecível no produto, e não ser uma configuração abstrata compartilhada por todas as chamadas.
Por exemplo, uma sugestão opcional em um painel pode tolerar que o sistema a omita se demorar demais. Por outro lado, se uma função fizer parte de um processo essencial, talvez seja necessário oferecer uma alternativa que permita concluir o fluxo sem IA. Um trabalho de classificação em lote pode aceitar uma fila e um status pendente, enquanto uma resposta interativa precisa de um limite de espera mais rigoroso.
Para escolher os limites, esclareça primeiro de qual resultado o usuário precisa, se ele é indispensável naquele momento e o que acontece se não estiver disponível. Separe também o orçamento da avaliação de qualidade: uma resposta rápida e barata pode estar incorreta, e uma resposta correta pode chegar tarde demais para ser útil. Os dois aspectos exigem medidas e critérios próprios.
Meça antes de definir os limites
Sem uma linha de base, os limites são suposições. Registre métricas por tipo de operação e observe como elas variam com o volume, o tamanho da entrada e as condições de uso. No mínimo, convém medir a duração total, o tempo até o primeiro resultado útil, quando aplicável, a frequência de uso e o custo estimado. Para operações assíncronas, registre também o tempo na fila e o tempo de processamento.
Associe cada medição a um identificador de operação, a um resultado e a dados contextuais não sensíveis, como o tamanho aproximado da solicitação ou o modo de execução. Evite armazenar o texto do usuário, segredos, informações pessoais ou respostas completas se isso não for necessário para diagnosticar o problema. Quando for preciso investigar um caso, aplique controles adequados de acesso, retenção e minimização.
O custo estimado deve se basear nas informações disponíveis para o serviço utilizado e refletir seus limites. Não o confunda com uma cobrança confirmada: preços, unidades contabilizadas e componentes faturáveis podem variar. Se a aplicação não puder calcular um custo confiável antes da chamada, use controles alternativos, como limites de frequência, tamanho máximo, cotas por usuário ou gasto agregado monitorado.
Transforme o orçamento em limites verificáveis
Defina onde cada controle será aplicado. Um limite por solicitação evita que uma execução individual se prolongue ou consuma recursos em excesso. Uma cota por usuário ou conta limita o uso repetido. Um limite por processo protege uma tarefa que agrupa várias operações. Para controlar o gasto global, monitore também o consumo agregado; um limite individual não impede que muitas solicitações simultâneas ultrapassem o orçamento do sistema.
Decida também como as novas tentativas vão funcionar. Repetir uma solicitação automaticamente pode duplicar o custo ou aumentar a latência, especialmente quando não se sabe se o serviço chegou a processar a solicitação. Defina quantas tentativas são permitidas, para quais erros e com qual intervalo. Use chaves de idempotência quando forem compatíveis e relevantes para evitar efeitos duplicados em operações que modificam dados.
Quando um limite for atingido, as opções incluem interromper a solicitação, reduzir seu escopo, adiá-la para uma fila ou encaminhá-la para revisão humana. A escolha depende do caso de uso. Uma resposta parcial só é aceitável se a interface a identificar claramente e o resultado continuar seguro e útil. Se a tarefa for sensível ou não aceitar resultados incompletos, pode ser preferível não exibir uma resposta gerada.
Aplique os controles em uma camada de integração PHP
Centralize as chamadas externas em uma camada de integração que receba a operação e seu orçamento, aplique os controles correspondentes e retorne um resultado explícito. Assim, a lógica de negócio não depende diretamente de um provedor nem interpreta de forma diferente os tempos limite e os erros em cada ponto da aplicação.
O trecho a seguir requer PHP 8.0 ou posterior, pois utiliza propriedades promovidas no construtor e argumentos nomeados. É um exemplo parcial: valida o tamanho da entrada e passa um tempo limite ao cliente, mas não implementa cotas, limites de gasto nem uma fila. Esses controles devem ser adicionados separadamente, conforme as necessidades da aplicação.
final class AiOutcome
{
public function __construct(
public string $status,
public ?string $content = null,
public ?string $reason = null,
) {}
}
function runAiOperation(
AiClient $client,
string $input,
int $timeoutSeconds
): AiOutcome {
if (strlen($input) > 12000) {
return new AiOutcome('rejected', reason: 'input_limit');
}
try {
$response = $client->generate($input, $timeoutSeconds);
return new AiOutcome('completed', $response->text);
} catch (TimeoutException $e) {
return new AiOutcome('timed_out', reason: 'timeout');
} catch (ProviderException $e) {
return new AiOutcome('unavailable', reason: 'provider_error');
}
}O cliente e as exceções dependem da integração escolhida. Em produção, configure o limite de tempo também no cliente HTTP e valide o tamanho antes de enviar os dados. O status timed_out indica que a solicitação excedeu o tempo de espera; não significa que ela tenha sido colocada em fila nem que continuará sendo processada. Retorne o status deferred somente se a aplicação tiver armazenado a tarefa em uma fila e dispuser de um processo capaz de retomá-la e comunicar o resultado.
Para completar a camada de controle, aplique limites de frequência ou cotas com um contador coordenado entre processos e monitore o gasto agregado. Se precisar impor um limite de custo antes de cada chamada, calcule o consumo estimado da solicitação e compare-o com o orçamento disponível; se não for possível estimá-lo com confiabilidade, use limites alternativos e alertas de consumo. As cotas compartilhadas não devem depender apenas da memória de uma requisição PHP.
Retorne status distintos, como concluído, rejeitado por limite, tempo de espera esgotado ou indisponível. Isso permite que a camada de negócio decida o que exibir sem confundir uma resposta lenta com uma resposta de baixa qualidade, nem um limite operacional com uma falha do provedor.
Projete uma degradação clara e útil
Degradar não significa ocultar um erro nem apresentar um resultado alternativo como se fosse equivalente. Significa manter uma experiência compreensível quando a função não consegue concluir o trabalho. Em uma ação opcional, pode bastar informar que a sugestão não está disponível e permitir que o usuário continue. Para uma tarefa longa, mostre que ela está pendente e ofereça um status que possa ser consultado, desde que a aplicação consiga mantê-lo de forma confiável.
Se for possível reduzir o escopo, explique o que foi omitido. Se a tarefa for encaminhada para revisão, não sugira que o resultado já foi validado. E, se for usada uma alternativa determinística, como uma regra de negócio existente, esclareça sua função quando a diferença afetar a decisão do usuário. Evite mensagens que prometam uma entrega posterior se não houver uma fila e um processo capazes de cumpri-la.
O fallback para falhas é diferente do controle de orçamento: ele é ativado diante de situações como indisponibilidade, erros de rede ou respostas inválidas. O orçamento pode se esgotar mesmo quando o serviço está funcionando corretamente. Os dois mecanismos devem ser definidos e testados separadamente, com status e mensagens adequados a cada causa.
Teste, configure alertas e ajuste com base em evidências
Teste os limites com cargas representativas e cenários adversos: entradas grandes, solicitações repetidas, respostas lentas, concorrência, erros do provedor e limites de cota. Verifique o que o usuário vê e o que fica registrado. Inclua casos de cancelamento e confirme que uma solicitação interrompida não continue consumindo recursos em segundo plano sem necessidade.
Configure alertas para anomalias operacionais: aumento da latência, mais solicitações rejeitadas, crescimento do gasto estimado ou acúmulo de trabalhos pendentes. Um alerta deve indicar uma condição que exija investigação, e não substituir a análise. Segmente por operação para evitar que um fluxo problemático fique oculto em uma média geral.
Revise os limites quando houver mudanças no volume, na experiência do produto, no tamanho das entradas ou na integração técnica. Não os flexibilize apenas para fazer um alerta desaparecer: primeiro identifique se o problema é uma expectativa mal definida, uma carga inesperada, uma falha de rede ou uma operação que precisa ser redesenhada.
Lista de verificação para produção
- Objetivo: a operação tem um caso de uso, uma pessoa usuária e uma alternativa caso a IA não responda.
- Medição: são registrados duração, frequência, resultado e custo estimado, sem coletar dados sensíveis desnecessários.
- Limites: existem limites adequados por solicitação e, quando pertinente, por usuário, processo e sistema.
- Comportamento: estão definidas as novas tentativas, o cancelamento, a fila e a resposta para cada limite.
- Experiência: os status e as mensagens distinguem espera, rejeição por limite e falha do serviço.
- Operação: há testes, alertas e uma pessoa ou equipe responsável por revisar os limites.
Controlar o custo e a latência de IA no PHP não consiste em escolher um único tempo limite para toda a aplicação. Consiste em vincular cada limite a uma necessidade específica, medir seu impacto e decidir antecipadamente qual alternativa mantém o produto compreensível e seguro quando a função não pode ser concluída.
