MiniCPM-V 4.7: OpenBMB Publicou um Modelo de Visão-Linguagem 35B-A3B Sem Model Card, Sem Licença e Sem Benchmarks

O MiniCPM-V 4.7 apareceu no Hugging Face na noite de 6 de outubro de 2026 como o repositório openbmb/MiniCPM-V-4.7-35B-A3B — e é uma das coisas mais estranhas que a série MiniCPM já lançou, porque quase nada foi lançado junto com ele. Não há ficha de modelo. Não há README. Não há licença declarada. Não há tabelas de benchmark, nem post de lançamento, nem relatório técnico, e nenhuma entrada na documentação do próprio GitHub da OpenBMB, que até esta semana ainda chama o MiniCPM-V 4.6 de "o modelo mais recente e mais eficiente da série MiniCPM-V". O que existe são 16 shards de pesos bfloat16, 70,4 GB deles, descrevendo um modelo de visão-linguagem de mistura de especialistas com 35,2 bilhões de parâmetros, uma janela de contexto de 256K e um design de atenção híbrida incomumente agressivo. Isso é suficiente para dizer o que o modelo é. Ainda não é suficiente dizer em que ele é bom, e este artigo mantém essas duas coisas estritamente separadas.

O que realmente chegou, byte por byte

O repositório foi criado às 18:36 UTC de 6 de outubro de 2026 e teve seu último commit doze minutos depois, às 18:48 UTC. Nesse intervalo, o responsável pelo upload enviou os arquivos de pesos e a configuração de que um carregador do Transformers precisa, e parou. A lista completa de arquivos tem dezoito entradas:

• Pesos — dezesseis safetensors fragmentos nomeados model-00001-of-00016 até model-00016-of-00016, com o arquivo de índice model.safetensors.index.json indicando um tamanho total de tensores de 70,425,751,648 bytes.

• Contagem de parâmetros — a API do Hugging Face lê 35.212.875.824 parâmetros, todos em BF16. Observe que esta é a contagem total, que, para um MoE esparso, não é o número de parâmetros ativos em qualquer token específico.

• Configuração — config.json (2.984 bytes), generation_config.json (186 bytes), preprocessor_config.json, processor_config.json.

• Tokenizer — tokenizer.json (20 MB), tokenizer_config.json, e chat_template.jinja (7.250 bytes).

• Ausente — README.md. Uma busca direta pelo arquivo bruto retorna HTTP 404. No Hugging Face, um README ausente significa que não há cartão de modelo, o que significa que não há campo de licença, o que significa que o repositório não exibe a license: tag de forma alguma.

O repositório tem três curtidas, zero downloads e uma aba de discussão vazia. Um upload comunitário de um checkpoint de 70 GB geralmente atrai comentários em poucas horas — perguntas sobre quants, sobre serving, sobre qual é a licença. Este não atraiu, o que é consistente com o fato de ter sido notado por um punhado de pessoas que observam a openbmb como uma organização, em vez de ter sido anunciado a alguém.

A arquitetura, lida diretamente do config.json

Como não há card para parafrasear, o arquivo de configuração é a fonte primária, e é excepcionalmente informativo. A classe é MiniCPMV4_7ForConditionalGeneration, o tipo de modelo é minicpmv4_7, e foi salvo pelo Transformers 5.2.0 — tudo o que indica que este é um checkpoint de primeira parte da OpenBMB na linhagem principal do MiniCPM-V, não um fine-tune da comunidade usando o nome.

• Backbone de linguagem — model_type: qwen3_5_moe_text. Um MoE esparso derivado do Qwen3.5, a primeira vez que a linha MiniCPM-V usa um stack de texto Qwen-MoE em vez das variantes Qwen pequenas densas que equipavam o MiniCPM-V 4.5 e 4.6.

• Esparsidade — 256 especialistas, 8 selecionados por token, com um tamanho intermediário de especialista de 512 e um especialista compartilhado do mesmo tamanho. Um checkpoint total de 35B em um padrão de roteamento 8-de-256 ativa uma pequena fração disso por passagem direta, que é exatamente o ponto do nome A3B: os pesos são grandes, a computação não.

• Profundidade e largura — 40 camadas ocultas, tamanho oculto 2048, 16 cabeças de atenção com 2 cabeças de chave/valor e uma dimensão de cabeça de 256.

• Atenção híbrida — layer_types é um array de 40 entradas e executa três linear_attention camadas para cada uma full_attention camada em um intervalo fixo de 4. Dez das quarenta camadas fazem atenção convencional; as outras trinta usam um caminho linear no estilo Mamba com um kernel de convolução de 4. Esta é a escolha de design mais consequente do arquivo, e é a mesma direção que o campo mais amplo tomou em 2026.

