Bonsai 27B: el modelo 27B de la familia Bonsai, explicado

Bonsai 27B es el modelo de 27 mil millones de parámetros de la familia Bonsai de PrismML, y es al que la gente se refiere cuando escribe «bonsai 27b», pero el nombre por sí solo no te llevará hasta él, porque tres cosas distintas responden a algo parecido. Bonsai 27B es una reconstrucción de bajos bits de Qwen3.6-27B, con fecha del 14 de julio de 2026 según el propio anuncio del proveedor, y se distribuye en dos paquetes del mismo modelo: 1-bit Bonsai 27B, que almacena pesos binarios {−1, +1} en unos 3,9 GB, y Ternary Bonsai 27B, que almacena pesos ternarios {−1, 0, +1} a 1,71 bits efectivos por peso — 5,9 GB en la cifra destacada del proveedor, 7,165 GB tal como se distribuye realmente el paquete. No es Ternary Bonsai 2 27B, la segunda generación con nombre independiente construida sobre Qwen3.8-27B, y no es el modelo de visión-lenguaje de 2 mil millones de parámetros que PrismML creó para las gafas inteligentes Snapdragon AR1 Gen 1. Ambos paquetes de Bonsai 27B incluyen un contexto de 262.000 tokens, una torre de visión compacta de 4 bits y una licencia Apache 2.0. El modelo es Bonsai 27B; la decisión que sigue es cuál de sus dos paquetes se ajusta a tu presupuesto de memoria.

Esta página es la referencia de ese modelo. No es un anuncio: Bonsai 27B está disponible desde julio de 2026, y las preguntas que vale la pena responder sobre él ahora son las que un lector trae consigo: qué es exactamente, qué distingue el nombre y cuánto cuesta realmente ejecutarlo.

¿Cuál es el 27B?

La confusión aquí es real, y vale la pena resolverla antes que nada, porque una suposición equivocada te envía a un modelo de 2 mil millones de parámetros o a la generación equivocada del correcto.

• Bonsai — el nombre de la familia, y el nombre que le da el proveedor. Por sí solo no identifica nada que puedas descargar. PrismML ha lanzado Bonsai 1.7B, Bonsai 4B, Bonsai 8B, Bonsai 27B y Bonsai Image, además del modelo de 2 mil millones de parámetros para gafas, y un lanzamiento anterior de abril de 2026 llamado Ternary Bonsai para la línea más pequeña. Una búsqueda de la palabra a secas recala en ese conjunto al azar.

• Bonsai 27B — el tema de esta página. Primera generación de la línea 27B, derivada de Qwen3.6-27B, con fecha del 14 de julio de 2026. Cuando una página dice "Bonsai 27B" sin otro calificador y sin "2", este es el modelo al que se refiere, y este es el nombre que se debe usar.

• Ternary Bonsai 27B — no es un modelo distinto. Es el paquete de Bonsai 27B orientado a la calidad: el mismo modelo 27B, la misma arquitectura y la misma base, pero con pesos ternarios en lugar de binarios. El repositorio se llama Ternary-Bonsai-27B-gguf, y su ficha de modelo indica Qwen3.6-27B como base exactamente igual que la ficha binaria. "Ternary" aquí es un formato de pesos, no una versión.

• Ternary Bonsai 2 27B — un modelo genuinamente diferente. La segunda generación de la línea 27B, construida sobre Qwen3.8-27B y anunciada el 17 de septiembre de 2026, con una división de parámetros diferente y una afirmación de calidad diferente. El "2" lleva toda la distinción.

• 1-bit Bonsai 2B — un miembro distinto de la familia a una escala diferente: un modelo de visión-lenguaje de 2 mil millones de parámetros para hardware de la clase de unas gafas, no un modelo de 27B a ninguna precisión.

