Elige un LLM de producción con una evaluación de 6 puntos

El equilibrio en la selección de LLM es la calidad frente al coste, la latencia de cola y la cola de fallos. Antes de decir que un modelo es mejor, escribe la aritmética: ganancia de calidad ÷ (aumento de coste + penalización de latencia + riesgo a la baja). Si el numerador es pequeño y el denominador es grande, el modelo no está listo para producción. Una pregunta útil para la selección de modelos de producción es qué modelo y configuración de razonamiento cumple las tolerancias de calidad, coste, velocidad, consistencia y tasa de fallos.

Costes

El coste no es el precio de etiqueta. Es el gasto esperado por salida útil. Registra el precio en dólares de EE. UU. por mil tokens, la longitud de entrada esperada, la longitud de salida esperada, la tasa de reintentos y la tasa de respaldo. Un modelo más barato por token pero que produce salidas más largas, necesita más reintentos o activa más respaldos puede ser más caro por tarea completada.

No trates un mayor esfuerzo de razonamiento como un control de calidad. Aumentar el esfuerzo de razonamiento no es un control de calidad fiable y puede aumentar el coste o reducir las puntuaciones.

Construye un modelo de costes con tres columnas: coste de entrada, coste de salida y coste de fallo. El coste de fallo incluye reintentos, revisión humana, tickets de soporte y tiempo de usuario perdido. Cuando finanzas pregunta por qué la función de IA es cara, esta tabla es la respuesta.

Al presentar a finanzas, separa el coste variable del coste fijo. El coste variable cambia con el tráfico, la longitud de salida y los reintentos. El coste fijo incluye tarifas de plataforma, monitoreo y mantenimiento. Un modelo puede parecer barato en una demo y volverse caro cuando la función la usan muchos usuarios o cuando la longitud de la respuesta crece. La ficha de puntuación debería forzar esa comparación antes de seleccionar el modelo.

Modelos

El mejor LLM para producción es el que sobrevive a una ficha de puntuación específica de la tarea. Usa seis campos: task_fit, eval_score, p95_latency_ms, coste por mil tokens, license_risk y fallback_success_rate. Un método de selección puede comparar puntuación, coste, tiempo y consistencia del riesgo a la baja usando una frontera.

El ajuste a la tarea es si la forma de la salida del modelo coincide con el producto: clasificación, extracción, resumen, código, llamadas a herramientas o JSON estructurado. Un modelo puede puntuar bien en una prueba de referencia genérica y aun así fallar tu esquema. La puntuación de evaluación debe provenir de un pequeño conjunto de evaluación construido con ejemplos similares a producción, no solo de pruebas de referencia públicas de LLM. Puntúa cada candidato con la misma rúbrica, los mismos prompts, la misma temperatura, los mismos tokens máximos y el mismo timeout.

La consistencia y el riesgo a la baja deben formar parte de la evaluación del modelo porque una mediana fuerte puede ocultar salidas ocasionales débiles.

El riesgo de licencia es un criterio de política, no una prueba de referencia. Registra si el modelo permite uso comercial, retención de datos, ajuste fino, redistribución y auditoría. Si seguridad o legal dice que no, el modelo queda descartado sin importar la puntuación.

Haz la evaluación reproducible. Almacena el prompt, la respuesta, la puntuación, la latencia, el recuento de tokens y la etiqueta de fallo. Si un candidato mejora después de ajustar el prompt, registra el prompt ajustado como parte del candidato. Un modelo más prompt más configuración es la unidad de producción, no solo el nombre del modelo.

Servicio

El servicio determina si el modelo es alcanzable, observable y recuperable. Las plataformas de gateway son opciones orientadas a empresas para centralizar el acceso a LLM, aplicar políticas de seguridad, gestionar el cumplimiento y supervisar el uso.

La latencia y la salida de tokens son restricciones medibles al evaluar gateways de LLM. Registra la latencia del primer token y la latencia total, pero también la longitud de la respuesta devuelta. Un primer token rápido no es una respuesta rápida si el modelo transmite una respuesta larga y de bajo valor. Para funciones orientadas al usuario, la latencia p95 es el número que importa.

El comportamiento de respaldo es la última línea de defensa. Define qué ocurre ante un timeout, un error del proveedor, un bloqueo de política, un fallo de esquema o baja confianza. Un respaldo puede ser un modelo más pequeño, una respuesta en caché, una respuesta basada en reglas o una transferencia a un humano. Mide fallback_success_rate como la proporción de solicitudes degradadas que aún devuelven una respuesta utilizable.

Los equipos de fiabilidad necesitan un runbook, no una esperanza. Para cada modo de fallo, define la señal de detección, la acción de respaldo, el mensaje visible para el usuario y la ruta de escalado. Si una interrupción del proveedor es común, el respaldo debe probarse en staging con tráfico realista. Si el respaldo es una transferencia a un humano, define la cola y la ventana de respuesta. El objetivo es mantener la función útil cuando el modelo principal no lo es.

Ejecuta la selección en cuatro pasos. Primero, lista las tolerancias del flujo de trabajo para calidad, coste, velocidad, consistencia y tasa de fallos. Segundo, puntúa cada candidato en los seis campos. Tercero, calcula el riesgo a la baja y elimina los candidatos que no cumplen la tolerancia. Cuarto, conserva solo los candidatos no dominados y elige el de menor riesgo operativo. El modelo que despliegues debe ser el más difícil de refutar, no el que mejor se ve en una demo.