RSI-Jev vs Jev 1.13: Uno que descargas, uno al que llamas

Ponga RSI-Jev v6.1-VL 4B y Jev 1.13uno al lado del otro y lo primero que nota quien llama es que se trata de la misma solicitud. Entregue a cualquiera de los dos un estado y un conjunto de preguntas tipadas —un sí/no, una elección de una entre k opciones, una calificación según una rúbrica— y ambos devuelven una probabilidad calibrada para cada opción, en una sola pasada forward, sin texto generado que haya que analizar. Eso no es una coincidencia: RSI-Jev está diseñado deliberadamente para hablar el formato de comunicación de Jev, de modo que un cliente escrito contra la API de TypeSafe funciona contra él con solo cambiar la URL base. Lo que no es igual es todo lo que rodea a la llamada. Jev 1.13 es el modelo comercial cerrado de TypeSafe, servido desde un endpoint cuyo uso se mide; RSI-Jev v6.1-VL es un checkpoint de 4,69B parámetros con pesos bajo Apache-2.0 que usted descarga y sirve en su propio hardware. Ninguno de los dos es una marca renombrada del otro, ningún proveedor respalda al otro, y casi todas las cifras de esta comparación provienen de la parte que las produjo.

La fecha en el asunto importa, porque este proyecto publica una versión aproximadamente cada día. RSI-Jev v6.1-VL 4B se publicó el 2026-10-07 por el proyecto de terceros Shanghua-Gao/RSI-Jev — un bucle de investigación automejorable que entrena modelos de decisión estilo Jev y publica cada brazo que falló junto con los que ganaron. Es la octava versión en trece días en esa línea, y es un promedio ponderado de pesos de la versión anterior con un segundo ajuste fino del mismo Qwen3.5-4B-Base. Jev 1.13 es el modelo de TypeSafe AI, lanzado el 2026-09-15 y presente en nuestro propio catálogo desde el 2026-09-24. Ambas fechas importan a continuación, porque una comparación con un proyecto que avanza a diario tiene una vida útil medida en días.

Qué son en realidad los dos, en una línea cada uno

Jev 1.13 es un modelo de decisión alojado detrás de un endpoint dedicado — POST /v1/systemone, no streaming, con aproximadamente 64,000 tokens de presupuesto de entrada entre el estado y todas tus preguntas juntas, con un precio de $0.042 por millón de tokens de entrada y la salida facturada a cero porque no hay tokens de salida. Su arquitectura, número de parámetros y cómputo de entrenamiento no se revelan; TypeSafe ha dicho que los detalles se mantienen en reserva y que puede seguir un artículo. No lo ejecutas. Lo llamas, y cada llamada es una solicitud de red medida.

RSI-Jev v6.1-VL es la otra configuración completa. Es una torre Qwen3.5-4B-Base ajustada de extremo a extremo, con cabezas de decisión en las capas 16, 20 y 32, servida desde un checkpoint autocontenido de 9,7 GB en bf16. El número de parámetros es 4,69B y vale la pena saber dónde se distribuyen: 3,57B en las 32 capas del decodificador, 0,64B en los embeddings de tokens, 0,33B en la torre de visión, 0,05B en la cabeza de decisión principal y 0,10B en las dos cabezas de salida temprana. No hay mezcla de expertos ni un segundo modelo. Se instala con un comando pip desde el repositorio, se ejecuta su servidor y, a partir de ese momento, la decisión nunca sale de tu infraestructura.

• Quién lo ejecuta — un endpoint alojado con cobro por uso que tú no controlas frente a un checkpoint de 9.7 GB en tu propia GPU, Apple Silicon o CPU.

• Forma del precio — $0,042 por millón de tokens de entrada, salida gratuita, pago por llamada frente a cero en el margen más el coste de la máquina y las operaciones.

• Presupuesto de entrada — unas 64.000 tokens por solicitud en el modelo alojado, frente a 32.768 tokens de texto más un presupuesto de imagen en el checkpoint; todo lo que supere ese límite se rechaza en lugar de truncarse.

Pesos y licencia — cerrado, tamaño no divulgado frente a pesos Apache-2.0, código MIT, 4,69B de parámetros.

• Modalidad — texto para el contrato de Jev frente a texto más hasta cuatro imágenes por solicitud en las versiones con visión de RSI-Jev.

• Titularidad — el modelo comercial de TypeSafe AI frente a un proyecto de investigación de terceros que declara en su propia línea de licencia que «no está afiliado a TypeSafe AI».

La puntuación en el propio marcador de RSI-Jev, y por qué es solo la mitad de una comparación

