MiniCPM-V 4.7 35B-A3B vs PixelUMM: uma licença decide isto antes que os benchmarks o façam

Há uma decisão que você pode tomar entre MiniCPM-V 4.7 35B-A3B e PixelUMM sem ler um único benchmark, e é provavelmente a decisão que mais importa. O MiniCPM-V 4.7 35B-A3B é Apache-2.0. O checkpoint do modelo do PixelUMM não é — ele é distribuído sob a One-Way Noncommercial License da NVIDIA, que permite apenas pesquisa e avaliação, em um checkpoint que a própria NVIDIA diz que "não foi validado para produção ou uso de alto risco". Se você está construindo algo que pretende vender, um desses dois modelos é inviável e o resto da comparação é acadêmico. Se você faz pesquisa, o campo se abre, e a pergunta interessante passa a ser contra o que o design sem encoder da NVIDIA está de fato apostando — porque ele está apostando exatamente contra a arquitetura que o MiniCPM-V 4.7 usa.

Ambos os modelos foram lançados discretamente. Os pesos do PixelUMM chegaram ao Hugging Face às 21:40 UTC de 1 de outubro de 2026, sem post de blog, sem comunicado de imprensa e sem keynote; a URL da página do projeto ainda diz "preview". O MiniCPM-V 4.7 apareceu em 6 de outubro da mesma forma, e a OpenBMB não colocou um cartão de modelo, uma licença ou uma seção de alegações nele até 12 de outubro. Nenhum dos dois foi avaliado de forma independente por ninguém, e nenhum tem uma tabela de benchmarks que um leitor possa citar — o cartão do PixelUMM não relata pontuação alguma, e as alegações de desempenho do MiniCPM-V 4.7 estão dentro de imagens de gráficos em vez de em texto. O que segue separa o que os repositórios afirmam daquilo que ninguém fora dos dois laboratórios ainda confirmou.

O que é o PixelUMM, em um parágrafo

O PixelUMM é um Transformer decoder-only de 15.199.672.064 parâmetros com uma cabeça de geração iterativa de pixels, construído sobre um backbone Qwen3-8B fixado em uma revisão específica. Sua tese é declarada na primeira linha da ficha do modelo e é genuinamente contrária ao senso comum: sem VAE e sem codificador de visão. Enquanto um modelo unificado convencional possui duas interfaces visuais — um Vision Transformer que produz features semânticas para compreensão e um autoencoder variacional que produz latentes de reconstrução para geração —, o PixelUMM não possui nenhuma delas. As imagens são cortadas em patches de 16×16 pixels, os vídeos em tubelets espaço-temporais de quatro quadros, e ambos chegam ao backbone por nada mais do que projeções lineares de camada única, com o denoising iterativo fazendo o trabalho de geração. O artigo o descreve como um Mixture-of-Transformers que combina atenção compartilhada com parâmetros específicos da tarefa. Ele lida com texto para imagem, geração de texto condicionada por imagem, compreensão condicionada por vídeo e geração de vídeo, incluindo texto para vídeo com 96 quadros, 24 fps e quatro segundos.

O rastro em torno disso se estendeu por cerca de quatro semanas, tudo em silêncio. O repositório GitHub nv-tlabs/PixelUMM foi criado em 4 de setembro de 2026 sob a licença Apache-2.0 e ficou com um único commit durante a maior parte do mês. Nos dias 28 e 29 de setembro, o commit inicial foi registrado e o arXiv atribuiu o preprint 2609.38597, cuja lista de autores se distribui entre a NVIDIA e a University of Waterloo. O repositório do modelo em si surgiu às 21:40 UTC de 1º de outubro, oito minutos depois de um commit final no GitHub que acrescentou a citação do artigo. O artigo não traz nenhuma linha de publicação — nenhuma conferência, nenhum “accepted to” — o que soa como uma equipe de pesquisa colocando um artefato no ar, em vez de um lançamento de produto, embora isso seja uma observação sobre as evidências, e não uma afirmação sobre a intenção.

