Ternary Bonsai 2 27B: paridad entre WebGPU y runtimes nativos para inferencia de IA local

Por qué Ternary Bonsai 2 27B cambia la pregunta sobre IA local en navegador frente a nativo

Ternary Bonsai 2 27B es interesante porque aparece en más de una categoría de runtime. El lanzamiento de Prism ML del 17 de septiembre describe un checkpoint ternario de clase 27B basado en Qwen3.8, un formato de 1.76 bits efectivos y una huella de modelo reportada de 5.9GB. La colección relacionada de Hugging Face apunta a artefactos nativos como GGUF y MLX. El Space de WebGPU añade una ruta de navegador.

Esa mezcla cambia la pregunta. La pregunta útil ya no es: "¿Puede este modelo ejecutarse localmente?" Es: "¿Qué partes de la experiencia local sobreviven al paso de runtime nativo a runtime de navegador?"

Ese es un umbral más estrecho y más útil. Una demo de navegador no demuestra paridad con CUDA o MLX en rendimiento, longitud de contexto, compatibilidad de funciones, comportamiento de memoria, registros o repetibilidad. Demuestra que existe suficiente superficie de artefactos públicos para probar correctamente el límite.

Este artículo no es una repetición de la publicación anterior de Optijara sobre la prueba de aceptación en dispositivo de Bonsai 1. La pieza de julio analizó la aceptación en dispositivo de primera generación. Bonsai 2 necesita una lente de paridad de runtime: descarga, caché, configuración del adaptador WebGPU, compilación de shaders o kernels, carga del modelo, prefill, decode, comportamiento de contexto, límites de texto e imagen y repetibilidad frente a rutas nativas. Para equipos que comparan el comportamiento de archivos cuantizados entre runtimes, la guía de migración de diseños por tensor en GGUF y recetas de cuantización es el mejor complemento.

WebGPU en el navegador es una experiencia de producto antes de ser una historia de benchmark. Puede ser una forma de baja fricción para que una parte interesada pruebe un modelo local. También puede ocultar los detalles exactos que necesita un evaluador serio. Trátalo como un runtime con sus propios modos de fallo, no como una envoltura más bonita alrededor de la inferencia nativa.

Una barrera más. Las cifras de rendimiento nativo de Prism, las publicaciones de la comunidad y las reacciones rápidas a demos son señales útiles de descubrimiento. No son evidencia de benchmark intercambiable. Optijara no ejecutó un benchmark independiente para este artículo. Todas las pruebas siguientes son planes de medición propuestos, no resultados afirmados.

El mapa de artefactos: qué puede demostrar cada fuente

El primer trabajo es separar la evidencia de la suposición. La página de lanzamiento puede establecer el anuncio, el posicionamiento del modelo y las afirmaciones del publicador. La colección de Hugging Face puede mostrar la agrupación pública de artefactos. Las tarjetas de modelo individuales pueden mostrar archivos específicos por runtime, licencias, revisiones y notas de uso. El árbol y el README del Space de WebGPU pueden mostrar lo que el artefacto de navegador expone en código o interfaz. Ninguna de esas fuentes, por sí sola, demuestra que cada capacidad del modelo llegue al navegador.

Esto importa porque una huella de pesos de 5.9GB no es memoria máxima. No es tamaño de caché del navegador. No es sobrecarga de transferencia, caché de shaders, asignación de búferes temporales ni supervivencia de pestañas bajo presión. La ejecución en navegador puede necesitar memoria de trabajo adicional durante la descarga, la compilación, la ejecución y la rehidratación de caché. Los runtimes nativos suelen exponer reportes de memoria, controles de cuantización y registros más claros.

La misma cautela aplica a las afirmaciones de contexto largo y multimodalidad. Si una familia de modelos o una arquitectura menciona contexto largo o visión, eso no significa que la demo de WebGPU admita entrada de imágenes o una longitud máxima de contexto práctica. Los límites de memoria del navegador, el comportamiento del adaptador GPU, la presión de caché y la construcción del prompt también cuentan.

Mapa de paridad entre navegador y nativo

El Mapa de paridad entre navegador y nativo usa cinco dimensiones: disponibilidad de artefactos, ruta de arranque, ruta de tokens, superficie de funciones y envolvente operativa. El objetivo no es coronar a WebGPU, MLX o CUDA. El objetivo es dejar de tratar "se ejecuta en el navegador" como una respuesta de sí o no.

