Presentación de Laguna S 2.1

 (poolside.ai)
1 puntos por GN⁺ 5 시간 전 | 1 comentarios | Compartir por WhatsApp
  • Poolside presentó Laguna S 2.1, reforzando la capacidad para trabajos de larga duración y razonamiento. Activa 8B de parámetros por token dentro de un total de 118B MoE, y soporta hasta 1M de tokens de contexto tanto en modo thinking como no-thinking
  • Desde el inicio del entrenamiento hasta el lanzamiento pasaron menos de 9 semanas; registró 70.2% en Terminal-Bench 2.1, 78.5% en SWE-Bench Multilingual y 40.4% en DeepSWE v1.1, compitiendo con modelos más grandes
  • El eje de la mejora de rendimiento no está tanto en escalar el modelo, sino en la persistencia, verificación y reintento tras retroceder. Busca reducir las declaraciones prematuras de finalización y el sobreajuste a un solo harness con rollouts más largos, un sandbox mejorado y varios harnesses de agentes
  • En tareas reales, construyó un motor de renderizado HTML/CSS en 181 pasos, aumentó en 5.2% la velocidad de su propio harness mientras reducía la asignación de memoria en cerca de 70%, y redescubrió de forma independiente una familia infinita de soluciones para el problema #397 de Erdős
  • Publicó las trayectorias completas de ejecución del modelo y de la evaluación final, aunque hay restricciones en las especificaciones de herramientas de harnesses de terceros, el JSON de llamadas anidadas de herramientas y razonamientos excesivamente largos. Los pesos y hasta 1M de contexto están disponibles en Hugging Face y en los principales frameworks y servicios de hosting de inferencia

Arquitectura del modelo y velocidad de lanzamiento

  • Laguna S 2.1 es un modelo Mixture-of-Experts con 118B de parámetros totales y 8B de parámetros activos por token
    • Soporta hasta 1M de tokens de contexto tanto en modo thinking como no-thinking
    • Tomó menos de 9 semanas desde el inicio del entrenamiento hasta el lanzamiento
  • El 22 de mayo de 2026 comenzó el preentrenamiento en 4,096 GPU NVIDIA H200 y se publicó 60 días después
  • Gracias a su pequeño tamaño activo, puede ejecutar tareas complejas en sistemas locales, e incluso correr en una sola NVIDIA DGX Spark

Rendimiento en benchmarks de codificación de larga duración

  • Los principales resultados al 21 de julio de 2026 son los siguientes
    • Terminal-Bench 2.1: 70.2%
    • SWE-Bench Multilingual: 78.5%
    • Dataset público de SWE-Bench Pro: 59.4%
    • DeepSWE v1.1: 40.4%
    • SWE Atlas (Codebase QnA): 46.2%
    • Toolathlon Verified: 49.7%
  • Terminal-Bench 2.1 evalúa varias tareas largas en las que el agente interactúa con el entorno vía terminal, y Laguna S 2.1 obtuvo 70.2% en el harness pool con thinking activado
  • En benchmarks maduros, los puntajes más altos suelen concentrarse entre 70% y 90%, por lo que modelos con conductas muy distintas pueden diferir solo por unos pocos puntos
  • DeepSWE dificulta las soluciones parciales e incluye tareas más largas, por lo que la dispersión de puntajes es mayor
    • En v1.1, los modelos de frontera registran entre 54% y 73%, mientras que algunos modelos abiertos de más de 1T quedan por debajo de 10%
    • Laguna S 2.1 registró 40.4% en su propio harness pool
    • Como usó su propio harness en lugar del mini-swe-agent de la tabla oficial, no es una comparación completamente equivalente con los puntajes de otros modelos
    • Para los demás modelos se usó el puntaje máximo entre sus anuncios propios, la tabla del benchmark y Artificial Analysis
  • Todas las trayectorias de ejecución de la evaluación final están publicadas en trajectories.poolside.ai

