PrismML y Google acercan la inferencia local de modelos de 200B con Bonsai y TurboQuant

La ejecución local de modelos de lenguaje muy grandes deja de ser fantasía para entusiastas con un rack de servidores. Dos enfoques nuevos — pesos de 1 bit de Bonsai de PrismML y compresión de KV-cache TurboQuant de Google Research — atacan directamente las dos partes más costosas de la inferencia: memoria para el modelo y memoria para contexto largo.

Cómo se comprimen los pesos

PrismML presentó Bonsai 8B con licencia Apache 2.0 — un modelo basado en Qwen3-8B, donde casi todos los pesos se almacenan en representación de 1 bit. En términos prácticos, esto significa una caída abrupta en el tamaño: aproximadamente 1,15 GB frente a 16,38 GB para la versión FP16, aproximadamente 14 veces más pequeño.

La empresa enfatiza que esto no es simplement empaquetamiento de archivos. Este formato requiere kernels especiales para evitar desempaquetar pesos de vuelta a FP16 completo durante la inferencia. El esquema parece tosco pero no primitivo: cada peso se codifica como un único bit, y un grupo de 128 pesos obtiene una escala común en FP16.

Como resultado, el costo efectivo resulta ser aproximadamente 1,125 bits por peso. Según las afirmaciones de PrismML, Bonsai 8B produce hasta 368 tokens por segundo en RTX 4090, aproximadamente 131 tokens por segundo en M4 Pro y sigue siendo competitiva en calidad entre modelos 8B, aunque no se convierte en líder absoluta en benchmarks.

Cómo se reduce el KV-cache

Pero los pesos ligeros por sí solos no son suficientes. Los modelos grandes desarrollan rápidamente KV-cache — memoria de trabajo que almacena representaciones de tokens y crece con la longitud del contexto. Aquí es donde Google Research propone TurboQuant.

El método comprime KV-cache sin reentrenamiento del modelo y, según los resultados de los autores, mantiene calidad incluso en el rango de aproximadamente 3–3,5 bits por canal, donde la cuantización ordinaria ya comienza a arriesgar notablemente la calidad de la respuesta. Dentro del enfoque hay dos ideas clave: primero, los datos se rotan hacia un espacio más conveniente donde es más fácil comprimir fuertemente, y luego un paso separado compensa el error de compresión. A través de esto, TurboQuant resuelve no solo la cuestión del tamaño sino también el problema de costos generales que frecuentemente agotan el beneficio de la cuantización vectorial ordinaria.

En las pruebas de Google, el método mostró al menos una reducción de seis veces en la memoria de KV-cache y aceleración de la computación de atención comparada con representación sin comprimir.

Si se combinan los enfoques

La parte más interesante comienza donde estas dos ideas se apilan juntas. Si el enfoque de 1 bit de PrismML alguna vez se escala a modelos de clase 200B+, y TurboQuant preserva sus propiedades en contexto largo, la ejecución local de tales sistemas dejará de ser dominio de servidores con cientos de gigabytes de memoria. Usando Qwen3-235B-A22B como ejemplo, las estimaciones ya no se ven fantásticas sino técnicamente discutibles, pero bastante realistas. Aún no se trata de un producto terminado, sino de la trayectoria del desarrollo de hardware e inferencia.

• Pesos del modelo en bfloat16: aproximadamente 437,7 GiB
• Variante hipotética de 1 bit por analogía con Bonsai: aproximadamente 30,8 GiB
• KV-cache para contexto 128k en 16 bits: aproximadamente 23,5 GiB
• KV-cache con TurboQuant en 3,5 bits: aproximadamente 5,1 GiB
• Total de pesos y caché: en el orden de 36 GiB en lugar de más de 460 GiB

Esto aún no es una promesa de un asistente 235B casero listo. Permanecen preguntas sobre el ancho de banda de la memoria, la calidad de kernels de bajo bit, estabilidad en tareas reales y qué tan bien el esquema de 1 bit se transfiere de 8B a modelos sustancialmente más grandes. Pero la trayectoria está cambiando: anteriormente la conversación era sobre cómo comprimir 7B o 14B para una computadora portátil, ahora ya se está discutiendo si una clase 200B puede llevarse a hardware local.

Qué significa esto

El mercado de LLM local se está desplazando de la optimización cosmética a avances arquitectónicamente significativos en inferencia. Si Bonsai y TurboQuant resultan ser escalables, los ganadores no serán solo entusiastas sino también empresas que necesitan privacidad, baja latencia y ejecución de modelos poderosos sin dependencia constante de la nube. Para equipos corporativos, ya es un camino hacia asistentes locales de una nueva clase en un único nodo poderoso, en lugar de en un clúster separado.