Ternary Bonsai 2 27B: qué cabe en 5,9 GB y qué es lo que el 98,2 % no te dice

Ternary Bonsai 2 27B es un modelo de lenguaje multimodal de 27,36 mil millones de parámetros que Prism ML anunció el 17 de septiembre de 2026, y lo que hay que entender sobre él es que sus pesos de lenguaje toman uno de exactamente tres valores. Su modelo base es Qwen3.8 27B —un modelo de 27B con atención híbrida— y Bonsai conserva esa arquitectura, ese entrenamiento y esa forma, y reemplaza los pesos matriciales del modelo de lenguaje por una representación ternaria. El archivo distribuido pesa 5,93 GB. La referencia de precisión completa pesa 53,81 GB. La afirmación principal del proveedor es que conserva el 98,2 % del promedio de benchmarks del original.

Empieza por la parte que la mayoría de la cobertura pasará por alto: ese 98,2 % es el propio número de Prism ML, medido con la propia suite de 20 benchmarks de Prism ML, con el propio harness de Prism ML, y nadie fuera de la empresa lo ha reproducido. Eso no es una acusación —es el estado normal de las cosas un día después de un lanzamiento, y es exactamente el estatus que deberías asignarle. Lo que puedes verificar de forma independiente hoy es el archivo: la API de Hugging Face enumera Ternary-Bonsai-2-27B-PTQ1_0.gguf con 5,947 GB frente a la referencia FP16 de 53,808 GB, lo que supone una reducción de 9,05x y coincide con el "aproximadamente 9x" del proveedor sin necesidad de confiar en nadie. El tamaño es un hecho. La retención de calidad es una medición del proveedor. El material interesante está en el medio —el desglose por categorías, que muestra con precisión dónde la compresión es gratuita y dónde no.

Esta publicación también tiene una segunda cara. El 18 de septiembre, un día después del anuncio, OrcaRouter publicó una variante del mismo modelo abliterada en tiempo de ejecución —la OrcaRouter Ternary Bonsai 2 27B Uncensored—, que elimina una dirección de rechazo aprendida en el momento de la inferencia y deja los pesos idénticos bit a bit. Se trata en su propia sección más abajo, porque la técnica es la parte interesante y porque sus límites son tan instructivos como sus resultados.

Es un Qwen3.8 27B comprimido, no un modelo entrenado desde cero.

Esta distinción es la diferencia entre explicar el lanzamiento y repetir un comunicado de prensa. Prism ML no entrenó un modelo de 27B desde cero ni ejecutó una nueva receta de preentrenamiento. Lo que hizo fue tomar Qwen3.8 27B y cambiar la representación numérica en la que se almacenan y se calculan sus pesos.

La arquitectura no ha cambiado, y es la del modelo base: un diseño de atención híbrida que es aproximadamente 75 % de atención lineal y 25 % de atención completa, con bloques MLP SwiGLU, RoPE y RMSNorm. Ese backbone híbrido también es la razón por la que el contexto de 262K tokens se describe como capaz de contexto completo en lugar de simplemente compatible: la atención mayormente lineal es lo que hace que un contexto largo sea asequible en un dispositivo. El modelo es un modelo de visión-lenguaje: acepta imágenes además de texto, y la torre de visión es la torre Qwen estándar, sin cuantizar, empaquetada por separado.

Lo que Prism ML aportó son dos cosas. La primera es la representación ternaria en sí, más el entrenamiento consciente de la cuantización que la hace viable. La segunda son los kernels: kernels personalizados de bajo bit para esa pila de atención híbrida en Apple Silicon y CUDA, que operan directamente sobre los pesos empaquetados en lugar de desempaquetarlos a FP16 y multiplicarlos. Sin la segunda contribución, la primera es un formato de almacenamiento sin manera de usarlo con rapidez.

El propio whitepaper de Prism ML reporta la división de parámetros como 24.35B en el backbone del lenguaje a lo largo de 64 bloques, 2.54B en el embedding y la cabeza LM, y 0.47B en la torre de visión de 27 bloques, para un total de 27.36B. La torre de visión es la única parte que es genuinamente un artefacto diferente: el lanzamiento de GGUF lo empaqueta como un archivo mmproj de 4 bits de aproximadamente 0.63 GB, cargado solo cuando llega una imagen, por lo que el servicio solo de texto nunca lo carga.