WebGPU puede bastar para una demo, un flujo educativo, una evaluación interna o un prompt local ligero donde la velocidad de configuración importa más que la instrumentación profunda. Es especialmente útil cuando un equipo quiere que la gente vea una ruta de modelo local sin instalar runtimes nativos.

Las rutas nativas siguen importando cuando el equipo necesita benchmarking repetible, controles explícitos de hardware, mejor perfilado, automatización tipo servidor, suites de evaluación más largas o comparaciones cuidadosas entre archivos cuantizados. MLX es la vía natural para Apple Silicon. CUDA y GGUF son la vía de evaluación para estaciones de trabajo y servidores.

{
  "framework": "Mapa de paridad entre navegador y nativo",
  "dimensions": ["artifact_availability", "startup_path", "token_path", "feature_surface", "operating_envelope"],
  "claim": "La paridad es específica de la carga de trabajo y debe medirse por separado para rutas de WebGPU en navegador, MLX y CUDA o GGUF.",
  "benchmark_status": "proposed_test_plan_only"
}

Mide el arranque y la generación de tokens por separado

Una comparación justa de runtimes de Bonsai 2 empieza separando el arranque de la generación. La descarga en primera visita, la recarga con acierto de caché, la inicialización del adaptador WebGPU, la compilación de shaders, la carga del modelo, la latencia del primer token, la velocidad de prefill, la velocidad de decode, la presión de memoria y la estabilidad de pestaña son eventos separados. Si los mezclas en una sola puntuación de "se sintió rápido", el cuello de botella real desaparece.

No compares una cifra nativa del publicador, una anécdota de velocidad en redes sociales y una impresión de demo en navegador como si fueran el mismo benchmark. Pueden usar hardware, longitudes de prompt, configuraciones de contexto, archivos cuantizados, versiones de navegador y estados de calentamiento distintos.

Un reporte útil debería incluir el paquete exacto de prompts, la revisión del modelo, el commit del runtime, el sistema operativo, el adaptador GPU, la versión del navegador, el archivo cuantizado, la longitud de contexto y los parámetros de decoding. Si faltan esos detalles, el resultado puede seguir siendo interesante, pero no debería guiar una decisión de adopción.

La paridad de funciones es más que salida de texto

La generación de texto suele ser el primer objetivo de paridad porque es visible y fácil de probar. Pero la paridad de texto no es paridad completa del modelo. Los equipos también deberían comprobar el comportamiento de JSON estructurado, la reutilización de contexto multi-turno, el resumen de documentos largos, el comportamiento de rechazo si corresponde y la variación entre ejecuciones repetidas.

El soporte de visión necesita su propia prueba. Si una familia completa de modelos o la documentación menciona capacidad multimodal, el artefacto de navegador todavía necesita evidencia en UI y código antes de que alguien afirme soporte de entrada de imágenes. Las etiquetas útiles son compatible, parcialmente compatible, no compatible o desconocido hasta que se pruebe.

El contexto largo merece la misma disciplina. Una afirmación de contexto a nivel de arquitectura no significa que una pestaña de navegador pueda procesar el contexto máximo con memoria, latencia y estabilidad aceptables. Para Bonsai 2, la mejor pregunta operativa no es "¿cuál es el contexto teórico?" Es "¿qué longitudes de prompt siguen siendo estables y útiles en este runtime en este dispositivo?"

Esa formulación es menos dramática, pero ayuda a los equipos a evitar convertir una suposición de demo en una promesa de producto.

Una matriz práctica de pruebas por dispositivo y flujo de trabajo

Los equipos deberían evaluar Bonsai 2 en dispositivos y flujos de trabajo, no con un solo prompt favorable. La matriz siguiente es un plan propuesto, no un resultado de benchmark de Optijara.

La suite de prompts debería incluir una instrucción corta, un resumen de documento largo, una salida JSON estructurada, una prueba de reutilización de contexto multi-turno, una comprobación de entrada de imagen solo si el artefacto la admite y una comprobación de recarga de caché. Registra aprobado, cautela o fallo. "Cautela" es útil cuando un runtime funciona para texto corto pero falla con contexto largo, necesita una bandera concreta del navegador o se comporta distinto tras una recarga en caliente.

