Curso / Lição 10  ·  English →
Lição 10 · Visão

Visão, com cuidado

Dar olhos ao seu modelo é tentador — e cheio de armadilhas. Imagem vira token, o encoder de visão come memória, um único print em alta resolução pode consumir milhares de tokens de contexto, e VLMs pequenos alucinam detalhes que não existem. Esta lição mostra os custos escondidos e, principalmente, o método que seguimos nesta sessão: medir 4 VLMs nas imagens reais do corpus do fundador antes de confiar em qualquer um.

122 tok/s
Qwen3-VL-30B-A3B (o vencedor, geração)
19,5 GB
RAM do vencedor (MoE, 3B ativos)
4 VLMs
testados nas imagens reais do corpus
default
Qwen3-VL agora é o @alembic/vision

01 · O custo escondido: imagem também vira token

A intuição traiçoeira da visão é achar que "uma imagem é só um anexo". Não é. No pipeline de um VLM, a imagem é fatiada em patches, cada patch passa pelo encoder de visão, e o resultado entra na janela de contexto como tokens — exatamente os mesmos tokens que o texto consome. Um único print em alta resolução pode custar milhares deles. O encoder, além disso, é peso extra de modelo carregado na memória. O diagrama abaixo segue um print do disco até o contexto.

Uma imagem → milhares de tokens (o custo que ninguém vê) print 2048×1536 fatiada em patches encoder de visão peso extra na memória (ViT + projeção) vira fluxo de tokens visuais ×1000s por imagem janela de contexto (compartilhada com o texto) imagem ocupa esta fatia sobra p/ texto ⚠ menos resolução de imagem = menos tokens gastos = mais contexto livre a regra do Ahmad: trate a resolução como um botão de custo, não como "quanto maior melhor"

O encoder é memória extra; os patches viram tokens que disputam a MESMA janela com o seu prompt. Resolução é um botão de custo.

Entrada não-textual também vira token. Encoders de visão adicionam memória. Patches de imagem consomem contexto. Uma única imagem em alta resolução pode consumir milhares de tokens.— Ahmad Osman, "LLMs 101 (2026)"

02 · A regra de ouro: avalie com amostras REAIS

VLMs pequenos alucinam detalhes visuais. A confiabilidade do OCR varia. Gráficos e tabelas continuam difíceis. Por isso a única coisa que vale para um workflow sério de documento ou imagem é testar com as suas amostras reais — nunca confiar numa demo bonita. Foi exatamente o que fizemos: rodamos os 4 candidatos nas imagens reais do corpus do fundador e medimos. O loop abaixo é o método.

O método: por que VLM pequeno engana — e como blindar a escolha demo bonita ✗ NÃO confie ponto de partida enganoso o que a demo esconde: alucina detalhes visuais OCR varia de confiança gráficos/tabelas ainda difíceis imagens reais corpus do fundador prints, ícones, texto-na-imagem meça precisão + tok/s + RAM leu o texto exato? vencedor vira o default Qwen3-VL repita por candidato — aqui foram 4 VLMs decisão = medida no SEU corpus, não a demo do README
A regra que não se negocia

Templates multimodais são mais fáceis de errar que os de texto. OCR varia. Gráficos e tabelas ainda são difíceis. Logo: para qualquer fluxo sério de documento ou imagem, avalie com amostras reais e não confie numa demo. A acurácia que importa é a sua, no seu corpus — não a do README do modelo.

03 · O benchmark: 4 VLMs nas imagens reais

Quatro candidatos, mesmas imagens do corpus, mesmo Mac. Plotamos cada um por velocidade (tok/s, eixo X) contra memória (RAM, eixo Y); o tamanho/posição conta a história. O Qwen3-VL-30B-A3B venceu: o mais rápido e o mais preciso (leu o texto exato dentro das imagens), num footprint pequeno.

Benchmark nesta sessão — velocidade (X) × memória (Y) · canto inferior-direito = melhor 0 30 60 90 120 velocidade de geração (tok/s) → 0 12 24 36 48 GB ↑ RAM (GB) — menor é melhor melhor Qwen2.5-VL-72B denso · 11 tok/s · 43,9 GB · menos preciso InternVL3-8B leve · 5,7 GB · nó de fallback diffusiongemma multimodal · 84,7 tok/s · 18,5 GB · ok ★ Qwen3-VL-30B-A3B MoE 3B ativos · 110–122 tok/s · 19,5 GB + leu o texto exato na imagem → VENCEU

