To run LFM3-VL-2B locally you download about 1.25 GB: the Q4_0 GGUF plus the Q8_0 vision projector. LFM2-VL-1.6B at Q4_0 plus its Q8_0 projector was 1.26 GB. Same download, and OCRBench goes from 72.9 to 82.2 before you even turn on the new thinking mode.
Liquid AI shipped the model on October 27, 2026 with the LFM3 family, and llama.cpp merged support the same day. There's a catch in the marketing numbers, though: a big chunk of the headline gain comes from thinking mode, and for OCR and screenshot work you probably want it off. Below are the llama.cpp, MLX and Transformers commands, file sizes per quant, and the one flag I'd flip first.
I haven't benchmarked it myself yet. Every number comes from the model card, the GGUF/MLX repos, or the llama.cpp repo, and I link each one.
What LFM3-VL-2B actually is
Specs from the card:
- 1.92B parameters total: 1.73B language model, 164M vision encoder, 25M projector
- Language model: 24 layers, of which 13 are gated short convolutions, 5 are sliding-window attention and 6 are global attention
- Vision encoder: Liquid's own, 14 layers (8 gated depthwise 2D convolutions, 6 bidirectional attention), 16×16 patches with 2D RoPE; each 2×2 block of patches becomes one language token
- Native resolution images, plus video sampled at 2 fps
- 128K context, 16 languages, tool calling in a Qwen3-Coder-style XML format
- License: LFM Open License v1.0
The vision side is the big structural change. LFM2-VL-1.6B used a 400M SigLIP2 NaFlex encoder and a 32K text context. LFM3-VL swaps that for a 164M in-house encoder, which explains why the mmproj file dropped from 564 MB to 203 MB at Q8_0.
The card is also blunt about what it's not for: coding, multi-turn conversation and complex reasoning. I'd take that at face value and give it one image and one question at a time.
LFM3-VL-2B vs LFM2-VL: the benchmark table
The LFM3 card doesn't compare against LFM2-VL at all; its baseline is LFM2.5-VL-3B. So I lined up the benchmarks that appear on both the LFM2-VL-1.6B card and the LFM3-VL-2B card. Treat this as a rough comparison: LFM3 was evaluated with vLLM 0.27.1, the LFM2-VL numbers come from a different setup, and I converted OCRBench from its 1000-point scale.
| Benchmark | LFM2-VL-1.6B | LFM3-VL-2B (no think) | LFM3-VL-2B (think) |
|---|---|---|---|
| OCRBench | 72.9 (729/1000) | 82.2 | 86.3 |
| InfoVQA (val) | 58.35 | 70.6 | 86.2 |
| RealWorldQA | 65.75 | 73.1 | 79.3 |
| MMStar | 49.87 | 62.2 | 74.4 |
| MMMU (val) | 39.67 | 48.6 | 55.7 |
| MathVista (mini) | 51.70 | 68.5 | 84.2 |
| BLINK | 44.50 | 68.7 | 71.1 |
| MM-IFEval | 46.35 | 54.7 | 72.8 |
| MM-Vet | 47.75 | 44.3 | 57.4 |
| SEED-Bench (image) | 72.00 | 76.8 | 78.6 |
Even with thinking off, LFM3-VL beats LFM2-VL on 9 of 10. MM-Vet is the exception, where no-think scores 44.3 against LFM2-VL's 47.75.
Now look at the card's own summary row. With thinking, the average across 62 benchmarks is 71.4. Without it, 62.1. LFM2.5-VL-3B, the card's previous-generation baseline, sits at 57.6. So with thinking off, the upgrade over Liquid's last 3B is about 4.5 points from a smaller model. Good, but a long way from the 14 points the headline number suggests, and I'd rather vendors led with the no-think number when the think number comes with reasoning long enough that the card's own example budgets 16,384 new tokens.
The same card lists Qwen3.5 2B at a 64.0 average. That's below LFM3-VL with thinking and above it without. If you were planning to run LFM3-VL in no-think mode anyway, Qwen is worth testing on quality alone, before the license question even comes up.
Turn thinking off for OCR and screenshots
If I could change one setting, it would be this one. The per-benchmark table on the card:
| Task | No think | Think | Gap |
|---|---|---|---|
| OCRBench | 82.2 | 86.3 | 4.1 |
| DocVQA (val) | 94.9 | 96.7 | 1.8 |
| ScreenSpot-v2 Desktop | 95.5 | 94.6 | -0.9 |
| ScreenSpot-v2 Mobile | 91.6 | 92.2 | 0.6 |
| ChartQA (test) | 81.4 | 92.7 | 11.3 |
| InfoVQA (val) | 70.6 | 86.2 | 15.6 |
| CharXiv reasoning | 44.5 | 70.2 | 25.7 |
Reading text off a page or finding a button on a screenshot barely benefits from reasoning; on desktop UI grounding, thinking scores slightly worse. Charts and infographics are where reasoning pays off. The card's own Transformers example sets max_new_tokens=16384 "since reasoning can be long", which tells you what that mode costs on a laptop CPU.
My rule: thinking off for OCR, receipts and UI grounding; on for "what does this chart say".
The chat template exposes an enable_thinking flag, and it defaults to true. When false, the prompt ends in an empty
Image resolution and token cost
LFM2-VL capped things: images up to 512×512 went in at native resolution, larger ones were split into 512×512 tiles plus a thumbnail, with a recommended 64–256 image tokens.
LFM3-VL goes native resolution. The card doesn't state limits, but processor_config.json has a size range of shortest_edge: 65536 and longest_edge: 16777216. Those look like Qwen2-VL-style pixel budgets (256×256 up to 4096×4096). With 16px patches merged 2×2, each token covers 32×32 pixels, so by my arithmetic:
- 256×256 minimum ≈ 64 tokens
- 1920×1080 screenshot ≈ 2,025 tokens
- 4096×4096 maximum ≈ 16,384 tokens
Great for small text in a full-screen capture, bad for prefill time on a phone. If you're batch-processing screenshots, downscale first: halving each dimension cuts tokens by 4×.
LFM3-VL-2B GGUF sizes and memory
File sizes from the GGUF repo. You need one model file plus one mmproj file:
| File | Size |
|---|---|
| QAD-Q4_0 | 1.05 GB |
| Q4_K_M | 1.1 GB |
| Q5_K_M | 1.26 GB |
| Q6_K | 1.43 GB |
| Q8_0 | 1.85 GB |
| F16 / BF16 | 3.47 GB |
| mmproj Q8_0 | 203 MB |
| mmproj F16 / BF16 | 379 MB |
The repos give no runtime RAM figures, and the card's device benchmarks (Ryzen AI Max+ 395, M5 Max, Galaxy S26 Ultra) are only in a chart image. Runtime memory is file size plus KV cache plus image tokens. Only 6 of the 24 layers are global attention, so the cache grows slower than in a pure transformer. The closest hard number is for the text sibling, LFM3-1.7B: Liquid's LFM3 post puts its full 128K-token KV cache at 1.6 GB. Expect the VL model to be in that range, but a 4K screenshot alone is thousands of tokens of prefill.
Grab the QAD-Q4_0 file first. Liquid trained it with quantization-aware distillation specifically for Q4_0, so it's the 4-bit file they actually optimized.
How to run LFM3-VL-2B with llama.cpp
Support landed in llama.cpp PR #31252, merged October 27, 2026. The model card still says "in review", so ignore that and use a build from after the merge. That PR left video out; video input for LFM3-VL followed in PR #31283, merged October 28.
This is the server command from the model card. -hf pulls the mmproj automatically, and the only Q4_0 file in the repo is the QAD one:
llama-server -hf LiquidAI/LFM3-VL-2B-GGUF:Q4_0 \
--temp 0.1 --top-p 1.0 --top-k 50 --min-p 0.0 --repeat-penalty 1.1 \
--no-reasoning-preserve --port 8080If you want to pin the exact file, the GGUF card's CLI command names it directly (type /image in chat to attach an image):
llama-cli -hf LiquidAI/LFM3-VL-2B-GGUF --hf-file LFM3-VL-2B-QAD-Q4_0.gguf \
--temp 0.1 --top-p 1.0 --top-k 50 --min-p 0.0 --repeat-penalty 1.1 \
--no-reasoning-preserveFor OCR runs, add --reasoning off to either command. It sets enable_thinking to false, so the template's no-think branch kicks in. Passing --chat-template-kwargs '{"enable_thinking": false}' still works, but current llama.cpp logs a deprecation warning and points you to --reasoning off.
One detail from the PR: the depthwise conv kernels in the vision encoder are kept in F32 when quantizing. If you make your own GGUF, use a llama.cpp checkout that includes the PR.
MLX on Apple Silicon
There's a 4-bit MLX checkpoint (1.59 GB, also QAD-trained, embeddings kept at 8-bit). The card says MLX-VLM support is "in progress", so this may fail on the current release:
pip install --upgrade mlx-vlm
python -m mlx_vlm.generate --model LiquidAI/LFM3-VL-2B-MLX-4bit \
--image <IMAGE PATH> --prompt "Describe this image." \
--temperature 0.1 --top-p 1.0 --top-k 50 --min-p 0.0 --repetition-penalty 1.1 \
--max-tokens 16384On a Mac today, llama.cpp with Metal is the safer route.
Transformers
Needs transformers>=5.21.0 and trust_remote_code=True. This is the card's snippet, adapted for OCR with thinking disabled:
import torch
from transformers import AutoModelForImageTextToText, AutoProcessor
model_id = "LiquidAI/LFM3-VL-2B"
model = AutoModelForImageTextToText.from_pretrained(
model_id, dtype=torch.bfloat16, device_map="auto", trust_remote_code=True)
processor = AutoProcessor.from_pretrained(model_id, trust_remote_code=True)
messages = [{"role": "user", "content": [
{"type": "image", "url": "receipt.jpg"},
{"type": "text", "text": "Extract all text from this receipt."}]}]
inputs = processor.apply_chat_template(
messages, add_generation_prompt=True, tokenize=True,
return_dict=True, return_tensors="pt",
enable_thinking=False).to(model.device)
output_ids = model.generate(**inputs, do_sample=True, temperature=0.1,
top_k=50, repetition_penalty=1.1, max_new_tokens=2048)
print(processor.batch_decode(output_ids[:, inputs["input_ids"].shape[1]:],
skip_special_tokens=True)[0])The license fine print
LFM Open License v1.0 is free for commercial use only while your company is under $10M in annual revenue. Above that, you email sales. Fine-tunes can stay proprietary, and research use has no cap. Fine for side projects, a real problem if your company is bigger and assumed "open weights" meant Apache. Qwen3.5 2B, the 64.0-average model from the same card, is the obvious fallback if legal says no.
Should you switch from LFM2-VL?
For OCR and screenshots, yes. You download about the same amount, and 9 of the 10 overlapping benchmarks go up even with thinking off. Native resolution also means small UI text stops getting squashed into 512px tiles. Wait a week if you're on MLX. Skip it if you need multi-turn chat about an image, because Liquid itself tells you not to use it that way.
So which would you run for local OCR right now: LFM3-VL-2B with thinking off, or Qwen3.5 2B? And if you've tried LFM3-VL with thinking on and off, do the card's numbers match what you're seeing?