Poolside says Laguna needs an H200. We ran it on a single H100.

Poolside's recipes for Laguna S 2.1 start at an H200 with 141 GB of VRAM. The INT4 checkpoint alone is ~72 GB on disk. An 80 GB H100 appears in no supported configuration, and four days after release, we could not find published numbers for one.

We have exactly one H100 80GB, the shared box from the H100 series. So we tried it. It works: ~130 tok/s single-stream, which is faster than the 27B model we serve in production on the same card. The catch is not speed. It is KV-cache memory: roughly 2 concurrent long-context sessions against the ~256 our production model handles.

This is the companion piece to running Laguna on Strix Halo. Same model, opposite end of the hardware spectrum, same honest-numbers treatment.

The production stack it had to fit into

The context matters because it defines the bar. Our H100 runs 24/7 in UpCloud's fi-hel2 data centre in Helsinki, everything OpenTofu-managed, endpoint behind Caddy with Let's Encrypt. Serving engine is vLLM, v0.24.0 in production. The workload is agentic coding: long contexts, often 100K+, tool calls, tens of concurrent agents, heavily prefix-cache-dependent.

Production model is Qwen3.6-27B-FP8. Since the June posts we moved from the 35B MoE to this dense 27B, and the reason is the same one this whole post turns on: its hybrid-GDN attention gives it an unusually cheap KV cache, ~10 KB per token. That is what lets one card hold ~256 concurrent long-context sessions. Remember that number.

The model under test

Laguna S 2.1, released by Poolside on 2026-07-21. We tested it four days later. 117.6B total parameters, ~8.5B active per token (256 routed experts, top-10 per token plus 1 shared). Open weights under OpenMDW-1.1, commercial use allowed, with BF16/FP8/INT4/NVFP4 variants and DFlash speculative-decode draft models.

The quality claim that makes it interesting: SWE-bench Multilingual 78.5% against Qwen3.6-27B's 71.3%, and Terminal-Bench 70.2 against 59.3. Those are vendor figures, but a +7 point gap on the benchmark closest to our actual workload is worth a Friday evening.

The architecture detail that matters: hybrid attention. Only 12 of 48 layers are global; 36 use a 512-token sliding window, and the KV cache is natively FP8. Effective cost lands around 24 KB per token at long context. Cheap by frontier standards, but 2.4× our production model's, and that ratio decides the ending.

How we tested it without risking production

Two rules: production comes back the same night, and the IaC-managed stack does not change.

Research first. Before touching hardware we ran two multi-agent research workflows, 28 agents total, mining primary sources, GitHub issues and PRs, Reddit, and Hugging Face discussions. Every load-bearing claim was adversarially verified against primary sources. Four-day-old model ecosystems are full of confidently wrong advice, and this step caught some of it (more below).

Then a Friday-night maintenance window, about three hours of endpoint downtime. The production model container was stopped, and Laguna was served from a temporary hot-attached 250 GB scratch volume, in a separate container, on a different port. vLLM v0.25.1 for the trial, required by Laguna's tool-call parsers and the quantized checkpoint. Zero changes to the managed stack. Restoring production was literally docker start vllm.

Community tuning applied: gpu-memory-utilization 0.97, context capped at 128K, PyTorch expandable segments, and Poolside's recommended sampling (temp 0.7, top_p 0.95, top_k 20).

The numbers

All measured, same physical GPU.

Fit. Three configs, all booted cleanly with CUDA graphs on, ~191 s boot each:

Speed, against production Qwen on the identical card:

Why does a 118B model out-run a 27B on the same GPU? Same lesson as the Strix Halo post, from the other direction. Decode is memory-bandwidth-bound. MoE decode only reads the ~8.5B active parameters per token, about 4.5 GB at INT4. The dense 27B reads all ~27 GB every token. Fewer bytes per token, faster decode. Total parameter count is a disk-space number, not a speed number.

One datapoint we have not seen published elsewhere: vLLM's prefix caching works correctly with Laguna's hybrid sliding-window attention. That 0.11 s warm TTFT on a 56K prompt is the proof. This was an open question in the community threads we mined, and for prefix-cache-heavy agentic workloads it is the difference between viable and not.

What didn't work

DFlash shipped broken for this checkpoint. Poolside's own speculative drafter recorded 0.000 draft acceptance, which makes it a pure slowdown: 55 tok/s versus 130 without it. This matches week-1 community reports of drafter/checkpoint mismatches. On Strix Halo, DFlash was unavailable; on the H100 it is available and worse than nothing. The one lever that should help is 0-for-2 across our hardware.

The widely-shared --moe-backend triton advice applies only to the FP8 variant. The INT4 path rejects it. Worth knowing before you copy a config from a thread about a different checkpoint.

War stories

The model was four days old and the ecosystem is raw. Weights were re-uploaded mid-week, drafters shipped broken, and one model-card note was actively misleading. The adversarial source-verification step caught it before it cost us window time.

There was an early panic moment. vLLM's idle-windowed log lines suggested 7 tok/s, and for a few minutes the whole experiment looked like a failure. Actual measurement: 130 tok/s. The log averages throughput over windows that include idle time. Do not trust averaged telemetry; measure.

And a side quest: during setup we discovered the production box had been running for 17 days with no shell access. A first-boot DNS race had silently killed Tailscale enrollment on two consecutive server builds. The endpoint was fine, the monitoring was fine, and nobody had needed to SSH in, so nothing surfaced it. The experiment forced an actual login, which found and fixed it. Sometimes the value of poking production hardware is the poking itself.

Total cost of the experiment: a few euros of GPU time and one Friday-evening maintenance window. Production restored and verified the same night, scratch volume deleted, zero infrastructure drift.

The honest conclusion

No same-card swap. Our workload needs tens of concurrent long-context sessions. After 72 GB of weights, the H100 has ~8 GB left for KV, which buys roughly 2. Speed was never the blocker. Memory is. A model that decodes 50% faster does not help if 254 sessions have nowhere to live.

A real contender on bigger hardware. On 2×H100 with tensor parallelism, or a single H200 or B200, the post-weights KV budget grows to 55-65 GB. At that point Laguna's +7 quality points and +50% single-stream speed make it a serious replacement candidate, not a curiosity.

The next step costs nothing. Speed is now a known quantity on our hardware. Quality on our workload is the open question, and it can be answered with a quality A/B of S 2.1 (there is a free OpenRouter endpoint) against our Qwen on real agent traces. No GPU required.

The vendor's hardware floor was real in the sense that matters for production serving, and beatable in the sense that matters for finding out. One evening, a scratch volume, and a separate container got us first-party numbers for a configuration we could not find published anywhere. That trade is almost always worth it.