OpenJev ejecuta 2 métodos de decisión con IA local en el navegador

OpenJev: un laboratorio abierto para medir decisiones de IA en tu navegador

OpenJev es un experimento público que corre un modelo de IA directamente en el navegador del usuario, sin backend, sin lista de espera y sin enviar datos a ningún servidor. La página carga el modelo desde Hugging Face, lo deja en caché del navegador y, una vez en memoria, plantea una comparación muy concreta: leer las probabilidades de las opciones válidas directamente de los logits del modelo, o pedirle al modelo que escriba esas mismas probabilidades como JSON, token a token. Mide ambas rutas en tu propia GPU y publica los tiempos.

El proyecto hereda el nombre Jev (el original, hospedado en servidor, logra un 88,3% en la métrica TypeSafe) y sueltas la versión "open" precisamente para que cualquier persona pueda replicar el experimento en local. La diferencia es relevante: si tu startup depende de que un LLM tome una decisión estructurada —clasificar un ticket, enrutar un lead, decidir un siguiente paso— la elección entre leer logits o generar texto cambia latencia, costo y confiabilidad.

Qué problema ataca OpenJev (y por qué debería importarte)

Cuando se usa un LLM como clasificador de opciones múltiples, hay dos formas de obtener la decisión y rara vez se comparan en igualdad de condiciones:

• Lectura directa de logits: el modelo recibe la pregunta y las opciones; tu código lee los logits finales, aplica softmax sólo sobre los tokens que corresponden a las opciones válidas (por ejemplo A, B, C) y devuelve el ganador. No se genera texto.
• Generación token a token: se le pide al modelo que emita algo como {"A": 0.12, "B": 0.65, "C": 0.23}. Cada carácter se genera secuencialmente. Es la forma "natural" si vienes de un wrapper de chat, pero introduce latencia acumulada y errores de formato.

OpenJev ejecuta las dos rutas sobre el mismo modelo cargado, en el mismo dispositivo y de forma secuencial, para que el ratio de tiempos sea comparable. La página recalca que "los métodos se ejecutan secuencialmente sobre el mismo modelo cargado para no competir por una sola GPU".

Los tres modelos disponibles y qué dice cada benchmark

El experimento ofrece tres modelos cuantizados en GGUF (formato portable de llama.cpp) pensados para ejecutarse enteramente en el navegador:

Modelo	Tamaño	Authored	Perturbed	TypeSafe
Qwen3 0.6B	639 MB	44,0%	52,8%	40,7%
MiniCPM5 2B	1,56 GB	68,6%	69,3%	63,7%
Qwen3.5 4B	3,01 GB	81,3%	76,6%	84,5%
Jev (hospedado)	—	—	—	88,3%

El default en escritorio es MiniCPM5 2B; el 0.6B está pensado para móviles y el 4B sólo si tienes memoria de sobra. Los tres números por modelo vienen de un mismo subset de 102 filas evaluado bajo tres condiciones:

• Authored: el escenario original, sin manipular.
• Perturbed: la entrada alterada para ver qué tan robusto es el modelo a ruido o reformulaciones.
• TypeSafe: la métrica clave de Jev, mide que la salida sea decisión + tipo correcto, no sólo la opción más probable.

El patrón es claro y útil: a más parámetros, mejor TypeSafe, pero la versión hospedada (BF16 nativo) sigue lidera a todos los cuantizados de navegador. La cuantización que usa la demo —pinned GGUF builds vía wllama— sacrifica calidad por el privilegio de correr local.

La pila técnica: por qué un modelo de IA puede vivir en una pestaña

Tres piezas hacen posible el experimento y todas están en producción fuera de OpenJev:

