ARTEMIS vs LFM2.5-2.6B-Base: el checkpoint que no puede hacer el trabajo, y el harness que necesita que lo haga

Cuatro elementos ocupan la hoja de ruta ARTEMIS de Google, y exactamente uno de ellos requiere un modelo que, obviamente, aún no existe: modelos de visión-lenguaje ligeros en el dispositivo, para una automatización de baja latencia y prioridad a la privacidad. El candidato obvio para un trabajo así es algo de la clase de tamaño de LFM2.5-2.6B-Base — el checkpoint preentrenado de 2,69 mil millones de parámetros de Liquid AI, publicado como pesos abiertos con un contexto de 131.072 tokens y una huella lo bastante pequeña para un teléfono. También es, tal como se distribuye, incapaz de ocupar esa posición, y las razones merecen entenderse antes de que alguien ponga a los dos en una tabla comparativa. ARTEMIS de Google es un arnés de automatización de Android en lenguaje natural, publicado como código abierto bajo Apache 2.0 en agosto de 2026, que controla un teléfono real mediante ADB y afirma una tasa de finalización superior al 99 % en el benchmark AndroidWorld de Google Research. LFM2.5-2.6B-Base es material preentrenado en bruto, sin ajuste por instrucciones, sin plantilla de chat y —deliberadamente— sin benchmarks publicados, pensado para equipos que lo entrenarán posteriormente por su cuenta. Uno es software terminado con un problema de modelo sin terminar. El otro son pesos sin terminar con un problema de licencia ya resuelto. Ninguno sustituye al otro, y el punto donde realmente se encuentran no es el que uno imaginaría.

Qué es realmente LFM2.5-2.6B-Base

Quítale la marca y es una base cuidadosamente construida para el trabajo en el dispositivo, con especificaciones que se leen como si alguien hubiera optimizado el ancho de banda de memoria en lugar de la posición en la clasificación.

• Tamaño — 2,69 mil millones de parámetros en bfloat16 en un único fragmento de ~5,39 GB, comercializado como «2,6 mil millones».

• Arquitectura — 30 capas en una división híbrida: 22 bloques de convolución corta de doble compuerta sobre 8 capas de atención de consultas agrupadas, ancho oculto 2048, 32 cabezas de atención frente a 8 cabezas KV, embeddings vinculados. La misma code>Lfm2ForCausalLM/code> clase que la generación anterior, por lo que no se requiere código de modelado personalizado.

• Entrenamiento — aproximadamente 34 billones de tokens, con una fase dedicada de entrenamiento intermedio para la extensión de contexto.

• Vocabulario — 128.000 tokens, duplicado en esta generación para manejar mejor los alfabetos no latinos. Alrededor de 262 M de parámetros, aproximadamente una décima parte del modelo, residen en el embedding vinculado.

• Contexto — la tarjeta del modelo y la configuración no coinciden aquí, y vale la pena saberlo: la documentación anuncia 131.072 tokens mientras que code>config.json/code> establece code>max_position_embeddings/code> en 128.000. Presupueste para 128K y considere todo lo que supere esa cifra como no verificado.

• Idiomas — dieciséis: inglés, árabe, chino, francés, alemán, hindi, indonesio, italiano, japonés, coreano, polaco, portugués, ruso, español, tailandés, vietnamita.

• Referencias de rendimiento — ninguna. Liquid no publica ninguna evaluación del checkpoint base, y la ficha del modelo presenta la omisión como intencional: este artefacto existe para recibir post-entrenamiento, no para medirse en su estado bruto.

Esa última línea es el punto central del lanzamiento, y también es la razón por la que una "X vs LFM2.5-2.6B-Base" comparación tiene que manejarse con cuidado. Un checkpoint base no tiene opinión sobre nada. Pídele que planifique un flujo de trabajo de Android y continuará tu texto de forma probabilística, porque nunca se le ha enseñado a responder. La ficha lo recomienda solo para casos que requieren un ajuste fino intensivo: un asistente específico de un idioma, uno específico de un dominio en un sector regulado, entrenamiento con datos propietarios o como estudiante de destilación. Para cualquier cosa lista para usar, incluido el uso de herramientas, Liquid te remite al LFM2.5-2.6B post-entrenado en su lugar.

Lo que ARTEMIS necesita de un modelo, que no es lo que ofrece un checkpoint base

