VideoJev: un modelo de video que responde con un número en lugar de una oración

VideoJev es una familia de modelos de comprensión de vídeo que nunca escriben una respuesta. Pídele la marca temporal de un evento y devuelve un intervalo compuesto a partir de ranuras candidatas puntuadas; hazle una pregunta de opción múltiple sobre un vídeo y devuelve la opción con la puntuación más alta. Hay dos checkpoints publicados — VideoJev-4B sobre Qwen3.5-4B y VideoJev-35B-A3B sobre Qwen3.6-35B-A3B — y no se lanzaron. Nadie publicó un comunicado de prensa. Un artículo apareció en arXiv el 13 de octubre de 2026, los pesos se subieron a Hugging Face el 10 de octubre de 2026, y el repositorio seguía ordenándose cuatro días después: el 14 de octubre seguía recibiendo commits como «Restaurar el vídeo integrado del README con un archivo adjunto público» y «Añadir enlace al artículo de arXiv y la cita BibTeX oficial». Así se ve un lanzamiento silencioso: los artefactos son reales e inspeccionables, y no hay ningún anuncio que te diga qué consideran importante los autores.

Todo lo que sigue proviene de uno de estos tres lugares: el preprint de arXiv (2610.18615, cs.CV, enviado el 13 de octubre de 2026), las tarjetas de modelo y el código que publicaron los autores, y las propias notas al pie del artículo sobre cómo se midieron las cifras. He intentado mantener esos tres claramente separados, porque lo interesante de esta publicación no es la cifra titular — es lo poco sólido que es el terreno que hay bajo ella.

Lo que el artículo realmente afirma

VideoJev toma un LLM multimodal preentrenado, elimina el MLP final y la cabeza de salida del modelo de lenguaje, y coloca un puntuador de candidatos en su lugar. Dos tokens nuevos, <|option_end|> y <|decide|>, producen lecturas. El estado de decisión y cada estado de candidato se proyectan a 512 dimensiones, se normalizan y se calcula su producto punto; los intervalos temporales se puntúan con una sigmoide y se ensamblan en un span, las opciones de respuesta se puntúan y se normalizan con una softmax. Ambas tareas se ejecutan a través de la misma cabeza. Nada se decodifica de forma autorregresiva, porque no hay nada que decodificar.

Las tres cifras principales del artículo, todas reportadas por el proveedor y todas provenientes del propio entorno de evaluación de los autores:

• Calidad de grounding — VideoJev-4B alcanza un mIoU medio de 65,3 en tres benchmarks de grounding temporal, 6,7 puntos por encima de su backbone Qwen3.5-4B. VideoJev-35B-A3B alcanza 67,7, 10,8 puntos por encima de Qwen3.6-35B-A3B.

• Paridad de QA sin razonamiento — en cuatro benchmarks de QA de vídeo, los dos modelos se sitúan en una media de 74,3 y 79,5, 0,6 puntos por debajo y 0,7 puntos por encima de sus backbones en modo Thinking, respectivamente.

• Latencia — entre 2,8 y 3,1× más rápido que esos backbones en grounding, y más de 100× en QA. La cifra medida para QA es 129× en 4B y 100× en 35B-A3B.

El planteamiento honesto de la afirmación sobre la velocidad es que se trata de una comparación con un modelo de razonamiento que hace algo mucho más difícil de lo que la tarea requiere. Qwen3.5-4B en modo Thinking consume 144,9 segundos por pregunta en LVBench para obtener 74,9; VideoJev-4B tarda 1,123 segundos en obtener 74,3. El 129× es aritmética real sobre la propia tabla de latencia del artículo, y es la aritmética que se obtendría de cualquier modelo que se niegue a pensar. La pregunta interesante no es si la aceleración es real —es si se puede construir un sistema donde ese intercambio sea correcto.

El argumento que subyace: decisiones, no generaciones.

