Um Pagode Voxel, 10% Menos Tokens e a Única Frase que a OpenBMB Realmente Endossa

A frase mais citada sobre o MiniCPM-V 4.7 35B-A3B nesta semana não está na sua ficha do modelo. É um tuíte, publicado em 13 de outubro de 2026, que diz: "MiniCPM-V 4.7 35B-A3B não só usou menos tokens, mas também produziu um pagode de voxels melhor do que o Qwen 3.6 35B-A3." A demonstração à qual ele se refere é um vídeo de dois modelos de linguagem escrevendo cada um o código de um pagode japonês em voxels 3D, renderizados lado a lado. É um artefato genuinamente interessante — mostra um modelo de visão-linguagem reproduzindo em três dimensões uma estrutura construída a partir de um prompt de imagem, o que é uma tarefa mais difícil do que legendar uma. Mas vale separar o que esse tuíte é do que ele não é, porque três alegações diferentes foram fundidas em uma única frase, e elas têm três níveis diferentes de respaldo. MiniCPM-V 4.7 35B-A3B é um checkpoint real da OpenBMB e tem cerca de uma semana; Qwen3.6-35B-A3B é um rival de nove meses, de pesos abertos, também Apache-2.0, também uma mistura esparsa de especialistas do mesmo tamanho anunciado. Tudo abaixo trata de quais das alegações de eficiência em torno deles são verificáveis, e qual delas é um JPEG de um gráfico.

Três afirmações vestindo uma única frase

O tweet agrupa coisas separáveis, e elas merecem ser separadas porque uma delas está documentada.

• "Usou menos tokens" — esta é uma afirmação mensurável sobre o consumo de tokens para uma tarefa. O número que circula junto com a demonstração é de 10% menos tokens do que o Qwen3.6 35B-A3B. Esse número vem do criador terceiro que fez a comparação, não da avaliação da OpenBMB, e é um único par de prompts, não um benchmark.

• "Produziu um pagode voxel melhor" — isto é um julgamento, feito ao se olhar para dois pagodes renderizados. Não há rubrica, nem sistema de pontuação, nem parte independente. É o tipo de afirmação que um humano faz em três segundos e que um benchmark não consegue fazer de modo algum, porque "melhor pagode" não tem verdade de referência.

• "Eficiência mais qualidade é o verdadeiro campo de batalha" — essa parte é uma tese, e por acaso é a que a OpenBMB de fato defende por escrito, com números anexados, no model card. Só que não é a frase que circulou.

Isso importa porque as duas primeiras afirmações são as memoráveis e a terceira é a defensável. Se você está decidindo se deve gastar 70 GB de download em um checkpoint, você quer a terceira.

O que a OpenBMB realmente escreveu, e quando

A cronologia primeiro, porque foi comprimida pela recontagem. Os pesos foram disponibilizados em silêncio: openbmb/MiniCPM-V-4.7-1Bfoi criado em 6 de outubro de 2026 às 17:40 UTC,openbmb/MiniCPM-V-4.7-35B-A3Bem 7 de outubro às 07:07 UTC. Nenhum dos dois trazia um model card, uma etiqueta de licença ou um benchmark naquele momento — isto foi abordado aqui na altura, e era um estado de coisas estranho para um upload de 35 bilhões de parâmetros. Seis dias depois, em 12 de outubro de 2026, a OpenBMB fez o commit da documentação de uma só vez: model card, licença Apache-2.0, gráficos de avaliação, um README do repositório reescrito que abre com a nova série, e um anúncio. Os parâmetros não mudaram naquele dia. A explicação, sim.

Portanto, o enquadramento honesto não é "MiniCPM-V 4.7 35B-A3B foi lançado esta semana." É "MiniCPM-V 4.7 35B-A3B tornou-se legível esta semana." Tudo sobre ele que agora é citável foi ou enviado nos dias 6 e 7, mas sem documentação, ou escrito no dia 12 e é uma alegação do fornecedor.

A afirmação que o model card de fato faz

Aqui está a frase, textualmente do card, e é mais restrita do que o tweet: no modo Instruct, a variante 35B-A3B "obtém uma pontuação geral mais alta em menos tempo de inferência do que o Qwen3.6 35B-A3B." É isso. Sem contagem de tokens, sem margem, sem detalhamento por benchmark em prosa. A evidência por trás disso é um gráfico de dispersão — pontuação média de avaliação no eixo vertical, tempo de inferência em segundos em escala logarítmica no eixo horizontal — no qual o MiniCPM-V 4.7 35B-A3B fica acima e à esquerda do Qwen3.6-35B-A3B. A própria nota de rodapé do gráfico define a média como a média de cinco benchmarks: MMStar, MMMU-Pro, CharXiv reasoning, BLINK e MathVista. Círculos indicam o modo Instruct, losangos indicam o modo Thinking.

