Executei o Qwen3.8-Flash-Next no Strata e pedi ao OpenCode para criar três projetos

Num PC Windows com uma RTX 4090, executei o modelo aberto MoE de 125B «Qwen3.8-Flash-Next» através do Strata e experimentei usá-lo como agente de implementação no OpenCode.

Testei três projetos: um jogo 3D em Three.js, uma aplicação Web mais prática e 30 segundos de motion graphics. A conclusão, antecipando-a, é: o jogo e a aplicação Web foram bem-sucedidos. O vídeo foi gerado, mas a qualidade visual ainda deixa muito a desejar.

Isto não é um benchmark rigoroso, mas sim um teste de trabalho real bastante subjetivo.

Ambiente de execução

Item	Configuração
GPU	NVIDIA GeForce RTX 4090 24GB
CPU	Intel Core i7-13700K (16 núcleos / 24 threads)
RAM	64GB
SO	Windows 11 Pro
Inferência	Strata v0.1.40.2 / Qwen3.8-Flash-Next IQ2_XS
Contexto	262.144 tokens
Agente de programação	OpenCode v1.17.13

O modelo em si ocupa cerca de 70GB. Na 4090, respostas curtas foram geradas a cerca de 86–108 tok/s, e até prompts longos de 32K a 128K foram carregados a aproximadamente 4.400–5.000 tok/s. Também consegui processar, na prática, 255K tokens.

No entanto, a maior limitação foi a RAM, não a VRAM. Como o Strata consome bastante memória, torna-se muito apertado executar Docker, builds do Next.js e Playwright simultaneamente na mesma máquina com 64GB. Para desenvolver seriamente em paralelo, penso que 96GB ou mais — ou separar o PC de inferência do PC de desenvolvimento — é uma opção mais realista.

1. Jogo 3D em Three.js: sucesso

Para começar, pedi-lhe que criasse uma versão 3D de Lights Out, com um tabuleiro 3×3×3, em Three.js. O prompt foi enviado apenas uma vez e incluía néon, bloom, efeitos sonoros, interface em japonês e inglês, Undo e animação de conclusão de nível.

A stack técnica é um único ficheiro HTML com Three.js. São 559 linhas de implementação que reúnem renderização, pós-processamento, Web Audio e controlos de rato. Foram gerados cerca de 31.000 tokens e demorou aproximadamente 5 minutos.

Ao verificar no Chrome headless, não houve erros de JavaScript. Os cliques, a rotação da perspetiva e a conclusão do nível funcionaram de facto.

Houve uma falha: a forma de criar o tabuleiro diferia entre a geração de níveis e o reset. Ainda assim, como qualquer configuração neste tabuleiro 3×3×3 é matematicamente solucionável, o jogo nunca fica bloqueado.

• Taxa de sucesso subjetiva: 90%
• Tempo necessário: cerca de 5 minutos
• Avaliação: muito bom para uma geração de uma só vez. Tanto o aspeto como o funcionamento já resultam plenamente numa «obra»

2. Aplicação Web com funcionalidades razoáveis: sucesso

A seguir, criei o «ORBIT», uma consola de gestão de reservas para um estúdio. Não se trata apenas de um dashboard: pedi-lhe uma aplicação Next.js com 12 ecrãs e cerca de 5.700 linhas.

A stack técnica inclui Next.js 16.4 (App Router / TypeScript), Tailwind CSS, Prisma 6.19, SQLite, recharts, date-fns, zod, jose e bcryptjs. Foram implementados login, calendários mensal, semanal e diário, gestão de reservas, clientes, salas, equipa, faturas, relatórios e definições.

O desenvolvimento autónomo inicial demorou 62 minutos. Contudo, 37 desses minutos foram passados num smoke test que não terminava, pelo que o tempo de trabalho efetivo do LLM foi de cerca de 25 minutos. Os 12 ecrãs ficaram prontos 26 minutos após o início. Só no desenvolvimento inicial foram gerados 157.000 tokens.

