LiquidAI LFM3-1.7B: A 1GB Local AI Model Built for Agents
LFM3-1.7B is LiquidAI's tri-hybrid model that runs in about 1GB at 4-bit. Here's how it works and how to run it locally.
What is LFM3-1.7B?
LFM3-1.7B is a 1.73-billion-parameter language model from Liquid AI, built specifically for running agents on phones and laptops rather than data centers. At 4-bit quantization it takes up roughly 1GB of memory, small enough to sit comfortably on a modern smartphone alongside everything else running on the device. It uses a tri-hybrid architecture mixing convolutions and attention, supports a 256K-token context window, and ships with GGUF, MLX, ONNX, and FP8/NVFP4 variants so it runs on nearly any hardware.
TL;DR
- LFM3-1.7B packs 1.73B parameters into about 1GB of memory at 4-bit precision, making it practical for on-device deployment on phones and laptops.
- The model uses a tri-hybrid architecture with 24 layers split across gated short convolutions, sliding-window attention, and global attention, rather than a standard all-attention transformer stack.
- It supports a 256K-token context window (input plus output) and a 128,000-token vocabulary covering 16 languages including English, Arabic, Chinese, and Hindi.
- Liquid AI post-trained it for agentic harnesses like Hermes Agent, Pi, and OpenClaw, with native tool calling and a “tool search” mechanism for working with large tool catalogs.
- You can run it through Ollama, llama.cpp, LM Studio, or MLX on Apple Silicon, or via vLLM, SGLang, and Transformers for GPU serving.
- Liquid AI explicitly recommends against using it for agentic coding or complex multi-step reasoning, positioning it instead for tool calling, structured output, and retrieval-backed tasks.
- The model is fine-tunable on a single GPU using TRL, with published recipes for structured JSON extraction, retrieval-grounded QA, tool-routing, and continued pretraining on new languages.
Plans first. Then code.
Remy writes the spec, manages the build, and ships the app.
Why build a 1GB model for agents?
Most “small” open models still target 7B to 8B parameters, which generally require several gigabytes of RAM even when quantized, putting them out of reach for always-on, low-power deployment on phones or embedded devices. LFM3-1.7B goes smaller on purpose. The pitch from Liquid AI is that a lot of agentic work doesn’t need a model that can reason about advanced mathematics or write production code. It needs a model that can reliably call the right tool, format a response correctly, and stay fast and cheap enough to run locally without draining a battery or needing a network round trip.
That tradeoff shapes everything about the model. Liquid AI’s own documentation is blunt about the limits: LFM3-1.7B is not recommended for agentic coding or complex multi-step reasoning. It’s built for a narrower job: local agents, tool calling, structured outputs, and domain-specific fine-tuning, with retrieval or search handling anything knowledge-heavy that the model itself can’t hold in its weights.
How does the tri-hybrid architecture work?
LFM3-1.7B’s 24 layers aren’t uniform. According to the model card, the stack breaks down into 13 gated short convolution layers, 5 sliding-window attention layers, and 6 global attention layers. That’s the “tri-hybrid” part: three distinct layer types working together instead of the all-attention design used in standard transformers.
The practical effect of this mix is efficiency. Convolutional layers are cheaper to compute than attention and handle local patterns well. Sliding-window attention captures mid-range dependencies without the quadratic cost of full attention. Global attention layers, used more sparingly, handle the long-range connections that need to see across the entire 256K-token context. Combining these lets the model support a long context window and agentic workloads while keeping the compute and memory footprint small enough for CPUs and mobile chips, not just GPUs.
This is consistent with Liquid AI’s broader LFM (Liquid Foundation Model) lineage, which has leaned on hybrid and non-transformer architectures across its model families specifically to hit efficiency targets that pure transformer designs struggle to match at small sizes.
What can you actually do with it?
The model card lists four areas LFM3-1.7B is explicitly tuned for:
- Tool calling. The model generates structured tool calls using an XML-based format (
<tool_call><function=...>), and the chat template handles formatting tool definitions and results automatically. - Tool search for large catalogs. For agents with many available tools, LFM3-1.7B supports “deferred tools”: tool definitions stay out of the prompt until a search step surfaces the relevant ones, then the chat template inserts them into context. This matters for real-world agent harnesses that might have dozens or hundreds of tools registered, since stuffing them all into every prompt wastes context and can confuse smaller models.
- Structured outputs. Good for parsing messy documents into JSON or enforcing specific response formats.
- Domain-specific fine-tuning. Liquid AI published Colab notebooks for four fine-tuning approaches: supervised fine-tuning (SFT) for extracting structured JSON from documents, direct preference optimization (DPO) for retrieval-grounded question answering, group relative policy optimization (GRPO) for tool-routing across a 108-tool phone app scenario, and continued pretraining (CPT) for teaching the model a new language (Turkish, in their example) from raw text.
The model also supports a reasoning mode by default, wrapping its internal thinking in <think> tags, though Liquid AI notes this can be disabled with enable_thinking=False and that the behavior “can be inconsistent, especially for reasoning-heavy tasks.”
How do you run LFM3-1.7B locally?
Liquid AI ships LFM3-1.7B in multiple formats depending on your hardware:
- GGUF for llama.cpp, Ollama, or LM Studio, the standard route for running it on a laptop CPU or consumer GPU.
- MLX (4-bit) for Apple Silicon Macs, taking advantage of Apple’s unified memory architecture.
- ONNX for cross-platform inference via ONNX Runtime.
- BF16 weights for GPU inference through vLLM, SGLang, or Hugging Face Transformers.
- FP8 and NVFP4 quantized checkpoints for GPU inference via SGLang, aimed at production serving rather than local use.
For local agent use, the realistic path is Ollama or llama.cpp with the GGUF build, or MLX if you’re on a Mac. Liquid AI recommends specific sampling settings depending on the task: temperature=0.1, top_k=50, repetition_penalty=1.1 for general chat, tool use, and coding, versus temperature=1.0, top_p=0.95, top_k=20 for math and science tasks. If you’re using llama.cpp directly, Liquid AI notes you need a GGUF with the current chat template, or you should load it manually with --chat-template-file, since the tool-calling and tool-search behavior depends on that template being correct.
Is LFM3-1.7B worth using over other small models?
It depends on what you’re building. If the job is a lightweight agent that needs to call a handful of tools, run offline on a phone or laptop, and respond quickly without burning battery or bandwidth, a sub-2B model purpose-trained for exactly that use case is a reasonable fit, especially given the 256K context window, which is unusually long for a model this size. The multilingual support (16 languages) also broadens where it’s useful beyond English-only agents.
Where it’s not a good fit: anything requiring heavy reasoning, multi-step planning, or code generation. Liquid AI is upfront that this isn’t the model for agentic coding. If your agent needs to debug a script or chain together complex logical steps, a larger model, even a 7B or 8B one, will likely outperform it. The right mental model is a specialist, not a generalist: fast, cheap, good at narrow structured tasks, and meant to be fine-tuned further for your specific domain rather than used as-is for open-ended work.
Frequently Asked Questions
How much memory does LFM3-1.7B need to run?
At 4-bit quantization, LFM3-1.7B takes up approximately 1GB of memory, according to Liquid AI’s model card. Higher-precision formats like BF16 will require more memory and are intended for GPU serving rather than on-device use.
What is a tri-hybrid architecture?
It refers to LFM3-1.7B’s layer design, which combines three different layer types across its 24 layers: 13 gated short convolution layers, 5 sliding-window attention layers, and 6 global attention layers. This mix is intended to balance efficiency with the ability to handle both local patterns and long-range context.
Can I fine-tune LFM3-1.7B myself?
Yes. Liquid AI designed it for single-GPU fine-tuning via TRL and published example notebooks covering supervised fine-tuning, DPO, GRPO, and continued pretraining, including a tool-routing example across a 108-tool catalog and a new-language learning example using Turkish.
Does LFM3-1.7B support tool calling?
Other agents ship a demo. Remy ships an app.
Real backend. Real database. Real auth. Real plumbing. Remy has it all.
Yes. It generates tool calls in an XML format and supports “deferred tools,” where tool definitions are only loaded into context after a search step identifies which ones are relevant, useful for agents with large tool catalogs.
What should I avoid using LFM3-1.7B for?
Liquid AI explicitly advises against using it for agentic coding or complex multi-step reasoning, since its small size limits that kind of deep logical chaining. It’s built for tool calling, structured outputs, and retrieval-backed tasks instead.
