Yes, LFM3 can run locally—but start with the right checkpoint. Liquid AI released the open-weight LFM3 family on October 27, 2026. Its text model, LFM3-1.7B, has 1.73 billion parameters and an advertised roughly 1 GB 4-bit weight footprint. A current llama.cpp build can serve its GGUF checkpoint on a local CPU or supported GPU. That does not mean a complete speech-and-vision assistant consumes only 1 GB.
The practical decision for a PC or home NAS is to choose text, vision, audio, or omni before sizing hardware. The model file, encoder/decoder, runtime buffers, context state, image or audio input, and simultaneous requests all use resources. For a first trial, choose the 4-bit text model, a 4K–8K context, and a single request; measure memory and latency before enabling larger inputs or other NAS services.
| Local deployment question | Short answer |
|---|---|
| Are official checkpoints available? | Yes. Open weights and model cards are published by Liquid AI. |
| Is there one 2B model with every feature? | No. LFM3 is a family of specialized checkpoints sharing a backbone. |
| Can a home server run text inference? | Yes, when its selected GGUF model and runtime fit available RAM. CPU-only operation may be slow. |
| Does 1 GB mean total running RAM? | No. It describes the approximate 4-bit text-model weight footprint, not process peak. |
| Is 256K context practical on 8 GB RAM? | Do not assume so. Context, request count and backend change live memory demand. |
| Can ZimaOS host it? | A compatible Linux runtime is a plausible path, but this article is not a ZimaOS compatibility certification. |
What Exactly Did Liquid AI Release With LFM3?
LFM3 is a collection of six 2B-class models trained from the LFM3-1.7B-Base backbone: a text model, a vision-language model, an audio model, an omni model, and two decision-oriented variants. Liquid AI describes the family as suitable for specialized on-device applications. The important word is family: downloading LFM3-1.7B does not add an image encoder, microphone support, or a speech decoder automatically. See the LFM3 launch announcement and the model family overview.
| Official checkpoint | Main input / output | Published detail | Local deployment caveat |
|---|---|---|---|
| LFM3-1.7B | Text to text, structured responses and tools | 1.73B parameters; 256K context | Small weights, but context and concurrency need separate sizing. |
| LFM3-VL-2B | Text, images and video to text | 1.92B total; 128K context | Vision encoder, image tokens and video frames add cost. |
| LFM3-Audio-2B | Audio/text to text or speech | Around 2B; 32K context; 18 supported speech languages | Audio frontend, decoder and latency are separate from text weights. |
| LFM3-Omni-2B | Multimodal input to text/speech | Shared vision/audio/text path | Requires the omni-specific checkpoint and supported runtime. |
| d1-2B / d1-omni-2B | Calibrated decision outputs | Specialized from VL/Omni models | Evaluate for the intended decision task, not general chat. |
LFM3 weights use the LFM Open License v1.0. “Open-weight” is the accurate description: review the actual license for the intended distribution and commercial use instead of treating it as an OSI open-source software license. The model cards describe individual limits, including that the compact text model is not recommended for complex multi-step reasoning or agentic coding.
Why Does the Tri-Hybrid Architecture Matter for Edge Devices?
The 1.73B text backbone has 24 layers: 13 gated short-convolution layers, five sliding-window attention layers and six global-attention layers, according to the official text model card. Mixing these operations reduces the need to handle every token in every layer like full global attention while preserving some global context. It is a design choice for latency and memory efficiency, not an exemption from the costs of long prompts.
Liquid AI reports training on 22 trillion tokens and claims better quality per parameter than earlier LFM models. Those numbers are developer-reported results; they should not be interpreted as independent home-NAS benchmarks. The architectural gains help explain why a roughly 2B-class model can be useful for extraction, lightweight question answering and tool routing, yet model capability still depends on task difficulty, prompting and external retrieval.

