Modelos locales 200B: Bonsai y TurboQuant

Pesos de 1 bit y compresión de KV-cache: El camino hacia modelos locales de 200B+

Ejecutar modelos de IA con 200B+ parámetros localmente se está convirtiendo en un objetivo realista gracias a Bonsai 8B de PrismML y TurboQuant de Google Research. Estas tecnologías reducen drásticamente los requisitos de memoria para los pesos y la KV-cache manteniendo una calidad aceptable. Un análisis de los principios, benchmarks y potencial de escalado.

Bonsai 8B: Representación de pesos de 1 bit

PrismML ha lanzado el modelo de código abierto Bonsai 8B bajo Apache 2.0. La arquitectura base es Qwen3-8B densa, pero todos los pesos (incrustaciones, proyecciones de atención, proyecciones MLP, cabezal LM) se cuantizan en un formato de 1 bit de extremo a extremo. El tamaño del archivo GGUF es de 1,15 GB en comparación con 16,38 GB en FP16, una relación de compresión de 14,2x.

Rendimiento:

• M4 Pro: ~131 tokens/seg
• RTX 4090: ~368 tokens/seg
• iPhone 17 Pro Max: ~44 tokens/seg

En RTX 4090, la velocidad de generación es hasta 6,2 veces más rápida que FP16, con una eficiencia energética 4–5 veces mayor. Benchmarks (promedio en 6 categorías): 70,5 (Bonsai) vs 79,3 (Qwen3 8B), 71,0 (Mistral 3 8B), 67,1 (Llama 3.1 8B). La calidad sigue siendo competitiva a pesar de la compresión extrema.

Principio de cuantización:

Cada peso es de 1 bit (0 ≈ -escala, 1 ≈ +escala), con una escala FP16 por grupo de 128 pesos. Efectivamente 1,125 bits/peso. La inferencia utiliza kernels de descuantización en línea sin materialización a FP16. Requiere bifurcaciones de llama.cpp y MLX con kernels personalizados.

Limitación: La receta de entrenamiento completa no se divulga, mencionando un marco matemático propietario para preservar el razonamiento.

TurboQuant: Comprimiendo KV-cache a 3,5 bits/canal

Google Research propuso TurboQuant para la cuantización extrema de KV-cache sin reentrenar el modelo. El objetivo es minimizar el uso de memoria durante la inferencia, que crece con la longitud del contexto.

Resultados clave:

• 3,5 bits/canal: neutralidad de calidad (sin pérdida en las pruebas de Google)
• 2,5 bits/canal: degradación mínima
• Reducción de memoria de KV-cache de al menos 6x

Ejemplo para Qwen3-235B-A22B (contexto de 128k):

• KV-cache FP16: 23,5 GiB
• TurboQuant 3,5 bits: ~5,1 GiB

Ahorro >18 GiB solo en la caché.

Mecanismo:

• Rotación de datos en un espacio conveniente para la compresión.
• Compensación de errores de cuantización para preservar los cálculos.

El enfoque tiene base matemática, probado en KV-cache.

Combinando enfoques para modelos de 200B+

Combinar la compresión de pesos de 1 bit tipo Bonsai (14,2x) y TurboQuant para KV-cache abre perspectivas para la inferencia local.

Cálculo para Qwen3-235B-A22B (pesos bfloat16 437,7 GiB, contexto 128k):

| Componente | FP16/bfloat16 | Comprimido |

|-----------|---------------|------------|

| Pesos | 437,7 GiB | ~30,8 GiB (14,2x) |

| KV-cache | 23,5 GiB | ~5,1 GiB (3,5 bits) |

| Total | ~461 GiB | ~36 GiB |

Desafíos restantes:

• Sobrecarga en tiempo de ejecución
• Ancho de banda de memoria
• Escalabilidad de 1 bit a 200B+
• Integración de kernels en frameworks principales

Esta combinación desplaza el límite: modelos de 235B de nivel servidor se acercan al hardware de consumo.

Conclusiones clave

• Bonsai 8B reduce los pesos de un modelo de 8B a 1,15 GB (14,2x), velocidad en RTX 4090 es 368 tokens/seg, calidad cercana a la línea base de 8B.
• TurboQuant comprime KV-cache a 3,5 bits/canal sin pérdida de calidad, ahorrando 18+ GiB en contexto de 128k para 235B.
• La combinación produce ~36 GiB para un modelo de 235B en lugar de 461 GiB—un paso hacia gigantes locales.
• Limitaciones: detalles de entrenamiento propietarios, necesidad de kernels personalizados.
• Perspectiva: Desarrollo de alternativas de código abierto para desarrolladores intermedios/senior.

— Editorial Team