Cómo ejecutar Qwen3.8-Flash-Next en local como agente de programación con OpenCode

Arquitectura de Qwen3.8-Flash-Next

Es un modelo MoE principal de 125B parámetros, pero solo se activan unos 6B por token. Además, incluye 51B parámetros adicionales en embeddings n-gram.

La arquitectura introduce varias ideas que Qwen está explorando para Qwen4:

• Gated DeltaNet + Qwen Sparse Attention (QSA) para un procesamiento de contexto largo más eficiente
• Conexiones residuales con compuerta para mejorar el flujo de información entre capas
• Embeddings n-gram que añaden capacidad al modelo sin exigir que todos esos parámetros se computen activamente

Fuente: Qwen 

El modelo tiene una ventana de contexto nativa de 262.144 tokens y, teóricamente, puede ampliarse hasta 1 millón de tokens con YaRN.

¿Cómo rinde Qwen3.8-Flash-Next en programación?

También es sorprendentemente sólido programando. Estos son algunos de los resultados reportados por Qwen frente a Qwen3.8-27B:

Estas son evaluaciones del propio Qwen, así que conviene tratarlas como resultados del proveedor, pero encajan bastante bien con mi experiencia usando el modelo para programar.

Preparar el servidor GPU para Qwen3.8-Flash-Next

Usé una RTX PRO 6000 con 96GB de VRAM, pero no necesitas necesariamente tanta VRAM.

De hecho, esto es una de las partes interesantes de Qwen3.8-Flash-Next. Como llama.cpp puede descargar partes del modelo a la RAM del sistema, puedes usar una GPU con menos VRAM siempre que tengas mucha RAM disponible.

La cuantización Unsloth UD-Q4_K_XL que usamos ronda los 111GB y se divide en cuatro archivos GGUF.

Para mi configuración, recomiendo tener al menos 140GB de RAM y VRAM utilizables en conjunto para que haya margen suficiente para el modelo, el contexto, la caché KV y la sobrecarga de ejecución.

Si tienes algo como una H200, podrías mantener prácticamente todo en la GPU. Yo opté por un punto intermedio. 

Empieza comprobando tu GPU:

nvidia-smi

Deberías ver tu GPU, la versión del driver, la versión de CUDA y la VRAM disponible.

Después, instala los paquetes necesarios:

sudo apt update

sudo apt install -y \
  git \
  cmake \
  build-essential \
  curl \
  libcurl4-openssl-dev \
  python3-pip

Compilar llama.cpp con soporte para Qwen3.8-Flash-Next

Qwen3.8-Flash-Next usa la nueva arquitectura qwen4_exp, que es muy distinta de simplemente cargar otro modelo Qwen3.8.

El soporte aún es muy reciente, así que utilicé la rama de Qwen3.8-Flash-Next mantenida por Unsloth en lugar de depender de un build antiguo de llama.cpp que quizá no reconozca la arquitectura. El trabajo correspondiente en llama.cpp añade la nueva arquitectura qwen4exp, QSA, embeddings n-gram y otros componentes específicos del modelo.

Ve al workspace:

cd /workspace

Clona la rama de Unsloth:

git clone \
  --branch qwen4exp/qwen3.8-flash-next \
  https://github.com/unslothai/llama.cpp.git

Entra en el directorio:

cd llama.cpp

Compila llama.cpp con CUDA:

cmake -B build \
  -DGGML_CUDA=ON \
  -DCMAKE_BUILD_TYPE=Release

cmake --build build \
  --config Release \
  -j"$(nproc)"

Por último, confirma que llama-server se compiló correctamente:

./build/bin/llama-server --version

Mi build devolvió:

version: 0.3.0-dev (build 10656, commit 035e22731)
built with GNU 13.3.0 for Linux x86_64

Descargar el modelo GGUF de Qwen3.8-Flash-Next

Descargar el modelo fue, de hecho, una de las partes más pesadas de esta configuración.

Primero probé ModelScope, pero la velocidad no era buena. En Hugging Face, la descarga empezó a buena velocidad y luego cayó de golpe a KB/s.

Hugging Face ahora usa su backend Xet para descargas de modelos grandes y normalmente activa la concurrencia adaptativa de forma automática. También proporciona HF_HUB_DISABLE_XET para desactivar Xet cuando da problemas.

En mi caso, desactivar Xet y descargar en paralelo los cuatro shards GGUF funcionó mucho mejor.

Instala la CLI de Hugging Face:

pip install -U huggingface_hub

Desactiva Xet para esta descarga:

export HF_HUB_DISABLE_XET=1
unset HF_XET_HIGH_PERFORMANCE
unset HF_XET_NUM_CONCURRENT_RANGE_GETS
unset HF_HUB_ENABLE_HF_TRANSFER