Este es el Bonsai de segunda generación del mismo laboratorio; el primer Bonsai 27B llegó en julio de 2026, aproximadamente dos meses antes, y la comparación entre las dos generaciones es una cuestión razonable —una que abordamos en el cara a cara contra Bonsai 27B en lugar de repetirla aquí.

¿Qué significa "ternary g128", concretamente?

Si nunca antes te has encontrado con pesos ternarios, este es el párrafo que hace legible todo lo demás, así que aquí lo tienes sin abreviaturas.

Un peso ordinario en una red neuronal es un número de coma flotante de 16 bits — alrededor de 65.536 valores distinguibles en un rango útil, y cada uno cuesta 16 bits de almacenamiento. Un peso ternario no es un float pequeño. Es una elección entre tres símbolos: −1, 0 o +1. Ese es todo el vocabulario. Si almacenas uno de esos símbolos de forma ingenua, gastarías dos bits por peso, ya que dos bits te dan cuatro estados y solo necesitas tres.

Por sí solo, eso sería una pérdida catastrófica de expresividad, y es la razón por la que el formato nunca es solo el símbolo. Cada grupo de 128 pesos consecutivos comparte un único factor de escala FP16, y el valor real del peso es el símbolo ternario multiplicado por esa escala:

• w = ssub>g/sub> · t, donde t ∈ {−1, 0, +1} y ssub>g/sub> es una escala FP16 compartida para el grupo de 128

Así que el modelo sigue representando una amplia gama de magnitudes; simplemente las representa en pasos gruesos y por grupos en lugar de uno por cada peso. El 0 no es un artefacto de redondeo; es un tercer estado real, y contar con él es lo que permite que un grupo de 128 pesos permanezca mayormente en silencio cuando hace falta.

La base rotada es la parte que sorprende a la gente. Antes de que ocurra la asignación ternaria, cada matriz de pesos se transforma por bloques mediante una rotación ortogonal —una matriz de Walsh–Hadamard combinada con una diagonal fija de signos ±1, con un tamaño de bloque de 1024— y los valores ternarios se eligen en ese espacio rotado. La rotación se integra en los pesos almacenados durante la preparación, así que no cuesta bits adicionales ni tráfico adicional de pesos. En inferencia, el entorno de ejecución aplica la transformación correspondiente a las activaciones en su lugar, y el modelo empaquetado declara su rotación en sus metadatos, de modo que un entorno de ejecución o bien aplica la transformación correspondiente o se niega a cargar el archivo.

¿Por qué molestarse? Porque una rotación de Hadamard reparte la energía de una matriz de pesos de forma más uniforme entre las coordenadas, lo que hace que la posterior cuantización de tres niveles sea mucho menos dañina de lo que sería sobre la distribución original, llena de picos. La rotación no es un adorno; es la razón por la que un modelo ternario puede conservar algo parecido a la calidad del modelo original. El costo es que la transformada se sitúa en la ruta crítica de cada proyección con tamaño de lote 1, lo que constituye un problema de ingeniería real: Prism ML integra la inversión de signo en la ruta de carga de la transformada en Metal y la paraleliza a lo largo de un bloque de hilos completo en CUDA para evitar que domine la decodificación.

Los números, con cuidado: 1.585, 1.71, 1.72, 1.76

Cuatro cifras de ancho de bits circulan en torno a esta versión, todas son correctas y miden cuatro cosas diferentes. Confundirlas es el error más fácil en esta historia. Aquí está cada una y lo que realmente abarca.

• 1,585 bits por peso — el contenido de información de un símbolo ternario, log₂3. Esto es una propiedad del formato, no de ningún archivo. Nada de lo distribuido funciona a 1,585 bits/peso.

• 1,71 bits por peso — solo los tensores ternarios. Si añades la escala de grupo FP16 de 16 bits amortizada entre 128 pesos, obtienes log₂3 + 16/128 ≈ 1,71. Sigue sin ser una cifra de un producto ya lanzado; son los tensores ternarios en aislamiento.

