Review de Bonsai 27B: ¿Puede un LLM de 27B Ejecutarse en un Móvil?

Sí, un modelo de la clase 27B ya puede ejecutarse en un móvil, pero la respuesta útil necesita más contexto que el titular. PrismML afirma que los pesos de lenguaje de 1 bit de Bonsai 27B ocupan unos 3,9 GB y generan aproximadamente 11 tokens por segundo en un iPhone 17 Pro Max. El modelo deriva de Qwen3.6-27B y se publica bajo Apache 2.0. Es un hito real de IA on-device, no una prueba de que cualquier workload de 27B quepa cómodamente en cualquier teléfono.

La evidencia también muestra dónde afecta la compresión. En la suite propia de 15 benchmarks de PrismML, la variante de 1 bit obtiene el 89,5% de la media a precisión completa. Matemáticas y coding retienen más que seguimiento de instrucciones, visión y uso de tools en varios pasos. La variante ternaria conserva el 94,6%, pero su despliegue GGUF actual ocupa unos 7,2 GB. Los 5,9 GB repetidos en muchos posts son el tamaño ideal de la representación, no el footprint desplegado hoy.

¿Qué es Bonsai 27B?

Bonsai 27B es la versión low-bit de PrismML de Qwen3.6-27B, un modelo denso y multimodal con backbone de lenguaje de 27B, encoder de visión y ventana nativa de 262.144 tokens. La arquitectura de Qwen usa atención lineal en la mayoría de bloques y atención completa en 16 de 64. Ese diseño híbrido limita el crecimiento de la KV cache frente a un modelo basado solo en atención completa.

PrismML publica dos puntos de operación. El modelo de 1 bit usa pesos binarios de {−1, +1} con un factor de escala FP16 por cada grupo de 128 pesos. El resultado son 1,125 bits efectivos por peso y unos 3,9 GB de pesos de lenguaje. El modelo ternario añade cero, con {−1, 0, +1}. Sus 1,71 bits efectivos por peso compran más calidad a cambio de más memoria.

No es solo exportar un checkpoint FP16 normal a un fichero genérico de 1 bit. PrismML afirma que los pesos low-bit cubren embeddings, proyecciones de atención, MLP y el head del modelo. Kernels específicos para CUDA, Metal, MLX y WebGPU consumen los pesos empaquetados directamente, sin expandirlos de nuevo a FP16 en cada operación.

¿Cómo baja un modelo de 27B de 54 GB a 3,9 GB?

La cuenta FP16 es sencilla: unos 27.300 millones de parámetros de lenguaje multiplicados por dos bytes son aproximadamente 54 GB antes del overhead de ejecución. El modelo binario guarda un bit de signo por peso y una escala de 16 bits compartida cada 128 pesos. Eso da 1,125 bits por peso, unas 14,2 veces menos que FP16.

El tamaño del modelo no es el consumo total de la aplicación:

• Pesos residentes: unos 3,9 GB para 1 bit y unos 7,2 GB para el GGUF ternario actual.
• Runtime y activaciones: las mediciones publicadas incluyen alrededor de 1,3 GB entre backends.
• KV cache: crece con el contexto activo. Incluso con caché KV de 4 bits, la ventana completa de 262K lleva la variante de 1 bit a unos 9,4 GB de pico.
• Componentes opcionales: la proyección de visión compacta ocupa unos 0,63 GB. El drafter de speculative decoding también añade memoria.

Esta distinción es comercialmente crítica. Los pesos pueden entrar en el presupuesto de una app móvil mientras que el contexto máximo anunciado no entra. La capacidad debe calcularse con pesos, contexto real y runtime medidos en el dispositivo objetivo.

¿Bonsai 27B conserva realmente el 90% de la inteligencia de Qwen3.6?

Conserva el 89,5% de una media de benchmarks reportada por el fabricante, no el 90% de cada capacidad. PrismML evaluó las variantes en thinking mode sobre la misma infraestructura H100 con EvalScope y vLLM. Las condiciones iguales hacen útil la comparación, pero todavía no existe una reproducción independiente y la media oculta diferencias importantes.

Los resultados individuales lo explican mejor. En 1 bit, MATH-500 baja de 99,40 a 98,00 y BFCL v3 de 77,10 a 70,72. Sin embargo, el benchmark multietapa τ²-Bench cae de 82,90 a 61,34, IFBench de 68,03 a 52,36 y MMMU-Pro de 79,94 a 60,48. La compresión golpea justo donde un agente largo puede acumular errores pequeños.

