Poolside: Laguna S 2.1 (free)

Poolside Laguna S 2.1 est un modèle linguistique à mélange d’experts conçu pour la programmation agentique et le travail de longue durée. Il compte 118 milliards de paramètres au total et environ 8 milliards actifs par jeton, ce qui le situe entre Laguna XS 2.1, plus petit, et Laguna M.1, plus grand, dans la série du fabricant. Le modèle traite du texte et produit du texte, du code, du raisonnement et des demandes d’appels d’outils dans une application connectée à des outils.

Son architecture combine l’attention globale et l’attention à fenêtre glissante dans 48 couches : 12 couches globales et 36 couches à fenêtre glissante. La fenêtre glissante de 512 jetons décrit l’attention locale dans ces couches, tandis que le contexte documenté du modèle est de 1 048 576 jetons. Ce sont des mesures différentes. Le contexte plus grand soutient les tâches qui accumulent des fichiers source, des observations et des décisions sur de nombreuses étapes. Gardez ensemble l’objectif de travail et les éléments probants significatifs, et réservez de l’espace pour le raisonnement ultérieur et la réponse finale dans la configuration applicable.

La vocation centrale du modèle est le travail logiciel qui exige de la persévérance, des vérifications et des révisions. Pour une tâche sur un dépôt, fournissez le comportement attendu, les fichiers pertinents sous forme de texte, l’information sur les dépendances et la sortie réelle en échec. Demandez un résultat ciblé : « Retracez la cause de cette régression, proposez une modification qui préserve l’interface documentée et identifiez les vérifications qui permettraient de distinguer un correctif d’une modification sans rapport. » Dans un flux connecté à des outils, donnez au modèle le résultat de chaque vérification exécutée avant qu’il choisisse l’étape suivante.

Pour le travail d’optimisation, fournissez des mesures et un objectif explicite. Par exemple : « Utilisez ce profil et ce rapport d’allocations pour identifier un goulot d’étranglement. Proposez une modification, expliquez l’effet attendu et comparez-le à la référence après répétition de la même mesure. » Cela rend une affirmation de performance inspectable. La publication de Poolside présente la vérification et la progression continue comme des comportements importants, mais une explication convaincante ne suffit pas à établir qu’une révision est plus rapide, correcte ou complète. Conservez les observations qui justifient de garder ou de rejeter la modification.

Laguna S 2.1 prend en charge la réflexion entrelacée avant et entre les appels d’outils. Le fabricant recommande de conserver le contenu de raisonnement des messages antérieurs de l’assistant dans l’historique suivant; supprimer ces blocs peut interrompre le raisonnement lors des étapes de suivi. Gardez ensemble la réponse de l’assistant, l’information d’appel d’outil et le résultat d’outil correspondant. Cela aide une tâche plus longue à se poursuivre à partir de son état réel au lieu de reconstruire à répétition ce qui a déjà été tenté.

Les choix documentés de réflexion sont off et max, avec max activé par défaut dans la configuration décrite par le fabricant. Dans ce mode, le modèle détermine son budget de réflexion; la publication ne présente pas de commandes d’effort low, medium et high distinctes. Pour la programmation agentique, Poolside recommande d’activer la réflexion et de la conserver entre les étapes. Précisez explicitement le livrable final et les critères d’achèvement, et distinguez une longue séquence de raisonnement du résultat terminé. Le fabricant identifie l’excès de réflexion, surtout en mathématiques de concours, comme une limite substantielle.

Les définitions d’outils demandent une attention particulière. Poolside rapporte que S 2.1 peut d’abord s’appuyer sur une interface d’outil familière plutôt que de suivre attentivement un schéma similaire mais différent. Il peut aussi produire du JSON mal formé ou mal échappé lorsqu’un argument d’outil contient un tableau imbriqué. Fournissez les définitions réelles des arguments, validez les appels proposés et renvoyez une erreur précise lorsque l’appel ne correspond pas. Le fabricant décrit la correction par rétroaction dans le contexte comme un moyen de résoudre certains de ces écarts. Gardez l’observation de l’outil qui en résulte disponible pour la décision suivante.

Le fabricant publie des variantes BF16 et quantifiées distinctes et un modèle auxiliaire DFlash optionnel. Ce sont des livrables et des recettes de service distincts; il ne faut donc pas déduire l’utilisation de mémoire d’un point de contrôle quantifié ou la performance du décodage spéculatif à partir du nom général du modèle. Pour le travail textuel courant, préparez le code source, les sorties de commandes et les extraits de documents comme du texte lisible. La publication note l’absence de capacité de vision du modèle; une capture d’écran nécessite une observation textuelle ou une étape d’inspection externe appropriée avant de pouvoir appuyer l’analyse.

Demandez un livrable final qui identifie le livrable modifié, les décisions importantes, les vérifications observées et toute condition non résolue. Pour une révision de code, reliez les constats à la source pertinente et montrez pourquoi chaque problème affecte le comportement. Pour une réparation, distinguez le correctif proposé d’un correctif dont le comportement a réellement été vérifié. La conservation de l’historique de raisonnement et d’outils aide le modèle à mener la tâche à bien, tandis que le livrable final et les résultats consignés établissent ce qui a été accompli.