• 1,72 bits por peso — cada parámetro del modelo de lenguaje, incluido el pequeño conjunto que se mantiene por encima de la representación de bits bajos. Prism ML mantiene 26.238.464 parámetros —el 0,0976 % del modelo de lenguaje, unos 52 MB en bf16— en mayor precisión, principalmente la ruta de estado recurrente de las capas de atención lineal más los pesos de normalización. Esos tensores no se rotan ni se cuantizan, y son los que hacen pasar la cifra de 1,71 a 1,72. Con 1,72, la huella idealizada es de 5,80 GB, una reducción de aproximadamente 9,3 veces. Esta es la fila «True Ternary» de Prism ML, y es un objetivo más que un archivo que se descargue.

• 1,76 bits por peso — el GGUF real que se distribuye. Los kernels eficientes necesitan un formato de empaquetado, y PTQ1_0 de Prism ML empaqueta los trits de forma densa, alcanzando 1,76 bits/peso en 5,93 GB, unas 9,1x. Este es el archivo que respalda tanto el "5,9 GB" como el "9x más pequeño" que cita el anuncio, y es el que confirman las mediciones anteriores.

El segundo empaquetado es PQ2_0, que almacena cada trit en una ranura de 2 bits en lugar de hacerlo de forma densa. Cuesta más espacio a cambio de un desempaquetado más barato: 2,16 bits/peso en 7,25 GB, alrededor de 7,4x. Ninguno de los dos empaquetados es uniformemente más rápido: PTQ1_0 mueve aproximadamente un 18% menos de datos de pesos por paso, pero paga aritmética para desempaquetar trits densos, así que gana en las tarjetas de la generación Ada y en la L4, donde la memoria es la restricción limitante, y pierde en Hopper, Blackwell y Apple silicon, donde, en cambio, la decodificación con lote de 1 está limitada por el rendimiento de instrucciones. El procesamiento de prompts favorece a PQ2_0 en todas partes, porque está limitado por el cómputo.

Dos notas aclaratorias para cualquiera que las coteje con las fuentes. Primero, los propios documentos de Prism ML redondean de forma ligeramente distinta: la tabla de almacenamiento del whitepaper da PTQ1_0 como 1,76 bits/peso con 5,93 GB, mientras que la ficha del modelo GGUF en Hugging Face da 1,75 y 5,95 GB, y el archivo medido es 5,947 GB. Se trata del mismo archivo descrito con distintas precisiones, no una discrepancia de fondo. Segundo, la reducción anunciada de «más de 9x» es la del proveedor; medida con los archivos reales, es 53,808 / 5,947 = 9,05x, lo cual es coherente.

El panorama de referencia: no el promedio, sino la forma

El titular es un promedio de 83,9 frente a 85,4 para la línea base Qwen3.8 27B FP16, que es el 98,2 %. El promedio es la parte menos interesante de todo esto. La forma que hay debajo es donde está la información real, y no es uniforme.

• Seguimiento de instrucciones — 82.66 vs 81.25. Esta es la única categoría en la que el modelo comprimido supera a su modelo padre de precisión completa. No es ruido que alguien pueda explicar a la ligera; es una victoria de categoría en la propia suite del proveedor.

• Matemáticas — 96,57 vs. 97,06, y programación — 81,58 vs. 82,17. Ambos esencialmente a la par: medio punto y seis décimas de punto en los promedios por categoría. Para un modelo con una novena parte de la huella, estos son los resultados en los que se basa todo el argumento de la técnica.

• Conocimiento y razonamiento — 83,95 frente a 86,66. Una caída de 2,7 puntos, y aquí es donde reside una parte significativa de los 1,8 puntos que faltan en el promedio total.

• Visión — 78,59 vs 81,64. Una caída de 3,05 puntos, la mayor pérdida en una sola categoría. Cabe señalar que la torre de visión en sí no es la parte comprimida; lo es el modelo de lenguaje que lee sus salidas.

• Agéntico y llamada de herramientas — 77,57 frente a 79,74. El promedio de la categoría abarca τ 2-Bench con 80,22 y BFCL v3 con 74,92.

