Un modelo 27B comprimido a dos bits por peso

Un modelo 27B comprimido a dos bits por peso

El 9 de octubre, Underdog AI publicó Saluki 27B, una versión comprimida del modelo Qwen 3.8 27B. La compresión es agresiva: dos bits por peso, lo que empaqueta todo en un archivo de unos 7,89 gigabytes. Underdog afirma que el resultado conserva alrededor del 96 por ciento del rendimiento del original en los benchmarks, y que en tareas de llamada a herramientas supera incluso al modelo de tamaño completo. Se distribuye bajo licencia Apache 2.0 para flujos de trabajo de agentes en local.

Las cifras suenan a error tipográfico. Reducir un modelo a una cuarta parte de su profundidad de bits suele costar mucha calidad. La afirmación de Saluki es que no fue así, y que en la tarea que más importa para los agentes, mejoró.

Por qué la cuantización a dos bits es difícil

Los pesos de un modelo se guardan como números, y el número de bits por peso determina cuánta precisión conserva cada uno. A 16 bits, un peso puede tomar uno de decenas de miles de valores. A dos bits, puede tomar uno de cuatro. Le estás pidiendo a una red construida sobre distinciones finas que se exprese con un vocabulario casi inexistente.

La razón por la que suele fallar es que los errores se acumulan. Redondea cada peso un poco y la capa queda ligeramente desviada. Apila docenas de capas ligeramente desviadas y la salida se aleja mucho del original. La mayor parte del trabajo de cuantización considera cuatro bits como un suelo práctico y acepta cierta pérdida de calidad por debajo.

Los métodos que bajan más no redondean simplemente con más fuerza. Deciden qué pesos pueden permitirse ser toscos y cuáles deben mantenerse finos, y a menudo ajustan después el modelo comprimido para reparar el daño. Hacer que dos bits se sostengan es un proceso cuidadoso y específico, no uno contundente.

El resultado en llamada a herramientas es la parte interesante

Que Saluki iguale al original en los benchmarks generales es notable. Que supere al original en llamada a herramientas es más extraño, y apunta a algo real. La llamada a herramientas es una tarea estructurada: el modelo tiene que emitir un nombre de función y unos argumentos correctos, y pequeñas incoherencias rompen todo. Un modelo un poco más ruidoso puede producir una salida un poco más variada, lo que en este contexto puede significar que tropieza menos en los casos límite.

También hay una explicación más simple. Si el proceso de compresión incluyó un ajuste fino sobre datos de uso de herramientas, el modelo resultante no solo es más pequeño, sino también más estrecho en la dirección correcta. Un especialista puede vencer a un generalista en su especialidad mientras pierde en todo lo demás. La lectura honesta es que Saluki es un modelo comprimido que además fue orientado hacia el trabajo de agente, y los dos cambios juntos explican el resultado.

La densidad de inteligencia es la métrica que importa aquí

Underdog enmarca la mejora como una ganancia de inteligencia por gigabyte, unas 7,5 veces la del original. Ese enfoque es exactamente el correcto para el caso del agente local. Cuando ejecutas un modelo en tu propia máquina, la restricción no es la puntuación del benchmark. Es si el modelo cabe en tu memoria y deja espacio para las aplicaciones que lo rodean.

Un modelo 27B a plena precisión necesita hardware serio. El mismo modelo a unos ocho gigabytes corre en un portátil, y un portátil es donde ocurre de verdad buena parte del trabajo de agente: leer archivos, ejecutar comandos, comprobar resultados. El valor de la compresión no es estético. Es la diferencia entre un modelo capaz que puedes ejecutar en local y un modelo capaz que solo puedes alquilar.

Por qué los modelos de agente locales convergen en este tamaño

Saluki es uno de varios modelos pequeños y de licencia abierta que aparecen para hacer el trabajo repetitivo dentro de sistemas más grandes. El patrón es constante: un modelo de entre unos 7 y 30 mil millones de parámetros, comprimido con agresividad, con licencia permisiva, orientado al bucle ajustado de un agente.

La lógica es la misma cada vez. Un agente llama a su modelo muchas veces por tarea, así que el coste y la latencia por llamada dominan la experiencia. Un modelo lo bastante pequeño para correr en local elimina tanto el viaje de ida y vuelta por la red como la factura por token, y eso cambia con cuánta soltura puedes usar el agente. Dejas de medir a tu propio asistente.

Hay una segunda razón, más silenciosa. Los modelos que corren en local no envían tus datos a ningún sitio, lo cual importa para cualquiera que trabaje con código o documentos que no tiene permitido subir. Para ese público, la compresión no es una optimización de costes. Es la única forma de conseguir un modelo capaz, sin más.

El argumento de los archivos pequeños, en una cifra

Ayuda hacer concreta la diferencia de tamaño. Un modelo de 27 mil millones de parámetros a 16 bits ocupa unos 54 gigabytes antes de cualquier sobrecarga de ejecución. Eso no cabe en la mayoría de los portátiles, y no cabe en la memoria que queda después de que el sistema operativo, un navegador y un editor se lleven su parte. A dos bits, el mismo número de parámetros aterriza cerca de 8 gigabytes, lo que sí cabe, y cabe junto a las herramientas que el agente debe manejar.

Ese es todo el argumento a favor de la compresión de baja precisión en un contexto de agente local. No se trata de ejecutar un modelo que antes no podía ejecutarse en absoluto, aunque eso forme parte. Se trata de ejecutar un modelo con la suficiente comodidad para que el agente pueda llamarlo repetidamente sin que la máquina lo note, porque un agente que ralentiza todo el sistema es un agente que nadie deja encendido.

Qué comprobar antes de creérselo

Los modelos comprimidos merecen un escepticismo concreto. El benchmark de titular puede mantenerse mientras el modelo se degrada en las entradas largas y desordenadas que produce el trabajo real. El daño de la cuantización suele aparecer primero en formatos poco habituales, contextos largos e idiomas raros, y un benchmark corto no captura ninguno de ellos.

También importa qué describe dos bits. La profundidad de bits por peso, los tamaños de grupo y si algunas capas se mantienen a mayor precisión cambian todos el significado de la cifra. Dos bits en un esquema no es lo mismo que dos bits en otro, y la diferencia no se ve en una ficha de modelo.

Qué suma todo esto

El debate de la frontera trata del modelo más grande que alguien puede entrenar. Un debate paralelo, igual de trascendente, trata del modelo más pequeño que sigue siendo lo bastante bueno para resultar útil en tu propio hardware. Saluki 27B se sitúa en el segundo debate, y lanza una afirmación concreta y comprobable: que dos bits bastan para el trabajo que los agentes hacen de verdad.

Si esa afirmación se sostiene fuera del benchmark, baja el suelo de lo que una persona puede ejecutar en local, y es en un suelo más bajo donde suele construirse la siguiente oleada de productos. El modelo no es la historia. El encogimiento del modelo sí lo es.

Vale la pena recordar que este es un campo joven. Los métodos que hacen funcionar los pesos a dos bits todavía se están escribiendo, y cada lanzamiento es tanto una demostración de una técnica de compresión como un producto. Saluki interesa menos por lo que es hoy que por lo que demuestra que ahora es posible hacer pasar por un tubo estrecho. El siguiente modelo de esta línea será más pequeño, más afilado o ambas cosas, y el suelo volverá a bajar.