Desenvolvedor dá visão local ao z.ai GLM-5.1: modelo de 8B fecha 70% da distância para os modelos de fronteira

Um desenvolvedor mostrou como eliminar uma das principais fraquezas dos modelos de código baratos: a cegueira em relação à própria UI. Para o z.ai GLM-5.1, ele montou um vision-sidecar local que lê screenshots e devolve a estrutura da interface em JSON. Com isso, o agente pode verificar o resultado sozinho depois de gerar o código.

Qual era o problema

O problema é conhecido por quase todo mundo que já testou modelos econômicos no lugar de sistemas frontier caros. O agente consegue escrever o HTML, subir a página, rodar o Playwright e salvar um screenshot, mas aí bate na parede: a imagem existe, só que não há compreensão. Se um botão saiu do lugar, uma tabela ficou cortada, o texto invadiu um card ou o grid mobile quebrou, o modelo não percebe. No fim, uma pessoa volta a checar a interface manualmente e, em vez de definir tarefas, vira um QA permanente entre as iterações.

O autor partiu de uma hipótese simples: esse tipo de feedback não exige o sistema multimodal mais poderoso do mercado. Em screenshots de interfaces web, o que costuma importar não é raciocínio abstrato, e sim extração de fatos: OCR, lista de botões, estrutura de blocos, presença de cortes e correção das tabelas. Se isso for verdade, um modelo de visão aberto e compacto pode virar uma camada sensorial barata para o agente de código e fechar o ciclo "escreveu -> olhou -> corrigiu" sem API na nuvem.

Como o pipeline foi montado

A visão ficou a cargo do qwen3-vl:8b, rodando localmente via Ollama. Em cima dele, o autor montou o servidor MCP vision-sidecar-mcp, que recebe screenshots e devolve uma descrição estruturada da tela. Essa camada não transforma o GLM-5.1 em um modelo multimodal completo, mas entrega o que faltava no desenvolvimento prático: a capacidade de ler o resultado visual do próprio trabalho por meio de uma interface de texto. Segundo o autor, em uma GPU comum ou em Apple Silicon, todo o esquema fica de pé em cerca de 20 minutos.

• qwen3-vl:8b como modelo de visão local
• Ollama para deploy rápido
• Servidor MCP com os métodos analyze_image, analyze_structured e extract_table
• Respostas em JSON que podem ir direto para o agente de código

A parte de engenharia decisiva não estava no fine-tuning dos pesos, e sim no ajuste da inferência. O autor fixou o seed, endureceu o sampling com top_p=0.9 e top_k=20 e passou as respostas para um schema JSON estrito. Um campo separado para símbolos e ícones ajudou a eliminar erros típicos de reconhecimento, em que glyphs decorativos eram lidos de forma incorreta. A conclusão é importante: quando a tarefa se resume a extrair estrutura, um bom prompt, um schema e disciplina na geração às vezes rendem mais do que partir direto para o fine-tuning.

Quais foram os números

O teste foi feito com dez screenshots de uma aplicação web real, de uma tela mobile pequena de 320×568 até um desktop de 1440×900. Foram comparados três modos: o qwen3-vl:8b base, o mesmo modelo após o ajuste e o Claude Opus 4.7 como teto de referência. A nota média subiu de 3,99 para 4,70 de 5, e a distância para o modelo de fronteira caiu de 1,01 para 0,30. Ou seja, o modelo local de 8B fechou cerca de 70% da defasagem sem fine-tuning e sem dados adicionais.

"O ciclo de testes está fechado. O modelo não é mais cego."

Depois do ajuste, o conjunto chegou quase à paridade nos pontos que importam para a verificação prática da interface pelo agente:

• OCR e extração precisa de texto
• detecção de elementos de UI e CTA
• compreensão da estrutura do layout
• extração de tabelas e adequação para processamento automático posterior

A principal distância ainda não resolvida envolve alucinações e nuances visuais. O modelo local podia confundir tons de cor, interpretar errado pequenos elementos decorativos e captava pior a intenção do design, sobretudo quando a própria cor indica status ou prioridade. Mas, para tarefas como checar clipping, presença de CTA, correção de tabelas e estrutura das seções, isso não parece um impeditivo: ele já consegue detectar erros críticos de interface de forma suficientemente confiável e previsível.

O que isso significa

A conclusão prática é simples: os modelos frontier caros continuam úteis como camada de verificação para casos complexos, mas a maior parte das iterações de UI já pode ficar com um conjunto local formado pelo modelo de código, screenshots e um modelo de visão compacto. O próximo passo lógico é o routing: telas simples são processadas localmente, enquanto as duvidosas seguem automaticamente para um modelo mais forte ou para uma pessoa. Para equipes que controlam o orçamento de inferência e querem mais autonomia no desenvolvimento front-end, isso já não parece um experimento, e sim um esquema funcional.