HF_HUB_ENABLE_HF_TRANSFER está ya en desuso, ya que Hugging Face ha movido las transferencias grandes a Xet.

Crea el directorio del modelo:

cd /workspace
mkdir -p Qwen3.8-Flash-Next-GGUF

Ahora descarga los cuatro shards en paralelo:

for i in 1 2 3 4; do
  shard=$(printf "%05d" "$i")

  hf download unsloth/Qwen3.8-Flash-Next-GGUF \
    "UD-Q4_K_XL/Qwen3.8-Flash-Next-UD-Q4_K_XL-${shard}-of-00004.gguf" \
    --local-dir Qwen3.8-Flash-Next-GGUF &
done

wait

El quant UD-Q4_K_XL completo ocupa aproximadamente 111GB.

Ejecutar Qwen3.8-Flash-Next con llama.cpp

Vuelve al directorio de llama.cpp:

cd /workspace/llama.cpp

Inicia el servidor:

./build/bin/llama-server \
  -m /workspace/Qwen3.8-Flash-Next-GGUF/UD-Q4_K_XL/Qwen3.8-Flash-Next-UD-Q4_K_XL-00001-of-00004.gguf \
  --alias qwen3.8-flash-next \
  --host 0.0.0.0 \
  --port 8080 \
  --ctx-size 131072 \
  --parallel 1 \
  --flash-attn on \
  --fit on \
  --fit-target 4096 \
  --jinja \
  --batch-size 1024 \
  --ubatch-size 512 \
  --temp 1.0 \
  --top-p 0.95 \
  --top-k 20 \
  --min-p 0.0

He usado deliberadamente una ventana de contexto de 131.072 tokens en lugar de los 262K nativos completos.

Para agentes de código, 131K ya es enorme y le da a OpenCode margen de sobra para archivos fuente, salidas de herramientas, logs de terminal y conversaciones largas sin malgastar aún más memoria en contexto que probablemente no use.

Los ajustes importantes aquí son:

1. --fit on permite a llama.cpp determinar automáticamente cuánto del modelo debe mantenerse en la GPU.

2. --fit-target 4096 le indica que deje alrededor de 4GB de memoria de GPU libre, lo que da algo de aire a la ejecución en lugar de ir al límite de VRAM. llama.cpp admite oficialmente el ajuste automático y un margen de memoria objetivo configurable.

3. Los parámetros de muestreo tampoco son aleatorios. Qwen recomienda temperature=1.0, top_p=0.95, top_k=20 y min_p=0.0 cuando se usa el modo de razonamiento.

Incluso tras cargar el modelo completo, me quedó bastante memoria libre: unos 13GB de VRAM disponibles para la ventana de contexto, la caché KV y otras aplicaciones.

Probar el servidor de Qwen3.8-Flash-Next con CURL

llama-server expone una API compatible con OpenAI.

Comprueba el modelo disponible:

curl http://127.0.0.1:8080/v1/models

Deberías ver qwen3.8-flash-next.

Ahora, probemos a generar una respuesta:

curl http://127.0.0.1:8080/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "qwen3.8-flash-next",
    "messages": [
      {
        "role": "user",
        "content": "Write a Python function that checks whether a number is prime."
      }
    ]
  }'

Si obtienes una respuesta válida, el servidor local está listo.

En mi configuración, inicialmente vi alrededor de 80 tokens por segundo, lo cual me sorprendió teniendo parte del modelo en la RAM del sistema.

A medida que el contexto crecía, empecé a ver velocidades más cercanas a 64 tokens por segundo.

Sigue siendo muy usable para un modelo de este tamaño, y la arquitectura ayuda a explicarlo. Aunque el modelo tiene 125B parámetros principales, solo unos 6B están activos por token.

Probar Qwen3.8-Flash-Next con la WebUI de llama.cpp

Algo que me gusta mucho de llama.cpp es que llama-server ya te da una WebUI sencilla.

Abre http://localhost:8080. Si todo está funcionando, el modelo debería estar disponible.

Para mi primera prueba en serio, le pedí que construyera de una tacada una web completa de un departamento de TI gubernamental:

Create a modern, professional government IT department portfolio website in a single index.html file.
Use HTML, CSS, and JavaScript featuring a clean official design and responsive layout with smooth animations, interactive elements, and accessible government-style navigation.
It should display department overview, key services, digital transformation projects, achievements, technology initiatives, statistics, leadership/team section, latest updates, contact information, 

Fue una generación bastante grande. El modelo dedicó muchos tokens a pensar y luego generó una web completa en un único archivo HTML. Tardó unos 13 minutos, y la velocidad bajó gradualmente a medida que crecía el contexto.

Pero el resultado fue mucho mejor de lo que esperaba.

