Poolside: Laguna XS 2.1 (free)

Poolside Laguna XS 2.1 ist ein Mixture-of-Experts-Sprachmodell für agentische Programmierung und längerfristige Arbeit, das in der Laguna-Serie als kleineres Modell für lokale Bereitstellung positioniert ist. Es besitzt insgesamt 33 Milliarden Parameter und 3 Milliarden aktive Parameter pro Token. Gegenüber Laguna XS.2 ist es ein aktualisiertes Modell, das dessen Architektur beibehält und zugleich die vom Hersteller berichteten Ergebnisse für Softwareentwicklung und Terminalaufgaben verbessert. Das Modell nimmt Text entgegen und erzeugt Text, Code, Reasoning und Anfragen für Werkzeugaufrufe.

Sein Design mit 40 Schichten kombiniert 10 Schichten mit globaler Attention und 30 Sliding-Window-Schichten mit Sigmoid-Gating und einem gleitenden Fenster von 512 Token. Dieses lokale Attention-Fenster ist vom Kontext des Modells mit 262.144 Token getrennt. Poolside beschreibt außerdem ein FP8-KV-Cache-Design, das den Speicherbedarf pro Token reduziert. Diese Merkmale erklären den Schwerpunkt auf lokaler Bereitstellung; der genaue Speicherbedarf hängt jedoch weiterhin vom Checkpoint, der Quantisierung, dem Arbeitskontext und der Bereitstellungskonfiguration ab.

Geben Sie für eine Programmieraufgabe die relevanten Quelldateien als Text, das erwartete Verhalten und den tatsächlichen Fehler oder die fehlerhafte Ausgabe an. Eine hilfreiche Anfrage lautet: „Korrigiere die Behandlung maskierter Trennzeichen in diesem Parser und bewahre dabei das veröffentlichte Eingabeformat. Zeige die vorgeschlagene Änderung, erkläre die betroffenen Fälle und benenne Beispiele, die eine Regression sichtbar machen würden.“ Halten Sie ein konkretes Ergebnis und eine Abschlussbedingung fest, damit das Modell auf ein Ergebnis hinarbeiten kann, statt das Problem lediglich zu besprechen.

Stellen Sie für Terminalaufgaben die aktuelle Umgebung, relevante Befehlsausgaben und Einschränkungen der Arbeit bereit. In einer werkzeugangebundenen Anwendung schlägt das Modell einen Funktionsaufruf vor, die Anwendung führt ihn aus und das Ergebnis wird für die nächste Entscheidung zurückgegeben. Bitten Sie es, vor dem Vorschlag eines weiteren Befehls zu erklären, was ein Fehler erkennen lässt. Stellen Sie beispielsweise das Abhängigkeitsmanifest und die Ausgabe der fehlgeschlagenen Installation bereit und fordern Sie dann die kleinste quellengestützte Korrektur sowie das erwartete Ergebnis der nächsten Prüfung an. Bewahren Sie frühere erfolgreiche Schritte und das ungelöste Problem im Verlauf.

Laguna XS 2.1 ist für verschränktes Thinking vor und zwischen Werkzeugaufrufen ausgelegt. Der Hersteller empfiehlt, beim Rekonstruieren der nächsten Anfrage Reasoning-Inhalte früherer Assistentennachrichten zu bewahren. Werden diese Inhalte entfernt, kann weiteres Reasoning in Folgeschritten ausbleiben. Halten Sie die Assistentenantwort, ihre Werkzeugaufrufinformationen und das zugehörige Werkzeugergebnis zusammen und machen Sie das fortlaufende Ziel sichtbar. Dies ist besonders hilfreich, wenn mehrere Beobachtungen zu einer Korrektur beitragen und ein späterer Schritt von einer früheren Entscheidung abhängt.

Thinking lässt sich über die Chat-Vorlage aktivieren oder deaktivieren. Poolside empfiehlt, es für agentische Programmierung zu aktivieren und über Gesprächsrunden hinweg zu bewahren. Eine Anfrage nach einer direkten Antwort kann für eine kleine Umwandlung oder Erklärung geeignet sein; eine Reparatur mit mehreren voneinander abhängigen Bedingungen profitiert dagegen von einer fortlaufenden Reasoning- und Beobachtungsschleife. Legen Sie das abschließende Ausgabeformat fest und lassen Sie Platz für die endgültige Antwort. Die Evaluierungseinstellungen des Herstellers sind Rezeptentscheidungen und keine universelle Garantie für den Reasoning-Umfang oder die maximale Antwortlänge.

Ordnen Sie bei langem Quellmaterial Dateien und Dokumentation mit klaren Grenzen und stabilen Namen. Fordern Sie die Nachverfolgung einer bestimmten Beziehung an, etwa welche Aufrufer von einer geänderten Schnittstelle abhängen, welche Bedingungen zwei Implementierungen unterscheiden oder warum ein Testergebnis der vorgeschlagenen Diagnose widerspricht. Bewahren Sie wichtige Entscheidungen und tatsächliche Prüfungen in einem kompakten Aufgabenprotokoll und entfernen Sie irrelevanten Verlauf. Die Kontextgrenze umfasst das Arbeitsmaterial und die erzeugte Fortsetzung; eine abschließende Antwort von voller Kontextgröße ist keine separat zugesicherte Kapazität.

Poolside veröffentlicht BF16 sowie separate FP8-, NVFP4-, INT4- und GGUF-Varianten und DFlash-Draft-Modellartefakte. Dies sind unterschiedliche Bereitstellungsoptionen. Eine geringe Zahl aktiver Parameter bedeutet nicht, dass die vollständigen Modellgewichte nur entsprechend wenig Speicher belegen. Ein Draft-Modell ist zudem ein Begleiter zur Beschleunigung und nicht das Coding-Modell selbst. Bewahren Sie beim Vergleichen lokaler Ergebnisse den genauen Checkpoint und bereiten Sie Code- oder Dokumentinhalte für dieses Text-zu-Text-Modell als Text auf.

Der Hersteller dokumentiert ein Problem des Werkzeugparsers in älteren Bereitstellungs-Builds, bei dem bestimmte Aufrufe verloren gehen und ihr rohes Markup als gewöhnlicher Antworttext erscheinen kann. Dies verdeutlicht, warum ein werkzeugverbundener Workflow zwischen der beabsichtigten Modellanfrage und einem korrekt geparsten Funktionsaufruf unterscheiden muss. Prüfen Sie den geparsten Namen und die Argumente, validieren Sie sie anhand des tatsächlichen Schemas und bewahren Sie das Ausführungsergebnis. Ein Abschlussbericht sollte das überarbeitete Artefakt, die beobachteten Prüfungen und die verbleibenden Annahmen nennen. Ein Patch- oder Befehlsvorschlag wird erst dann zu einem abgeschlossenen Ergebnis, wenn sein Verhalten durch diese Aufzeichnungen belegt ist.