La mayoría de benchmarks de modelos sirven de poco en el momento en que tienes que tomar una decisión de producto.
Se ejecutaron desde la cuenta de otro, por otro proveedor, en otro sitio del mundo y con un prompt que tú no vas a mandar nunca. Luego una gráfica de colores te dice qué modelo «ganó».
Está bien si te gustan las gráficas. No basta si tienes que decidir qué mueve un chat, un agente, un flujo de código o un producto que tiene que portarse bien un lunes por la mañana.
Por eso PAELLADOC ya tiene su propio módulo de benchmarks de inferencia.
Lanza campañas controladas contra las rutas que tienes configuradas en tu Mac y guarda el resultado en local: workload, endpoint, parámetros, entorno, qué volvió, cuánto tardó y si falló.
No es un leaderboard de modelos. Es una forma de ver qué está haciendo tu stack.
Por qué hacía falta
«Rápido» es una palabra bastante inútil cuando hablas de la respuesta de una IA.
Un modelo puede empezar a contestar en un segundo y tardar dos minutos en acabar. Otro puede dejar al usuario mirando un mensaje vacío medio minuto y después escribir a buen ritmo. Un tercero puede ir bien hasta que le metes 100K tokens o lanzas diez peticiones a la vez.
Son problemas distintos. Hasta ahora era demasiado fácil aplastarlos en una sensación: esta ruta parece lenta; esta se siente bien; este proveedor fue inestable la semana pasada.
El módulo nuevo convierte esa sensación en una campaña que puedes mirar después.
Qué guarda una campaña
Eliges un workload controlado y una ruta. PAELLADOC crea las muestras, las ejecuta y conserva el contexto de la medición.
Los workloads controlados cubren 1K, 10K y 100K de contexto de texto, además de visión. Puedes lanzar una sola petición o un escenario en paralelo. Importa porque un modelo que parece correcto con una petición corta y tranquila se puede comportar de otra forma con contexto grande o concurrencia.
En cada ejecución se guardan las cosas que de verdad notas:
- cuándo llegó el primer token;
- cuándo llegó la primera respuesta utilizable;
- a qué velocidad generó salida una vez arrancó el streaming;
- cuándo llegó la respuesta completa;
- los tokens que reportó el proveedor;
- reintentos, fallos y muestras incompletas.
También se conserva la ruta detrás del número: proveedor, endpoint, tipo de cuenta, identidad de modelo, parámetros, entorno del cliente y protocolo de benchmark. Si faltan esos detalles o la identidad del modelo no es fiable, PAELLADOC puede ocultar el rendimiento en vez de enseñar un número limpio que no se debería comparar.
Esa última parte no es decoración. Es la diferencia entre medir una ruta e inventarte una liga.
Las primeras campañas ya han demostrado el porqué
He empezado a usar el módulo con las primeras campañas de 10K y 100K. Los datos todavía son pequeños y no están para convertirlos en claims grandilocuentes. Precisamente por eso el módulo sirve.
Una ruta de 10K empezó a mostrar texto aproximadamente al segundo. Otra tardó más de treinta segundos en soltar el primer token visible. La segunda puede ser útil para el trabajo adecuado; simplemente no es la que pondría detrás de un chat donde hay una persona esperando.
Las ejecuciones de 100K en paralelo son todavía más reveladoras. Algunas muestras han terminado, otras han fallado y otras aún no están en estado terminal. La salida correcta no es una gráfica de velocidad escogida a mano. Es una campaña incompleta con los fallos pegados.
Eso es lo que quería que hiciera el módulo: avisarme de cuándo todavía no tengo evidencia suficiente.
Para qué sirve
Esto no pretende decirte qué modelo es «el mejor». Una prueba de latencia no sabe si el código es correcto, si un plan es bueno, si el modelo ha usado una herramienta con seguridad o si su política de datos encaja contigo.
Sí hace que la siguiente decisión deje de ser tan a ojo.
Si estás haciendo un flujo interactivo, mira la espera hasta el primer token. Si generas un documento largo en segundo plano, mira el tiempo hasta terminar. Si enrutas un agente por un repo grande, corre el workload que se parezca a ese trabajo. Si una ruta no es fiable, no escondas los fallos porque las muestras que salieron bien se vean rápidas.
Después llevas el resultado a la decisión grande: siguen importando calidad, coste, privacidad, disponibilidad y validación. Ese es el trabajo del routing de modelos. El módulo de benchmark le da a esa capa algo mejor que intuición.
Local por defecto, exportable cuando hace falta
Las campañas viven con el resto de los datos del proyecto en tu máquina. No son datos de entrenamiento para un ranking público compartido. Puedes inspeccionar una campaña en la app, exportar el informe en Markdown o usar el resultado estructurado en otro sitio.
Eso hace útil el módulo de dos maneras. Primero, contesta una pregunta práctica hoy: ¿qué ruta configurada debo usar para este tipo de trabajo? Segundo, deja registro de por qué esa elección tenía sentido entonces, para repetir la prueba cuando cambie un proveedor, modelo, cuenta o camino de red.
Qué viene ahora
El módulo acaba de empezar a recoger campañas reales. Lo siguiente no es sacar deprisa un leaderboard público a partir de unas pocas ejecuciones. Es construir historial suficiente para ver variación, fallos y cambios con el tiempo; y después conectar esos datos con calidad de tarea real.
Ahí es donde un benchmark se vuelve infraestructura de producto útil, en vez de otra página de opiniones sobre modelos.
PAELLADOC ya tiene el sitio para hacerlo.