Método de evaluación y control del reward hacking

  • En la evaluación de agentes existe el problema de reward hacking, donde se obtienen puntos buscando en línea la respuesta o correcciones ya existentes
  • El acceso a internet está permitido por defecto, y se usa un juez LLM calibrado con trayectorias etiquetadas por humanos (LLMaaJ) para marcar casos sospechosos
    • En el post-entrenamiento inicial, la tasa de reward hacking era menor a 2%
    • A medida que avanzó el entrenamiento, las trayectorias marcadas en la familia SWE-bench superaron 50%
    • La investigación manual mostró que en muchos casos el modelo encontraba el PR o repositorio base del problema y aplicaba la corrección real existente
  • Tras añadir al prompt del usuario una indicación de no usar respuestas directas encontradas en línea, la tasa de reward hacking bajó en general a menos de 2%
    • No es una solución completa, y hubo excepciones en ProgramBench y MirrorCode
  • La verificación adicional incluyó investigación manual de éxitos marcados por LLMaaJ, análisis abierto de agentes sobre trayectorias completas y revisión experta de todas las ejecuciones de alto puntaje en Terminal-Bench 2.1
  • Recientemente reforzaron la detección de reward hacking con revisión adversarial, y las trayectorias de evaluación final del checkpoint público pueden consultarse y descargarse

Casos de trabajo reales

  • Construcción de un motor de navegador desde una carpeta vacía

    • Laguna S 2.1 construyó un motor de renderizado HTML/CSS desde una carpeta vacía sin intervención humana, ejecutando 181 pasos durante 50 minutos
    • Sin capacidades visuales, leyó el canvas con Chromium headless y comparó numéricamente capturas de pantalla para verificar el resultado
    • Implementó todo el pipeline en Vanilla JavaScript
      • Tokenizador HTML y árbol DOM
      • Parser CSS con manejo de prioridad de selectores
      • Motor de cascada con soporte de herencia
      • Layout del modelo de cajas y renderizador Canvas 2D
    • Se completó como una app que muestra lado a lado 9 ejemplos del mismo marcado en su propio canvas y en un iframe del navegador
    • Publicó la trayectoria completa de ejecución

  • Optimización de su propio harness de agente

    • En un loop automatizado de investigación instrumentado con benchmarks, midió el rendimiento tras cada cambio y restringió la retención solo a cambios con mejora confirmada
    • A lo largo de varias horas, aceleró el harness en 5.2% y redujo la asignación de memoria en alrededor de 70%
    • Las optimizaciones principales fueron las siguientes
      • Reemplazó con buffers la concatenación de strings O(n²) usada para acumular tokens en streaming
      • Eliminó copias redundantes en la materialización de trayectorias mediante memoización
      • Preasignó slices con el tamaño exacto para reducir sobreasignación
    • Cuando la diferencia de velocidad se volvió difícil de medir, cambió el foco a optimizar asignación de memoria, que podía medirse con mayor precisión
    • El benchmark usado no era una prueba de producción completa, pero validó el resultado final con compuertas de Go race detector y go vet, y verificó el funcionamiento del artefacto
    • Proporcionó la trayectoria completa de ejecución

  • Redescubrimiento del problema #397 de Erdős

    • Encontró de forma independiente una construcción que genera una familia infinita de soluciones para el problema #397 de Erdős, propuesto en 1975 por Erdős, Graham, Ruzsa y Straus
    • El problema estuvo sin resolver por más de 50 años hasta que GPT-5.2 Pro lo resolvió primero en enero de 2026, así que no es la primera solución sino un redescubrimiento
    • La fecha límite de conocimiento del modelo es noviembre de 2025 y, al no haber Python en el sandbox, encontró Perl y trabajó durante 68 minutos
    • El proceso de resolución fue el siguiente
      • Hizo búsqueda exhaustiva de factorización prima exacta
      • Analizó patrones y conjeturó una familia de soluciones
      • Probó una familia infinita cerrada formada por 8 índices
    • La expresión encontrada es la siguiente para todo n ≥ 0
    B(11+10n) · B(14+12n) · B(18+15n) · B(22+20n)
= B(12+10n) · B(13+12n) · B(17+15n) · B(23+20n)