Resultados individuales que vale la pena conocer, porque no todos apuntan en la misma dirección. En Terminal-Bench 2.1, el modelo obtiene 52.8 frente a 69.7 de precisión completa —aproximadamente tres cuartos—, y en SWE-bench Verified obtiene 60.8 frente a 80.6, de nuevo alrededor de tres cuartos. Esta fue la primera vez que esta familia de modelos se evaluó en Terminal-Bench, y Prism ML es explícita en que las mejoras de ingeniería de software de largo horizonte que prometió en la primera versión de Bonsai son parciales, no completas. En contraste: τ 2-Bench subió a 80.2 desde 73.6 en la versión anterior, BFCL v3 se mantiene en 74.9, y AA-LCR se sitúa en 77.0, a un punto de la precisión completa. AIME26 alcanza 95.83 y LiveCodeBench, 90.07.

Dónde confiar en él y dónde no. Confía en la forma de los resultados en matemáticas, programación y seguimiento de instrucciones — esas son las categorías donde la técnica hace demostrablemente lo que afirma, y se miden en el mismo arnés de evaluación que la línea base. Sé prudente con el trabajo agéntico de horizonte largo: los dos benchmarks que realmente ponen a prueba la ingeniería sostenida impulsada por herramientas, Terminal-Bench 2.1 y SWE-bench Verified, muestran una brecha materialmente mayor que la que implica el agregado, y el proveedor lo dice en lugar de ocultarlo. Y trata toda la tabla como la medición de un solo laboratorio en un solo arnés de evaluación hasta que alguien más la lleve a cabo. Esa advertencia no es una formalidad aquí — es la diferencia entre «este modelo retiene el 98,2 %» y «el proveedor de este modelo midió el 98,2 % en un conjunto de pruebas que el proveedor eligió». Ambas son ciertas; solo una es un hecho sobre el modelo.

Por qué esto supera a una compilación IQ2_XXS del mismo modelo base

Esto merece su propia sección en lugar de una sola línea, porque constituye todo el argumento a favor del entrenamiento ternario con reconocimiento de cuantización frente a la cuantización posterior al entrenamiento.

La forma convencional de reducir el tamaño de Qwen3.8 27B es cuantizarlo después del entrenamiento. El punto de comparación del informe técnico es una compilación IQ2_XXS GGUF del mismo modelo base:

• Ternary Bonsai 2 27B — 1,76 bits/peso, 5,93 GB, promedio de 20 benchmarks: 83,9

• Qwen3.8 27B IQ2_XXS — 2.2 bits/peso, 7.3 GB, promedio de 20 benchmarks: 75.2

El modelo comprimido durante el entrenamiento es a la vez más pequeño y mejor. Es 1,23 veces más pequeño que la versión convencional de bits bajos y obtiene 8,7 puntos más. Esa combinación no es una curiosidad de redondeo; es la afirmación de que una representación elegida durante el entrenamiento vale sustancialmente más que el mismo presupuesto nominal de bits aplicado después.

La parte más instructiva es cómo falla la versión convencional, porque el fallo es selectivo y fácil de pasar por alto. IQ2_XXS no se degrada de manera uniforme. Se mantiene bien en conocimiento superficial —85,79 en MMLU-Redux— mientras se derrumba en tareas que requieren cadenas de razonamiento sostenidas: 78,6 en AIME26, 70,05 en LiveCodeBench, 65,45 en GPQA Diamond. Bonsai 2 obtiene 95,83, 90,07 y 85,76 en esas mismas tres. Una prueba informal de chat consideraría la versión IQ2_XXS perfectamente utilizable y nunca revelaría el colapso; el daño está exactamente donde ocurren el razonamiento prolongado y la generación de código. Esa asimetría es la razón por la que «me pareció bien cuando lo probé» no es evidencia sobre un modelo cuantizado.

Prism ML comprime el mismo argumento en una única cifra derivada a la que llama densidad de inteligencia —aproximadamente, capacidad de benchmark por gigabyte. En el conjunto de 20 benchmarks, informa 0,444 por GB para Bonsai 2, 0,276 para la compilación IQ2_XXS y 0,051 para FP16. La métrica es una construcción del propio proveedor y su ponderación es una decisión de diseño, no una ley; pero el orden que produce es el mismo orden que produce la tabla sin procesar, así que añade interpretación en lugar de evidencia.

