Poolside: Laguna XS 2.1 (free)

Poolside Laguna XS 2.1 ist ein Mixture-of-Experts-Sprachmodell für agentengestützte Programmierung und langfristige Aufgaben, positioniert als kleineres Modell zur lokalen Bereitstellung in der Laguna-Reihe. Es besitzt insgesamt 33 Milliarden Parameter, davon 3 Milliarden aktive pro Token. Gegenüber Laguna XS.2 ist es ein aktualisiertes Modell, das dessen Architektur beibehält und zugleich die vom Hersteller berichteten Ergebnisse in Softwareentwicklung und Terminalaufgaben verbessert. Das Modell verarbeitet Text und erzeugt Text, Code, Reasoning und Anfragen für Werkzeugaufrufe.

Sein Aufbau mit 40 Schichten kombiniert 10 Schichten globaler Attention und 30 Sliding-Window-Schichten mit Sigmoid-Gating und einem Sliding Window von 512 Token. Dieses lokale Attention-Fenster ist vom Modellkontext mit 262.144 Token getrennt. Poolside beschreibt auch ein FP8-KV-Cache-Design zur Verringerung des Speicherbedarfs pro Token. Diese Eigenschaften erklären die Ausrichtung auf lokale Bereitstellung; der genaue Speicherbedarf hängt dennoch von Checkpoint, Quantisierung, Arbeitskontext und Bereitstellungskonfiguration ab.

Geben Sie für eine Programmieraufgabe die relevanten Quelldateien als Text, das erwartete Verhalten und den tatsächlichen Fehler oder die fehlschlagende Ausgabe an. Eine nützliche Anfrage lautet: „Korrigieren Sie die Behandlung maskierter Trennzeichen in diesem Parser und bewahren Sie dabei das veröffentlichte Eingabeformat. Zeigen Sie die vorgeschlagene Änderung, erklären Sie die betroffenen Fälle und nennen Sie Beispiele, die eine Regression aufdecken würden.“ Halten Sie ein konkretes Ergebnis und eine Abschlussbedingung fest, damit das Modell auf ein Ergebnis hinarbeiten kann, statt das Problem bloß zu diskutieren.

Stellen Sie für Terminalaufgaben die aktuelle Umgebung, relevante Befehlsausgaben und Einschränkungen der Arbeit bereit. 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. Fordern Sie das Modell auf, 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 durch die Quellen begründete Korrektur und das erwartete Ergebnis der nächsten Prüfung an. Bewahren Sie frühere erfolgreiche Schritte und das ungeklärte Problem im Verlauf.

Laguna XS 2.1 ist für abwechselndes Denken vor und zwischen Werkzeugaufrufen ausgelegt. Der Hersteller empfiehlt, Reasoning-Inhalte aus früheren Assistentennachrichten beim Zusammenstellen der nächsten Anfrage beizubehalten. Werden diese Inhalte weggelassen, kann weiteres Reasoning in Folgeschritten ausbleiben. Halten Sie die Assistentenantwort, ihre Werkzeugaufrufinformationen und das passende Werkzeugergebnis zusammen und lassen Sie 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.

Das Denken lässt sich über die Chatvorlage aktivieren oder deaktivieren. Poolside empfiehlt, es für agentengestützte Programmierung einzuschalten und über Gesprächsrunden hinweg zu bewahren. Eine direkte Antwort kann für eine kleine Umwandlung oder Erklärung passen, während eine Reparatur mit mehreren voneinander abhängigen Bedingungen von einer fortlaufenden Denk- und Beobachtungsschleife profitiert. Geben Sie das endgültige Ausgabeformat an und lassen Sie Platz für die Abschlussantwort. Die Evaluationseinstellungen des Herstellers sind Entscheidungen seiner Anleitung und keine allgemeingültige Garantie für den Reasoning-Umfang oder die maximale Antwortlänge.

Organisieren Sie bei umfangreichen Quelleingaben 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. Halten Sie wichtige Entscheidungen und tatsächliche Prüfungen in einer kompakten Aufgabenaufzeichnung fest und entfernen Sie irrelevanten Verlauf. Das Kontextlimit umfasst Arbeitsmaterial und erzeugte Fortsetzung; eine Abschlussantwort in voller Kontextgröße wird nicht als eigene Kapazität zugesagt.

Poolside veröffentlicht BF16 sowie eigene FP8-, NVFP4-, INT4- und GGUF-Varianten und DFlash-Draft-Modellartefakte. Das sind unterschiedliche Bereitstellungsoptionen. Eine geringe 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. Behalten Sie bei lokalen Ergebnisvergleichen den exakten Checkpoint bei und bereiten Sie Code- oder Dokumentinhalte für dieses Text-zu-Text-Modell als Text auf.

Der Hersteller dokumentiert ein Werkzeugparserproblem in älteren Bereitstellungs-Builds, das bestimmte Aufrufe auslassen und deren rohes Markup als normalen Antworttext ausgeben kann. Das zeigt, warum ein werkzeuggebundener Ablauf zwischen der beabsichtigten Modellanfrage und einem korrekt geparsten Funktionsaufruf unterscheiden muss. Prüfen Sie geparsten Namen und 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 benennen. Ein vorgeschlagener Patch oder Befehl wird erst zum abgeschlossenen Ergebnis, wenn sein Verhalten durch diese Aufzeichnungen belegt ist.