LFM3-1.7B is Liquid AI’s text-only model for specialized local applications. Its official Q4_K_M GGUF download is about 1.10 GB, making it a small artifact to try on a laptop. That file size does not establish how much memory your application will use, especially with long prompts or several requests running together.
The practical starting point is a compatible runtime, a modest context allocation and a task with answers you can check. Liquid’s model card lists 1.73 billion parameters and a 256K-token input-plus-output window. It recommends retrieval for knowledge-heavy work and advises against agentic coding or complex multistep reasoning. Those boundaries matter when deciding what to automate.
Pick the text checkpoint and a compatible build
The LFM3 family includes separate vision, audio and omni models. Downloading the 1.7B text checkpoint does not give an application those other inputs. Liquid’s release explanation describes a shared backbone but distinct models for different modalities.
Text and vision support merged into llama.cpp on October 27. Use a build containing that change. An older installed binary can fail to recognize the architecture even when the GGUF file downloaded correctly; changing quantization will not fix an unsupported architecture.
With an LFM3-compatible llama-cli available, this follows the official GGUF instructions, adding an explicit 8,192-token context allocation for an initial trial:
llama-cli -hf LiquidAI/LFM3-1.7B-GGUF:Q4_K_M \
-c 8192 --temp 0.1 --top-k 50 --repeat-penalty 1.1The download selector chooses Q4_K_M. The context setting is a proposed starting configuration, not Liquid’s maximum or a measured hardware requirement. Keep the build revision and selected file in your run notes so a later update can be compared with the same setup.
The repository also contains a QAD Q4_0 checkpoint, which Liquid says was trained to recover accuracy lost to Q4_0 quantization. It is a separate artifact. Record which one you used rather than treating every four-bit file as interchangeable.
Budget beyond the 1.10 GB download
The official file listing reports Q4_K_M at 1,099,627,808 bytes, QAD Q4_0 at 1,049,615,680 bytes and BF16 at 3,466,626,336 bytes. Dividing by one billion gives approximately 1.10 GB, 1.05 GB and 3.47 GB respectively. These are stored file sizes, not observations of resident RAM or VRAM.
A useful lower-bound calculation is 1.73 billion × 4 ÷ 8 = 865 million bytes for an ideal four-bit parameter payload. The actual Q4_K_M file is larger. Quantized formats carry additional information, and the process also needs working allocations that are absent from the downloaded file. The lower bound cannot be used as an application memory requirement.
Liquid’s architecture mixes 13 short-convolution layers, five sliding-window attention layers and six global attention layers. The sliding windows cover 256 tokens. This explains why applying a dense-transformer cache formula to all 24 layers would misrepresent the model. It also leaves global attention in the design: the small weight artifact does not make long context free.
For your first measurement, record process memory after loading, during prompt processing and during generation. On a GPU system, record device memory separately. Repeat at 8K and 32K with the same output allowance and one request at a time, then test the concurrency your application actually needs. Those measurements answer whether your machine has headroom; the advertised maximum window does not.
Check the application contract before specializing
A small local model can be useful when success has a narrow definition: assigning a support ticket to a permitted category, extracting fields or selecting an allowed tool. The same task becomes harder when it requires broad factual recall, ambiguous policies or many dependent actions.
The model card says thinking is enabled by default. In its Transformers interface, enable_thinking=False requests no thinking, but Liquid warns that this can be inconsistent, particularly on reasoning tasks. Do not build a strict latency or output-format guarantee around that switch without checking actual responses.
Build a small acceptance set before fine-tuning: 20 ordinary inputs, 10 ambiguous ones, 10 with missing information and 10 deliberately malformed inputs. Define the expected category, required fields or allowed tool for each. This is a proposed evaluation, not a result from an EyesTech model run.
Count valid formatting separately from correct decisions. For example, 48 valid JSON responses out of 50 is 96% format compliance; it says nothing about how many chosen actions were right. Include an explicit abstention path for missing information and reject tool arguments that fail your application’s schema. A plausible tool selection should still pass permission checks before execution.
The release uses the custom LFM Open License v1.0, including commercial-use conditions. Check those terms for the intended deployment. The engineering case for trying it is its small local footprint and specialization focus; adoption should depend on measured memory, response time and correctness on your task.
Reporting note: Prepared with AI assistance from primary sources checked October 28, 2026. File conversions and payload arithmetic are EyesTech calculations. No model weights were downloaded or inference benchmarks run. The cover is an original AI-generated editorial illustration.
