Phase 12 - Lesson 08

LLaVA-OneVision: Single-Image, Multi-Image, Video em um Único Modelo

Antes do LLaVA-OneVision (Li et al., agosto de 2024), o mundo de VLMs open-weight tinha linhagens separadas: LLaVA-1.5 para imagens únicas, modelos multi-imagem como Mantis e VILA, e modelos de vídeo como Video-LLaVA e Video-LLaMA. Cada um vencia em seu próprio benchmark e falhava nos outros. O LLaVA-OneVision propôs que um currículo de treinamento unificado poderia treinar um único modelo para dominar os três cenários, e que os efeitos emergentes de transferência de tarefas (habilidades de imagem única exportadas para vídeo, raciocínio multi-imagem exportado para imagem única) superavam a soma dos especialistas. A receita é deceptivamente simples: um orçamento de tokens visuais que permanece constante entre os cenários, além de um currículo explícito que avança de imagem única para OneVision (multi-imagem) e depois para vídeo. Esta lição analisa o orçamento, o currículo e os comportamentos emergentes.

Tipo: Build Linguagens: Python (stdlib, planejador de currículo + resolvedor de orçamento de tokens) Pré-requisitos: Phase 12 · 05 (LLaVA), Phase 12 · 06 (any-resolution) Tempo: ~180 minutos

Objetivos de Aprendizagem

• Projetar um orçamento de tokens visuais que permaneça constante para entradas de imagem única, multi-imagem e vídeo.
• Organizar um currículo de treinamento que transfira habilidades de imagem única para vídeo sem esquecimento catastrófico.
• Explicar por que um único modelo supera especialistas com o mesmo número de parâmetros quando o currículo é feito corretamente.
• Nomear as três capacidades emergentes relatadas pelo LLaVA-OneVision: raciocínio multi-câmera, prompting de conjunto de marcações (set-of-mark) e agente de captura de tela de iPhone.

O Problema

Imagem única, multi-imagem e vídeo exigem características diferentes do modelo.

Imagem única precisa de tokens de alta resolução (AnyRes, ~2880 tokens visuais) para capturar OCR e detalhes finos. Orçamento por amostra: uma imagem, 2880 tokens.

Multi-imagem precisa de várias imagens em resolução moderada (~576 tokens cada) para que o raciocínio entre imagens caiba no contexto. Orçamento por amostra: 4-8 imagens, 576 tokens cada, 2300-4600 tokens.

Vídeo precisa de muitos frames em baixa resolução (~196 tokens por frame após pooling) para capturar a dinâmica temporal. Orçamento por amostra: 8-32 frames, 196 tokens cada, 1600-6200 tokens.

Se você treinar modelos separados, escolhe um único orçamento. Se treinar um único modelo, precisa que o orçamento escale de forma sensata entre os cenários sem estourar o contexto.

Antes do OneVision, a resposta padrão era "treinar um cenário e ignorar os outros". O Video-LLaVA adaptou vídeo a um modelo de imagem com etapas adicionais de treinamento. O LLaVA-NeXT adicionou suporte a multi-imagem com divisão em blocos (tiling). Nenhum deles lidava com os três cenários de forma limpa.

O Conceito

O orçamento de tokens do OneVision

O LLaVA-OneVision escolhe um orçamento unificado de tokens visuais de aproximadamente 3000-4000 tokens por amostra, alocado de forma diferente para cada cenário:

• Imagem única: AnyRes-9 (blocos 3x3 + miniatura), cada bloco em 384 com 729 patches, pooling bilinear agressivo de 2x2 → 182 por bloco. Total: 9 * 182 + 182 = 1820 tokens. Ou AnyRes-4 com 729 por bloco = 2916 + 729.
• Multi-imagem: cada imagem em resolução moderada (384, sem blocos/tiling), 729 tokens sem pooling. Orçamento de 6 imagens → 4374 tokens.
• Vídeo: 32 frames em resolução 384 com pooling bilinear agressivo de 3x3 → 81 tokens por frame. Total: 32 * 81 = 2592 tokens.

A alocação mantém a quantidade total de tokens aproximadamente constante. O LLM nunca vê um lote (batch) que estoure seu contexto. O codificador produz uma geometria diferente por cenário, mas o LLM consome o mesmo orçamento.

O currículo em três etapas

O LLaVA-OneVision treina em três etapas:

1. SFT de imagem única (etapa SI). Todos os dados são compostos por imagem única mais texto. Treina com entrada de alta resolução AnyRes. Isso ensina percepção, OCR e compreensão detalhada. Usa dados do LLaVA-NeXT mais dados de imagem única específicos do OneVision.
2. SFT do OneVision (etapa OV). Mistura imagem única + multi-imagem + vídeo (frames amostrados uniformemente). Treina com o orçamento unificado de tokens. Isso ensina o modelo a lidar com formatos heterogêneos de lote. Sem redefinição de pesos — continua a partir da etapa SI.
3. Transferência de tarefas (etapa TT). Continua com uma mistura de tarefas específicas, normalmente mais focada em multi-imagem ou vídeo, dependendo do produto. Ajuste fino opcional para implantação.

Crítico: a ordem do currículo importa. Treinar primeiro em vídeo ou primeiro em multi-imagem resulta em um desempenho de imagem pior do que treinar primeiro em imagem única, mesmo com os mesmos dados. O artigo faz ablações explícitas disso.

Por que o currículo funciona

O treinamento em imagem única constrói a base perceptual. Os tokens de patches carregam recursos visuais detalhados; o LLM aprende a integrá-los com o texto. Multi-imagem e vídeo introduzem desafios estruturais (qual imagem é qual, o que aconteceu primeiro) que são difíceis de aprender sem uma base perceptual forte.

