Qwen 3.6 27B: el modelo local que hace que pagar por tokens sea cosa de pringados

Por qué el modelo denso gana al MoE para desarrollo

Antes de entrar en números, hay una decisión de arquitectura que define todo lo demás: denso vs. Mixture-of-Experts (MoE).

Qwen 3.6 tiene dos sabores principales. El 27B denso activa todos sus parámetros en cada inferencia. El 35B A3B MoE activa solo una fracción por token, lo que lo hace más rápido en velocidad bruta pero introduce una trampa sutil: cuando la tarea requiere seguir instrucciones complejas y mantener coherencia a lo largo de varios pasos, el MoE tiene más margen para saltarse detalles.

Piotr Migdał lo documentó en junio de 2026 con un test concreto: generación de un clon de buscaminas hexagonal usando OpenCode y pnpm. El 27B denso produjo un paquete Node correcto con las instrucciones del gestor de dependencias respetadas, en un solo intento. El 35B A3B MoE ignoró la especificación de pnpm y devolvió un HTML suelto, sin estructura de proyecto.

La diferencia no es espectacular en un benchmark de capacidades generales. Pero en desarrollo real, donde el contexto acumula requisitos específicos de herramientas, versiones y estructura de proyecto, el modelo que sigue instrucciones sin improvisar vale más que el que responde más rápido pero se inventa el brief.

"El 27B denso es mi recomendación para inteligencia general y tareas de código. El MoE va más rápido, pero el denso piensa sin atajos." , Piotr Migdał, junio 2026

Esto no significa que el MoE sea inútil. Para tareas de respuesta rápida y contexto corto, el 35B A3B tiene su sitio. Pero si estás construyendo algo que requiere razonamiento encadenado y seguimiento de especificaciones, el denso es el que no te falla en el peor momento.

---

Los números reales: velocidad en hardware que ya existe

Aquí es donde Qwen 3.6 27B deja de ser interesante en papel y empieza a ser interesante en producción.

Según el blog de Quesma (29 de junio de 2026), en un MacBook M5 Max con 128 GB de RAM unificada, el modelo cuantizado a 8 bits rinde 32 tokens por segundo con Multi-Token Prediction (MTP) activado, usando aproximadamente 42 GB de RAM con llama.cpp. Sin MTP, la velocidad baja a 17-18 tok/s con MLX o llama.cpp estándar.

¿Qué es MTP? Es decodificación especulativa: el modelo predice varios tokens en paralelo y los verifica en un solo paso, en lugar de generarlos uno a uno. El resultado es que el throughput casi se dobla sin cambiar el modelo ni el hardware. El coste es algo más de RAM, pero 42 GB sigue siendo manejable en cualquier MacBook Pro de gama alta actual.

En comparación, DeepSeek V4 Flash llegó a 33 tok/s en el mismo hardware, pero necesitó 103 GB de RAM. El 27B usa menos de la mitad y entrega velocidades equivalentes. Para un equipo con varios desarrolladores compartiendo la misma máquina, esa diferencia de RAM es la diferencia entre el "sí" y el "no".

En el lado de GPUs NVIDIA, un usuario de Hacker News reportó 50 tok/s en una RTX 5090 con pesos Q6_K y KV cache Q4_0 vía LM Studio, usando aproximadamente 28 GB de VRAM con un contexto de 123k tokens. Según el blog de Quesma y datos de NVIDIA, las RTX PRO ofrecen hasta 3x más velocidad de generación de tokens con Qwen 3.6 usando llama.cpp frente a alternativas.

50 tok/s con 123k de contexto en una GPU de consumo. Eso ya no es "modo hobby local". Es velocidad de API en hierro propio.

---

Cómo montarlo: llama.cpp, no Ollama

El blog de Quesma hace una recomendación explícita: usa llama.cpp directamente en lugar de Ollama. No por razones técnicas de rendimiento exclusivamente, sino también por razones éticas relacionadas con cómo Ollama gestiona los modelos y su relación con los pesos originales.

El comando base para lanzar el servidor llama.cpp con Qwen 3.6 27B incluye tres flags que marcan la diferencia:

./llama-server \
-m qwen3.6-27b-q8_0.gguf \
-ngl 999 \
-fa on \
-c 65536 \
--port 8080

• -ngl 999: carga todas las capas del modelo en GPU. Sin esto, parte del modelo se queda en CPU y la velocidad cae en picado.
• -fa on: activa Flash Attention, que reduce el uso de memoria durante la atención y permite contextos más largos sin OOM.
• -c 65536: contexto de 64k tokens. Suficiente para la mayoría de tareas de desarrollo sin desperdiciar RAM en contextos que no vas a.

Con MTP activado (flag --mtp en versiones recientes de llama.cpp), se alcanza el techo de 32 tok/s en Apple Silicon.

El blog incluye también una configuración opencode.jsonc para conectar directamente OpenCode con el servidor llama.cpp local corriendo el 27B. Sin cuenta de API, sin variables de entorno que gestionar, sin factura. El endpoint local se comporta como cualquier API compatible con OpenAI.

