Bonsai 2 llegó a Ollama antes de que nadie anunciara que iba a llegar

En algún momento de la madrugada del 17 de octubre de 2026, Ollama comenzó a servir Bonsai 2 — una entrada de biblioteca de nueve etiquetas que abarca Ternary Bonsai 2 2B, Ternary Bonsai 2 4B, Ternary Bonsai 2 9B y Bonsai 2 27B, cada uno en dos empaquetados más un alias predeterminado. Prism ML no ha dicho nada al respecto. No hay ninguna publicación en la página de noticias del proveedor, ninguna línea en el anuncio del 15 de octubre de los modelos pequeños — esa publicación nombra a llama.cpp y MLX como los entornos de ejecución y a una consola alojada como la demostración, y nunca menciona a Ollama en absoluto. El listado simplemente existe, con las nueve etiquetas marcadas con la misma antigüedad de unas pocas horas, que es lo que parece un push reciente y no lo que parece un despliegue gradual.

Así que la división honesta es esta. Lo que se puede saber ahora mismo, a partir del registro y los archivos: las etiquetas, sus nombres, sus tamaños exactos en bytes, sus resúmenes de contenido y —como Ollama distribuye GGUF— la arquitectura y las cadenas de metadatos dentro de los propios pesos. No confirmado: quién los empaquetó, por qué el anuncio del proveedor omite la plataforma, si los kernels ternarios son upstream en el propio motor de Ollama o están vendorizados, y si alguno de los números del proveedor sobrevive el trayecto. Esas son preguntas separadas y este artículo las mantiene separadas.

¿Qué hay realmente en el estante?

Nueve etiquetas, cuatro tamaños, tres empaques de los mismos pesos. La página de biblioteca de Ollama lista un alias predeterminado por tamaño y una -q2_0 variante por tamaño:

• bonsai-2:latest — 3.2 GB, se resuelve al 9B (digest c8b5462f8688)

• bonsai-2:2b y bonsai-2:2b-q2_0 — 911 MB, mismo digest de2ccb4e7328

• bonsai-2:4b y bonsai-2:4b-q2_0 — 1.6 GB, mismo digest 93edd652c932

• bonsai-2:9b y bonsai-2:9b-q2_0 — 3.2 GB, mismo digest c8b5462f8688

• bonsai-2:27b y bonsai-2:27b-q2_0 — 8.3 GB, mismo digest f3c4f4208659

El nombre hace más trabajo de lo que parece. Dos etiquetas por tamaño que comparten un digest no son un duplicado: es una declaración sobre qué empaquetado eligió Ollama. Extrae el manifiesto de bonsai-2:9b y la capa del modelo es de 2,557 GB. Ese es el archivo Q2_0 de Ternary Bonsai 2 9B, medido en Hugging Face en 2,557 GB al byte. El PQ2_0 es de 2,417 GB y el paquete PTQ1_0 —el más pequeño, con 1,997 GB— no está aquí en absoluto.

Esa elección tiene una consecuencia que vale la pena declarar sin rodeos, porque es el tipo de cosa que termina convirtiéndose en un hilo de soporte. En la tarjeta de modelo del proveedor, el llama.cpp upstream ejecuta exactamente uno de los tres empaquetados: Q2_0, "master reciente, que incluye el runtime de activación Hadamard". Rechaza PQ2_0 y PTQ1_0 como tipos desconocidos, porque esos necesitan el fork Prism ML de llama.cpp. Ollama sirve su propio motor. Q2_0 es el paquete que un consumidor de GGUF estándar puede cargar de forma plausible — y Q2_0 es precisamente el paquete que Ollama distribuyó. Que Ollama haya desarrollado sus propios kernels ternarios o enrute a una compilación vendorizada no es algo que el registro te diga. Lo que sí te dice es que no distribuyeron el archivo que no puede cargar.

Los metadatos GGUF te dicen más que la página.

La página de Ollama informa cuatro datos por etiqueta: un tamaño en bytes, una insignia de contexto «256K», un tipo de entrada de texto más imagen y una marca de tiempo relativa. Todo lo demás está dentro del archivo. Leer la cabecera GGUF de cada capa del modelo da lo siguiente, y vale la pena leerla por una razón concreta: es la única parte de esta historia que no es la afirmación publicitaria de alguien.

• general.architecture — qwen35 en los cuatro tamaños

• general.name — Ternary-Bonsai-2-2B, -4B, -9B en los tres pequeños; la capa de 27B reporta la cadena genérica Hf con general.basename = folded

• general.file_type — 41 en los cuatro, con general.quantization_version = 2

• general.size_label — 2B, 4B, 9B, 27B, coincidiendo con los nombres de las etiquetas

• Recuentos de tensores — 320 para el 2B, 426 para el 4B, 427 para el 9B, 851 para el 27B

