LFM2.5-Encoders llegan para resolver un problema muy práctico: entender textos muy largos sin romper la billetera ni la latencia. Si trabajas con contratos, transcripciones o hilos de soporte que pasan de miles de tokens, esto es directamente relevante para ti.
Qué son y por qué importan
Son encoders bidireccionales preentrenados en la familia LFM2, disponibles en dos tamaños principales: 230M y 350M parámetros. Están diseñados para mantener buen desempeño en tareas clásicas (GLUE, SuperGLUE y clasificación multilingüe) y, sobre todo, para procesar contexto largo —hasta 8,192 tokens— con una latencia que crece lentamente cuando el input se hace mayor.
¿Por qué esto importa? Muchas aplicaciones de producción (enrutadores de intención, filtros de seguridad, detectores de PII, clasificadores) funcionan todo el día en CPU y reciben documentos largos. Un encoder optimizado para contexto largo puede ahorrar costos significativos y responder en tiempos aceptables en hardware común.
Arquitectura y entrenamiento (resumen técnico)
Los modelos se inicializan desde los backbones decoder de LFM2: LFM2.5-230M y LFM2.5-350M. Para convertir el decoder causal en un encoder bidireccional se hicieron cambios concretos:
- Máscara de atención bidireccional: cada token ve contexto a ambos lados, no solo los previos.
- Convoluciones no causales y padding simétrico: las convoluciones cortas mezclan vecinos a izquierda y derecha.
- Objetivo de masked language modeling: se enmascaró el 30% de los tokens durante el entrenamiento.
El entrenamiento se hace en dos etapas:
- Competencia general: MLM en contexto corto (1,024 tokens) sobre un gran corpus web para aprender idioma y patrones generales.
- Adaptación a contexto largo: extender a 8,192 tokens en la mezcla completa de datos para reforzar competencia factual, legal y multilingüe.
Se reportan resultados finos: cada modelo se fine-tunea por completo en cada tarea y las métricas son la media sobre cinco seeds detenidas, lo que da números estables.
Rendimiento: precisión y velocidad
En accuracy, LFM2.5-Encoder-350M queda cuarto entre 14 modelos probados en 17 tareas. Los tres por delante son modelos más grandes (uno de 3.5B). LFM2.5-Encoder-230M supera a ModernBERT-base y a varios EuroBERT, siendo además más pequeño que la mayoría.
En latencia y throughput es donde destacan:
- Soportan 8,192 tokens. En CPU,
LFM2.5-Encoder-230Mes el más rápido en todos los largos de secuencia medidos. A 8,192 tokens, ModernBERT-base tarda alrededor de 90 segundos por forward, mientras que LFM2.5-Encoder-230M tarda cerca de 28 segundos, es decir aproximadamente 3.7× más rápido. - En GPU el patrón es similar pero con margen menor: ModernBERT domina por debajo de ~1K tokens en Apple GPU, y los LFM2.5 toman la delantera a partir de ~2K tokens.
Traducción práctica: en un laptop CPU puedes clasificar o analizar un contrato completo en menos de 30 segundos con el encoder de 230M. Eso abre posibilidades para pipelines de alto volumen y bajo costo.
Casos de uso y demos prácticas
Liquid AI publica demos que corren en espacios Hugging Face con CPU únicamente. Ejemplos útiles:
- Zero-shot prompt routing: compara un prompt contra varias rutas definidas en texto libre en una sola pasada.
- Zero-shot policy linting: evalúa cada token frente a reglas de empresa escritas en lenguaje natural en una sola pasada.
- Spell checking token a token.
- PII detection para 40 tipos de información en 16 idiomas.
- Masked-diffusion text generation (modo chatbot que va desmascarando tokens iterativamente).
Estos muestran la versatilidad: un encoder bien afinado sirve para clasificación, extracción, scoring y enrutamiento, y suele ser más barato que usar un LLM generativo para tareas de entendimiento.
Cómo empezar (ejemplo práctico)
Instala la última versión de transformers:
pip install -U transformers
Ejemplo mínimo de masked-token prediction:
from transformers import AutoModelForMaskedLM, AutoTokenizer
import torch
model_id = "LiquidAI/LFM2.5-Encoder-230M" # o "LiquidAI/LFM2.5-Encoder-350M"
tok = AutoTokenizer.from_pretrained(model_id, trust_remote_code=True)
mlm = AutoModelForMaskedLM.from_pretrained(model_id, trust_remote_code=True)
text = f"The capital of France is {tok.mask_token}."
enc = tok(text, return_tensors="pt")
with torch.no_grad():
logits = mlm(**enc).logits
pos = (enc["input_ids"][0] == tok.mask_token_id).nonzero()[0].item()
print([tok.decode([t]).strip() for t in logits[0, pos].topk(5).indices.tolist()])
# -> ['Paris', 'Strasbourg', 'Paris', 'Lyon', 'Versailles']
Para tareas downstream, carga solo el cuerpo con AutoModel y agrega tu propia cabeza (clasificación, token classification, regresión, retrieval).
Si tu GPU lo soporta, instala flash-attn para eficiencia adicional:
pip install flash-attn
Liquid AI también ofrece un tutorial de fine-tuning para documentos legales largos con contexto 8k.
Cuándo elegir 230M vs 350M y recomendaciones de despliegue
- LFM2.5-Encoder-350M: elige cuando la prioridad sea precisión máxima y tu hardware lo permita.
- LFM2.5-Encoder-230M: elige cuando necesites más throughput o estés limitado por CPU/memoria.
Si tu tarea es alta frecuencia y corre todo el día en CPUs, un encoder bien afinado suele ser la opción más barata y eficiente frente a un LLM generativo. Para búsqueda multilingüe ya existían los LFM2.5-Retrievers; estos encoders son más generales: clasificación, enrutamiento, extracción y seguridad.
Reflexión final
LFM2.5-Encoders muestran que es posible combinar contexto largo, buena precisión y velocidad en CPU sin caer en modelos enormes. Si tu producto necesita entender documentos largos a escala y con bajo costo operativo, merece la pena probarlos. ¿Vas a probarlos en producción o en una prueba rápida en tu laptop?