Poolside: Laguna XS 2.1 (free)

Poolside Laguna XS 2.1 est un modèle de langage à mélange d’experts pour la programmation agentique et les tâches de longue haleine, positionné comme le plus petit modèle de déploiement local de la série Laguna. Il compte 33 milliards de paramètres au total et 3 milliards actifs par token. C’est une mise à jour par rapport à Laguna XS.2 : il conserve son architecture tout en améliorant les résultats d’ingénierie logicielle et de tâches en terminal rapporté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 de 40 couches combine 10 couches d’attention globale et 30 couches à fenêtre glissante, avec un mécanisme de portes sigmoïdes 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 une conception de cache KV en FP8 destinée à réduire la mémoire par token. Ces caractéristiques aident à comprendre l’orientation vers le déploiement local, mais le besoin précis en mémoire dépend toujours du checkpoint, de la quantification, du contexte de travail et de la configuration de mise à disposition.

Pour une tâche de programmation, fournissez les fichiers source pertinents sous forme de texte, le comportement attendu et l’erreur réelle ou la sortie en échec. Une demande utile est : « Corrige le traitement des délimiteurs échappés par cet analyseur tout en conservant 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 puisse avancer vers un résultat plutôt que 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 des dépendances et la sortie de l’installation échouée, puis demandez la plus petite correction justifiée par la source et le résultat attendu de la vérification suivante. Conservez dans l’historique les étapes antérieures réussies et le problème non résolu.

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. Le supprimer peut empêcher la poursuite du raisonnement lors des étapes suivantes. Gardez ensemble la réponse de l’assistant, ses informations d’appel d’outil et le résultat correspondant, en laissant visible l’objectif en cours. Cela est particulièrement utile lorsque plusieurs observations contribuent à une correction 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 au moyen du gabarit de conversation. Poolside recommande de l’activer pour la programmation agentique et de la conserver au fil des échanges. Une demande de réponse directe peut convenir à une petite transformation ou à une explication, tandis qu’une réparation soumise à plusieurs conditions dépendantes bénéficie d’une boucle continue de raisonnement et d’observation. Précisez le format de sortie final et réservez de la place pour la réponse finale. Les réglages d’évaluation du fabricant sont des choix de recette, sans garantie universelle sur la quantité de raisonnement ou la longueur maximale de la réponse.

Pour une entrée source longue, organisez les fichiers et la documentation avec des délimitations claires et des noms stables. Demandez de retracer une relation précise : quels appelants dépendent d’une interface modifiée, quelles conditions distinguent deux mises en œuvre ou pourquoi un résultat de test contredit le diagnostic proposé. Gardez les décisions importantes et les vérifications réelles dans un dossier de tâche compact, puis retirez l’historique sans rapport. La limite de contexte couvre le matériel de travail et la suite générée ; une réponse finale occupant tout le contexte n’est pas une capacité promise séparément.

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

Le fabricant documente un problème d’analyse des outils dans d’anciennes versions de mise à disposition, susceptible de perdre certains appels et d’exposer leur balisage brut comme du texte de réponse ordinaire. Cela illustre pourquoi un flux 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 achevé que lorsque ces traces en établissent le comportement.