Así que, si viniste aquí para resolver cuál de estos es el modelo 27B, la respuesta es que la tercera y la cuarta línea de arriba son el mismo modelo en dos formatos de pesos, y la quinta es la que no lo es. En la práctica: llámalo Bonsai 27B y añade el pack cuando importe.

La especificación, de la tarjeta del modelo

Cada cifra de esta sección procede de las tarjetas de modelo publicadas por PrismML para los dos paquetes, y es la propia declaración del proveedor sobre su propio modelo. Cuando una cifra es una afirmación en lugar de una medición, se etiqueta como tal.

• Parámetros —alrededor de 27.3B en total, y el "27B" se refiere a ese conjunto completo. Vale la pena conocer el desglose porque explica el comportamiento de la memoria: aproximadamente 24.8B residen en la columna vertebral del lenguaje a lo largo de 64 bloques, aproximadamente 2.5B en el embedding y la cabeza LM, y alrededor de 0.46B en una torre de visión de 27 bloques. La representación de baja precisión se aplica de extremo a extremo —embeddings, atención, MLP y la cabeza LM—, sin ninguna válvula de escape de mayor precisión en ningún punto de la red de lenguaje.

• Contexto — 262.000 tokens completos, sin variante de contexto largo y sin versión de contexto reducido. El coste de esa ventana se gestiona en lugar de pagarse por completo: la red troncal es híbrida, por lo que solo 16 de sus 64 capas mantienen una caché de atención completa, y esa caché se almacena en un formato de 4 bits casi sin pérdidas. Con la ventana completa de 262K, la caché comprimida es lo que mantiene el modelo dentro de aproximadamente 9,4 GB en el paquete binario y 12,8 GB en el ternario.

• Modalidad — texto e imágenes, ambos paquetes. La torre de visión se distribuye en un formato compacto de 4 bits (0,63 GB) junto con una copia en BF16 (0,93 GB). La visión es también donde la compresión resulta más costosa, lo cual se trata a continuación.

• Formato y tamaño de los pesos — 1-bit Bonsai 27B utiliza pesos binarios {−1, +1} con escalado por grupos en FP16, empaquetados como GGUF Q1_0_g128 con 1,125 bits efectivos reales por peso; el archivo distribuido es de 3,803 GB, y la tarjeta redondea la huella desplegada a unos 3,9 GB. Ternary Bonsai 27B utiliza pesos ternarios {−1, 0, +1} con el mismo escalado por grupos; un valor ternario transporta log₂3 ≈ 1,585 bits de información, por lo que el mínimo de la representación es de ~1,71 bits por peso, lo que da un ideal de 5,9 GB. El paquete ternario publicado es más grande que ese ideal, porque los kernels actuales almacenan cada valor ternario en una ranura de 2 bits — 2,125 bits por peso desplegados — y el archivo distribuido es de 7,165 GB. PrismML declara ambas cifras en lugar de solo la favorable, y la diferencia entre ellas es una limitación del kernel y no una decisión de modelado.

• Licencia — Apache 2.0 en ambos paquetes, indicado en ambos repositorios y en el anuncio del proveedor. Se trata de una licencia permisiva sin restricción de campo de uso, lo cual importa más en este tamaño de pesos que en la mayoría.

• Modelo base — Qwen3.6-27B en ambos casos. Esta es una recompresión del modelo de otra persona en lugar de un modelo entrenado desde cero, y la consecuencia es que tanto el techo de capacidad de Bonsai 27B como su cadencia de actualización siguen la línea upstream de 27B en lugar de la de PrismML.

La relación ternaria, enunciada una vez

Los dos paquetes son un único modelo, y el resumen honesto es que el ternario gana en calidad y el binario gana en huella, con una brecha entre ellos menor de lo que sugiere la diferencia de tamaño de 3,9 GB frente a 7,2 GB.

