Ternary Bonsai 2 27B vs Bonsai 27B: Dos meses, dos modelos base, una variante faltante

Ternary Bonsai 2 27B llegó el 17 de septiembre de 2026, dos meses después de que Bonsai 27B llegara el 14 de julio de 2026, y la comparación principal entre ambos es un solo par de números: la primera generación conservó alrededor del 95 % del promedio de benchmarks de su modelo base de precisión completa, y la segunda conserva el 98,2 %. Eso se lee como una mejora generacional directa, y en su mayor parte lo es, pero las dos cifras no miden lo mismo, porque el modelo base cambió por debajo de ellas. La versión de julio comprimía Qwen3.6-27B. La versión de septiembre comprime Qwen3.8-27B. Parte de la ganancia de calidad corresponde a la receta de compresión y parte, al nuevo Qwen3.8-27B, y ninguna cifra publicada separa ambas cosas.

Hay una segunda diferencia entre las generaciones que ha recibido mucha menos atención y que importa más a un grupo específico de usuarios: el primer Bonsai se lanzó en dos variantes y el segundo se lanza en una. La compilación de 3,9 GB que hizo que un modelo de clase 27B cupiera en un iPhone 17 Pro no tiene sucesor en este lanzamiento. Si ese tamaño es la razón por la que te interesaba Bonsai, la generación más nueva no es una actualización: es un producto diferente que no cubre tu caso.

Lo que realmente se lanzó en la primera generación

Bonsai 27B se lanzó el 14 de julio de 2026 bajo Apache 2.0 como dos artefactos construidos sobre el mismo modelo base, y la división entre ambos era precisamente el objetivo del lanzamiento.

• Ternary Bonsai 27B — pesos ternarios {−1, 0, +1} con escalado por grupos en FP16, 1,71 bits efectivos por peso, una huella de 5,9 GB. La versión orientada a la calidad, pensada para un portátil de uso diario con razonamiento completo, llamada a herramientas y capacidad agéntica.

• 1-bit Bonsai 27B — pesos binarios {−1, +1} con el mismo escalado por grupos, 1.125 bits efectivos por peso, una huella de 3.9 GB. La variante orientada a la huella, dimensionada para caber en el presupuesto de memoria de un iPhone 17 Pro.

Ambos tenían un contexto de 262K tokens, ambos conservaban una torre de visión compacta de 4 bits para que el modelo siguiera siendo multimodal, y ambos admitían decodificación especulativa con un modelo borrador DSpark. El planteamiento de Prism ML en aquel momento era que la representación de bajos bits se ejecutaba de extremo a extremo —embeddings, atención, MLP y la cabeza LM— sin mecanismos de escape de mayor precisión, y que la versión de 1 bit era el primer modelo de la clase 27B capaz de ejecutarse en un teléfono. El rendimiento notificado en la variante de 1 bit era de alrededor de 11 tokens por segundo en un iPhone 17 Pro, 87 tok/s en un Apple M5 Max y 163 tok/s en una RTX 5090; la variante ternaria se indicó en 58 tok/s en el M5 Max y 134 tok/s en la 5090.

El coste de calidad se comunicó junto con esas cifras en lugar de quedar enterrado. En una suite de 15 benchmarks en modo de pensamiento, la base de precisión completa obtuvo 85,0, la variante ternaria 80,5 —alrededor del 95 %— y la variante de 1 bit 76,1, alrededor del 90 %. La degradación se concentró en la invocación de herramientas agénticas, que cayó de 80,0 a 66,0 en la variante de 1 bit, y en visión, que cayó de 72,6 a 59,6. Matemáticas y programación se mantuvieron considerablemente mejor en ambas variantes.

Qué cambió la segunda generación

Ternary Bonsai 2 27B mantiene la receta y cambia las entradas. La representación ternaria sigue siendo {−1, 0, +1} con una escala FP16 por grupo de 128 pesos, ahora empaquetada a 1,76 bits por peso en un archivo de 5,93 GB, con contexto de 262K y la misma torre de visión separada — 0,63 GB a 4 bits en esta versión, que se carga solo cuando llega una imagen.

Dos cosas son genuinamente nuevas, y ambas se describen como la razón por la que la cifra de retención se movió.

La primera es la precisión selectiva. A diferencia de la versión de julio, que ternarizó esencialmente todo, Bonsai 2 mantiene 26.238.464 parámetros en precisión completa —el 0,0976 % del modelo de lenguaje, unos 52 MB en bf16—, concentrados en la ruta del estado recurrente de las capas de atención lineal, además de los pesos de normalización. Es una concesión pequeña en bytes y, al parecer, grande en comportamiento.