La cadena de arquitectura es la interesante. qwen35 es el backbone de atención híbrida de Qwen3.5, y confirma desde el propio artefacto lo que las tarjetas del modelo dicen en prosa: los tres pequeños son Qwen3.5-2B, -4B y -9B, con la arquitectura sin cambios y los pesos reemplazados. También deja al descubierto una costura de nomenclatura que las propias notas de lanzamiento del proveedor tapan. La publicación del 15 de octubre dice que los nuevos modelos están «basados en Qwen3.5». El 27B es una base completamente distinta: Qwen3.8-27B, anunciado el 17 de septiembre. Cuatro tamaños, un nombre de familia, dos modelos base. Cualquier cosa que leas sobre el comportamiento de «Bonsai 2» medido en el 27B no se traslada automáticamente al 9B, y la cabecera GGUF es donde puedes ver por qué.

Los metadatos del 27B también son visiblemente menos ordenados que los del resto: general.name = Hf, un general.basename = folded, un general.version = v5, y una clave de muestreo adicional que los tres pequeños no llevan. Eso es lo que parece la salida intermedia de un pipeline de conversión cuando se sube sin una pasada final de cambio de nombre. No es un defecto —los tensores son los tensores—, pero es una huella, y sugiere que la etiqueta del 27B llegó por una ruta diferente a la de los tres pequeños.

Lo que los números de Ollama no significan

Aquí es donde la mayoría de las coberturas de una ficha de biblioteca se equivocan, así que vale la pena ir despacio. Los tamaños en bytes de la página de Ollama son tamaños de contenedor, y en todos los casos son mayores que el archivo del modelo que hay dentro. La etiqueta 2B indica 911 MB frente a una capa de modelo de 0,547 GB y un proyector de visión de 0,365 GB. La etiqueta 27B indica 8,3 GB frente a una capa de modelo de 7,626 GB y un proyector de 0,629 GB. Sume los blobs de licencia y de parámetros y la aritmética cuadra: Ollama está indicando el artefacto completo descargado, torre de visión incluida.

Eso significa que los 3,2 GB de la página de Ollama para el 9B no son comparables con la cifra de "2GB" del proveedor para el mismo modelo, y la diferencia no es una discrepancia que reportar — son dos mediciones diferentes de dos cosas diferentes. Los 0,43 GB / 0,95 GB / 2 GB de Prism ML son solo los modelos de lenguaje. La torre de visión se descarga y se carga solo cuando llega una imagen, por lo que una implementación solo de texto nunca paga por ella, pero un ollama pull sí. Si estás dimensionando un dispositivo según los números del proveedor y luego descargas desde Ollama, estarás entre 0,5 y 1 GB por encima del presupuesto antes de ejecutar nada.

La misma precaución se aplica a la insignia "256K". El contexto subyacente es de 262.144 tokens, heredado del backbone Qwen3.5 —24 capas de atención lineal y 8 de atención completa en el modelo de 9B—, y la insignia de Ollama lo redondea a la baja para mostrarlo. El contexto es real y es heredado, no algo que Ollama haya añadido. Lo que no se indica en ninguna parte de la página es cuánta memoria cuesta un contexto largo y, en un modelo de atención híbrida con una caché de atención completa en un subconjunto de capas, esa no es una cifra pequeña. Nada en la página de Ollama te dice si 262K cabe realmente allí donde pretendas ejecutarlo.

¿Quién empaquetó esto, y tiene importancia?

Sin respuesta, y debería marcarse como sin respuesta en lugar de adivinarse. Tres posibilidades: que Prism ML lo subiera, que Ollama lo extrajera de los repositorios públicos de GGUF del proveedor como parte de su propio trabajo de catálogo, o que lo hiciera un tercero. El registro no puede decirte cuál.

Lo que sí se puede comprobar es la procedencia del artefacto, y coincide. La propia descripción del modelo de Ollama dice: «Bonsai 2 de Prism ML es una familia de modelos de visión creados para pesos ternarios (−1, 0 o +1): aproximadamente la mitad del tamaño de los modelos estándar de 4 bits, con una calidad cercana a la de precisión completa», y enlaza la organización de Hugging Face del proveedor, el whitepaper de Bonsai 2 27B y Apache 2.0. El bloque de licencia incrustado en cada uno de los cuatro manifiestos de tamaño es el texto literal de Apache 2.0. El bloque de parámetros de los 2B, 4B y 9B dice {"presence_penalty":1,"temperature":1,"top_k":20,"top_p":0.95} —que es la receta de muestreo en modo de pensamiento recomendada por el proveedor en las fichas de los modelos, con min_p omitido exactamente tal y como la ficha del 27B dice que lo omiten los archivos GGUF. Eso no es una suposición de nadie; es una conversión que leyó la ficha.

Lo cual es reconfortante y aun así no te dice nada sobre lo que realmente determina tu experiencia: si los kernels ternarios están en el motor que estás ejecutando. La postura honesta es que un pull exitoso demuestra que el archivo es GGUF bien formado, y nada más. Verifícalo en tu propio hardware antes de construir sobre ello.

Las afirmaciones del proveedor, y lo que se ha verificado