• Codificação posicional — RoPE com um theta de 10.000.000 e partial_rotary_factor: 0.25, o que significa que apenas um quarto das dimensões de cada cabeça é rotacionado. O RoPE multimodal está habilitado com mrope_interleaved: true, uma divisão de seção de [11, 11, 10], e mrope_mode: canvas.

• Contexto — max_position_embeddings: 262144, e o model_max_length do tokenizador concorda. 256K tokens.

• Previsão multi-token — mtp_num_hidden_layers: 1, uma única cabeça de decodificação especulativa, o mesmo truque que o MiniCPM-V 4.6 trazia.

• Torre de visão — minicpmv4_7_vision, tamanho oculto 1152, 27 camadas, ativações GELU-tanh, tamanho de patch 14 com um image_size de 980, e um insert_layer_id de 6, que é onde os embeddings visuais são inseridos na pilha de linguagem. O formato da torre é próximo ao do MiniCPM-V 4.6, então o lado da visão é uma evolução, e não uma reconstrução.

• Compressão de visão — downsample_mode: "16x" e max_slice_nums: 9 no processador de imagens. O MiniCPM-V 4.6 introduziu um esquema comutável de compressão de tokens 4x/16x; a configuração do 4.7 anuncia a opção 16x como padrão, com o slicer permitindo até nove subimagens para entradas de alta resolução.

• Vocabulário — 248.144 tokens, com <|image_pad|> no id 248.056 e <|video_pad|> no 248.057. Vídeo é uma entrada de primeira classe, exatamente como tem sido desde o MiniCPM-V 4.5.

• Um resquício curioso — a configuração do tokenizer ainda declara <|audio_start|>, <|audio_end|> e <|audio_pad|>. Isso quase certamente significa que o vocabulário é compartilhado com o ramo omni MiniCPM-o, e não que o MiniCPM-V 4.7 fala áudio. Interpretar isso como um recurso de áudio seria um erro que a configuração sozinha não consegue descartar.

O que a família nos diz que este repositório não diz

A geração 4.6 é o ponto de referência, e o contraste é a história. O MiniCPM-V 4.6 foi lançado em 11 de maio de 2026 como um modelo de 1,3 bilhão de parâmetros construído sobre um codificador de visão SigLIP2-400M e um modelo de linguagem Qwen3.5-0.8B, sob Apache-2.0, com uma proposta explícita: ele pontua 13 no Artificial Analysis Intelligence Index — um número informado pelo fornecedor — enquanto usa drasticamente menos tokens do que modelos pequenos comparáveis, e roda em iOS, Android e HarmonyOS com o código de adaptação para edge em código aberto. Toda a sua identidade era "pequeno, eficiente, no dispositivo."

MiniCPM-V 4.7 é 1,3B multiplicado por aproximadamente 27. O nome 35B-A3B o coloca na classe ocupada por flagships esparsos, e não por celulares. Se a OpenBMB pretende usá-lo como um companheiro do lado do servidor para a linha edge, como um professor para um futuro modelo pequeno, ou como um teste de teto de capacidade, isso não é declarado em lugar nenhum, e o repositório não contém nenhuma pista em nenhuma direção.

O que é genuinamente novo, e que vale a pena destacar para quem acompanha a série, é o backbone Qwen-MoE, além da proporção 3:1 entre atenção linear e completa. Ambos representam rupturas. Tudo o que a OpenBMB publica sobre a família ainda está redigido em torno da 4.6, então este checkpoint está à frente da própria documentação.

O que ainda não é possível saber — e por que essa lista importa

Vale a pena ser direto sobre o tamanho da lacuna aqui, porque a tentação com um checkpoint de 70 GB é preenchê-la com inferência plausível.

• Sem licença. Isso não é uma formalidade. O MiniCPM-V 4.6 é Apache-2.0, e a comunidade passou a esperar isso dessa linha. Um repositório sem licença: tag é, por padrão, todos os direitos reservados na maioria das jurisdições — você não pode construir sobre ele com segurança até que a tag apareça. Esse único arquivo ausente é a ausência mais significativa no repositório.

• Nenhum benchmark, divulgado pelo fornecedor ou não. Não há um único número para discutir. Qualquer pessoa que cite uma pontuação de MMMU ou OCRBench para o MiniCPM-V 4.7 hoje está citando algo que não existe na fonte.

• Nenhuma avaliação independente. O Artificial Analysis e rastreadores semelhantes indexam modelos por nome; um checkpoint sem card e sem anúncio costuma ficar sem ser medido por um tempo.