ARTEMIS es un bucle de control con dos modos. Flash es un ciclo reactivo de observar y actuar de aproximadamente 3 a 5 segundos por paso. Pro es un grafo multiagente de aproximadamente 15 a 40 segundos por paso, con un Planificador que mantiene un plan Markdown vivo, un Operador con el conjunto de herramientas completo y un Verificador de solo lectura que verifica puntos de control en cuatro niveles desde code>off/code> hasta code>strict/code>. Ambos modos piden lo mismo al modelo subyacente: mirar una captura de pantalla, elegir una acción de un conjunto de herramientas fijo y hacerlo de nuevo en uno o dos segundos, cien veces, sin perder el hilo.

Eso es una petición exigente —seguir instrucciones bajo un esquema rígido, comprensión visual fundamentada y coherencia a largo plazo—, y es exactamente el conjunto de habilidades que no se le han dado a un checkpoint base. Los propios backends probados de ARTEMIS son modelos alojados: Gemini, Claude, GPT-4o, Qwen-VL. Todos ellos están ajustados por instrucciones para el uso de herramientas, y todos ellos son grandes.

Así que la brecha no es de tamaño. Un modelo postentrenado de 2.6B puede sostener un bucle de llamadas a herramientas — el propio modelo hermano postentrenado de Liquid afirma superar a Gemma 4 E2B-it y E4B-it en todas sus evaluaciones de seguimiento de instrucciones y en casi todas las de uso de herramientas, aunque son cifras reportadas por el proveedor y sin verificación independiente. La brecha es que a un base checkpoint no se le ha aplicado nada de ese entrenamiento, por lo que no se puede incorporar a un arnés en absoluto.

La licencia es la diferencia más marcada.

Aquí es donde realmente se decide el enfrentamiento, y es la parte que la mayoría de las comparativas se salta.

• ARTEMIS — Apache 2.0. Úsalo comercialmente, hazle un fork, distribúyelo dentro de un producto, sin condición de ingresos. La única obligación es conservar los avisos y declarar tus cambios, una obligación que el propio proyecto tuvo que reparar públicamente en septiembre de 2026 después de que Minitap alegara que 228 de los 229 archivos de ARTEMIS coincidían con su propio proyecto Apache-2.0 code>mobile-use/code> y que los nombres de los autores habían sido eliminados mediante force-push. El repositorio ahora incluye una línea de crédito a Minitap.

• LFM2.5-2.6B-Base — la LFM Open License, una licencia personalizada en lugar de Apache o MIT. Por debajo de $10M de ingresos anuales, la concesión es amplia, perpetua y libre de regalías. En ese umbral o por encima de él, la licencia no se extiende en absoluto al uso comercial, y debes contactar con Liquid. El detalle importante para quien construya sobre él: las obras derivadas heredan los mismos términos. El checkpoint que entrenas posteriormente no es algo nuevo que poseas en su totalidad —arrastra la licencia condicionada por los ingresos, con una excepción para organizaciones sin ánimo de lucro cualificadas.

Pon esos dos hechos uno al lado del otro y la decisión se invierte dependiendo de quién seas. Una empresa financiada que quiere lanzar un agente del lado del teléfono tiene un arnés Apache-2.0 que puede usar libremente y un checkpoint que quizá no pueda usar comercialmente en absoluto. Un desarrollador individual o una startup por debajo del umbral tienen ambos, y la licencia es una nota al pie. Ningún proveedor está siendo irrazonable — Liquid es una empresa que protege su nivel comercial, Google está liberando como código abierto herramientas de prueba — pero «pesos abiertos» y «pesos abiertos» no son el mismo permiso, y una comparación que se detiene en el número de parámetros no te dirá cuál tienes.

La familia, porque el checkpoint base es la puerta equivocada para entrar en ella.

Si el objetivo es un agente Android en el dispositivo, tres hermanos importan más que la base, y el que la hoja de ruta de ARTEMIS realmente necesita no es el obvio.

• LFM2.5-2.6B — el hermano agéntico post-entrenado. El rendimiento reportado por el proveedor es de unos 30 tokens por segundo en hardware de clase telefónica, 113 en un Ryzen AI Max+ 395 y 220 en un Apple M5 Max, ejecutándose en menos de 2.5 GB.

• LFM2.5-VL-3B — el modelo de borde de visión-lenguaje, construido sobre la misma base con un codificador SigLIP2 400M NaFlex, con una precisión de grounding precision@1 reportada por el proveedor que pasó de 57.1 a 87.9 en RefCOCO y, según Liquid, un rendimiento en elementos de interfaz de usuario en pantalla que supera a modelos Gemma mucho más grandes y se queda a un 0.7% de un Qwen 3.5 de 4.7B. Sin verificar, pero es el único miembro de esta familia que puede ver una pantalla.

• LFM2.5-230M — el nivel de extracción y clasificación, explícitamente no recomendado para trabajo intensivo en razonamiento.

