LFM3-1.7B-Base vs LFM2.5-2.6B-Base: menos parámetros, menos tokens, más contexto

La aritmética va en la dirección equivocada. LFM3-1.7B-Base, publicado el 26 de octubre de 2026, es un 36 % más pequeño que LFM2.5-2.6B-Base, que Liquid AI lanzó el 4 de agosto de 2026 —1730 millones de parámetros frente a 2690 millones—. También se entrenó con menos tokens: 22 billones frente a aproximadamente 34 billones. Según los dos números que la industria suele usar para clasificar modelos preentrenados, el checkpoint más reciente debería ser peor. La afirmación de Liquid es la contraria, al menos para el modelo postentrenado construido sobre él, y la pregunta interesante para cualquiera que elija un tronco para afinar es cuál de esas diferencias es real y cuál es un relato contado con una suite de benchmarks. Ejecutar la comparación debería costar cómputo, no un segundo contrato. 0 % de margen OrcaRouter traslada los precios de lista de los proveedores con un margen del 0 %.

Esta es una comparación dentro de una misma familia, lo que la hace inusualmente limpia. Mismo proveedor, misma familia de licencias, mismo vocabulario de 128.000 tokens, mismo tamaño oculto de 2.048, mismo rol de base a base. Los dos checkpoints difieren en arquitectura, volumen de datos, longitud de contexto y la cantidad de posentrenamiento incorporado en el tronco. Casi todo lo demás se mantiene constante.

El delta, dimensión por dimensión

• Parámetros — 1,73 B para LFM3-1.7B-Base frente a 2,69 B para LFM2.5-2.6B-Base. Una reducción del 35,7 %, que es de donde proviene la frase «35 % menos parámetros» de la publicación de lanzamiento de Liquid.

• Capas — 24 frente a 30. El modelo más reciente es menos profundo y también más estrecho.

• Mezcla de capas — trece convoluciones cortas con compuerta, cinco bloques de atención de ventana deslizante y seis bloques de atención completa para LFM3; veintidós convoluciones y ocho bloques de atención completa para LFM2.5, sin nivel de ventana deslizante.

• Atención — dieciséis cabezas de consulta y cuatro cabezas de clave-valor en LFM3, frente a treinta y dos y ocho en LFM2.5. Ambos mantienen una dimensión de cabeza de 128 y un tamaño oculto de 2.048.

• Ancho de feed-forward — 7.680 para LFM3 frente a 10.752 para LFM2.5. Aquí es donde reside realmente la mayor parte de la reducción de parámetros.

• Caché de convolución — siete para LFM3 frente a tres para LFM2.5, con una ventana deslizante de 256 tokens añadida.

• Contexto — 262.144 tokens frente a 128.000. El checkpoint más reciente lo duplica.

• Tokens de preentrenamiento — 22 billones frente a unos 34 billones, y los últimos 3,5 billones de la ejecución más reciente se dedicaron a datos curados de entrenamiento intermedio, incluidas trazas de agentes y llamadas a herramientas.

• Artefactos — LFM3-1.7B-Base se distribuye únicamente como safetensors BF16, con 3,46 GB. LFM2.5-2.6B-Base se distribuye en Safetensors además de compilaciones GGUF, ONNX y MLX, funciona con menos de 2,5 GB cuantizado y es compatible con Transformers, vLLM, SGLang, llama.cpp y MLX.

Dónde fueron a parar los parámetros

La reducción no se distribuye de manera uniforme, y eso es importante para cualquiera que estime el costo del ajuste fino. Los embeddings están vinculados en ambos modelos y el vocabulario es idéntico con 128.000 tokens, por lo que la matriz de embeddings no cambia. El tamaño oculto no cambia: sigue siendo 2.048. Los ahorros provienen de tres puntos: seis capas menos, la mitad de cabezas de atención y un bloque feed-forward aproximadamente un 29 % más estrecho.