How Much RAM, VRAM and Storage Do You Actually Need?
A transparent calculation helps: 1.73B × 4 bits / 8 ≈ 0.865 GB of idealized raw weights. Quantization metadata and file packaging raise that number, which is why Liquid AI describes the 4-bit text model as occupying about 1 GB. But the model still needs context state, execution buffers, allocators and application overhead. A running system may consume substantially more than the file size.
These are cautious trial configurations, not official model minimums or guaranteed tokens-per-second targets. They assume a single 4-bit text checkpoint, no large concurrent workload and sufficient free storage.
| Host class | Reasonable first test | Main limitation |
|---|---|---|
| 8 GB RAM, CPU only | Text GGUF; 4K context; one user | CPU latency and competition with NAS services. |
| 16 GB RAM, CPU or supported accelerator | Text first; then modest VL tests | Multimodal preprocessing and larger contexts need measurement. |
| 32 GB+ RAM with suitable GPU | Explore more ambitious VL/audio pipelines | Driver, backend, projector/decoder compatibility and peak memory. |
| ZimaCube 2 or another shared NAS | Keep checkpoints and project data on dedicated storage; size inference separately | Disk capacity cannot substitute for RAM, GPU memory or memory bandwidth. |
A 256K advertised context is a supported model limit, not a recommended starting setting. The runtime may hold substantially more state during large prompts and concurrent sessions. Use the ZimaSpace guide to local model RAM and GPU requirements and the explanation of model routing by complete memory footprint to plan from observed resource use, rather than parameter count alone.
Which LFM3 Model Should You Choose for a Home NAS?
For local text chat, tagging, extraction and lightweight tool-routing, LFM3-1.7B is the simplest experiment. For scanned documents, camera stills or visual inspection, choose LFM3-VL-2B; its model card notes a 164M-parameter vision encoder and 25M projector in addition to the language backbone. The official vision model card also specifies video sampling and frame limits. Inputting video is more expensive than reading a short plain-text prompt.
For voice interactions, LFM3-Audio-2B is an audio-specific system, not a free upgrade to the text GGUF. It supports multilingual speech, transcription and speech responses, while streaming performance is device-dependent. Choose LFM3-Omni-2B only when the workflow truly combines modalities and the exact backend supports that combination. A single GPU hosting chat, vision and audio pipelines must budget for peak simultaneous memory, as explained in our home-GPU multimodal guide.
How Can You Run LFM3-1.7B Locally With llama.cpp?
For the runtime side of this setup, see our llama.cpp 0.8.0 deployment guide, including the distinction between text inference and experimental realtime voice.
For a reproducible initial check, start with the published GGUF repository and llama.cpp v0.8.0 or a newer LFM3-compatible build. The example uses the official Q4_K_M variant and binds the server to loopback; it does not expose a model API to the internet. On a Linux host with Git, CMake and a compatible compiler:
git clone https://github.com/ggml-org/llama.cpp.git
cd llama.cpp
git checkout v0.8.0
cmake -S . -B build
cmake --build build --config Release -j --target llama-server
./build/bin/llama-server \
-hf LiquidAI/LFM3-1.7B-GGUF:Q4_K_M \
-c 4096 --host 127.0.0.1 --port 8080
Open http://127.0.0.1:8080 on that same machine, or test the server from its terminal:
curl -s http://127.0.0.1:8080/v1/chat/completions \
-H 'Content-Type: application/json' \
-d '{"model":"local","messages":[{"role":"user","content":"Explain quantization in three sentences."}],"max_tokens":128}'
The OpenAI-compatible API's exact model identifier can differ by server configuration. If your build rejects "local", first query /v1/models and use the ID returned there. Building the default CPU backend is a safe starting point; GPU acceleration requires selecting and testing an appropriate backend. The official GGUF card provides other runtime options, including Ollama and LM Studio. Treat them as alternative runtimes, not as evidence that every ZimaOS package already ships this exact model version.
To test vision later, use the documented LFM3-VL GGUF checkpoint and follow the official vision quick-start so that the matching vision projector is loaded. Do not replace the text model name in a random command and assume image input will work.
What Should You Verify Before Calling the Deployment Successful?
- Model identity: confirm the selected GGUF variant and runtime version, not merely that a download completed.
- Resource ceiling: record resident RAM/VRAM at idle, during prefill, and during a longer prompt; check that ZimaOS and other NAS apps retain headroom.
- Latency and quality: benchmark prompt processing, generated tokens per second, instruction-following, and correctness on five representative tasks.
- Privacy boundary: keep any local API on loopback or a trusted private network; authenticate and proxy access deliberately if other clients need it.
- Persistence: store downloaded model files away from the boot partition and preserve a clear separation between immutable weights and writable app state. See model-file and runtime-state separation and our local LLM deployment safety guide.
If a deployment works on a desktop but fails on a NAS, diagnose the complete path: quantized model size, correct bind mount, available RAM, backend choice, CPU instruction compatibility, projectors and context length. The model storage verification checklist is a useful companion.
FAQ
Is LFM3 fully open source?
Liquid AI publishes open weights under the LFM Open License v1.0. That does not automatically mean its models and training components satisfy every definition of open-source software; read the license before redistributing or monetizing a deployment.
Can I run LFM3 on a CPU-only PC or NAS?
The small GGUF text model can run through a compatible llama.cpp CPU backend if the operating system and available RAM support it. Whether it feels interactive depends on CPU performance, memory bandwidth and prompt length. Treat 8 GB as a practical test tier, not an official minimum.
Does LFM3-1.7B support image or speech input?
Not by itself. Use LFM3-VL for images/video, LFM3-Audio for speech, or LFM3-Omni where combined modalities are required. Each has different checkpoints and runtime dependencies.
Does a 1 GB 4-bit model need only 1 GB of RAM?
No. That number describes approximate quantized text weights. The serving process adds state, runtime buffers, token caches and operating-system usage. Long contexts and multiple users can dominate the difference.
Is 256K context available on every LFM3 model?
No. The text model advertises 256K; the vision model specifies 128K and the audio model 32K. Even a supported maximum is not a guarantee that a particular 8 GB device can serve it comfortably.
Can ZimaCube 2 or ZimaOS run LFM3 today?
A local inference stack is technically plausible when the chosen hardware, model and runtime fit. ZimaCube 2 is also useful for private model storage, documents and application services. The checks above are not a claim of an independently certified ZimaOS LFM3 installation or a measured throughput result.
Final Takeaway
LFM3 makes small, specialized on-device AI more practical, but the choice of checkpoint matters more than the headline “2B multimodal.” The clearest first win for a home server is a 4-bit LFM3-1.7B text model with a short context and controlled workload. Add vision and speech only when the specific checkpoint, runtime support and measured memory justify the change.
For a ZimaSpace setup, treat storage, inference and application access as separate decisions. A home NAS can hold model files, protect personal documents and coordinate local workflows even when a more powerful machine executes the model. If your interest expands to much larger open-weight systems, the Kimi K3 local hardware analysis shows how dramatically the memory boundary changes with parameter scale.
Sources and Scope
Official materials checked October 29, 2026: Liquid AI launch blog, family overview, text model card, vision model card, audio model card and llama.cpp v0.8.0 release. Performance claims are attributed to developers; hardware tiers and operational recommendations here are editorial estimates, not ZimaSpace benchmark results.
Cover image: Liquid AI, official LFM3 launch video thumbnail.
Tech & AI HUB
More to Read

What Factors Determine Recovery Point Objectives for a Home AI Stack?
A mechanism-first explanation of recovery point objectives for a home ai stack, its shared-resource tradeoffs, three query-fanout FAQs, and a practical.

What Components Detect Silent Divergence Between Replicated AI Indexes?
A mechanism-first explanation of what components detect silent divergence between replicated ai indexes, its shared-resource tradeoffs, three query-fanout FAQs.

What Features Enable Reliable AI Session Handoff Between Home Devices?
A mechanism-first explanation of reliable ai session handoff between home devices, its shared-resource tradeoffs, three query-fanout FAQs, and a practical.




