O "3B de Parâmetros Ativos" do MiniCPM-V 4.7 não está na ficha do modelo — eu o medi a partir dos pesos

O número mais repetido sobre o MiniCPM-V 4.7 35B-A3B não aparece em lugar algum na sua própria documentação. A alegação — “apenas 3B de parâmetros ativos (!) — roda até em um iPhone” — vem de uma postagem de terceiros em 13 de outubro de 2026, e a ficha do modelo, o README do repositório e as notas de lançamento do fornecedor nunca informam nenhum número de parâmetros ativos. Isso não é tanto uma crítica à alegação quanto uma lacuna que vale a pena fechar: o checkpoint codifica a própria resposta. Então, antes de qualquer outra coisa aqui, puxei o índice safetensors e cada cabeçalho de shard de openbmb/MiniCPM-V-4.7-35B-A3B e contei. Para comparação, o outro modelo na mesma postagem — Qwen3.8-27B, lançado em 13 de agosto de 2026 — é um denso de 27B e não tem essa ambiguidade a resolver: todos os parâmetros estão ativos em todos os tokens. A pergunta interessante é se “3B ativos” sobrevive ao contato com os pesos, e a resposta é: sobrevive, mas só se você definir a palavra “ativo” do jeito do fornecedor, e o número honesto fica mais próximo de 4B quando você conta as partes que não pode evitar executar.

O livro-razão, lido a partir do próprio checkpoint

O arquivo de índice lista 40 camadas de linguagem, além de uma torre de visão e um projetor, 35.212.875.824 parâmetros no total em BF16 — 70,43 GB de pesos para baixar. Isso corresponde ao "35B" no nome. A questão do MoE é que fração disso é tocada por token:

• Total armazenado — 35,21B parâmetros, 70,43 GB em BF16. Todos os especialistas estão no disco, sejam usados ou não.

• Orçamento do roteador — 8 especialistas selecionados por token, entre 256, por camada MoE. Configurado em config.json como num_experts_per_tok: 8. Cada especialista é pequeno: 3,15 milhões de parâmetros.

• Caminho MoE por camada — 8 especialistas (25,17M) + um especialista compartilhado (3,15M) + o portão do roteador (0,52M) ≈ 28,83M.

• Caminho de atenção por camada — a arquitetura é híbrida: 30 das 40 camadas usam atenção linear (33,72M cada), 10 usam atenção completa (27,26M cada). Total ≈ 2,44B em todas as 40 camadas para atenção mais aritmética do MoE, repetido por token.

• Além do que você não pode pular — embeddings de tokens 508,2M, cabeça LM 508,2M, torre de visão 522,3M, projetor 30,7M.

• As duas respostas defensáveis — ~2,44B ativos apenas no caminho de atenção e MoE; ~4,01B se você contar embeddings, cabeça de saída, torre de visão e projetor, que uma requisição de visão de fato aciona.

Então, "3B ativos" não está errado. É um arredondamento de 2,44B para cima, e cai no intervalo entre os dois números acima. Só que não é um número que a OpenBMB publicou, e não é a mesma coisa que o sufixo "A3B" — esse sufixo faz parte do nome do modelo, e os próprios materiais do fornecedor nunca o transformam em uma medida.

Por que o sufixo e o número não são a mesma coisa

As convenções de nomenclatura em todo o ecossistema de pesos abertos implicam uma contagem de parâmetros ativos: um modelo chamado 30B-A3B, ou 235B-A22B, está dizendo que ativa aproximadamente essa quantidade de parâmetros por token. A implicação geralmente é confiável — mas é uma convenção, não um contrato, e o MiniCPM-V 4.7 é um caso em que nada no card, no README ou no post de lançamento converte o "A3B" em um número com o qual você possa planejar a memória. Até que alguém faça a contagem, o sufixo é um rótulo.

A contagem acima é aritmética, não uma inferência a partir desse rótulo. É também a razão pela qual os números de ~2,44 B e ~4,01 B diferem: contar ou não a tabela de embeddings e a cabeça de saída é uma decisão real, não pedantismo. Em um modelo denso, os embeddings são uma pequena fração de um orçamento de 27B. Em um modelo esparso, em que o caminho de computação por token tem apenas alguns bilhões de parâmetros, uma tabela de embeddings de 508M e uma cabeça LM de 508M já não são ruído — juntas, representam cerca de um quinto do caminho ativo, e são armazenadas em largura total enquanto os especialistas são quantizados.

Uma consequência que vale a pena afirmar claramente: a proporção entre parâmetros armazenados e ativos aqui é de cerca de 8,8 para 1 na leitura restrita. É exatamente por isso que um modelo de 35B pode ser apresentado como um modelo de celular, e também é por isso que ele não é um no sentido em que um modelo denso de 3B é. O armazenamento não diminui quando o roteador ignora um especialista.

