Como executar o Qwen3.8-Flash-Next localmente como um agente de código com OpenCode

Arquitetura do Qwen3.8-Flash-Next

É um modelo MoE principal com 125B de parâmetros, mas apenas cerca de 6B de parâmetros são ativados por token. Ele também inclui 51B adicionais em embeddings de n-gramas.

A arquitetura apresenta várias ideias que a Qwen está explorando para o Qwen4:

• Gated DeltaNet + Qwen Sparse Attention (QSA) para processamento de contexto longo mais eficiente
• Conexões residuais com gate para melhorar o fluxo de informação entre camadas
• Embeddings de n-gramas que aumentam a capacidade do modelo sem exigir que todos esses parâmetros sejam computados ativamente

Fonte: Qwen 

O modelo tem uma janela de contexto nativa de 262.144 tokens e pode ser estendida teoricamente para 1 milhão de tokens usando YaRN.

Como o Qwen3.8-Flash-Next se sai em programação?

Ele também é surpreendentemente forte em código. Estes são alguns resultados relatados pela própria Qwen, comparados com o Qwen3.8-27B:

Essas são avaliações da própria Qwen, então eu ainda trataria como resultados reportados pelo fornecedor, mas elas batem bem com a minha experiência usando o modelo para programação.

Preparando o servidor com GPU para o Qwen3.8-Flash-Next

Usei uma RTX PRO 6000 com 96GB de VRAM, mas você não precisa necessariamente de tanta VRAM.

Esse é, na verdade, um dos pontos interessantes do Qwen3.8-Flash-Next. Como o llama.cpp pode descarregar partes do modelo para a RAM do sistema, você pode usar uma GPU com menos VRAM, desde que tenha bastante RAM disponível.

A quantização Unsloth UD-Q4_K_XL que estamos usando tem cerca de 111GB e é dividida em quatro arquivos GGUF.

Para o meu setup, eu recomendaria ter pelo menos 140GB somados de RAM e VRAM utilizáveis para garantir espaço suficiente para o modelo, contexto, KV cache e overhead de runtime.

Se você tiver algo como uma H200, pode manter praticamente tudo na GPU. Eu preferi um meio-termo.

Comece verificando sua GPU:

nvidia-smi

Você deve ver sua GPU, versão do driver, versão do CUDA e VRAM disponível.

Em seguida, instale os pacotes necessários:

sudo apt update

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

Compilando o llama.cpp com suporte ao Qwen3.8-Flash-Next

O Qwen3.8-Flash-Next usa a nova arquitetura qwen4_exp, que é bem diferente de simplesmente carregar outro modelo Qwen3.8.

O suporte ainda é muito recente, então usei o branch do Qwen3.8-Flash-Next mantido pela Unsloth em vez de depender de um build antigo do llama.cpp que talvez não reconhecesse a arquitetura. O trabalho correspondente no llama.cpp adiciona a nova arquitetura qwen4exp, QSA, embeddings de n-gramas e outros componentes específicos do modelo.

Vá para o workspace:

cd /workspace

Clone o branch da Unsloth:

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

Entre no diretório:

cd llama.cpp

Compile o llama.cpp com CUDA:

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

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

Por fim, confirme que o llama-server foi compilado corretamente:

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

Meu build retornou:

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

Baixando o modelo GGUF do Qwen3.8-Flash-Next

Baixar o modelo foi, na verdade, uma das partes mais chatas deste setup.

Primeiro tentei o ModelScope, mas a velocidade não foi boa. No Hugging Face, o download começou rápido e, de repente, caiu para a casa dos KB/s.

O Hugging Face agora usa o backend Xet para downloads de modelos grandes e normalmente ativa a concorrência adaptativa automaticamente. Ele também oferece a variável HF_HUB_DISABLE_XET para desabilitar o Xet quando isso causa problemas.

No meu caso, desabilitar o Xet e baixar os quatro shards do GGUF em paralelo funcionou bem melhor.

Instale o CLI do Hugging Face:

pip install -U huggingface_hub

Desabilite o Xet para este download:

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 agora está obsoleto, já que o Hugging Face migrou grandes transferências para o Xet.

Crie o diretório do modelo:

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

Agora, baixe os quatro shards em 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

O quant UD-Q4_K_XL completo tem aproximadamente 111GB.

Executando o Qwen3.8-Flash-Next com o llama.cpp

Volte ao diretório do llama.cpp:

cd /workspace/llama.cpp

Inicie o 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

Eu deliberadamente usei uma janela de contexto de 131.072 tokens em vez do contexto nativo completo de 262K.

Para agentes de código, 131K já é enorme e dá bastante espaço no OpenCode para arquivos-fonte, saídas de ferramentas, logs de terminal e conversas longas, sem desperdiçar ainda mais memória com contexto que provavelmente não vou usar.

As configurações importantes aqui são:

1. --fit on permite que o llama.cpp determine automaticamente quanto do modelo deve ficar na GPU.

2. --fit-target 4096 indica para deixar cerca de 4GB de memória da GPU livres, o que dá um fôlego ao runtime em vez de operar colado no limite de VRAM. O llama.cpp suporta oficialmente o ajuste automático e uma margem-alvo de memória configurável.

3. As configurações de amostragem também não são aleatórias. A Qwen recomenda temperature=1.0, top_p=0.95, top_k=20 e min_p=0.0 ao usar o modelo em modo de raciocínio.

Mesmo após carregar o modelo completo, ainda sobrou bastante memória, com cerca de 13GB de VRAM disponíveis para a janela de contexto, KV cache e outros aplicativos.

