Anyways, keep 'em coming.
edit: on bigger tests, got it to loop pretty easily unfortunately, probably local settings.
Been playing around for a few hours with the poolside/Laguna-S-2.1-NVFP4 + poolside/Laguna-S-2.1-DFlash-NVFP4 + vLLM, been seeing the same behaviour. Usually new model releases are plagued with issues at release though, best to wait 1-2 weeks then retry, or better yet, investigate yourself :) Personally I haven't found any obvious issues.
[deleted]
The pricing here is incredible. This is the first US release that's competitive with DeepSeek V4 Flash. Very excited about this.
That said, if someone would kindly quantise this down for the 64GB paupers, that would be appreciated. (I know there’s likely degradation, but some people reported good results with a 2 bit version of Qwen 3.5 122B, and this is starting from a higher point. Would be interesting to try, at least.)
Edit: someone in the process of doing so: https://huggingface.co/vcruz305/Laguna-S-2.1-GGUF
For a while there's been nothing to run on my Strix Halo that's notably better than what I can run on my dual 32GB GPU desktop (Gemma 4 or Qwen 3.6 dense models), but this seems likely to be the step up in size that actually works better than those.
A lot of people are testing it, and reporting disappointed results / benchmaxxxing claim. But do not realize that thinking has a issue with the default configuration.
Important - make sure that THINKING is enabled. By default it wasn't although I was passing the flag --default-chat-template-kwargs '{"enable_thinking": true}' in vllm recipe. The generation_config.json file that is included has by default max_new_tokens as 32k which seems to be cutting off thinking altogether so increase it. At first I was very disappointed with the output I was seeing, but once thinking is enabled, the code quality seems to be MUCH better. More real world testing to be done.
https://www.reddit.com/r/LocalLLaMA/comments/1v2pg99/laguna_...
Also, I really like Poolside's habit to compare not only to other top models in its weight class (others don't do it, looking at you Mistral), but also to the very top open-weight models, even much bigger ones like the 2.5T Kimi-K3!
Even more important, subjectively, is that this model will run very well on Strix Halo (e.g. Framework Desktop), DGX Spark kinds of devices. Looking forward to Unsloth dynamic mtp quants.
P.S. Looking at the HF release they already offer Q4_K_M and DFlash drafter for speculative decoding!
+
https://poolside.ai/assets/laguna/laguna-m1-xs2-technical-re...
I need to evaluate their large hosted model.
similar performance to deepseek v4, inkling at size of nemotron 3 super (!)
$0,10 / $0,20per 1M
from openrouter
host: Apple M3 Max, 128 GB model: Laguna-S-2.1, 118B-A8B MoE, Q4_K_M (75 GB), DFlash speculative decoding server: http://127.0.0.1:8000, llama.cpp, ctx 64K, 8-bit KV cache
mode: max thinking
# tokens tok/s dflash
1 600 14.4 11%
2 600 26.1 27%
3 600 17.8 18%
4 600 14.0 16%
5 600 9.3 15%
--------------------------------
median 14.4 mean 16.3 min 9.3 max 26.1 tok/s
mode: no thinking
# tokens tok/s dflash
1 190 10.0 20%
2 109 26.7 65%
3 95 29.6 72%
4 93 32.8 81%
5 382 14.0 30%
--------------------------------
median 26.7 mean 22.6 min 10.0 max 32.8 tok/s[dead]
[dead]
[dead]
From Poolside CEO Eiso Kant on Twitter:
> Learning we have some bugs on the RTX6000. We’re on it. Team has worked non stop last days and it’s getting late for a lot of the inference folks, so might be until tomorrow till we have a solution. - https://x.com/eisokant/status/2079693050796785720
Update2: I'm now running poolside/Laguna-S-2.1-NVFP4 with vLLM 0.23.1rc1.dev1378+gd6dbdb9b0 (FlashInfer 0.6.14) and seeing slightly better results in regards to the looping. I can't see any specific changes that would affect this though, strangely enough.
> The BF16 checkpoint doesn't exhibit any of the complaints [...] with our current quants, the models tend to choose the wrong logits sometimes [...] why we'll need a requant [...] We're not aware of any bugs in any runtimes themselves [...] We have two remaining things that we're trying to tackle: some people are reporting thinking being too hard to trigger (^^) , and others are saying it thinks too much. We've seen much more of the latter internally
/* Just started testing with the gguf (with gpu offload, m5 max 128gb), q4_k_m, running seemingly well. Speed is initially slightly faster than antirez/ds4 - decode tok/s in the 30s, prefill ~400-ish. Expected, given the slightly smaller size. Looks to be working fine, but too early to tell. Definitely likes to "think". */
Anyways, guessing that discord might be focusing on the nvfp4 stuff. I've noticed spelling mistakes in the thinking traces, tool calls have been fine so far.
[deleted]
Running deepseek flash on something locally now, this will have to wait a bit. I still stand by my initial quick assessment - looks capable. Some people on r/localllama also reported loops. We'll see in ~10 hours. Hopefully I haven't terribly mislead people.
https://github.com/vllm-project/llm-compressor
my setup to help you on your way: https://github.com/verdverm/quantr
Though it seems these will not be needed as Poolside has published quants & dflash with their models.
https://huggingface.co/poolside/Laguna-XS-2.1-GGUF/tree/main
Maybe the chat template is broken, maybe not. But I can't get it to think/reason, or at least sometimes it seems to decide not to even when asked. And it is wildly inconsistent when it does it, sometimes thinking out loud.
However, without thinking enabled it is shockingly good at researching using web tool calls. It's also very fast.
I am assuming something is not yet right with the chat template, even using a recent build of llama.cpp, and I guess I will revisit this model again at some point in the future.
The Q4_K_M is 75GB. I'm exactly at 64GB, and I wouldn't quantize it further. Instead, do partial weight residency and stream the rest from SSD.
In the huggingface link they mention building for CPU and for CUDA, does anyone know if that means it wouldn’t be possible to build targeting Vulkan?
Someone has benchmarked a wide range of different quants.
Laguna S 2.1 runs at 15-28 tokens per second, depending on context and...something about how long it's been running, which is very comfortable for chatting, but still not usable for interactive agentic coding. Their `pool` agent just times out when I try to use it with the Strix Halo-hosted instance of the model.
[deleted]
[deleted]
[deleted]
This is pretty impressive.
Edit: it amazes me how fast ik_llama.cpp moves
Let me also look at the GameLogic::update() to see the rest of the update flow, especially the object update loop.
Actually, I think I have enough information now. Let me also check the GameLogic::UPDATE to understand the full update flow.
Since they mentioned that they're working on new quants, guess I'll wait. From earlier tests on work stuff, it's definitely capable.
https://huggingface.co/poolside/Laguna-S-2.1-FP8/discussions...
Wait time.
> we've got an NVFP4 checkpoint that has a KD of 0.135 relative to the BF16 checkpoint (for W4A4, on some GSM8K prompts). [...] We're still seeing some looping on W4A4 (although much less than before), whereas for W4A16 we've not been able to make it loop. Given that W4A4 is still a little broken, we won't make this an official release (we have one more idea planned to fix that). [...] The RC1 for NVFP4 is reachable as poolside/Laguna-S-2.1-NVFP4 @ RC1
Seems to be available already indeed: https://huggingface.co/poolside/Laguna-S-2.1-NVFP4/tree/RC1
Unfortunately I don’t know about the best way of running on an Nvidia gpu, you could try llama.cpp and offloading as many layers as possible into the gpu and using RAM for the rest, not sure if that would slow it down too much though.