Laguna-S-2.1 seems to look pretty good

· 23 Jul 2026

Just two days ago, I published my current workflow with the feeling that in some weeks I can probably share the next update. Today, it seems that Poolside shipped a model that already introduces some change. They have released Laguna-S-2.1, a 118B total parameter Mixture-of-Experts (MoE) model with 8B activated parameters per token. It supports up to 1M tokens in context. I was excited to see in their benchmarks that they actually compare themselves to very recent model releases that are larger than their own model. Typically, vendors only compare against models that are worse than their own. Here, we can see the relative performance much better.

While Laguna-S-2.1 is not the next frontier model, it has a very important attribute for me: its 4-bit quantisation fits on a MacBook Pro with 128 GB of RAM. Furthermore, I was excited to see that they also released a DFlash speculator and llama.cpp (via their fork) on the same day. This means I can test it out locally immediately and also might get good performance through the existence of a speculator.

Running plain Laguna-S-2.1 on a MacBook

Poolside themselves provide GGUF files for use with llama.cpp on HuggingFace. We can use the Q4_K_M quant with a size of 75.2GB for the MacBook. In my tests, I will use a 128GB version, but given its size, you might be lucky with a 96GB MacBook, too.

While there is llama.cpp support is available, it is only for now on their fork in the laguna branch. Meanwhile, upstream support in llama.cpp has landed while I was writing this post. This is only for the base model, not the DFlash speculator, though. Thus, in what follows, we will use their fork.

Instead of compiling llama.cpp from their branch, I used my conda-forge expertise to provide builds in my inference-extensions channel on prefix.dev. You can use that with the following pixi.toml:

[workspace]
channels = ["https://prefix.dev/inference-extensions", "conda-forge"]
name = "laguna-llama.cpp"
platforms = ["osx-arm64"]
version = "0.1.0"

[dependencies]
# Keep the build = "laguna*" here. I might upload other llama.cpp builds in the future.
# By keeping the build, you can get updates via `pixi update` without switching to a different fork.
"llama.cpp" = { version = "*", build = "laguna*" }
huggingface_hub = ">=1.24.0"

If you want to use this on Linux, replace "osx-arm64" with { platform = "linux-64", cuda = "12.9" } (or linux-aarch64) to get a CUDA-enabled version. I had to skip the Windows builds because the free GitHub Actions runners are insufficient for the large build.

You can then install it and download the models using:

pixi shell
hf download hf://poolside/Laguna-S-2.1-GGUF/laguna-s-2.1-Q4_K_M.gguf
hf download hf://poolside/Laguna-S-2.1-GGUF/laguna-s-2.1-DFlash-BF16.gguf
hf download hf://poolside/Laguna-S-2.1-GGUF/laguna-s-2.1.imatrix

The models are then downloaded to a directory that follows the pattern ~/.cache/huggingface/hub/models--poolside--Laguna-S-2.1-GGUF/snapshots/<commit-id>. Set LAGUNA_DIR to the directory displayed when running the commands in the following examples.

⚠️ 2026-07-23 18:15 UTC: It seems that the latest GGUFs broke tool calling in pi. e08e1fe855bb2d43f96ad78e24495283f3426c67 still works for me. To select them, add @08e1fe855bb2d43f96ad78e24495283f3426c67 after …GGUF to the hf download calls.

The most basic command you can use is:

llama-server -m $LAGUNA_DIR/laguna-s-2.1-Q4_K_M.gguf --jinja --port 9995

This already runs the model pretty well, with around 600 t/s for pre-fill and ~30 t/s for decode. This brings it slightly above the numbers I get with DeepSeek-V4-Flash in 2-bit quantisation with ds4.

For now, I have settled on the following command, where I reused some options I had from previous Qwen3.6 tunings. These seemed to be fitting in this case and led to a slight performance increase (650 t/s prefill, 33 t/s decode). The speedup is probably mostly from using slightly less RAM and thus having less inference with my browser that I’m running at the same time.

llama-server -m $LAGUNA_DIR/laguna-s-2.1-Q4_K_M.gguf \
    --n-gpu-layers 99 \
    --cache-type-k q8_0 \
    --cache-type-v q8_0 \
    --parallel 1 \
    --mlock \
    --alias laguna-s-2.1 \
    -fa on \
    --jinja \
    --port 9995 \
    --kv-unified

The numbers mentioned here are not collected in a reproducible manner; they are observations from use to give you a rough hint. They are also solely collected on coding tasks as this is a coding-specific model

DFlash drafter (speculator)

One thing that really excited me is that they also provided a DFlash drafter. While 33 tokens per second during decoding is decent compared to the alternatives, it is far from the ~120 t/s I get with some cloud-hosted models (e.g., GLM 5.2). While we probably won’t get there soon, getting much closer would help a lot.

Adding the DFlash speculator is according to their documentation by adding the following arguments to llama.cpp:

-md laguna-s-2.1-DFlash-BF16.gguf --spec-type draft-dflash --spec-draft-n-max 15

Sadly, this drops the decode performance to ~5 t/s. This could also be related to exhausting RAM (now llama.cpp uses all my available RAM), but I also see draft acceptance rates of <0.023. So it seems that, by default, the speculator adds RAM usage but not any performance improvement.

This is another instance where they have fixed something while writing the blog. Someone already posted about this on HuggingFace. Meanwhile, they released an updated drafter. With this update, I get an acceptance rate of roughly 10% (0.1), and the decode performance increases to 10 t/s. Sadly, this is still way less than without a drafter. As I saw an average draft acceptance length somewhere between 2 and 3, I adjusted the parameter to ` –spec-draft-n-max 3`. This brought my decode performance up to ~45 t/s.

Verdict after a day

After a bit more than 24h with the model, I’m still as excited as I was when I saw the first benchmarks. The performance seems, anecdotally, in line with the benchmarks, and it is on track to remain my new local default. It seems a bit more chatty than DeepSeek-V4-Flash, but also more capable. That’s fine for me. If DFlash performance improves, I could disregard this entirely. The day-zero availability for several serving engines, the speculator availability, and the fact that they have already pushed various updates to the model and serving engines is a great interaction. While poolside has been very quiet for the past year(s?), this is a great next step. Still, memory is quite tight; thus, I’m running it only with a context length of 256k. While the 1M context might fit within the total memory of my MacBook, my desktop applications wouldn’t fit anymore.