MiniCPM-V 4.7 no iPhone: os 3 GB explicados

O MiniCPM-V 4.7 no iPhone não cabe em 3 GB de RAM. Os 3 GB divulgados pela OpenBMB são a pegada de memória de trabalho, enquanto os cerca de 21,2 GB do arquivo quantizado em 4 bits permanecem no armazenamento flash. A engenharia que conecta os dois números é o tema deste artigo.

MiniCPM-V 4.7 no iPhone: o que os 3 GB realmente contam

Os 3 GB divulgados para o MiniCPM-V 4.7 no iPhone são a memória de trabalho, não o tamanho do modelo. A OpenBMB, laboratório que desenvolve a família MiniCPM, afirma que a variante multimodal de 35 bilhões de parâmetros (35B-A3B) roda a 13+ tokens por segundo em um iPhone 17 Pro Max. Em 2026, esse número circula como manchete, mas a documentação não define se ele mede pico ou média de memória.

A contradição aparece nos próprios arquivos de download. O checkpoint completo em BF16 soma 70,4 GB em 16 fragmentos, e a versão em 4 bits (Q4_KM, formato GGUF usado por ferramentas como o llama.cpp) ocupa 21,2 GB. Divida 21,2 por 3 e o arquivo fica cerca de sete vezes maior que a memória reivindicada. Nenhum modelo inteiro cabe aí.

O que fecha a conta é a leitura correta: os dois números medem coisas diferentes. Os 3 bilhões de parâmetros ativos por token barateiam o cálculo, e os 3 GB representam o conjunto de dados de que o modelo precisa a cada instante. O resto dos pesos espera no flash. Planeje o armazenamento pelos 21,2 GB do arquivo, não pelos 3 GB.

Onde ficam os pesos que não cabem na RAM

Cerca de 18 GB de pesos ficam no armazenamento flash do aparelho, não na memória RAM. Se o iPhone usa um arquivo próximo dos 21,2 GB da versão em 4 bits, e a memória de trabalho é de 3 GB, o resto precisa esperar no disco. Os dois números nunca competiram entre si.

A ideia de manter parâmetros no flash e carregá-los sob demanda vem do artigo da Apple LLM in a Flash, apresentado na ACL de 2024. O trabalho mostra que é viável rodar modelos até duas vezes maiores que a memória disponível e favorece blocos contíguos de dados, que combinam com o padrão de leitura do flash.

Para um paralelo externo, o estudo Paging the Experts (2025), de autoria independente, rodou o Qwen3 35B-A3B — mesma configuração de especialistas — em um iPhone usando Swift e MLX, o framework de aprendizado de máquina da Apple para silício Apple. O estudo mediu picos de memória do processo entre 1,87 e 2,73 GiB, na mesma ordem de grandeza dos 3 GB reivindicados. O sistema é diferente, então o valor serve como escala, não como confirmação.

Por que só 3 bilhões dos 35 bilhões de parâmetros trabalham

O MiniCPM-V 4.7 usa Mixture-of-Experts (MoE), uma arquitetura em que um roteador escolhe, para cada token, um pequeno subconjunto de redes especialistas. O modelo tem 40 camadas, cada uma com 256 blocos especialistas, e o roteador ativa 8 deles por token, além de um especialista compartilhado que sempre roda.

A aritmética sai da configuração publicada, não de um número oficial. Estimando três matrizes por especialista, cerca de 32 bilhões dos 35,2 bilhões de parâmetros vivem nos especialistas roteados. Por token, cada camada lê 8 de 256 especialistas, cerca de 1 em 32, o que dá aproximadamente 1 bilhão de parâmetros roteados ativos. Somando as partes que todo token usa, como o especialista compartilhado, chega-se aos cerca de 3 bilhões ativos.

Essa esparsidade explica por que cada token é barato de calcular. O roteador escolhe de novo no próximo token, então qualquer especialista pode ser convocado a qualquer momento — e é exatamente esse padrão que torna o flash atraente como depósito dos pesos.

Como o LES carrega especialistas do flash sem travar a geração

O Lookahead Expert Scheduling (LES) sobrepõe o carregamento de pesos do flash ao cálculo da camada anterior. Sem essa sobreposição, o gerador esperaria até 40 viagens ao disco por token, uma por camada. A própria documentação da OpenBMB reconhece o problema: sem sobrepor carregamento e computação, as leituras repetidas de pesos atrasam a geração.

O mecanismo usa uma pista entre camadas. A saída de cada camada é somada à sua entrada e passada adiante, então camadas vizinhas veem entradas muito parecidas. O artigo FATE, que estuda outro sistema, relata similaridade de cosseno média acima de 83% entre entradas de camadas vizinhas, com precisão de pré-busca de 97,15% (e 78,79% na decodificação). Isso explica o princípio, mas os números são do sistema do próprio FATE, não do MiniCPM.

Enquanto uma camada calcula, o LES usa a dica do roteador para pré-carregar do flash os especialistas que a próxima camada provavelmente vai pedir. Quando o roteador real escolhe, os especialistas já chegados são computados primeiro e os demais chegam em paralelo. O cálculo segue sempre o roteamento do próprio modelo, sem treino adicional.

