Qwen3.8-27B: qué es, cómo ejecutarlo y cuánto piensa

Qwen3.8-27B es un modelo multimodal de 27.000 millones de parámetros, con pesos abiertos bajo Apache 2.0, que cabe en unos 17 GB y que la gente ya está usando para trabajo agéntico de verdad. Salió el 14 de agosto de 2026 y lleva dos días fuera.

Eso último importa más de lo que parece. Dos días son suficientes para que aparezcan cuantizaciones, soporte en llama.cpp y capturas espectaculares en Reddit. No son suficientes para que nadie haya verificado los benchmarks del propio Qwen con un método serio.

Así que este post hace dos cosas a la vez: te cuenta lo que hay, y te señala dónde están los asteriscos.

Lo que vas a encontrar aquí:

• Qué lleva Qwen3.8-27B por dentro y por qué es raro que un denso de 27B sea multimodal
• Los benchmarks oficiales, con la letra pequeña puesta donde toca
• El problema del que todo el mundo habla: cuánto razona el modelo en su modo por defecto
• El primer benchmark comunitario decente que ha aparecido, con hardware y cuantización declarados
• Qué necesitas para ejecutarlo en tu máquina, y por qué 17 GB no significa 17 GB
• Cómo enchufarlo a OpenCode, Pi, Claude Code o Hermes Agent hoy mismo

⚠️ Este post está escrito el 16 de agosto de 2026, dos días después del lanzamiento. Todo lo que leas sobre rendimiento son resultados de Qwen o experiencias individuales sin control de variables. La parte que aguanta el paso del tiempo es la de arquitectura, hardware y método de evaluación. Si llegas aquí meses después, salta directo a la sección de cómo comprobarlo tú mismo.

¿Qué es Qwen3.8-27B y qué lleva por dentro? ¶

Es el modelo denso de tamaño medio de la familia Qwen3.8, publicado por Alibaba con pesos abiertos y licencia Apache 2.0 desde el primer día. No es una mezcla de expertos: es un denso de 27B, con todos sus parámetros activos en cada token.

Hay tres cosas de esa tabla que conviene fijar antes de seguir, porque explican casi todo lo demás.

Es multimodal nativo, y eso en un denso de 27B no es lo habitual. Texto, imágenes y vídeo entran por la misma puerta. Si tu flujo consiste en pasarle capturas al agente para que arregle un componente que se ve torcido, este modelo sí puede mirarlas. Es justo lo que GLM-5.3, lanzado el mismo día, no puede hacer.

La arquitectura es híbrida y viene de la generación anterior. De las 64 capas, 48 usan Gated DeltaNet y solo 16 atención completa. Traducido: la mayor parte del modelo mantiene un estado recurrente en vez de mirar toda la ventana en cada paso. Es la razón de que un contexto de 262K sea manejable en hardware que no es un centro de datos, y también la razón de que el consumo de memoria no se comporte igual que en un transformer clásico.

Tiene cabeza MTP integrada. Sirve para speculative decoding sin necesidad de un modelo borrador aparte. Es un detalle que suena a nota al pie y que se traduce en tokens por segundo cuando el runtime lo aprovecha.

Y una cuarta, la que va a dominar el resto del post: el nivel de esfuerzo de razonamiento por defecto es xhigh. El más alto de los tres. Guárdate ese dato.

Guía interactiva gratis

El modelo es una pata. El agente que lo mueve es la otra

Qwen3.8-27B no hace nada solo: necesita un harness que le pase el repo, ejecute comandos y verifique. En la parada 3 de esta guía gratuita separamos las dos patas —modelo y agente— y en la 5 eliges el tuyo con presupuesto en la mano, que es la decisión más gruesa de todas.

Entra en el curso gratis →

¿Qué dicen los benchmarks oficiales de Qwen3.8-27B? ¶

Dicen cosas llamativas. Estas son las cifras que Qwen publica en su ficha de modelo, comparándose con su generación anterior y con modelos bastante más grandes:

En el lado multimodal y agéntico las cifras son todavía más gruesas: 84,3 en OSWorld-Verified, frente al 63,9 de Qwen3.6, el 73,3 de Qwen3.7-Plus y el 72,7 que la propia tabla asigna a Opus 4.6 Max. WebArena-Verified sube de 48,8 a 64,8.

Ahora los asteriscos, que son grandes.

Son evaluaciones de Qwen. No de un tercero. La tabla la publica el laboratorio que ha entrenado el modelo, en el documento donde lo anuncia.

Tres de los seis benchmarks son internos. QwenSWEBench, CoWorkBench y RecreationBench no los puede reproducir nadie fuera de Qwen. Casualmente son los que muestran las mayores distancias.

Los métodos de ejecución no son homogéneos. En SWE-bench Pro, el resultado de Opus procede de su cifra oficial publicada, mientras que otros modelos los ejecutó Qwen. Comparar un número que ha medido el rival con otro que has medido tú, en la misma fila, es exactamente el tipo de detalle que se pierde cuando la tabla circula por Twitter.

Con eso encima de la mesa, yo no leería “61,7 contra 53,4” como “un 27B programa mejor que Opus 4.6”. Lo leería como “hay una señal lo bastante fuerte como para que merezca la pena comprobarlo”.

Que es distinto. Y es la única lectura que aguanta dos días después de un lanzamiento.

¿Qué está diciendo la gente que ya lo ha probado? ¶

Aquí es donde empieza lo interesante, porque las primeras experiencias apuntan todas en la misma dirección y añaden un matiz que la ficha oficial no menciona.

Simon Willison lo está ejecutando en un MacBook Pro con M5 Max mediante LM Studio, y también en una NVIDIA DGX Spark. Su prueba informal de siempre —el pelícano montando en bicicleta, dibujado en SVG— con un GGUF de alrededor de 17 GB le dio, según publicó, el mejor resultado que había visto hasta ese momento entre modelos capaces de ejecutarse en su portátil. Ha llegado a construir una herramienta pequeña solo para seguir probándolo.

Viniendo de alguien que lleva años pasando ese mismo test a todo lo que sale, es una señal que vale más que una tabla.

En Reddit hay dos experiencias que se citan mucho. Un usuario comparó Qwen3.6 y Qwen3.8 generando una aplicación desde cero: la 3.8 produjo algo bastante más ambicioso, pero se gastó alrededor de 50.000 tokens de razonamiento y necesitó dos rondas de corrección de bugs. Otro asegura haber hecho one-shot de un clon de Super Mario ejecutando Q8 en un Framework Desktop, en su propia oficina.

La segunda es anecdótica, y en el mismo hilo hay gente cuestionando que eso sea un benchmark de nada. Pero encaja con el patrón: donde la mejora se percibe con claridad es en tareas largas de construcción de software, no en respuestas cortas.

Y encaja también con la queja.

¿Por qué todo el mundo habla del overthinking de Qwen3.8-27B? ¶

Porque el modelo, en su configuración por defecto, puede razonar durante una cantidad de tokens que no se corresponde con la dificultad de lo que le has pedido. Simon Willison lo describió con una etiqueta que se ha pegado sola: chronic over-thinker.

En las discusiones de la ficha oficial hay usuarios reportando que se queda pensando durante cantidades enormes de tokens incluso intentando bajar a low o medium. Otros dicen que con medium el comportamiento mejora bastante. Las dos experiencias conviven en el mismo hilo, que es justo lo que pasa cuando el resultado depende del runtime, la plantilla de chat y el parser que tengas montado.

No es un despiste de configuración: xhigh es el valor por defecto que Qwen ha elegido. Y la documentación avisa de algo que conviene leer dos veces antes de bajarlo a lo bruto: reducir el esfuerzo de razonamiento puede provocar más fallos y más reintentos en flujos agénticos. O sea, que menos razonamiento por turno no significa menos coste total.

🔑 Menos tokens por turno y más turnos puede salirte más caro que más tokens por turno y un solo intento. La métrica útil no es “tokens por respuesta”, es tokens hasta la tarea terminada.