Eixo X = velocidade, eixo Y = memória. O vencedor fica no canto bom (rápido e enxuto) E foi o mais preciso — a precisão não aparece no eixo, mas decidiu o empate.

ModeloTipotok/sRAMVeredicto
Qwen3-VL-30B-A3BMoE · 3B ativos110–12219,5 GBVenceu. Mais preciso; leu o texto exato dentro da imagem. Agora é o default do @alembic/vision.
Qwen2.5-VL-72Bdenso1143,9 GBMais lento e menos preciso num ícone. Tamanho não comprou acurácia.
diffusiongemmadenso · multimodal84,718,5 GBOk. É multimodal de fato; roda via mlx-vlm da branch main.
InternVL3-8Bdenso5,7 GBLeve. Bom nó de fallback quando a folga aperta.

04 · Por que o MoE de poucos ativos venceu o denso gigante

O resultado repete a lição do cérebro (Lição 04): poucos parâmetros ativos batem muitos parâmetros densos. O Qwen3-VL-30B-A3B tem 30B de parâmetros mas só ~3B ativos por token — então gera rápido (110–122 tok/s) e ocupa pouco (19,5 GB). O Qwen2.5-VL-72B é denso: cada token paga os 72B inteiros, daí 11 tok/s e 43,9 GB. Em visão, como em texto, a esparsidade é o que faz caber e correr num Mac de memória unificada.

★ Qwen3-VL-30B-A3B — MoE 30B no disco · só ~3B ativos por token roteador acende 1 de N especialistas: ativo dormindo (custo zero por token) velocidade RAM → 110–122 tok/s · 19,5 GB · cabe sobrando Qwen2.5-VL-72B — denso 72B no disco · TODOS ativos por token cada token paga o modelo inteiro: todos acesos a cada passo velocidade RAM → 11 tok/s · 43,9 GB · lento e pesado
Mesma física da Lição 04: o que importa para a velocidade num Mac unificado são os parâmetros ativos, não os parâmetros totais. Um MoE de 30B/3B-ativos lê a imagem com a inteligência de um modelo grande e a velocidade de um pequeno. Foi por isso que ele virou o default do @alembic/vision.

05 · Encaixando a visão no orçamento: swap sob demanda

O cérebro (DeepSeek q2) já ocupa ~81 GB. Co-residir a visão o tempo todo encosta nos 128 GB (Lição 08). A saída é o swap sob demanda: o DeepSeek serve normalmente; quando chega uma imagem, pausa-se o DS4 para liberar os 81 GB, carrega-se o Qwen3-VL (20 GB), descreve-se a imagem, e o DeepSeek volta. A sequência abaixo mostra o pico de RAM em cada passo — nunca cruza o teto.

Swap sob demanda — RAM por passo (teto seguro 102 GB) 1 · DS4 servindo cérebro on · :8000 DeepSeek q2 81 GB residente pico ~99 GB ✓ 🖼 2 · chega imagem tarefa de visão na fila DeepSeek ainda on decide pausar 3 · pausa DS4 libera 81 GB RAM quase livre só macOS ~18 GB pico ~18 GB ✓ 4 · carrega Qwen3-VL descreve a imagem Qwen3-VL · 20 GB 110–122 tok/s pico ~38 GB ✓ 5 · reinicia DS4 (reload mmap, segundos) → volta ao passo 1 Em nenhum passo a RAM cruza o teto: o cérebro e a visão nunca estão grandes ao mesmo tempo. Custo: alguns segundos de reload do DS4 por troca. Benefício: zero contenção, zero OOM, dentro dos 128 GB.
Por que funciona: o cérebro (81 GB) e a visão (20 GB) nunca coexistem em tamanho cheio. A cada momento só um deles está grande, então o pico real fica bem abaixo dos 102 GB seguros. É o modo default da Lição 08 aplicado à visão esporádica — você troca segundos de reload por estabilidade total.
1. Por que uma única imagem em alta resolução é cara para o contexto de um VLM?
Correto: c. Entrada não-textual também vira token; o encoder ainda é peso extra na memória. Mais resolução = mais tokens gastos = menos contexto livre. Trate a resolução como um botão de custo (Ahmad, "LLMs 101").
2. No benchmark desta sessão, por que o Qwen3-VL-30B-A3B venceu o Qwen2.5-VL-72B (denso)?
Correto: b. Mesma física da Lição 04: contam os parâmetros ATIVOS, não os totais. O denso de 72B paga o modelo inteiro por token (11 tok/s, 43,9 GB) e ainda errou um ícone. Tamanho não comprou acurácia — e a decisão veio de medir no corpus real, não de confiar numa demo.