Laguna S2.1: el modelo americano open-weight
Cada vez que esta serie abre las puertas a un nuevo modelo, la advertencia sigue siendo la misma: no se trata de un benchmark científico, es el relato de un usuario exigente que instala un modelo open-weight en el PC de su casa y lo pone a prueba con las mismas tareas reservadas a los competidores que han pasado por aquí. Esta vez, sin embargo, el origen del modelo cambia el peso de la pregunta.
Desde hace meses, quienes siguen el ecosistema de los modelos abiertos se han acostumbrado a una lista que siempre suena igual: Alibaba con Qwen, DeepSeek, Moonshot con Kimi, Zhipu con GLM. El centro de gravedad del open-weight—el de los pesos descargables, inspeccionables y ejecutables sin pedir permiso a nadie—se ha desplazado casi por completo hacia los laboratorios chinos. Poolside, una empresa de San Francisco ya conocida por dar servicio a clientes enterprise y gubernamentales, ha decidido volver a poner en juego un nombre estadounidense con Laguna S 2.1, un modelo de 118 mil millones de parámetros totales y 8 mil millones activos por token diseñado para el coding agentico y para el trabajo en horizontes largos, lanzado el 21 de julio de 2026 bajo la licencia OpenMDW-1.1.
El tono con el que Poolside ha acompañado el lanzamiento no es el tono apagado de una actualización técnica. El co-CEO Jason Warner ha enmarcado el lanzamiento como la respuesta a un vacío que Occidente se ha construido por sí mismo: mientras los proveedores estadounidenses más capaces cierran sus mejores sistemas detrás de API de pago y barreras regulatorias, la empresa afirma ofrecer una opción open-weight production-ready pensada para quienes necesitan control sobre los datos, costes previsibles y posibilidad de autohosting. En el blog oficial de Poolside se lee explícitamente que la cuestión de quién proporciona los modelos abiertos de Occidente ha pasado de los círculos de investigación a las salas de reuniones de las empresas, y de ahí hasta Washington. Se trata de un marco a la vez industrial y político: quién controla los pesos, quién puede ejecutarlos en hardware propio y quién puede realmente inspeccionarlos línea por línea.
Mi configuración, la misma metodología
La configuración de hardware sigue siendo la ya descrita en las entregas anteriores de esta serie: un Ryzen 7700, 32 GB de RAM DDR5 y una Radeon RX 9060 XT con 16 GB de VRAM—la misma máquina con la que ya he puesto a prueba a Qwen 3.5, Qwen 3.6, la familia Gemma 4 y Ornith-1.0. Quienes deseéis conocer los detalles sobre los frameworks y los criterios de elección encontraréis todo en la primera entrega y en la segunda; aquí me limito a confirmar que el principio rector sigue siendo el mismo: elegir el tamaño de modelo que realmente pueda caber en la máquina y demostrar su valor en el uso diario, no el que resulte más impresionante sobre el papel.
El hermano mayor: Laguna S 2.1
Antes de descender al tamaño que efectivamente he probado, vale la pena comprender dónde se sitúa dentro de la familia. Laguna S 2.1 tiene 48 capas (layers), una ventana de contexto declarada de hasta un millón de tokens, y comparte con el resto de la familia la arquitectura básica: un router de token-choice con gating softplus sobre 256 expertos más uno compartido, grouped-query attention y capas de atención global alternadas con capas de sliding window. En los benchmarks declarados por Poolside, Terminal-Bench 2.1 marca un 70,2%, SWE-bench Multilingual un 78,5% y DeepSWE un 40,4%—cifras que, según MarkTechPost, lo sitúan a la cabeza entre los modelos abiertos de tamaño declarado, aunque por detrás de los sistemas cerrados de frontera como GPT-5.6 Sol o Claude Fable 5, que en Terminal-Bench 2.1 se mantienen por encima del 88%. En resumen, la familia Laguna cubre un rango que va desde el tamaño XS de 33B, diseñado para ejecutarse en local, hasta el S de 118B y más allá, con una coherencia arquitectónica que hace que los modelos sean comparables entre sí.
El modelo de la prueba: Laguna XS 2.1
Laguna XS 2.1 es el tamaño compacto de la familia: 33 mil millones de parámetros totales con solo 3 mil millones activados para cada token, distribuidos en 40 capas totales en una relación de 3 a 1 entre sliding window attention (con una ventana de 512 tokens) y atención global. El gating es sigmoid con escalas rotacionales por capa, los expertos son 256 más uno compartido siempre activo, y la caché KV está cuantizada en FP8 para reducir el consumo de memoria por token. El contexto declarado llega a los 262.144 tokens, el modelo es puramente textual—sin modalidad visual—y soporta el razonamiento nativo con thinking intercalado entre las llamadas a las herramientas, activable o desactivable para cada solicitud individual.
En los benchmarks oficiales, reflejados en la ficha del modelo de HuggingFace, Laguna XS 2.1 marca un 63,1% en SWE-bench Multilingual, lo que supone un salto de 5,4 puntos porcentuales respecto a la generación anterior XS.2, y Poolside declara además una mejora sensible en las tareas de estilo terminal. Hay que decir con claridad, por honestidad hacia el lector, que algunas fuentes secundarias que circulan por internet ofrecen cifras diferentes para este modelo, incluidas referencias a una arquitectura derivada de Qwen2.5—información que las fuentes primarias de Poolside y HuggingFace desmienten explícitamente, describiendo a Laguna como una familia con su propia receta arquitectónica. He preferido ceñirme a los datos verificables en las páginas oficiales y no a las cifras no confirmadas que circulan por otros lados.
El modelo se distribuye en BF16, FP8, INT4 y NVFP4, con soporte declarado para vLLM, SGLang, NVIDIA TensorRT-LLM, HuggingFace Transformers y Ollama, mientras que el soporte nativo para llama.cpp—y, por tanto, para los GGUF necesarios para LM Studio—llegó más tarde a través de una pull request dedicada en el repositorio oficial, tal como se lee en la página GGUF de Poolside. Para completar el paquete, Poolside también ha lanzado los modelos DFlash, pequeños speculators que, en la fase de inferencia local, duplican en las pruebas de la empresa los tokens por segundo realmente obtenidos.
OpenMDW-1.1: qué significa realmente "abierto"
Laguna XS 2.1 se distribuye bajo la licencia OpenMDW-1.1, cuyas siglas significan Open Model Data Weights—un formato de licencia respaldado por NVIDIA y la Linux Foundation que Poolside adopta explícitamente para reducir la fricción legal en la distribución de modelos abiertos, tal como se explica en la página oficial de la licencia. Es una distinción que merece la pena hacer con precisión, porque en el lenguaje periodístico "open source" y "open-weight" acaban a menudo confundiéndose. Aquí no hay publicación del código de entrenamiento ni del dataset; lo que es público y libremente descargable son los pesos del modelo, utilizables, modificables y redistribuibles incluso en contextos comerciales sin restricciones particulares. Es el mismo principio ya visto con licencias como Apache 2.0 o MIT para otros modelos de esta serie, pero aplicado a un formato pensado específicamente para los artefactos de los modelos lingüísticos.
Mi elección: GGUF Q6 sobre 16 GB de VRAM
La versión original en BF16 de Laguna XS 2.1 pesa 66,9 GB, una cifra que excluye a priori cualquier hipótesis de ejecución directa en mi máquina. La tabla de archivos GGUF publicada por Poolside indica Q4KM como la cuantización aconsejada por defecto para el uso local, unos 20,3 GB, un compromiso pensado para seguir siendo accesible incluso en configuraciones modestas, incluidos los Mac con 36 GB de RAM unificada. Para esta prueba he elegido, no obstante, una cuantización más alta, Q6_K, un paso por encima del valor por defecto recomendado, para mantenerme más cerca de la calidad del modelo original aprovechando los 16 GB de VRAM disponibles en la Radeon. Es una decisión mía, no un preset indicado por Poolside; la tabla oficial no incluye el Q6 entre las opciones recomendadas en primera instancia, pero sí entre las compatibles, y es la que he utilizado en LM Studio, el mismo de toda la serie.
Ocho pruebas, un veredicto a medias
Laguna XS 2.1 es el intento de Poolside de devolver el open-weight americano al centro del debate, no con un modelo generalista, sino con un sistema compacto, local y declaradamente especializado en el coding agentico. Las ocho pruebas que siguen verifican sobre el terreno hasta qué punto esa especialización declarada soporta la comparación con el uso real: coding, razonamiento, contexto largo y calidad de la conversación en múltiples turnos.
Configuración de LM Studio: contexto ajustado a 150.784 tokens, GPU offload en 20 de las 32 capas, pool de 8 hilos (threads) de CPU, lote (batch) de evaluación de 2048, batch size de 512, máximo de 4 predicciones concurrentes, 8 expertos activos por token.
Prueba 1, razonamiento científico sobre el mecanismo de Higgs, nota 5/5, 15,26 tokens por segundo. La explicación se desarrolla en seis secciones lógicas: desde la simetría inicial al campo de Higgs con el potencial de "sombrero mexicano", hasta el mixing entre los campos W3 y B y la definición del ángulo de Weinberg, ambos tratados con precisión. La única imprecisión se refiere a la motivación sobre la ausencia de masa del fotón, un detalle que no compromete la sustancia de una explicación notable para un modelo declaradamente especializado en coding.
Prueba 2, lectura multimodal de una tabla de Excel, no ejecutada. Laguna XS 2.1 es un modelo puramente textual; la carga de la imagen en LM Studio no es reconocida—una limitación estructural coherente con lo declarado por Poolside, no un defecto de configuración.
Prueba 3, generación de código para el ciclo máximo en un grafo, nota 3,8/5, 11,60 tokens por segundo, con 13 minutos y 22 segundos de thinking. Aquí el modelo ha decepcionado. La cadena de razonamiento muestra una comprensión teórica sólida: se reconoce la naturaleza NP-hard del problema, así como la necesidad de gestionar los back-edges y de rastrear los antecesores en la ruta para evitar recuentos duplicados. Después de trece minutos, sin embargo, el algoritmo producido resuelve un problema diferente al planteado: encuentra ciclos en un árbol DFS en lugar del ciclo de longitud máxima. Un tiempo de thinking de esta duración es en sí mismo una anomalía poco compatible con un uso interactivo, y más aún cuando la respuesta final no da en el clavo.
Prueba 4, planificación de viaje multilingüe, nota 3,5/5, 14,98 tokens por segundo. El prompt requería una respuesta en francés para un cliente francés, y aquí surgió una disociación curiosa: la cadena de pensamiento planifica correctamente en francés, pero la respuesta final llega en italiano al primer intento. Solo tras un requerimiento explícito el modelo corrige el idioma, produciendo un francés de buena calidad con referencias realistas a Kinkaku-ji, Fushimi Inari y los mercados de Tsukiji y Nishiki. El contenido, una vez corregido el idioma, es sólido, pero el comportamiento del primer intento sigue siendo una señal de alarma sobre la fiabilidad en contextos multilingües.
Prueba 5, contexto largo en un PDF de 460 páginas, nota 5/5, 13,88 tokens por segundo. La tarea consistía en cargar el Artificial Intelligence Index Report 2025 de Stanford HAI, de unas 460 páginas, y pedir al modelo los datos sobre el crecimiento de la generación de vídeo, indicando la página en la que se encuentran. A pesar de un contexto ajustado a 150.784 tokens, el modelo respondió al primer intento indicando las páginas 126 y 127—el mismo rango identificado por los mejores modelos probados hasta ahora en esta serie—, citando Google Veo, Meta Movie Gen y OpenAI Sora, el ejemplo del spaghetti eating test, e incluso la Figura 2.3.11 que compara las preferencias de los usuarios entre Veo 2, Movie Gen, Kling v1.5 y Sora Turbo, un nivel de detalle superior a la media.
Prueba 6, razonamiento espacial sobre una habitación desordenada, no ejecutada. La misma limitación de la Prueba 2: ausencia de soporte multimodal.
Prueba 7, planificación agentica de una aplicación web, nota 4,8/5, 15,34 tokens por segundo. El stack propuesto—React con Vite, Node.js con Express, PostgreSQL con Prisma, JWT, SendGrid, Puppeteer—es moderno y coherente. La hoja de ruta en cuatro sprints está bien equilibrada entre setup, dashboard, generación de PDF y pruebas, indicando los entregables (deliverables) y las criticidades de cada uno. Los ejemplos de código para el modelo de Prisma y para el endpoint de importación de CSV muestran un conocimiento práctico real; la única carencia es la ausencia de una división explícita del trabajo entre los dos desarrolladores solicitada por el prompt.
Prueba 8, conversación técnica en cuatro turnos, nota 5/5, velocidad media en caída fisiológica de 15,54 a 11,45 tokens por segundo. Laguna mantuvo la coherencia construyendo un marco arquitectónico progresivo: desde el stack inicial a la comparación entre WebSocket y polling para mil usuarios simultáneos con ejemplos de código, pasando por un esquema de PostgreSQL completo con índices y consultas, para cerrar con una estrategia de escalabilidad a diez mil usuarios que aborda el clustering de Node.js, el sharding de Redis, el equilibrio de carga (load balancing) y la monitorización.
Conclusiones
La nota media de las seis pruebas realizadas se queda en 4,52 sobre 5, un resultado respetable que revela, sin embargo, un modelo a dos velocidades. Allí donde se necesita construir, explicar, planificar y mantener la coherencia en múltiples turnos, Laguna XS 2.1 se comporta como un colega sólido, a ratos sorprendente en contextos largos. Pero allí donde la tarea es precisamente aquella para la que se vende el modelo—el coding puro sobre un problema algorítmico de dificultad media—, el rendimiento no estuvo a la altura, con un tiempo de procesamiento de trece minutos que sigue siendo el dato más difícil de justificar para cualquiera que necesite usarlo en producción.
En la comparación con los demás protagonistas de esta serie—Qwen 3.5, la familia Gemma 4, Qwen 3.6 y, sobre todo, Ornith-1.0, que en esta misma serie había cerrado con un ocho de ocho—, Laguna XS 2.1 no consigue imponerse como el punto de referencia en su clase de tamaño, aunque sigue siendo un modelo a tener en cuenta precisamente por su procedencia. Queda abierta la pregunta más interesante de todas: si la brecha que aún separa los esfuerzos occidentales de los laboratorios chinos en el ámbito del open-weight es una cuestión de tiempo—con Poolside prometiendo ciclos de lanzamiento cada vez más rápidos gracias a su "Model Factory"— o si refleja, en cambio, una diferencia más estructural en la cantidad de datos y recursos que las empresas chinas pueden destinar a estos proyectos sin la limitación de tener que sostener en paralelo un modelo de negocio enterprise.
Quién debería fijarse hoy en Laguna XS 2.1, con qué hardware y para qué escenarios de uso específicos es una pregunta que solo valdrá la pena responder tras ver cómo se comporta la próxima iteración, teniendo en cuenta que la generación anterior, XS.2, llegó al mercado solo unas semanas antes que esta. Sobre el anómalo tiempo de thinking observado en la Prueba 3, queda por entender si se trata de un límite del modelo en sí o de un efecto secundario de la cuantización Q6 elegida para esta prueba, una cuestión que merece una verificación dedicada antes de extraer conclusiones definitivas. Y luego está la cuestión más amplia, la geopolítica de la que partíamos: un modelo americano capaz de competir en el terreno del coding local es una noticia importante, pero ¿basta un solo lanzamiento para llenar un vacío que se ha formado a lo largo de años de estrategias divergentes entre Occidente y China en el ámbito de la inteligencia artificial abierta?