O que é o MiniCPM-V 4.7 35B-A3B

O MiniCPM-V 4.7 35B-A3B é a primeira entrada MoE da OpenBMB na série MiniCPM-V: 256 especialistas com 8 ativos por token, 40 camadas, uma janela de contexto de 262.144 tokens e um vocabulário de 248.144 tokens, resultando em aproximadamente 3B parâmetros ativos de um total de 35,2B. A visão passa por um módulo SigLIP2 com compressão precoce intra-ViT do LLaVA-UHD v4 e um modo selecionável de compressão mista de tokens visuais de 4x/16x — 16x por padrão para vazão, 4x quando detalhes finos importam. Ele entende imagens individuais, várias imagens e vídeo, e responde em texto. Ele não gera imagens.

A alegação principal do card é que este é o primeiro modelo MoE de código aberto com inferência no dispositivo sem perdas e fluida, proporcionada por Lookahead Expert Scheduling, quantização em granularidade fina por camada e amostragem especulativa por meio dos drafts DSpark separados, com relatos de mais de 13 tokens por segundo em um iPhone 17 Pro Max. Esse número é relatado pelo fornecedor, não reproduzido e não qualificado. O card também afirma uma pontuação geral mais alta no modo Instruct do que o Qwen3.6 35B-A3B em menos tempo de inferência — uma alegação que aparece dentro da imagem de um gráfico, o que significa que não é um número citável e não deve ser tratado como tal.

Onde o MiniCPM-V 4.0 está inequivocamente à frente não é em nenhum placar, mas no elenco de coadjuvantes, todo ele real e baixável: pesos base, FP8, int4, AWQ, GPTQ e GGUF; suporte em SGLang, vLLM, llama.cpp, Ollama e OpenVINO; aplicativos para iOS, Android e HarmonyOS; e Rockchip, Houmo, Intel, AMD e Arm listados para silício desde o dia zero. Seis semanas atrás, a crítica honesta a este modelo era que ele era um checkpoint não documentado. Isso já não é verdade — é um checkpoint documentado sem benchmarks. Problema diferente, menor.

O argumento de arquitetura escondido por trás da comparação

Os dois modelos discordam sobre algo fundamental, e vale a pena dar nome a isso, porque é a parte deste confronto cujo prazo de validade é mais longo do que o de qualquer um dos dois modelos.

• Como a visão chega ao modelo de linguagem — o PixelUMM usa pixels brutos e uma única projeção linear, sem nenhum codificador de visão pré-treinado em qualquer parte da pilha; o MiniCPM-V 4.7 usa um codificador SigLIP2 com compressão precoce intra-ViT e uma taxa de downsample configurável.

• Como a geração funciona — o PixelUMM prevê pixels iterativamente por meio de uma cabeça de flow matching treinada conjuntamente com a previsão autorregressiva de texto; o MiniCPM-V 4.7 gera texto e nada mais.

• O que isso rende — a PixelUMM ganha um único conjunto de pesos que tanto descreve uma imagem quanto a produz, ao custo de uma licença apenas para pesquisa e sem validação de produção; a MiniCPM-V 4.7 ganha um modelo pequeno, quantizável e implantável em telefone, capaz de ler o mundo, mas não de redesenhá-lo.

• Contagem de parâmetros — 15,2B quase densos contra 35,2B totais com 3B ativos. A contagem de parâmetros ativos é a que prediz o custo de inferência, e nesse eixo o modelo MiniCPM é o menor dos dois por uma ordem de magnitude.

• Pesos no disco — o repositório do PixelUMM contém 491 arquivos distribuídos em quatro variantes de checkpoint; a versão base do MiniCPM-V 4.7 é composta por dezesseis shards BF16 de aproximadamente 70 GB.