La cifra con la que el proyecto abre es su puntuación en el Decision Index 0.3: 50,98 para v6.1-VL 4B, por encima de los 46,23 de la versión anterior. Se trata de una ejecución completa de la configuración predeterminada —140.178 solicitudes, cobertura 1,0— y, en el tablero público del propio proyecto, con fecha 2026-10-06, empata con el mejor modelo 4B de ese tablero (50,98 frente a los 50,82 de ezjev 4B s2, que el kit considera un empate a 0,25) y ocupa el puesto 27 de 113 en total. En el antiguo Decision Index 0.2.1 registra 50,74 frente a los 46,24 de v6.0-VL. Su suite de quince benchmarks, reportada sin la tarea open_jev_ood que se encontró que se solapaba con filas de entrenamiento, es 0,793, y su conjunto reservado es 0,729.

Todas esas cifras son propias de RSI-Jev y se midieron en el arnés de RSI-Jev. El Decision Index es un tablero público de benchmarks, pero no hay ninguna lectura de Jev 1.13 en él, porque la suite del proyecto se creó para puntuar checkpoints de decisión abiertos, y Jev es un endpoint cerrado. Así que la tentación de poner 50,98 frente al 0,727 de Jev en el benchmark de decisiones tipadas y declarar un ganador es exactamente el error que hay que evitar: esas dos cifras provienen de arneses distintos, tamaños de muestra distintos y datos distintos, y nadie ha ejecutado un mismo arnés sobre ambos modelos.

El único cara a cara que existe es el de Laya, no el de RSI-Jev.

Hay una comparación publicada que sí pone una cifra Jev junto a un checkpoint abierto, y no fue realizada por ninguna de las dos partes aquí. Convai Innovations, los creadores del modelo de decisión Laya, tabuló las cifras publicadas de Jev 1.13.0 de TypeSafe frente a las suyas propias y señaló ellos mismos las limitaciones: las cifras Jev son publicadas por terceros y nunca fueron medidas por Convai, los tamaños de muestra y los prompts difieren, y el proveedor no enumera sus propios benchmarks para el modelo. Vale la pena leer esa tabla para calibrar, no para emitir un veredicto, y no incluye RSI-Jev en absoluto, porque RSI-Jev no existía cuando se publicó.

Lo que sí muestra es la forma de la cuestión entre alojado y abierto que un lector realmente está sopesando. El modelo alojado va por delante cuando el espacio de opciones es amplio y el modelo tiene que mantener estable un conjunto amplio de respuestas; los modelos abiertos ganan en latencia bruta por llamada porque no hay red en la ruta. Nada en ese patrón te dice cuál de estos dos modelos específicos es mejor para tu tarea, y la postura honesta es que la respuesta aún no existe en público.

Qué aporta el checkpoint que el endpoint no puede

El argumento más sólido a favor de RSI-Jev no es una puntuación. Es que los pesos residen en tu disco. Para una decisión de enrutamiento tomada a partir de un historial médico, un documento legal o el historial de la cuenta de un cliente, «los datos nunca salen del edificio» no es una preferencia que se negocie contra un punto de referencia; es un requisito absoluto, y ningún endpoint alojado, a ningún precio, lo satisface. Esa misma propiedad elimina el límite de tasa: la propia documentación del proveedor para el modelo alojado señala que sus límites se ajustan dinámicamente y pueden cambiar sin previo aviso, y un checkpoint autoalojado no tiene ese techo más allá de tu hardware.

La segunda cosa que el checkpoint aporta es control de profundidad, y es inusual. Porque las cabezas de decisión se sitúan en tres profundidades, un esfuerzo de ajuste elige cuántas capas puede usar una solicitud: bajo se detiene en la capa 16 con una mediana de unos 23 ms, medio en la capa 20 durante 27 ms, alto en la capa 32 durante unos 40 ms, y auto responde en la primera salida suficientemente segura, promediando 19,5 de 32 capas en la suite del proyecto. Esas latencias son números propios del proyecto medidos en una H200 en bf16 y no deben combinarse con ninguna cifra alojada — una pasada hacia adelante local y una llamada a API medida no son la misma medición, y la propia documentación de RSI-Jev es explícita en que su comparación anterior con la latencia publicada de Jev enfrentó trabajo local de GPU contra un viaje de ida y vuelta de red.