Una nota honesta más sobre la comparación. La tarjeta de modelo GGUF de Prism ML reporta una segunda evaluación, más limitada —una suite de 14 benchmarks en modo de pensamiento— en la que la misma cifra de retención vuelve a aparecer en 84,78 frente a 86,32, con IQ2_XXS en 72,59. Que dos suites diferentes coincidan en el mismo 98,2 % es una corroboración leve de que la afirmación agregada no es un artefacto de la selección de un solo benchmark. Sigue siendo el mismo laboratorio el que ejecuta ambas, en el mismo harness. Nuestro desglose más completo de este enfrentamiento, incluida la cuestión del formato de empaquetado, está en la comparación con las builds GGUF de Qwen3.8 27B.

Lo que realmente se necesita para ejecutar

Las cifras de rendimiento, a partir de la medición estandarizada tg128 del whitepaper con tamaño de lote 1 y con la torre de visión excluida:

• Apple M5 Max — 46,8 tok/s en decodificación, 765 tok/s en procesamiento de prompt

• Apple M5 Pro — 27,7 tok/s en decodificación; una ejecución independiente de ventana más larga del paquete PQ2_0 midió 27,0 tok/s sostenidos, con un consumo de 27,0 W en el riel de la GPU y 32,8 W entre CPU y GPU

• Apple M4 Pro — 18,0 tok/s de decodificación, con el procesamiento del prompt a aproximadamente 125 tok/s convirtiéndose en la restricción determinante para contextos muy largos

• NVIDIA RTX 5090 — 142,5 tok/s de decodificación en el paquete PQ2_0 a 0,582 mWh por token

La afirmación práctica que hace Prism ML no es una relación de aceleración sino una ausencia: la línea base de FP16 con 53.8 GB no cabe en un portátil de 16 GB en absoluto, por lo que la afirmación significativa es que un modelo de clase 27B ahora se ejecuta de forma interactiva en hardware cotidiano. En el M5 Pro, la decodificación medida transmite unos 201 GB/s de pesos, lo que confirma el perfil dominado por el ancho de banda de memoria que la representación de bajos bits está diseñada para aprovechar.

Luego los casos límite, que importan más que las cifras máximas.

No puedes usar el llama.cpp estándar. Los kernels ternarios de atención híbrida viven en el propio fork de llama.cpp de Prism ML. El llama.cpp estándar rechaza los tipos PTQ1_0 y PQ2_0 como desconocidos y, lo que es más peligroso, carga el antiguo formato ternario Q2_0 sin ninguna advertencia y produce basura, porque no tiene un runtime de activación de Hadamard. Si ejecutas este modelo en un binario que no aplica la rotación correspondiente, no obtendrás un error; obtendrás sinsentidos que parecen fluidos. Esta es la forma más probable de perder una tarde con esta versión.

El paquete MLX no tiene ruta CUDA. La versión de MLX (prism-ml/Ternary-Bonsai-2-27B-mlx-2bit) está orientada a Apple Silicon, donde cuenta con kernels personalizados para la pila híbrida tanto en los runtimes de Python como de Swift. Su matmul cuantizada tiene kernels de Metal y CPU, pero ninguna implementación CUDA, así que en una máquina NVIDIA ese paquete en particular no obtiene aceleración por GPU en absoluto. La inferencia en CPU funciona, pero un forward pass de 27B en CPU puede tardar minutos — lo que hace que la ruta de CPU de Linux sea útil para pruebas de implementación y reproducibilidad, e inútil para servir.

Los dos paquetes son un intercambio genuino, no una clasificación. Si usas una tarjeta de la generación Ada o una L4, o si la memoria es la limitación determinante, PTQ1_0 es la opción a elegir con 5,93 GB. Si usas Hopper, Blackwell o una 5090, PQ2_0 te aporta velocidad de decodificación a cambio de 1,3 GB. Si usas Apple silicon, ten en cuenta que las cifras del M5 Pro anteriores se midieron con PQ2_0, que también es el paquete que descarga de forma predeterminada el entorno de demostración.

