Poolside: Laguna S 2.1 (free)

Poolside Laguna S 2.1 ist ein Mixture-of-Experts-Sprachmodell für agentengestütztes Coding und langfristige Aufgaben. Es hat insgesamt 118B Parameter und etwa 8B aktive Parameter pro Token und liegt damit in der Herstellerreihe zwischen dem kleineren Laguna XS 2.1 und dem grösseren Laguna M.1. Das Modell verarbeitet Text und erzeugt in einer Anwendung mit Werkzeuganbindung Text, Code, Reasoning und Werkzeugaufrufanfragen.

Seine Architektur kombiniert globale Attention und Sliding-Window-Attention über 48 Schichten: 12 globale Schichten und 36 Sliding-Window-Schichten. Das Sliding Window von 512 Tokens beschreibt die lokale Attention innerhalb dieser Schichten, während der dokumentierte Modellkontext 1,048,576 Tokens umfasst. Das sind unterschiedliche Messgrössen. Der grössere Kontext unterstützt Aufgaben, bei denen sich Quelldateien, Beobachtungen und Entscheidungen über viele Schritte ansammeln. Halte das Arbeitsziel und aussagekräftige Belege zusammen und reserviere innerhalb der geltenden Konfiguration Platz für weiteres Reasoning und die Abschlussantwort.

Der zentrale Zweck des Modells ist Softwarearbeit, die Ausdauer, Prüfung und Überarbeitung erfordert. Gib für eine Repository-Aufgabe das erwartete Verhalten, relevante Dateien als Text, Abhängigkeitsinformationen und die tatsächliche fehlerhafte Ausgabe vor. Verlange ein gezieltes Ergebnis: «Verfolge die Ursache dieser Regression, schlage eine Änderung vor, die die dokumentierte Schnittstelle bewahrt, und benenne die Prüfungen, die eine Korrektur von einer nicht damit zusammenhängenden Änderung unterscheiden würden.» Gib dem Modell in einem Ablauf mit Werkzeuganbindung das Ergebnis jeder ausgeführten Prüfung zurück, bevor es den nächsten Schritt wählt.

Liefere für Optimierungsarbeit Messungen und ein ausdrückliches Ziel. Ein Beispiel lautet: «Nutze dieses Profil und diesen Allokationsbericht, um einen Engpass zu ermitteln. Schlage eine Änderung vor, erkläre die erwartete Wirkung und vergleiche sie mit der Ausgangsmessung, nachdem dieselbe Messung wiederholt wurde.» So wird eine Leistungsaussage überprüfbar. Poolsides Veröffentlichung behandelt Überprüfung und anhaltenden Fortschritt als wichtige Verhaltensweisen, doch eine überzeugende Erklärung allein belegt nicht, dass eine Überarbeitung schneller, korrekt oder vollständig ist. Bewahre die Beobachtungen, die das Beibehalten oder Verwerfen der Änderung stützen.

Laguna S 2.1 unterstützt eingeschobene Thinking-Phasen vor und zwischen Werkzeugaufrufen. Der Hersteller empfiehlt, Reasoning-Inhalte aus früheren Assistentennachrichten im nachfolgenden Verlauf zu bewahren; das Weglassen dieser Blöcke kann dazu führen, dass Reasoning in Folgeschritten aufhört. Halte die Assistentenantwort, Werkzeugaufrufinformationen und das zugehörige Werkzeugergebnis zusammen. Das hilft einer längeren Aufgabe, vom tatsächlichen Zustand aus fortzufahren, statt wiederholt zu rekonstruieren, was bereits versucht wurde.

Die dokumentierten Thinking-Optionen sind off und max, wobei max in der vom Hersteller beschriebenen Einrichtung standardmässig aktiviert ist. Das Modell bestimmt in diesem Modus sein Thinking-Budget; die Veröffentlichung führt keine separaten Aufwandsstufen low, medium und high auf. Für agentengestütztes Coding empfiehlt Poolside, Thinking zu aktivieren und zwischen den Schritten zu bewahren. Benenne das Endergebnis und die Abschlusskriterien ausdrücklich und unterscheide eine lange Reasoning-Sequenz vom abgeschlossenen Resultat. Der Hersteller nennt übermässiges Nachdenken, besonders bei Wettbewerbsaufgaben in Mathematik, als wesentliche Einschränkung.

Werkzeugdefinitionen erfordern besondere Sorgfalt. Poolside berichtet, dass S 2.1 sich anfangs auf eine vertraute Werkzeugschnittstelle verlassen kann, statt einem ähnlichen, aber anderen Schema genau zu folgen. Es kann auch fehlerhaftes oder falsch maskiertes JSON erzeugen, wenn ein Werkzeugargument ein verschachteltes Array enthält. Gib die tatsächlichen Argumentdefinitionen vor, validiere vorgeschlagene Aufrufe und liefere einen präzisen Fehler zurück, wenn der Aufruf nicht passt. Der Hersteller beschreibt Korrektur durch Rückmeldung im Kontext als eine Möglichkeit, einige dieser Abweichungen zu beheben. Halte die resultierende Werkzeugbeobachtung für die nächste Entscheidung verfügbar.

Der Hersteller veröffentlicht separate BF16- und quantisierte Varianten sowie ein optionales DFlash-Draft-Modell. Das sind unterschiedliche Artefakte und Bereitstellungskonfigurationen; Speicherbedarf eines quantisierten Checkpoints oder Leistung beim spekulativen Decoding sollten daher nicht aus dem allgemeinen Modellnamen abgeleitet werden. Bereite für gewöhnliche Textarbeit Quellcode, Befehlsausgaben und Dokumentauszüge als lesbaren Text vor. Die Veröffentlichung weist auf die fehlende Bildfähigkeit des Modells hin; ein Screenshot braucht eine textuelle Beobachtung oder einen geeigneten externen Prüfschritt, bevor er die Analyse stützen kann.

Verlange ein Endergebnis, das das geänderte Artefakt, wichtige Entscheidungen, beobachtete Prüfungen und jede ungeklärte Bedingung nennt. Verbinde bei einer Codeprüfung Erkenntnisse mit dem relevanten Quellcode und zeige, warum jedes Problem das Verhalten beeinflusst. Trenne bei einer Reparatur den vorgeschlagenen Patch von einem Patch, dessen Verhalten tatsächlich geprüft wurde. Das Bewahren des Reasoning- und Werkzeugverlaufs hilft dem Modell, die Aufgabe durchzuarbeiten; das Endergebnis und die aufgezeichneten Resultate belegen, was erreicht wurde.