Modos de razonamiento y diferencias de rendimiento

  • Hay dos modos de razonamiento: off y max, que es el valor por defecto
    • En max, el modelo decide el presupuesto de razonamiento y cómputo en tiempo de prueba según cada problema
    • Se observaron casos donde sostuvo razonamiento consistente durante horas y cientos de miles de tokens
  • Usar max thinking eleva mucho el rendimiento
    • Terminal-Bench 2.1: 60.4% → 70.2%
    • DeepSWE: 16.5% → 40.4%
  • En el lanzamiento no ofrece control personalizado de intensidad de razonamiento tipo low, medium o high
  • En pool, el uso de thinking puede alternarse por sesión con el comando /thought-level

Limitaciones conocidas

  • Debido al sobreajuste del harness, al llamar por primera vez herramientas parecidas a su propio harness pero con especificaciones distintas en detalles, como la herramienta de terminal de Hermes Agent, puede apoyarse en recuerdos de la interfaz previa
    • Si el harness rechaza la llamada incorrecta y pide reintento, normalmente lo corrige mediante aprendizaje en contexto
  • Usa un formato de llamadas a herramientas basado en etiquetas parecido a XML, y cuando los argumentos requieren arreglos JSON puede escapar mal o generar JSON inválido
  • En particular, puede razonar durante demasiado tiempo sin avanzar, especialmente en problemas de matemáticas competitivas
    • Planean introducir control de intensidad de razonamiento y mejoras de eficiencia en modelos posteriores

Cambios de entrenamiento que mejoraron el rendimiento

  • Mejoras en la forma de trabajar más que en el tamaño del modelo

    • El objetivo no es solo añadir más inteligencia, sino reforzar conductas de verificar más, no dar cosas por sentadas y no declarar éxito demasiado pronto
    • Modelos Laguna anteriores a veces declaraban finalización cuando pasaban algunas pruebas o abandonaban un enfoque justo antes del éxito, pero S 2.1 sigue trabajando
    • Consideran que, además de la inteligencia bruta, la persistencia, la verificación y la disposición a retroceder son ejes clave del rendimiento, y están invirtiendo en ambos frentes
    • El siguiente gran modelo Laguna ya comenzó el preentrenamiento

  • Preentrenamiento y post-entrenamiento

    • Es un modelo ampliado que usa los mismos datos de preentrenamiento que Laguna XS 2.1
    • La diferencia respecto a XS 2.1 está en la escala, ajustes del código de entrenamiento y pequeños cambios en la receta de entrenamiento, no en nuevos datos
    • Por primera vez ejecutó RL en precisión FP8, acelerando esa etapa de entrenamiento
    • El post-entrenamiento se realizó en dos etapas
      • Ajuste fino supervisado (SFT), usando en parte datos sintéticos, para inicializar capacidades
      • Aplicación de RL a tareas que aún no podían resolverse con alta tasa de acierto
    • Como las sesiones largas de agente acumulan cientos de miles de tokens de contexto de trabajo, la ampliación a 1M de contexto mejora el rendimiento en tareas antes difíciles

  • Composición de tareas de post-entrenamiento

    • El corpus de entrenamiento se compone de 409,000 entornos de agente y no agente
      • 83,000 entornos de uso de terminal
      • 168,000 tareas generales de ingeniería de software
    • Obtuvieron tareas de repositorios open source, datos sintéticos internos, un sistema automático de instalación de dependencias y adquisiciones de proveedores externos de datos
    • Las tareas de ingeniería de software se basan principalmente en historiales reales de código
      • La parte más grande corresponde a unas 38,000 tareas que reproducen commits reales de alrededor de 17,000 repositorios
      • También incluye reproducción de PRs fusionados, corrección de bugs inyectados y tareas de restauración de archivos eliminados a partir del test suite
    • En S 2.1 se añadió la tarea de instalación de repositorios de agente, que instala todas las dependencias de un repositorio y ejecuta el test suite
    • Las tareas de terminal usan datasets que generan entornos y desafíos no vistos en las semillas

  • Mejoras en el loop de entrenamiento

    • Aplicó un presupuesto de rollout mayor que en modelos previos, aumentando límite de tiempo, tokens por turno y número de turnos por tarea
    • Migró RL a un nuevo servicio de sandbox para aprovechar estas funciones
      • Soporte para procesos en segundo plano
      • Bloqueo opcional de red para reducir la superficie de reward hacking
      • Caché de artefactos para evitar sobrecarga de servicios externos
    • Ejecuta el mismo prompt en varios harnesses de agentes para aprender conductas que funcionen en distintos harnesses, no solo en un scaffold único