Y ahora la pregunta incómoda, que también salió en Reddit. Un usuario afirma que bajando a Medium o Low obtiene resultados que se parecen mucho a los de Qwen3.6. Si eso se confirma, significaría que una parte del salto espectacular de 3.6 a 3.8 viene simplemente de dejar que el modelo piense mucho más.

Ojo: es una observación anecdótica de una persona, no una conclusión demostrada. Pero es la hipótesis correcta que hay que intentar tumbar, y es lo que yo vigilaría durante los próximos días por encima de cualquier otra cosa.

¿Hay algún benchmark independiente de Qwen3.8-27B? ¶

Todavía poco, pero ha aparecido una comparación bastante mejor controlada que la media de lo que circula estos días. Y lo que la hace valiosa no son los resultados: es que declara el hardware, la cuantización y el contexto.

Un usuario ejecutó en una RTX 5090 de 32 GB, con Q4_K_M y 64K de contexto, un conjunto de 16 problemas difíciles con respuestas verificables:

Qwen resolvió los 6 problemas de código y los 4 de razonamiento, y falló dos de matemáticas. Fue además el que completó el conjunto entero en menos tiempo, pese a no ser el más rápido por token.

Hay un detalle en sus fallos que merece más atención que la puntuación. Uno de los errores matemáticos incluía una referencia a OEIS que parecía verificable y no lo era.

Ese es el tipo de error caro. No el que se equivoca de manera evidente, sino el que te da una fuente con pinta de real para respaldar algo falso. Si trabajas con agentes, ya sabes cuánto tiempo se va en comprobar una cita que resultó no existir.

Dieciséis preguntas no son un leaderboard. Pero es una señal independiente con las variables declaradas, y eso vale bastante más que “me hizo una web impresionante”.

Mide en tu proyecto, no en la tabla

Un modelo que razona 50.000 tokens necesita que alguien mida si eso sirve para algo

Ponytail promete menos código y menos tokens, y en esta masterclass la destripamos entera y la pasamos por un benchmark contra un proyecto real para ver si cumple. El método de medición es lo que te llevas: exactamente lo que te falta para saber si el xhigh de Qwen te está pagando o te está sangrando.

Ver el método de medición →

Incluye autodiagnóstico · Acceso con Web Reactiva Premium

¿Qué hardware necesitas para ejecutar Qwen3.8-27B en local? ¶

Menos del que te imaginas, y aquí es donde hay más consenso entre todas las fuentes.

Estas son las cifras publicadas por quienes lo han empaquetado:

• Unsloth ya ofrece GGUF que se sitúan alrededor de los 17 GB.
• Ollama publica una variante de unos 18 GB.
• SGLang documenta ejecución en una sola RTX 5090 usando NVFP4, con los pesos en aproximadamente 16,5 GB. FP8 ronda los 28,5 GB y se queda demasiado justo para una tarjeta de 32 GB salvo con cargas muy pequeñas.
• AMD salió el mismo día con soporte y reporta unos 24,5 tok/s en un Ryzen AI Max+ 395 y 51,8 tok/s en una Radeon AI Pro R9700, usando llama.cpp. Recomienda tener alrededor de 24 GB de memoria disponible para trabajar con holgura.

Y en el extremo optimizado, hay un despliegue comunitario con una RTX Pro 6000 que afirma 140 tok/s, 0,156 segundos hasta el primer token y los 262K de contexto completos, apoyándose en NVFP4 y speculative decoding. Trátalo como lo que es: un resultado de un usuario, no un benchmark oficial.

⚠️ Que un GGUF pese 17 GB no significa que puedas usar 262K de contexto dentro de 17 GB. Los pesos son una parte. Después están el estado de las capas Gated DeltaNet, la caché KV, el encoder de visión y el propio runtime. Buena parte de la guía de SGLang está dedicada justo a gestionar ese compromiso.

Ese matiz se lo salta medio internet cuando publica capturas del tamaño del fichero. Si te llevas una sola cosa de esta sección: el tamaño del GGUF es el suelo, no el techo.

