OPTIC comprime 100 veces los per-layer embeddings de Gemma 4 E4B y conserva el 97,8% de la calidad

Investigadores de VILA-Lab han demostrado que las tablas de per-layer embeddings (PLE) de Gemma 4 E4B pueden comprimirse unas 100 veces con una pérdida de calidad casi imperceptible. El método OPTIC conserva el 97,8% del rendimiento del modelo BF16 sin comprimir, en el agregado de siete benchmarks. El mejor de seis cuantizadores clásicos, la cuantización por producto, logra solo un 66,3% con el mismo nivel de compresión. Al mismo tiempo, en una GPU RTX 4090, el consumo de memoria cae un 29,7%, mientras que el tiempo de ejecución aumenta como máximo un 0,40%.

Por qué las tablas de embeddings se convirtieron en un problema propio

En los modelos de lenguaje se observa una tendencia cada vez más clara: la capacidad crece no solo mediante el cómputo del transformer, sino también a través de los embeddings. Los per-layer embeddings de Gemma 4 son un ejemplo de este enfoque. En la versión E4B representan el 35,2% de todos los parámetros. Es una proporción enorme, y además ocupa memoria, un recurso que casi siempre escasea en los dispositivos.

De ahí surge el desafío: conservar las ventajas de los embeddings grandes y, al mismo tiempo, ajustar el modelo a un presupuesto de despliegue limitado. Con una compresión de 100 veces, los métodos clásicos chocan con un límite. Codifican cada vector token–capa de forma independiente, y a cada vector le quedan apenas unos cinco bytes. Un código tan pequeño no puede transmitir mucha información. Además, la relación entre capas queda completamente sin aprovechar.

Un código por token en lugar de un código separado por cada capa

OPTIC (Output-Path-fitted, Token-shared Indexed Codes) funciona de otra manera. Para cada token se almacena una única tupla de códigos cuantizados, compartida entre todas las capas. En cada capa, un decodificador afín propio la despliega y reconstruye el vector específico de esa capa. El presupuesto de bytes se gasta una sola vez por token y se distribuye entre las capas.

La segunda parte de la idea tiene que ver con qué se ajusta exactamente. Los códigos y decodificadores no se calibran sobre los vectores almacenados en sí, sino sobre el camino de salida (output path) del PLE: el vector pasa por una puerta (gate) y una proyección de salida, y la compresión se evalúa según el resultado tras esos pasos. La función objetivo coincide con la forma en que el modelo usa realmente los embeddings, por lo que la precisión no se desperdicia en detalles que no afectan al resultado final.

Las cifras del estudio

• Los PLE representan el 35,2% de los parámetros de Gemma 4 E4B.
• Con una compresión de aproximadamente 100x, cada vector token–capa queda reducido a unos cinco bytes.
• BF16 E4B a ~100x: OPTIC conserva el 97,8% de la calidad del modelo sin comprimir (agregado de siete benchmarks). La cuantización por producto, la más fuerte de seis métodos de referencia clásicos, logra un 66,3%.
• A 594x, OPTIC conserva el 90,5%.
• A 1002x, OPTIC conserva el 84,1%.
• La versión oficial de E4B con pesos lineales de 4 bits y activaciones de 16 bits (W4A16): 96,9% con una compresión de PLE de ~100x.
• Inferencia de BF16 E4B a partir de códigos compactos a ~100x: 29,7% menos memoria de GPU con el mismo caché KV (1 GiB), con una ralentización no superior al 0,40%. Medición realizada en una RTX 4090.

El trabajo con W4A16 merece una atención especial. La cuantización de los pesos del backbone y la compresión de los PLE resuelven partes distintas del problema, y el resultado del 96,9% muestra que ambas se suman: OPTIC no obliga a elegir entre una u otra.

A quién le servirá esto, y cuándo

La principal conclusión práctica para quienes despliegan Gemma 4 E4B en hardware de consumo es que los PLE dejan de ser un gasto de memoria inevitable. El ahorro del 29,7% de VRAM con el mismo caché KV significa poder ejecutar el modelo en una tarjeta más pequeña o disponer de más espacio para el contexto. La ralentización, de hasta un 0,40%, resulta prácticamente imperceptible.

Para los desarrolladores que construyen productos de IA en dispositivos, también resulta interesante el principio en sí. Si las arquitecturas siguen aumentando la proporción de embeddings dentro de los parámetros, serán precisamente ellos los que haya que comprimir. Un código compartido por token, con decodificadores propios para cada capa y un ajuste orientado al camino de salida, ofrece una plantilla funcional para este tipo de modelos.

Los autores (Jiacheng Liu, Yaxin Luo, Xiaohan Zhao, Peng Sun, Xinyi Shang, Jiacheng Cui, Yonina C. Eldar y Zhiqiang Shen) publicaron el código y un análisis del método en GitHub, en el repositorio VILA-Lab/optic. Un artefacto listo para usar, con compresión de 100x de los PLE, está disponible en Hugging Face bajo el nombre gemma-4-E4B-it-OPTIC-100x, por lo que el resultado puede verificarse en tareas propias. El preprint está disponible como arXiv 2610.31309.