A afirmação sobre o iPhone é uma afirmação separada, com uma base de evidências separada.

Tudo o que é concreto sobre o desempenho no dispositivo nesta versão é informado pelo fornecedor e não reproduzido. O número específico é 13+ tokens por segundo com cerca de 3 GB de memória em um iPhone 17 Pro Max, com o mesmo checkpoint demonstrado em um iPad M4. A OpenBMB atribui isso a três técnicas que trabalham em conjunto — Lookahead Expert Scheduling, que prevê o roteamento entre camadas e faz prefetch de especialistas, quantização refinada camada por camada, e amostragem especulativa DSpark — e descreve o resultado como o primeiro modelo MoE de código aberto a rodar suavemente no dispositivo sem perder capacidade. Não há medição independente dessa taxa de processamento no registro público, nenhuma reprodução por terceiros e nenhum detalhamento publicado de qual quantização o valor de 3 GB pressupõe.

Isso importa por um motivo específico: 3 GB é o número que determina se a afirmação é interessante para você, e é o número sobre o qual sabemos menos. Um MoE de 35B cujos pesos de especialistas ficam majoritariamente em armazenamento flash não é um modelo de 3 GB; é um modelo cujo conjunto de trabalho residente por acaso cabe em 3 GB quando previsões de roteamento, pré-busca e um cache de especialistas quantizado estão todos fazendo o seu trabalho. Essas são exatamente as condições sob as quais o throughput de benchmark e o throughput do mundo real divergem — o primeiro prompt aquece o cache, e o comportamento que lhe dá 13 tokens por segundo em uma demonstração é um agendamento, não uma propriedade dos pesos.

Trate os 13 tokens por segundo como uma afirmação sobre uma técnica, não sobre o checkpoint. O checkpoint é o que você pode verificar hoje: 35,21B armazenados, 8 de 256 especialistas roteados por token, ~2,44B a ~4,01B ativos dependendo do que você conta, Apache-2.0, quantizações day-0 em GGUF, AWQ, GPTQ, int4 e FP8, e uma lista de fornecedores de chips suportados que inclui Rockchip, Houmo, Intel, AMD e Arm.

O que a contagem ativa decide e o que não decide

A contagem de parâmetros ativos é um proxy de computação. Ela informa quanta multiplicação de matrizes ocorre por token, o que se traduz na velocidade de execução de uma decodificação limitada pela GPU. Ela não informa quanta memória você precisa para armazenar o modelo, que é regida pelo total — 70,43 GB de pesos BF16, ou aproximadamente um quarto disso em 4 bits, antes de considerar um cache KV. Em um modelo com contexto de 256K, esse cache também não é desprezível.

• Velocidade de decodificação — determinada pelos parâmetros ativos (~2,44B–4,01B aqui). É a isso que se refere a afirmação de 13 tokens/s.

• Memória residente — regida pelo total de parâmetros (35,21B armazenados), depois cortada pela quantização e por qualquer conjunto de especialistas que permaneça residente.

• Armazenamento e carregamento — governados pelo total de 70,43 GB em BF16. O roteamento esparso não reduz o download.

• Largura de banda, não flops — em um celular, a restrição determinante é fazer os especialistas passarem por um barramento de memória, e é por isso que a técnica de escalonamento existe e por que apenas a contagem de ativos não prevê nada sobre a latência móvel.

A conclusão prática: se você tem uma GPU com memória suficiente para armazenar os pesos quantizados, a contagem de ativos é o que determina sua vazão, e "3B ativos" é uma coisa boa. Se você é o motivo pelo qual a frase "roda em um iPhone" aparece em um post, a contagem total é o número que decide a viabilidade, e o trabalho de agendamento do fornecedor é a parte que torna a contagem total suportável. As duas leituras da mesma manchete estão corretas e não são a mesma leitura.

A comparação naquele post precisa de dois rótulos, não de um.

O enquadramento que fez isto circular foi o de hardware local versus hardware caro: o MiniCPM-V 4.7 35B-A3B como o modelo que te dá a mesma capacidade sem a máquina, contra o Qwen3.8-27B como o modelo que era mais inteligente mas precisava da máquina. A metade da capacidade vem do próprio model card do Qwen, e é comunicada pelo fornecedor como tudo o resto nesta página. Os números publicados do Qwen para o Qwen3.8-27B incluem 90,3 no LiveCodeBench v6, 89,2 no GPQA Diamond, 84,3 no OSWorld-Verified e 79,0 no QwenSWEBench, e a nossa própria entrada de catálogo para ele assinala esses valores como resultados agênticos e de código invulgarmente fortes para um modelo denso de 27B. Se era «mais inteligente do que o Opus 4.6» é uma afirmação do post nas redes sociais, e não tenho nenhuma avaliação independente à minha frente que o esclareça — por isso não vou repeti-la como facto.

