El 27 de octubre de 2026, Liquid AI lanzó LFM3: seis modelos open-weight para texto, visión, audio, omni y “decisiones”, todos derivados de una misma base de 1.7B. El modelo de texto, LFM3-1.7B, acepta 256K tokens de contexto y entra en alrededor de 1 GB a 4 bits. El post de lanzamiento de Liquid afirma que supera a Qwen3.5-9B en el promedio de su tabla de benchmarks con más o menos un quinto de los parámetros.
Esto es una guía práctica, escrita al día siguiente del lanzamiento. El 28 de octubre de 2026 contrasté cada spec, tamaño de archivo y comando con las model cards, la API de HF, la documentación de Liquid y los repos de cada runtime, y recalculé yo mismo el promedio de los benchmarks. No corrí los modelos, así que acá no hay afirmaciones propias de velocidad ni de calidad.
1. La ficha técnica
La familia vive en una colección de Hugging Face. Los seis comparten el mismo backbone LFM3 y la LFM Open License v1.0. Esto es lo que cambia entre modelos, tal cual lo dicen las cards.
Los seis modelos LFM3 (cards de Hugging Face, revisadas el 28 de octubre de 2026)
“Formatos oficiales” lista los repos de LiquidAI de cada modelo. FP8 y NVFP4 existen solo para los modelos de texto y de visión.
| Modelo | Parámetros | Contexto | Entrada → salida | Formatos oficiales |
|---|---|---|---|---|
| LFM3-1.7B | 1.73B | 256K | Texto → texto; razonamiento activo por defecto | Pesos para Transformers, GGUF, MLX (4/5/6/8 bits, BF16), ONNX, FP8, NVFP4 |
| LFM3-VL-2B | 1.92B (1.73B de LM + 164M de encoder de visión + 25M de proyector) | 128K | Texto, imágenes, video a 2 fps → texto; piensa antes de responder | Pesos para Transformers, GGUF, MLX (4/5/6/8 bits, BF16), ONNX, FP8, NVFP4 |
| LFM3-Audio-2B | 2B | 32K | Texto o audio a 16 kHz → texto, voz a 24 kHz, o ambos | Pesos para Transformers, GGUF, MLX (4/8 bits, BF16), ONNX |
| LFM3-Omni-2B | 2.17B | 32K | Texto, imágenes, video con sonido, audio → texto, voz, o ambos; sin razonamiento | Pesos para Transformers, GGUF, MLX (4/8 bits, BF16), ONNX |
| d1-2B | 1.92B | 128K | Estado (texto o JSON), imágenes o video + preguntas con nombre → respuestas tipadas con probabilidades | Pesos para Transformers, GGUF, MLX (4/8 bits, FP16), ONNX |
| d1-Omni-2B | 2.17B | 128K | Lo mismo que d1-2B, más clips de audio y preguntas habladas → respuestas tipadas | Pesos para Transformers, GGUF, MLX (8 bits, FP16), ONNX |
Lo que comparte toda la familia
- • Lanzamiento: 27 de octubre de 2026 (blog de Liquid), en Hugging Face, el Liquid Playground y la API de Liquid.
- • Backbone: LFM3-1.7B-Base, preentrenado con 22T tokens. Sus 24 capas son 13 convoluciones cortas con compuerta, 5 capas de atención de ventana deslizante y 6 de atención global.
- • Vocabulario: 128.000 tokens. Las cards de texto, visión, omni y d1 listan 16 idiomas de texto, del inglés, el español y el chino al hindi, el tailandés y el polaco; Audio y Omni hablan 18.
- • Licencia: LFM Open License v1.0 en todos los repos, gratis para uso comercial por debajo de USD 10M de facturación anual (detalle en la sección 5).
- • Hardware: Arm anunció soporte desde el primer día el 27 de octubre, y el post de Liquid cita a AMD, Qualcomm y Ambarella llevando los modelos a sus chips.
Tres números fáciles de confundir
El contexto de 256K es solo del modelo de texto: VL y los dos d1 aceptan 128K, Audio y Omni 32K. “Alrededor de 1 GB” es el modelo de texto a 4 bits: 0,97 GB en MLX de 4 bits, 1,05 GB como GGUF QAD Q4_0 y 1,10 GB como Q4_K_M, según la API de HF. Y “seis modelos” deja afuera un séptimo repo, LFM3-1.7B-Base, el checkpoint preentrenado para fine-tunes.
Los dos d1 no son modelos de chat
d1-2B y d1-Omni-2B son lo que Liquid llama modelos de decisión. Las dos cards dicen que “devuelven respuestas calibradas en un solo forward pass, sin generar tokens”. Les pasás un estado (un string, cualquier valor JSON, o nada cuando una imagen o un clip es todo el estado) más preguntas con nombre, y te devuelven respuestas tipadas con probabilidades. d1-2B se apoya en LFM3-VL-2B (texto, imágenes, video); d1-Omni-2B se apoya en LFM3-Omni-2B y suma clips de audio y preguntas habladas. Suceden a d1-3B y d1-omni-600M, los primeros d1 abiertos de Liquid, publicados el 7 de octubre sobre LFM2.5.
Si leíste mi guía de Open-Jev, la interfaz te va a resultar conocida: los mismos tipos de pregunta choice, noul y score, respondidos en una sola pasada, y d1-2B incluso reporta un puntaje en JevBench. El método de Python se llama system_one, la misma idea de “System One” que expliqué en mi deep dive de modelos de decisión tipados. Liquid no dice que d1 esté construido sobre Open-Jev ni que sea compatible con la API de Jev, así que leelo como un vocabulario compartido, no como un proyecto compartido.
Tipos de pregunta (model cards de d1)
- • noul: sí o no; devuelve P(yes).
- • choice: una opción entre criterios con nombre, con probabilidades por opción; con multiple: true pasa a ser multi-etiqueta.
- • score: uno de 2 a 10 niveles ordenados; devuelve el nivel mediano y sus probabilidades.
- • text, number, date: valores leídos del estado, con su span; None si no los encuentra.
- • number con range: una estimación con un intervalo p10–p90.
- • box y boxes: un objeto o todas sus instancias (hasta 16) en una imagen.
Para qué dice Liquid que sirven
Ruteo y triage, moderación y guardrails, clasificación de intención y de tema, extracción de documentos y formularios, juicio y reranking, e inspección visual. d1-Omni-2B apunta a decisiones que dependen del sonido, como el ruteo de llamadas y mensajes de voz. El ruteo de tools no está en la lista de Liquid. Podrías plantear “¿qué tool uso?” como una pregunta choice, pero eso es una extrapolación mía, no un caso de uso documentado.
2. Qué cambió frente a LFM2, y el diseño tri-híbrido en palabras simples
LFM2 era un híbrido de dos partes. La config de LFM2-1.2B tiene 16 capas: 10 convoluciones cortas y 6 capas de atención global. LFM3 crece a 24 capas y suma un tercer tipo de capa, la atención de ventana deslizante. De ese tercer tipo sale lo de “tri-híbrido”.
Pensá los tres tipos de capa como tres formas en que un token puede mirar hacia atrás el texto que tiene antes. Cada uno cambia alcance por costo, y la mezcla define cuánta memoria necesita el modelo a medida que crece el contexto.
Los tres tipos de capa
Convoluciones cortas con compuerta (13 capas)
Cada token se mezcla con los pocos tokens que tiene justo antes; el kernel pasó de 3 en LFM2 a 7. El estado queda chico y fijo con cualquier largo de contexto, así que estas capas son baratas en la CPU de un celular.
Atención de ventana deslizante (5 capas)
Atención de verdad, pero solo sobre los últimos 256 tokens. Capta estructura cercana que un kernel de 7 tokens no alcanza, y su caché nunca crece más allá de la ventana.
Atención global (6 capas)
Atención completa sobre todo el contexto, donde pasa el recall de largo alcance. Solo estas 6 capas guardan una caché key-value que crece con el prompt.
Ese último punto es la ganancia. Liquid dice que un contexto completo de 128K tokens necesita 1,6 GB de caché KV, frente a 4,3 GB de Qwen3.5-4B y 5,6 GB de MiniCPM5-2B. Mi cuenta a partir de config.json coincide: 6 capas globales × keys y values × 4 cabezas KV × 128 dimensiones × 131.072 tokens × 2 bytes da alrededor de 1,6 GB. En el stack van primero dos convoluciones, después se alternan atención y convolución, y la atención global y la de ventana deslizante se van turnando.
Otros cambios que lista Liquid
- • Búsqueda de arquitectura con el hardware en el loop sobre 14 combinaciones de dispositivo y backend (celulares, una Raspberry Pi 5, notebooks, CPUs en la nube, GPUs, la NPU Hexagon de Qualcomm), frente a dos CPUs en LFM2.
- • Compuerta sigmoide por cabeza en las salidas de atención, RoPE parcial solo en las capas globales y normalización tipo sándwich (las dos últimas se ven en config.json).
- • Un vocabulario de 128.000 tokens, frente a los 65.536 de LFM2.
- • 22T tokens de preentrenamiento con más papers, código a nivel de repositorio y matemática. Los últimos 3,5T usan datos curados con más trazas agénticas y tool calls, y llevan el contexto a 256K.
- • Post-entrenamiento: 1,75T tokens de SFT, RL mixto con penalización por largo, destilación desde seis maestros de RL especializados y, al final, RL agéntico en harnesses reales como Hermes Agent, Pi y OpenClaw.
- • Encoders nuevos: un encoder de visión propio de 164M (el primer modelo de visión LFM que acepta video), más un encoder de audio nuevo y el tokenizer LiquidCodec.
La versión en una oración
LFM3 gasta atención solo donde rinde (6 capas globales) y usa convoluciones baratas y ventanas cortas en todo lo demás, y así un modelo de 1.7B sostiene 256K tokens en un celular. Liquid dice que el resultado supera a LFM2.5-2.6B con un 35% menos de parámetros.
3. Benchmarks (autorreportados)
La tabla de Liquid compara LFM3-1.7B con cinco modelos en 29 benchmarks, de agentes y uso de tools a conocimiento y contexto largo, todos corridos en vLLM en BF16. Elegí las filas que más importan para un agente en el dispositivo, más las que pierde.
Filas seleccionadas de la card de LFM3-1.7B (autorreportadas por Liquid AI)
Más alto es mejor. “Promedio” es la media sin ponderar de los 29 puntajes que calcula Liquid; la recalculé desde la card y me dio lo mismo, 49,37 y 47,24.
| Benchmark | LFM3-1.7B | LFM2.5-2.6B | Qwen3.5-4B | Qwen3.5-9B |
|---|---|---|---|---|
| Promedio (29 benchmarks) | 49.37 | 31.55 | 39.27 | 47.24 |
| BFCL V4 (tool calling) | 71.39 | 55.89 | 55.12 | 62.83 |
| ToolSandbox | 80.36 | 78.04 | 75.40 | 76.41 |
| τ³-bench (4 dominios) | 68.01 | 56.77 | 65.98 | 67.11 |
| MCP-Atlas | 32.57 | 16.45 | 41.37 | 42.67 |
| WebArena-Verified | 38.42 | 3.02 | 21.92 | 28.94 |
| AutomationBench (público) | 41.29 | 0.94 | 8.67 | 15.10 |
| IFBench | 73.03 | 60.48 | 38.16 | 48.84 |
| LiveCodeBench v6 | 73.46 | 60.57 | 61.99 | 69.86 |
| SWE-bench Verified (OpenCode) | 43.40 | 18.00 | 41.20 | 51.20 |
| Terminal-Bench 2.1 (OpenCode) | 12.92 | 0.00 | 13.48 | 17.98 |
| GPQA Diamond | 63.37 | 57.78 | 75.76 | 80.40 |
| Humanity’s Last Exam (sin tools) | 7.17 | 5.88 | 12.84 | 16.41 |
| AA-Omniscience accuracy | 7.07 | 8.75 | 15.67 | 13.17 |
| AA-LCR (contexto largo) | 52.83 | 6.00 | 52.67 | 62.00 |
| RULER 128K | 65.56 | 1.15 | 84.63 | 87.11 |
La historia de verdad está en el uso de tools y el seguimiento de instrucciones: BFCL V4, ToolSandbox, IFBench y AutomationBench favorecen al 1.7B frente a un modelo cinco veces más grande. Las filas de conocimiento y de contexto largo van para el otro lado, y por mucho.
¿Cuánto del promedio es un solo benchmark? (mi cuenta)
Cara a cara, LFM3-1.7B gana 14 de las 29 filas contra Qwen3.5-9B. Tres filas son variantes de AA-Omniscience, donde LFM3 saca 0,50 contra -28,00 en el índice y 92,93 contra 52,59 en no-alucinación. Si sacás esas tres, las otras 26 filas promedian 51,20 para LFM3 y 51,24 para Qwen3.5-9B: un empate. Igualar a un 9B con 1.73B sigue siendo el punto; solo no leas “supera a Qwen3.5-9B” como “es mejor en todo”.
Benchmarks de decisión de d1-2B (autorreportados)
Orden: d1-2B / d1-Omni-2B / d1-3B (el modelo de octubre construido sobre LFM2.5), tal como los publica la card de d1-2B. Liquid evaluó a todos sobre los mismos ítems.
- • Decision Index, suite pública (v0.3): 51.1 / 49.0 / 49.0
- • DecisionBench (Hanno Labs) v1: 77.1 / 76.4 / 73.1
- • JevBench v1.4.1: 77.9 / 75.3 / 76.2
- • WorkflowEvals: 81.6 / 77.1 / 74.4
- • Typed Decisions: 61.3 / 63.1 / 65.0 (acá gana el d1-3B anterior)
- • Promedio de los benchmarks públicos que comparten todos los modelos de la card: 70.2 / 67.7 / 65.4
- • Latencia de una pregunta, en caliente, después de model.compile(): 5,7 ms en una NVIDIA H100 PCIe, 3,8 ms en una AMD MI325X, 18,6 ms en una Apple M5 Pro
Los otros tres, en una línea cada uno (autorreportado)
- • LFM3-VL-2B: en 62 benchmarks de visión, Liquid dice que supera por al menos 8 puntos a todos los modelos de tamaño similar e iguala a Gemma 4 12B.
- • LFM3-Audio-2B: VoiceBench 73,13 contra 55,17 de LFM2.5-Audio; tasa de error de palabras en ASR en inglés de 6,23, cerca del 6,13 de LFM2.5-Audio.
- • LFM3-Omni-2B: Daily-Omni 70,09 contra 58,81 de Qwen2.5-Omni 3B, pero OmniBench general 46,32 contra 47,11, así que no gana todos los tests omni.
Afirmaciones de velocidad (números del fabricante y de partners)
La card de Liquid dice que con 32K de contexto (GGUFs Q4_0 en llama.cpp), LFM3-1.7B hace el prefill al menos 2,5× más rápido y decodifica al menos 1,8× más rápido que todos los modelos comparados en una AMD Ryzen AI Max+ 395, una Apple M5 Max y un iPhone 17 Pro, con la menor memoria. También afirma 3.600 millones de tokens por día en una sola NVIDIA B300. El post de Arm del día del lanzamiento califica sus propias cifras como “early, provisional”: con SME2, LFM3-1.7B (Q4_0) logra 3,1× de aceleración en prefill y 1,5× en decode sobre CPUs Arm, con más de 400 tokens/s de prefill y más de 50 tokens/s de decode en dos hilos.
4. Quickstart: llama.cpp, Ollama, Transformers y MLX
El soporte de los runtimes cambia hora a hora, así que fijate la fecha de todo. LFM3 llegó a llama.cpp b11960 (v0.8.0) el 28 de octubre, al día siguiente del lanzamiento, y Ollama 0.40.12 publicó tags oficiales el mismo día del lanzamiento, solo para hardware de Apple. Cada comando de abajo está copiado de una model card o de unas release notes.
Estado de los runtimes al 28 de octubre de 2026
Según releases y pull requests de GitHub, PyPI y las model cards. Las cards actualizadas antes del 28 de octubre pueden seguir diciendo que el soporte de llama.cpp está “in review”.
| Runtime | Estado de LFM3 | Notas |
|---|---|---|
| llama.cpp | Soportado desde b11960 / v0.8.0 (28 de octubre): texto, VL con video, Audio, Omni y los dos d1 | d1 responde en el /v1/systemone de llama-server |
| Ollama | 0.40.12 trae lfm3, lfm3-vl, lfm3-audio, lfm3-omni, d1 y d1-omni en hardware de Apple; Linux y Windows “pronto” | Importar el GGUF de HF falló con “unknown model architecture: 'lfm3'” en 0.40.12 |
| mlx-lm | Sin release: la última es 0.32.2 (16 de octubre), y el pull request #2016 de LFM3 sigue abierto | La card MLX dice que el soporte está en progreso |
| mlx-vlm | Soporte de LFM3, VL, Audio, Omni y d1 mergeado en main el 27 de octubre | La 0.7.10 de PyPI (21 de octubre) es anterior |
| Transformers | Corre el código propio de cada repo con trust_remote_code=True; los pull requests nativos siguen abiertos | Las cards piden 5.21.0+ (VL), 5.20.2+ (Audio, Omni), 5.19+ (d1) |
| SGLang | El pull request #46858 sigue abierto | Las cards FP8 y NVFP4 apuntan a ese PR |
| vLLM | Card de VL: “in progress”; no encontré ningún pull request mergeado | Las docs de Liquid igual muestran un snippet; yo esperaría una release |
| ONNX Runtime | Exportaciones ONNX para los seis modelos | Navegador: onnxruntime-web/webgpu con q4f16 (1,38 GB para el 1.7B) |
llama.cpp: el modelo de texto (card de LFM3-1.7B-GGUF)
Necesita b11960 o superior. El segundo comando elige el archivo Q4_0 con destilación consciente de la cuantización, que Liquid entrenó para recuperar la precisión que se pierde en Q4_0.
# llama.cpp b11960 (v0.8.0) or newer
llama-cli -hf LiquidAI/LFM3-1.7B-GGUF:Q4_K_M \
--temp 0.1 --top-k 50 --repeat-penalty 1.1
# Quantization-aware distilled Q4_0 build (1.05 GB)
llama-cli -hf LiquidAI/LFM3-1.7B-GGUF \
--hf-file LFM3-1.7B-QAD-Q4_0.gguf \
--temp 0.1 --top-k 50 --repeat-penalty 1.1llama.cpp: d1-2B como servidor de decisiones (card de d1-2B-GGUF)
Cada pregunta se lee en un solo batch, así que -b y -ub tienen que alcanzar para el estado más cualquier media. En llama.cpp, d1 responde preguntas noul, choice y score.
llama-server -hf LiquidAI/d1-2B-GGUF:Q8_0 -b 8192 -ub 8192
curl http://127.0.0.1:8080/v1/systemone -H "Content-Type: application/json" -d '{
"state": "I was charged twice this month, please refund one of them.",
"questions": {
"refund": {"type": "noul", "instructions": "Is the customer asking for a refund?"},
"team": {"type": "choice", "instructions": "Which team should handle this?",
"criteria": {"billing": "Charges, refunds, invoices", "technical": "App or site faults",
"fraud": "Suspected unauthorised use"}},
"urgency": {"type": "score", "instructions": "How urgent is this?",
"criteria": ["Can wait", "Today", "Blocking the customer now"]}
}
}'llama.cpp: una pregunta sobre un video (card de LFM3-VL-2B-GGUF)
La entrada de video necesita ffmpeg en tu PATH. Para un chat interactivo, corré llama-cli con los mismos flags y escribí /image o /video para adjuntar media.
llama-mtmd-cli -hf LiquidAI/LFM3-VL-2B-GGUF:Q4_0 \
--video reading.mp4 -p "What is the child doing in this video?" \
--temp 0.1 --top-p 1.0 --top-k 50 --min-p 0.0 --repeat-penalty 1.1Ollama 0.40.12 en hardware de Apple (release notes)
lfm3:latest es el 1.7B en NVFP4 sobre el motor MLX de Ollama (1,7 GB). Pedí d1:2b de forma explícita, porque d1:latest sigue apuntando al d1-3B anterior.
ollama run lfm3
ollama run d1:2b "I was charged twice for order 4417." --ask "Is this a billing issue?"Transformers: LFM3-1.7B (model card)
Carga el código de modelo propio de Liquid desde el repo. El razonamiento viene activo por defecto; mirá las notas de sampling más abajo.
# pip install -U transformers torch accelerate
from transformers import pipeline
generator = pipeline(
"text-generation",
model="LiquidAI/LFM3-1.7B",
trust_remote_code=True,
)
messages = [{"role": "user", "content": "What is C. elegans?"}]
output = generator(
messages,
do_sample=True,
temperature=0.1,
top_k=50,
repetition_penalty=1.1,
max_new_tokens=2048,
)
print(output[0]["generated_text"][-1]["content"])Transformers: d1-2B (model card)
Un solo forward pass y ningún parámetro de sampling. La última línea es la salida que muestra la card, no una que haya obtenido yo.
# pip install "transformers>=5.19" torch torchvision pillow
import torch
from transformers import AutoModel
device = "cuda" if torch.cuda.is_available() else "mps" if torch.backends.mps.is_available() else "cpu"
dtype = torch.float32 if device == "cpu" else torch.bfloat16
model = AutoModel.from_pretrained("LiquidAI/d1-2B", trust_remote_code=True, dtype=dtype).to(device)
# Several named questions over one state, answered in one pass
questions = {
"refund": {"type": "noul", "instructions": "Is the customer asking for a refund?"}, # yes/no: P(yes)
"team": {"type": "choice", "instructions": "Which team should handle this?",
"criteria": {"billing": "Charges, refunds, invoices", "shipping": "Delivery and parcels",
"technical": "App or site faults"}},
"topics": {"type": "choice", "multiple": True, "instructions": "Which topics does the message raise?",
"criteria": {"billing": "Payments and charges", "delivery": "Shipping and parcels",
"login": "Signing in to the account"}},
"urgency": {"type": "score", "instructions": "How urgent is this ticket?", "criteria": ["low", "medium", "high"]},
}
out = model.system_one("I was charged twice and my parcel never arrived. Please refund one charge.", questions)
a = out["answers"]
urgency = a["urgency"]["legend"][str(int(a["urgency"]["score"]))]
print(round(a["refund"]["noul"], 2), a["team"]["choice"], a["topics"]["choices"], urgency)
# 1.0 billing ['billing', 'delivery'] mediumMLX: el modelo de texto en 4 bits (cuando mlx-lm lo soporte)
Este es el comando de la card, y no corre en mlx-lm 0.32.2. La CLI no tiene flag de repetition penalty, así que la card sugiere make_logits_processors(repetition_penalty=1.1) en Python.
mlx_lm.generate --model LiquidAI/LFM3-1.7B-MLX-4bit \
--prompt "What is the capital of Australia?" \
--temp 0.1 --top-k 50 --max-tokens 16384Ajustes de sampling y de thinking según las cards
- • LFM3-1.7B, uso general (chat, tools, agentes): temperature 0.1, top_k 50, repetition_penalty 1.1.
- • LFM3-1.7B, matemática y ciencia: temperature 1.0, top_p 0.95, top_k 20.
- • LFM3-VL-2B: temperature 0.1, top_p 1.0, top_k 50, min_p 0.0, repetition_penalty 1.1.
- • LFM3-Omni-2B: greedy para texto; audio_temperature 0.4 y audio_repetition_penalty 1.2 para voz. No razona, así que pasale --reasoning off a llama-server.
- • LFM3-Audio-2B: audio_temperature 1.0, audio_top_k 128 y audio_repetition_penalty 1.1 para voz.
- • Modelos d1: no hay nada que ajustar.
- • El thinking viene activo por defecto en texto y VL; el razonamiento de turnos anteriores se descarta salvo que pases preserve_thinking=True.
En una Mac hoy
Ollama 0.40.12 y el build de llama.cpp con Metal son los dos caminos que funcionan ahora mismo. El comando MLX de arriba es el que vas a usar cuando mlx-lm mergee LFM3. Si nunca configuraste mlx-lm, mi guía de MLX + mlx-lm cubre la instalación y el fine-tuning, así estás listo el día que llegue el soporte.
5. Límites honestos
Planificá alrededor de esto antes de meter LFM3 en un producto.
Dónde tendría cuidado
- • Todos los números de la sección 3 son de Liquid, con el harness de Liquid. Un día después del lanzamiento, no encontré ninguna evaluación independiente.
- • El promedio del titular se apoya en AA-Omniscience: sin esas tres filas, LFM3-1.7B y Qwen3.5-9B quedan empatados (sección 3).
- • El conocimiento es escaso: GPQA Diamond 63,37 contra 80,40, y accuracy de 7,07% en AA-Omniscience. El modelo casi siempre admite lo que no sabe (92,93 en no-alucinación), así que combinalo con retrieval, como recomienda la card.
- • Una ventana larga no es recall largo: RULER a 128K da 65,56, contra 87,11 de Qwen3.5-9B y 84,63 de Qwen3.5-4B.
- • No es un agente de código. La card dice que “no se recomienda para código agéntico ni razonamiento complejo de varios pasos por su tamaño chico”.
- • El razonamiento viene activo por defecto, lo que cuesta tokens y latencia en un celular, y la card dice que apagarlo “puede ser inconsistente”.
- • Los runtimes tienen un día de vida. Solo llama.cpp y Ollama (solo en hardware de Apple) tienen soporte en una release; la card del 1.7B lista vLLM y SGLang, que todavía no lo tienen.
- • d1 pierde confiabilidad pasados unos 64K tokens de estado, y en llama.cpp todavía no hace choice multi-etiqueta, extracción, estimaciones ni boxes. Calibrá cada umbral con tus propios datos.
- • En Ollama, d1:latest sigue apuntando al d1-3B anterior (construido sobre LFM2.5, 32K de contexto), así que bajá d1:2b de forma explícita.
- • Las afirmaciones de velocidad son del fabricante: Liquid compara su build de llama.cpp con LFM3 contra la release b11744 para los demás modelos, y Arm califica sus cifras con SME2 de provisorias.
La licencia, en palabras simples
LFM Open License v1.0 sigue casi entera la plantilla de Apache 2.0, con un agregado grande en la Sección 5. El uso comercial está licenciado solo mientras tu facturación anual quede por debajo de USD 10 millones, y “vos” incluye a cualquier entidad que te controle, que controles o que esté bajo control común con vos. Por encima del umbral, el uso comercial “no está licenciado”, así que necesitarías un acuerdo aparte con Liquid. Las organizaciones sin fines de lucro calificadas quedan exentas para uso no comercial o de investigación. Eso la hace gratis para startups y proyectos personales, pero no es una licencia open source aprobada por la OSI. No soy abogado: pedí que alguien de legal la lea antes de lanzar.
Veredicto: qué modelo probar
LFM3 es el lanzamiento de modelos chicos más interesante del mes si construís agentes locales. Un modelo de 1.7B que se defiende contra un 9B en tool calling y seguimiento de instrucciones, en alrededor de 1 GB, es un avance real. El par d1 es la historia más silenciosa: decisiones en milisegundos con probabilidades, en un paquete abierto que ya corre en llama.cpp.
No reemplaza a un modelo más grande para conocimiento, recall en documentos largos ni agentes de código, y los propios números de Liquid lo dicen. Tratalo como un especialista rápido y barato, hacele fine-tuning para tu dominio, y dejá retrieval o un modelo más grande detrás.
Quién debería probar cada modelo
LFM3-1.7B
Agentes locales, tool calling y salida estructurada en notebooks y celulares, idealmente con fine-tuning sobre tus propias tools y con retrieval al lado.
LFM3-VL-2B
Lectura en el dispositivo de documentos, gráficos y pantallas de apps, preguntas sobre videos cortos y razonamiento espacial para robots.
LFM3-Audio-2B
Transcripción offline, síntesis de voz y comandos de voz que se convierten en tool calls. La transcripción en vivo es solo en inglés.
LFM3-Omni-2B
Un solo modelo en el dispositivo en lugar de modelos separados de ASR, visión, LLM y TTS. Sin razonamiento, 32K tokens.
d1-2B
Cualquier paso de un pipeline donde hoy un LLM te devuelve una etiqueta que parseás de un JSON: ruteo, triage, moderación, extracción.
d1-Omni-2B
Ruteo de llamadas y mensajes de voz, o eventos de sonido. Sin audio, su card dice que conviene d1-2B.
Salteátelo si…
Necesitás respuestas que dependen de conocimiento, recall sobre documentos muy largos o un agente de código, o tu empresa supera el umbral de USD 10M de la licencia.
Checklist para probarlo
- 1. Actualizá llama.cpp a b11960 o superior y corré el modelo de texto Q4_K_M o QAD Q4_0 con el sampling de la card.
- 2. En una Mac, probá ollama run lfm3 con Ollama 0.40.12, o esperá la release de mlx-lm.
- 3. Corré entre 20 y 50 de tus propias tareas de tool calling con el thinking activado y desactivado; registrá tasa de aciertos, tokens y latencia.
- 4. Poné d1-2B detrás del /v1/systemone de llama-server en un paso de clasificación y comparalo con tu llamada actual a un LLM. Calibrá los umbrales con tus datos.
- 5. Evaluá las preguntas de conocimiento con retrieval activado antes de confiar en respuestas crudas.
- 6. Revisá la facturación de tu empresa contra el umbral de la licencia antes de lanzar.
Fuentes de este post
- Blog de Liquid AI: Introducing LFM3 (27-oct-2026)
- Blog de Liquid AI: Open d1, los primeros modelos de decisión abiertos (7-oct-2026)
- Hugging Face: colección LFM3 de LiquidAI
- Model card: LiquidAI/LFM3-1.7B (ficha, benchmarks, sampling)
- Model card: LiquidAI/LFM3-1.7B-GGUF (comandos de llama.cpp, QAD Q4_0)
- Model card: LiquidAI/LFM3-1.7B-MLX-4bit
- Model card: LiquidAI/LFM3-VL-2B
- Model card: LiquidAI/LFM3-Audio-2B
- Model card: LiquidAI/LFM3-Omni-2B
- Model card: LiquidAI/d1-2B (modelo de decisión, tipos de pregunta, benchmarks)
- Model card: LiquidAI/d1-2B-GGUF (llama-server /v1/systemone)
- Model card: LiquidAI/d1-Omni-2B
- LFM Open License v1.0 (archivo LICENSE)
- Docs de Liquid: página del modelo LFM3-1.7B
- Release notes de llama.cpp v0.8.0 / b11960 (soporte de LFM3 y d1)
- Release notes de Ollama v0.40.12 (tags lfm3 y d1)
- Biblioteca de Ollama: lfm3
- Biblioteca de Ollama: d1
- Pull request #2016 de mlx-lm: soporte de LFM3 (abierto)
- Pull request #2607 de mlx-vlm: soporte nativo de LFM3 y LFM3-VL (mergeado)
- Pull request #46858 de SGLang: soporte de LFM3 (abierto)
- Pull request #50036 de Transformers: familia LFM3 (abierto)
- Arm en X: soporte de LFM3 desde el primer día y cifras con SME2 (27-oct-2026)
- AI/TLDR: resumen del lanzamiento de LFM3 (secundaria)
- AI Weekly: Liquid AI abre la familia LFM3 de seis modelos (secundaria)