Isso é uma afirmação real e específica sobre um tradeoff bidimensional, e é a coisa mais forte do lançamento. Também vale a pena notar o que o gráfico não pode dizer: não há rótulos numéricos nos pontos representados, então você não pode ler uma pontuação ou um tempo, apenas uma direção. A direção, como desenhada, favorece o MiniCPM em ambos os eixos ao mesmo tempo.

E foi medido pelo fornecedor. Os números de avaliação da ficha trazem a frase "Os resultados vêm de relatórios públicos e da nossa avaliação local usando checkpoints oficiais." Avaliação local significa hardware da OpenBMB, harness da OpenBMB, seleção de modo da OpenBMB. Isso é uma coisa normal para uma ficha de modelo fazer e uma coisa anormal de se transformar em fato. Nenhuma parte independente executou esses dois checkpoints em um harness compartilhado. Nenhum ranking indexou qualquer um dos resultados. No momento em que escrevo, a alegação tem exatamente uma fonte, e a fonte vende o modelo.

De onde deveria vir a eficiência de tokens

O argumento de eficiência não se apoia no gráfico de benchmark. Apoia-se em três escolhas de engenharia, e vale a pena entendê-las porque determinam se o ganho se transfere para o seu hardware ou não.

• Lookahead Expert Scheduling (LES) — a técnica em destaque. Uma mistura esparsa de especialistas armazena muito mais parâmetros do que ativa por token e, em um dispositivo que não consegue manter todos os especialistas na memória, os pesos são paginados para dentro e para fora e a decodificação trava. O LES usa previsão de roteamento entre camadas para pré-carregar especialistas que provavelmente serão necessários na camada seguinte e prioriza a computação para os especialistas que o roteador real de fato selecionou e que por acaso já estão carregados. A OpenBMB faz questão de afirmar que a previsão impulsiona apenas o pré-carregamento e o escalonamento; o roteamento em nível de token do modelo permanece inalterado, e os especialistas que o preditor não previu ainda são carregados e avaliados. A ficha técnica alega um ganho de velocidade de 5× em dispositivos reais com isso, sem perda de capacidade.

• Quantização refinada camada por camada — reduz a pegada dos pesos dos especialistas e o tráfego de memória, que é a outra metade para fazer um padrão de carregamento no dispositivo caber.

• Amostragem especulativa DSpark — um caminho de modelo draft pareado, publicado separadamente como openbmb/MiniCPM-V-4.7-35B-A3B-DSpark, e integrado juntamente com o trabalho de agendamento e quantização.

Combinados, eles produzem o número de destaque do lançamento: mais de 13 tokens por segundo usando cerca de 3 GB de memória em um iPhone 17 Pro Max. Esse é um dado do fornecedor, em hardware do fornecedor, com software do fornecedor — um aplicativo escrito pela OpenBMB. É o tipo de alegação que ou é o produto inteiro, ou não é nada, e atualmente não há como alguém fora da empresa verificá-la, porque reproduzi-la exige a pilha no dispositivo que a demonstração no telefone executa.

A eficiência de tokens é real, mas aqui é uma matriz, não um escalar.

Há um detalhe neste lançamento que foi achatado em todos os resumos dele, e é justamente ele que de fato rege a economia dos tokens.

• MiniCPM-V 4.7 35B-A3B suporta compressão de tokens visuais mista de 4x e 16x, selecionável por requisição. A configuração 16x mescla tokens visuais para ganhar velocidade; a 4x mantém quatro vezes mais, para detalhes. O padrão do card é 16x, e o parâmetro precisa ser passado tanto para o template de chat quanto para a chamada de generate, ou a contagem de placeholders e o codificador de visão divergem.

• A própria tabela comparativa de visão-linguagem do fornecedor registra a configuração de compressão usada para a linha de cada modelo. Nessa tabela, a linha do MiniCPM-V 4.7 35B-A3B está em 4x — a configuração que preserva detalhes, ou seja, a mais cara — e a linha do Qwen3.6 35B-A3B está em 16x. Uma linha do Gemma 4 31B está listada em 9x; as duas linhas do Qwen 27B, em 4x.

• Uma nota de rodapé afirma claramente que o MiniCPM-V 4.7 oferece suporte a qualquer uma das configurações, enquanto os demais modelos da tabela suportam apenas uma taxa de compressão fixa.

Leia isso em conjunto e o quadro muda. Se a linha do MiniCPM está obtendo suas pontuações de visão-linguagem na configuração que consome muitos tokens, enquanto a linha do Qwen está obtendo suas pontuações na configuração econômica em tokens, então as duas colunas estão comparando quantidades diferentes de detalhe visual, e a história da eficiência não é "mesma entrada, menos tokens" — é "entrada ajustável, e aqui está a coluna que vence em qualidade". Essa é uma afirmação mais interessante e mais honesta do que a do tweet, e a OpenBMB a publicou em uma nota de rodapé em vez de destacá-la.

Isso também significa que o número com que você realmente se importa — tokens por unidade de detalhe visual — não pode ser lido diretamente desta tabela de forma alguma. Ele exige executar ambos os modelos na mesma configuração, o que ninguém publicou.