Reducir el bloque feed-forward es la forma más barata de encoger un transformer, porque ese bloque contiene la mayor parte de los parámetros de cada capa. Dividir por la mitad las cabezas de atención reduce tanto la caché de clave-valor como los pesos, y por eso un modelo con el doble de contexto aún puede describirse como que cabe en aproximadamente 1 GB a 4 bits. La contrapartida es la capacidad: un MLP más estrecho tiene menos espacio para almacenar asociaciones factuales, y un número menor de cabezas le da al modelo menos patrones de atención independientes con los que trabajar. El argumento de Liquid es que mejores datos y una mejor mezcla de capas compensan de sobra. Ese argumento es comprobable y, en el momento de la publicación, nadie fuera de la empresa lo ha probado.

De dónde provino el contexto

Duplicar el contexto de 128K a 256K sin duplicar el coste de atención exige no atender de forma global. La pila de LFM3 lo consigue enviando cinco de sus veinticuatro capas a una ventana deslizante de 256 tokens y trece a convoluciones, dejando solo seis capas que ven la secuencia completa. La configuración también incluye un factor rotatorio parcial de 0,5 en las capas de atención global, aplicando embeddings rotatorios a la mitad de las dimensiones de cada cabeza, y un theta rotatorio de un millón en esas capas frente a diez mil en las deslizantes.

La publicación de lanzamiento de Liquid ofrece una cifra concreta de lo que esto aporta: con 128K tokens, la caché KV del modelo de texto es de 1,6 GB. Para LFM2.5-2.6B-Base no se publica ninguna cifra equivalente. Por lo tanto, la comparación es orientativa más que exacta: la arquitectura más reciente está diseñada para mantener un contexto más largo con menos memoria, y la cifra del propio proveedor es la única medición disponible.

Por qué menos tokens es la afirmación interesante

Pasar de treinta y cuatro billones de tokens a veintidós billones supone una reducción del 35 % en el cómputo de preentrenamiento a nivel de datos, y es la dirección opuesta a la de la mayoría de las generaciones de modelos. La historia habitual es más datos, más parámetros, mejor modelo. La historia de Liquid es menos de ambos, con una nueva arquitectura y una mezcla de datos que incorpora artículos científicos, código a nivel de repositorio, matemáticas y una gama más amplia de fuentes de conocimiento.

La etapa de entrenamiento intermedio de 3,5 billones de tokens es lo que distingue este checkpoint de un preentrenamiento convencional. Utiliza datos curados de mayor calidad, con una mayor proporción de trazas agénticas y llamadas a herramientas, y es donde se amplía la ventana de contexto. Esa etapa también es la razón por la que el modelo base incluye una plantilla de chat: los datos de entrenamiento intermedio se formatearon como conversaciones, con y sin trazas de pensamiento.

Nada de esto se puede verificar desde fuera. Los recuentos de tokens son autodeclarados, las mezclas de datos no se publican y no hay ningún estudio de ablación que muestre qué cambio produjo qué mejora. La afirmación es plausible —la calidad de los datos ha superado repetidamente el volumen bruto en los últimos dos años—, pero plausible no equivale a medido.

Lo que una comparación base a base puede resolver

Puede resolver las especificaciones, el costo y la compatibilidad, y esta página lo hace. No puede resolver la calidad, porque ninguno de los dos checkpoint tiene un benchmark publicado. Liquid no publicó ninguna evaluación para LFM2.5-2.6B-Base y tampoco ha publicado ninguna para LFM3-1.7B-Base. Ambas tarjetas recomiendan el checkpoint para un ajuste fino extensivo y remiten a los lectores a otros lugares para el chat.

La única evidencia de calidad en la familia es el par con post-entrenamiento. Liquid informa que LFM3-1.7B obtiene un promedio de 49,37 en su propio conjunto de pruebas frente a 31,55 de LFM2.5-2.6B, y el modelo más nuevo usa un 35 % menos de parámetros. Esa es una gran diferencia, y es una cifra del proveedor medida en un conjunto de pruebas elegido por el proveedor, que compara dos modelos que difieren tanto en el post-entrenamiento como en el tronco. Es evidencia de que la receta de LFM3 produce un mejor modelo instruct. No es evidencia de que el checkpoint base sea un mejor punto de partida, porque el post-entrenamiento sobre él podría explicar toda la diferencia.