En la propia suite de 15 benchmarks en modo de pensamiento de PrismML, el modelo base FP16 Qwen3.6-27B obtiene 85,07. Ternary Bonsai 27B obtiene 80,49 —un 94,6 % de retención, que el proveedor redondea a alrededor del 95 %. 1-bit Bonsai 27B obtiene 76,11 —un 89,5 %, redondeado a alrededor del 90 %. Así que el paquete orientado a la calidad recupera aproximadamente la mitad de la distancia entre el paquete binario y la precisión completa, aunque cuesta unos 3,3 GB más, y el paquete binario es el que cabe en un teléfono de 12 GB. La misma suite muestra una compilación Q4_K_XL de 4 bits del mismo modelo base con 84,99, o un 99,9 % de retención, en 17,6 GB —que es la comparación que explica por qué existe cualquiera de los paquetes de bajo bit, ya que los supera en calidad y pierde en todos los dispositivos que tienen menos de 18 GB para destinar a un modelo.

Donde el paquete binario cede terreno es desigual, y el desglose por categorías es la parte útil. Frente a la línea base FP16, cae de 95.33 a 91.66 en matemáticas y de 88.74 a 81.88 en programación, pero de 78.47 a 65.74 en seguimiento de instrucciones, de 80.00 a 66.03 en trabajo agéntico y de llamada a herramientas, y de 72.61 a 59.57 en visión. Si tu carga de trabajo es aritmética o autocompletado de código, 3.9 GB es casi gratis. Si se trata de agentes que llaman a herramientas o de comprensión de imágenes, ahí es donde realmente se paga la compresión.

La ficha del modelo también publica una cifra derivada a la que llama densidad de inteligencia —puntuación agregada por gigabyte, normalizada de modo que una puntuación perfecta tiende a infinito—. Según esa medida, 1-bit Bonsai 27B alcanza 0,530 y Ternary Bonsai 27B 0,400, frente a 0,199 de una versión IQ2_XXS de 2 bits del mismo baseline, 0,155 de una versión Q4_K_XL de 4 bits, y 0,051 del modelo FP16. El número interesante de esa lista es la primera comparación: el paquete binario supera a la versión convencional de 2 bits en calidad agregada con menos de la mitad de la huella, que es toda la tesis de la familia en una línea.

La comparación completa cara a cara entre los dos paquetes, y de dónde proceden los números de cada uno, se detalla en la página Bonsai vs Bonsai 27B de este blog, junto con el modelo de 2.000 millones de parámetros que comparte el nombre de la familia.

Una pregunta que surge con este modelo merece una respuesta factual y nada más. Los packs son codificaciones de baja precisión del mismo modelo subyacente, no una variante reentrenada, y los repositorios no publican junto a ellos ningún checkpoint ajustado por separado ni sin censura: el único artefacto de precisión completa que se ofrece es una conversión FP16 desempaquetada de los mismos pesos, publicada para que puedas comparar un pack comprimido con su propia línea base en herramientas estándar.

Pesos y licencia, de los repositorios

Los pesos de Bonsai 27B se publican en Hugging Face bajo la organización prism-ml, y el listado de archivos es lo más concreto del lanzamiento. El repositorio del paquete binario contiene el modelo en sí con 3,803 GB, un GGUF FP16 del mismo modelo con 53,808 GB para comparación, un drafter de decodificación especulativa DSpark con 1,787 GB en 4 bits y 7,292 GB en BF16, y torres de visión con 0,931 GB y 0,629 GB. El repositorio ternario contiene su propio paquete de 7,165 GB más un segundo empaquetado de 7,585 GB, que es group-64 en lugar de group-128 y compatible con upstream en lugar de óptimo, y los mismos archivos de drafter y visión. Ambos repositorios son Apache 2.0 y ambos nombran Qwen3.6-27B como la base.

