Apertus 1.5: Como a Swiss AI Integra Imagem e Áudio sem Vision Encoder

A novidade aqui não é mais um modelo multimodal. É como esse modelo virou multimodal. O time do Apertus trocou o caminho padrão, acoplar um vision encoder tipo CLIP ao transformer, por algo mais radical: tratar pixel e áudio como se fossem subpalavras, no mesmo vocabulário do texto. Vale entender a mecânica, porque ela decide o que o modelo consegue e o que ele nunca vai conseguir.

O que foi lançado

A Swiss AI Initiative lançou o Apertus 1.5, um pré-treinamento continuado dos modelos de 8B e 70B parâmetros do Apertus 1.0, adicionando entendimento multimodal nativo de imagem e áudio, um modo de reasoning (thinking mode), janela de contexto de 262k tokens e melhor instruction-following e uso de ferramentas. Os modelos continuam totalmente abertos: pesos abertos sob Apache 2.0, dados abertos, detalhes de treino publicados e checkpoints intermediários disponíveis em pretraining, SFT, RLVR e DPO. Os pesos foram publicados no Hugging Face em 24 de julho de 2026.

O que diferencia esta versão não é tamanho nem benchmark, é a abordagem arquitetural para multimodalidade. É isso que a próxima seção explica.

Como funciona: multimodalidade pelo tokenizer, não pelo encoder

A rota padrão para fazer um LLM enxergar é anexar um vision encoder (quase sempre CLIP ou um derivado) que converte a imagem em uma sequência de embeddings contínuos, e então projetar esses embeddings no espaço de embeddings do transformer. Dois subsistemas acoplados, com objetivos de treino diferentes.

O Apertus 1.5 faz outra coisa. A multimodalidade entra em modo early-fusion: imagens e áudio chegam ao Apertus como tokens discretos, na mesma sequência dos tokens de texto, em vez de passar por um vision encoder separado. Imagens são tokenizadas com o tokenizer Emu3.5 (uma imagem de 512×512 vira 1.024 tokens) e áudio com o WavTokenizer (40 tokens por segundo). O vocabulário é estendido, a arquitetura fica inalterada e o treino roda na velocidade do treino só com texto. O modelo entende imagens e áudio, mas gera apenas texto.

Uma analogia que ajuda, e onde ela quebra

Pense num teclado estrangeiro. Se você quer um PC brasileiro digitando japonês, tem duas opções: plugar um dispositivo extra que capta kanji e envia para a CPU através de um canal próprio (isso é o vision encoder), ou expandir o layout do teclado para incluir as teclas japonesas, de modo que o sistema operacional continue vendo tudo como teclas pressionadas, sem saber se são latinas ou kanji. O Apertus escolheu o segundo caminho: para o transformer, não existe diferença entre um token de palavra e um token de um pedaço de 16×16 pixels. Tudo é posição no vocabulário.

A analogia quebra num ponto importante: tokens de texto são linguisticamente motivados (subpalavras BPE), enquanto tokens visuais são códigos de um codebook treinado para reconstruir pixel. O tokenizer adotado é treinado só com objetivo de reconstrução de pixel, não com um objetivo de alinhamento semântico ou de imagem-texto como o usado em vision encoders tipo CLIP. Os códigos discretos pré-treinados são usados diretamente como entrada e alvo de predição para o modelo de linguagem. Ou seja, cada token visual carrega informação sobre como reconstruir aquela região, não sobre o que ela significa. O alinhamento semântico é problema do transformer, aprendido durante o pré-treinamento continuado.

O que acontece com um 512×512 na prática

O tokenizer mapeia cada bloco de 16×16 pixels para um código vindo de um codebook de 131.072 entradas, de dimensão 256. Faz a conta: 512 dividido por 16 dá 32, logo 32 por 32 igual a 1.024 blocos, e cada bloco vira um token. Isso bate com o número da release.

Áudio funciona parecido. O WavTokenizer emite um código por frame, então áudio entra no modelo como uma única sequência plana, exatamente como texto. Esse fluxo de código único é o critério decisivo, porque deixa a pilha de treino inalterada.

Por que isso importa de verdade: adicionar um encoder separado te força a desenhar um loop de treino com dois ritmos, dois gradientes e dois objetivos. Estendendo só o vocabulário, o loop continua sendo um loop de next-token prediction. É a mesma mecânica do GPT original, apenas com um dicionário maior.

O pipeline em quatro estágios de pré-treino

O modelo não aprende tudo de uma vez. Dados não pareados introduzem as novas modalidades, dados pareados de imagem-caption e áudio-transcript alinham essas modalidades com a linguagem, um estágio de cooldown enfatiza dados de maior qualidade em matemática e código, e um estágio de contexto longo expande a janela passo a passo de 8.000 para 262.000 tokens. Mais da metade dos tokens de treino permanece como texto puro para preservar a capacidade linguística.

O pós-treino tem cinco estágios: SFT, SFT de contexto longo, RLVR (reinforcement learning com recompensas verificáveis), DPO e SDPO para alinhamento com a Charter. O detalhe interessante aqui está nas trajetórias de uso de ferramenta: só entram no SFT trajetórias cuja execução foi verificada, o que corta drasticamente o volume de dados ruidosos de agentes.

O que isso significa na prática

Para quem vai usar, três consequências práticas saem direto do mecanismo:

