Dejamos de preguntarnos "¿cuál es el mejor modelo?"

GPT-6 salió la semana pasada. Un 99,9% en ARC-AGI-3, un 98% en el nivel más alto de FrontierMath, "la era de la AGI" en boca de su presidente. Benchmarks saturados, titulares saturados. Y en el índice independiente de Artificial Analysis, que no lo evalúa el propio fabricante, empata con su predecesor.

No escribo esto para discutir si GPT-6 es bueno. Seguramente lo es. Lo escribo porque la semana del lanzamiento me di cuenta de que en VibePeak hace meses que nadie pregunta "¿cuál es el mejor modelo?". Ni de texto, ni de imagen, ni de vídeo. La pregunta desapareció de nuestras conversaciones sin que nadie la prohibiera, y creo que merece la pena explicar por qué.

Lo que hacemos y por qué esto nos toca de cerca

Generamos vídeo inmobiliario. Una inmobiliaria sube las fotos de un piso y nosotros devolvemos un vídeo narrado, con movimiento de cámara, personas en escena si toca, subtítulos y música. Para eso pasan cada semana miles de imágenes y clips por varios modelos de imagen y de vídeo, de varios proveedores. Uno de los modelos que usábamos en producción ya no está. Otro entró hace poco. Y en el laboratorio interno hay siempre dos o tres candidatos esperando.

Es decir: elegir modelos es nuestro trabajo. Cada semana. Con dinero real. Y nada de lo que hemos aprendido haciéndolo aparece en una tabla comparativa.

"Calidad" son cinco ejes, y se pelean entre sí

Cuando alguien pregunta cuál es el mejor modelo, casi siempre está preguntando por calidad visual. Es la más fácil de ver y la más fácil de enseñar en un vídeo de lanzamiento.

Nosotros medimos cinco cosas: calidad visual, adherencia al prompt, velocidad, coste y consistencia. Ningún modelo gana las cinco. Ni siquiera hemos encontrado uno que gane cuatro.

El ejemplo que mejor lo ilustra es el modelo que usamos cuando hay personas en la imagen. Es el que mejor las mueve: gestos naturales, nadie atraviesa una pared, las manos siguen siendo manos. Por eso está en producción. Pero también es el que, con el mismo prompt, en la misma habitación, un día devuelve un clip con seis veces más movimiento que otro. Lo medimos en un mismo proyecto: dos escenas de la misma piscina, prompt idéntico byte a byte, una con las dos personas congeladas durante cinco segundos y la otra con movimiento normal.

Eso no es un fallo del modelo. Es un modelo estocástico haciendo lo que hacen los modelos estocásticos. Pero en un benchmark sale como una media, y una media de 0,45 no te dice que uno de cada sesenta clips va a salir a 0,04. Ese es el clip que el cliente va a ver, y por el que va a escribir a soporte.

La consistencia no se mide con una generación. Se mide con sesenta.

Muchas veces el modelo no era el problema. Éramos nosotros

Esta me duele un poco.

Durante bastante tiempo tuvimos un defecto visible en uno de nuestros productos: cuando una escena narrada duraba más de cinco segundos, el clip de vídeo se movía y luego se quedaba congelado en el último frame el resto de la escena. Movimiento, y luego una foto fija. Se veía. Los clientes lo veían.

La explicación que circulaba internamente era que el modelo de vídeo "solo genera cinco segundos". Con esa explicación llegamos a redactar una especificación para migrar a la versión siguiente del mismo modelo, que sí permitía duraciones más largas. Una migración de varias semanas, justificada por una limitación.

Cuando fuimos a verificar la limitación antes de empezar, resultó que no existía. El modelo aceptaba un parámetro de duración con valores de 5, 10 y 15 segundos. Nosotros nunca lo enviábamos. Nuestro cliente HTTP mandaba imagen, prompt, prompt negativo y relación de aspecto. Ni un campo más. Otro equipo de la casa, en una herramienta interna, sí lo enviaba desde el principio.