Errores comunes al probar IA local en navegador contra runtimes nativos

El primer error es tratar el tamaño de descarga como requisito de memoria. La huella del publicador es un dato del artefacto del modelo, no una envolvente completa del runtime. Mide memoria pico, tamaño de caché, búferes temporales y comportamiento de fallo.

El segundo error es tratar el throughput nativo como throughput de navegador. Las cifras de CUDA o MLX nativos no se trasladan automáticamente a WebGPU. Mide cada runtime en su propia ruta.

El tercer error es tratar el soporte de demo como soporte completo del modelo. Un Space de navegador puede exponer generación de texto y dejar sin soporte entrada de imágenes, contexto completo o controles avanzados. Inspecciona archivos, UI y comportamiento de red antes de hacer afirmaciones.

El cuarto error es asumir que la IA local en navegador es privada por defecto. La ejecución local aún puede implicar endpoints de fetch, comportamiento de almacenamiento, service workers, telemetría o llamadas a dependencias. Inspecciona la ruta de red. Desconecta la red después de la carga en caliente y observa qué sigue funcionando.

El quinto error es usar un prompt como benchmark. Una sola instrucción amable puede ocultar problemas de contexto, estructura, decoding y estabilidad. Usa una suite de prompts y mantén las entradas exactas bajo control de versiones.

Salvedades y trade-offs operativos

La IA local con navegador primero puede reducir la fricción de configuración, pero no elimina el trabajo de implementación. Seguridad y privacidad siguen necesitando revisión de código, inspección de red, revisión de caché, revisión de dependencias y pruebas de comportamiento offline.

El rendimiento varía según navegador, driver, adaptador GPU, memoria del dispositivo, estado térmico y cadencia de actualización del runtime. La reproducibilidad es más difícil cuando el navegador forma parte del runtime. Una actualización del navegador, una actualización de driver, un cambio del compilador de shaders o una invalidación de caché pueden cambiar la experiencia.

Las rutas nativas requieren más configuración, pero a menudo dan a los equipos mayor control sobre versiones, registros, perfilado y automatización. El mantenimiento es el coste oculto. Si un equipo publica IA en navegador como herramienta interna, alguien es responsable de la compatibilidad de navegadores, las actualizaciones de artefactos del modelo, la invalidación de caché y las notas de soporte para dispositivos no compatibles. Si un equipo publica flujos nativos, alguien es responsable de la instalación del runtime, drivers, archivos cuantizados y restricciones de hardware. Ninguna ruta es gratis.

Guía de decisión: WebGPU, MLX, CUDA o una ruta mixta

Elige WebGPU en navegador cuando el objetivo sea una demo de baja fricción, un recorrido educativo, un piloto interno o una ruta de evaluación donde los usuarios puedan tolerar límites explícitos de funciones. Es una buena primera experiencia cuando el equipo quiere probar interés antes de instalar stacks nativos.

Elige MLX cuando la audiencia de evaluación esté principalmente en Apple Silicon y el equipo necesite integración nativa, repetibilidad y caracterización en dispositivos Apple. MLX también es útil cuando la ruta de navegador funciona pero no expone suficiente observabilidad para una comparación seria.

Elige CUDA o GGUF cuando el equipo necesite evaluación estilo estación de trabajo o servidor, instrumentación más profunda, comparación de cuantización, suites de prompts más largas o pruebas de rendimiento controladas. Esta ruta tiene más coste de configuración, pero suele ser la vía más fuerte para medición repetible.

Usa varios runtimes cuando Bonsai 2 vaya a aparecer en más de un entorno. Una demo de navegador puede ayudar a las partes interesadas a entender la experiencia. MLX puede dar soporte a portátiles de desarrolladores Apple. CUDA o GGUF puede anclar una evaluación controlada. Ahí es donde el Mapa de paridad entre navegador y nativo demuestra su valor: convierte la elección de runtime en una prueba de aceptación documentada en lugar de un debate sobre titulares de lanzamiento.

Para equipos que necesitan un plan de pruebas neutral, Optijara puede ayudar a definir la suite de prompts, la matriz de runtimes, los campos de medición y las notas de adopción sin asumir de antemano que navegador, MLX o CUDA sea la respuesta correcta.