---

Dónde está en los benchmarks y qué significa eso

Aquí hay que ser preciso, porque los benchmarks de modelos locales se exageran con facilidad.

Según Artificial Analysis, Qwen 3.6 27B tiene una puntuación de 37 en su índice de calidad, comparable a modelos de mediados de 2025 como GPT-5 o Claude Sonnet 4.5. El 35B A3B MoE puntúa 32, en la zona de principios de 2025 (o3, Claude Sonnet 4).

Para contexto: Gemma 4 31B de Google, lanzado en abril de 2026 y que también se ejecuta localmente en laptops y smartphones, queda en la franja de finales de 2024 según esos mismos datos. Gemma 4 es multimodal (texto, imágenes, audio) y rivaliza con modelos de más de 1.1 billones de parámetros en ciertos benchmarks, pero para coding puro el 27B denso de Qwen 3.6 tiene ventaja en el índice de Artificial Analysis.

¿Qué significa un índice de 37? Que en las tareas que mide Artificial Analysis (razonamiento, código, instrucción, matemáticas), el 27B se comporta como los modelos frontier de hace 12-18 meses. Para desarrollo de aplicaciones, eso es más que suficiente para el 90% de las tareas cotidianas.

Lo que no significa: que sea el mejor modelo para todo. Para tareas que requieren capacidades multimodales, Gemma 4 tiene ventaja. Para razonamiento matemático extremo o investigación de vanguardia, los modelos de 400B+ siguen ganando. El 27B es el punto dulce para desarrollo local de aplicaciones, no el modelo universal.

---

El problema real que resuelve: la sangría de tokens en producción

Hay un argumento económico que el post corto apunta pero merece desarrollarse.

Cuando un equipo de desarrollo usa APIs de modelos frontier para asistencia de código, cada token cuenta. Un desarrollador que usa Claude Sonnet 4.5 o GPT-5 para completar código, revisar PRs, generar tests y documentar funciones puede fácilmente generar 2-5 millones de tokens al mes. A los precios actuales de APIs de gama alta, eso son entre 30 y 150 dólares mensuales por desarrollador.

Escala eso a un equipo de 10 personas y estás hablando de 300-1.500 dólares al mes solo en tokens de asistencia de código, sin contar los tokens que generan los agentes automatizados que corren en CI/CD.

Un servidor llama.cpp local con Qwen 3.6 27B tiene coste marginal cero por token. El coste es el hardware y la electricidad. Pero "el hardware" no es un número abstracto, así que vale la pena ponerle cifras reales.

Qué hardware necesitas y cuánto cuesta

Apple Silicon (la opción más cómoda para desarrollo individual):

El setup documentado, MacBook M5 Max con 128 GB de RAM unificada, cuesta alrededor de 4.500-5.000 € en configuración de gama alta. Si ya tienes un M4 Pro con 64 GB (unos 2.500-3.000 €), el 27B a Q6_K con margen. El M4 Pro con 36 GB es el límite inferior: el modelo entra, pero sin RAM para el sistema operativo y el IDE trabajando en paralelo, la experiencia se degrada.

El consumo eléctrico de un MacBook M5 Max bajo carga de inferencia ronda los 40-60 W. A 0,20 €/kWh (tarifa media en España), 8 horas diarias de uso intensivo son aproximadamente 3-4 € al mes en electricidad. Irrelevante.

GPU NVIDIA (la opción para equipos o uso continuo):

Una RTX 5090 cuesta alrededor de 2.000-2.200 € en el mercado europeo actual. Con 32 GB de VRAM, el 27B a Q8_0 entero en GPU, y el rendimiento documentado es de 50 tok/s. El consumo bajo carga de inferencia ronda los 300-350 W. A 0,20 €/kWh, 8 horas diarias son unos 17-20 € al mes.

Si el presupuesto no llega a la 5090, una RTX 4090 (24 GB de VRAM, unos 1.400-1.600 € de segunda mano) puede correr el 27B a Q4_K_M o Q6_K con velocidades de 35-40 tok/s. Suficiente para uso individual.

Para un servidor compartido de equipo, el NVIDIA DGX Spark (128 GB de memoria unificada, ~3.000-4.000 €) permite correr el 35B A3B MoE o varios modelos simultáneamente. Para un equipo de 5-10 desarrolladores, el coste por za baja a 300-800 €.

El break-even real

Un desarrollador que gasta 100 $/mes en tokens de API amortiza una RTX 5090 en 20-22 meses. Un equipo de 5 personas gastando 80 $/mes cada uno amortiza un DGX Spark en 7-10 meses. A partir de ahí, el coste marginal es solo electricidad.

Para un equipo que ya tiene el hardware (MacBooks Pro de gama alta o RTX recientes), el break-even es casi inmediato.

