TL;DR: Laguna M.1 is Poolside’s biggest open-weight model — 225B total parameters, 23B active, Apache 2.0, released April 28, 2026. It scores 72.5% on SWE-bench Verified, but the community Q4_K_M GGUF is ~125GB, upstream llama.cpp doesn’t support the architecture (you need a patched fork), and Poolside’s own July release — Laguna S 2.1, at roughly half the size — outscores it on every shared benchmark. Unless you’re fine-tuning from the Apache 2.0 base checkpoint, run S 2.1 or the free API tier instead.

	Community GGUF at home	Official checkpoints, rented	API
What you need	256GB DDR5 build, or 192GB+ unified memory	FP8 on 4 datacenter GPUs; BF16 on an 8×H200 node	An OpenRouter key
Weights	Q4_K_M ~125GB via linuxid10t/Laguna-M.1-GGUF	FP8 / NVFP4 from poolside/Laguna-M.1-*	none
The catch	Patched llama.cpp fork only — no Ollama tag, no official GGUF	You’re renting a small cluster for a superseded model	$0.20/$0.40 per M tokens — and a free variant exists

Honest take: M.1 is three months old, and in model-years that was a lifetime. Poolside itself shipped Laguna S 2.1 in July — 118B total, 8.5B active, 78.5% SWE-bench Multilingual against M.1’s 67.3% — with official GGUFs and an Ollama tag. M.1’s Q4 needs ~53GB more memory to run a model that benches lower and decodes slower. The only people who should download these weights are teams who want an Apache 2.0 base checkpoint of this scale to fine-tune. Everyone else: the free OpenRouter tier answers “is it any good for my work?” without buying anything.

Poolside’s Laguna family has a confusing shape in August 2026, so the map first. The April 28 launch brought Laguna XS.2 (33B) and Laguna M.1 (225B) under Apache 2.0 — the company’s first public models after years of building in private, per VentureBeat’s launch coverage. July brought the 2.1 generation — XS 2.1 (33B) and S 2.1 (118B) — which we covered yesterday. M.1 is still the largest Laguna you can download. It is no longer the best one. That gap between “flagship-sized” and “flagship” is what this guide is about, because a 225B Apache 2.0 model is exactly the kind of headline that talks people into $4,000 hardware decisions.

What M.1 actually is

The specs, from Poolside’s launch post and the Hugging Face model card: 225B total parameters in a Mixture-of-Experts layout activating ~23B per token, trained from scratch on 30T tokens across 6,144 Hopper GPUs. Context window is 262,144 tokens (256K), with native interleaved reasoning — the model can think between tool calls rather than only before them, which matters for long agentic sessions.

The architecture details, from Poolside’s deeper-dive post, explain both its strengths and its memory bill: 3 dense SwiGLU layers followed by 67 sparse MoE layers with 256 experts and top-16 routing, trained with the Muon optimizer, RoPE positions extended via YaRN. Two choices stand out for anyone planning local inference:

• Global attention on every layer. 64 query heads, 8 KV heads, softplus attention output gating — and no sliding-window layers anywhere. Every one of the 70 layers attends over the full context.
• Top-16 routing over 256 experts. That’s how 225B total lands at 23B active — nearly three times the ~8.5B active of S 2.1. Active parameters are what your memory bandwidth moves per token, so this ratio sets decode speed everywhere from EPYC builds to unified-memory boxes.

Benchmarks as Poolside reported them on April 28: 72.5% SWE-bench Verified, 67.3% SWE-bench Multilingual, 46.9% SWE-bench Pro, 40.7% Terminal-Bench 2.0 (MarkTechPost’s summary has the full table alongside XS.2’s 68.2% Verified). Those were competitive numbers in April. The problem is what shipped in July.

The supersession math

Put the three downloadable Lagunas side by side and M.1’s position collapses:

	XS 2.1 (Jul 2)	S 2.1 (Jul 21)	M.1 (Apr 28)
Total / active params	33B / ~3B	118B / ~8.5B	225B / ~23B
SWE-bench Multilingual	63.1%	78.5%	67.3%
SWE-bench Pro	—	59.4%	46.9%
Terminal-Bench	33.4% (2.1)	70.2% (2.1)	40.7% (2.0)
Q4-class weights	20GB	~71.7GB	~125GB
Official GGUF / Ollama tag	yes / yes	yes / no	no / no
License	OpenMDW-1.1	OpenMDW-1.1	Apache 2.0