Si vienes de la duda de qué significa exactamente que un modelo tenga los pesos publicados y qué te deja hacer la licencia, lo desmenuzamos en qué son los modelos de pesos abiertos. Con Apache 2.0, Qwen3.8-27B está en el lado cómodo de esa conversación.

¿Qué cuantización elegir y por qué importa tanto? ¶

Porque comparar experiencias sin decir la cuantización es hablar de modelos distintos.

Ya está apareciendo investigación comunitaria específica sobre qué cuantización degrada menos este modelo. Una comparación KLD independiente publicada en Hugging Face encuentra diferencias apreciables incluso entre dos cuantizaciones sub-2-bit del mismo modelo, con distinto tamaño y distinta calidad.

Eso tiene una consecuencia práctica inmediata. Cuando leas “a mí me funciona fatal” o “a mí me va de escándalo” en un foro, la primera pregunta no es qué modelo usa esa persona. Es:

1. Qué cuantización exacta ha descargado y de qué repositorio.
2. Qué runtime la ejecuta (llama.cpp, LM Studio, Ollama, vLLM, SGLang).
3. Qué contexto ha configurado y cuánta memoria le queda para la caché KV.
4. Qué reasoning_effort tiene puesto.

Sin esas cuatro respuestas, la anécdota no se puede comparar con la tuya. Y en un lanzamiento de dos días, el 90% de lo que vas a leer no las incluye.

¿Puedes usar Qwen3.8-27B como agente de código hoy? ¶

Sí, y esto es lo que a mí me parece más relevante de todo el lanzamiento. El ecosistema para usarlo como agente local ha aparecido el mismo día que el modelo, no tres semanas después.

SGLang publicó documentación específica para conectarlo con OpenCode, Pi, Claude Code y Hermes Agent. Ollama fue todavía más directo y sacó integración de lanzamiento:

# Arrancar OpenCode con Qwen3.8 servido por Ollama
ollama launch opencode --model qwen3.8

También publicó integración con Pi y una versión optimizada con MLX para Apple Silicon, que es la que hace viable el escenario de “modelo serio en un portátil”.

Por el lado de llama.cpp, Georgi Gerganov sacó soporte casi inmediato usando el GGUF de ggml-org y aprovechando la cabeza MTP integrada del modelo para speculative decoding:

# Servidor local con el GGUF oficial de ggml-org
llama serve -hf ggml-org/Qwen3.8-27B-GGUF

Si nunca has enchufado un modelo local a un agente de terminal, el camino más corto es OpenCode, que además es open source y no te ata a un proveedor. Y si quieres el ángulo de agentes multi-modelo, Hermes Agent es de los que mejor toleran cambiar el motor por debajo.

💡 Un par de puntos de benchmark se olvidan en un mes. Que tu agente de terminal favorito hable con el modelo el mismo día del lanzamiento, no. Es la diferencia entre un modelo que puedes probar esta tarde y uno que te dará pereza montar.

¿Qué dicen Hacker News y los foros técnicos? ¶

El tono general es positivo, y bastante menos crédulo que el de Twitter. En el hilo de Hacker News se repiten tres temas.

El primero, sorpresa genuina de que un modelo de unos 27B se coloque tan cerca de modelos cloud mucho más grandes en determinadas tareas. El segundo, dudas sobre el origen de esas cifras: cuánto viene de optimizar contra los benchmarks y cuánto de dejar el razonamiento en xhigh. Y el tercero, avisos de que la cuantización, la plantilla de chat y el harness pueden cambiar la experiencia por completo.

Hay además una recomendación que aparece varias veces: esperar una o dos semanas antes de juzgarlo. No por prudencia decorativa, sino porque históricamente llama.cpp, Ollama, LM Studio, las plantillas y los parsers necesitan ajustes finos después de cada lanzamiento.

Eso coincide con algo que Georgi Gerganov lleva tiempo repitiendo sobre modelos locales: muchas veces lo que parece un problema del modelo termina siendo el harness, la plantilla de chat, cómo se construye el prompt o un bug de inferencia.

