Bonsai vs Bonsai 27B: Un solo nombre de familia, dieciséis veces los parámetros

Cualquiera que compre esta familia por su nombre obtendrá el modelo equivocado, y la razón es que el nombre a secas «Bonsai» no es un modelo. Es la familia y, desde esta semana, la familia incluye un modelo de visión-lenguaje de 2.000 millones de parámetros que funciona en unas gafas inteligentes y un modelo de 27.000 millones de parámetros que funciona en un teléfono, un portátil o un ordenador de sobremesa. El primero es el modelo de visión-lenguaje Bonsai 2B de 1 bit anunciado el 23 de septiembre de 2026 —un modelo de lenguaje de 1,7B y 1 bit más un codificador de visión de 0,3B y 4 bits, con un contexto de 1.024 tokens, construido sobre Bonsai 1.7B—. El segundo es Bonsai 27B, publicado el 14 de julio de 2026 bajo Apache 2.0, construido sobre Qwen3.6-27B con un contexto de 262.000 tokens y la opción de una compilación ternaria de 5,9 GB o una compilación binaria de 3,9 GB. Comparten un nombre, un proveedor, una filosofía de compresión y casi nada más. Dieciséis veces los parámetros, doscientas cincuenta y seis veces el contexto y dos dispositivos totalmente distintos.

Esta página es para la persona que buscó uno de ellos y aterrizó en el otro.

El problema de la denominación, planteado sin rodeos

El menú de modelos de PrismML actualmente incluye Bonsai 2 27B, Bonsai 27B, Bonsai 8B, Bonsai 4B, Bonsai 1.7B y Bonsai Image. El anuncio de las gafas añade un modelo de visión y lenguaje de 2 mil millones de parámetros sobre la línea Bonsai 1.7B. Así que "Bonsai" por sí solo puede referirse a cualquiera de al menos cuatro clases de parámetros y dos generaciones, y el sufijo de tamaño es lo único que lo desambigua. Eso no es una crítica al nombre —es la forma normal de una familia de modelos—, pero sí significa que el nombre de la familia no aporta información sobre lo que estás descargando.

El corte útil no es la generación, sino la clase de dispositivo. Todo en la línea de 27B asume que tienes entre 4 GB y 8 GB de memoria para darle a un modelo de lenguaje y que estás dispuesto a gastarla. Todo en la línea de 1.7B asume que tienes unos pocos cientos de megabytes y nada más. Ese único hecho determina qué mitad de la familia es relevante para ti antes de que lo haga cualquier benchmark.

Lo que realmente es cada uno

• Parámetros — un LLM de 1,7B y 1 bit más un codificador de visión de 0,3B y 4 bits en el modelo de las gafas, frente a un modelo de clase 27B derivado de Qwen3.6-27B en Bonsai 27B.

• Contexto — 1.024 tokens en el modelo de gafas, frente a un contexto completo de 262.000 tokens en Bonsai 27B.

• Pesos del modelo de lenguaje: 0,43 GB para el 1-bit 1.7B, frente a 5,9 GB para el Bonsai 27B ternario y 3,9 GB para su versión 1-bit.

• Representación — pesos binarios {−1, +1} con escalado por grupos en FP16 en ambos, que es la receta de 1 bit sobre la que se basa la familia; Bonsai 27B además ofrece una versión ternaria {−1, 0, +1} con 1,71 bits efectivos por peso.

• Silicio objetivo — la NPU Hexagon de Qualcomm en la plataforma de gafas Snapdragon AR1 Gen 1, compilada a través de un SDK QNN con soporte de kernel de 1 bit, frente al silicio de Apple mediante MLX y NVIDIA mediante CUDA para Bonsai 27B.

• Rendimiento de decodificación: 15,36 tokens por segundo en una plataforma de prueba AR1 Gen 1 de 4 GB para el modelo de gafas, frente a aproximadamente 11 tokens por segundo en un iPhone 17 Pro, 87 en un Apple M5 Max y 163 en una RTX 5090 para el Bonsai 27B de 1 bit.

Todas y cada una de esas cifras son del proveedor, y los dos conjuntos se midieron en hardware distinto y con bases de referencia distintas, así que describen dos productos y no dos puntos de una misma curva.

Donde gana Bonsai 27B, y no es ni de cerca

El contexto es lo primero, y el margen no es un matiz. Una ventana de 262.000 tokens alberga una base de código, un documento extenso, una transcripción o una sesión de agente en funcionamiento con espacio de sobra. Una ventana de 1.024 tokens contiene una instrucción breve y una imagen. Si tu carga de trabajo implica leer algo más largo que una página, Bonsai 27B es el único de los dos que puede hacer el trabajo, y ninguna cantidad de prompting ingenioso en el modelo de gafas cierra esa brecha, porque el límite es la memoria reservada para el estado de clave-valor en lugar del tamaño de los pesos.

