Poolside: Laguna XS 2.1 (free)

Poolside Laguna XS 2.1 je jazykový model s architekturou mixture-of-experts pro agentní programování a dlouhodobé úlohy, který je v řadě Laguna zařazen jako menší model pro lokální nasazení. Má celkem 33 miliard parametrů a 3 miliardy aktivních parametrů na token. Jde o aktualizovaný model oproti Laguna XS.2, který zachovává jeho architekturu a zlepšuje výrobcem uváděné výsledky softwarového inženýrství a terminálových úloh. Model přijímá text a generuje text, kód, uvažování a požadavky na volání nástrojů.

Jeho 40vrstvý návrh kombinuje 10 vrstev globální pozornosti a 30 vrstev s posuvným oknem, se sigmoidálním řízením a posuvným oknem 512 tokenů. Toto okno lokální pozornosti je oddělené od kontextu modelu s 262 144 tokeny. Poolside také popisuje návrh KV cache v FP8 ke snížení paměti na token. Tyto vlastnosti pomáhají vysvětlit zaměření modelu na lokální nasazení, přesné paměťové nároky však stále závisejí na checkpointu, kvantizaci, pracovním kontextu a konfiguraci obsluhy.

U programátorské úlohy dodejte příslušné zdrojové soubory jako text, očekávané chování a skutečnou chybu nebo neúspěšný výstup. Užitečný požadavek zní: „Oprav zpracování oddělovačů s escape sekvencemi v tomto parseru při zachování zveřejněného vstupního formátu. Ukaž navrženou změnu, vysvětli dotčené případy a urč příklady, které by odhalily regresi.“ Zachovejte konkrétní výstup a podmínku dokončení, aby model mohl pracovat k výsledku a pouze o problému nediskutoval.

U terminálových úloh poskytněte aktuální prostředí, relevantní výstupy příkazů a omezení práce. V aplikaci propojené s nástroji model navrhuje volání funkce, aplikace je provede a výsledek se vrátí pro další rozhodnutí. Požadujte, aby před návrhem dalšího příkazu vysvětlil, co selhání odhaluje. Dodejte například manifest závislostí a výstup neúspěšné instalace a poté požadujte nejmenší opravu podloženou zdroji a očekávaný výsledek další kontroly. V historii zachovejte dřívější úspěšné kroky a nevyřešený problém.

Laguna XS 2.1 je navržena pro průběžné uvažování před voláními nástrojů a mezi nimi. Výrobce při sestavování dalšího požadavku doporučuje zachovat obsah uvažování z dřívějších zpráv asistenta. Jeho vypuštění může v navazujících krocích zabránit dalšímu uvažování. Odpověď asistenta, informace o jejím volání nástroje a odpovídající výsledek nástroje uchovávejte pohromadě s viditelným průběžným cílem. To je obzvlášť užitečné, když k opravě přispívá několik pozorování a pozdější krok závisí na dřívějším rozhodnutí.

Uvažování lze zapnout nebo vypnout prostřednictvím chatové šablony. Poolside doporučuje zapnout je pro agentní programování a zachovat je mezi tahy. Požadavek na přímou odpověď může vyhovovat malé transformaci nebo vysvětlení, zatímco opravě s několika závislými podmínkami prospívá pokračující smyčka uvažování a pozorování. Uveďte konečný výstupní formát a ponechte prostor pro závěrečnou odpověď. Nastavení hodnocení výrobce jsou volby konkrétního postupu, nikoli univerzální záruka množství uvažování nebo maximální délky odpovědi.

U dlouhého zdrojového vstupu uspořádejte soubory a dokumentaci s jasnými hranicemi a stabilními názvy. Požadujte vysledování konkrétního vztahu, například kteří volající závisejí na změněném rozhraní, které podmínky odlišují dvě implementace nebo proč výsledek testu odporuje navržené diagnóze. Důležitá rozhodnutí a skutečné kontroly zachovejte ve stručném záznamu úlohy a odstraňte nerelevantní historii. Limit kontextu zahrnuje pracovní materiál a generované pokračování; závěrečná odpověď velikosti celého kontextu není samostatně slibovanou kapacitou.

Poolside vydává BF16 a samostatné varianty FP8, NVFP4, INT4 a GGUF i artefakty pomocného návrhového modelu DFlash. Jde o různé možnosti nasazení. Malý počet aktivních parametrů neznamená, že váhy celého modelu zabírají v paměti jen tento objem, a návrhový model je pomocníkem pro zrychlení, nikoli samotným programátorským modelem. Při porovnávání lokálních výsledků zachovejte přesný checkpoint a obsah kódu nebo dokumentů pro tento model text-to-text připravte jako text.

Výrobce dokumentuje problém parseru nástrojů ve starších sestaveních obslužného systému, který může některá volání zahodit a zobrazit jejich syrové značkování jako běžný text odpovědi. To ukazuje, proč postup propojený s nástroji musí odlišovat zamýšlený požadavek modelu od správně parsovaného volání funkce. Zkontrolujte parsovaný název a argumenty, ověřte je proti skutečnému schématu a zachovejte výsledek vykonání. Závěrečná zpráva by měla určit upravený artefakt, pozorované kontroly a zbývající předpoklady. Navržená oprava nebo příkaz se stává dokončeným výsledkem teprve tehdy, když tyto záznamy doloží jeho chování.