Es un consejo que ahorra bastante frustración. Si el modelo te da resultados raros el día 1, la probabilidad de que el fallo esté en tu cadena de herramientas es alta.

¿Cómo compruebas tú mismo si el salto es real? ¶

Esta es la sección que te va a servir cuando Qwen3.8 sea historia y estemos hablando de la 3.9 o de lo que toque. El problema de este lanzamiento no es que falten datos: es que casi ningún dato es comparable con otro.

Para que una comparación entre Qwen3.6 y Qwen3.8 signifique algo, tienes que fijar cuatro variables:

1. El mismo harness. El mismo agente, la misma versión, la misma plantilla de chat.
2. La misma cuantización. Del mismo repositorio, con el mismo nombre de fichero.
3. El mismo presupuesto de razonamiento. Si comparas 3.8 en xhigh contra 3.6, no estás comparando modelos: estás comparando presupuestos.
4. El mismo contexto configurado. Y con memoria suficiente para la caché KV en los dos casos.

Con eso fijado, la prueba que a mí me parece más informativa es esta. Coge cinco tareas de un repositorio tuyo de verdad:

1. Una funcionalidad que toque al menos cuatro archivos.
2. Un bug antiguo con reproducción incómoda.
3. Una migración pequeña con tests que tienen que pasar al ejecutarlos.
4. Una tarea con una captura de pantalla de por medio, para estrujar la parte multimodal.
5. Una tarea larga de esas que necesitan tres o cuatro vueltas.

Y mide cuatro cosas: vueltas necesarias, tests rotos, tokens totales hasta terminar y cuánta basura convincente deja por el camino. La cuarta es la que no sale en ningún benchmark, la que cuesta más cara y la que la referencia falsa de OEIS anticipa perfectamente.

Si además quieres el mapa completo de qué modelo usar según el tipo de trabajo, lo mantenemos actualizado en los mejores modelos de IA para programar.

¿Cuándo compensa Qwen3.8-27B y cuándo no? ¶

Te lo pongo como decisión, no como tabla.

Merece la pena probarlo si:

• Quieres un modelo capaz corriendo en tu máquina sin enviar código a ningún sitio. Con 24 GB de memoria disponible estás dentro.
• Necesitas multimodalidad en local: capturas de UI, diagramas, vídeo. Es de lo poco que hay a este tamaño que lo hace.
• Trabajas con tareas agénticas largas, que es donde el salto se percibe con más claridad.
• Ya tienes montado OpenCode, Pi, Claude Code o Hermes Agent y solo quieres cambiar el motor.
• La licencia te importa: Apache 2.0 desde el día uno, sin cláusulas raras.

Todavía no compensa si:

• Necesitas resultados reproducibles y auditados. Los benchmarks independientes acaban de empezar.
• Tu presupuesto de tiempo por tarea es estrecho: el modo por defecto piensa mucho, y bajarlo tiene contrapartidas.
• No quieres pelearte con plantillas de chat ni parsers durante las primeras semanas.
• Buscas la capacidad absoluta máxima. Para eso siguen estando los grandes cerrados, y no es una pelea justa.

Lo que queda por demostrar ¶

Qwen3.8-27B llega con una tesis fuerte y unos cuantos agujeros. Los agujeros, por orden de importancia:

• Nadie ha reproducido los benchmarks principales. Tres de ellos ni siquiera se pueden reproducir.
• El coste real del razonamiento está sin medir. No sabemos cuánto del salto sobrevive al normalizar tokens.
• La cuantización cambia el modelo lo suficiente como para que las comparaciones entre usuarios no valgan nada sin declararla.
• Alucina fuentes con aplomo. La referencia falsa de OEIS es el aviso, no la excepción.
• El ecosistema aún se está asentando. Plantillas y parsers van a moverse durante semanas.

Y la tesis, que es lo que a mí me hace guardar este lanzamiento en la carpeta de “esto importa”: puede que estemos cruzando un umbral bastante más práctico que cualquier comparación con Opus.