• Entra multimodal, sai só texto. O modelo não desenha, não gera áudio, não produz imagem. Se o seu caso de uso é geração visual, Apertus 1.5 não serve. Ele serve para interpretar documento, chart, foto, fala.
• Imagem come contexto rápido. 1024 tokens por 512×512. Dez screenshots já são 10 mil tokens antes de o seu prompt entrar. A janela de 262k parece generosa até você meter PDFs digitalizados dentro.
• Áudio longo é caro. 40 tokens por segundo significa que um áudio de 10 minutos custa 24 mil tokens de entrada. Transcrição por Whisper mais texto no Apertus pode sair mais barato que mandar o áudio direto, dependendo do caso.

Para rodar o modelo texto, o caminho via Transformers é o padrão da família. Baseado na model card:

from transformers import AutoModelForCausalLM, AutoTokenizer

model_name = "swiss-ai/Apertus-v1.5-8B"
tokenizer = AutoTokenizer.from_pretrained(model_name)
model = AutoModelForCausalLM.from_pretrained(model_name, device_map="auto")

messages = [{"role": "user", "content": "Explique recursão."}]
text = tokenizer.apply_chat_template(messages, tokenize=False, add_generation_prompt=True)
inputs = tokenizer([text], return_tensors="pt").to(model.device)
out = model.generate(**inputs, max_new_tokens=512)
print(tokenizer.decode(out[0][inputs.input_ids.shape[1]:], skip_special_tokens=True))

Para a entrada multimodal, o pipeline exige o processor do apertus-omni-tokenizer, publicado junto no repositório swiss-ai. A API de imagem/áudio deles ainda está mais crua que a de texto, e o Quickstart no repo é mais confiável que os snippets de terceiros circulando.

Em projetos onde já trabalhei com geração ancorada em dado estruturado real, com validação antes da publicação, em vez de texto solto, um modelo que entende imagem como tokens discretos tem um charme específico: você consegue debugar o que o modelo “viu” olhando o ID do token, igual você olha um token BPE suspeito. Não é interpretável de verdade, mas é mais rastreável que um embedding de 1024 dimensões saído de um CLIP.

Onde quebra

A escolha arquitetural tem preço, e ele é previsível:

• Resolução fixa engessa. Se o tokenizer foi treinado em 512×512, mandar uma imagem muito maior exige recorte ou downscale, e detalhes finos somem. OCR de documento denso, por exemplo, tende a sofrer mais do que num modelo com encoder dinâmico.
• Granularidade de 16×16 limita texto na imagem. Cada bloco de 16×16 pixels vira um único código. Fonte pequena cai dentro de meia célula e vira ruído. É um limite do tokenizer, não da escala do modelo.
• Trailing frontier. Os resultados de avaliação mostram melhorias em coding e instruction-following, performance competitiva em tradução multilíngue (batendo Claude Haiku 4.5 e Google Translate em um benchmark) e boa performance em tarefas jurídicas suíças, embora os modelos ainda fiquem atrás dos modelos de pesos abertos de fronteira em geral. Para produção séria em inglês genérico, isso é um fator.
• Thinking mode custa tokens. Reasoning explícito gera traços intermediários, que entram no custo e na latência. Vale para problema difícil, não para chat.

Já perdi tempo em projeto achando que o problema estava no prompt quando estava na granularidade do tokenizer visual. É um erro comum: a pessoa trata o modelo multimodal como uma caixa que “vê”, quando ele na verdade só vê o que o tokenizer deixou passar. Isso vem da experiência que escrevi nos livros que publiquei, entre eles a série IA na Prática, onde insisto no mesmo ponto: você só entende um modelo depois de olhar o que entra nele em formato de token.

O que não dá para afirmar ainda

Alguns pontos que a release toca mas não resolve:

• Qual a performance real em OCR de documento denso em português brasileiro. Os benchmarks publicados cobrem Swiss Legal e tradução, não documento digitalizado em escala.
• Latência prática por token em inferência local do 70B com 262k de contexto. A release documenta a capacidade, não os perfis de throughput em hardware comum.
• Até onde a vantagem de “treino na velocidade de texto” se traduz em custo de inferência menor comparado a modelos com encoder separado. A arquitetura de treino não decide sozinha a arquitetura de serving.
• Como o thinking mode se comporta em cadeias de tool use longas. A release menciona que RLVR integrou os dois, mas não quantifica a interação.

Como testar isso você mesmo

Um caminho curto, uma hora de trabalho:

1. Baixe o swiss-ai/Apertus-v1.5-8B do Hugging Face. Em GPU de 24GB roda em bf16 sem truque.
2. Teste primeiro só texto, com o snippet acima, e confirme que o chat template e o tokenizer estão corretos.
3. Pegue uma imagem 512×512 (ou faça resize) de um gráfico simples com números legíveis. Rode através do processor multimodal do repo apertus-omni-tokenizer e peça para o modelo descrever o valor mais alto. Isso testa alinhamento semântico mínimo.
4. Agora pegue a mesma imagem em 2048×2048 com texto pequeno. Observe o que o modelo acerta e erra. Essa diferença é a assinatura do tokenizer visual, não do modelo.
5. Compare o custo de token da imagem (1024) contra uma descrição textual equivalente da mesma imagem. Esse ratio decide se multimodal faz sentido para o seu caso.

Se o resultado do passo 4 te decepcionar, você entendeu em uma hora o que levei projetos inteiros para enxergar: multimodalidade por tokenizer discreto é elegante arquiteturalmente e dura visualmente. Isso não é defeito do Apertus, é consequência do caminho que ele escolheu. Saber onde o caminho estreita é metade do trabalho de escolher qual modelo usar.