MiniCPM-V 4.7 coloca um modelo de visão de 35B em 3 GB: desvendando a alegação de 100 tok/s

Um modelo de 35 bilhões de parâmetros não cabe em três gigabytes. O MiniCPM-V 4.7 35B-A3B roda em cerca de três gigabytes mesmo assim, e ambas as afirmações são verdadeiras — é justamente aí que está o truque, e o motivo pelo qual vale a pena desacelerar para entender os números que circulam sobre este lançamento. O modelo é a primeira entrada de mistura esparsa de especialistas da linha MiniCPM-V da OpenBMB: 35,2 bilhões de parâmetros armazenados, cerca de 3 bilhões ativos por token, Apache-2.0, pesos no Hugging Face. Ele lê imagens, conjuntos com várias imagens e vídeos, e responde em texto. Desde 10 de outubro, ele também roda no llama.cpp upstream, que é onde a maioria das pessoas o conheceu. O que segue separa os três números que todos estão repetindo — 3 GB, 35B e o valor de 100 tok/s — e mostra quais deles a OpenBMB realmente publicou. Mais de 200 modelos hospedados, uma única chave, preço de tabela do provedor repassado com 0% de margem. Veja o que o OrcaRouter roteia O checkpoint de pesos abertos permanece no seu hardware; a válvula de escape hospedada é um único endpoint. As falhas de IA documentadas e os incidentes com agentes por trás de lançamentos como este estão reunidos em o OrcaRouter AI Incident Archive onde cada entrada traz suas próprias fontes, classificação de gravidade, grau de confiança e sinalização de contestação.

Três gigabytes, trinta e cinco bilhões de parâmetros e nenhuma contradição

A aritmética só parece impossível se você presumir que "na memória" significa "tudo". O MiniCPM-V 4.7 35B-A3B mantém cerca de 3 bilhões de parâmetros residentes e faz streaming do restante dos especialistas à medida que o roteador os solicita — o próprio enquadramento do model card é Lookahead Expert Scheduling, um preditor de roteamento entre camadas que pré-carrega os especialistas que a próxima camada provavelmente precisará, sobrepondo esse carregamento à computação já em andamento. O card faz questão de dizer que a predição só orienta a pré-carga e o agendamento; os tokens continuam seguindo o roteamento real do modelo, e um especialista que o preditor não previu é carregado e avaliado como qualquer outro.

Essa distinção tem uma consequência mensurável. O repositório GGUF publica o modelo inteiro em todas as quantizações comuns, e nenhum desses arquivos tem três gigabytes:

• Q4_K_M — 21,2 GB no disco.

• Q8_0 — 36,9 GB.

• F16 — 69,4 GB.

• Projetor de visão — 0,9 GB com compressão 4x, 1,1 GB em f16.

Portanto, "3 GB" é um valor de memória residente no streaming de especialistas em um celular, não um tamanho de download nem um requisito de VRAM para um desktop. Se você está planejando uma implantação, o número que rege seu disco e seu primeiro carregamento é 21,2 GB em Q4_K_M, e o número que rege sua pegada em regime estacionário em um celular é o ~3 GB do fornecedor. Ambos estão no release. Eles respondem a perguntas diferentes, e a maior parte da cobertura os reduziu a um só.

De onde vêm 100 tok/s — e de onde não vêm

Eis a parte sobre a qual vale a pena ser direto. A OpenBMB não publica um número de 100 tok/s para o MiniCPM-V 4.7. O número no cartão do modelo é de 13+ tokens/s, num iPhone 17 Pro Max, com cerca de 3 GB de memória. Essa é a única alegação de throughput no dispositivo feita no lançamento, e ela é medida pelo fabricante em hardware que ninguém fora do laboratório reproduziu.

Existem números mais altos, e eles vêm de um artefato diferente. O fork llama.cpp-omni da OpenBMB — o repositório que contém as otimizações no dispositivo — publica sua própria tabela para o alvo 35B-A3B, organizada pelas otimizações que estão ativadas:

• iPhone 18 Pro Max, 12 GB — linha de base de 3,38 tok/s, 11,34 com Lookahead Expert Scheduling, 17,16 com precisão mista adicionada, 20,51 também com a cabeça de rascunho DSpark.

• iPad Pro de 11 polegadas M4, 16 GB — 2,97 tok/s na linha de base, 9,81 com LES, 14,92 com precisão mista, 17,39 com DSpark.

Esses são os maiores números publicados no dispositivo para este modelo, e o topo da escala é 20,51 tok/s — um quinto de 100. A diferença importa porque muda para que serve o modelo. A 13 tok/s, um app de celular responde a uma pergunta sobre uma foto em alguns segundos. A 100 tok/s, você o consideraria um leitor de primeira passagem em streaming para vídeo. O primeiro é um produto real. O segundo não é o que foi lançado, e qualquer pessoa que faça orçamento com base no número do tweet ficará decepcionada por um fator de cinco.

A leitura honesta da alegação de 100 tok/s é que ela é uma compressão de três fatos separados — 3 GB, roda localmente, mais rápido que a geração anterior por uma margem ampla — em um único número que nenhuma das fontes contém. A melhoria de geração para geração é real e grande: 3,38 para 20,51 tok/s é um avanço de 6x na mesma classe de dispositivo, alcançado empilhando três técnicas em vez de usar um chip maior.

O lançamento não foi de um único dia, e as datas importam.

O MiniCPM-V 4.7 surgiu como muitos lançamentos de pesos abertos fazem agora: primeiro os arquivos, a explicação depois, e o suporte de frameworks em algum lugar no meio.

• 6 de outubro, 17:40 UTC — o modelo 1B e suas variantes AWQ, GPTQ e int4 aparecem no Hugging Face, além das builds GGUF às 18:05.

