Bonsai 2 27B: Compresión casi sin pérdida en una huella 9 veces menor

Artículo original ↗ Discusión en Hacker News ↗

Una nueva versión “Bonsai 2” del modelo de lenguaje Qwen 3.8 27B afirma una precisión casi sin pérdida mientras comprime los pesos en un formato ternario de 5,9 GB, lo bastante pequeño como para ejecutarse en GPU de consumo de 8–16 GB, Apple Silicon e incluso en un navegador web. Los primeros usuarios informan de un rendimiento impresionante para tareas cortas y configuraciones con VRAM ajustada, pero resultados mixtos en trabajos de codificación agentiva más largos, con bucles frecuentes y un rendimiento real peor de lo que sugieren los benchmarks. Gran parte de la conversación se centra en cómo se compara con esquemas de cuantización existentes como Unsloth e ISTA, los límites prácticos del contexto y la VRAM, y si una compresión tan agresiva realmente puede preservar las capacidades del modelo base.

Hardware, VRAM y rendimiento

  • Principal atractivo: modelo derivado de Qwen 3.8 de 27B en ~5,9 GB, lo que hace viables las GPU de 16 GB y el hardware de gama media.
  • Los usuarios informan que lo ejecutan en:
    • NVIDIA: 3070 (8 GB, al límite), 3060 (12 GB), 4090, 5090, 6000 Pro Blackwell, tarjetas antiguas de 16 GB.
    • AMD: 6700 XT, 7900 XT/XTX; la inferencia funciona, pero requiere el fork de Prism, ajustes específicos de HIP y, a veces, rutas más lentas.
    • Apple Silicon: dispositivos M1/M2/M4/M5 ven ~7–40 tok/s, con problemas de la API de “tensor” de Metal en el fork actual.
    • WebGPU / navegador: funciona en navegadores de escritorio; falla o es inestable en algunos teléfonos (p. ej., Pixel 9).
  • Las GPU de 6 GB pueden cargarlo, pero son muy lentas (~0,7 tok/s).
  • El tamaño efectivo de los pesos es de ~5,9 GB, pero se necesita VRAM adicional para la caché KV; 8 GB puede funcionar solo con contextos cortos.

Configuración, herramientas y compatibilidad

  • Los GGUF requieren el fork de llama.cpp de Prism; el upstream de llama.cpp aún no admite el formato ternario.
  • Los usuarios comparten flags de compilación, comandos de servidor y ajustes de cuantización/caché para evitar OOM y mejorar la velocidad.
  • Aún no hay un modelo drafter/speculative-decoding para Bonsai 2; los usuarios de Spark/DGX ven un beneficio limitado de la especulación con n-gramas.

Calidad, afirmaciones de “casi sin pérdida” y benchmarks

  • Los benchmarks en la tarjeta de HF sugieren un rendimiento cercano al de cuantizaciones fuertes de 4 bits, lo que algunos consideran “increíblemente bueno” si es exacto.
  • Varios usuarios informan:
    • Bucle frecuente, especialmente en WebGPU y tareas más largas.
    • Razonamiento a largo plazo notablemente peor, codificación agentiva y recuperación de texto memorizado frente a Qwen 3.8 27B en precisión completa.
    • Buenas salidas cortas y libres, pero decepcionante como agente de programación.
  • Algunos creen que los benchmarks están seleccionados a conveniencia (pocas tareas de contexto largo o multietapa) y que “casi sin pérdida” debe tomarse con escepticismo.

Comparaciones con otras cuantizaciones y modelos

  • Comparado con cuantizaciones de Unsloth (UD-Q4, variantes de 2–3 bits), la cuantización 3-bit de Qwen de ISTA y otros esquemas avanzados (p. ej., AngelSlim).
  • El consenso del hilo: las cuantizaciones ingenuas de ≤4 bpw se degradan rápidamente, pero QAT/PTQ sofisticados (como Bonsai) pueden bajar de 2 bpw; los detalles de implementación son propietarios o complejos.
  • Algunos usuarios ahora prefieren GGUFs alternativos de 3–4 bits (Unsloth, ISTA) por calidad, usando Bonsai principalmente cuando la VRAM es el cuello de botella.

Casos de uso, limitaciones y direcciones futuras

  • Hay gran interés en:
    • Bonsai de clase 8B apto para teléfonos basado en Qwen 3.8.
    • Modelos comprimidos muy grandes (100B+ o variantes Flash/Next) que podrían caber en la VRAM de consumo de gama alta.
  • Múltiples informes señalan que en tareas de codificación “agentivas” reales el modelo se atasca, entra en bucle o no logra decidir un enfoque, mientras que los modelos de frontera en la nube completan las mismas tareas de forma fiable.

Discusión sobre lenguaje y métricas

  • Largo debate secundario sobre frases como “9x smaller”:
    • Algunos sostienen que es matemáticamente absurdo; otros lo tratan como un modismo ampliamente entendido que significa “1/9 del tamaño”.
    • Argumentos similares aparecen en torno a “N× faster” y a elecciones de unidades como mWh/token.