Poolside: Laguna S 2.1 (free)

Poolside Laguna S 2.1 ist ein Mixture-of-Experts-Sprachmodell für agentengestützte Programmierung und langfristige Aufgaben. Es besitzt insgesamt 118 Milliarden Parameter und etwa 8 Milliarden aktive pro Token und liegt damit in der Herstellerreihe zwischen dem kleineren Laguna XS 2.1 und dem größeren Laguna M.1. Das Modell verarbeitet Text und erzeugt in einer Anwendung mit Werkzeuganbindung Text, Code, Reasoning und Anfragen für Werkzeugaufrufe.

Seine Architektur kombiniert globale und Sliding-Window-Attention über 48 Schichten: 12 globale Schichten und 36 Sliding-Window-Schichten. Das Sliding Window von 512 Token beschreibt lokale Attention innerhalb dieser Schichten, während der dokumentierte Modellkontext 1.048.576 Token umfasst. Das sind unterschiedliche Messgrößen. Der größere Kontext unterstützt Aufgaben, die über viele Schritte hinweg Quelldateien, Beobachtungen und Entscheidungen sammeln. Halten Sie das Arbeitsziel und aussagekräftige Belege zusammen und reservieren Sie innerhalb der jeweiligen Konfiguration Platz für weiteres Reasoning und die abschließende Antwort.

Der Hauptzweck des Modells ist Softwarearbeit, die Ausdauer, Prüfung und Überarbeitung erfordert. Stellen Sie für eine Repository-Aufgabe das erwartete Verhalten, relevante Dateien als Text, Abhängigkeitsinformationen und die tatsächliche fehlschlagende Ausgabe bereit. Fordern Sie ein gezieltes Ergebnis an: „Verfolgen Sie die Ursache dieser Regression, schlagen Sie eine Änderung unter Beibehaltung der dokumentierten Schnittstelle vor und nennen Sie Prüfungen, die eine Korrektur von einer sachfremden Änderung unterscheiden würden.“ Geben Sie dem Modell in einem werkzeuggebundenen Ablauf das Ergebnis jeder ausgeführten Prüfung zurück, bevor es den nächsten Schritt wählt.

Stellen Sie für Optimierungsarbeit Messwerte und ein ausdrückliches Ziel bereit. Ein Beispiel lautet: „Verwenden Sie dieses Profil und diesen Speicherallokationsbericht, um einen Engpass zu bestimmen. Schlagen Sie eine Änderung vor, erklären Sie den erwarteten Effekt und vergleichen Sie ihn nach Wiederholung derselben Messung mit dem Ausgangswert.“ Dadurch wird eine Leistungsaussage überprüfbar. Poolsides Veröffentlichung behandelt Verifikation und anhaltenden Fortschritt als wichtige Verhaltensweisen; eine überzeugende Erklärung allein belegt jedoch nicht, dass eine Überarbeitung schneller, korrekt oder vollständig ist. Bewahren Sie die Beobachtungen, die für das Beibehalten oder Verwerfen der Änderung sprechen.

Laguna S 2.1 unterstützt eingeschobenes Denken vor und zwischen Werkzeugaufrufen. Der Hersteller empfiehlt, Reasoning-Inhalte aus früheren Assistentennachrichten im weiteren Verlauf zu bewahren; das Weglassen dieser Blöcke kann Reasoning in Folgeschritten zum Stillstand bringen. Halten Sie Assistentenantwort, Werkzeugaufrufinformationen und das zugehörige Werkzeugergebnis zusammen. So kann eine längere Aufgabe von ihrem tatsächlichen Zustand aus weiterlaufen, statt bereits unternommene Schritte immer wieder rekonstruieren zu müssen.

Die dokumentierten Denkoptionen sind off und max; in der beschriebenen Herstellerumgebung ist max standardmäßig aktiviert. In diesem Modus bestimmt das Modell sein Denkbudget selbst; die Veröffentlichung bietet keine gesonderten Aufwandsstufen low, medium und high. Für agentengestützte Programmierung empfiehlt Poolside, das Denken zu aktivieren und zwischen den Schritten beizubehalten. Benennen Sie fertiges Artefakt und Abschlusskriterien ausdrücklich und unterscheiden Sie eine lange Reasoning-Abfolge vom abgeschlossenen Ergebnis. Der Hersteller nennt übermäßiges Nachdenken, insbesondere bei Wettbewerbsmathematik, als wesentliche Einschränkung.

Werkzeugdefinitionen erfordern besondere Sorgfalt. Poolside berichtet, dass S 2.1 anfangs auf eine vertraute Werkzeugschnittstelle zurückgreifen kann, statt einem ähnlichen, aber abweichenden Schema genau zu folgen. Es kann auch fehlerhaftes oder falsch maskiertes JSON erzeugen, wenn ein Werkzeugargument ein verschachteltes Array enthält. Geben Sie die tatsächlichen Argumentdefinitionen vor, validieren Sie vorgeschlagene Aufrufe und geben Sie bei Abweichungen einen präzisen Fehler zurück. Der Hersteller beschreibt Korrekturen durch Rückmeldungen im Kontext als Möglichkeit, einige dieser Abweichungen zu beheben. Halten Sie die daraus entstehende Werkzeugbeobachtung für die nächste Entscheidung verfügbar.

Der Hersteller veröffentlicht eigene BF16- und quantisierte Varianten sowie ein optionales DFlash-Draft-Modell. Das sind verschiedene Artefakte und Bereitstellungsanleitungen; Speicherbedarf eines quantisierten Checkpoints oder Leistung beim spekulativen Decodieren dürfen daher nicht aus dem allgemeinen Modellnamen abgeleitet werden. Bereiten Sie für gewöhnliche Textarbeit Quellcode, Befehlsausgaben und Dokumentauszüge als lesbaren Text auf. Die Veröffentlichung weist auf die fehlende Bildverarbeitungsfähigkeit des Modells hin; ein Screenshot benötigt eine textliche Beobachtung oder einen passenden externen Prüfschritt, bevor er die Analyse stützen kann.

Fordern Sie ein fertiges Ergebnis an, das das geänderte Artefakt, wichtige Entscheidungen, beobachtete Prüfungen und etwaige ungeklärte Bedingungen benennt. Verknüpfen Sie bei einer Codebegutachtung Befunde mit den relevanten Quellen und zeigen Sie, warum jeder Punkt das Verhalten beeinflusst. Unterscheiden Sie bei einer Reparatur den vorgeschlagenen Patch von einem Patch, dessen Verhalten tatsächlich geprüft wurde. Das Bewahren von Reasoning und Werkzeugverlauf hilft dem Modell bei der Bearbeitung; das fertige Artefakt und die aufgezeichneten Ergebnisse belegen, was erreicht wurde.