La capacidad queda en segundo lugar. Se informa que la versión ternaria de Bonsai 27B conserva alrededor del 95 % de su referencia de precisión completa en una suite de 15 benchmarks en modo de pensamiento, y su versión de 1 bit, alrededor del 90 %, con las mayores pérdidas en visión y uso de herramientas. Esas son cifras del proveedor sobre la propia suite del proveedor, y aun así siguen siendo algo de un orden distinto al de un modelo de 2.000 millones de parámetros cuya única declaración de calidad publicada es que logró «resultados comparativos en benchmarks» frente a un Qwen 3 1.7B de 4 bits. El modelo de las gafas no es comparado con un modelo de 27B por su propio fabricante, porque la comparación no sería útil.

El ecosistema es el tercero. Bonsai 27B se distribuye en empaquetados GGUF, MLX y AWQ con entornos de ejecución documentados, así que hay una vía para ejecutarlo en hardware que ya tienes. El modelo de las gafas existe dentro de una cadena de herramientas NPU de Qualcomm.

Donde el 2B gana, y de eso se trata todo.

Un modelo de lenguaje de 0,43 GB cabe en lugares a los que uno de 5,9 GB no puede llegar, y la plataforma de gafas es uno de ellos. Ese es todo el argumento, y es un argumento más fuerte de lo que sugiere el contraste de especificaciones, porque los dispositivos en cuestión no tienen alternativa: unas gafas con 4 GB de memoria de plataforma compartida no pueden alojar Bonsai 27B en ninguna compilación, y un teléfono no puede alojar la compilación ternaria sin renunciar a la mayor parte de aquello para lo que sirve el teléfono.

Hay una segunda ventaja que recibe menos atención: la representación de 1 bit no es una concesión en esta clase de dispositivos, sino el truco que lo hace posible. Según el propio planteamiento de PrismML, la ruta de 1 bit ofrece aproximadamente la misma inteligencia que el mismo modelo con precisión de 4 bits, pero usando alrededor de una cuarta parte de la memoria y generando tokens a más del doble de velocidad. Para un dispositivo siempre activo, donde cada milivatio y cada megabyte se disputan, ese intercambio es el producto.

Así que los dos modelos no compiten. El 2B es el que se ejecuta cuando no hay ningún otro lugar donde ejecutarse. El 27B es el que se ejecuta cuando sí lo hay.

El límite del nivel es la verdadera decisión

Casi nadie está eligiendo entre estos dos. El despliegue realista incluye ambos: un modelo pequeño siempre activo en el dispositivo para las solicitudes que caben en 1.024 tokens, y algo más grande detrás para todo lo demás. Una vez que aceptas esa forma, la pregunta de ingeniería deja de ser «¿cuál Bonsai?» y pasa a ser «¿dónde está la línea y quién la hace cumplir?».

Si se aplica en el código de la aplicación, esa línea se convierte en una rama que hay que reescribir cada vez que el modelo en el dispositivo cambia la longitud de contexto o la capacidad —lo que, según la evidencia de los últimos tres meses, es aproximadamente mensual. Si se aplica como política de enrutamiento, se convierte en una regla sobre el presupuesto de contexto y la capacidad requerida, y el nivel local sigue siendo un nivel en lugar de convertirse en una suposición integrada en el cliente. Esa es la capa en la que opera OrcaRouter: un endpoint frente a más de 200 modelos alojados, con conmutación por error y la política de escalado expresada en la configuración. Ningún Bonsai se enruta aquí —ambos son descargas que ejecutas en tu propio hardware—, así que el enfoque honesto es que la capa de enrutamiento cubre el nivel superior al local, y con un modelo local de 1.024 tokens ese nivel es donde aterrizará la mayor parte del tráfico.

Si tienes que elegir uno

• Estás construyendo para gafas, wearables o cualquier dispositivo siempre activo — el modelo de visión-lenguaje Bonsai 2B de 1 bit es la única opción aquí, y el contexto de 1.024 tokens es la restricción de diseño en torno a la cual construyes en lugar de contra la cual.

• Estás desarrollando para un teléfono: Bonsai 27B de 1 bit con 3,9 GB es el modelo más grande de esta familia que cabe en un presupuesto de memoria de gama iPhone, y te ofrece un contexto de 262K al que el modelo para gafas no puede acercarse.

• Estás compilando para un portátil o un equipo de escritorio — la versión ternaria de Bonsai 27B es la opción orientada a la calidad dentro de la familia, y la versión de 1 bit ofrece velocidad en lugar de capacidad.

• Estás construyendo un híbrido: decide primero la regla de escalado y después el modelo. El modelo puedes cambiarlo; el límite no, una vez que está en el cliente.

Lo que vale la pena observar es si la ruta de la NPU que hizo posible el lanzamiento de las gafas se extiende hacia arriba. Si los kernels de 1 bit en aceleradores móviles se generalizan, la línea de 1.7B crece y el argumento a favor de un modelo de 27B en un teléfono se fortalece. Hasta entonces, las dos mitades de la familia permanecen claramente separadas por clase de dispositivo, lo que hace que la elección sea más fácil de lo que sugiere el nombre compartido.