El segundo es una base de pesos rotada. Las matrices de pesos se almacenan tras una rotación de Walsh–Hadamard por bloques con un tamaño de bloque de 1024, y la transformación correspondiente se aplica a las activaciones en tiempo de ejecución, bajo la teoría de que distribuir los valores atípicos entre coordenadas hace que una aproximación de tres niveles tenga menos pérdida. No supone almacenamiento adicional porque la rotación se incorpora a los pesos, pero sí está en la ruta de cómputo.

Luego está el cambio que no es una técnica en absoluto: el modelo base. Qwen3.8-27B es un diseño de atención híbrida —aproximadamente 75 % de atención lineal y 25 % de atención completa—, mientras que su predecesor no lo era. Las puntuaciones por categoría reportadas por Prism ML muestran lo que aportó ese cambio. El seguimiento de instrucciones se sitúa en 82,66 para Bonsai 2, frente a 74,53 para Qwen3.6-27B, el modelo base que la primera generación comprimió. El razonamiento y el conocimiento se sitúan en 83,95 frente a 84,71 del modelo base anterior, y la codificación, en 81,58 frente a 82,57. El nuevo modelo base es mejor en el seguimiento de instrucciones por un amplio margen y está ligeramente por detrás en otras dos categorías, que es exactamente el tipo de perfil que hace que los porcentajes de retención entre generaciones sean poco útiles por sí solos.

Por qué las dos cifras de retención no son comparables

El 95 % y el 98,2 % parecen dos lecturas de una misma escala. No lo son, por tres razones que conviene tener claras antes de concluir que la receta mejoró 3,2 puntos.

• Los denominadores son distintos. El 95 % de la primera generación se midió en un conjunto de 15 benchmarks frente a Qwen3.6-27B. El 98,2 % de la segunda proviene de un conjunto de 20 benchmarks frente a Qwen3.8-27B. Distintos conjuntos, distintas líneas base, distintas combinaciones de dificultad.

• Las líneas base se movieron de forma independiente. Parte de la mejora en la retención se debe a que el modelo comprimido se vuelve mejor comprimiendo, y otra parte se debe a que el modelo base cambia de maneras que resultan más favorables para los pesos ternarios. Nada publicado separa esas contribuciones.

• La retención es relativa, por lo que puede aumentar mientras la capacidad absoluta disminuye en una categoría. Un modelo que retiene el 99 % de un padre más débil aún puede quedar por detrás de un modelo que retiene el 96 % de uno más fuerte.

La comparación absoluta es más informativa que la relativa y, sobre esa base, el panorama es más claro. El agregado de 83.9 de Bonsai 2 está por encima del 83.6 que el Qwen3.6-27B de precisión completa obtuvo en el conjunto de pruebas anterior, lo que significa que el sucesor comprimido ahora está por delante del modelo sin comprimir al que reemplazó una generación antes. La compilación ternaria de primera generación obtuvo 80.5 en su propio conjunto de pruebas. Ambas cifras son de Prism ML, y los conjuntos de pruebas son distintos, así que hay que fijarse en el orden, no en los decimales.

La variante que no volvió

Esta es la parte de la comparación que cambia una decisión de compra en lugar de un gráfico de referencia.

No existe un Bonsai 2 de 1 bit. La versión de septiembre incluye una compilación ternaria, en dos empaquetados —PTQ1_0 a 1,76 bits por peso y 5,93 GB, y PQ2_0 a 2,16 bits por peso y 7,25 GB—, además de un contenedor MLX para Apple Silicon. No existe una variante binaria de 3,9 GB, ni se ha anunciado ninguna. La cifra de 3,9 GB de clase móvil que aparece en la cobertura actual sigue refiriéndose al modelo de julio.

La consecuencia práctica es directa. Si tu objetivo es un iPhone o un iPad, o cualquier dispositivo donde no cabe un modelo de lenguaje de 5,9 GB más una torre de visión de 0,63 GB más un presupuesto de contexto, entonces la versión de 1 bit de primera generación sigue siendo la única opción de esta familia, y lo seguirá siendo hasta que exista un Bonsai 2 de 1 bit. Actualizar la ruta ternaria no actualiza esa ruta. Cualquiera que lea «Bonsai 2 es mejor» y lo vuelva a descargar en un teléfono descubrirá que el archivo no cabe.

Si estás en una laptop o una computadora de escritorio, el cálculo es el opuesto: no hay ninguna razón para ejecutar el build ternario de julio cuando el de septiembre es más pequeño por unidad de calidad, mejor en los benchmarks que importan y tiene el mismo contexto de 262K.

Velocidad, donde las generaciones son genuinamente difíciles de clasificar

El rendimiento es la parte de esta comparación en la que la respuesta honesta es que las cifras publicadas no respaldan una clasificación clara, y merece la pena decirlo en lugar de elegir el par que resulta halagador.