De ese listado se desprenden dos cosas. La primera es que 53,808 GB frente a 3,803 GB es la proporción de 14,2x con la que abre la ficha del modelo, y es comprobable en lugar de una simple afirmación: el archivo de precisión completa está justo ahí. La segunda es que el lanzamiento pesa más que el modelo: si además tomas el modelo de borrador y la torre de visión, que la vía multimodal requiere, estás añadiendo unos 2,4 GB por encima de un modelo de 3,9 GB. La cifra destacada de 3,9 GB corresponde a los pesos del lenguaje, no al despliegue.

Las descargas son el único aspecto en el que el paquete orientado a la calidad va por delante: a fecha de octubre de 2026, el repositorio GGUF ternario ha superado las 590.000 descargas, frente a algo más de 400.000 del paquete binario, mientras que los contenedores MLX de ambos se sitúan por encima del millón cada uno. La forma de eso sugiere que la mayor parte de este modelo se está ejecutando en hardware de Apple en lugar de en servidores, y que quienes lo descargan están comprando los cinco puntos adicionales de retención en lugar del archivo más pequeño posible, que es, más o menos, para lo que el proveedor diseñó el par.

Ejecutándolo

Lo que puedes obtener hoy son cuatro tipos de artefacto por paquete, y cuál de ellos quieres lo determina tu entorno de ejecución en lugar de la calidad.

• GGUF para llama.cpp — la ruta principal, y aquella para la que se escribieron los kernels de bits bajos. Ambos paquetes son compilaciones de llama.cpp para CUDA, Metal y CPU, pero los kernels de 1 bit y ternarios viven en el fork propio de PrismML en lugar de en upstream, así que llama.cpp estándar aún no los cargará correctamente. El empaquetado ternario de grupo 64 existe precisamente para los casos en los que necesitas compatibilidad con upstream y estás dispuesto a aceptar 7.585 GB en lugar de 7.165 GB para obtenerla.

• MLX para Apple silicon — contenedores enviados por separado: 5,129 GB para el paquete binario y 8,491 GB para el ternario. Ten en cuenta que el contenedor binario de MLX es más grande que el paquete binario de GGUF, lo cual es una diferencia de sobrecarga del contenedor y no de un modelo diferente.

• AWQ de 4 bits para frameworks de servidor — una versión de 4 bits de cada modelo para los frameworks de servicio que esperan un checkpoint AWQ, en nueve fragmentos que suman 18,70 GB, incluida una receta para múltiples GPU. Este no es un artefacto de baja precisión; es el mismo modelo con una precisión que tiene sentido en un rack, y sacrifica por completo la razón por la que existe el modelo.

• Safetensors FP16 sin empaquetar — el modelo completo de ~54 GB en el formato estándar de Hugging Face, publicado explícitamente para frameworks que todavía no admiten pesos de 1 bit de forma nativa. El proveedor afirma que este artefacto se retirará una vez que los kernels de bajo bit lleguen al upstream.

El rendimiento de decodificación medido en el paquete binario, según la propia tabla de la ficha del modelo, es de 66,4 tokens por segundo en un M5 Max, 44,2 en un M5 Pro, 26,0 en un M4 Pro y 104,8 en un H100, con prefill de 874, 421, 133 y 2.755 tokens por segundo, respectivamente. La página del anuncio cita picos más altos —hasta 87 tokens por segundo en un M5 Max y 163 en una RTX 5090—, que corresponden a la propia configuración óptima del proveedor, no a la de la tabla. Los dos conjuntos deben tratarse como condiciones de medición distintas, no como una contradicción, y ambos deben considerarse datos reportados por el proveedor. La memoria máxima, de nuevo según la ficha, es de 5,2 GB con un contexto de 4K, 5,6 GB con 10K y 11,6 GB con 100K en el paquete binario, y de 8,4, 8,7 y 14,7 GB en el paquete ternario —con la salvedad de que esas cifras son anteriores a la caché KV de 4 bits, que es lo que reduce la ventana completa de 262K a gigabytes de un solo dígito.

