Durante años, la Inteligencia Artificial generativa se ha asociado a una idea casi automática: servicios en la nube, facturas mensuales y dependencia de APIs. Pero esa narrativa empieza a tener grietas. En un momento en el que empresas y usuarios piden más control sobre sus datos —y menos costes recurrentes—, los modelos “pequeños” y optimizados para ejecutarse en el propio dispositivo están viviendo un nuevo impulso. La última señal llega con LFM2.5-1.2B-Instruct, un modelo de Liquid AI que, según sus creadores, puede ofrecer inferencia de nivel “production-grade” en un teléfono o en un portátil sin GPU dedicada.
La promesa va directa a tres puntos que obsesionan a cualquier equipo técnico: velocidad, memoria y despliegue. En su documentación pública, el modelo se presenta como capaz de decodificar a 239 tokens por segundo en CPU AMD, alcanzar 82 tokens por segundo en una NPU móvil y funcionar con menos de 1 GB de RAM, una combinación que apunta a usos reales fuera del laboratorio: asistentes offline, automatizaciones locales, extracción de datos en campo o herramientas corporativas donde el dato no debe salir del dispositivo.
Un modelo “híbrido” para la era del edge
LFM2.5 forma parte de una familia que Liquid AI describe como “híbrida”, diseñada específicamente para despliegues en edge (móviles, portátiles, sistemas embebidos). En el caso de la variante 1.2B Instruct, la ficha técnica sitúa el modelo en 1,17 miles de millones de parámetros y una arquitectura con 16 capas, combinando bloques convolucionales y atención (GQA), un enfoque que busca equilibrar calidad y eficiencia. En paralelo, la compañía subraya que ha ampliado el entrenamiento previo hasta 28 billones de tokens, además de apoyarse en refuerzo (RL) para mejorar el seguimiento de instrucciones.
Lo relevante no es solo la cifra de parámetros —ya existen muchos modelos en esa liga—, sino la obsesión por el “cómo” se ejecuta en hardware limitado. En su informe técnico, Liquid AI explica que parte del trabajo pasa por optimizar la arquitectura bajo restricciones reales de latencia y memoria, incluso con mediciones “hardware-in-the-loop”, una forma de diseño que acerca el entrenamiento a las condiciones de ejecución finales.
Rendimiento en CPU y NPU: lo que cambia si no hay nube
Los números divulgados por el proyecto buscan un impacto inmediato: un modelo que corre rápido en CPU y que, además, empieza a aterrizar en NPUs (las unidades de procesamiento neuronal que ya llegan en móviles y portátiles). En la propia ficha del modelo se habla de 239 tokens/s en CPU AMD y 82 tokens/s en NPU móvil, manteniendo el consumo por debajo de 1 GB en escenarios de inferencia optimizados.
Esto abre un abanico de usos “sin permiso”: sin claves, sin conectividad, sin depender de un proveedor externo. En entornos corporativos, el atractivo es evidente: hay datos que no deberían salir del endpoint, por cumplimiento o por simple prudencia operativa. En el mundo industrial o de campo —técnicos, logística, mantenimiento—, el argumento también es fuerte: una herramienta local puede funcionar en condiciones de conectividad pobre y seguir siendo útil.
Eso sí: Liquid AI también pone límites a la expectativa. Recomienda el modelo para tareas agénticas, extracción de datos y RAG (búsqueda y respuesta con contexto), pero avisa de que no es la opción ideal para tareas intensivas de conocimiento o programación. En otras palabras: no pretende sustituir a los grandes modelos en todo, sino cubrir bien lo que importa cuando el cómputo y la privacidad mandan.
32.768 tokens de contexto y soporte “día uno” en herramientas populares
Otro dato que apunta a un uso real es la longitud de contexto: la ficha del modelo indica 32.768 tokens, una cifra elevada para un modelo de este tamaño, útil para flujos donde se necesita “leer mucho” (documentación interna, contratos, manuales, incidencias, historiales).
En despliegue, Liquid AI juega una baza pragmática: estar donde ya está la comunidad. LFM2.5 se ofrece en formatos que facilitan el aterrizaje en diferentes entornos, incluyendo GGUF (típico en llama.cpp), ONNX (para runtimes acelerados y portabilidad) y MLX (en Apple Silicon), además del checkpoint “nativo” para frameworks habituales. La compatibilidad declarada con llama.cpp, vLLM y MLX desde el inicio es un mensaje directo a quienes montan pilotos rápidos o prototipos sin querer reescribir media infraestructura.
Además, el modelo se anuncia como multilingüe e incluye español entre los idiomas contemplados, un punto importante para productos que no pueden vivir solo en inglés si aspiran a adoptarse en organizaciones reales.
Qué significa esto para el mercado (y por qué importa ahora)
El debate de fondo no es técnico, sino estratégico: ¿quién paga la IA y dónde viven los datos? La nube seguirá siendo imprescindible para muchos casos, pero el “todo a la nube” empieza a parecer una simplificación cara. Un modelo que puede correr en local con rendimiento alto permite otro tipo de producto: asistentes internos que no filtran información, automatizaciones que no dependen de internet y herramientas que funcionan como una feature del dispositivo, no como una suscripción permanente.
Para el ecosistema de ingeniería, la lectura es clara: el “edge” ya no es un juguete. Si modelos como LFM2.5 cumplen lo que prometen, la próxima ola de aplicaciones de IA podría parecerse menos a un chat en la nube y más a utilidades integradas en el flujo de trabajo: rápidas, privadas y siempre disponibles.
Preguntas frecuentes
¿Qué ventajas tiene ejecutar un modelo de lenguaje en local frente a usar servicios en la nube?
Permite trabajar sin conexión, reduce dependencia de terceros, mejora la privacidad (los datos no salen del dispositivo) y evita costes variables por uso.
¿Para qué tipo de tareas encaja mejor un modelo pequeño como LFM2.5-1.2B-Instruct?
Para automatización agéntica, extracción de información de documentos, asistentes internos y flujos con RAG, donde importa la latencia y el control del dato.
¿Qué hardware hace falta para correr LFM2.5 en un portátil o móvil?
Según la documentación, puede ejecutarse en CPU con un perfil de memoria inferior a 1 GB y también aprovechar NPUs en dispositivos compatibles, lo que lo hace viable en equipos sin GPU dedicada.
¿Qué formato conviene usar si se quiere inferencia local rápida en CPU?
El formato GGUF está orientado a herramientas como llama.cpp y suele ser el punto de partida para despliegues locales eficientes, mientras que ONNX y MLX se usan para portabilidad y optimización en plataformas concretas.
