Poolside har offentliggjort Laguna S 2.1, en 118 milliarder parameters Mixture‑of‑Experts model med åbne vægte på Hugging Face under OpenMDW‑1.1. Modellen understøtter et kontekstvindue på op til 1 million tokens i både thinking og no‑thinking, og Poolside rapporterer 70,2 procent på Terminal‑Bench 2.1 samt 78,5 procent på SWE‑Bench Multilingual. Ifølge de offentliggjorte sammenligninger placerer det Laguna S 2.1 foran betydeligt større systemer på flere langtidshorisont‑opgaver. Spørgsmålet er nu, hvordan man udnytter det uden at købe katten i sækken.
Åbne vægte plus stor kontekst ændrer, hvor hurtigt teams kan teste on‑prem og i hybrid. MoE‑sparsitet kan trykke compute pr. token, mens memory stadig skal rumme alle 118B ved provisioning. Og ja, tallene ser stærke ud—men de er Poolsides egne og bør gentestes uafhængigt, før de bliver styrende for produktion.
Hvad Laguna S 2.1 teknisk set er
Laguna S 2.1 er en MoE‑model, hvor kun en delmængde af eksperter aktiveres pr. token. Poolside oplyser, at cirka 8 milliarder parametre rutes per token, omkring 6,8 procent af de 118B. Pointen er enkel: inferensstien føles “stor”, mens man kun betaler compute for det, der er aktivt i hvert step. Alle 118B ligger dog resident i hukommelsen, så kapacitetskravet ligner en fuld 118B ved opstart og drift.
Routingdetaljer—top‑k, load‑balancing, fallback—er ikke fuldt dokumenteret offentligt. Det gør det svært at forudsige latency‑spikes, kvalitetsvariance og reproducerbarhed på tværs af workloads. Notér det som et valideringskrav, ikke en bagatel.
Kontekstvindue og thinking modes
Modellen understøtter op til 1.000.000 tokens i både thinking og no‑thinking. Thinking står som max, hvor modellen selv styrer test‑time compute med kæder af mellemtrin. Poolside oplyser, at max‑thinking løfter Terminal‑Bench 2.1 fra 60,4 til 70,2 procent og DeepSWE fra 16,5 til 40,4 procent. Prisen er tokenforbrug—fx omkring 249.000 completion tokens i DeepSWE thinking mod 99.000 uden.
Det store vindue gør det muligt at lægge hele kodebaser, længere specifikationer eller ugers CI‑logs i ét kald. Long‑horizon agentik bliver praktisk muligt i et sammenhængende flow for plan, implementering og validering. Uafklaret del: konkret latency under max‑thinking i realistiske scenarier og cost‑profilen ved lange sessions—målinger mangler offentligt.
Åbne vægte og licensvalg
Poolside har udgivet vægtene på Hugging Face under OpenMDW‑1.1 samt leveret officielle konverteringer til GGUF og MLX og varianter i BF16, FP8, INT4 og NVFP4 plus DFlash‑udkast. Det giver frihed til lokale tests og optimeringer uden hård vendor‑lockin. Praktisk note: find Laguna S 2.1 på Poolsides Hugging Face‑org og verificér checksums. Den præcise direkte URL og checksum‑liste er ikke oplyst i de anvendte kilder og bør kontrolleres ved download.
Licenser betyder noget i drift. OpenMDW‑1.1 beskrives som permissiv, men få en juridisk gennemgang af vilkår for redistribution, finetuning og kommercielle services, før modellen kobles på forretningskritiske flows.
Benchmarks og hvad de faktisk siger
Poolside rapporterer 70,2 procent på Terminal‑Bench 2.1 og 78,5 procent på SWE‑Bench Multilingual. I deres sammenligninger ligger Laguna S 2.1 foran større modeller som DeepSeek‑V4‑Pro‑Max, Nvidia Nemotron 3 Ultra og Thinking Machines Inkling på flere målinger. På DeepSWE v1.1 oplyses 40,4 procent mod 9,0 for DeepSeek‑V4‑Pro‑Max, trods cirka en sjettedel aktive parametre. For en 118B MoE er det opsigtsvækkende.
Men alle scores stammer fra Poolside og deres eget kompilerede leaderboard. En uafhængig gentest bør køre identiske prompts, seed, tool‑miljø og thinking‑indstillinger samt måle tre ting side om side: kvalitetsscore, tokenforbrug og end‑to‑end tid. Uden det får man kun halvdelen af billedet.
Service og drift i den virkelige verden
Poolside skriver, at modellen kan køre på en enkelt Nvidia DGX Spark. Det antyder et håndterbart footprint i enterprise‑setup, men konkrete HBM‑tal for de forskellige præcisionsformater mangler offentligt. MoE hjælper compute pr. token, ikke resident memory—alle 118B skal i hukommelsen. Det påvirker sizing, failover og multitenancy direkte.
Vægtene fås i BF16, FP8, INT4 og NVFP4, med officielle GGUF og MLX‑konverteringer. Det åbner både højpræcisions‑ og kvantiserede serving‑spor. Latency og throughput vil afhænge af routing, batchning og præcision. Uafhængige målinger af tokens per sekund, svartider og stabilitet under max‑thinking ved mange samtidige sessions savnes stadig.
Træningstempo og FP8 i RL
Poolside angiver, at pre‑training startede 22. maj 2026 på 4.096 H200‑GPUer, med under ni uger fra start til lancering. Derudover er det første Poolside‑model med reinforcement learning i FP8. Hurtig iteration lyder attraktivt, men stabilitet, konvergens og reproducerbarhed i FP8‑RL er ikke fyldestgørende dokumenteret offentligt. Det bør testes, før man kopierer til egne RL‑løb.
Konklusionen her er mindre romantisk og mere praktisk: uden kapitel og vers om hyperparametre og sikringer må man regne med ekstra tid til at gøre RL‑pipelines robuste.
Agentiske evner og sikkerhed
Poolside har udgivet længere trajectories som adfærdseksempler: blandt andet en session, der byggede en enkel HTML‑ og CSS‑browsermotor fra tom mappe og validerede mod headless Chromium over 181 skridt på cirka 50 minutter uden menneskelig indgriben. Et andet eksempel handler om optimering af deres egen agent‑harness, og et tredje om en genafledning af Erdős problem nr. 397 i Perl uden Python i sandboxen. De peger på udholdende, værktøjsdrevet problemløsning—og på behovet for stram kontrol, når agenten får handlemuligheder.
Praktiske implikationer for on‑prem og hybrid
Åbne vægte i flere formater gør lokale tests realistiske. Kvantisering til INT4 eller NVFP4 kan trykke memorykrav og tillade flere instanser pr. node. GGUF‑konvertering gør CPU‑ og edge‑scenarier mulige i lette opgaver, men long‑horizon agentik kræver i praksis GPU. En enkel hybrid‑idé: lokal inference, cloud‑orkestrering, og stram datasuverænitet for kildekode og logs.
Sparsitet ændrer økonomien, fordi cirka 8B rutes pr. token. Det kan sænke omkostningen pr. token mod fuldt‑tætte T‑modeller på visse workloads. Men resident memory er stadig stort, så provisionering og kapacitetsomkostninger forsvinder ikke. Billigere nogle steder, ikke alle.
Sådan validerer du benchmark‑påstande
Lav en reproducérbar benchmarkpakke: fixér container‑image, CUDA‑stack og tool‑adgange. Kør Terminal‑Bench 2.1 og SWE‑Bench Multilingual med Poolsides rapporterede settings—både med og uden max‑thinking. Log alt: seed, prompts, tool‑kald, tokens ind og ud, wall‑clock tid, GPU‑udnyttelse. Sammenlign kvalitetsscores med Poolside‑tallene og rapportér konfidensintervaller frem for enkeltmålinger.
Udvid med en “cost lens”: mål pris pr. bestået opgave ved forskellige præcisioner (BF16 vs. INT4), og notér hvor much thinking, der realt skal til, før kvaliteten flader ud. Uden de tal risikerer man at overbudgettere i blinde.
Hvad man bør måle i en seriøs PoC
Start med fire hårde tal: latency per forespørgsel under no‑thinking og max‑thinking, omkostning pr. 1.000 tokens ved forskellige præcisioner, hallucinationsrate målt mod referencekode, og end‑to‑end throughput i en CI‑simuleret kø. Læg en stabilitetstest oveni, hvor modellen kører i timevis på en større refaktorering med kontinuerlig validering. Her skal 1M‑kontekst bevise sin værdi—ellers er det bare brødtekst med ekstra kalorier.
Integrér i det, der allerede findes: issue trackere, code review‑pipelines, PR‑skabeloner, testgenerering og patch‑validering i sandbox. Brug egne repos, egne test‑suiter og egne kvalitetsscorer. Ellers måler man bare benchmarks med et andet logo.
Governance og risikostyring før produktion
Indfør adgangskontrol og rolleprofiler for agentiske handlinger, før modellen må committe eller åbne issues. Log alt. Kør statisk og dynamisk analyse på alle forslag. Hav en kill‑switch, der stopper agenten, hvis cost‑budget eller sikkerhedspolicy overskrides. Og indfør en review‑politik, hvor mennesker godkender strukturelle ændringer i arkitektur, afhængigheder og secrets.
Supply chain‑risiko gælder også for åbne vægte: verificér checksums, brug et privat artifact‑spejl, fastfrys versioner i drift. OpenMDW‑1.1 ser fleksibel ud, men få en juridisk gennemgang af vilkår for redistribution, finetuning og leverede services, før kontrakter underskrives.
Markedsperspektivet
VentureBeat beskriver Poolsides linje som radikal transparens frem for rå skala. Det skiller sig ud i en tid med store, lukkede flagskibe. Hvis Laguna S 2.1 får traction, vil efterspørgslen stige efter sikre deployment‑pakker, kvantisering og on‑prem hosting. Også specialister i MoE‑serving og test af long‑horizon agentik bliver mere eftertragtede.
De store proprietære spillere kommer til at svare igen med længere kontekst, bedre tool‑integrationer og måske semi‑åbne varianter. Åben‑vægt strategien skubber under alle omstændigheder på kundekrav om indsigt, reproducerbarhed og frihed til at optimere selv.
Huller, der stadig skal lukkes
Uafhængige reproduktioner af benchmark‑resultater mangler. Routing og sparsity‑fordeling er ikke fuldt beskrevet (top‑k, load‑balancing, fallback). Der er ingen komplette latency‑ og throughput‑målinger under max‑thinking i realistiske produktionsscenarier. FP8‑RL‑stabilitet og hyperparametre er sparsomt dokumenteret. Og konkrete memory‑tal for DGX Spark i de forskellige formater er ikke publiceret detaljeret.
Alt dette kan måles—og bør måles—før større udrulninger. Indtil da: planlæg PoC som et måleprojekt, ikke som en hurtig demo.
Konklusion og næste skridt
Laguna S 2.1 er en markant open‑weight udgivelse: 118B MoE, cirka 8B aktive per token, 1M‑token kontekst og stærke long‑horizon benchmarks—alt ifølge producentens egne data. Mulighederne for on‑prem og hybrid er reelle, især til agentiske kodeflows med meget kontekst. Værdien afgøres af målinger i egen virkelighed, ikke tabeller.
Pragmatisk opskrift: hent vægtene fra Poolsides Hugging Face‑org, verificér checksums, kør to PoC‑spor i parallel (ét BF16, ét kvantiseret), mål latency, cost og kvalitet på egne repos over en uge. Test med og uden thinking. Log alt. Få governance på plads, før agenten får rettigheder. Man opdager først forskellen, når man sidder med det.