A diferença estrutural é a que é realmente verificável: o Qwen3.8-27B é denso, portanto os seus 27B de parâmetros estão todos ativos e a sua pegada de memória e a sua conta de computação são o mesmo número. O MiniCPM-V 4.7 35B-A3B separa esses dois números por um fator de aproximadamente nove. Esse é todo o argumento arquitetural, e ele é real. Só que não é o mesmo que uma comparação de benchmarks, e o post que o tornou famoso misturou as duas coisas.

Onde um roteador altera a decisão, e onde não.

Duas coisas são verdadeiras aqui e vale a pena separá-las, porque apontam em direções opostas.

A primeira é que não disponibilizamos o MiniCPM-V 4.7. Ele não está no nosso catálogo. Se o quiser, o caminho é o seu próprio hardware — que é exatamente para isso que o lançamento foi concebido, com pesos, quantizações e guias de implementação no dispositivo publicados juntamente com ele. Nada numa API alojada ajuda a executar um modelo num telemóvel, e seria enganador sugerir o contrário.

A segunda é que o modelo com o qual este está sendo comparado não está nessa posição. O Qwen3.8-27B está disponível através da nossa API, auto-hospedado na nossa própria infraestrutura, a US$ 0,33 por milhão de tokens de entrada e US$ 2,40 por milhão de tokens de saída. Se a pergunta que você está realmente fazendo é "devo substituir minhas chamadas hospedadas do Qwen3.8-27B por um MiniCPM-V 4.7 implantado localmente", a versão honesta da resposta é que você deve executar o experimento antes de se comprometer: o número de throughput no dispositivo não foi reproduzido, e a comparação de capacidade é a própria ficha da outra parte. É para essa situação que o failover existe — encaminhe uma fração do tráfego por um novo caminho, mantenha o comprovado atrás dele e deixe que uma semana ruim lhe custe uma fração de uma carga de trabalho em vez da carga de trabalho inteira. Um modelo com 0% de markup também mantém a aritmética honesta: quando um fornecedor muda um preço, o número que você paga se altera no mesmo dia, porque não há camada de margem entre o preço de tabela deles e a sua fatura.

O que um roteador não consegue fazer é eliminar a questão entre local e hospedado. Essa é decidida pelo seu hardware, pelas suas restrições de privacidade e por se um download de 70 GB é aceitável — e a contagem de parâmetros ativos, não importa como você a arredonde, não altera nenhuma das três.

O que resolveria isso

Três coisas, por ordem decrescente de utilidade. Um número de parâmetros ativos publicado pela OpenBMB, para que o número que todos repetem deixe de ser aritmética de terceiros — incluindo a minha, e a minha é reproduzível a partir dos cabeçalhos dos shards se discordar dela. Uma medição independente dos 13 tokens por segundo num telemóvel, com as configurações de quantização indicadas, porque um valor dependente do escalonamento sem as suas configurações não é uma especificação. E uma avaliação real que compare o MiniCPM-V 4.7 35B-A3B com o Qwen3.8-27B nas mesmas tarefas, visto que a comparação que tornou este modelo notável é atualmente o gráfico de um fornecedor contra a ficha de outro fornecedor.

Até então, o resumo seguro é mais estreito que o post: os pesos são reais, a esparsidade é real, o download é de 70,43 GB e, por token, o modelo realiza um trabalho equivalente a algo entre 2,4 e 4 bilhões de parâmetros, dependendo de como você conta as partes que não dá para contornar por roteamento. Esse é um resultado genuíno de engenharia. Ainda não é um benchmark medido em celular, e não é uma vitória em benchmark sobre um modelo denso de 27B.

Fontes: parâmetros, contagem de especialistas, tipos de camada, comprimento de contexto e tamanho do download foram lidos diretamente de config.json e dos cabeçalhos dos shards safetensors de openbmb/MiniCPM-V-4.7-35B-A3B em 13 de outubro de 2026. A velocidade no dispositivo, o valor de memória, os resultados de benchmark e os números da avaliação do Qwen3.8-27B são informados pelo fornecedor e não reproduzidos. As alegações de "3B parâmetros ativos" e "mais inteligente que o Opus 4.6" originam-se de uma postagem de terceiros em rede social, não de nenhum dos fornecedores.

Nada disso é hipotético: as falhas de IA documentadas e os incidentes com agentes em que um número como este é citado estão reunidos no OrcaRouter AI Incident Archive, onde cada entrada traz suas próprias fontes, severidade, grau de confiança e indicador de contestação.