LFM2.5 2.6B VRAM Requirements: What 2.69B Hybrid Actually Needs
How Much VRAM Does LFM2.5 2.6B Need?
2.08 GB at Q4_K_M with an 8K context, rising to 4.40 GB at the full 128K context. Weights are 1.67 GB and do not move. What moves is the KV cache: 0.13 GB at 8K, 2.15 GB at 128K. Liquid AI reports "under 2.5 GB" at 220 tok/s on an M5 Max but does not disclose the quantization level or context length behind that figure.
The short answer on LFM2.5 2.6B VRAM requirements is that any 8GB card runs this model at any context it supports. The interesting part is why the long-context number stays as low as it does.
LFM2.5-2.6B is Liquid AI's on-device agentic model, released August 4, 2026. It is a hybrid: 22 short-convolution layers plus 8 grouped-query attention layers, 30 layers total, 2.69 billion parameters, 131,072 token context. Weights are on Hugging Face under the LFM Open License v1.0, which permits commercial use up to $10M annual revenue. The lab publishes GGUF quantizations itself.
Every tier below. The weights column is the lab's own published GGUF file sizes, so those are measured rather than estimated. KV cache and totals come from our calculator at F16 KV under llama.cpp, including its 15% runtime overhead:
| Quantization | Weights | KV at 8K | Total at 8K | KV at 128K | Total at 128K |
|---|---|---|---|---|---|
| BF16 / F16 | 5.40 GB | 0.13 GB | 6.37 GB | 2.15 GB | 8.68 GB |
| Q8_0 | 2.87 GB | 0.13 GB | 3.46 GB | 2.15 GB | 5.78 GB |
| Q6_K | 2.22 GB | 0.13 GB | 2.71 GB | 2.15 GB | 5.02 GB |
| Q5_K_M | 1.94 GB | 0.13 GB | 2.39 GB | 2.15 GB | 4.70 GB |
| Q4_K_M | 1.67 GB | 0.13 GB | 2.08 GB | 2.15 GB | 4.40 GB |
| Q4_0 | 1.59 GB | 0.13 GB | 1.99 GB | 2.15 GB | 4.30 GB |
Note what the last two columns do. Going from 8K to 128K, a 16x increase in context, costs 2.01 GB. On a standard transformer of this size it would cost several times that. The next section is why.
The Hybrid Architecture: Why Long Context Stays Cheap
LFM2.5-2.6B is not a standard transformer. Its 30 layers split into two types, and only one of them cares about context length:
- 22 short-convolution layers (
convin config.json). Each holds a fixed 3-token recurrent state atconv_dim2048. That state is the same size at 1,000 tokens as at 131,072. All 22 layers together hold 0.27 MB, and that number never changes. - 8 grouped-query attention layers (
full_attention). Standard GQA: 32 query heads, 8 KV heads, head_dim 64. These are the only layers whose cache grows.
The arithmetic is short enough to check by hand. 8 layers x 8 KV heads x 64 head_dim x 2 tensors for K and V x 2 bytes at F16 = 16,384 bytes per token. At 8,192 tokens that is 0.13 GB. At 131,072 tokens it is 2.15 GB.
Run the same calculation on a conventional 30-layer model with all layers attending, and you get 8.05 GB at 128K instead of 2.15 GB. Roughly a quarter of the cost, because roughly a quarter of the layers are doing the caching. That is the whole trick, and it is a straightforward one.
Confirmed in config.json: conv_L_cache: 3, conv_dim: 2048, num_key_value_heads: 8, head_dim: 64, num_hidden_layers: 30, max_position_embeddings: 131072, and a layer_types array listing all 30 layers individually.
Observed GGUF Sizes vs Computed
The lab publishes GGUF files directly, so the weight figures here are measured file sizes rather than estimates. Computed sizes use effective bits per weight, which is what the format actually stores: Q8_0 writes 8.5 bits per weight, not 8, because each 32-value block carries a scale alongside it. Use nominal bpw instead and you invent a discrepancy that is not there.
| Quant | Observed file | Effective bpw | Computed | Delta |
|---|---|---|---|---|
| BF16 / F16 | 5.40 GB | 16.00 | 5.39 GB | +0.01 GB |
| Q8_0 | 2.87 GB | 8.50 | 2.87 GB | +0.01 GB |
| Q6_K | 2.22 GB | 6.57 | 2.22 GB | +0.01 GB |
| Q5_K_M | 1.94 GB | 5.67 | 1.91 GB | +0.03 GB |
| Q4_K_M | 1.67 GB | 4.85 | 1.64 GB | +0.04 GB |
| Q4_0 | 1.59 GB | 4.50 | 1.52 GB | +0.08 GB |
Every delta is at or under 0.08 GB. What remains is the parts of the file that are not quantized at the headline rate: token embeddings are commonly promoted to a higher precision, and GGUF metadata carries its own small cost. The effect is proportionally largest on the lowest tier, which is why Q4_0 shows the widest gap. Observed sizes are what you actually download, so plan capacity against those.
CPU Inference: What the Vendor Claims
Liquid AI's blog states, on August 4, 2026:
- 220 tok/s on Apple M5 Max
- 113 tok/s on AMD Ryzen AI Max+ 395
- 30 tok/s on a phone
- All "under 2.5 GB"
Neither the quantization nor the context length is disclosed for any of those figures, which limits what they can be compared against. Our own numbers put Q4_K_M at 2.08 GB at 8K, so "under 2.5 GB" is consistent with a short context at Q4_K_M or Q4_0. It is not consistent with a long one: the same quant reaches 4.40 GB at 128K. We label the claim vendor-reported, quantization and context undisclosed.
No independent throughput measurements exist yet. The model launched on August 4 and community reports typically take a few days.
GPU Fit: What Runs Where
| GPU | VRAM | Q4_K_M at 8K | Q4_K_M at 128K | Notes |
|---|---|---|---|---|
| RTX 4060 / RTX 3060 8GB | 8 GB | Yes (26%) | Yes (55%) | Comfortable at every context |
| RTX 3080 10GB | 10 GB | Yes (21%) | Yes (44%) | Fine |
| RTX 3060 12GB / RTX 4070 12GB | 12 GB | Yes (17%) | Yes (37%) | Plenty of headroom |
| Arc A750 8GB | 8 GB | Yes (26%) | Yes (55%) | Intel Xe driver maturity varies |
| Arc A770 16GB | 16 GB | Yes (13%) | Yes (27%) | Comfortable |
| RTX 3090 / RTX 4090 24GB | 24 GB | Yes (9%) | Yes (18%) | Overkill for this model |
| M-series 8GB unified | 8 GB | Yes (26%) | Yes (55%) | System RAM shared, leave headroom for the OS |
At Q4_K_M every 8GB card holds this model at full context with room to spare. Q8_0 needs 5.78 GB at 128K, which still fits 8GB. Only BF16 at full context, 8.68 GB, pushes past a 8GB card and wants 10GB or more. For a 2.69B model, hardware is not the constraint.
Quantization Guidance
- Q4_K_M (1.67 GB) is the default choice: near-lossless, smallest practical download, fits everything.
- Q5_K_M (1.94 GB) buys a quality margin for 0.27 GB. On a model this small, that margin is nearly free.
- Q4_0 (1.59 GB) saves 0.08 GB over Q4_K_M and gives up more quality than that saving is worth. Skip it unless a runtime forces your hand.
- Q8_0 / BF16 for full fidelity. At this size the whole model still fits a mid-range card, so fidelity is affordable if you want it.
The model uses a ChatML-like template with a think tag inserted at assistant start. Generation defaults: temperature 0.1, top_k 50, repetition_penalty 1.1.
License Note
Weights are under the LFM Open License v1.0, not Apache 2.0. Commercial use is permitted up to $10M annual revenue, above which a separate agreement is required. Worth reading before it goes into a product, because "open weights" does not always mean what people assume.
Check what fits your GPU directly. It scans your hardware against every model in the catalog, LFM2.5 2.6B included.
Read more: llama.cpp Performance Flags That Matter on Low VRAM | Can My Gaming PC Run AI? | Chinese Open-Weight Models Top the Leaderboards
FAQ
How much VRAM does LFM2.5 2.6B need at 4-bit?
At Q4_K_M, 2.08 GB at an 8K context and 4.40 GB at the full 128K context, both including llama.cpp's 15% overhead. Weights account for 1.67 GB of that; the rest is KV cache, which is what grows with context.
Can I run LFM2.5 2.6B on an 8GB GPU?
Yes, at every quantization the lab publishes except BF16 at full context. Q4_K_M uses 26% of an 8GB card at 8K and 55% at 128K. Q8_0 reaches 5.78 GB at 128K, still inside 8GB. BF16 at 128K needs 8.68 GB and wants a 10GB card or larger.
What is the context length?
131,072 tokens, which is the 128K figure Liquid AI markets, set by max_position_embeddings in config.json. The KV cache at that length is 2.15 GB, because only 8 of the 30 layers cache anything that grows.
Does LFM2.5 2.6B use MLA or sliding-window attention?
Neither. It uses short convolution with a fixed 3-token state on 22 layers, and standard grouped-query attention with 8 KV heads on the other 8. No MLA, no sliding window, no compression of the attention cache itself. The saving comes from having fewer attention layers, not from making each one cheaper.
How much VRAM does the KV cache use at long context?
0.13 GB at 8K and 2.15 GB at 131,072 tokens, at F16. That is 16,384 bytes per token, from 8 attention layers x 8 KV heads x 64 head_dim x 2 tensors x 2 bytes. Quantizing the KV cache to Q8_0 roughly halves it.
What quantization should I use for agentic workloads?
Q4_K_M. The model is trained for tool use and multi-step reasoning at small scale, and K-quants keep attention tensors at higher precision than the headline rate suggests, which is the part agentic behaviour leans on most.
Is there an Apache 2.0 version?
No. The license is LFM Open License v1.0, with a $10M annual revenue cap on commercial use. There is no alternative licensing of the same weights.
Where are the GGUF files?
Hugging Face, under LiquidAI/LFM2.5-2.6B-GGUF. Seven files are published: BF16, F16, Q4_0, Q4_K_M, Q5_K_M, Q6_K and Q8_0. The lab builds them itself rather than leaving it to the community.
Does the calculator have this model?
Yes. LFM2.5 2.6B is in the catalog with its real layer split, so the KV figures shown here come from the same engine as every other model on the site rather than from a one-off spreadsheet.
What hardware does Liquid AI benchmark on?
M5 Max at 220 tok/s, Ryzen AI Max+ 395 at 113 tok/s, a phone at 30 tok/s, and an H100 SXM5 concurrency sweep for GPU serving. Quantization and context are not disclosed for the CPU figures, so treat them as vendor-reported rather than reproducible.
How does it compare to Qwen3 4B?
At Q4_K_M and 8K context, our calculator puts LFM2.5 2.6B at 2.1 GB against 4.2 GB for Qwen3 4B, so it needs roughly half. Only part of that is the smaller parameter count. The rest is the cache: Qwen3 4B attends on all 36 of its layers and holds 1.2 GB of KV at 8K, where LFM2.5 attends on 8 of 30 and holds 0.13 GB. The gap widens as context grows.