"Multimodal" virou termo de marketing. Quase todo modelo lançado em 2026 se descreve como multimodal. Mas há uma diferença técnica fundamental entre um modelo que aceita imagens via módulo adicionado após o treinamento e um que foi treinado com todas as modalidades desde o início. Em produção, essa diferença se manifesta em qualidade de raciocínio, coerência de resposta e, especialmente, capacidade de processar áudio e vídeo — não apenas imagens estáticas.
O Que "Nativo" Significa Tecnicamente
Modelos multimodais podem ser construídos de duas formas.
A primeira é a fusão precoce (early fusion): dados de texto, imagem, áudio e vídeo são convertidos em tokens desde o início do pipeline de treinamento. O modelo aprende representações conjuntas de todas as modalidades simultaneamente. Quando você pergunta ao modelo sobre o conteúdo de um vídeo, ele raciocina sobre vídeo da mesma forma que raciocina sobre texto — não é uma operação separada.
A segunda é a fusão tardia (late fusion): um modelo de texto recebe inputs de outros encoders como "visão" ou "áudio" como módulos adicionais. É mais fácil de construir, mas o modelo não aprende relações profundas entre modalidades durante o pré-treinamento. O resultado tende a ser raciocínio multimodal mais superficial e menor robustez quando as modalidades precisam ser integradas.
A maioria dos modelos multimodais de 2024 usava fusão tardia. Em 2026, os líderes migraram para fusão precoce — mas a adoção não é universal.
O Mapa das Capacidades em Maio de 2026
Gemini 3.1 Pro (Google): O líder atual em multimodalidade nativa completa. Processa texto, imagem, áudio, vídeo e PDF em uma janela de contexto unificada de 1 milhão de tokens. É o único modelo de fronteira que aceita todos os cinco tipos de input nativamente na mesma chamada de API. Contexto de 64K tokens de output. Custo: US$ 2,00/US$ 12,00 por milhão de tokens. GPQA Diamond: 94,3%.
GPT-5.5 (OpenAI): Texto, imagens e áudio. Suporte a vídeo é limitado — o modelo não processa vídeo diretamente como stream; extração de frames ainda é necessária para a maioria dos casos. Computer use aprimorado é o destaque da atualização de abril.
Claude Opus 4.7 (Anthropic): Texto e imagens apenas. Áudio e vídeo nativos não são suportados. O foco da Anthropic tem sido raciocínio, código e agência — não expansão multimodal. Para uso cases que requerem processamento de áudio ou vídeo, Claude não é a opção em maio de 2026.
Llama 4 Scout/Maverick (Meta): Texto e imagem via fusão precoce — o primeiro modelo aberto com MoE multimodal nativo. Vídeo e áudio não são suportados. Para modelo aberto, o nível de integração texto-imagem é superior ao que estava disponível antes.
Gemma 4 E2B/E4B (Google): Os únicos modelos open source com vídeo e áudio nativos, via fusão precoce, projetados para rodar em dispositivos edge. A limitação é o tamanho: são modelos de 2 e 4 bilhões de parâmetros efetivos, com capacidade geral mais limitada do que os modelos maiores.
Grok 4.3 (xAI): Texto, imagem e vídeo nativo — processamento direto de arquivos de vídeo sem extração de frames. Áudio não está listado como modalidade suportada. Este é um dos diferenciadores do 4.3 em relação ao 4.20.
Por Que Áudio Nativo Muda Casos de Uso
A maioria das aplicações que processa áudio hoje usa um pipeline separado: transcrição via Whisper ou equivalente, seguido de processamento de texto pelo LLM. Funciona, mas tem limitações.
A transcrição perde informação paralinguística — entonação, pausas, ênfase emocional. Um modelo com áudio nativo pode inferir humor, certeza ou hesitação diretamente da forma como algo foi dito, não apenas do que foi dito. Para análise de chamadas de atendimento ao cliente, entrevistas, reuniões, essa dimensão é relevante.
O pipeline de transcrição+texto também adiciona latência e custo. Para aplicações de tempo real — assistentes de voz, transcrição live com análise simultânea — a latência do pipeline duplo pode ser proibitiva. Modelos com áudio nativo eliminam uma etapa.
Por Que Vídeo Nativo Muda Casos de Uso
Vídeo é composto por frames (imagens) mais áudio, mais a dimensão temporal entre frames. Extrair frames e processar como imagens individuais perde o contexto temporal — o que mudou entre frame 1 e frame 100, o movimento, a sequência de eventos.
Processamento de vídeo nativo captura a dimensão temporal. Para análise de segurança (câmeras CCTV), monitoramento industrial, análise de esportes ou procedimentos médicos gravados, a sequência importa tanto quanto o frame individual.
O Gemini 3.1 Pro no contexto de 1 milhão de tokens pode processar vídeos longos, não apenas clips curtos. Para revisão de documentação em vídeo, análise de treinamentos ou auditorias de processo, isso abre casos de uso que antes exigiam análise humana completa.
A Fronteira de 2026: Vídeo em Tempo Real
O que ainda não existe em nenhum modelo comercialmente disponível de forma confiável em maio de 2026 é processamento de vídeo ao vivo — stream de câmera em tempo real com raciocínio simultâneo.
Há demonstrações técnicas e previews em alguns laboratórios. Mas para produção estável, a fronteira atual é vídeo gravado, não stream ao vivo. Para IoT industrial com câmeras em tempo real, ainda há dependência de pipelines híbridos com processamento especializado de visão computacional antes do LLM.
Essa é a próxima barreira — e a corrida para ultrapassá-la já está em andamento.
Eu defendo armazenamento e distribuição local de mídia. Por isso faço experimentos com IPFS. Em particular envolvendo ffmpeg e HLS.
Um dos meus experimentos clássicos envolvia transformar quase qualquer formato de vídeo em um HLS de 4 resoluções(360p,480p,720p e 1080p), para que o browser pudesse baixar o m3u8 contendo os fluxos, o m3u8 de cada fluxo e os ts com os pedaços de vídeo de cada fluxo. Não sei se já existe suporte nativo nos browsers para HLS, apesar de quase todo mundo usar esse formato.
O que eu gosto nele é justamente que o player do browser é capaz de mudar a resolução no meio da reprodução, baixando um conjunto de ts mais pesados ou mais leves, dependendo do caso. Fora que o ffmpeg tem um mecanismo que recebe um fluxo de vídeo por rtmp ou rtsp e fica modificando o m3u8 periodicamente com fluxos parciais, fazendo com que o browser fique baixando e descartando arquivos ts para exibir uma única vez, se atualizando periodicamente com os m3u8 para saber quais ts baixar.
O grande problema do HLS é que não dá pra baixar(facilmente) os vídeos exibidos nos sites, uma vez que eles estão separados em múltiplos cabeçalhos m3u8 e diversos fragmentos TS. Mas pelo menos tem muitas bibliotecas Javascript para exibir fluxos HLS no browser.
Já faço uso do IPFS para armazenar todos os m3u8 e ts de vídeos completos em HLS, mas minha dúvida seria sobre a possibilidade de, para poder fazer um fluxo contínuo, ficar publicando os TS em tempo real no IPFS, atualizando apenas os m3u8 do fluxo com os CIDs dos tss alimentados no IPFS.
O que eu descrevi acima:
Tecnologia usada tanto para transmitir vídeos completos(como arquivos mp4) quanto transmissões em tempo real(como rtsp ou rtmp) de um servidor para múltiplos browsers de forma que cada um seja capaz de selecionar a resolução manualmente ou automaticamente dependendo da conexão.