• wllama es el binding WebAssembly de llama.cpp mantenido por ngxson. Firefox, por ejemplo, lo usa oficialmente como uno de sus motores de inferencia para Link Preview.
• @localmode/wllama lo envuelve y expone la misma interfaz LanguageModel que webllm y transformers, así que cambiar entre backends es una línea.
• GGUF (GGML Universal File), introducido en agosto de 2023 por Georgi Gerganov (ggerganov), agrupa pesos, tokenizer y metadatos en un solo archivo. Hugging Face aloja más de 178.000 modelos GGUF según el conteo de mayo de 2026 publicado por LocalMode.

Según el blog técnico de LocalMode, WebAssembly está disponible en todos los navegadores modernos desde 2017 (Chrome 57+, Firefox 52+, Safari 11+, Edge 16+), mientras que WebGPU —más rápido— sólo está activado por defecto en Chrome 113+, Edge 113+ y Safari 26+; en Firefox depende de versión y SO. Por eso la elección de WASM en OpenJev: funciona en más dispositivos, aunque sea ~40–50% más lento que WebGPU puro en CPU.

La primera carga del MiniCPM5 2B implica descargar 1,56 GB desde Hugging Face, compilar pases de warmup y dejar el modelo en caché del navegador. Los pesos nunca salen de tu página; el sitio lo recalca: "Las entradas nunca salen de esta página. La primera carga puede tardar varios minutos dependiendo del modelo, la red y la GPU".

Qué miden realmente los tiempos (y qué no)

El benchmark es transparente sobre sus límites. Cuatro advertencias que vale la pena tener presentes si lo usas para decidir:

• Las probabilidades de lectura directa son condicionales: son un softmax sobre sólo los tokens de las opciones mostradas. No son confianza calibrada y excluyen respuestas que el modelo habría preferido fuera del menú.
• El modelo para móvil sacrifica accuracy por tamaño; el de 4B necesita memoria de sobra; ninguno iguala al Jev hospedado.
• Los números son wall-time real, no simulados: setup, warmup, prompt, ejecución directa, primer token y fin de generación se cronometran con performance.now(). No hay resultados pregrabados.
• Los pesos del navegador están cuantizados; la demo usa GGUF pinned y la calidad cambia según la cuantización elegida.

¿Qué significa esto para tu startup?

Si tu producto ya enruta decisiones a un LLM (soporte, scoring de leads, clasificación de tickets, agentes), OpenJev te deja comprobar empíricamente algo que la mayoría de equipos da por sentado: leer logits es casi siempre más rápido y más barato que generar texto, porque te saltas toda la decodificación. Tres acciones concretas que puedes implementar esta semana:

• Audita una decisión de tu producto: identifica un punto donde hoy generas JSON o texto libre para una elección de N opciones. Reescríbelo para leer logits sobre los tokens de las opciones y compara latencia y errores de formato en producción durante una semana. La mayoría de los flujos de clasificación se benefician.
• Prototipa un fallback local: usa OpenJev (o su pila wllama) como campo de pruebas para ver si un modelo pequeño (MiniCPM5 2B) cubre un caso de uso cuando el servidor cae o cuando un cliente pide "modo privado". El hecho de que los pesos vivan en el navegador cambia las reglas de privacidad que puedes vender.
• Dimensiona tu cuantización: si vas a correr modelos en el navegador de tus usuarios, el tradeoff calidad–memoria–velocidad no es negociable. OpenJev te da tres puntos en la curva (0.6B / 2B / 4B) sin levantar un servidor; úsalo para fijar la línea base antes de comprometerte con WebGPU o WASM puro.

Conclusión

OpenJev no es un producto, es un banco de pruebas público para una pregunta que cualquier equipo de producto con IA se hace tarde o temprano: ¿leo los logits o le pido al modelo que escriba? La gracia es que te deja medirlo en tu propia máquina, con tu propia conexión y tu propio dispositivo, en vez de aceptar benchmarks teóricos. Para founders construyendo sobre LLMs, ese tipo de instrumentos vale más que cualquier keynote.

Fuentes

• OpenJev — experimento local en el navegador
• GGUF Models in the Browser: 160.000+ modelos vía llama.cpp WASM — LocalMode Blog