Donde esto se vuelve más interesante que una tabla de benchmark es en la afirmación arquitectónica. Los autores hicieron fine-tuning de un Qwen3.5-4B autorregresivo común con exactamente los mismos datos de post-entrenamiento, en la misma única etapa, con la misma configuración, y le hicieron generar intervalos o responder con letras. La Tabla 3 del artículo dice que VideoJev-4B supera a ese control por 1,3 puntos de mIoU de grounding medio y 1,9 puntos de puntuación media de QA. Ambos modelos recibieron una supervisión idéntica; solo difirió la forma de la lectura.

Si eso se sostiene, la ganancia no está en los datos ni en la escala — está en que pedirle a un modelo que emita una distribución de probabilidad sobre candidatos estructurados se ajusta mejor a una decisión estructurada que pedirle que produzca una cadena y luego analizar la cadena para volver a convertirla en una decisión. Esa es la misma apuesta que hizo TypeSafe con Jev 1.13 y su familia System One, generalizada de estados de texto a video. El artículo deja claro que se basa en esa línea de trabajo en lugar de inventar la categoría.

Dos detalles de implementación valen más que las cifras destacadas, porque son lo que lo hacen utilizable en lugar de simplemente rápido. Inferencia en caché codifica y prellena el vídeo una sola vez y permite que las consultas que van llegando se ramifiquen desde ese prefijo en caché: una pasada hacia delante por consulta. Inferencia conjunta coloca varias consultas tras un único prefijo de vídeo y lee un <|decide|> independiente para cada una, de modo que un grupo de preguntas cuesta una sola pasada hacia delante en total. En diez consultas de grounding sobre un vídeo, el artículo mide 0,39 s para VideoJev frente a 5,98 s para una línea base Instruct; en el lado de QA, diez consultas tardan 1,67 s. El artículo también comprueba el modo de fallo obvio de la inferencia conjunta —que una pregunta anterior filtre su respuesta a una posterior— e informa de que verificó que no se insertan respuestas de referencia ni predichas en el prefijo compartido. Cabe señalar que esta es la propia verificación de los autores, y que la inferencia conjunta puntúa mejor que el modo aislado en caché (65,3 frente a 64,5 mIoU en 4B), lo que atribuyen al entrenamiento con la misma disposición conjunta.

Lo que la tarjeta no te dice

Cuatro cosas brillan por su ausencia, y importan más que todo lo anterior si estás decidiendo si esto está listo para producción.

• Los datos de entrenamiento no se divulgan. El repositorio documenta el formato y te ofrece las herramientas para construir tu propio JSONL, pero no se indican el corpus, su tamaño ni su procedencia. No puedes evaluar la contaminación frente a los siete benchmarks sobre los que reporta.

• Los pesos de 35B comienzan en FP32. La página del proyecto indica FP32 para Cached y BF16 para Joint, por lo que la configuración principal del modelo más grande es la que tiene mayor consumo de memoria, y la página no ofrece una cifra de VRAM para ninguna de las dos.

• La confianza es demasiado confiada. El artículo reporta un error de calibración medio de 8.65 puntos para 4B y 8.13 para 35B-A3B. La puntuación es una señal de clasificación utilizable, no una probabilidad a partir de la cual debas ramificar sin un umbral que hayas ajustado tú mismo.

• Nadie ha hecho los cálculos de forma independiente. Todas las cifras que aparecen aquí proceden del grupo que entrenó los modelos. A día de hoy no existe replicación por parte de terceros, ni entrada en ninguna clasificación, ni ha llegado soporte de frameworks — la ruta de inferencia es trust_remote_code=True sobre una arquitectura personalizada, que requiere como mínimo PyTorch 2.8/CUDA 12.8 y FlashAttention 2.