El modelo de borrador DSpark es opcional y conviene entenderlo antes de habilitarlo, porque no cambia nada en las salidas: es un transformer paralelo por bloques de seis capas condicionado por estados ocultos extraídos de cinco capas objetivo espaciadas uniformemente, añade alrededor de 0,5 GB en precisión de servicio y se verifica contra el modelo objetivo en lugar de muestrear por su cuenta. Por eso el proveedor puede citar una aceleración de 1,37x en CUDA sin tocar las cifras de calidad. No está habilitado de forma predeterminada en Apple silicon.

Donde el modelo local se queda sin camino es la interesante cuestión de ingeniería, y es una cuestión de enrutamiento más que una cuestión de modelo. Un modelo de 3,9 GB en un portátil hace lo que cabe en su contexto; todo lo demás tiene que ir a algún sitio, y ese sitio es un modelo alojado detrás de una API. OrcaRouter es esa capa — una que abarca más de 200 modelos alojados con un 0 % de recargo sobre los precios de lista de los proveedores, conmutación automática entre proveedores, y la regla de escalado desde un nivel local a uno alojado expresada como configuración en lugar de ensamblada a mano. Es la capa por encima de un modelo local, no un reemplazo para él.

El índice de comparación

Bonsai 27B se sitúa en una familia donde cada vecino responde a una pregunta diferente, y estas son las páginas que abordan cada una — ninguna de ellas se vuelve a argumentar aquí.

• Bonsai vs Bonsai 27B — el modelo de gafas de 2 mil millones de parámetros frente a este: dieciséis veces los parámetros y doscientas cincuenta y seis veces el contexto, y por qué el nombre de la familia no aporta ninguna información sobre lo que estás descargando. La página es una entrada de blog aquí, no un modelo alojado, una distinción que conviene tener clara en esta familia.

• Bonsai 27B frente a Qwen3.8-27B — el cara a cara entre este modelo y la base más reciente que no utiliza. Una página dedicada de este lote contiene esa comparación y, como los dos modelos responden a nombres similares y están a una generación de distancia, merece la pena leerla por derecho propio en lugar de como una extensión de esta especificación.

• Bonsai vs Ternary Bonsai 2 27B — el salto generacional y el hecho de que los dos lanzamientos reporten su calidad con dos varas de medir distintas: la retención de una línea base en un caso y una afirmación comparativa en el otro.

• Ternary Bonsai 2 27B — la segunda generación por sí sola, sobre Qwen3.8-27B, para lectores que han decidido que quieren el modelo más nuevo en lugar de este.

Lo que no está resuelto

Todas las cifras de calidad de esta página son de PrismML, medidas en el propio conjunto de 15 benchmarks de PrismML, y nadie fuera de la empresa ha publicado una reproducción de ellas. Esa es la mayor laguna en lo que se sabe sobre Bonsai 27B: las afirmaciones sobre compresión son inusualmente específicas y inusualmente verificables, y siguen sin ser verificadas por un tercero. El proveedor también dice explícitamente que la programación agéntica —flujos de trabajo de horizonte largo, con múltiples archivos, de ejecutar y reparar— no es un objetivo fuerte de esta versión y que una variante ajustada para ello es lo siguiente en la hoja de ruta, lo cual es coherente con las pérdidas en llamadas a herramientas y seguimiento de instrucciones del desglose por categorías anterior. Hasta que exista una evaluación independiente, tanto la cifra de retención como la clasificación de densidad deben leerse como la posición del proveedor y no como un resultado establecido.

Lo que está resuelto es más pequeño y más útil: los pesos existen, los tamaños se pueden verificar contra el listado de archivos, la licencia es Apache 2.0, y los dos paquetes difieren en unos 3,3 GB a cambio de aproximadamente cinco puntos de calidad retenida. Eso basta para elegir entre ellos. Cuál de los dos es el adecuado para ti depende de si tu carga de trabajo se parece más a la aritmética o más al llamado de herramientas, y los números por categoría anteriores son la mejor evidencia disponible para esa decisión hoy.