A tabela, com as ressalvas anexadas

A placa vem com duas tabelas do fornecedor, uma para visão-linguagem e outra para linguagem, ambas no modo Instruct, ambas comparadas a um conjunto que inclui dois modelos Qwen da classe 35B-A3B, uma Gemma de 31B e duas Qwen de 27B. Os números abaixo foram lidos diretamente do gráfico PNG do próprio fornecedor, e a ressalva é estrutural: os números existem apenas como pixels nesse gráfico, não como uma tabela, portanto o que segue foi extraído por leitura automática e pequenos erros de transcrição são possíveis.

• OCRBench — MiniCPM-V 4.7 35B-A3B 91,20 contra Qwen3.6 35B-A3B com 90,40. Uma diferença de 0,8 ponto, na própria execução do fornecedor.

• OmniDocBench v1.6 — aproximadamente 98,2 para o MiniCPM contra aproximadamente 93,3 para o modelo Qwen, que é a maior diferença isolada da tabela e a que mais importaria se se reproduzisse, já que o parsing de documentos é onde os orçamentos de tokens costumam ser gastos.

• MMMU — aproximadamente 80,2 contra 80,0, um empate técnico na resolução de uma imagem de gráfico.

• MMMU-Pro — aproximadamente 69,7 contra 67,7, em uma linha onde um Qwen de 27B fica acima dos dois.

• Tabela de linguagem — o mesmo formato, com as células mais impressionantes em seguimento de instruções e código. IFBench está listado em torno de 47,7 contra 35,3, e LiveCodeBench-v6 em torno de 97,0 contra 54,3. Esses dois são grandes o suficiente para que devam ser tratados como as células menos confiáveis do lançamento até que alguém de fora os execute: uma diferença de 43 pontos em um benchmark de código entre dois modelos MoE abertos de tamanho semelhante, medida por uma das duas partes, é uma afirmação que precisa de um segundo instrumento.

Relatado pelo fornecedor, testado no harness do fornecedor, não reproduzido. Isso é tudo. Se estes números se sustentarem sob um harness independente, a alegação de fronteira de Pareto está correta e o vídeo da pagoda é uma nota de rodapé. Se não, o vídeo da pagoda é tudo o que há.

O que os números de adoção dizem, o que não diz nada sobre qualidade

Há um número nesta comparação que ninguém contesta, e não é um benchmark. O contador de downloads do Hugging Face, consultado a 13 de outubro de 2026, indica 630 para openbmb/MiniCPM-V-4.7-35B-A3Bcontra cerca de 3,6 milhões paraQwen/Qwen3.6-35B-A3B— um repositório criado a 15 de abril de 2026 e que, por isso, está cerca de nove meses mais avançado na curva de adoção. Essa diferença mede tempo, não mérito, e é a razão pela qual a questão da eficiência está a ser colocada nesta direção: o recém-chegado tem de argumentar numa base por token precisamente porque não teve nove meses para ser o padrão.

Há também uma pequena contradição interna na listagem que vale a pena destacar. O repositório carrega a tag "On-Device Model" herdada do resto da família, e um MoE esparso de 35,2 bilhões de parâmetros em 70,4 GB de pesos BF16 não é on-device em nenhum sentido que quem baixa reconheceria. A história de on-device é real, mas passa por quantização e streaming de especialistas por cima do checkpoint, não pelo checkpoint. Dimensione os recursos com base na build quantizada e no app, não na tag.

O que fazer sobre isso esta semana

A posição prática é estreita e clara. Se você quer a alegação de eficiência verificada, ainda não há nada a verificar — é o gráfico de um único fornecedor, e o único número com um valor por tarefa associado (10% menos tokens, uma pagoda) vem de uma única demonstração de terceiros. Se você quer executar o modelo, os pesos são Apache-2.0, a arquitetura está documentada, e a configuração de downsampling é você quem escolhe, o que é uma alavanca genuína e subestimada: 16x quando a taxa de transferência importa, 4x quando o gráfico está lhe mostrando um documento.

Metade desta comparação está acessível hoje por meio de uma API hospedada, e a outra não, e vale a pena ser preciso sobre qual é qual. qwen/qwen3.6-35b-a3bé um modelo hospedado no OrcaRouter — ele fica no catálogo atrás de uma única chave, pelo preço de tabela da própria Qwen, sem nada acrescentado por cima, encaminhando para o provedor que estiver saudável em vez de para um que você fixou. O MiniCPM-V 4.7 não é hospedado por nós; é um checkpoint de pesos abertos que você mesmo serve. Essa assimetria é o que há de útil aqui. Você pode colocar o lado Qwen desta comparação em uma baseline hoje à tarde, rodar o harness da OpenBMB nos seus próprios dados contra ele, e deixar o gráfico do fornecedor ser a hipótese em vez da resposta.

O que, dado que todo o argumento é sobre eficiência no seu hardware, é a única medição que algum dia iria resolvê-lo.