← Volver al blog

LFM2.5-2.6B: agentes locales cuando la nube no encaja

Publicado el 2026-08-10 · Soluciones GenAI y LLMs

Agentes IA locales con LFM2.5-2.6B para empresas de Gipuzkoa

Liquid AI publicó el 4 de agosto de 2026 en Hugging Face LFM2.5-2.6B, un modelo de 2,6B parámetros pensado para ejecutar agentes locales. La promesa concreta: llamadas a herramientas, flujos de varios pasos y despliegue en hardware cotidiano, desde portátiles hasta móviles, sin depender siempre de inferencia cloud.

La noticia no va de montar un laboratorio de IA en cada mesa. Va de algo más útil para muchas empresas de Donostia - San Sebastián, Gipuzkoa y Euskadi: hay procesos donde enviar todo a la nube no encaja por privacidad, coste, latencia o simple prudencia.

Un agente local no resuelve todos los casos. Tampoco debería venderse como sustituto automático de modelos grandes. Pero sí cambia una conversación que vemos mucho: qué tareas podrían prepararse cerca del dato, con alcance limitado, antes de escalar a una arquitectura más grande.

Qué ha publicado Liquid AI

La publicación presenta LFM2.5-2.6B como un modelo pequeño orientado a agentes. Según el artículo, soporta tool calling y workflows multi-step, y ha sido entrenado con una fase de Agentic Reinforcement Learning dentro de entornos de agente reales.

Hay tres datos que merece la pena separar del ruido.

  • Liquid AI lo sitúa como competitivo con modelos bastante mayores en uso de herramientas, seguimiento de instrucciones y tareas agentic de varios pasos.
  • El despliegue llega con soporte para llama.cpp, MLX, vLLM, SGLang y ONNX.
  • En las pruebas que publica Liquid AI, el modelo alcanza 220 tokens por segundo en un M5 Max y 113 tokens por segundo en un Ryzen AI Max+ 395. También menciona ejecución en móvil alrededor de 30 tokens por segundo.

Son cifras del proveedor, así que conviene leerlas con cuidado. Aun así, apuntan a una dirección clara: los modelos pequeños ya no son solo una opción de emergencia para ahorrar coste. Empiezan a ser una pieza razonable para tareas locales bien acotadas.

La lectura para una empresa de Gipuzkoa

En una pyme industrial, una asesoría, una ingeniería o una empresa de servicios de Gipuzkoa, la IA no siempre puede vivir en el mismo sitio. Hay datos que pueden ir a un proveedor cloud con contrato, controles y trazabilidad. Hay datos que deberían quedarse dentro. Y hay tareas donde ni siquiera hace falta llamar a un modelo enorme.

Piensa en casos bastante normales:

  • clasificar documentos internos antes de que los revise una persona;
  • detectar campos que faltan en una solicitud;
  • preparar un resumen de una ficha técnica local;
  • proponer etiquetas para tickets repetidos;
  • revisar texto sensible sin sacarlo del equipo o del dispositivo;
  • decidir si una tarea merece escalar a un agente más potente.

Ahí un modelo pequeño puede tener sentido. No porque sea mágico, sino porque reduce dependencia externa en tareas estrechas. La clave está en no pedirle lo que no puede dar.

El gancho de negocio: privacidad y coste sin parálisis

Muchas empresas frenan la IA por una razón comprensible: no quieren pegar contratos, listados de clientes, ofertas o documentación técnica en herramientas públicas. La respuesta no debería ser “entonces no usamos IA”. La respuesta sensata es diseñar niveles.

Un primer nivel puede ser local o privado: limpiar datos, clasificar, resumir, detectar riesgo, preparar borradores internos. Un segundo nivel puede usar modelos cloud cuando haga falta más razonamiento, más contexto o una integración más compleja. Y en medio tiene que haber reglas: qué dato sale, qué dato no sale, quién revisa y dónde queda el registro.

Ese enfoque interesa a leads cualificados porque no vende IA como juguete. La baja a una decisión de arquitectura y proceso. Si tu empresa tiene información sensible y aun así quiere automatizar, probablemente no necesita otra demo genérica. Necesita separar tareas, datos y riesgos.

Un piloto razonable: preclasificación de documentos

Un caso pequeño para empezar sería una bandeja de preclasificación de documentos. El flujo podría ser así:

  1. Un documento entra desde email, carpeta compartida o gestor documental.
  2. El modelo local identifica tipo de documento, idioma, datos presentes y datos ausentes.
  3. Si detecta información sensible, marca el caso y evita enviarlo a servicios externos.
  4. Si el documento es rutinario, prepara una ficha para revisión humana.
  5. Una persona valida, corrige y decide si el flujo merece automatizar el siguiente paso.

No es espectacular. Mejor. Los primeros pilotos que funcionan suelen ser aburridos: quitan trabajo repetitivo, no prometen demasiado y dejan claro cuándo una persona debe intervenir.

Qué revisar antes de elegir IA local

Antes de decidir que todo debe ir en local, conviene hacerse preguntas incómodas.

  • Qué datos no pueden salir de la empresa.
  • Qué tareas necesitan respuesta rápida y cuáles admiten espera.
  • Qué precisión mínima necesita el proceso.
  • Qué hardware existe ya y qué habría que comprar.
  • Quién mantiene el modelo, las versiones y los logs.
  • Qué ocurre cuando el modelo no sabe o clasifica mal.

La IA local no elimina el trabajo de diseño. Lo cambia de sitio. Si nadie va a mantener el sistema, medir errores o revisar casos límite, el despliegue local puede acabar siendo otra caja negra, solo que instalada más cerca.

Cómo puede ayudar Umintia

En Umintia ayudamos a empresas de Donostia - San Sebastián, Gipuzkoa y Euskadi a decidir cuándo usar IA local, cuándo usar cloud y cuándo combinar ambas. La decisión no debería tomarse por moda ni por miedo, sino por datos, riesgo, coste y proceso.

Si tu empresa maneja documentación sensible y quiere automatizar sin perder control, el primer paso puede ser una revisión corta: qué procesos usan datos delicados, qué parte puede resolverse localmente y qué piloto tendría impacto en cuatro semanas.

¿Quieres implantar esto en tu empresa?

Cuéntanos tu caso en el chatbot de contacto y revisamos qué piloto de IA tiene sentido para tu equipo.

Abrir formulario de contacto