Un campo. Ningún benchmark del mundo te dice que te falta un campo.

Lo interesante es lo que pasó después. Al añadir el campo descubrimos que el proveedor factura la duración redondeada hacia arriba: una escena de 6,8 segundos se genera como 10 y se paga como 10. El doble. Así que la migración a la versión nueva sí tenía sentido, pero por un motivo completamente distinto al que habíamos escrito: la versión nueva factura por segundo. No era una cuestión de capacidad. Era una cuestión de granularidad de facturación. Si hubiéramos migrado por el motivo equivocado, habríamos acertado por casualidad y no habríamos aprendido nada.

Los límites de la API pesan más que el modelo

Cuando generamos clips con personas, mandamos un prompt negativo largo: nada de multitudes, nada de gente de fondo, nada de extremidades duplicadas, nada de saltos, nada de morphing. Es la lista de todo lo que ha salido mal alguna vez. Tenía 949 caracteres y cada línea estaba ahí por un ticket concreto.

Un proveedor corta el prompt negativo a 500 caracteres. Sin error, sin aviso, sin línea en el log. Lo descubrimos leyendo el JSON que el proveedor nos devolvía al consultar el estado del trabajo: el prompt negativo terminaba a mitad de palabra, exactamente en el carácter 500.

El 47% de nuestras barreras llevaba semanas sin llegar al modelo. Y no cualquier 47%: la lista está ordenada, y las últimas líneas eran precisamente las que prohibían multitudes y deformaciones. Las que más nos importaban. Nuestro código tenía comentarios explicando que esas líneas evitaban una serie de bugs concretos. Los comentarios eran verdad. Las líneas no llegaban.

Aquí la lección no es "el proveedor X es malo". El límite de 500 caracteres es una decisión razonable de su API. La lección es que la adherencia al prompt, ese eje que aparece en todas las comparativas, está acotada por cosas que la comparativa no mide: el límite de caracteres, cómo se trunca, si te avisa. Un modelo con mejor adherencia teórica al que le llega la mitad de tu prompt es peor, en producción, que uno mediocre al que le llega entero.

El coste es una decisión de producto, no una línea de factura

En junio nuestra factura de generación de imágenes se multiplicó por 8,5 en dos semanas. Mismo volumen: unas 2.500 imágenes al día. Lo que cambió fue que el pipeline de home staging pasó de la versión rápida de nuestro modelo de imagen a la versión "pro" con salida 2K, el mismo día que sacamos a producción un selector de resolución.

La versión pro es mejor. Las imágenes tienen más detalle, aguantan mejor un zoom, el texto de un cartel se lee. Nadie discutió eso.

Lo que discutimos, y seguimos discutiendo, es dónde merece la pena. Las previsualizaciones interactivas del editor, que el usuario regenera cinco o seis veces hasta que le gusta el sofá, no necesitan 2K. Las exportaciones finales quizá sí. Volvimos a la versión rápida en todos los caminos y dejamos abierta la pregunta de las exportaciones.

Y una nota de servicio para quien vaya por el mismo camino: la versión rápida de nuestro modelo ignora el parámetro de tamaño de imagen sin quejarse. Le pides 2K, te devuelve 1 megapíxel, no hay error. Otra cosa que no sale en la tabla.

Esa discusión de dónde va cada versión es una discusión de producto. Cuánto vale un píxel de más para un cliente que va a ver el vídeo en el móvil. Ningún benchmark la responde, porque ningún benchmark sabe cuánto cobras.

La velocidad es un presupuesto, no una métrica

Todos nuestros pipelines tienen cascadas: si el proveedor A falla, prueba el B; si el B falla, prueba el C. En el diagrama de arquitectura queda muy bien.