Una nota sobre la propia contabilidad del paquete MLX, porque es una fuente común de confusión. El contenedor MLX es un formato afín de 2 bits cuyo bloque almacena tanto una escala FP16 y un sesgo FP16 por cada grupo de 128 pesos. Los pesos ternarios de Bonsai solo necesitan la escala —los niveles surgen de la escala por sí sola—, así que el sesgo es peso muerto, y el bloque cuesta 36 bytes por cada 128 pesos en lugar de 34. Eso lleva la tasa empaquetada del paquete MLX a 2,250 bits/peso, no 1,72 ni 1,76. Es un contenedor diferente que transporta los mismos valores ternarios, y su archivo medido en Hugging Face es de 8,005 GiB.

La variante abliterada en tiempo de ejecución

El 18 de septiembre, OrcaRouter publicó el OrcaRouter Ternary Bonsai 2 27B Uncensored, que aplica ablación de la dirección de rechazo a este modelo por completo en tiempo de ejecución. La idea de ingeniería merece más atención que el producto, así que aquí está primero la idea.

La abliteración convencional edita los pesos. Encuentra una dirección en el espacio de activaciones que corresponde al comportamiento de rechazo y luego ortogonaliza contra ella las matrices de pesos que escriben en el flujo residual: W ← W − r(rᵀW). En un modelo FP16 ordinario eso está bien: la matriz editada sigue siendo una matriz densa de punto flotante, así que la guardas y sigues adelante. En un paquete ternario es un callejón sin salida y, en concreto, es un callejón sin salida por la razón por la que existe todo este modelo. Ortogonalizar una matriz ternaria produce una matriz densa de precisión completa. Para volver a almacenarla en el paquete ternario tendrías que recuantizar, y recuantizar pesos editados no reproduce el entrenamiento consciente de cuantización que produjo el original. Tirarías por la borda exactamente lo que se compró.

Así que, en cambio, la proyección se traslada al momento de inferencia. En lugar de cambiar W, cambia su salida:

• y ← y − α · dot(y, r) · r, calculado en float32, donde y es una contribución residual y r es la dirección de rechazo normalizada

Cuando α = 1, se elimina la componente de cada escritura residual paralela a la dirección de rechazo. Cuando α = 0, el modelo no se modifica. Un α mayor que 1 sobreproyecta y puede degradar la calidad. Como α es un parámetro en tiempo de ejecución en lugar de una propiedad del checkpoint, el mismo paquete puede probarse A/B contra sí mismo en el mismo proceso, que es precisamente lo que hacen las evaluaciones de OrcaRouter. El paquete original de Bonsai permanece idéntico a nivel de bits: cero pesos modificados, cero recuantización, cero error adicional de cuantización de pesos.

Hay dos detalles de implementación donde falla una versión ingenua de esto.

129 sitios de intervención, no 16. Todo módulo que pueda escribir en el flujo residual tiene que envolverse, y en esta arquitectura híbrida eso son 64 bloques mlp.down_proj, 48 capas linear_attn.out_proj, 16 capas self_attn.o_proj y model.embed_tokens — 129 en total. Envolver solo self_attn.o_proj es el error obvio y atrapa 16 de ellos, dejando las otras 113 escrituras sin proyectar. Un script de autocomprobación mide si el componente restante a lo largo de la dirección de rechazo se lleva aproximadamente a 1e-6 de la norma residual, y advierte si no detecta los 129 sitios.

No vuelvas a rotar la dirección. El paquete ternario mantiene sus proyecciones en una base rotada sobre su entrada dimensión y compensa en el lado de la activación. La proyección de rechazo opera sobre las salidas de esas proyecciones, que ya están de vuelta en la base oculta normal — así que la dirección de rechazo es un vector ordinario de 5120 dimensiones y aplicarle una rotación de Hadamard adicional la proyectaría contra una base completamente equivocada.

Lo que OrcaRouter midió — nuestras propias cifras, no independientes

Estas son mediciones propias de OrcaRouter basadas en reglas, y deben leerse como tales: un clasificador de frases de apertura basado en reglas, no un juez LLM, pensamiento desactivado, decodificación greedy, presupuesto de 64 tokens, con la base y la versión ablacionada siendo los mismos pesos en el mismo proceso en α = 0 frente a α = 1. Son indicativas, no aptas para publicación, y no son una verificación de nada de lo que Prism ML afirmó.

Sobre el rechazo, medido como la proporción de prompts que recibieron un rechazo:

• AdvBench (n=100) — 99,0 % base, 6,0 % con ablación, con un 56,0 % respondidas, pero envueltas en un descargo de responsabilidad

