Poolside: Laguna XS 2.1 (free)

Poolside Laguna XS 2.1 ist ein Mixture-of-Experts-Sprachmodell für agentengestütztes Coding und langfristige Aufgaben. In der Laguna-Reihe ist es als kleineres Modell für lokale Bereitstellung positioniert. Es hat insgesamt 33B Parameter und 3B aktive Parameter pro Token. Gegenüber Laguna XS.2 ist es ein aktualisiertes Modell, das dessen Architektur beibehält und die vom Hersteller berichteten Ergebnisse für Softwareentwicklung und Terminalaufgaben verbessert. Das Modell akzeptiert Text und erzeugt Text, Code, Reasoning und Werkzeugaufrufanfragen.

Sein 40-schichtiges Design kombiniert 10 Schichten mit globaler Attention und 30 Sliding-Window-Schichten mit Sigmoid-Gating und einem Sliding Window von 512 Tokens. Dieses lokale Attention-Fenster ist vom Kontext des Modells mit 262,144 Tokens getrennt. Poolside beschreibt auch ein FP8-KV-Cache-Design, das den Speicherbedarf pro Token verringert. Diese Merkmale erklären die Ausrichtung auf lokale Bereitstellung; der genaue Speicherbedarf hängt dennoch von Checkpoint, Quantisierung, Arbeitskontext und Bereitstellungskonfiguration ab.

Gib für eine Coding-Aufgabe die relevanten Quelldateien als Text, das erwartete Verhalten und den tatsächlichen Fehler oder die fehlerhafte Ausgabe vor. Eine nützliche Anfrage lautet: «Korrigiere den Umgang dieses Parsers mit maskierten Trennzeichen und bewahre dabei das veröffentlichte Eingabeformat. Zeige die vorgeschlagene Änderung, erkläre, welche Fälle betroffen sind, und benenne Beispiele, die eine Regression sichtbar machen würden.» Halte ein konkretes Ergebnis und eine Abschlussbedingung fest, damit das Modell auf ein Resultat hinarbeiten kann, statt bloss das Problem zu diskutieren.

Gib für Terminalaufgaben die aktuelle Umgebung, relevante Befehlsausgaben und Einschränkungen für die Arbeit vor. In einer Anwendung mit Werkzeuganbindung 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. Verlange eine Erklärung, was ein Fehler erkennen lässt, bevor ein weiterer Befehl vorgeschlagen wird. Liefere zum Beispiel das Abhängigkeitsmanifest und die Ausgabe der fehlgeschlagenen Installation und verlange danach die kleinste aus den Quellen begründete Korrektur und das erwartete Ergebnis der nächsten Prüfung. Bewahre frühere erfolgreiche Schritte und das ungeklärte Problem im Verlauf.

Laguna XS 2.1 ist für eingeschobene Thinking-Phasen vor und zwischen Werkzeugaufrufen ausgelegt. Der Hersteller empfiehlt, beim Zusammenstellen der nächsten Anfrage Reasoning-Inhalte aus früheren Assistentennachrichten zu bewahren. Das Weglassen dieser Inhalte kann weiteres Reasoning in Folgeschritten verhindern. Halte die Assistentenantwort, ihre Werkzeugaufrufinformationen und das zugehörige Werkzeugergebnis zusammen und das fortlaufende Ziel sichtbar. Das ist besonders nützlich, 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 Chatvorlage aktivieren oder deaktivieren. Poolside empfiehlt, es für agentengestütztes Coding zu aktivieren und über Gesprächsrunden hinweg zu bewahren. Eine Anfrage nach einer direkten Antwort kann zu einer kleinen Umwandlung oder Erklärung passen, während eine Reparatur mit mehreren abhängigen Bedingungen von einer fortlaufenden Schleife aus Reasoning und Beobachtung profitiert. Lege das endgültige Ausgabeformat fest und lass Platz für die Abschlussantwort. Die Evaluierungseinstellungen des Herstellers sind Konfigurationsentscheidungen und keine allgemeine Garantie für den Reasoning-Umfang oder die maximale Antwortlänge.

Organisiere bei langen Quelleingaben Dateien und Dokumentation mit klaren Grenzen und stabilen Namen. Verlange die Nachverfolgung eines bestimmten Zusammenhangs, etwa welche Aufrufer von einer geänderten Schnittstelle abhängen, welche Bedingungen zwei Implementierungen unterscheiden oder warum ein Testergebnis der vorgeschlagenen Diagnose widerspricht. Halte wichtige Entscheidungen und tatsächliche Prüfungen in einem knappen Aufgabenprotokoll fest und entferne irrelevanten Verlauf. Die Kontextgrenze umfasst das Arbeitsmaterial und die generierte Fortsetzung; eine endgültige Antwort in voller Kontextgrösse ist keine separat zugesagte Kapazität.

Poolside veröffentlicht BF16 und separate FP8-, NVFP4-, INT4- und GGUF-Varianten sowie DFlash-Draft-Modellartefakte. Das sind unterschiedliche Bereitstellungsoptionen. Eine kleine Anzahl aktiver Parameter bedeutet nicht, dass die vollständigen Modellgewichte nur entsprechend wenig Speicher belegen; ein Draft-Modell ist ein Begleiter zur Beschleunigung und nicht das Coding-Modell selbst. Bewahre beim Vergleich lokaler Ergebnisse den genauen Checkpoint und bereite Code- oder Dokumentinhalte als Text für dieses Text-zu-Text-Modell vor.

Der Hersteller dokumentiert ein Werkzeugparserproblem in älteren Bereitstellungsbuilds, bei dem bestimmte Aufrufe verloren gehen und ihre rohe Auszeichnung als gewöhnlicher Antworttext sichtbar werden kann. Das zeigt, warum ein Ablauf mit Werkzeuganbindung zwischen der beabsichtigten Anfrage des Modells und einem korrekt geparsten Funktionsaufruf unterscheiden muss. Prüfe den geparsten Namen und die Argumente, validiere sie anhand des tatsächlichen Schemas und bewahre das Ausführungsergebnis. Ein Abschlussbericht sollte das überarbeitete Ergebnis, die beobachteten Prüfungen und verbleibende Annahmen nennen. Ein vorgeschlagener Patch oder Befehl wird erst zum abgeschlossenen Ergebnis, wenn sein Verhalten durch diese Aufzeichnungen belegt ist.