Lo tercero son las imágenes. El contrato de Jev es texto de entrada, JSON estructurado de salida. Las versiones de visión de RSI-Jev aceptan de una a cuatro imágenes por solicitud como URL de datos base64, y el estado se refiere a cada una mediante un marcador; v6.1-VL obtiene 0.834 en el conjunto de imágenes reservado del proyecto. Si tu decisión es «¿la foto muestra daños visibles?», esa es una capacidad que el contrato alojado no ofrece en absoluto.

Lo que sacrificas también es real, y el proyecto lo publica. La calibración empeoró en esta versión, no mejoró: el error de calibración esperado final es de 0,048 en la capa 32 y de 0,055 con auto, frente a 0,036 y 0,024 de la versión anterior. El umbral único predeterminado de 0,95 se entrega explícitamente sin confirmar — es el respaldo de una regla de selección cuya propia elección, 0,85, no cumplió con el límite de profundidad del proyecto en la mitad de sus datos de desarrollo. Las salidas tempranas solo leen texto, así que cualquier pregunta con una imagen ejecuta las 32 capas sin importar el esfuerzo. Y cinco de las fuentes de entrenamiento de imágenes son no comerciales o solo para investigación, y el proyecto afirma claramente que no está resuelto si los pesos entrenados con datos no comerciales heredan esos términos.

Dónde llamar al alojado, y dónde no

Esta es la parte de la comparación en la que tenemos un interés, así que vale la pena ser precisos. Servimos el modelo comercial de TypeSafe como typesafe/jev-1.13 en el endpoint dedicado systemone —un POST a /v1/systemone en lugar del formato chat-completions de OpenAI, sin streaming, contra el contexto de 65.536 tokens que enumera nuestro catálogo. Es la misma forma de petición y respuesta que implementa RSI-Jev, del modelo cuyo contrato copia el proyecto. A RSI-Jev en sí no lo alojamos; no hay ningún id rsi-jev ni ningún id shgao en nuestro catálogo, y el lector que quiera ese modelo lo descarga.

La razón por la que esta distinción importa aquí es concreta y limitada. Una capa de decisión rara vez constituye todo un flujo de trabajo: por lo general, se sitúa junto a un modelo generativo que redacta la respuesta, el resumen o el código. Históricamente, eso ha implicado dos contratos. Ya no tiene por qué ser así en la parte alojada: Jev 1.13 se apoya en la misma clave que más de 200 modelos en el precio de lista del proveedor trasladado con un 0% de margen, así que si TypeSafe cambia una tarifa, el cambio está activo en nuestro lado el mismo día en lugar de en el siguiente ciclo de facturación. La parte autoalojada nunca tuvo ese problema, porque tú eres el proveedor. La forma más limpia de decidir entre ambas es probar el contrato comercial con unos cuantos de tus propios casos etiquetados, comprobar si el comportamiento predeterminado es lo bastante bueno como para automatizar sobre él y solo entonces evaluar si vale la pena asumir la operación de ejecutar tú mismo un checkpoint de 4,69B.

Cuál deberías elegir en realidad

Elige RSI-Jev v6.1-VL 4B si la decisión tiene que permanecer dentro de tu perímetro, si necesitas una decisión tanto sobre una imagen como sobre texto, si tus conjuntos de opciones ascienden a cientos (el checkpoint admite hasta 5.120 opciones por pregunta) o si quieres ajustar la profundidad y la latencia por solicitud. Entra sabiendo que estás adoptando un proyecto que se movió ocho veces en trece días, que su última versión sacrificó la calibración por la precisión y que su propia tarjeta nombra las partes de la política de salida que no pudo confirmar.

Elige Jev 1.13 si quieres que la decisión funcione sin una pila de servicio, si valoras un endpoint que alguien más mantiene activo y si el precio de $0.042 por millón de tokens de entrada —sin tokens de salida que medir— resulta barato frente a tu volumen de llamadas. Entra sabiendo que estás llamando a un modelo cerrado cuyo tamaño no se divulga, cuyos límites de velocidad pueden cambiar sin aviso y cuyos benchmarks publicados no son algo que puedas volver a ejecutar.

Lo que ambos comparten es más útil que lo que los separa, y es la razón por la que vale la pena escribir una comparación como esta. Ninguno de los dos modelos genera texto, así que ninguno introduce la clase de fallo que proviene de un modelo que se olvida de cerrar una llave o inventa un campo. Ambos devuelven probabilidades, y en ambos casos la probabilidad es la parte que tienes que validar con tus propios datos etiquetados antes de automatizar en función de ella: la latencia ya está comoditizada, y el valor de confianza es lo que hay que ganarse en cada despliegue. Del lado que sea de la línea entre descargar y llamar en el que acabes, prueba primero la calibración.