Una función de inteligencia artificial puede ser útil y, aun así, resultar demasiado lenta o costosa para una operación concreta. El riesgo aparece cuando se trata cada llamada como si tuviera las mismas necesidades: resumir un texto en segundo plano no tiene el mismo impacto que responder una consulta durante el pago. Para controlar coste y latencia de IA en PHP, conviene definir un presupuesto operativo para cada caso de uso y decidir de antemano qué ocurrirá cuando se alcance.
Ese presupuesto no es una promesa de calidad ni una garantía de que el proveedor responderá dentro de un plazo. Es un conjunto de límites y decisiones de producto que permite contener el impacto, informar al usuario y mantener el comportamiento de la aplicación bajo control.
Un presupuesto distinto para cada operación
Un presupuesto operativo reúne los recursos que una función puede consumir y el tiempo durante el que tiene sentido esperar. Puede incluir un máximo de duración, un límite de gasto estimado, un número de intentos, una cantidad de texto procesado o una combinación de estos controles. Debe estar vinculado a una operación reconocible en el producto, no ser una configuración abstracta compartida por todas las llamadas.
Por ejemplo, una sugerencia opcional dentro de un panel puede tolerar que el sistema la omita si tarda demasiado. En cambio, si una función forma parte de un proceso esencial, quizá haya que ofrecer una alternativa que permita completar el flujo sin IA. Un trabajo de clasificación por lotes puede aceptar una cola y un estado pendiente, mientras que una respuesta interactiva necesita un límite de espera más estricto.
Para escoger los límites, aclara primero qué resultado necesita el usuario, si es imprescindible en ese momento y qué ocurre si no está disponible. También separa el presupuesto de la evaluación de calidad: una respuesta rápida y barata puede ser incorrecta, y una respuesta correcta puede llegar demasiado tarde para ser útil. Ambos aspectos requieren medidas y criterios propios.
Medir antes de fijar los umbrales
Sin una línea base, los límites son conjeturas. Registra métricas por tipo de operación y observa cómo varían con el volumen, el tamaño de la entrada y las condiciones de uso. Como mínimo, conviene medir duración total, tiempo hasta el primer resultado útil cuando aplique, frecuencia de uso y coste estimado. Para las operaciones asíncronas, registra también el tiempo en cola y el tiempo de procesamiento.
Asocia cada medición a un identificador de operación, un resultado y datos de contexto no sensibles, como el tamaño aproximado de la solicitud o el modo de ejecución. Evita guardar el texto del usuario, secretos, información personal o respuestas completas si no son necesarios para diagnosticar. Cuando haga falta investigar un caso, aplica controles de acceso, retención y minimización adecuados.
El coste estimado debe basarse en la información disponible para el servicio utilizado y reflejar sus límites. No lo confundas con un cargo confirmado: precios, unidades contabilizadas y componentes facturables pueden variar. Si la aplicación no puede calcular un coste fiable antes de la llamada, usa controles alternativos como límites de frecuencia, tamaño máximo, cuotas por usuario o gasto agregado monitorizado.
Convertir el presupuesto en límites verificables
Define dónde se aplica cada control. Un límite por solicitud evita que una ejecución individual se prolongue o consuma demasiado. Una cuota por usuario o cuenta limita el uso repetido. Un tope por proceso protege una tarea que agrupa varias operaciones. Para controlar el gasto global, monitoriza además el consumo agregado; un límite individual no impide que muchas solicitudes simultáneas excedan el presupuesto del sistema.
Decide también cómo se comportan los reintentos. Repetir automáticamente una solicitud puede duplicar coste o empeorar la latencia, especialmente si no se sabe si el servicio llegó a procesar la petición. Define cuántos intentos se permiten, ante qué errores y con qué espera. Usa claves de idempotencia cuando sean compatibles y relevantes para evitar efectos duplicados en operaciones que modifican datos.
Al agotarse un umbral, las opciones incluyen detener la solicitud, reducir su alcance, diferirla a una cola o derivarla a revisión humana. La elección depende del caso de uso. Una respuesta parcial sólo es aceptable si la interfaz la identifica claramente y el resultado sigue siendo seguro y útil. Si la tarea es sensible o no admite resultados incompletos, puede ser preferible no mostrar una respuesta generada.
Aplicar los controles en una capa de integración PHP
Centraliza las llamadas externas en una capa de integración que reciba la operación y su presupuesto, aplique los controles correspondientes y devuelva un resultado explícito. Así, la lógica de negocio no depende directamente de un proveedor ni interpreta de forma distinta los tiempos de espera y errores en cada punto de la aplicación.
El siguiente fragmento requiere PHP 8.0 o posterior, porque utiliza propiedades promovidas en el constructor y argumentos con nombre. Es un ejemplo parcial: valida el tamaño de entrada y pasa un tiempo de espera al cliente, pero no implementa cuotas, límites de gasto ni una cola. Estos controles deben añadirse por separado según las necesidades de la aplicación.
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');
}
}El cliente y las excepciones dependen de la integración elegida. En producción, configura el límite de tiempo también en el cliente HTTP y valida el tamaño antes de enviar datos. El estado timed_out indica que la solicitud agotó el tiempo de espera; no significa que se haya encolado ni que vaya a continuar. Devuelve un estado deferred sólo si la aplicación ha guardado la tarea en una cola y dispone de un proceso que pueda reanudarla y comunicar su resultado.
Para completar la capa de control, aplica límites de frecuencia o cuotas con un contador coordinado entre procesos y monitoriza el gasto agregado. Si necesitas imponer un tope de coste antes de cada llamada, calcula el consumo estimado de la solicitud y compáralo con el presupuesto disponible; si no es posible estimarlo con fiabilidad, usa límites alternativos y alertas de consumo. Las cuotas compartidas no deberían depender sólo de la memoria de una petición PHP.
Devuelve estados diferenciados, como completado, rechazado por límite, agotado el tiempo de espera o no disponible. Esto permite que la capa de negocio decida qué mostrar sin confundir una respuesta lenta con una respuesta de mala calidad, ni un límite operativo con un fallo del proveedor.
Diseñar una degradación clara y útil
Degradar no significa ocultar un error ni presentar un resultado alternativo como si fuera equivalente. Significa conservar una experiencia comprensible cuando la función no puede completar su trabajo. En una acción opcional, puede bastar con indicar que la sugerencia no está disponible y permitir continuar. Para una tarea larga, muestra que está pendiente y ofrece un estado consultable, siempre que la aplicación pueda mantenerlo de forma fiable.
Si se puede reducir el alcance, explica qué se ha omitido. Si se deriva a revisión, no sugieras que el resultado ya está validado. Y si se usa una alternativa determinista, como una regla de negocio existente, aclara su función cuando la diferencia afecte a la decisión del usuario. Evita mensajes que prometan una entrega posterior si no hay una cola y un proceso capaces de cumplirla.
El fallback ante fallos es distinto del control de presupuesto: se activa ante situaciones como indisponibilidad, errores de red o respuestas inválidas. El presupuesto puede agotarse aunque el servicio funcione correctamente. Ambos mecanismos deben definirse y probarse por separado, con estados y mensajes adecuados a cada causa.
Probar, alertar y ajustar con evidencia
Prueba los umbrales con cargas representativas y escenarios adversos: entradas grandes, solicitudes repetidas, respuestas lentas, concurrencia, errores del proveedor y límites de cuota. Comprueba qué ve el usuario y qué queda registrado. Incluye casos de cancelación y verifica que una solicitud detenida no siga consumiendo recursos en segundo plano sin necesidad.
Configura alertas para anomalías operativas: aumento de latencia, más solicitudes rechazadas, crecimiento del gasto estimado o acumulación de trabajos pendientes. Una alerta debe señalar una condición que requiera investigar, no sustituir el análisis. Segmenta por operación para evitar que un flujo problemático quede escondido en una media general.
Revisa los límites cuando cambien el volumen, la experiencia de producto, el tamaño de las entradas o la integración técnica. No los relajes sólo para hacer desaparecer una alerta: primero identifica si el problema es una expectativa mal definida, una carga inesperada, un fallo de red o una operación que necesita rediseño.
Lista de comprobación para producción
- Propósito: la operación tiene un caso de uso, una persona usuaria y una alternativa si la IA no responde.
- Medición: se registran duración, frecuencia, resultado y coste estimado sin recopilar datos sensibles innecesarios.
- Límites: existen topes adecuados por solicitud y, cuando corresponde, por usuario, proceso y sistema.
- Comportamiento: están definidos los reintentos, la cancelación, la cola y la respuesta ante cada umbral.
- Experiencia: los estados y mensajes distinguen entre espera, rechazo por límite y fallo del servicio.
- Operación: hay pruebas, alertas y una persona o equipo responsable de revisar los límites.
Controlar coste y latencia de IA en PHP no consiste en escoger un único tiempo de espera para toda la aplicación. Consiste en vincular cada límite con una necesidad concreta, medir su impacto y decidir de antemano qué alternativa mantiene el producto comprensible y seguro cuando la función no puede completarse.