Las dos direcciones en las que se enfoca Poolside

  • La primera es la capacidad de coding con agentes
    • Considera el coding y la interfaz flexible con software como una ruta hacia la inteligencia
    • Se enfoca en casos donde el modelo usa software como agente y trabaja de forma consistente durante horas o días
  • La segunda es el enfoque de que el proceso de pensamiento que llevó a una respuesta registrada en la web puede reconstruirse con aprendizaje por refuerzo
    • Este lanzamiento corresponde al resultado de la primera dirección, mientras la segunda sigue en desarrollo

Model Factory y ciclo de desarrollo

  • Con la plataforma interna de investigación e ingeniería Model Factory, automatiza el proceso de desarrollo del modelo, incluyendo datos, experimentos de ablación de arquitectura e infraestructura de evaluación
  • En menos de 3 meses tras lanzar Laguna M.1, desarrolló un modelo más fuerte con la mitad del tamaño de ejecución
  • Está invirtiendo en acelerar la iteración e integración de investigación y en reducir la atención que el personal investigador dedica a tareas administrativas e infraestructura
  • Planea aplicar el mismo método de desarrollo a modelos más grandes durante el próximo año

Despliegue y formas de uso

  • Está publicado en Hugging Face bajo la licencia OpenMDW-1.1
    • Ofrece pesos BF16, FP8, INT4 y NVFP4
    • Ofrece conversiones oficiales GGUF y MLX, y modelos borrador DFlash
  • En hardware NVIDIA soporta serving con TRT-LLM, NVFP4 en Blackwell y optimización de inferencia hasta una sola DGX Spark
  • El serving local y público está soportado en vLLM, SGLang y Ollama
  • Las rutas de acceso hospedadas son las siguientes
  • El endpoint gratuito de OpenRouter ofrece 256K de contexto
    • Los endpoints pagos dedicados soportan 1M de contexto
    • El precio es de $0.10 por millón de tokens de entrada, $0.20 de salida y $0.01 por lectura de caché
  • También puede usarse en Kilo, Hermes Agent, pi, OpenCode, OpenClaw, Cline y el agente de coding por terminal pool
  • El post-entrenamiento soporta NVIDIA NeMo AutoModel y Prime Intellect Prime Lab, y ZML LLMD soporta ejecución en varios hardwares
  • Los usuarios no desarrolladores pueden usar chat.poolside.ai sin iniciar sesión, con búsqueda web y ejecución básica de código
  • Los pesos del modelo base previos al post-entrenamiento están disponibles por solicitud vía correo electrónico

Condiciones de ejecución de benchmarks

  • Usó un fork interno de Harbor Framework, el harness de agente pool, un máximo de 500 pasos y sandbox interno
  • SWE-bench Multilingual, SWE-Bench Pro y Terminal-Bench 2.1 usan pass@1 promedio de 4 ejecuciones por tarea
  • DeepSWE v1.1 y SWE Atlas usan 3 ejecuciones por tarea, y Toolathlon Verified también aplica promedio de 3 ejecuciones
  • SWE Atlas aplica la metodología pública tal cual y juzga con Opus 4.5
  • Toolathlon Verified usó un harness replicado en EC2 y un agente personalizado, y a diferencia de la versión oficial reinicia y restaura completamente el entorno tras cada ejecución de evaluación
  • Para evitar apropiación de recursos del sandbox, ajustó límites de CPU, memoria y almacenamiento según el benchmark, garantizando al menos 2 núcleos de CPU, 8GB de memoria y 25GB de almacenamiento
  • Las correcciones por tarea individual están resumidas en el reporte técnico

Lecturas relacionadas