Incluía gráficos, animaciones, pestañas, diferentes secciones, estilos responsive, interacciones en JavaScript y un diseño general sorprendentemente pulido.

Lo interesante es que fue prácticamente una generación de un solo intento. No le pedí explícitamente muchos de esos detalles.

Ahí fue cuando me di cuenta de que este modelo puede ser especialmente bueno para tareas de programación donde le das cierta libertad en lugar de especificar cada detalle de implementación.

Conectar Qwen3.8-Flash-Next a OpenCode

Chatear está bien, pero yo quería probar Qwen3.8-Flash-Next como modelo agentico para programar.

Para eso usé OpenCode. Instálalo primero:

curl -fsSL https://opencode.ai/install | bash

Reinicia tu terminal y comprueba la instalación:

opencode --version

En mi caso era la versión 1.18.23.

Ahora crea la configuración de OpenCode:

mkdir -p ~/.config/opencode

Añade el proveedor local de llama.cpp que construimos antes:

printf '%s\n' '{"$schema":"https://opencode.ai/config.json","model":"llama.cpp/qwen3.8-flash-next","provider":{"llama.cpp":{"npm":"@ai-sdk/openai-compatible","name":"Qwen3.8 Flash Next Local","options":{"baseURL":"http://127.0.0.1:8080/v1"},"models":{"qwen3.8-flash-next":{"name":"Qwen3.8 Flash Next","limit":{"context":65536,"output":32768}}}}}}' > ~/.config/opencode/opencode.json

La parte más importante es http://127.0.0.1:8080/v1. 

OpenCode admite proveedores personalizados compatibles con OpenAI a través de @ai-sdk/openai-compatible, lo que hace que conectar llama.cpp sea muy sencillo.

Configuré OpenCode con un contexto de trabajo de 65K aunque el servidor de llama.cpp tenga 131K disponibles.

Así dejo margen de sobra para salidas largas y evito que las sesiones del agente llenen demasiado rápido todo el contexto del servidor.

Usar Qwen3.8-Flash-Next como agente de programación local

Ve a un directorio de proyecto e inicia OpenCode:

cd /workspace/my-project
opencode

Ahora puedes darle tareas agenticas normales de programación. Por ejemplo, le pedí a Qwen que construyera un panel de analítica:

Build a modern system analytics and task-management dashboard. 
It should monitor CPU, RAM, VRAM, GPU usage, temperatures, disk usage, running processes, and temporary files. 
Users should be able to safely terminate tasks, free unused RAM/VRAM, clear caches, and clean temporary files from one interface.

El modelo empezó creando una lista de tareas y planificando la aplicación antes de escribir nada.

En pocos minutos generó el primer panel funcional. La primera UI no me convenció: demasiado dispersa y con varios problemas de usabilidad.

Así que simplemente le indiqué lo que no me gustaba y le pedí que reconstruyera la interfaz como un centro de control más compacto.

La segunda versión fue mucho mejor.

Terminé con un panel compacto donde podía monitorizar en tiempo real CPU, RAM, VRAM, uso de GPU, almacenamiento, actividad de red y procesos en ejecución. También añadió controles para vaciar cachés, limpiar temporales y gestionar procesos.

Lo interesante fue el enfoque de implementación. Lo probé en dos aplicaciones distintas y a menudo prefirió HTML, CSS y JavaScript básicos en lugar de instalar de inmediato React, paquetes de Node u otro framework pesado.

A mí esto me gustó. Si no especificaba un framework, intentaba encontrar la arquitectura más simple que resolviera el problema en vez de añadir dependencias innecesarias.

La pega es que se toma su tiempo. Hay mucho razonamiento, muchos tokens generados y, a veces, bastante depuración. Se nota que el modelo invierte tokens pensando el problema.

Pero los proyectos finales me resultaron bastante más completos que lo que suelo obtener con modelos locales más pequeños.

Conclusiones

Tras probar Qwen3.8-Flash-Next para generar sitios web y programación agentica, creo que está claramente por encima de Qwen3.8-27B. La mayor diferencia es cómo afronta los proyectos. Presta más atención a la estructura, los detalles y la implementación práctica en lugar de limitarse a generar código. Si te interesa ejecutar este modelo en local, lee nuestro tutorial de Qwen3.8-27B.

También me gustó que a menudo se apoyara en HTML, CSS, JavaScript y Python sencillos en lugar de sumar frameworks y dependencias innecesarias.

La principal desventaja es el tamaño. El GGUF UD-Q4_K_XL ronda los 111GB, y el modelo puede usar mucho razonamiento y tokens de salida, especialmente durante la depuración.

Por lo demás, la configuración fue sorprendentemente sencilla. Si tienes suficiente RAM y VRAM, Qwen3.8-Flash-Next es de los modelos locales para programar más potentes que he probado hasta ahora.