🔑 Un modelo multimodal local de 17-20 GB que ya es lo bastante competente para hacer trabajo agéntico largo de verdad. Ese es el titular, y no tiene nada que ver con quién gana una tabla.

Porque si eso se sostiene, la conversación deja de ser “qué modelo puntúa más” y pasa a ser “qué puedo ejecutar yo, en mi máquina, sin pedirle permiso a nadie”. Que es una conversación bastante más interesante.

Qwen3.8-27B en una frase ¶

El primer modelo multimodal de pesos abiertos que cabe en un portátil decente y aguanta trabajo agéntico de verdad, con un modo de razonamiento por defecto que todavía no sabemos si es su mayor virtud o su mayor factura.

TL;DR ¶

• 🧠 Qwen3.8-27B es un denso de 27B multimodal (texto, imagen y vídeo) con 262K de contexto nativo, ampliable a 1M, y licencia Apache 2.0 desde el día uno.
• 📈 En los benchmarks de Qwen saca 61,7 en SWE-bench Pro, 90,3 en LiveCodeBench v6 y 84,3 en OSWorld-Verified, pero tres de sus seis benchmarks son internos y no los puede reproducir nadie.
• 🌀 Su nivel de esfuerzo por defecto es xhigh, y las primeras experiencias hablan de 50.000 tokens de razonamiento para generar una aplicación. Simon Willison lo llama chronic over-thinker.
• 💻 Se ejecuta en local con GGUF de unos 17 GB, 16,5 GB con NVFP4 en una RTX 5090 y 24,5 tok/s en un Ryzen AI Max+ 395. Ojo: el tamaño del fichero no incluye caché KV ni encoder de visión.
• 🔌 OpenCode, Pi, Claude Code, Hermes Agent, Ollama y llama.cpp lo soportan desde el mismo día del lanzamiento, con speculative decoding vía la cabeza MTP integrada.

Preguntas frecuentes sobre Qwen3.8-27B ¶

¿Qué es Qwen3.8-27B? ¶

Es un modelo de lenguaje multimodal de Alibaba, publicado el 14 de agosto de 2026 con pesos abiertos bajo licencia Apache 2.0. Tiene 27.000 millones de parámetros en arquitectura densa (no mezcla de expertos), acepta texto, imágenes y vídeo, y ofrece 262.144 tokens de contexto nativo ampliables hasta 1M.

¿Qwen3.8-27B es open source? ¶

Sus pesos son abiertos y la licencia es Apache 2.0, que es de las más permisivas del panorama: puedes descargarlo, ejecutarlo, ajustarlo y usarlo en productos comerciales. Eso no es exactamente lo mismo que open source según la definición de la OSI, porque no publica los datos de entrenamiento. La diferencia está explicada en detalle en el post sobre modelos de pesos abiertos.

¿Cuánta memoria necesita Qwen3.8-27B? ¶

Los GGUF de Unsloth se sitúan alrededor de 17 GB y la variante de Ollama en unos 18 GB. Con NVFP4, SGLang documenta pesos de unos 16,5 GB en una sola RTX 5090. AMD recomienda tener alrededor de 24 GB de memoria disponible para trabajar con holgura, porque además de los pesos hay que alojar la caché KV, el estado de las capas Gated DeltaNet y el encoder de visión.

¿Se puede ejecutar Qwen3.8-27B en un portátil? ¶

Sí, si tiene memoria unificada suficiente. Simon Willison lo está ejecutando en un MacBook Pro con M5 Max mediante LM Studio, y Ollama publicó una versión optimizada con MLX para Apple Silicon. En equipos AMD se reportan unos 24,5 tok/s en un Ryzen AI Max+ 395 usando llama.cpp.

¿Qué es el problema del overthinking en Qwen3.8-27B? ¶

Que el nivel de esfuerzo de razonamiento por defecto es xhigh, el más alto de los tres disponibles, y el modelo puede gastar decenas de miles de tokens pensando incluso en tareas que no lo justifican. Hay usuarios reportando que el comportamiento persiste al bajar a medium o low, y otros que dicen que con medium mejora bastante. La documentación avisa de que reducir el razonamiento puede provocar más fallos y reintentos en agentes.