Notas de migración para quienes usen LFM2.5

Los dos checkpoints comparten un tamaño de vocabulario, un tamaño oculto y una familia de tokenizadores, lo que hace que la migración parezca más sencilla de lo que es. No comparten código de modelado: LFM2.5 se carga como Lfm2ForCausalLM y LFM3 como Lfm3ForCausalLM, ambos mediante código personalizado con trust_remote_code=True. Un script de entrenamiento escrito para uno no cargará el otro sin cambiar la clase del modelo, y las plantillas de chat difieren en su manejo de los rastros de pensamiento.

La mayor diferencia operativa es el empaquetado. LFM2.5-2.6B-Base tiene builds GGUF, ONNX y MLX, y se ejecuta con llama.cpp, vLLM, SGLang, Transformers y MLX. LFM3-1.7B-Base se distribuye como un único archivo safetensors BF16; las builds cuantizadas y multiplataforma existen para la versión post-entrenada de LFM3-1.7B, no para el checkpoint base. Si tu pipeline depende de un artefacto GGUF, tendrás que convertirlo tú mismo y validar el resultado.

El soporte para el ajuste fino es el contrapeso. LFM3-1.7B-Base enlaza notebooks de TRL para el ajuste fino supervisado y el preentrenamiento continuado, y la documentación cubre el camino a partir de ahí. El checkpoint más pequeño, el contexto de 256K y el entrenamiento intermedio agéntico están todos orientados exactamente al tipo de adaptación de dominio que demuestran esos notebooks.

¿Desde qué tronco empezar?

Empieza desde LFM3-1.7B-Base si estás iniciando un nuevo ajuste fino, tu tarea se beneficia de un contexto largo y puedes trabajar en BF16 con Transformers o convertir los pesos tú mismo. La reducción del 35 % de parámetros es dinero real en una ejecución de entrenamiento con una sola GPU, el contexto duplicado es un cambio real de capacidad y la plantilla de chat acorta la fase supervisada.

Siga con LFM2.5-2.6B-Base si ya tiene un pipeline en funcionamiento, depende de un artefacto GGUF u ONNX, o necesita un checkpoint con un año de herramientas de la comunidad detrás. El modelo más nuevo tiene tres días. Su variante instruct tiene compilaciones cuantizadas y soporte desde el primer día en vLLM, SGLang, llama.cpp, Ollama, LM Studio, MLX y ONNX Runtime, pero el checkpoint base no, y esa brecha es el coste práctico de llegar pronto.

Si tiene dudas, haga el experimento en lugar de leer el marketing. Tome una pequeña muestra de sus propios datos, ejecute la misma receta de preentrenamiento continuado con ambos troncos durante el mismo número de pasos y evalúe con un conjunto reservado que haya creado antes de empezar. Eso son unas pocas horas de GPU y responde una pregunta que ninguna tabla de proveedor puede responder. Cuando existan los dos ajustes finos, coloque ambos detrás de un único endpoint: OrcaRouter, cuyo DSL de enrutamiento puede dividir el tráfico entre ellos, y la conmutación automática por error hace que un mal experimento no se convierta en un mal día de producción. La plataforma transfiere los precios de lista de los proveedores con un margen del 0 %, de modo que el costo de ejecutar la prueba es el costo del cómputo, no el de un segundo contrato.

El número a vigilar

La afirmación que zanjaría esto no es otro promedio. Es una evaluación de modelo base —cualquier evaluación de modelo base— publicada por Liquid o por un tercero, que compare LFM3-1.7B-Base y LFM2.5-2.6B-Base tras aplicar una receta de ajuste fino idéntica. Hasta que eso exista, el delta generacional está documentado en la arquitectura y la configuración, es plausible en los recuentos de tokens y no está demostrado donde importa. El checkpoint más reciente es más pequeño, tiene mayor contexto y está mejor empaquetado para el entrenamiento. Si es mejor es una pregunta que el repositorio no responde.