Esto conecta directamente con la guerra del coste por token que está redefiniendo qué modelos tiene sentido en producción. El 27B denso de Qwen 3.6 es el argumento más sólido hasta ahora para que esa guerra la gane el hierro propio frente a la nube para tareas de desarrollo.

---

Las trampas que nadie menciona

Nada es gratis. Hay cuatro puntos donde el setup local con Qwen 3.6 27B puede romperse:

1. La RAM es el techo real. 42 GB para el modelo + sistema operativo + IDE + browser significa que necesitas al menos 64 GB de RAM unificada en Apple Silicon para trabajar con comodidad. En el M5 Max con 128 GB estás bien. En un M4 Pro con 36 GB, el 27B a 8 bits no sin sacrificar todo lo demás.

2. El contexto tiene precio en velocidad. A 123k tokens de contexto, los 50 tok/s de la RTX 5090 son impresionantes. Pero si usas -c 65536 en Apple Silicon con un contexto lleno, la velocidad cae. Flash Attention mitiga esto, pero no lo elimina. Para conversaciones largas con mucho contexto acumulado, la velocidad efectiva puede bajar a 15-20 tok/s.

3. Las cuantizaciones no son iguales. Q8_0 (8 bits) preserva prácticamente toda la calidad del modelo completo. Q4_0 (4 bits) es más rápida y usa menos RAM, pero en tareas de razonamiento complejo la degradación es visible. Para código, Q6_K es el equilibrio recomendado si tienes la VRAM: velocidad de Q4 con calidad cercana a Q8.

4. MTP no está en todas las versiones. Multi-Token Prediction requiere que el modelo tenga los pesos MTP incluidos en el GGUF y que tu versión de llama.cpp lo soporte. Si descargas el modelo de HuggingFace sin verificar, puedes acabar con un GGUF sin za MTP y preguntarte por qué no llegas a 32 tok/s. Verifica que el archivo incluye las capas model.lm_head adicionales antes de culpar al hardware.

---

Qwen 3.6 vs. el resto: dónde encaja de verdad

Para cerrar el cuadro, vale la pena situar el 27B en el actual de modelos locales.

Gemma 4 31B (Google, abril 2026) es la alternativa más directa para uso local. Su ventaja es la multimodalidad nativa: texto, imágenes y audio en un solo modelo. Su desventaja es que en coding puro queda por debajo del 27B en el índice de Artificial Analysis. Si tu caso de uso incluye procesamiento de imágenes o audio, Gemma 4 merece consideración seria. Si es solo código y texto, el 27B gana.

Hermes Agent de Nous Research (140.000 estrellas en GitHub en menos de tres meses, el agente más usado según OpenRouter) está optimizado para correr sobre modelos locales en GPUs NVIDIA RTX. Es agnóstico al modelo, pero su rendimiento óptimo está documentado con hardware NVIDIA, no con Apple Silicon. Para flujos agentivos continuos en hardware NVIDIA, la combinación Hermes Agent + Qwen 3.6 27B es la que más sentido tiene según los datos disponibles.

NVIDIA DGX Spark (128 GB de memoria unificada, 1 petaflop de rendimiento AI) es la opción para equipos que necesitan correr el 35B o modelos de 120B parámetros de forma continua. A 20 GB de memoria para el 35B A3B MoE, el DGX Spark puede manejar varios modelos simultáneamente. Para un equipo de desarrollo que quiere un servidor compartido de IA local, el DGX Spark + Qwen 3.6 35B es la configuración de gama alta. Para un desarrollador individual, el MacBook M5 Max + 27B es suficiente.

El punto común de todos estos escenarios es el mismo: la brecha entre lo que puedes correr localmente y lo que ofrecen las APIs de modelos frontier se ha cerrado lo suficiente como para que la decisión de nube o local ya no sea técnica. Es económica y de control de datos.

---

El setup mínimo viable para empezar hoy

Si quieres replicar el rendimiento documentado sin perder tiempo:

1. Descarga el modelo: qwen3.6-27b-q8_0.gguf desde HuggingFace. Verifica que incluye las capas MTP.
2. Compila llama.cpp con soporte Metal (Apple Silicon) o CUDA (NVIDIA). Los binarios precompilados suelen ir con retraso en features como MTP.
3. Lanza el servidor con -ngl 999 -fa on -c 65536 --mtp y el puerto que uses para tu cliente.
4. Conecta OpenCode con la config opencode.jsonc apuntando a http://localhost:8080/v1.
5. Verifica la velocidad: si no ves 30+ tok/s en Apple Silicon con contexto corto, revisa que MTP está activo y que -ngl 999 está cargando todas las capas en GPU (el log de llama.cpp lo confirma al arrancar).

Si trabajas con agentes o flujos de código más complejos, el artículo sobre el prompt no controla tu agente de IA: el harness sí explica por qué la arquitectura de control importa más que el modelo cuando las tareas se encadenan.

42 GB de RAM, llama.cpp compilado, MTP activado. Lo que pase después es tuyo, sin que nadie te pase factura por ello.