S 2.1 beats M.1 by 11 points on SWE-bench Multilingual and 12.5 on SWE-bench Pro while needing a bit more than half the memory and moving about a third as many active parameters per token — meaning it’s also markedly faster on the same hardware. Even XS 2.1, the 33B that runs at 296 tok/s on a used RTX 3090, lands within 4.2 points of M.1 on Multilingual at one-sixth the Q4 footprint.

The usual caveat applies in both directions: these are vendor-reported scores on Poolside’s own harness, and we flagged the methodology concerns (max-of-sources comparisons, harness overfit) in the S 2.1 write-up. But this table compares Poolside to Poolside on Poolside’s harness — the fairest read available, and it says the company out-trained its own flagship one quarter later. Their 2.1-generation data pipeline and FP8 reinforcement-learning stage went into the smaller models first. M.1 never got the refresh.

The memory bill, checkpoint by checkpoint

Poolside publishes M.1 in three official precisions on Hugging Face, plus a separate base checkpoint:

• BF16: ~450GB of weights — sized for a single 8×H200 node, per the model card.
• FP8: roughly half that; Poolside’s deployment guidance targets 4 datacenter-class GPUs. There’s an official vLLM recipe if you rent that.
• NVFP4: 4-bit floating point for Blackwell — arithmetic says ~115–120GB of weights, which still clears every consumer card and every 96GB workstation card. NVFP4’s hardware path needs RTX 50-series or newer, same as we covered for Qwen3.6 NVFP4.

What Poolside did not publish for M.1 — and did publish for XS 2.1 — is a GGUF or MLX conversion, and there’s no Ollama library tag. The community filled the gap: linuxid10t/Laguna-M.1-GGUF carries conversions from ~420GB at F16 down to ~125GB at Q4_K_M.

Now add the KV cache, and remember that global-attention design. With 8 KV heads across all 70 layers and standard 128-dim heads, the arithmetic works out to roughly 280KB per token at FP16 — call it ~18GB of cache at 64K context and 70GB+ at the full 256K window (our math from the published architecture, not a measured figure; quantized KV halves it). Models with sliding-window layers shed most of that. M.1 doesn’t. A “125GB model” is realistically a 145–200GB deployment the moment you use the context window that makes it interesting.

The fork problem: unknown model architecture: 'laguna'

Here’s the part that stops most people before the memory math even matters. Download the community GGUF, point stock llama.cpp at it, and the load fails immediately:

$ llama-cli -m Laguna-M.1-Q4_K_M-00001-of-00003.gguf -p "hello"
...
llama_model_load: error loading model: error loading model architecture: unknown model architecture: 'laguna'
llama_model_load_from_file_impl: failed to load model

That error normally means a stale build or a wrong file — but here no update fixes it, because upstream llama.cpp has no Laguna support at all as of early August 2026. The M.1 quants were made and tested against a patched fork that implements the architecture, per the GGUF repo’s own model card. The fix is building that fork:

git clone https://github.com/linuxid10t/llama.cpp-add-laguna
cmake -B build -DGGML_CUDA=ON && cmake --build build --config Release

Workable, but be clear about what you’re signing up for: no Ollama, no LM Studio, no officially supported runtime — a single maintainer’s fork for a 125GB download. XS 2.1 is ollama run laguna-xs-2.1 and 20GB. That contrast is the whole Laguna-at-home story in one sentence.

What would actually run it

Say you still want to. Three paths, priced with early-August numbers:

A 256GB DDR5 + 24GB GPU offload build (~$3,500–$4,500). The same shape as the Kimi K2.7 CPU build: attention and shared layers on a used RTX 3090 (~$1,050 average on eBay per BestValueGPU), the 256-expert tensors in system RAM via --n-cpu-moe. But where S 2.1 moves ~8.5B active parameters per token, M.1 moves ~23B — from dual-channel DDR5 at ~90GB/s, bandwidth arithmetic caps decode in the low single digits of tok/s before overheads. The verified analogue on this site: the GMKtec EVO-X2 runs Qwen3-235B-A22B — nearly identical 235B/22B geometry — at ~11 tok/s, and that’s on 256GB/s of unified bandwidth. Expect worse from desktop DDR5.

A 128GB unified-memory box. Doesn’t fit Q4. 125GB of weights plus KV plus the OS overruns 128GB, so you’re down to Q3/Q2-class quants — the accuracy tax we always warn about — for a model whose selling point was capability. And unified-memory pricing jumped ~75% this summer, so this path costs more than it did when M.1 launched.