Testando o servidor Qwen3.8-Flash-Next com CURL

O llama-server expõe uma API compatível com OpenAI.

Confira o modelo disponível:

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

Você deve ver qwen3.8-flash-next.

Agora, vamos testar a geração de uma resposta:

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."
      }
    ]
  }'

Se você receber uma resposta válida, o servidor local está pronto.

No meu setup, inicialmente vi cerca de 80 tokens por segundo, o que me surpreendeu, considerando que parte do modelo estava na RAM do sistema.

Conforme o contexto aumentou, as velocidades caíram para algo próximo a 64 tokens por segundo.

Ainda assim, isso é extremamente utilizável para um modelo desse tamanho, e a arquitetura ajuda a explicar o porquê. Embora o modelo tenha 125B de parâmetros principais, apenas cerca de 6B ficam ativos por token.

Testando o Qwen3.8-Flash-Next com a WebUI do llama.cpp

Uma coisa que eu curto no llama.cpp é que o llama-server já traz uma WebUI simples.

Abra http://localhost:8080. Se tudo estiver rodando corretamente, o modelo já deve aparecer.

Para meu primeiro teste pra valer, pedi que construísse, de uma vez, um site completo para um departamento de TI do governo:

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, 

Foi uma geração bem grande. O modelo gastou muitos tokens "pensando" e depois gerou um site inteiro em um único arquivo HTML. Levou cerca de 13 minutos para finalizar, e a velocidade foi caindo conforme o contexto crescia.

Mas o resultado ficou bem melhor do que eu esperava.

Incluiu gráficos, animações, abas, seções diferentes, estilo responsivo, interações em JavaScript e um layout geral surpreendentemente polido.

O interessante é que foi praticamente uma geração one-shot. Eu não pedi explicitamente para adicionar muitos desses detalhes menores.

Foi aí que percebi que esse modelo pode ser especialmente bom para tarefas de programação em que você dá certa liberdade, em vez de especificar cada detalhe de implementação.

Conectando o Qwen3.8-Flash-Next ao OpenCode

Bater papo é legal, mas eu queria mesmo testar o Qwen3.8-Flash-Next como um modelo agentic de codificação.

Para isso, usei o OpenCode. Instale primeiro:

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

Reinicie o terminal e confira a instalação:

opencode --version

No meu caso, era a versão 1.18.23.

Agora crie a configuração do OpenCode:

mkdir -p ~/.config/opencode

Adicione o provider local do llama.cpp que compilamos 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

A parte mais importante é http://127.0.0.1:8080/v1. 

O OpenCode suporta provedores personalizados compatíveis com OpenAI via @ai-sdk/openai-compatible, o que torna a conexão com o llama.cpp muito simples.

Defini o OpenCode com um contexto de trabalho de 65K, embora o servidor do llama.cpp tenha 131K disponíveis.

Isso deixa bastante folga para saídas longas e evita que sessões de agente ocupem o contexto inteiro do servidor agressivamente.

Usando o Qwen3.8-Flash-Next como um agente local de codificação

Navegue até o diretório do projeto e inicie o OpenCode:

cd /workspace/my-project
opencode

Agora você pode passar tarefas normais de agente de codificação para o modelo. Por exemplo, pedi ao Qwen para construir um dashboard de analytics:

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.

O modelo começou criando uma lista de tarefas e planejando o aplicativo antes de escrever tudo.

Em poucos minutos, ele produziu o primeiro dashboard funcional. Eu não curti muito a primeira UI. Parecia muito espaçada e havia vários problemas de usabilidade.

Então simplesmente disse ao agente o que não gostei e pedi para reconstruir a interface como um centro de comando mais compacto.

A segunda versão ficou bem melhor.

Terminei com um dashboard compacto onde pude monitorar CPU, RAM, VRAM, uso de GPU, armazenamento, atividade de rede e processos em execução em tempo real. Também adicionou controles para limpar caches, remover arquivos temporários e gerenciar processos.

O interessante foi a abordagem do Qwen para a implementação. Testei em duas aplicações diferentes e ele frequentemente preferiu HTML, CSS e JavaScript puros em vez de instalar imediatamente React, pacotes Node ou outro framework pesado.

Eu curti esse comportamento. Quando eu não especificava um framework, ele buscava a arquitetura mais simples que resolvesse o problema, em vez de adicionar dependências desnecessárias.

O lado negativo é que ele leva seu tempo. Há muito raciocínio, muitos tokens gerados e, às vezes, bastante depuração. Dá pra sentir o modelo gastando tokens pensando no problema.

Mas os projetos finais geralmente pareceram muito mais completos do que o que costumo obter de modelos locais menores.

Considerações finais

Depois de testar o Qwen3.8-Flash-Next para geração de sites e codificação agentic, acho que ele dá um salto claro em relação ao Qwen3.8-27B. A maior diferença é a forma como aborda projetos. Ele presta mais atenção à estrutura, aos detalhes e à implementação prática, em vez de apenas cuspir código. Se você quer rodar esse modelo localmente, leia nosso tutorial do Qwen3.8-27B.

Também gostei de ver que ele muitas vezes recorre a HTML, CSS, JavaScript e Python simples, em vez de adicionar frameworks e dependências sem necessidade.

O principal ponto negativo é o tamanho. O GGUF UD-Q4_K_XL tem cerca de 111GB, e o modelo pode usar muito raciocínio e tokens de saída, especialmente durante a depuração.

Fora isso, o setup foi surpreendentemente simples. Se você tem RAM e VRAM suficientes, o Qwen3.8-Flash-Next é um dos modelos locais de codificação mais fortes que testei até agora.