Bonsai 27B: el modelo de 27B parámetros que cabe en 3.9 GB y corre en un iPhone (guía completa)
27B parámetros en 3.9 GB: el modelo que cabe en tu teléfono
El 14 de julio de 2026, PrismML —una spinoff de Caltech respaldada por Khosla Ventures, Cerberus, Google y Samsung— publicó Bonsai 27B, una compresión de Qwen3.6-27B de Alibaba que reduce sus pesos de 54GB (FP16) a solo 3.9GB en 1-bit o 5.9GB en ternary, manteniendo entre 89.5% y 94.6% del rendimiento original. Es el primer modelo de clase 27B que corre en un iPhone: 11 tokens por segundo en un iPhone 17 Pro Max, con 262K tokens de contexto y multimodalidad nativa.
No es un modelo nuevo. Es Qwen3.6-27B con cada peso comprimido a uno de dos valores (1-bit: {−1, +1}) o tres valores (ternary: {−1, 0, +1}). La arquitectura queda intacta. Lo que cambia es cómo se almacenan y computan los pesos. Y el resultado es extraordinario: un modelo que normalmente necesita una workstation GPU ahora corre en un teléfono de bolsillo.
¿Quién está detrás de PrismML?
PrismML salió de stealth en marzo 2026 con $16.25M en seed funding. La empresa se basa en el trabajo del profesor de Caltech Babak Hassibi sobre compresión de redes neuronales low-bit, con la universidad licenciando las patentes exclusivamente a la compañía. Los backers incluyen Khosla Ventures, Cerberus, Google y Samsung.
Según un reporte de CNBC, Apple ya está testeando la tecnología de PrismML. Hassibi confirmó que Apple y otras compañías están evaluando los modelos para velocidad, consumo y rendimiento. Las conversaciones están en etapa "muy early", pero "things are progressing nicely."
Las dos variantes de Bonsai 27B
| Variante | Esquema de pesos | Bits/weight reales | Tamaño en disco | Retención vs FP16 | Casos de uso |
|---|---|---|---|---|---|
| 1-bit Bonsai | {−1, +1} | 1.125 | 3.9 GB | 89.5% | Phone, chat, summarization |
| Ternary Bonsai | {−1, 0, +1} | 1.71 | 5.9 GB (ideal) / 7.2 GB (GGUF real) | 94.6% | Laptop, agentes, coding |
| Qwen3.6-27B Q4_K_XL (ref) | convencional | 5.2 | 17.6 GB | 99.9% | Workstation, máxima calidad |
| Qwen3.6-27B FP16 (ref) | 16-bit | 16.0 | 54 GB | 100% | Servidor, sin compresión |
El detalle honesto del tamaño
El ternary se anuncia como 5.9 GB (el ideal teórico de 1.71 bits/weight), pero el archivo GGUF que descargas hoy es 7.17 GB porque los kernels actuales almacenan a ~2.125 bits/weight. El 1-bit no tiene ese gap: 3.9 GB es tanto el ideal como el tamaño real descargado.
Ambas variantes incluyen opcionalmente:
- Vision tower: 0.63 GB (HQQ 4-bit, se carga solo cuando envías una imagen)
- Speculative decoding drafter: 1.79 GB opcional para menor latencia
Especificaciones técnicas
| Especificación | Valor |
|---|---|
| Modelo base | Qwen3.6-27B (Alibaba) |
| Parámetros totales | ~27.8B (24.8B lenguaje + 0.46B vision + 2.5B embeddings/LM head) |
| Arquitectura | Dense hybrid-attention (~75% linear attention, 25% full attention) |
| Capas | 64 (16 full attention, 48 linear attention) |
| Ventana de contexto | 262.144 tokens (262K) |
| Modalidades | Texto + imagen (input), texto (output) |
| Quantization | 1-bit (1.125 bpw) o Ternary (1.71 bpw) en todo el LM; vision tower a 4-bit HQQ |
| Licencia | Apache 2.0 |
| Fecha de release | 14 de julio de 2026 |
| Formatos disponibles | GGUF (llama.cpp, CUDA, Metal) y MLX (Apple Silicon) |
Por qué el contexto de 262K es viable en un teléfono
Qwen3.6-27B usa hybrid attention: solo 16 de 64 capas generan un KV cache full-attention completo. Las otras 48 capas usan linear attention, que no crece con el contexto. Esto significa que el KV cache total es una fracción de lo que sería en un transformer puro, lo que hace que 262K tokens sean prácticos en hardware consumer.
Benchmarks: qué se preserva y qué colapsa
Promedio general (15 benchmarks, thinking mode)
| Modelo | Tamaño | Promedio | vs FP16 | Densidad (puntos/GB) |
|---|---|---|---|---|
| Qwen3.6-27B FP16 | 54 GB | 85.07 | 100% | 0.051 |
| Qwen3.6-27B Q4_K_XL | 17.6 GB | 84.99 | 99.9% | 0.155 |
| Qwen3.6-27B IQ2_XXS ("2-bit") | 9.4 GB | 72.73 | 85.5% | 0.199 |
| Ternary Bonsai 27B | 5.9 GB | 80.49 | 94.6% | 0.400 |
| 1-bit Bonsai 27B | 3.9 GB | 76.11 | 89.5% | 0.530 |
El dato más revelador: el "2-bit" convencional de Qwen3.6-27B (IQ2_XXS, 9.4 GB) scorea 72.7, mientras que el 1-bit Bonsai a menos de la mitad del tamaño (3.9 GB) scorea 76.1. Bonsai supera al quantization convencional siendo 2.4x más pequeño.
Desglose por categoría: dónde duele la compresión
| Categoría | FP16 baseline | Ternary | 1-bit | Degradación 1-bit |
|---|---|---|---|---|
| Overall | 85.0 | 80.5 | 76.1 | −10.5% |
| Math | 95.3 | 93.4 | 91.7 | −3.8% |
| Coding | 88.7 | 86.0 | 81.9 | −7.7% |
| Tool-calling | 80.0 | 74.0 | 66.0 | −17.5% |
| Instruction following | — | — | — | Degradación significativa |
| Vision | — | — | — | Degradación significativa |
Tool-calling degrada 4.6x peor que math. El 1-bit pierde 14 puntos en tool-calling (80→66), mientras que math apenas pierde 3.6 puntos (95.3→91.7). Esto es crítico: si vas a usar el modelo para agentes con function calling, el 1-bit no es buena opción. Usa ternary.
La razón: la compresión post-training no es uniforme. Degrada más donde la precisión de los pesos estaba haciendo más trabajo. Tool-calling depende de decisiones finas en cada paso; math depende más de razonamiento estructurado que sobrevive mejor a la compresión.
VRAM real: los 3.9 GB no son toda la historia
Los 3.9 GB son solo los pesos. El KV cache crece con el contexto y puede superar el tamaño del modelo. PrismML midió los peaks de memoria con KV cache a FP16:
| Contexto | 1-bit peak (FP16 KV) | 1-bit peak (4-bit KV) | Ternary peak (FP16 KV) |
|---|---|---|---|
| 4K tokens | 5.2 GB | ~4.5 GB | ~8.5 GB |
| 10K tokens | 5.6 GB | ~4.8 GB | ~9.0 GB |
| 100K tokens | 11.6 GB | 6.8 GB | ~14.9 GB |
| 262K tokens (máximo) | ~17.2 GB | 9.4 GB | ~20.5 GB |
BONSAI_KV4=1: no es opcional, es obligatorio
Con KV cache a 4-bit (activado con BONSAI_KV4=1), 100K tokens de contexto caben en 6.8 GB para el 1-bit. Sin esto, los mismos 100K tokens necesitan 11.6 GB. La diferencia es ~5 GB, más que todo el tamaño del modelo.
La regla práctica: fix tu KV cache antes de comprometer tus pesos. El decision ternary-vs-1-bit te compra 2 GB. El decision KV4-vs-FP16 te compra ~6 GB a 100K contexto. Prioriza el KV cache.
Rendimiento por hardware
| Hardware | 1-bit tok/s | Ternary tok/s |
|---|---|---|
| NVIDIA RTX 5090 | 163 | 134 |
| Apple M5 Max | 87 | 58 |
| iPhone 17 Pro Max | 11 | — |
Batería en iPhone
PrismML midió 672 tokens generados por cada 1% de batería en iPhone 17 Pro Max, extrapolando a ~67.000 tokens en una carga completa. El chip hace throttle ligero después de ~5 minutos de uso continuo. A 11 tok/s, es usable para chat y respuestas cortas, pero lento para reasoning traces largos.
Cómo correr Bonsai 27B localmente
Opción 1: llama.cpp (GGUF)
# Descargar el modelo 1-bit (3.9 GB)
huggingface-cli download prism-ml/Bonsai-27B-gguf Bonsai-27B-Q1_0.gguf --local-dir .
# Correr con llama.cpp
./build/bin/llama-cli \
-m Bonsai-27B-Q1_0.gguf \
-p "Explica computación cuántica en términos simples." \
-n 256 \
--temp 0.7 --top-p 0.95 --top-k 20 \
-ngl 99Opción 2: MLX en Apple Silicon
# Descargar el build MLX 1-bit
huggingface-cli download prism-ml/Bonsai-27B-mlx-1bit --local-dir .
# Correr con MLX
python -m mlx_lm.generate \
--model ./Bonsai-27B-mlx-1bit \
--prompt "Explica computación cuántica en términos simples." \
--max-tokens 256Opción 3: Ternary con KV4 para contexto largo
# Descargar ternary GGUF
huggingface-cli download prism-ml/Ternary-Bonsai-27B-gguf Ternary-Bonsai-27B-Q2_0.gguf --local-dir .
# Activar 4-bit KV cache para contexto largo
BONSAI_KV4=1 ./build/bin/llama-cli \
-m Ternary-Bonsai-27B-Q2_0.gguf \
-p "Analiza este repositorio completo..." \
-n 512 \
-c 100000 \
--temp 0.7 --top-p 0.95 \
-ngl 99Opción 4: iPhone via Locally AI
El build MLX Swift (Bonsai-27B-mlx-1bit) está empaquetado en la app Locally AI para iOS. Descarga la app desde la App Store y selecciona Bonsai 27B como modelo.
Repositorios disponibles
| Variante | Formato | Repositorio | Tamaño en disco |
|---|---|---|---|
| 1-bit | GGUF (Q1_0) | prism-ml/Bonsai-27B-gguf | 3.53 GiB |
| 1-bit | MLX (1-bit) | prism-ml/Bonsai-27B-mlx-1bit | 3.92 GiB |
| Ternary | GGUF (Q2_0) | prism-ml/Ternary-Bonsai-27B-gguf | 6.66 GiB |
| Ternary | MLX (2-bit) | prism-ml/Ternary-Bonsai-27B-mlx-2bit | 7.05 GiB |
¿Cuándo usar cada variante?
| Caso de uso | Variante recomendada | Por qué |
|---|---|---|
| Agente local con function calling | Ternary | Tool-calling 74.0 vs 66.0 en 1-bit. Los 2 GB extra valen 8 puntos. |
| Chat / summarization / drafting | 1-bit | Tool-calling irrelevante. 3.9 GB y 163 tok/s en 5090. |
| Coding assistant | Ternary | 86.0 vs 81.9 en coding. La diferencia es real pero no fatal. |
| Math / reasoning | 1-bit | 93.4 vs 91.7. Math barely nota la diferencia. Toma 1-bit y los 2 GB gratis. |
| Phone deployment | 1-bit | Es el único que cabe, a 11 tok/s. Fine para async, painful interactivo. |
| Contexto largo (100K+) | Ternary + BONSAI_KV4=1 | KV cache domina. Fix eso antes de tocar pesos. |
| Máxima calidad, sin compromisos | Qwen3.6-27B Q4_K_XL | 17.6 GB pero 84.99 vs 80.49. 3-5 puntos más alto. |
Comparativa: Bonsai 27B vs otros modelos edge
| Modelo | Parámetros | Tamaño | Contexto | Licencia | Multimodal |
|---|---|---|---|---|---|
| Bonsai 27B (1-bit) | 27B | 3.9 GB | 262K | Apache 2.0 | Sí (imagen) |
| Bonsai 27B (ternary) | 27B | 5.9-7.2 GB | 262K | Apache 2.0 | Sí (imagen) |
| Qwen3.6-27B Q4_K_XL | 27B | 17.6 GB | 262K | — | Sí (imagen) |
| Llama 3.2 3B Q4 | 3B | ~2 GB | 128K | Llama License | No |
| Phi-4 14B Q4 | 14B | ~8 GB | 16K | MIT | No |
| Gemma 3 12B Q4 | 12B | ~7 GB | 128K | Gemma License | Sí (imagen) |
Bonsai 27B ofrece intelligence density (puntos de benchmark por GB) de 0.530 para 1-bit y 0.400 para ternary, frente a 0.155 del Q4_K_XL convencional y 0.051 del FP16. Es el modelo con mayor densidad de inteligencia por GB disponible en su clase.
Cómo funciona la compresión: 1-bit y ternary explicado
Quantization convencional vs Bonsai
La quantization convencional (Q4, Q2, INT8) toma pesos FP16 y los redondea a menos bits. Bonsai va más lejos: cada peso se almacena como un pequeño código entero (un signo para 1-bit, uno de tres valores para ternary) multiplicado por un factor de escala FP16 compartido por grupo de 128 pesos: w_i = s_g × t_i.
Esto permite a PrismML publicar un "true bits per weight" real en lugar de uno teórico: 1.125 bpw para 1-bit (vs 1.0 teórico) y 1.71 bpw para ternary (vs 1.58 teórico, log₂3 ≈ 1.585). Los factores de escala FP16 son los bytes extra que explican la diferencia.
Post-training, no pretraining from scratch
A diferencia de BitNet b1.58 que pre-entrena from scratch con pesos low-bit, Bonsai hace compresión post-training de un modelo ya entrenado (Qwen3.6-27B). Esto es más difícil: la literatura dice que pre-training nativo en low precision generalmente supera al post-training a bit-widths extremos. PrismML logra buenos números con el enfoque más difícil, pero significa que la degradación no es uniforme: golpea más donde la precisión original estaba haciendo más trabajo (tool-calling, vision).
El vision tower se maneja separado
El vision tower (0.46B parámetros) se quantiza a 4-bit con HQQ, no a 1-bit. PrismML encontró que la calidad visual degrada más rápido que la calidad del lenguaje bajo compresión extrema. El vision tower se carga solo cuando envías una imagen, ahorrando 0.63 GB cuando no se usa.
Limitaciones honestas
- Tool-calling colapsa en 1-bit: 80→66 es una caída de 17.5%, 4.6x peor que math. Si tu use case es agéntico, no uses 1-bit.
- Vision e instruction following degradan significativamente en 1-bit. PrismML reconoce esto en su white paper.
- El tamaño del ternary es 7.2 GB real, no 5.9 GB. El 5.9 es el ideal teórico; el GGUF que descargas es más grande.
- KV cache no incluido en el headline. 3.9 GB es solo pesos. Con 100K contexto necesitas 6.8-11.6 GB según configures KV4.
- 11 tok/s en iPhone es lento para reasoning. Thinking mode es donde el modelo gana sus scores, pero a 11 tok/s un reasoning trace largo es painful interactivo.
- No es un nuevo pretrain. Es Qwen3.6-27B comprimido. Si Qwen3.6-27B tiene sesgos o limitaciones, Bonsai los hereda.
- SciCode se mantuvo plano: Artificial Analysis reportó que SciCode (coding eval) pasó de 47 a 45 entre M2.7 y M3, una pequeña regresión que complica el "mucho mejor en coding" narrative.
FAQ
¿Bonsai 27B es open source?
Sí, bajo Apache 2.0. Los pesos están en Hugging Face y son descargables gratuitamente.
¿Puedo correr Bonsai 27B en mi laptop?
Sí. El 1-bit necesita 5.2 GB peak a 4K contexto (cabe en 8 GB RAM). El ternary necesita ~8.5 GB (cabe en 12 GB). Con BONSAI_KV4=1, el 1-bit maneja 100K tokens en 6.8 GB.
¿Realmente corre en un iPhone?
Sí, el 1-bit corre en iPhone 17 Pro Max a 11 tok/s via la app Locally AI. El iPhone 17 Pro Max tiene 12 GB RAM, de los cuales ~6 GB son accesibles para una app. Los 3.9 GB de pesos + KV cache + runtime caben.
¿Es mejor que un Q4 convencional?
En densidad de inteligencia, sí. El 1-bit Bonsai a 3.9 GB scorea 76.1 vs 72.7 del IQ2_XXS "2-bit" a 9.4 GB. Pero el Q4_K_XL a 17.6 GB scorea 84.99, 9 puntos más alto. Bonsai gana donde el tamaño importa más que la calidad absoluta.
¿Puedo usar Bonsai 27B para agentes?
El ternary sí (tool-calling 74.0). El 1-bit no es recomendable para agentes (tool-calling cae a 66.0). Si necesitas function calling confiable, usa ternary.
¿Qué modelo base usa Bonsai 27B?
Qwen3.6-27B de Alibaba, un modelo dense hybrid-attention con ~75% linear attention y 25% full attention. La arquitectura no se modifica, solo se comprimen los pesos.
¿Apple va a usar Bonsai?
Apple está testeando la tecnología de PrismML según CNBC. El CEO de PrismML confirmó las conversaciones pero las calificó como "muy early". No hay anuncio oficial de integración.
¿Bonsai 27B soporta video input?
El modelo base Qwen3.6-27B soporta imagen como input. PrismML mantiene el vision tower a 4-bit HQQ. No hay confirmación explícita de soporte de video en Bonsai 27B.
Conclusión
Bonsai 27B es un hito en compresión de modelos de IA. PrismML demostró que un modelo de 27B parámetros puede comprimirse a 3.9 GB manteniendo 89.5% del rendimiento original, corriendo en un iPhone a 11 tok/s con 262K tokens de contexto. La densidad de inteligencia por GB (0.530) es la más alta disponible en su clase, superando al quantization convencional por 2.4x a menor tamaño. Pero no es magia: tool-calling degrada 17.5% en 1-bit, el tamaño real del ternary es 7.2 GB no 5.9, y el KV cache puede superar el tamaño del modelo en contextos largos. La recomendación práctica es clara: usa ternary con BONSAI_KV4=1 para agentes y coding en laptops, usa 1-bit para chat y summarization en phones y máquinas de 8 GB, y usa Q4_K_XL convencional si tienes 18 GB+ y la calidad es no-negotiable. Bonsai abre una categoría que no existía: modelos de clase 27B que corren en tu bolsillo.