Liquid AI ha publicado en Hugging Face un nuevo lote de checkpoints de la serie LFM2.5, en formato GGUF Q4_0, entrenados con un método llamado QAD (quantization-aware distillation, destilación consciente de la cuantización). Los cuatro tamaños (230M, 350M, 1.2B-Instruct y 2.6B) recuperaron, respectivamente, el 97,1%, el 96,5%, el 97,4% y el 96,6% de sus resultados de referencia en BF16 en las pruebas de evaluación.
Para quien no trabaja con inferencia local, este dato puede no decir mucho. Para entender su alcance, primero hay que saber qué lugar ocupa Q4_0 en el ecosistema de llama.cpp.
Un formato abandonado por la comunidad
Q4_0 es uno de los primeros esquemas de cuantización de 4 bits, con una regla simple: cada 32 pesos comparten un factor de escala, y el resto se comprime directamente a enteros de 4 bits. Más tarde la comunidad desarrolló la serie K-quant (Q4_K_M, Q5_K_M, etc.), que asigna distinto ancho de bits según la importancia de cada tensor y ofrece una precisión claramente mejor para el mismo tamaño de archivo. Eso dejó a Q4_0 prácticamente retirado, sobreviviendo solo en algunos dispositivos y runtimes antiguos.
Aun así, conserva una ventaja que nadie le puede quitar: una estructura regular que se traduce directamente en las instrucciones de producto escalar int8 de las CPU Arm. La división en bloques y las tablas de consulta de K-quant necesitan más rodeos en las CPU de los móviles; Q4_0 no. Las cifras de velocidad que ha presentado ahora Liquid AI apuntan justo a eso: con los mismos modelos, los checkpoints Q4_0 son entre un 4% y un 33% más rápidos que Q5_K_M, y entre un 3% y un 14% más rápidos que Q4_K_M.
Así que lo que siempre había frenado a Q4_0 era la precisión. Y ahí es exactamente donde actúa QAD.
Meter la cuantización dentro del entrenamiento
El enfoque habitual es el PTQ (post-training quantization, cuantización posterior al entrenamiento): el modelo termina de entrenarse, luego se comprime, después se comprueba cuánto rendimiento se ha perdido, y si se pierde demasiado, se cambia de formato y se vuelve a empezar. La idea de QAD es que el modelo sepa, ya durante el entrenamiento, a qué formato se le va a comprimir después: un modelo profesor de alta precisión destila conocimiento hacia un modelo alumno ya cuantizado, la restricción de cuantización forma parte del entrenamiento, y la distribución de los pesos se acerca desde el principio a la retícula de 4 bits. En su blog oficial, Liquid AI lo describe así: "QAD substantially improves the Q4_0 checkpoint" (QAD mejora sustancialmente el checkpoint Q4_0).
No es un concepto nuevo: el entrenamiento consciente de la cuantización lleva años usándose en modelos de visión. La dificultad al trasladarlo a los modelos de lenguaje está en el coste: cada formato objetivo requiere su propia ronda de entrenamiento. Que una empresa esté dispuesta a pagar ese coste indica que ha hecho números. El volumen de descargas y llamadas de los modelos en el dispositivo, al parecer, justifica entrenar específicamente para un formato.
Verificación en cuatro máquinas
Las pruebas cubrieron dos categorías de hardware: MacBook Pro y NucBox EVO-X2 con inferencia en GPU, y Samsung Galaxy S26 Ultra y Raspberry Pi 5 con inferencia en CPU Arm. Que la Raspberry Pi 5 aparezca en la lista llama la atención: representa precisamente el escenario sin GPU y con poca memoria, donde la ventaja de Q4_0 es mayor.
Haciendo un cálculo aproximado: un modelo de 2.600 millones de parámetros almacenado en 4 bits pesa algo más de 1,4 GB; sumando la caché KV y la sobrecarga del runtime, un móvil con 8 GB de memoria todavía puede alojarlo y le queda margen para otras tareas. La versión de 230M, por su parte, se sitúa en unos pocos cientos de megabytes, perfectamente viable para integrarla en una app como función local.
A qué apuesta este lote de checkpoints
La dirección de la disyuntiva es nueva. En los últimos dos años, el enfoque dominante en la inferencia en el dispositivo ha sido reducir el modelo: destilar a menos parámetros o cambiar a un formato de cuantización más inteligente. Esta vez Liquid AI ha elegido una tercera vía: sin cambiar el formato, sin cambiar el número de parámetros, trasladando toda la presión de optimización al lado del entrenamiento.
El precio es que el método solo funciona con sus propios modelos. La comunidad no puede usar esta técnica para salvar pesos Q4_0 publicados por terceros, ya que requiere el pipeline de entrenamiento original. Esto es algo que solo puede ofrecer el propio fabricante del modelo, y es uno de los pocos puntos donde todavía se puede marcar diferencia en la carrera de los modelos pequeños para dispositivo: con el mismo tamaño de 2.600 millones y ejecutándose igualmente en llama.cpp, gana esta ronda quien pierda menos precisión en su versión de 4 bits.
Para los desarrolladores, la barrera de entrada no cambia: GGUF Q4_0 es el formato más universal, y llama.cpp o cualquier runtime compatible con Q4_0 lo cargan directamente, sin tocar código ni añadir nuevos operadores. Esa es también la razón para elegirlo en lugar de un formato personalizado: la propia compatibilidad ya es, en sí misma, capacidad de distribución.
Fuentes: blog oficial de Liquid AI, CocoLoop, página del modelo en Hugging Face; los porcentajes de recuperación de precisión de los cuatro tamaños y los dos rangos de velocidad se han verificado según los datos publicados oficialmente.