Se você treinar todos os cenários do zero juntos, o modelo sofre subajuste (underfitting) na percepção (dados limitados de imagem única por lote) e sobreajuste (overfitting) na estrutura (muitos dados de multi-imagem / vídeo). Resultado: um modelo que segue padrões de raciocínio entre imagens, mas é visualmente superficial.

A ordenação do currículo oferece força de percepção a partir da etapa SI e, em seguida, raciocínio composicional/temporal a partir da etapa OV, sem perder nenhum dos dois.

Habilidades emergentes em múltiplos cenários

O artigo do LLaVA-OneVision relata três capacidades emergentes:

1. Raciocínio multi-câmera. Treinado em multi-imagem + vídeo separadamente; na inferência, solicitado a raciocinar sobre uma cena de direção com várias câmeras. O modelo integra corretamente as visualizações, apesar de nunca ter visto esse formato exato no treinamento.
2. Prompting de conjunto de marcações (Set-of-mark). O usuário anota objetos em uma imagem com marcações numeradas; o modelo raciocina sobre "o que a marcação 3 está fazendo em relação à marcação 7". Não foi treinado nem em marcações nem em anotação; aprendeu a partir da combinação de alinhamento espacial (spatial grounding) + referência multi-imagem.
3. Agente de captura de tela de iPhone. O usuário fornece uma captura de tela de um iPhone e pede para planejar o próximo clique. Treinado em capturas de tela de interface de usuário (UI), vídeos de fluxos de trabalho de usuários e pares de imagens de antes/depois. Generaliza para o caso de uso de agente.

Essas não são tarefas treinadas; elas emergem da estrutura composicional do currículo.

Pooling de tokens visuais

O orçamento de tokens exige pooling. O OneVision usa interpolação bilinear na grade de patches 2D: 24x24 = 576 patches tornam-se 12x12 = 144 (fator de 2x) ou 8x8 = 64 (fator de 3x). O pooling é feito no espaço da grade de patches, não no espaço de tokens, para preservar a localidade.

A escolha do fator de pooling por cenário é, por si só, um hiperparâmetro. Menos pooling = mais tokens = representação mais rica. Mais pooling = menos tokens = cabem mais frames / imagens.

LLaVA-OneVision-1.5

A continuação de 2025 (LLaVA-OneVision-1.5, arXiv 2509.23661) é "totalmente aberta" em dados de treinamento, pesos de modelo e código. Reduz a diferença em relação aos modelos proprietários em alguns benchmarks e democratiza a receita. Mesmo currículo, mais dados, melhor LLM base. Nenhuma mudança de arquitetura.

Contraste com Qwen2.5-VL

O Qwen2.5-VL (Lição 12.09) faz escolhas diferentes. Ele usa M-RoPE e FPS dinâmico em vez de pooling fixo. Seu orçamento escala com a entrada — um vídeo de 1 minuto usa mais tokens do que um de 5 segundos. O LLaVA-OneVision fixa o orçamento e escala o pooling. Ambos funcionam; eles trocam configurabilidade por previsibilidade.

Use It

code/main.py é um planejador de orçamento e currículo para um VLM no estilo OneVision. Dado um orçamento de tokens por amostra e uma mistura de cenários alvo (por exemplo, 40% imagem única, 30% multi-imagem, 30% vídeo), ele:

• Aloca a resolução, o fator de pooling e os frames por cenário.
• Verifica se cada cenário cabe no orçamento compartilhado.
• Relata a contagem esperada de tokens, FLOPs do LLM e quais cenários estão sub-tokenizados.
• Imprime um cronograma de treinamento etapa por etapa.

Use-o para planejar um ajuste fino do OneVision ou para verificar a consistência do custo por requisição de uma implantação de VLM.

Ship It

Esta lição produz outputs/skill-onevision-budget-planner.md. Dada uma distribuição de tarefas alvo e um orçamento por amostra, ela gera o fator AnyRes, o pooling por frame, a contagem de frames de vídeo e os pesos das etapas do currículo. Use isso sempre que treinar ou ajustar um VLM de cenário unificado.

Exercícios

1. Seu produto suporta 80% imagem única, 10% multi-imagem (2-4 imagens), 10% vídeo (8-16 frames). Desenhe o orçamento de tokens. Onde você colocaria o orçamento extra que economizou ao não fazer multi-imagem pesada?

2. Leia a Seção 4.3 do LLaVA-OneVision (capacidades emergentes). Proponha uma quarta habilidade emergente que o currículo provavelmente desbloquearia, mas que o artigo não relatou.

3. Inverta a ordem do currículo — treine primeiro em multi-imagem, depois em imagem única e depois em vídeo. Preveja quais benchmarks degradam e o porquê.

4. O artigo relata benchmarks de vídeo treinados com apenas 8 frames por amostra. Isso se generaliza para vídeos de 30 segundos na inferência? O que quebra primeiro — o orçamento de tokens ou o raciocínio temporal?

5. O pooling bilinear de patches de 24x24 para 12x12 é uma redução de 4x por dimensão. Implemente o pooling em Python padrão e verifique se a média de cada bloco de 2x2 corresponde à saída bilinear.

Termos-Chave

Leituras Adicionais

• Li et al. — LLaVA-OneVision (arXiv:2408.03326)
• LLaVA-OneVision-1.5: Fully Open Framework (arXiv:2509.23661)
• Lin et al. — Video-LLaVA (arXiv:2311.10122)
• Lin et al. — VILA (arXiv:2312.07533)
• Wang et al. — Qwen2-VL (arXiv:2409.12191)