LiquidAI LFM3-1.7B: A Local Agent Model That Fits on a Phone

Liquid AI released LFM3-1.7B, a 1.73-billion-parameter edge language model that runs in roughly 1GB of memory at 4-bit precision, targeting on-device agents and tool calling on phones and laptops. The model uses a 24-layer "tri-hybrid" architecture — 13 gated short convolution layers, 5 sliding-window attention layers and 6 global attention layers — with a 256K-token context window, a 128,000-token vocabulary and native support for 16 languages, shipping in BF16, FP8/NVFP4, GGUF, MLX and ONNX formats. Liquid AI post-trained LFM3-1.7B for agentic harnesses such as Hermes Agent, Pi and OpenClaw and recommends against using it for agentic coding or complex multi-step reasoning, positioning it instead for structured tool calling and single-GPU fine-tuning on domain-specific tasks.

LiquidAI LFM3-1.7B: A Local Agent Model That Fits on a Phone LFM3-1.7B is a 1.73B-parameter edge model running in ~1GB at 4-bit, built for on-device agents, tool calling, and fine-tuning. What is LFM3-1.7B? LFM3-1.7B is a 1.73-billion-parameter language model from Liquid AI, built specifically to run agents and tool-calling workflows on phones and laptops rather than in the cloud. At 4-bit precision it needs roughly 1GB of memory, small enough to load on consumer hardware without a dedicated GPU. It ships as part of the broader LFM3 family base, text, vision, audio, omni, and decision variants and is distributed in multiple formats, including GGUF, MLX, and ONNX, so developers can deploy it across the inference stacks already common on edge devices. TL;DR - LFM3-1.7B packs 1.73B parameters into a footprint of about 1GB at 4-bit quantization, making it viable for on-device deployment on phones and laptops. - The model uses a tri-hybrid architecture of 24 layers mixing gated short convolutions, sliding-window attention, and global attention, rather than a standard transformer-only design. - It supports a 256K-token context window covering both input and output, which is unusually large for a model this size. - Liquid AI post-trained it specifically for agentic harnesses like Hermes Agent, Pi, and OpenClaw, with built-in support for structured tool calling and deferred tool search. - It ships in six deployment formats : BF16 and FP8/NVFP4 for GPU serving via vLLM and SGLang, and GGUF, MLX, and ONNX for CPU, Apple Silicon, and cross-platform on-device inference. - Liquid AI explicitly recommends against using it for agentic coding or complex multi-step reasoning , positioning it instead for narrower, specialized tasks. - The model supports fast fine-tuning on a single GPU, with published recipes for structured extraction, retrieval-grounded QA, tool selection, and even learning a new language from raw text. - ✕a coding agent - ✕no-code - ✕vibe coding - ✕a faster Cursor The one that tells the coding agents what to build. How is LFM3-1.7B different from a typical small language model? Most small open models under 2B parameters are standard transformers: stacks of attention layers trained to be general-purpose chat assistants. LFM3-1.7B takes a different structural approach. Its 24 layers split into three mechanisms: 13 gated short convolution layers, 5 sliding-window attention layers, and 6 global attention layers. Liquid AI calls this a “tri-hybrid” architecture. The practical effect is a model that can handle long context efficiently while staying small enough to fit in about 1GB of RAM at 4-bit precision. The 256K-token context window covering both prompt and generation is large for a model this size, and the convolution-heavy layer mix is part of how Liquid AI keeps inference cheap on constrained hardware, which is the whole point of an edge-targeted design. The vocabulary sits at 128,000 tokens and the model natively covers 16 languages, including English, Arabic, Chinese, French, German, Japanese, Korean, Russian, and Hindi. What is LFM3-1.7B actually good for? Liquid AI positions LFM3-1.7B for three jobs: local agents, tool calling with structured outputs, and domain-specific fine-tuning. The model card is explicit that it is not built for agentic coding or complex multi-step reasoning, which rules out tasks like autonomous software engineering agents or long chains of logical deduction. For knowledge-heavy questions, the recommendation is to pair it with retrieval or search rather than relying on what the model has memorized, since a 1.73B model simply can’t hold as much world knowledge as larger systems. Where it’s meant to shine is narrower, well-defined work: an agent running on a phone that needs to call a fixed set of functions, parse user intent, and return structured output, or a specialized assistant fine-tuned on a company’s own documents and formats. The model was post-trained for agentic harnesses including Hermes Agent, Pi, and OpenClaw, suggesting Liquid AI built it with existing agent frameworks in mind rather than expecting developers to write orchestration from scratch. How does tool calling work in LFM3-1.7B? Tool calling is a first-class feature in the chat template, not a bolt-on. Developers pass function schemas through the tools parameter when applying the chat template, and the model generates calls in an XML-style format wrapped in <tool call tags. The application executes the call, appends the result as a tool message, and keeps passing the tool schemas on subsequent turns. More notable is support for “deferred tools” and tool search. Instead of stuffing every available function definition into the prompt which burns context and can confuse smaller models when the tool list gets long , developers can mark tools with defer loading=True . The model is then told, via the system prompt, that it has a search tools function it can call to find the right tool by name before using it. The harness’s search returns a tool reference , and the chat template inserts the actual tool definition into the context only when needed. This matters a lot in phone-app scenarios where an agent might need to pick the correct function out of a hundred or more options. Liquid AI’s own fine-tuning examples include a GRPO reinforcement learning recipe trained specifically on a 108-tool phone app scenario, which signals this is a use case they tested directly, not a theoretical one. This deferred-tool mechanism works with vLLM, SGLang, and LFM3-compatible llama.cpp builds, provided the GGUF file includes the current chat template or it’s loaded explicitly with --chat-template-file . What deployment formats does it support? LFM3-1.7B ships in six checkpoint variants, split between GPU-oriented and edge-oriented formats: - BF16 : full-precision weights for GPU inference via vLLM, SGLang, or Transformers. - FP8 : 8-bit quantization for GPU inference through SGLang. - NVFP4 : 4-bit floating-point quantization for GPU inference through SGLang. - GGUF : for local inference on CPUs and GPUs via llama.cpp, Ollama, or LM Studio. - MLX : 4-bit quantized for Apple Silicon. - ONNX : for cross-platform inference through ONNX Runtime. This spread covers both ends of the deployment spectrum: data-center-grade serving with FP8 or NVFP4 on GPUs, and consumer-grade local inference through formats that run on an iPhone, a MacBook, or a Windows laptop without a discrete GPU. The GGUF and MLX paths in particular are what make phone and laptop deployment realistic, since both formats are designed around quantization and limited memory rather than raw throughput. Is LFM3-1.7B worth using over a larger model? The answer depends entirely on the task. For general chat quality, broad world knowledge, or complex reasoning, a larger model will outperform LFM3-1.7B by a wide margin, and Liquid AI says as much on the model card itself. The tradeoff that justifies LFM3-1.7B is deployment: a 1GB footprint means it can run entirely on-device, with no API costs, no network latency, and no data leaving the device. For privacy-sensitive applications, offline agents, or products where every API call to a cloud model adds cost at scale, that tradeoff can matter more than raw capability. The model is also built to be fine-tuned quickly on a single GPU, with Liquid AI publishing example notebooks for supervised fine-tuning structured JSON extraction from documents , DPO answering from retrieved documents or declining when unsure , GRPO tool selection in a 108-tool environment , and continued pretraining learning a new language from raw text . That combination of small size, agentic post-training, and fast customization is the actual pitch: not a general assistant, but a base you shape for one job and run locally. Frequently Asked Questions How much memory does LFM3-1.7B need to run? At 4-bit quantization, LFM3-1.7B needs about 1GB of memory, which is why Liquid AI markets it as fitting on phones and laptops. Higher-precision formats like BF16 or FP8 require more memory and are intended for GPU serving rather than on-device use. Can LFM3-1.7B write code or do complex reasoning? Liquid AI explicitly advises against using it for agentic coding or complex multi-step reasoning, citing its small parameter count. It’s designed for narrower tasks like tool calling, structured output, and domain-specific applications, not as a general coding or reasoning model. What inference engines support LFM3-1.7B? It supports vLLM, SGLang, and Transformers for GPU inference BF16, FP8, NVFP4 , plus llama.cpp, Ollama, and LM Studio for GGUF, MLX for Apple Silicon, and ONNX Runtime for cross-platform deployment. Does LFM3-1.7B support multiple languages? Remy is new. The platform isn't. Remy is the latest expression of years of platform work. Not a hastily wrapped LLM. Yes. It covers 16 languages including English, Arabic, Chinese, French, German, Italian, Japanese, Korean, Portuguese, Spanish, Vietnamese, Thai, Indonesian, Hindi, Russian, and Polish. How is LFM3-1.7B licensed? It’s released under the LFM Open License v1.0, a custom license from Liquid AI rather than a standard Apache or MIT license, so developers should review its specific terms before commercial deployment.