Poolside: Laguna S 2.1 (free)

Poolside Laguna S 2.1 es un modelo de lenguaje de mezcla de expertos diseñado para programación con agentes y trabajo a largo plazo. Tiene 118B de parámetros totales y unos 8B activos por token, lo que lo sitúa entre el más pequeño Laguna XS 2.1 y el mayor Laguna M.1 de la serie del fabricante. El modelo procesa texto y produce texto, código, razonamiento y solicitudes de llamadas a herramientas en una aplicación conectada con herramientas.

Su arquitectura combina atención global y de ventana deslizante en 48 capas: 12 capas globales y 36 de ventana deslizante. La ventana deslizante de 512 tokens describe la atención local dentro de esas capas, mientras que el contexto documentado del modelo es de 1,048,576 tokens. Son medidas distintas. El contexto más amplio admite tareas que acumulan archivos fuente, observaciones y decisiones a lo largo de muchos pasos. Mantén juntos el objetivo de trabajo y las pruebas significativas y reserva espacio para el razonamiento posterior y la respuesta final dentro de la configuración aplicable.

El propósito central del modelo es el trabajo de software que requiere persistencia, comprobación y revisión. Para una tarea de repositorio, proporciona el comportamiento esperado, los archivos pertinentes como texto, información de dependencias y la salida real del fallo. Pide un resultado acotado: «Rastrea la causa de esta regresión, propone un cambio que conserve la interfaz documentada e identifica las comprobaciones que distinguirían una corrección de un cambio sin relación». En un flujo conectado con herramientas, proporciona al modelo el resultado de cada comprobación ejecutada antes de que elija el siguiente paso.

Para trabajo de optimización, proporciona mediciones y un objetivo explícito. Un ejemplo es: «Utiliza este perfil y este informe de asignaciones para identificar un cuello de botella. Propón un cambio, explica el efecto esperado y compáralo con la referencia inicial después de repetir la misma medición». Esto permite inspeccionar una afirmación de rendimiento. La publicación de Poolside presenta la verificación y el progreso continuo como comportamientos importantes, pero una explicación persuasiva por sí sola no demuestra que una revisión sea más rápida, correcta o completa. Conserva las observaciones que respaldan mantener o rechazar el cambio.

Laguna S 2.1 admite razonamiento intercalado antes de las llamadas a herramientas y entre ellas. El fabricante recomienda conservar el contenido de razonamiento de mensajes anteriores del asistente en el historial posterior; eliminar esos bloques puede hacer que el razonamiento se detenga en los siguientes pasos. Conserva juntos la respuesta del asistente, la información de llamadas a herramientas y el resultado correspondiente de la herramienta. Esto ayuda a que una tarea más larga continúe desde su estado real en lugar de reconstruir repetidamente lo que ya se intentó.

Las opciones de razonamiento documentadas son off y max, con max activado de forma predeterminada en la configuración descrita por el fabricante. El modelo determina su presupuesto de razonamiento en ese modo; la publicación no presenta controles de esfuerzo separados low, medium y high. Para programación con agentes, Poolside recomienda activar el razonamiento y conservarlo entre pasos. Indica explícitamente el resultado final y los criterios de finalización y distingue una secuencia larga de razonamiento del resultado completado. El fabricante identifica el exceso de razonamiento, especialmente en matemáticas de competición, como una limitación sustancial.

Las definiciones de herramientas requieren especial cuidado. Poolside señala que S 2.1 puede apoyarse inicialmente en una interfaz de herramientas conocida en lugar de seguir con precisión un esquema similar pero distinto. También puede producir JSON mal formado o con escapes incorrectos cuando un argumento de herramienta contiene un array anidado. Proporciona las definiciones reales de argumentos, valida las llamadas propuestas y devuelve un error preciso cuando la llamada no coincida. El fabricante describe la corrección mediante retroalimentación dentro del contexto como una forma de resolver algunas de estas discrepancias. Mantén disponible la observación resultante de la herramienta para la siguiente decisión.

El fabricante publica variantes BF16 y cuantizadas por separado y un modelo borrador DFlash opcional. Son artefactos y recetas de servicio distintos, por lo que el uso de memoria de un checkpoint cuantizado o su rendimiento con decodificación especulativa no se deben suponer a partir del nombre general del modelo. Para trabajo ordinario con texto, prepara el código fuente, la salida de comandos y los fragmentos de documentos como texto legible. La publicación señala que el modelo carece de capacidad de visión; una captura de pantalla necesita una observación textual o un paso adecuado de inspección externa antes de respaldar el análisis.

Solicita una entrega final que identifique el producto modificado, las decisiones importantes, las comprobaciones observadas y cualquier condición sin resolver. Para una revisión de código, conecta los hallazgos con las fuentes pertinentes y muestra por qué cada problema afecta al comportamiento. Para una reparación, separa el parche propuesto de un parche cuyo comportamiento se haya comprobado realmente. Conservar el razonamiento y el historial de herramientas ayuda al modelo a desarrollar la tarea, mientras que el resultado final y los resultados registrados establecen lo que se ha logrado.