Ese último punto también se extiende al modelo más pequeño, y va en contra de la suposición obvia. VideoJev-4B es el que uno esperaría ejecutar en hardware modesto, y el propio inicio rápido de la tarjeta asume una H200 a 2 fps con hasta 2,048 fotogramas. Hay una demostración más barata —un clip de diez segundos, diez intervalos candidatos, probabilidades impresas—, pero los resultados de video largo del artículo usan un contexto fijo de 262,144 tokens con fotogramas limitados a 640×640. El 4B es pequeño en parámetros, no necesariamente en costo de servicio.

Probarlo sin apostar por ello

Como los checkpoints son lo que realmente existe, la vía de entrada de bajo riesgo es ejecutar VideoJev localmente con tus propias grabaciones antes de construir nada sobre él: la ruta de la demo es una descarga y una docena de líneas, y los casos de fallo que el propio artículo documenta (conteo de objetos pequeños en Video-MME, donde ambos tamaños pasan por alto una respuesta de cuatro libros) son exactamente los que quieres encontrarte en tus datos y no en Charades. VideoJev-4B y VideoJev-35B-A3B están bajo Apache-2.0, así que nada te detiene.

Dónde encaja OrcaRouter es la otra mitad del flujo de trabajo. Una interfaz de decisión de vídeo es rara por sí sola; lo habitual es un pipeline que además necesita un modelo generativo que escriba el resumen, un clasificador barato que controle la llamada costosa, y algo que enrute entre ellos. OrcaRouter pone más de 200 modelos tras una sola API con 0 % de margen — el precio de lista del proveedor se traslada tal cual, de modo que una bajada de precio de un proveedor está activa aquí el mismo día — con conmutación automática en caso de fallo entre proveedores, un DSL de enrutamiento para componer varios modelos en una sola llamada, y fusión de modelos para paneles. Ningún checkpoint de VideoJev está alojado aquí, y este artículo no va a fingir lo contrario; los dos lugares donde se gana su sitio son como segundo tramo de un pipeline cuyo primer tramo es un modelo local, y como la razón por la que un modelo de investigación como este se puede probar sin un segundo contrato con un proveedor para todo lo que lo rodea.

¿Qué haría que esto fuera una historia más grande?

El punto de control de este artículo es inusualmente claro, así que vale la pena decirlo sin rodeos: VideoJev es una versión de investigación, no el lanzamiento de un producto. No hay registro de cambios, ni página de precios, ni endpoint alojado, ni lista de espera, ni publicación en el blog del proveedor. Lo que existe es un preprint enviado el 13 de octubre de 2026, dos checkpoints Apache-2.0 subidos el 10 de octubre, y un repositorio que todavía se estaba editando el 14 de octubre — el día anterior a este artículo. La ausencia de un anuncio no es prueba de un problema, pero sí significa que el planteamiento tiene que ser "lo que dicen los artefactos", no "lo que afirma el proveedor".

Tres desarrollos cambiarían la forma de esto. Una evaluación de terceros que reprodujera las ganancias de +6,7 y +10,8 mIoU frente a los mismos backbones bajo el mismo protocolo. Una implementación en vLLM o SGLang, que lo llevaría de ser una curiosidad con trust_remote_code a algo que se puede servir con buen rendimiento. O un endpoint alojado de alguien, que haría que la afirmación de 100× fuera un número que puedes medir en tu propio vídeo en lugar de uno que tomas de una tabla en la página seis. Hasta que llegue uno de esos desarrollos, la postura útil es la que adopta el propio artículo: la interfaz de puntuación directa es una forma genuinamente diferente de construir un agente de vídeo, y la evidencia a su favor es actualmente el preprint de nueve páginas de un solo grupo.

Mantén abierto el notebook de demostración, ejecútalo con el metraje menos favorecedor que tengas y trata las puntuaciones de confianza como una clasificación hasta que las hayas calibrado tú mismo.

Un lanzamiento también es el momento de revisar lo que ha salido mal antes: los incidentes documentados de IA y los fallos de agentes relacionados con modelos de esta clase se recopilan en el OrcaRouter AI Incident Archive, donde cada entrada incluye sus propias fuentes, severidad, grado de confianza e indicador de disputa.