LFM2.5-VL-3B Gives the Edge Eyes. Keep Its Hands Tied.
A field technician points a phone at an equipment panel. The model reads the labels, locates the warning light, and returns a bounding box without sending the frame to a cloud API. That is the compelling LFM2.5-VL-3B demo.
The dangerous next sentence is: “So let it operate the machine.”
Liquid AI has released a credible local pair of eyes. It has not collapsed perception, planning, permission, and control into one trustworthy 3 GB agent. That distinction is the useful way to read LFM2.5-VL-3B, a 3.12 billion-parameter open-weight vision-language model announced on August 12.
Its strongest launch evidence is about seeing: screen understanding, object grounding, document OCR, multi-image input, and low-latency visual response. The model can also generate function calls, but its tool-use scores are less convincing than its grounding scores. Liquid itself recommends single-turn, high-throughput work and advises against long-context or reasoning-intensive tasks.
Even the “3 GB” headline needs a label. It describes a quantized deployment using Q4 language weights and an F16 vision projector. The native BF16 checkpoint is about 6.25 GB. All capability and speed numbers available on launch day were measured or published by Liquid; no independent reproduction of this exact checkpoint was available.
That still leaves a meaningful release. The edge now has a deployable visual worker that can turn private pixels into typed observations. Builders should put a policy gate between those observations and anything with consequences.
The safe loop keeps perception, policy, and action separate. Low-confidence observations leave the local lane; consequential actions require an independent gate and a new frame to verify the outcome.
The launch becomes easier to evaluate when we stop treating “vision-language model” as one indivisible capability. Follow a screenshot from capture to action and the model’s strengths—and the missing system around it—become obvious.
The released processor configuration divides large images into non-overlapping 512 × 512 tiles and includes a resized thumbnail of the whole image. It budgets 64 to 256 visual tokens per image, with limits of 10 tiles and 1,024 patches.
That is not an implementation footnote. A phone screenshot, scanned form, dashboard, or camera frame often needs both global context and tiny local detail. The thumbnail preserves the overall layout; tiles give small labels and controls a chance to survive resizing. The token and tile limits also make the compute budget explicit.
For builders, the variable is not simply “one image.” It is:
image dimensions
× tile count
× image-token budget
× number of frames
× text context
= actual visual workload
The model accepts multiple images, which makes comparisons and short frame sequences possible. But the documented product context remains 32,768 tokens. The checkpoint config contains max_position_embeddings: 128000; Liquid’s model documentation and model card both promise 32K. Until longer multimodal context is validated, 128K is a config value, not a product capability.
LFM2.5-VL-3B can answer questions about screens, locate objects described in natural language, and emit normalized bounding boxes on a 0–1,000 coordinate scale. Its document mode can return ordered regions for titles, text, lists, images, equations, code, and tables. Tables use OTSL, an optimized table-structure format.
Liquid’s launch results show why this part of the model deserves attention:
These are launch-vendor results, not independent measurements. Liquid’s own launch page and model card differ slightly on some competitor values, while Qwen’s card reports different results for Qwen3.5-2B under its own settings. Prompts, resolution, reasoning mode, runtime, and harness all matter. The fair conclusion is not that Liquid won a universal leaderboard. It is that Liquid reports a large specialist gain in screen and object grounding within roughly the same model size.
The OCR interface needs even more caution. Liquid explicitly calls its layout-annotation format experimental: it may change, may be unreliable, and may not be easy to parse. Treat the output as an unstable upstream API. Version the parser, validate every region, retain page coordinates, and have a fallback for malformed tables or missing blocks.
The broad shape of the model did not change much. The released config shows a 2.6B LFM language backbone paired with a roughly 400M SigLIP2 NaFlex vision encoder. The language stack mixes 22 short-convolution layers with eight full-attention layers. Exact checkpoint metadata lists 3,123,483,888 parameters.
Liquid says the language base was pretrained on about 34 trillion tokens, its vocabulary doubled to 128,000, and vision pretraining consumed four times as many visual tokens as the prior model. Post-training combined supervised fine-tuning, larger-teacher distillation, Antidoom training, and multi-reward reinforcement learning. Synthetic grounding data received particular emphasis.
The result, in Liquid’s evaluation, is a 30.8-point RefCOCO gain and a 33.1-point ToolSandbox gain without moving to a larger parameter tier. Not everything improved: CountBenchQA fell from 92.2 to 87.3 and POPE slipped from 89.2 to 88.7.
This is the first non-obvious lesson of the release: the competitive unit for small VLMs is becoming the training mixture plus the delivery bundle, not parameter count alone. Better synthetic coordinates, targeted post-training, direct-answer behavior, quantized artifacts, parsers, and runtime support can change the product more than another billion generic parameters.
Liquid does not disclose the absolute vision-token count, full dataset inventory, synthetic-data generator, teacher identity, reward mixture, evaluation prompts, or complete eval code. Builders can inspect the weights and artifacts; they cannot independently audit the training recipe from the launch material.
Liquid presents the model as fast on phones, workstations, and H100 servers. All three statements can be true while describing completely different purchase decisions.
| Workload | Metric that matters | Liquid-reported result | What the number does not prove |
|---|---|---|---|
| Interactive endpoint | Decode rate, memory, thermals, and battery | 228 tok/s on M5 Max; 116 on Ryzen AI Max+ 395; 20 on tested Galaxy CPU | Qwen3.5-2B was faster on the same M5 and phone chart; sustained power and heat were not published |
| Short multi-frame loop | Time to first token | 34 ms for five 256 × 256 frames on one H100 | LFM was not the lowest-latency model on every single-image case |
| Batched visual service | Aggregate output under concurrency | About 11,000 tok/s on one H100 SXM5 | The result assumes BF16, vLLM 0.26, fixed image/text sizes, and sustained in-flight load |
Liquid’s on-device profile uses Q4_K_M language weights, an F16 vision projector, one 512 × 512 image, 1,024 text input tokens, and 64 output tokens. Under that profile, the model used 3,257 MB on M5 Max, 3,045 MB on the AMD machine, and 3,056 MB on the tested phone.
The same chart shows why “fastest edge VLM” would be careless. Qwen3.5-2B reached 237 tokens per second on M5 Max and 23 on the phone while using less memory in two of the three listed systems. LFM’s clearest differentiated results are the five-frame first-token latency and high-concurrency H100 throughput—not a clean sweep of consumer hardware.
At 11,000 output tokens per second, the arithmetic reaches about 950 million output tokens per day. That makes “nearly one billion” fair for Liquid’s specific benchmark. It does not describe a day of variable production requests, prompt processing, queueing, retries, or downtime. Our vLLM 0.27 analysis explains why a serving claim is really a contract across checkpoint, parser, quantization, kernels, driver, runtime, and recovery behavior.
The most instructive artifact is not the leaderboard. It is the GGUF repository.
Measured runtime: roughly 3.0–3.26 GB. Native BF16 artifact: about 6.25 GB. MLX 8-bit checkpoint: about 3.72 GB on disk.
The Q4_K_M language file is 1,674,454,240 bytes. The separate F16 multimodal projector adds 853,993,088 bytes before runtime buffers, visual tokens, and KV cache. Quantizing the language model does not make the vision tower disappear.
That creates a vision quantization floor. Text-model back-of-the-envelope math based on bits per language weight understates the system. For device selection, download budgets, browser caches, app packaging, and memory-pressure tests, the deployable unit is the checkpoint plus projector plus processor plus runtime state.
This is still a major improvement over workstation-sized local agent stacks. In our Muse Glimmer deployment teardown, the meaningful unit was a roughly 24 GB combination of model, projector, cache, runtime, and sandbox. LFM brings a narrower visual-worker role down toward phone and browser budgets.
Liquid shipped native Transformers weights, GGUF variants for llama.cpp, an 8-bit MLX export, ONNX artifacts and a WebGPU demo, plus vLLM and SGLang serving paths. That is unusually complete launch packaging.
It matters because visual agents fail to become products when they require a research-only inference path. A browser demo can keep a camera still or screenshot on the device. MLX gives Apple Silicon a first-class route. llama.cpp opens CPU-heavy deployments. vLLM and SGLang turn the same family into a visual extraction service.
RohitAI has already argued that the browser is becoming a first-class local inference surface. LFM2.5-VL-3B strengthens that pattern: private perception can happen near the data, while only a compact observation or ambiguous case travels elsewhere.
But a list of framework logos is evidence of intent, not identical portability. Liquid’s public pages currently disagree on minimum Transformers and vLLM versions, and its headline H100 test uses vLLM 0.26. Pin the checkpoint revision, runtime, quantization, projector precision, prompt template, image resolution, sampling parameters, and output schema. “Supported” should mean that exact manifest passed your fixtures.
LFM2.5-VL-3B’s tool support works like a normal model protocol. The host provides schemas; the model emits a Python-like function call between special tokens; the host parses and executes it; the result returns to the model. The weights do not reach into an operating system and perform an action by themselves.
That is good. It gives the application a place to say no.
The launch results argue for using that place aggressively. ScreenSpot-v2 at 80.7 and RefCOCO at 87.9 suggest useful visual localization in Liquid’s harness. BFCL v4 at 32.5 does not support a story in which the same model should freely select functions, construct arguments, and execute consequential workflows. Scores from different benchmarks are not directly subtractable; the pattern still says perception is the stronger product surface.
A safer observation contract looks like this:
{
"frame_id": "screen-1842",
"target": "Approve payment button",
"bbox_0_1000": [742, 884, 916, 947],
"confidence": 0.91,
"proposed_action": "click",
"requires_approval": true
}
The policy layer then checks frame freshness, coordinate transforms, target allowlists, action idempotency, confidence, user role, and consequence. After the action, a new screenshot must confirm the intended state. If the target is ambiguous, the local model should escalate rather than guess.
The UK AI Security Institute’s large public agent-security competition collected 1.8 million prompt-injection attempts and more than 60,000 successful policy violations across the tested agents. That research did not test LFM2.5-VL-3B, but its system lesson applies: model capability and agent robustness are separate properties. A smaller local model still needs allow-listed tools, sandboxing, approvals, and outcome verification.
The same checkpoint can sit in three very different systems.
Use it for screenshot localization, menu translation, document intake, product-image classification, or camera assistance where raw pixels should stay on the device. Optimize sustained latency, memory, battery, and quantization quality.
Keep OCR, grounding, and routine classification local. Send compact observations or low-confidence cases to a stronger planner. This is the best general architecture when privacy and reasoning quality both matter.
Serve high-volume document, catalog, moderation, or visual-extraction queues on vLLM or SGLang. Optimize accepted outputs per GPU-hour, concurrency, queue time, parser validity, and recovery—not phone tokens per second.
Avoid a fourth personality: the unbounded local operator. Liquid discourages reasoning-heavy and highly technical visual tasks. A 32K direct-answer model that sees a control does not automatically understand the long workflow, policy, or physical consequence behind it.
The weights are public and downloadable without an access gate. The legal rights are narrower than the phrase “without restrictions” suggests.
The controlling LFM Open License v1.0 grants free commercial rights only while the user or legal entity remains below $10 million in annual revenue. Commercial use by an entity at or above that threshold is not licensed by the public agreement. Larger organizations need separate terms.
That is not a small procurement footnote. A startup can build below the threshold, embed the model into data pipelines and output contracts, then face a licensing event precisely when adoption makes migration expensive. Direct peers such as Qwen3.5-2B, Gemma 4 E2B, and InternVL3.5 list Apache 2.0 licenses on their model cards.
The architecture review should therefore ask two independent questions:
As our open-weight customization analysis put it, access to weights, practical operating access, and legal permission are separate contracts. Liquid publishes no model-specific token price; LEAP lists core tooling as free and directs enterprise support and scaling to sales.
A public benchmark average cannot tell you whether small text survives your display scaling, whether a table parser breaks on rotated scans, or whether Q4 changes a tool argument. Build the evaluation around the complete loop.
For a screen agent, the primary metric should be verified task completion without an unsafe action. Break that into perception accuracy, coordinate accuracy after transforms, schema validity, policy-gate rejection quality, action success, and verification success. A model can improve at one stage while the complete system gets worse.
For document work, score region recall, reading order, table reconstruction, parser failure detection, and human correction time. For an H100 service, add p50/p95 first-token latency, throughput at realistic request mixes, queue saturation, memory peaks, and recovery after malformed images.
The benchmark you want is not “tokens per second.” It is “accepted visual outcomes per unit of constrained compute.”
LFM2.5-VL-3B does not need to be a tiny frontier model to matter. It needs to make visual perception cheap enough that products stop treating every screenshot, page, and camera still as a cloud-model event.
I expect three consequences.
First, visual-agent stacks will split into sight, judgement, permission, and action. A compact local VLM will read and ground. A larger model or deterministic service will plan when needed. A policy engine will authorize. A constrained runner will act. A new frame will verify. That decomposition is easier to test and lets sensitive pixels remain local.
Second, small-model moats will move toward data and runtime delivery. Liquid kept the broad 3B architecture shape and reported large improvements through more vision training, synthetic grounding, distillation, RL, and coordinated exports. Competitors can match parameter counts quickly. Reproducing the task mixture, parsers, quantization quality, and device support is harder.
Third, “edge model” will stop naming one hardware class. The useful continuity here runs from a WebGPU tab to a phone CPU, Apple Silicon, an AMD workstation, and a high-concurrency H100 service. Compute location becomes a route chosen per task, not a permanent product badge. The raw frame can stay local while only uncertainty travels.
There are reasons to wait. Independent reproductions may reorder Liquid’s comparisons. Sustained thermals and energy use are unknown. Runtime guidance needs cleaner version pins. The experimental OCR contract can change. The revenue threshold may be unacceptable. Qwen, Gemma, InternVL, and specialized UI models may win particular device or task profiles.
But the direction is sound. Captioning is no longer the interesting ceiling for small VLMs. The practical frontier is a model that reads the screen, points to the right object, extracts the right structure, and hands a typed observation to a system that knows whether it is allowed to act.
Liquid has made that visual handoff small enough to run almost anywhere.
The edge has better eyes. Keep the hands behind a gate.
Only under a quantized deployment profile. Liquid’s device benchmark uses Q4_K_M language weights plus an F16 vision projector, with measured memory around 3.0–3.26 GB. The native BF16 checkpoint is about 6.25 GB, and memory also depends on image tiles, context, KV cache, runtime, and output length.
Liquid provides ONNX artifacts and a WebGPU demo that runs in the browser, plus GGUF files for llama.cpp. The company reports 20 output tokens per second on a tested Galaxy S26 Ultra CPU. Hardware support, download size, memory pressure, battery, and sustained thermals still need device-specific testing.
It can understand screens, return normalized bounding boxes, and generate function calls from text or vision-text prompts. The host application parses and executes those calls. The release does not establish that the model is safe or reliable as an autonomous computer-use agent.
It is more precise to call it open-weight under the LFM Open License v1.0. The weights are downloadable and modifiable, but the public license stops granting commercial-use rights when the relevant user or legal entity reaches $10 million in annual revenue.
Liquid’s product documentation and model card specify 32,768 tokens. The checkpoint config contains a 128,000 positional setting, but Liquid has not documented or validated a 128K multimodal product context for this release.
Start with bounded, high-volume tasks: screenshot element localization, document OCR and layout extraction, image classification, product-image processing, sign or menu translation, and natural-language object grounding. Escalate long planning, ambiguous visual reasoning, and consequential decisions.