¿Cómo cambio el reasoning_effort de Qwen3.8-27B? ¶

El modelo expone tres niveles: xhigh, medium y low, y el valor por defecto es xhigh. Cómo se configura depende del runtime que uses (llama.cpp, Ollama, LM Studio, vLLM o SGLang), porque cada uno lo expone a su manera. Antes de bajarlo, mide tokens hasta tarea terminada y no solo tokens por respuesta: menos razonamiento por turno puede significar más turnos.

¿Qwen3.8-27B es mejor que Opus 4.6 o GLM-5.3? ¶

En la tabla que publica Qwen supera a Opus 4.6 Max en SWE-bench Pro, QwenSWEBench, CoWorkBench, LiveCodeBench y OSWorld-Verified, y queda por detrás en Terminal Bench 2.1. Pero son evaluaciones del propio Qwen, con benchmarks internos incluidos y métodos de ejecución no homogéneos. Frente a GLM-5.3 la diferencia práctica más clara es otra: Qwen ve imágenes y GLM-5.3 no, y Qwen publicó los pesos el primer día.

¿Qué cuantización de Qwen3.8-27B conviene usar? ¶

Depende de tu memoria, pero la elección importa más de lo que parece. Una comparación KLD independiente publicada en Hugging Face encuentra diferencias apreciables incluso entre dos cuantizaciones sub-2-bit del mismo modelo. Como regla práctica, Q4_K_M es el punto habitual de equilibrio en tarjetas de 32 GB, y NVFP4 es la opción documentada por SGLang para una sola RTX 5090.

¿Con qué agentes de código funciona Qwen3.8-27B? ¶

SGLang publicó documentación específica para OpenCode, Pi, Claude Code y Hermes Agent. Ollama sacó integración de lanzamiento con OpenCode mediante ollama launch opencode --model qwen3.8 y también con Pi. llama.cpp lo soporta desde el mismo día con el GGUF de ggml-org, aprovechando la cabeza MTP del modelo para speculative decoding.

¿Merece la pena cambiarse a Qwen3.8-27B ahora mismo? ¶

Si quieres capacidad multimodal en local con licencia permisiva y ya tienes un agente montado, sí merece una prueba esta semana. Si necesitas resultados auditados o presupuesto de tiempo predecible por tarea, espera una o dos semanas: es lo que suelen tardar en asentarse las plantillas de chat, los parsers y las primeras comparaciones con variables controladas.

Fuentes ¶

• Qwen/Qwen3.8-27B — ficha oficial del modelo en Hugging Face
• Qwen3.8-27B — documentación de despliegue de SGLang
• Run Qwen 3.8 27B on AMD Ryzen AI Max and Radeon graphics cards, day 0 — AMD
• A crazy thinking model — discusión sobre el razonamiento en la ficha oficial
• Benchmark de 16 problemas difíciles en RTX 5090 con Q4_K_M — Hugging Face
• Qwen3.8-27B en una RTX Pro 6000: 140 tok/s — Hugging Face
• Benchmark KLD independiente entre cuantizaciones — unsloth/Qwen3.8-27B-GGUF
• Qwen 3.8 27B Released! Please Share Your Experience — r/LocalLLaMA
• Un modelo local haciendo one-shot de un clon de Super Mario — r/LocalLLaMA
• Qwen 3.8 27B — hilo de Hacker News
• Simon Willison’s Weblog
• Qwen3.8-27B: Specs, Benchmarks & Verdict — Kingy AI
• Qué son los modelos de pesos abiertos — Web Reactiva
• GLM-5.3: qué es, cuánto cuesta y cuándo usarlo — Web Reactiva
• Cómo usar OpenCode — Web Reactiva

🧨 Última oportunidad para recibir la dinamita que mereces sobre programación con IA el próximo domingo: Suscríbete gratis a Web Reactiva en https://webreactiva.com/newsletter