La propia ficha del modelo dice que el coding agentic de largo horizonte, con varios ficheros y ciclos run-test-repair, todavía no es un objetivo fuerte del release. Esa advertencia pesa más en una compra que el titular redondeado del 90%.

¿Puede Bonsai 27B ejecutarse localmente en móvil y portátil?

Sí, con hardware de gama alta compatible y el runtime correcto. PrismML reporta unos 11 tok/s con MLX Swift en iPhone 17 Pro Max. Para el GGUF de 1 bit, llama-bench indica 26,0 tok/s en M4 Pro, 44,2 en M5 Pro y 66,4 en M5 Max al generar 128 tokens. El GGUF ternario publica 18,0, 26,2 y 44,0 tok/s en esas mismas clases de portátil.

No son cifras intercambiables. Móvil, Metal, CUDA y WebGPU usan kernels, contextos, límites térmicos y protocolos distintos. El procesamiento del prompt y la generación también son fases diferentes. Un decode rápido no garantiza un primer token rápido cuando el input es un documento largo.

¿Son fiables los 90 tokens por segundo en WebGPU?

La demo de Joshua Lochner en Hugging Face confirma lo esencial: Bonsai 27B puede ejecutarse localmente en el navegador con shaders WGSL específicos. La página atribuye la autoría y optimización de los kernels a Fable 5 y GPT 5.6 Sol, con pruebas de corrección y benchmarks por forma antes de incorporarlos. Tras descargar los pesos, el modelo y la conversación permanecen en el dispositivo.

El código público de la demo no acompaña los 90 tok/s ampliamente compartidos con modelo de hardware, versión del navegador, contexto, warm-up ni protocolo repetible. Trátalo como resultado de demo, no como constante de capacidad. Para comprar o construir, mide navegador, GPU, modo de energía, longitud de prompt y output, latencia al primer token, decode sostenido, pico de memoria y thermal throttling.

¿Dónde puede generar valor comercial Bonsai 27B?

• Asistencia privada sobre documentos: resumir, clasificar o extraer datos sensibles sin enviarlos a una API, siempre que el resto de la aplicación también sea local.
• Software offline de campo: ayudar a técnicos, inspectores o equipos móviles con conectividad irregular.
• Features on-device: ofrecer asistencia de texto con latencia local predecible y sin coste de red por token tras el despliegue.
• Routing híbrido: mantener pasos privados y acotados en local, y enviar razonamiento difícil o tools frágiles a un modelo cloud más fuerte.
• Pilotos en una sola máquina: evaluar la clase 27B en portátiles o GPUs modestas antes de comprar un fleet de inferencia.

El producto valioso sigue siendo el sistema alrededor del modelo. Nuestro servicio de habilitación de IA cubre selección de casos de uso, evals, acceso a datos, routing, despliegue, observabilidad y traspaso al equipo. El caso Twinsoft AI muestra por qué el workflow y sus controles crean más valor que el número de parámetros.

¿Qué variante de Bonsai 27B debería elegir una empresa?

Este artículo se limita a la decisión de despliegue de Bonsai. Para elegir entre familias, consulta nuestra comparativa de LLM open-weight de 2026. Para decidir entre hardware y API, usa la calculadora break-even de modelos locales frente a APIs. Separar esas intenciones evita que una review de producto compita con la comparativa de mercado o la economía de infraestructura.

¿Qué debe medir un piloto de Bonsai 27B?

1. Congelar artefacto y runtime: registrar revisión de Hugging Face, hash, fork, commit de kernels, dispositivo, OS y versión de MLX o navegador.
2. Medir toda la memoria: incluir pesos, runtime, contexto esperado, formato KV, visión y drafter opcional.
3. Crear una evaluación propia: al menos 50 a 100 tareas reales con formatos, tools, rechazos y fallos inaceptables.
4. Separar fases de latencia: medir primer token, procesamiento del prompt, decode sostenido y runs calientes repetidos.
5. Verificar offline y privacidad: revisar descargas, analítica, crash reporting, logs, embeddings y fallback.
6. Calcular resultados exitosos: comparar soporte de dispositivos, ingeniería, distribución de updates, monitoring y fallback con una API.
7. Diseñar rollback: conservar un modelo estable y una ruta de servidor para hardware incompatible, sobrecarga o fallos de calidad.

Nuestra guía para elegir el stack de un MVP usa la misma regla: decidir primero por el constraint caro de revertir. En IA on-device suele ser el hardware mínimo soportado y la calidad del workflow crítico más débil, no el tamaño de descarga.