• Nenhuma receita de serving. Se os pesos publicados rodam de forma padrão em vLLM, SGLang ou llama.cpp não foi testado por ninguém fora da OpenBMB. Os caminhos de código personalizados (MiniCPMV4_7ForConditionalGeneration, MiniCPMV4_7Processor, MiniCPMV4_7ImageProcessor, MiniCPMV4_7VideoProcessor) todos exigem trust_remote_code, e a combinação de MoE mais atenção linear não é um formato para o qual todo motor de inferência tenha um kernel.

• Sem quantizações. O MiniCPM-V 4.6 foi disponibilizado em variantes GGUF, AWQ, GPTQ e BNB, e chegou à biblioteca do Ollama em junho de 2026. Nenhuma existe para o 4.7. Para um modelo de 35B, esta é a diferença entre um laptop e um cluster.

• Nenhuma relação com o 4.6 é declarada. A OpenBMB pode estar substituindo a linha edge, estendendo-a ou testando algo ortogonal. O repositório não diz, e o README do GitHub também não, o qual ainda lista o 4.6 como a versão atual, conforme seu commit de 8 de setembro de 2026.

Há também uma leitura plausível, mas não confirmada, da linha do tempo: o intervalo de doze minutos entre a criação do repositório e o último commit, a ausência de um cartão e a ausência de qualquer post são o que um checkpoint parece ser quando é preparado para um lançamento, e não depois dele. Isso é uma hipótese sobre intenção, não um fato sobre o artefato, e deve ser tratada como tal.

Como você realmente o executaria, quando há algo para executar.

Nada aqui pode ser citado como um caminho suportado por enquanto, mas a configuração restringe as opções. Um checkpoint BF16 de 35B parâmetros precisa de cerca de 70 GB de memória de acelerador antes do KV cache, então a implantação por entusiastas em uma única GPU está descartada até que surjam quantizações. O contexto de 256K e a proporção de atenção linear de 3:1 fazem com que o KV cache cresça muito mais devagar do que um transformer convencional da mesma profundidade, e é exatamente por isso que essa arquitetura vale a complexidade — trabalho multimodal de contexto longo é onde o design se paga. Quando uma placa surgir, as primeiras coisas a verificar são a licença, se uma receita oficial do vLLM ou do SGLang foi publicada e se o padrão de downsample de 16x pode ser trocado pela configuração de 4x que a 4.6 expôs.

Para equipes que querem avaliar um modelo como este no momento em que ele se torna utilizável, o problema prático não são os pesos, e sim a infraestrutura ao redor deles. Um modelo que roda na sua própria GPU ainda precisa de tudo ao seu redor — um roteador que coloca mais de 200 modelos hospedados atrás de uma única chave, pelo preço de tabela de cada provedor, sem nenhuma margem nossa adicionada por cima, e que faz failover automaticamente quando um provedor degrada. É para isso que o OrcaRouter serve, e vale dizer claramente que o próprio MiniCPM-V 4.7 não é um modelo hospedado: é um checkpoint de pesos abertos que você mesmo serve. O roteador importa aqui como a outra metade da arquitetura — o modelo de fronteira para o qual sua máquina com o 4.7 repassa os casos difíceis, acessível pelo mesmo cliente que você já escreveu.

O estado atual das coisas, e o único arquivo a atualizar

MiniCPM-V 4.7 existe. Os seus pesos estão disponíveis para download hoje, a contagem de pesos é exata, e as escolhas de design da sua época de treino — MoE esparso, atenção linear 3:1, contexto de 256K, compressão visual de 16x — são todas legíveis a partir do ficheiro de configuração. O que não existe é qualquer declaração da OpenBMB sobre o que o modelo faz, quanto custa executá-lo na prática, ou o que se pode fazer com ele. Para um laboratório cujo último modelo de visão foi um lançamento edge de 1,3B Apache-2.0 com uma tabela de comparação completa, isso é uma lacuna desconcertante, e a postura sensata é observar o repositório em vez do discurso. O único ficheiro a atualizar constantemente é README.md: no momento em que aparecer, trará a licença, os benchmarks e provavelmente a explicação do que um MiniCPM-V de 35B está a fazer numa série baseada em modelos pequenos.

Até então, o resumo honesto é o mais entediante. Este é um checkpoint real de um laboratório real, enviado discretamente, e a pergunta interessante — se ele é bom — não tem resposta publicada.

O OrcaRouter alcança mais de 200 modelos hospedados por meio de uma única chave, com o preço de tabela de cada provedor repassado diretamente com 0% de markup e failover automático entre provedores. preço de tabela do provedor repassado com 0% de markup O MiniCPM-V 4.7 não é um deles — é um checkpoint de pesos abertos que você mesmo serve, e o roteador é o que fica do outro lado da transferência.