• Licença — Apache-2.0 versus NVIDIA One-Way Noncommercial para o checkpoint, com a Apache-2.0 aplicando-se apenas ao código-fonte do PixelUMM e a base Qwen3-8B sendo licenciada separadamente sob Apache-2.0. O cartão do PixelUMM também observa que inclui código modificado derivado do BAGEL, pelo que os termos upstream se aplicam adicionalmente.

• Avaliação pública — nenhuma, de ambos os lados. O MiniCPM-V 4.7 pelo menos apresenta alegações de desempenho; o card do PixelUMM não informa nenhum número de benchmark.

Qual deles você pode realmente colocar na frente de um usuário

Acompanhe a licença e o cenário de implantação em conjunto e a escolha praticamente se faz sozinha.

O PixelUMM é o artefacto de investigação mais interessante e o produto menos utilizável. Um checkpoint não comercial bloqueia desde logo os usos comerciais óbvios, não há receita de serving no cartão, nenhuma build quantizada, nenhum valor de comprimento de contexto, e 83 gostos contra zero downloads registados significa que, essencialmente, ninguém fora dos autores o executou. Neste momento, o seu valor reside em ser um argumento forte e publicado de que os codificadores de visão podem ser desnecessários em modelos unificados. Vale a pena acompanhar esse argumento, quer alguma vez carregue os pesos quer não.

O MiniCPM-V 4.7 é o que tem um caminho para produção, e o caminho é estreito, mas real. A Apache-2.0 remove a questão do licenciamento. Seis formatos de quantização e cinco runtimes de inferência significam que você não precisa escrever kernels personalizados. Duas ou mais GPUs para a build não quantizada são a barreira; as builds quantizadas e a história de execução no dispositivo são a solução alternativa, e a alegação de execução no dispositivo é justamente a que não foi verificada de forma independente. Trate-o como um modelo que você pode executar hoje e uma alegação de desempenho com a qual você ainda não pode contar.

Para equipes cuja resposta é "nenhum dos dois, vamos chamar outra coisa", o equivalente hospedado mais próximo do formato do MiniCPM é o Qwen3.6 35B A3B — mesmos 35B no total, mesmos 3B ativos, mesmo contexto de 262K, mesma entrada de texto, imagem e vídeo — e ele é servido pelo OrcaRouter pelo preço de tabela do provedor, com zero markup, US$ 0,25 por milhão de tokens de entrada e US$ 1,48 por milhão de tokens de saída, com failover automático se uma rota do provedor degradar. Isso não é um substituto para nenhum dos dois modelos deste artigo; é o grupo de controle que mostra o que a auto-hospedagem de um MoE multimodal esparso de 70 GB realmente compra para você.

Onde isto vai parar

Deixe de lado a arquitetura e restam dois lançamentos discretos apontando em direções opostas. A NVIDIA publicou um artefato de nível de artigo sob uma licença que impede a maioria das pessoas de usá-lo, e um repositório sem receita, sem benchmarks e sem downloads. A OpenBMB publicou um modelo documentado, com licença permissiva e múltiplos runtimes, com uma alegação de eficiência convincente e nenhuma tabela de avaliação que a sustente.

A única coisa que resolveria cada caso: para o PixelUMM, qualquer reprodução independente que seja — 0 downloads significa que não existe nenhum ponto de dados externo, e a tese sem encoder é exatamente o tipo de afirmação que ou se sustenta ou desmorona ao entrar em contato com uma segunda implementação. Para o MiniCPM-V 4.7, uma tabela de benchmark, ou um comprimento de aceitação reproduzido no modelo draft do DSpark, que é a única parte da família com números publicados. Nenhum dos dois existe ainda. Ambos são a razão pela qual esses dois modelos ainda merecem ser acompanhados em vez de arquivados — eles estão mais no início de sua vida pública do que a cobertura sugere, e nenhum deles foi chamado de lançamento pelo laboratório que o criou.