Cada cifra de calidad asociada a esta familia proviene de Prism ML, en el propio sistema de evaluación de Prism ML, y ninguna se reproduce de forma independiente. Eso es normal a esta edad y debería decirse en voz alta en lugar de dejarlo implícito. La publicación del 15 de octubre informa de 19 benchmarks en seis áreas de habilidad para los modelos pequeños, con retención frente a las líneas base de Qwen3.5 de precisión completa:

• 2B — agéntico 95,5 %, matemáticas 107,8 %, seguimiento de instrucciones 121,5 %, programación 115,0 %, conocimiento 82,9 %, visión 89,0 %

• 4B — 90,0 % / 99,3 % / 106,0 % / 100,7 % / 90,9 % / 91,3 %

• 9B — 92,4 % / 98,2 % / 100,0 % / 100,1 % / 93,0 % / 92,5 %

Varios de esos superan el 100 %, lo que no es una errata ni un artefacto de redondeo: significa que el modelo ternario obtuvo una puntuación más alta que el modelo de precisión completa del que se derivó en esa categoría. El seguimiento de instrucciones al 121,5 % para el 2B es el ejemplo más llamativo. Hay que tomarlo con la desconfianza que merece: que un modelo comprimido supere su propia línea base en un benchmark seleccionado por el proveedor dice tanto sobre el entrenamiento y el arnés como sobre la representación, y las puntuaciones de la categoría de modelos pequeños son bastante más ruidosas que las del 27B. Las cifras del 27B son más conservadoras y más creíbles en su forma —84,78 frente a 86,32 para FP16, una retención del 98,2 % en 14 benchmarks de modo pensamiento, con matemáticas en 96,57 frente a 97,06 y el nivel de programación en 89,42 frente a 89,07, y la pérdida concentrada en conocimiento/razonamiento y visión—. Cuando una familia cede capacidad bajo una representación de 1,7 bits, ese es el perfil que cabría predecir.

La única afirmación en la publicación sobre el modelo pequeño que no es un benchmark es la que más merece tomarse en serio: el 9B «usa aproximadamente un 40 % menos de tokens en tareas estándar de seguimiento de instrucciones y matemáticas cotidianas». Eso es una afirmación sobre la verbosidad, no sobre la capacidad, y es el tipo de cosa que puedes comprobar en una tarde con tus propios prompts. También se relaciona con una advertencia en las propias fichas de modelo del proveedor —el modo de pensamiento puede consumir más de 3.000 tokens en una pregunta trivial, así que configura al menos 8.192 tokens de salida, y no ejecutes decodificación greedy con el pensamiento activado, porque puede quedarse atascado razonando. Un modelo que es un 40 % menos verboso y que aun así necesita un presupuesto de 8.192 tokens te está diciendo que es verboso en un lugar concreto.

Dónde te deja esto

Si ya ejecutas Ollama y querías probar un modelo de clase 27B en un portátil sin una GPU de centro de datos, las cuatro etiquetas son el camino más corto que existe ahora mismo: una descarga, sin fork, sin compilación de kernel. Si necesitas el empaquetado que es realmente el más pequeño, o los modelos borrador de decodificación especulativa que el proveedor incluye para los 4B y 9B, el listado de Ollama no los tiene — eso es una descarga de Hugging Face y la compilación de llama.cpp de Prism ML, y así ha sido desde el 15 de octubre.

La otra cosa que conviene saber es que lo local no es la única forma de consumir un modelo de bajos bits, y no siempre es la más adecuada. OrcaRouter pone una sola API delante de más de 200 modelos alojados con un 0% de recargo —el precio de lista del proveedor se transfiere tal cual— además de conmutación automática entre proveedores, para que puedas evaluar un modelo con una carga de trabajo real antes de decidir si merece un sitio en tu portátil. Hoy ninguno de los tamaños de Bonsai 2 se sirve a través de OrcaRouter, y este artículo no afirma lo contrario: la familia es una descarga que ejecutas tú mismo, y seguirá siendo así hasta que el proveedor publique un endpoint. Lo que te aporta la capa de enrutamiento es la otra mitad de la decisión: los modelos alojados con los que lo compararás, tras una sola clave, con el DSL de fusión de modelos y enrutamiento disponible cuando un solo modelo no basta.

Qué hay que observar, en orden de cuánto cambiaría el panorama: una etiqueta de Ollama que gane un ptq1_0 hermano, lo que significaría que los kernels dense-trit llegaron al upstream; una publicación de un proveedor que reconozca la plataforma, lo que respondería a la pregunta sobre la procedencia; y cualquier benchmark independiente del 9B o del 27B, que es lo único que movería las cifras de retención fuera de la columna de datos reportados por el proveedor. Hasta que llegue uno de esos, el listado es un mecanismo de entrega, no un modelo nuevo — y el modelo que entrega es público desde el 15 de octubre.

Nada de eso es hipotético: los fallos documentados de IA y los incidentes de agentes detrás de lanzamientos como este se recopilan en el OrcaRouter AI Incident Archive, donde cada entrada incluye sus propias fuentes, severidad, grado de confianza e indicador de disputa.