Intel aprieta un LLM ternario a 1,485 bits por peso sin tocar los pesos
El formato BITCOS separa los ceros del resto de pesos y baja de 1,58 a 1,485 bits por peso sin reentrenar el modelo ni alterar su salida. La decodificación mejora hasta un 18% en CPU y un 27% en GPU.
Intel ha encontrado la forma de almacenar un modelo ternario por debajo de los 1,58 bits por peso sin cambiar un solo peso ni reentrenar nada. El formato se llama BITCOS, comprime un checkpoint a 1,485 bits por peso y acelera la decodificación hasta un 18% en CPU y un 27% en GPU. La clave es que ese 1,58 asume que los tres valores posibles aparecen con la misma frecuencia, y en la práctica no ocurre: sobran ceros.
De dónde sale el 1,58
Un modelo ternario solo usa tres valores de peso: -1, 0 y +1. Los 1,58 bits son el mínimo teórico para representar tres opciones equiprobables. El almacenamiento real va por otro camino: el método habitual mete cinco valores ternarios en un byte de ocho bits, 1,6 bits por peso. Como los pesos se guardan en bloques de 128, el último byte queda a medias y la tasa efectiva sube a 1,625 bits.
Los investigadores midieron la distribución de pesos en 29 checkpoints de siete familias ternarias. Los ceros suponían entre el 29,7% y el 51,5% del total. En 26 de esos checkpoints había ceros suficientes para que BITCOS ganara al empaquetado de cinco trits. El caso más disperso, una versión ternaria de Qwen3-1.7B producida con cuantización post-entrenamiento CAT-Q, tenía un 51,48% de ceros y bajó a 1,485 bits por peso.
Dos flujos y un bit de presencia
BITCOS divide los pesos en dos corrientes: una asigna un bit a cada peso para marcar si es cero o no, y otra da un bit de signo solo a los que no son cero. Un peso positivo o negativo consume dos bits; un cero necesita únicamente el bit de presencia, porque no tiene signo que guardar. Con z como proporción de ceros, el coste es 2 − z bits por peso, así que el formato empieza a ganar al empaquetado de cinco trits cuando más del 37,5% de los pesos son cero. Al descomprimir se recuperan los valores -1, 0 y +1 originales, de modo que la precisión no se toca.
Intel escribió kernels de desempaquetado distintos para CPU AVX-512 y AVX2 y para GPU Xe2. En AVX-512 el kernel usa el bitmap de presencia como máscara y pdep para repartir los bits de signo compactados por las posiciones no nulas; como las Xe2 no tienen una instrucción equivalente, la misma operación se resolvió con una tabla de búsqueda de 2KB. Frente a los kernels de 2 bits, BITCOS va entre un 10% y un 18% más rápido en un servidor Xeon de 64 núcleos, y entre un 2% y un 15% en un Core Ultra 9 de 24 núcleos. En gráficas, la mejora es de un 9% a un 22% en una Arc 140V integrada y de un 2% a un 27% en una Arc Pro B70 dedicada.
No gana en todas partes. En un Lunar Lake de ocho núcleos el kernel fijo de 2 bits fue más rápido con todos los modelos, porque había ancho de banda de sobra y el desempaquetado se convertía en el cuello de botella. En las GPU sí mantuvo la ventaja, aunque el propio solapamiento de la decodificación recortó parte del margen.
El artículo no ha pasado revisión por pares, los cinco sistemas de prueba son Intel y los benchmarks de extremo a extremo cubren siete modelos con batch igual a uno. No hay mediciones en hardware de Nvidia, AMD ni Arm, que es justo donde estaría la pregunta interesante para quien sirve modelos en producción.