• JailbreakBench (n=100) — 96,0 % base, 4,0 % con ablación, 52,0 % con salvedades

• StrongREJECT (n=150) — 99,3 % base, 3,3 % con ablación, 45,3 % con salvedades

• HarmBench (n=150) — 98.7% base, 7.3% ablacionado, 48.0% con salvedades

• MaliciousInstruct (n=100) — 97,0 % base, 0,0 % ablacionado, 52,0 % con salvedades

• ForbiddenQuestions (n=150) — 75,3 % base, 5,3 % con ablación, 42,7 % con salvedades

• SimpleSafetyTests (n=50) — 96.0% base, 18.0% ablacionado, 60.0% con salvedades — y esta cifra está subestimada. Ese conjunto se compone mayormente de prompts de autolesión, y el modelo los responde con una apertura de redirección a crisis que dice "I am deeply sorry to hear…", la cual la lista de frases exactas del clasificador no detecta y puntúa como cumplimiento. La tasa real de rechazo residual en ese conjunto es superior al 18.0%. El clasificador se dejó deliberadamente tal cual para que las cifras sigan siendo comparables con las demás tarjetas de modelo de OrcaRouter.

Ninguna respuesta en ningún conjunto agotó su presupuesto de tokens, por lo que ninguna de estas tasas está inflada por truncamiento. En indicaciones benignas, la misma proyección también elimina el exceso de rechazo: XSTest-safe bajó del 5,2% de rechazo al 0,4%, y el subconjunto benigno de JailbreakBench del 25,0% al 0,0%. El paquete publicado rechaza una cuarta parte de las indicaciones benignas de ese benchmark; ablacionado, no rechaza ninguna.

En cuanto a la capacidad, que los pesos sean idénticos a nivel de bits significa que no hay que pagar por una recuantización, y las mediciones son consistentes con eso:

• MMLU (n=300) — 76,7 % base, 77,7 % ablacionado, +1,0

• GSM8K (n=150) — 87,3 % base, 86,0 % ablacionado, −1,3

• CMMLU (n=500) — 76,2 % base, 75,6 % ablacionado, −0,6

Cada movimiento está dentro del ruido con estos tamaños de muestra; una sola pregunta de GSM8K vale 0,7 puntos. MMLU-Pro se excluye en lugar de reportarse: su prompt pide razonamiento antes de la respuesta, y el 63–64 % de las respuestas en ambos lados no lo había alcanzado dentro del presupuesto de tokens, así que cualquier cifra de exactitud sería un límite inferior fijado por el presupuesto en lugar de una medición.

La salvedad que más importa

La dirección de rechazo se estimó a partir del modelo base BF16 con el que se entrenó el Bonsai pack. La arquitectura y la base oculta son idénticas, por lo que la geometría encaja. Pero cuán bien sobrevive esa dirección al entrenamiento consciente de la cuantización no se ha medido por completo.

El runtime puede demostrar, matemáticamente y con una precisión de aproximadamente 1e-6, que elimina la dirección proporcionada de cada escritura residual. No puede demostrar solo con eso que la dirección siga capturando la misma característica de comportamiento en el modelo cuantizado que capturaba en el modelo denso. Son afirmaciones distintas, y solo la primera está resuelta. Cualquiera que lea la tabla de seguridad anterior debería leerla sabiendo que la intervención es exactamente tan eficaz como el supuesto de transferencia de dirección, y ese supuesto es la cuestión abierta.

También está el planteamiento práctico que OrcaRouter hace del propio lanzamiento, que vale la pena repetir en lugar de diluir mediante paráfrasis: eliminar una dirección de rechazo aprendida puede hacer que un modelo responda a solicitudes que el original habría rechazado. Este es un mecanismo de investigación y control de inferencia, no evidencia de que cualquier salida resultante sea segura, correcta o apropiada, y los despliegues que lo utilicen deben aplicar sus propios controles de acceso y aplicación de políticas. Eliminar los rechazos no es una mejora gratuita, y este artículo no está escrito como si lo fuera.

