Poolside: Laguna S 2.1 (free)

Poolside Laguna S 2.1 è un modello linguistico mixture-of-experts progettato per programmazione basata su agenti e attività di lungo periodo. Ha 118B parametri totali e circa 8B attivi per token, collocandosi tra il più piccolo Laguna XS 2.1 e il più grande Laguna M.1 nella serie del produttore. Il modello elabora testo e produce testo, codice, ragionamento e richieste di chiamata agli strumenti in un'applicazione collegata a strumenti.

La sua architettura combina attenzione globale e a finestra scorrevole in 48 livelli: 12 livelli globali e 36 livelli a finestra scorrevole. La finestra scorrevole di 512 token descrive l'attenzione locale entro quei livelli, mentre il contesto documentato del modello è di 1.048.576 token. Sono misure diverse. Il contesto più ampio supporta compiti che accumulano file sorgente, osservazioni e decisioni lungo molti passaggi. Mantieni insieme l'obiettivo di lavoro e le evidenze significative e riserva spazio al ragionamento successivo e alla risposta finale entro la configurazione applicabile.

Lo scopo centrale del modello è il lavoro software che richiede continuità, verifiche e revisioni. Per un compito su un repository, fornisci il comportamento atteso, i file pertinenti come testo, le informazioni sulle dipendenze e l'output effettivo che mostra il problema. Chiedi un risultato mirato: «Ricostruisci la causa di questa regressione, proponi una modifica che mantenga l'interfaccia documentata e identifica le verifiche che distinguerebbero una correzione da una modifica non pertinente». In un flusso collegato a strumenti, fornisci al modello il risultato di ogni verifica eseguita prima che scelga il passaggio successivo.

Per l'ottimizzazione, fornisci misurazioni e un obiettivo esplicito. Un esempio è: «Usa questo profilo e rapporto di allocazione per identificare un collo di bottiglia. Proponi una modifica, spiega l'effetto atteso e confrontala con la situazione di riferimento dopo aver ripetuto la stessa misurazione». Questo rende una dichiarazione di prestazioni verificabile. La versione di Poolside tratta la verifica e il progresso continuo come comportamenti importanti, ma una spiegazione persuasiva da sola non dimostra che una revisione sia più veloce, corretta o completa. Conserva le osservazioni che sostengono la scelta di mantenere o rifiutare la modifica.

Laguna S 2.1 supporta il ragionamento intercalato prima delle chiamate agli strumenti e tra una chiamata e l'altra. Il produttore consiglia di conservare nella cronologia successiva il contenuto di ragionamento dei messaggi precedenti dell'assistente; eliminare quei blocchi può far cessare il ragionamento nei passaggi seguenti. Mantieni insieme la risposta dell'assistente, le informazioni sulle chiamate agli strumenti e il risultato corrispondente dello strumento. Questo aiuta un compito lungo a proseguire dal suo stato effettivo anziché ricostruire ripetutamente ciò che è già stato tentato.

Le opzioni di ragionamento documentate sono off e max, con max abilitato per impostazione predefinita nella configurazione descritta dal produttore. Il modello determina il proprio budget di ragionamento in quella modalità; la versione non presenta controlli separati di impegno low, medium e high. Per la programmazione basata su agenti, Poolside consiglia di abilitare il ragionamento e conservarlo tra i passaggi. Indica esplicitamente l'artefatto finale e i criteri di completamento e distingui una lunga sequenza di ragionamento dal risultato completato. Il produttore identifica l'eccesso di ragionamento, soprattutto nella matematica competitiva, come un limite sostanziale.

Le definizioni degli strumenti richiedono particolare attenzione. Poolside segnala che S 2.1 può inizialmente affidarsi a un'interfaccia di strumenti familiare anziché seguire con precisione uno schema simile ma diverso. Può anche produrre JSON malformato o con escape errati quando un argomento dello strumento contiene un array annidato. Fornisci le definizioni effettive degli argomenti, convalida le chiamate proposte e restituisci un errore preciso quando la chiamata non corrisponde. Il produttore descrive la correzione tramite feedback nel contesto come un modo per risolvere alcune di queste discrepanze. Mantieni l'osservazione risultante dello strumento disponibile per la decisione successiva.

Il produttore pubblica varianti separate BF16 e quantizzate e un modello draft DFlash opzionale. Sono artefatti e ricette di serving distinti, quindi l'uso di memoria di un checkpoint quantizzato o le prestazioni di decodifica speculativa non vanno dedotti dal nome generale del modello. Per il normale lavoro testuale, prepara codice sorgente, output dei comandi ed estratti di documenti come testo leggibile. La versione segnala l'assenza di capacità visive del modello; uno screenshot richiede un'osservazione testuale o un passaggio esterno di ispezione appropriato prima di poter supportare l'analisi.

Richiedi un risultato finale che identifichi l'artefatto modificato, le decisioni importanti, le verifiche osservate e ogni condizione irrisolta. Per una revisione del codice, collega i risultati al sorgente pertinente e mostra perché ogni problema influisce sul comportamento. Per una correzione, separa la patch proposta da una patch il cui comportamento è stato effettivamente verificato. Conservare il ragionamento e la cronologia degli strumenti aiuta il modello a svolgere il compito, mentre l'artefatto finale e i risultati registrati stabiliscono ciò che è stato realizzato.