• 7 de outubro, 07:07 UTC — o repositório 35B-A3B é publicado. Ainda sem cartão de modelo.

• 8 de outubro — cabeças de decodificação especulativa DSpark para ambos os tamanhos, e uma versão FP8 do 35B.

• 10 de outubro, 18:42 UTC — llama.cpp integra suporte ao modelo.

• 12 de outubro — A OpenBMB faz commit do model card, declara Apache-2.0 e anuncia o lançamento como um produto documentado.

• 15 de outubro — os heads do DSpark estão vinculados a partir do card principal, com rascunhos GGUF para ambos os alvos.

Essa ordem explica boa parte da confusão na cobertura secundária. Alguém que conheceu o modelo por meio do llama.cpp na segunda semana de outubro estava executando uma versão que oficialmente ainda não existia, sem etiqueta de licença e sem gráfico de benchmark, e seus números de throughput refletem as escolhas de quantização do próprio framework, e não qualquer coisa que a OpenBMB tenha avaliado em benchmark.

Suporte ao llama.cpp: mesclado, e ainda não totalmente concluído

O pull request upstream que adicionou o MiniCPM-V 4.7 é excepcionalmente claro sobre o que mudou, e a resposta é: quase nada em termos de arquitetura. O modelo é quase idêntico ao MiniCPM-V 4.6; o delta é o 3D RoPE, uma posição com três valores por token — tempo, linha, coluna — em vez do único escalar que a maioria dos modelos de visão e linguagem usa. O suporte estende o caminho existente do 4.6 para carregar essa dimensão extra. O PR também indicava o modelo como "em breve" quando foi aberto em 25 de setembro, o que é uma boa pista sobre quão cedo os pesos estavam em circulação.

Vale a pena conhecer esse resíduo antes de construir uma funcionalidade de grounding sobre ele. Desde aquele merge, o upstream llama.cpp atribui posições erradas aos tokens de marcador de imagem nos prompts do MiniCPM-V 4.7: os próprios tokens de imagem são posicionados corretamente, mas <slice>, </slice> e os marcadores de fim de linha são numerados como texto simples, em vez de receberem as coordenadas dos cantos do tile como a implementação de referência get_rope_index faz. O sintoma visível é que as coordenadas retornadas ficam sistematicamente baixas quando você pergunta onde algo está em uma imagem. Uma correção com um teste unitário existe como um pull request aberto, datado de 14 de outubro, e, em 20 de outubro, ainda está aberto. Se sua carga de trabalho for "descreva isto", você não vai notar. Se for "me dê a bounding box", você vai notar, e deve esperar pelo merge ou usar o fork que carrega o caminho corrigido.

Mais uma coisa sobrevive à ida e volta: para o modelo 1B, o projetor de visão é o maior download. Os pesos Q4_K_M têm 672 MB; o projetor f16 tem 1,11 GB. A menor implantação útil de 1B é, portanto, cerca de 1,8 GB de arquivos, a maior parte deles olhos em vez de linguagem — um detalhe que qualquer expectativa de que "1B significa 1 GB" erra.

O que executar, e em quê

Se o objetivo é experimentar esta semana, o caminho de menor atrito é o llama.cpp ou o Ollama com os repositórios GGUF, apontando o cliente multimodal para o arquivo mmproj correspondente. Em uma GPU de 24 GB, o Q4_K_M com 21,2 GB deixa muito pouca margem para contexto — uma janela de 8K tokens mais blocos de imagem não caberá confortavelmente, então planeje usar Q4_K_S ou uma quantização menor se também quiser um prompt longo. Em um Mac com 32 GB ou mais, o Q8_0 é viável e é o mais próximo do comportamento de referência. Em um celular, apenas os apps do próprio fabricante e o fork llama.cpp-omni trazem o trabalho de agendamento de especialistas; o llama.cpp padrão entrega correção, não os 20 tok/s.

Onde uma camada de roteamento conquista seu lugar aqui é do outro lado da chamada local. Um modelo de 3B ativos em um telefone é excelente no cenário rotineiro — leia este recibo, esta prateleira parece abastecida, o que diz esta placa — e ocasionalmente encontrará uma página que não consegue concluir. O OrcaRouter coloca mais de 200 modelos hospedados atrás de uma única chave, repassa o preço de tabela de cada provedor com 0% de acréscimo para que uma mudança de preço do fornecedor entre em vigor no mesmo dia, e faz failover automaticamente quando um upstream degrada. O padrão que funciona é local-first com uma saída de emergência hospedada, não somente local. O checkpoint de pesos abertos continua seu para hospedar; o roteador cuida de tudo o que o telefone repassa.

MiniCPM-V 4.7 não é servido pelo OrcaRouter, e não vamos insinuar o contrário. É um checkpoint que você executa.

O que resolveria os três números

Uma medição independente do modelo 35B em um telefone específico, com o aplicativo e a quantização informados, resolveria a questão da vazão — inclusive se 20,51 tok/s sobrevive ao cronômetro de outra pessoa. Uma definição publicada do valor de 3 GB — conjunto residente, alocação de pico ou outra coisa — resolveria a questão da memória. E uma tabela por benchmark com pontuações reais, em vez dos cinco gráficos interligados que a ficha atualmente traz, permitiria verificar a alegação de "melhor que o Qwen3.6 35B-A3B em menos tempo" em relação à ponderação escolhida pela OpenBMB. Nada disso existe ainda. Até que exista, a frase precisa é a mais sem graça: um modelo esparso de 35B que roda em um telefone a mais de 13 tokens por segundo, segundo relatos, em cerca de 3 GB, com um download de 21 GB e um caminho de framework mesclado que ainda tem um bug de coordenada em aberto.