Tres notas prácticas adicionales para cualquiera que lo reproduzca. El paquete debe cargarse con su propio runtime incluido; un cargador MLX común puede parecer que lo carga correctamente mientras calcula silenciosamente algo incorrecto, así que si las salidas parecen incorrectas antes incluso de habilitar la ablación, revisa primero la ruta de carga. Se admite la ablación selectiva por capas, así que la intervención no tiene que ser todo o nada. Y la evaluación de la ablación se ejecutó sobre la expansión FP16 desplegada del paquete en lugar de que el paquete ejecutara sus propios kernels, porque la matmul cuantizada empaquetada no tiene implementación en CUDA y el backend de CPU necesita minutos por pasada forward; esa expansión conserva exactamente los valores ternarios del paquete y reproduce las distribuciones de siguiente token del propio paquete con tres decimales en comprobaciones puntuales, pero es un cambio de contenedor y merece la pena saberlo. El código y las tablas completas están en el repositorio OrcaRouter Ternary Bonsai 2 27B Uncensored. Una comparación aparte que cubre la compilación MLX con ablación frente a la ruta MLX de Qwen3.8 27B sin modificar profundiza más en los detalles específicos del runtime.

Hacia dónde va esto, y qué sigue sin demostrarse

Lo que un modelo de 27B casi sin pérdida en unos seis gigabytes cambia para los agentes locales tiene que ver, sobre todo, con lo que queda residente. Un modelo de lenguaje que cabe junto con una ventana de contexto real en un portátil de 16 GB puede permanecer cargado mientras un agente hace otro trabajo —leer archivos, llamar a herramientas, mantener un plan a lo largo de los turnos— en lugar de intercambiarse en cada solicitud o enviarse a un servidor. Esa es la diferencia entre un modelo local que pruebas y un modelo local que dejas en ejecución, y es la propiedad específica que las métricas agénticas, τ 2-Bench en 80.2 y BFCL v3 en 74.9, están ahí para respaldar.

Lo que no está probado es una lista más larga de lo que implica el anuncio.

• Sin reproducción independiente. Todas las cifras de calidad de este artículo —el 83,9, el 98,2 %, los promedios por categoría— son mediciones propias de Prism ML en el propio conjunto de pruebas de Prism ML. Eso no es un defecto del lanzamiento; es simplemente el aspecto que tiene algo con un día de vida. También es lo primero que cambiará.

• El trabajo agéntico de horizonte largo es la parte más débil de la propia tabla del proveedor, no la más fuerte. Terminal-Bench 2.1 con 52,8 frente a 69,7 es una brecha real, y el proveedor afirma que la capacidad es parcial.

• Prompts que no has probado. El perfil de fallos de los modelos de bits bajos es selectivo, y el colapso de IQ2_XXS en AIME26 y LiveCodeBench mientras mantiene 85.79 en MMLU-Redux es la evidencia más clara disponible de que un promedio de benchmarks no te dice qué ocurrirá con tu carga de trabajo. Bonsai 2 no muestra ese colapso en esos dos benchmarks, lo cual es alentador y no es lo mismo que una garantía.

• La cuestión de la transferencia de dirección en la variante abliterada, arriba, que queda sin resolver por construcción.

• Si los kernels resisten a medida que evolucionan los runtimes. Ahora mismo, este modelo necesita un fork; el llama.cpp estándar rechaza dos de los tres formatos y corrompe el tercero sin avisar. Hasta que esos kernels se integren upstream, «funciona en cualquier lugar donde funcione llama.cpp» aún no es cierto para este modelo.

El lanzamiento en sí no está en duda. Un modelo multimodal de clase 27B con 5,93 GB, a un noveno de la huella de aquello de lo que fue comprimido, con matemáticas y programación a la par del padre y el seguimiento de instrucciones ligeramente por delante, es un punto de operación genuinamente diferente para la inferencia local. La postura razonable el 18 de septiembre de 2026 es tomar el tamaño del archivo como un hecho, tomar la cifra de retención como una afirmación cuidadosa del proveedor hecha un día antes sobre un conjunto de pruebas que el proveedor eligió, y reservar el juicio sobre su propia carga de trabajo hasta que lo haya ejecutado en ella.

El código de ablación en tiempo de ejecución, la dirección de rechazo y las tablas completas de evaluación los publica OrcaRouter, junto con la plataforma de enrutamiento que el equipo desarrolla.