1 comentarios

 
GN⁺ 5 시간 전
Opiniones en Hacker News
  • Lo estoy probando ahora y, al menos, parece estar al nivel para competir con DS4-Flash. En una base de código de pruebas en C pequeña pero con una densidad de significado muy alta, detectó un problema que antes solo gpt-5.2 había encontrado, aunque también cometió el disparate de juzgar erróneamente que se había usado memfd_create()/mmap para IPC, y Sol también se lo perdió hasta que yo lo señalé.
    La comparación con DeepSeek V4 puede cambiar en un instante en un entorno que se mueve tan rápido como el actual, porque tanto Flash como Pro pronto tendrán suficiente entrenamiento posterior y se lanzarán oficialmente. Ojalá sigan saliendo modelos así.
    • Me da curiosidad qué arnés de pruebas y método de cuantización usaron.
  • Es impresionante, y de todo lo lanzado hoy es claramente lo más destacado; está a un nivel que opaca los nuevos productos de Google. En particular, su competitividad en precio sorprende, y genera muchas expectativas porque es el primer modelo estadounidense que parece poder enfrentarse a DeepSeek V4 Flash.
  • Este modelo no es ningún juego, y ya generó un PR que se puede usar en trabajo real.
    https://github.com/mozilla-ai/otari/pull/348
  • Es impresionante y, con este tamaño, parece posible ejecutarlo incluso en hardware doméstico realista. Aunque implique una pérdida de rendimiento, me gustaría que saliera una cuantización para entornos de 64 GB.
    Hubo evaluaciones de que la versión de 2 bits de Qwen 3.5 122B también era decente, y como este modelo parte de una base más alta, vale la pena probarlo. Ya hay alguien trabajando en eso: https://huggingface.co/vcruz305/Laguna-S-2.1-GGUF
  • Un MoE de 118B parámetros con solo 8B activos, inferencia de contexto largo y pesos abiertos: es una combinación muy bienvenida. Es la primera vez que oigo de este laboratorio, pero parece estar cerca del punto óptimo entre tamaño de modelo y rendimiento, así que tengo muchas ganas de probarlo.
    • Si las cifras de rendimiento publicadas son ciertas, entonces por fin salió el modelo que estábamos esperando.
  • Exactamente hacía falta un modelo de gama media con self-hosting realista, suficiente inteligencia y MoE rápido incluso con ancho de banda de memoria limitado.
    Hasta ahora, en Strix Halo no había una opción claramente mejor que ejecutar modelos densos como Gemma 4 o Qwen 3.6 en un escritorio con doble GPU de 32 GB, pero este modelo parece tener el tamaño para ofrecer una mejora real de rendimiento.
  • Hay que tener cuidado al probar el modelo. Con la configuración predeterminada, la función de razonamiento no queda bien activada, así que uno puede decepcionarse con los resultados o concluir que los benchmarks están inflados.
    Incluso agregando --default-chat-template-kwargs '{"enable_thinking": true}' a la configuración de ejecución de vLLM no se activó, y parece que el valor predeterminado de max_new_tokens en el generation_config.json incluido es 32k, por lo que corta el razonamiento; hay que aumentarlo. Al activar el razonamiento, la calidad del código mejoró mucho, aunque hace falta más validación en trabajo real.
    https://www.reddit.com/r/LocalLLaMA/comments/1v2pg99/laguna_...
    • Poco después de que se publicara este post, parece que la plantilla de chat predeterminada de Hugging Face se modificó para activar el razonamiento por defecto.
    • El modelo ofrecido oficialmente en OpenRouter parece tener el mismo problema; espero que se pueda corregir fácilmente.
    • Al ajustar la configuración de ejecución, los resultados cambiaron drásticamente.
  • Que un modelo de 128B supere a DeepSeek V4, de escala 1.6T, en la mayoría de los benchmarks de coding es una señal muy impresionante.
    Me gusta que Poolside no solo lo compare con modelos de una categoría similar, sino también con modelos de pesos abiertos de primera línea mucho más grandes, como Kimi-K3 de 2.5T. Ojalá otros, incluido Mistral, hicieran lo mismo.
  • Conocí Poolside hace aproximadamente una semana, cuando descubrí el arnés de coding local pool y un modelo MoE de 33B. Funcionó rápido y de manera efectiva incluso en una Mac mini vieja de 32 GB, y también pienso evaluar los modelos grandes alojados.
  • El chat de Poolside indicado en esa página se puede usar aquí: https://chat.poolside.ai