O ponto fraco é a taxa de acerto, e é justamente o número que falta. A documentação do LES não descreve o preditor, a precisão, a taxa de acerto, o tamanho do cache nem a política de descarte, e não diz se usa o preditor do FATE. No estudo independente Paging the Experts, um preditor com bloqueio por confiança alcançou apenas 61,31% de precisão e ganho mínimo de velocidade, com um registro de desligamento térmico no iPhone. O blog da Orca Router, fornecedora de roteamento de IA, também sinaliza que os 13 tokens por segundo são afirmação do fabricante, não medida reproduzida. Um acerto de pré-busca alto é a peça decisiva, e o único dado público é o do fornecedor.

Benchmarks do iPad Pro: o que a tabela da OpenBMB mostra

A única tabela publicada, medida pela própria OpenBMB em um iPad Pro de 11 polegadas com chip M4 e 16 GB, mostra a velocidade subindo de 2,97 para 17,39 tokens por segundo. São números do fornecedor, em um iPad Pro de 16 GB — um iPhone comum ou um iPad simples podem se comportar de forma diferente.

Estágio	Velocidade (tokens/s)	Ganho sobre o baseline
Baseline: pesos de especialistas lidos do SSD, sem otimização	2,97	1,00x
LES + layout de pesos contíguo	9,81	3,30x
+ quantização por camada	14,92	5,02x
+ amostragem especulativa D-Spark	17,39	5,86x

Três detalhes merecem atenção. Primeiro, o baseline é uma versão deliberadamente sem otimizações, comparada contra carregamento lento do SSD — não contra um modelo que cabe inteiro na memória. Segundo, a decodificação especulativa, em que um modelo pequeno propõe 15 tokens de uma vez e o modelo grande verifica, adicionou apenas 1,17x sobre o estágio anterior; a OpenBMB não explica o ganho baixo, e a maior parte da aceleração vem do carregamento e da quantização. Terceiro, o anúncio fala em "5x" junto com "pelo menos 17 tokens por segundo", mas o 5x pode ser o estágio de 5,02x enquanto só o conjunto completo atinge os 17.

Sobre qualidade, o anúncio cita 90,4 pontos no OCRBench com compressão de 16x dos tokens visuais, 5,2 pontos à frente do Qwen3 35B-A3B. Um relatório secundário indica que a seção de avaliações do model card traz imagens sem pontuações por benchmark, então o 90,4 segue como número da OpenBMB. A promessa de saídas byte a byte idênticas também não tem um teste descrito que a comprove.

O que ainda não está comprovado

Quatro afirmações seguem abertas em outubro de 2026. Trate cada uma como promessa do fornecedor até que evidência independente apareça.

• O que os 3 GB medem. Nem o model card, nem o README, nem o documento do LES dizem se é pico ou média, nem se cobre o processamento de imagens, o cache de tokens ou o modelo de rascunho da decodificação especulativa.
• A medição no iPhone. Os 13+ tokens por segundo no iPhone 17 Pro Max são afirmação da OpenBMB; ninguém de fora cronometrou.
• Saídas idênticas byte a byte. O anúncio promete, o documento fala em "inferência sem perdas", mas não há teste comparativo descrito.
• Outras plataformas. O lançamento lista suporte no primeiro dia para Apple, Intel, AMD, ARM e Rockchip, sem nenhum resultado medido. Nada indica que uma GPU com 3 GB reproduza o comportamento: o desenho depende de flash rápido e de escrita direta na memória que o chip gráfico lê, um ajuste natural aos dispositivos Apple de memória unificada.

Para quem tem um iPhone ou iPad recente, o mecanismo é crível: pesos no flash, conjunto de trabalho na RAM e carregamento à frente do cálculo têm base sólida. A pergunta aberta é simples. Quando alguém de fora da OpenBMB medir isso em um iPhone real, os acertos de pré-busca bastarão para sustentar 13 tokens por segundo?

Perguntas frequentes

• O MiniCPM-V 4.7 realmente roda com 3 GB de RAM no iPhone? Os 3 GB são a memória de trabalho reivindicada pela OpenBMB, não o modelo inteiro. Os cerca de 21,2 GB de pesos em 4 bits ficam no flash e são carregados sob demanda. A medição no iPhone ainda não foi reproduzida de forma independente.

• Quanto espaço o MiniCPM-V 4.7 ocupa no iPhone? Conte com o tamanho do arquivo, não com os 3 GB anunciados. O GGUF em 4 bits listado pela OpenBMB tem 21,2 GB, e o checkpoint completo em BF16 soma 70,4 GB.

• O que é o LES no MiniCPM-V 4.7? Lookahead Expert Scheduling é a técnica da OpenBMB que pré-carrega do flash os especialistas que a próxima camada provavelmente vai usar, enquanto a camada atual calcula. O cálculo segue o roteamento real do modelo, então erros de previsão só custam tempo de carregamento.

• O LES perde qualidade na saída? A OpenBMB afirma inferência sem perdas e promete saídas byte a byte idênticas, porque o cálculo segue o roteamento original. Porém, nenhum teste comparativo de saídas foi descrito publicamente, então a afirmação segue sem verificação.

• Funciona em GPU com 3 GB de VRAM? Não há evidência para isso. O desenho depende de flash rápido e de escrita direta na memória unificada dos dispositivos Apple, e a OpenBMB não publicou resultados medidos para outras plataformas, apesar de listar suporte no dia do lançamento.

Source video