¿Cuál es la conclusión incómoda para el checkpoint base en este enfrentamiento: el elemento de la hoja de ruta de ARTEMIS es un requisito de visión, el modelo base es solo texto, y el miembro de la familia que ocupa ese lugar es la variante VL a la que ya se le han aplicado tanto el codificador de visión como el post-entrenamiento. El papel del checkpoint base en una pila de automatización de Android no es controlar el teléfono. Es ser la materia prima que subyace a cualquier modelo pequeño que finalmente lo haga.

Donde sí coinciden: el volante de inercia que nadie ha construido todavía

Aquí está la única conexión que es real y no retórica, y va en sentido inverso a la dirección habitual. La característica más subestimada de ARTEMIS no es el agente, sino los datos residuales que genera. Cada ejecución captura pilas de fallos, capturas de pantalla de fotogramas clave, un registro de sesión de pasos comprimidos y un informe de diagnóstico, y Pro abre un «incidente de ejecución» siempre que falla una acción y lo mantiene en contexto hasta que un éxito posterior lo resuelve. Eso es un corpus etiquetado de exactamente los momentos en que la percepción de un agente de UI se equivocó.

Si a eso le sumas un checkpoint cuyo propósito no es otro que el post-entrenamiento, tienes un bucle obvio: ejecutar el arnés sobre un modelo alojado, recopilar las trazas donde tropezó con tu app y ajustar un modelo de 2.6B precisamente con esos frames. Es el tipo de conjunto de datos propietario que la propia ficha de Liquid cita como la justificación para lanzar siquiera un checkpoint base —"entrenar con tus propios datos"—, y la licencia condicionada por los ingresos significa que es una ruta que tiene sentido para equipos por debajo del umbral y requiere una conversación para equipos por encima de él.

Para ser explícitos sobre el estatus de esa idea: nadie ha publicado este bucle, ninguno de los dos proveedores lo sugiere y no hay evidencia de que ninguna de las partes lo haya probado. Es una propuesta, no un resultado, y debe leerse como tal. Pero es el único marco en el que estos dos artefactos son colaboradores en lugar de un error de categoría.

Si llegas hasta el ajuste fino, el conjunto de comparación es la otra mitad del problema. LFM2.5-2.6B-Base no está en nuestro catálogo —ninguna variante de LFM2.5 lo está—, así que ese checkpoint proviene de la distribución propia de Liquid y de los hosts de terceros habituales. Donde un catálogo enrutado se gana su sitio es al evaluar tu ajuste fino frente a los modelos a los que tiene que superar en uso de herramientas, con una sola clave y una sola factura, y con failover para que una mala tarde de un proveedor no se convierta en la mala tarde de tu evaluación. Eso es algo genuinamente útil de tener cuando el objetivo de todo el ejercicio es un cara a cara sobre el que piensas actuar.

Entonces, ¿cuál es tu problema?

Si tienes una app para Android y quieres que se pruebe automáticamente este trimestre, lo que quieres es ARTEMIS, y LFM2.5-2.6B-Base no es parte de la respuesta: ejecutarás ARTEMIS contra un modelo de visión alojado, pagarás por paso, y el punto de la hoja de ruta sobre los VLM en el dispositivo llegará con el tiempo y resolverá un problema de costos que aún no has medido.

Si estás creando un producto que debe ejecutarse en un teléfono móvil sin red, quieres la ruta de los modelos pequeños, y LFM2.5-2.6B-Base es el comienzo de ese proyecto, no una parte de su solución: lo postentrenarás, leerás la LFM Open License a la luz de tu proyección de ingresos antes de escribir el primer script de entrenamiento y, si tu agente necesita ver una pantalla, acabarás usando la variante VL en su lugar.

Lo único que no hay que hacer es poner estas dos cosas una al lado de la otra, declarar que el harness es más capaz y seguir adelante. La comparación útil es entre los dos stacks completos —modelo alojado más harness, frente a modelo pequeño ajustado más un framework que construyas tú—, y solo uno de ellos tiene una tasa de éxito publicada en un benchmark público, lo cual vale exactamente lo mismo que el hecho de que el otro no tenga ningún costo de nube.

Donde un catálogo enrutado se gana su lugar es al comparar tu fine-tune con los modelos a los que tiene que superar en el uso de herramientas, con una sola clave y una sola factura, con failover para que una mala tarde de un proveedor no se convierta en una mala tarde de tu evaluación.

LFM2.5-2.6B-Base no está en nuestro catálogo — ninguna variante de LFM2.5 lo está — así que ese checkpoint proviene de la propia distribución de Liquid y de los hosts de terceros habituales.