Poolside: Laguna XS 2.1 (free)

Poolside Laguna XS 2.1 est un modèle linguistique à mélange d’experts destiné à la programmation agentique et au travail sur la durée, positionné comme le plus petit modèle à déployer localement dans la série Laguna. Il compte 33 milliards de paramètres au total, dont 3 milliards actifs par token. Il s’agit d’un modèle mis à jour par rapport à Laguna XS.2, qui conserve son architecture tout en améliorant les résultats d’ingénierie logicielle et de tâches dans le terminal annoncés par le fabricant. Le modèle accepte du texte et génère du texte, du code, du raisonnement et des demandes d’appels d’outils.

Sa conception à 40 couches combine 10 couches d’attention globale et 30 couches à fenêtre glissante, avec un mécanisme de sélection sigmoïde et une fenêtre glissante de 512 tokens. Cette fenêtre d’attention locale est distincte du contexte de 262 144 tokens du modèle. Poolside décrit aussi un cache KV en FP8 pour réduire la mémoire par token. Ces caractéristiques expliquent l’accent mis sur le déploiement local, mais le besoin précis en mémoire dépend toujours du point de contrôle, de la quantification, du contexte de travail et de la configuration de service.

Pour une tâche de programmation, fournissez les fichiers sources pertinents sous forme de texte, le comportement attendu et l’erreur réelle ou la sortie en échec. Une demande utile serait : « Corrige le traitement des délimiteurs échappés dans cet analyseur tout en préservant le format d’entrée publié. Montre la modification proposée, explique quels cas sont concernés et identifie des exemples qui révéleraient une régression. » Gardez un livrable concret et une condition d’achèvement pour que le modèle vise un résultat plutôt que de simplement discuter du problème.

Pour les tâches de type terminal, fournissez l’environnement actuel, les sorties de commandes pertinentes et les contraintes du travail. Dans une application connectée à des outils, le modèle propose un appel de fonction, l’application l’exécute et le résultat est renvoyé pour la décision suivante. Demandez-lui d’expliquer ce que révèle un échec avant de proposer une autre commande. Fournissez par exemple le manifeste de dépendances et la sortie de l’installation échouée, puis demandez la plus petite correction étayée par les sources et le résultat attendu de la prochaine vérification. Conservez les étapes antérieures réussies et le problème non résolu dans l’historique.

Laguna XS 2.1 est conçu pour une réflexion intercalée avant et entre les appels d’outils. Le fabricant recommande de conserver le contenu de raisonnement des messages précédents de l’assistant lors de la reconstruction de la requête suivante. Supprimer ce contenu peut empêcher la poursuite du raisonnement dans les étapes ultérieures. Gardez ensemble la réponse de l’assistant, ses informations d’appel d’outil et le résultat correspondant, avec l’objectif en cours bien visible. Cela est particulièrement utile lorsque plusieurs observations contribuent à un correctif et qu’une étape ultérieure dépend d’une décision antérieure.

La réflexion peut être activée ou désactivée via le gabarit de conversation. Poolside recommande de l’activer pour la programmation agentique et de la préserver d’un tour à l’autre. Une demande de réponse directe peut convenir à une petite transformation ou explication, tandis qu’une réparation comportant plusieurs conditions dépendantes bénéficie d’une boucle continue de raisonnement et d’observation. Précisez le format de sortie final et laissez de la place pour la réponse finale. Les paramètres d’évaluation du fabricant sont des choix de recette, et non une garantie universelle sur la quantité de raisonnement ou la longueur maximale de la réponse.

Pour une longue entrée source, organisez les fichiers et la documentation avec des limites claires et des noms stables. Demandez de retracer une relation précise, par exemple quels appelants dépendent d’une interface modifiée, quelles conditions distinguent deux implémentations ou pourquoi le résultat d’un test contredit le diagnostic proposé. Conservez les décisions importantes et les vérifications réelles dans un relevé compact de la tâche, et retirez l’historique sans rapport. La limite de contexte couvre les contenus de travail et la continuation générée ; une réponse finale de la taille de tout le contexte ne constitue pas une capacité distincte promise.

Poolside publie des versions BF16 et des variantes séparées FP8, NVFP4, INT4 et GGUF, ainsi que des artefacts de modèle d’ébauche DFlash. Ce sont différents choix de déploiement. Un faible nombre de paramètres actifs ne signifie pas que les poids complets du modèle n’occupent que cette quantité de mémoire, et un modèle d’ébauche sert de compagnon d’accélération plutôt que de modèle de programmation lui-même. Conservez le point de contrôle exact lors de la comparaison des résultats locaux et préparez le code ou les documents sous forme de texte pour ce modèle texte vers texte.

Le fabricant documente, dans d’anciennes versions de service, un problème d’analyse des outils qui peut omettre certains appels et exposer leur balisage brut comme du texte ordinaire de réponse. Cela illustre pourquoi un workflow connecté à des outils doit distinguer la requête voulue par le modèle d’un appel de fonction correctement analysé. Examinez le nom et les arguments analysés, validez-les par rapport au schéma réel et conservez le résultat d’exécution. Un rapport final doit identifier le livrable révisé, les vérifications observées et les hypothèses restantes. Un correctif ou une commande proposés ne deviennent un résultat accompli que lorsque ces relevés établissent leur comportement.