En producción medimos una cosa distinta. El proveedor principal de imágenes responde en menos de un segundo cuando rechaza una petición. El segundo de la cascada tarda unos 50 segundos de media en acertar. Y el tercero, cuando le llega el turno, hereda lo que queda del presupuesto total de la petición: unos 38 segundos. El tercero necesita 41 segundos de media para producir algo. En diez días lo intentó 63 veces y acertó 12.

El tercer proveedor de la cascada es, a efectos prácticos, código muerto. No porque sea lento. Porque llega tarde.

En vídeo pasa algo parecido pero peor. Un clip que tarda más de 600 segundos no falla: el sistema lo da por perdido, la escena se degrada silenciosamente a una foto con un zoom lento, el vídeo se marca como terminado y nadie se entera hasta que el cliente pregunta por qué una escena de trece no se mueve. El 11% de nuestros clips supera los 600 segundos.

Nada de esto aparece en "tiempo medio de generación: 84 segundos". La velocidad de un modelo solo tiene sentido dentro del presupuesto de tiempo de la operación completa, con lo que consume cada paso anterior y con lo que pasa cuando se agota.

Lo que hacemos en lugar de mirar benchmarks

Hacemos benchmarks de producción. Son mucho menos vistosos.

Para el problema de los clips congelados, el proceso fue este. Tomamos sesenta clips reales de producción de los últimos cuatro días, todos del mismo tipo de escena. A cada uno le calculamos un número: la energía de movimiento, que es la media de la diferencia de luminancia entre frames consecutivos. Un comando de ffmpeg, nada más.

La distribución salió así: mínimo 0,110; mediana 0,449; máximo 1,42. El clip por el que se había quejado el cliente daba 0,040. Casi tres veces por debajo del mínimo de producción, once veces por debajo de la mediana.

Con eso pusimos un umbral en 0,08: detecta el clip malo y dispara cero falsos positivos sobre los sesenta reales. Medido, no adivinado. Y ese umbral es ahora nuestro benchmark para cualquier modelo de vídeo candidato: si en el mismo tipo de escena produce clips por debajo de 0,08 con más frecuencia que el actual, no entra, aunque sus vídeos de demostración sean más bonitos.

Lo mismo con el coste: tenemos un catálogo interno con el precio por segundo o por imagen de cada modelo que probamos, y cada candidato se compara contra el coste actual por vídeo terminado, no contra un precio de lista. Y lo mismo con la velocidad: cada modelo tiene un p90 medido en nuestra carga, y ese p90 es el que entra en el cálculo del presupuesto de la cascada.

Un modelo nuevo entra cuando mejora nuestro número, a nuestro coste, con nuestra latencia. Si no, da igual lo que diga la tabla.

Volviendo a GPT-6

GPT-6 será mejor en algo que te importe a ti. A lo mejor en tu caso de uso es una mejora enorme. No lo sé, y ese es exactamente el punto: no lo sé, y una tabla de benchmarks generales tampoco lo sabe.

La pregunta "¿cuál es el mejor modelo?" tiene un defecto de fábrica: presupone que existe una respuesta independiente del uso. Para nosotros no existe. El mejor modelo para mover a dos personas en una piscina no es el mejor para hacer un travelling por un pasillo vacío, que no es el mejor para poner un sofá en un salón, que no es el mejor para escribir el guion de la locución. Y el mejor de cada uno cambia si le quitas 30 segundos de presupuesto o si la factura se multiplica por ocho.

La conversación útil es otra. ¿Mejor para qué plano? ¿A qué precio por vídeo terminado? ¿Con cuánta varianza entre generaciones? ¿Con qué límites de API que nadie documenta? ¿Qué pasa cuando tarda más de la cuenta?

Cambiar la conversación de benchmarks generales a benchmarks específicos de producción es más aburrido. Requiere ffmpeg, hojas de cálculo y leer JSON de respuesta a las once de la noche. Pero es la única forma que hemos encontrado de que un modelo nuevo sea una decisión y no una apuesta.