Na verificação final, 24 de 25 itens E2E passaram. TypeScript, build, Lint e smoke test também passaram. Das oito correções pedidas, sete foram resolvidas.

Por outro lado, apesar de ainda haver erros de Lint na primeira execução, o agente declarou que «todas as condições passaram». Também ficou um caso de deslocamento horizontal na versão móvel. Não se deve confiar cegamente na autoavaliação: é necessário ter uma verificação independente.

Outra falha foi a configuração PostgreSQL + Docker. Com 64GB de RAM, não havia margem para executar simultaneamente Strata, Docker e o build, pelo que acabei por mudar para SQLite. O agente também foi encerrado à força duas vezes por falta de memória.

• Taxa de sucesso subjetiva: 95%
• Tempo necessário: cerca de 62 minutos (cerca de 25 minutos de trabalho efetivo) + cerca de 30 minutos de correções
• Avaliação: pelo menos, parece capaz de criar aplicações Web comuns de ponta a ponta

3. Vídeo de motion graphics: geração bem-sucedida, qualidade ainda insuficiente

Por fim, fiz um motion graphic 4K de 30 segundos sincronizado com música: «STRATA // SIGNAL».

A stack técnica inclui Python, Skia, NumPy, SciPy, Pillow e FFmpeg. Além do vídeo, a música algorítmica de 128 BPM e 16 compassos também foi gerada em código. O ficheiro final tem 3840×2160, 30fps, 900 fotogramas e 30,000 segundos. O áudio é estéreo a 48kHz e -14 LUFS.

Desde o início até ao resultado final em 4K, demorou cerca de uma hora e meia. Pelo caminho, houve uma sessão que repetiu o mesmo raciocínio até ao limite de saída de 32K, outra em que o OpenCode ficou parado durante 13 minutos após iniciar e um encerramento por falta de memória durante o render final. O render em 4K propriamente dito demorou cerca de 11 minutos e meio.

Como ficheiro de vídeo, está funcional. Mas os anéis de néon e os streaks que tinha especificado quase não se veem em 4K, e o conjunto está demasiado escuro. O ruído granulado é forte, as mudanças de cena são fracas e a sincronização entre imagem e batida é difícil de perceber. É positivo ter conseguido chegar autonomamente a 30 segundos em 4K com áudio, mas é difícil considerar a qualidade criativa aprovada.

• Taxa de sucesso subjetiva: 50%
• Tempo necessário: cerca de uma hora e meia
• Avaliação: consegue criar o pipeline de geração. Mas a composição visual exige revisão humana e várias rondas de correções

Conclusão: provavelmente o modelo aberto mais forte até agora que funciona numa RTX 4090

É uma avaliação extremamente subjetiva, mas, entre os modelos open source que podem correr numa RTX 4090, o Qwen3.8-Flash-Next é provavelmente o mais forte que já experimentei.

Destaca-se sobretudo no desenvolvimento de aplicações Web. Ao receber uma especificação, consegue planear, implementar e avançar por todo o processo, incluindo build e testes, numa aplicação com muitos ecrãs. Naturalmente, não se deve acreditar apenas quando diz «está feito»; uma validação independente é essencial. Ainda assim, é sinceramente impressionante conseguir fazer tanto apenas com um modelo local.

Em termos de sensação, tem uma utilidade parecida com a do Sonnet — já não me lembro da versão — numa altura em que o Opus ainda era caro demais para usar sem pensar duas vezes. O jogo também ficou bastante bom. Por outro lado, tarefas como motion graphics, nas quais há uma grande distância entre o código funcionar e a obra ser artisticamente boa, ainda precisam de ser mais testadas.

E, desta vez, o maior problema não foi a inteligência do modelo, mas os 64GB de RAM.

Os LLMs locais estão mesmo a evoluir.