Multi-GPU. Four used 3090s give you 96GB — not enough for the weights alone. This only closes at 192GB+ of VRAM, which is two RTX PRO 6000 Blackwells or a rented pod. At that point run the official FP8 on RunPod with the vLLM recipe for a weekend and let the benchmark numbers, not the download size, tell you whether it earns permanent hardware.

Against all three, the API column is brutal: OpenRouter lists M.1 at $0.20 input / $0.40 output per million tokens with the full 256K context and 32K output — among the cheapest frontier-adjacent coding endpoints of 2026 — and there’s a $0 free variant for evaluation. A million output tokens for forty cents makes “years of API use” cost less than the RAM kit in the CPU build.

Who M.1 is actually for

One group genuinely benefits from these weights existing, and it isn’t inference hobbyists. M.1 is the largest Apache 2.0 coding-focused MoE with a published base checkpoint — S 2.1 and XS 2.1 ship under OpenMDW-1.1 (also permissive, but newer and less lawyer-tested), and plenty of big open models never release the base at all. If you’re a team fine-tuning a code model on proprietary data and your legal department wants the boring license, poolside/Laguna-M.1-base on rented H200s is a legitimately rare asset. That work happens on cloud clusters — pair it with a coding-agent stack from our sister site aicoderscope.com when you get to the tooling side — not on anything with a single power connector.

For everyone else, the ranking hasn’t changed since yesterday’s piece: XS 2.1 on a 24GB card for daily local agent work, S 2.1 via expert offload or API when you need the extra capability, and M.1 as a free-tier curiosity. The largest model in a family is the headline. It’s almost never the right download.

FAQ

Can I run Laguna M.1 on a single GPU? No. The smallest useful quant (community Q4_K_M) is ~125GB of weights before KV cache — beyond any consumer card (RTX 5090: 32GB) and beyond 96GB workstation cards. Single-GPU setups need expert offload to 128GB+ of system RAM and a patched llama.cpp fork, at single-digit tok/s.

Does Ollama or LM Studio support Laguna M.1? No, as of August 2026. There’s no Ollama library tag and no official GGUF; stock llama.cpp fails with unknown model architecture: 'laguna'. Only the community fork at linuxid10t/llama.cpp-add-laguna loads the GGUF conversions. XS 2.1 is the family member with first-class Ollama support.

Is Laguna M.1 better than Laguna S 2.1? On Poolside’s own reported benchmarks, no — S 2.1 (118B) scores 78.5% SWE-bench Multilingual and 59.4% SWE-bench Pro against M.1’s 67.3% and 46.9%, while needing about half the memory and decoding roughly 3× fewer active parameters per token. M.1’s advantages are the Apache 2.0 license and the public base checkpoint.

Why is the 225B model cheaper on the API than smaller frontier models? Sparse MoE economics — only ~23B parameters activate per token — plus provider competition and the model’s superseded status. OpenRouter lists $0.20/$0.40 per million tokens, with a free variant for testing.

What’s the minimum hardware to experiment with M.1 locally? Realistically a 24GB GPU plus 256GB of DDR5 (~$3,500–$4,500 built new), running the Q4_K_M GGUF with expert offload on the patched fork. Bandwidth math and the closest verified analogue (Qwen3-235B-A22B at ~11 tok/s on 256GB/s unified memory) say to expect single-digit token speeds on desktop DDR5.

Sources

• Introducing Laguna XS.2 and Laguna M.1 — Poolside
• Laguna XS.2 and M.1: A Deeper Dive — Poolside
• poolside/Laguna-M.1 model card — Hugging Face
• poolside/Laguna-M.1-NVFP4 — Hugging Face
• poolside/Laguna-M.1-FP8 — Hugging Face
• poolside/Laguna-M.1-base — Hugging Face
• Laguna-M.1-GGUF community quants (Q4_K_M ~125GB, patched-fork requirement) — linuxid10t, Hugging Face
• llama.cpp-add-laguna fork — GitHub
• Poolside AI Introduces Laguna XS.2 and M.1: 68.2% and 72.5% on SWE-bench Verified — MarkTechPost
• Poolside launches free, high-performing open model Laguna XS.2 — VentureBeat
• Laguna M.1 API pricing and providers — OpenRouter
• Laguna M.1 (free variant) — OpenRouter
• poolside/Laguna-M.1 deployment recipe — vLLM Recipes
• Used RTX 3090 price history — BestValueGPU

Last updated August 3, 2026. Prices and specs change; verify current rates before purchasing.