Las mediciones estandarizadas de la segunda generación con tamaño de lote 1 y excluyendo la torre de visión son 142,5 tok/s de decodificación en una RTX 5090 con el empaquetado PQ2_0, 46,8 tok/s en un Apple M5 Max, 27,7 en un M5 Pro y 18,0 en un M4 Pro. La primera generación citó 134 tok/s en una RTX 5090 y 58 tok/s en un M5 Max para su compilación ternaria. La cifra de la 5090 se mueve modestamente en la dirección esperada. La cifra del M5 Max se mueve en la dirección contraria —de 58 a 46,8—, lo que no es el aspecto que se supone que debería tener un avance generacional de dos meses.

Dos salvedades impiden que eso constituya un hallazgo. Las bases de medición difieren entre versiones, y al menos una cifra publicada del M5 Max para el modelo más reciente se ha atribuido a una compilación anterior a la optimización de rotación. Pero merece la pena señalarlo como una cuestión abierta, porque el mecanismo que lo explicaría está en las notas de la versión: la base rotada sitúa una transformada en la ruta crítica de cada proyección con tamaño de lote 1, y la decodificación en Apple Silicon es el régimen en el que eso más perjudica. La técnica que compra calidad puede costar rendimiento de decodificación, y en hardware de memoria unificada ese compromiso alcanza su punto más agudo.

El contenedor MLX añade una complicación aparte para los usuarios de Apple. Es un formato afín de 2 bits cuyo bloque almacena tanto una escala como un sesgo para cada grupo de 128 pesos, pero los pesos ternarios solo necesitan la escala, así que el sesgo es peso muerto: el bloque cuesta 36 bytes por cada 128 pesos en lugar de 34, y la tasa empaquetada queda en 2,25 bits por peso con un tamaño de archivo medido de 8,005 GiB. Es un contenedor distinto que lleva los mismos valores, y es el paquete que el entorno de demostración descarga de forma predeterminada.

Ejecutar cualquiera de las dos generaciones

Ambas generaciones comparten una restricción operativa que ninguna versión de este modelo ha logrado eludir: ninguna de las dos se ejecuta en llama.cpp estándar. Los kernels ternarios para esta arquitectura residen en el fork propio de Prism ML; llama.cpp estándar rechaza los empaquetados actuales como desconocidos y —peor aún— cargará el formato ternario antiguo sin quejarse y producirá basura fluida, porque no aplica la rotación que asumen los pesos. La compilación de MLX incluye kernels de Metal y CPU, pero no una ruta CUDA. Elijas la generación que elijas, la cuestión del runtime la resuelve la propia distribución de Prism ML o un runtime que haya adoptado sus kernels, no el ecosistema ggml en general.

Dónde encaja OrcaRouter en una decisión como esta es un nivel más arriba. Ninguna de las generaciones de Bonsai se aloja aquí: son descargas que ejecutas en tu propio hardware. Para lo que resulta útil la capa de enrutamiento es para el límite: las solicitudes que tu modelo local no debería estar respondiendo. Define la política de escalado una sola vez en la configuración de enrutamiento en lugar de en el código de la aplicación, de modo que un nivel servido localmente pase solicitudes de contexto largo, con mucha carga visual o que queden fuera de alcance a un modelo alojado en lugar de fallar con ellas, y de modo que el respaldo sobreviva sea cual sea la generación de Bonsai que tengas instalada. Tanto el nivel local como el alojado entonces quedan detrás de una única clave, y la política reside en un solo lugar cuando llegue la próxima generación de Bonsai y los límites entre niveles vuelvan a desplazarse.

Qué hacer con esto

• Si ejecutas la compilación ternaria de julio en una laptop o computadora de escritorio, cámbiate a Ternary Bonsai 2 27B. Es un modelo mejor con una huella aproximadamente igual, y las puntuaciones por categoría en las que gana son las que importan para el trabajo agéntico y de seguimiento de instrucciones.

• Si ejecutas la compilación de 1 bit de julio en un teléfono, quédate. No hay sucesor, y la compilación ternaria de 5.93 GB no es un reemplazo directo para una de 3.9 GB.

• Si está evaluando la familia por primera vez, decida primero el footprint y luego la generación. La variante que necesita determina en qué versión está comprando, y ese orden es el inverso de cómo se suele describir esta actualización.

• Si estás eligiendo en función de los benchmarks — trata el 95 % y el 98,2 % como dos mediciones diferentes en lugar de dos puntos en una línea, y considera cada cifra de ambos como propia del proveedor hasta que aparezca una evaluación independiente del modelo de septiembre. Esa evaluación es la que hay que seguir de cerca, porque es la primera que podrá comparar las dos generaciones sobre una base común.