Um modelo de 35B em um iPhone usando 3 GB? Verifiquei a alegação

Ver no idioma original →

Autoria: Prompt Engineer 48 · Assistir no YouTube

Vídeo de autoria do canal indicado, não da IANIA; todos os direitos pertencem ao criador. Transcrição, resumo e tradução gerados automaticamente; o conteúdo no idioma original é preservado na versão em idioma original.

Idioma original: inglês

Vídeo original: A 35B Model on an iPhone Using 3GB? I Checked the Claim · Canal: Prompt Engineer 48 · 08:22 · Assistir no YouTube

Tópicos: Avaliação e benchmarks de IA, Inferência e otimização de modelos, Infraestrutura e hardware de IA, Modelos locais e open source, Modelos multimodais

Resumo

O vídeo verifica as alegações sobre o MiniCPM-V 4.7 com base no repositório, na página do Hugging Face e nas tabelas de benchmark. O apresentador explica como o look-ahead expert scheduling (LES) sobrepõe o carregamento de especialistas à computação e aponta uma divergência na alegação de desempenho em compressão visual 16x. Em testes locais, o modelo 1B rodou em uma GPU de notebook com 8 GB de VRAM: a compressão 4x leu melhor uma imagem de recibo que a 16x, enquanto o modelo também descreveu um clipe de futebol. O apresentador ressalta que são testes preliminares e que o modelo 35B não foi testado localmente.

Pontos-chave

• O repositório indica licença Apache 2.0 e disponibiliza versões 35B A3B e 1B, além de arquivos GGUF e versões quantizadas.
• No modelo 35B A3B, cerca de 3 bilhões dos 35,2 bilhões de parâmetros ficam ativos por token; o modelo chamado 1B tem aproximadamente 1,55 bilhão de parâmetros.
• O LES antecipa quais especialistas serão necessários na camada seguinte e começa a carregá-los enquanto a camada atual é calculada.
• Segundo a documentação, previsões incorretas de especialistas afetam apenas o prefetch: a computação continua seguindo o roteador real.
• A alegação de 5,2 pontos de vantagem na métrica OCR com compressão 16x não bate com a tabela: a diferença é 4,4 pontos; 5,2 corresponde à compressão 4x.
• Nos testes do apresentador, o modelo 1B usou 3,11 GB de VRAM em BFloat16 e leu corretamente o recibo com compressão 4x.
• No teste do recibo, a compressão 16x produziu erros e atingiu o limite de 300 tokens; a compressão 4x terminou em 111 tokens.
• O teste com um clipe de futebol identificou o placar e os códigos dos times, mas inventou um nome para a equipe BHA.
• O apresentador classifica os testes como uma primeira impressão, não como benchmark, e observa que o vídeo foi gravado no primeiro dia de disponibilidade.

Capítulos

Início	Capítulo	Resumo
00:00	Verificação das alegações e visão geral do modelo	O apresentador confere o repositório e os pesos, explica a arquitetura MoE e descreve o LES.
02:35	Desempenho anunciado e divergência nos benchmarks	O vídeo examina as demonstrações de velocidade, a compressão de tokens visuais e a discrepância na comparação de OCR.
04:44	Testes locais do modelo 1B	O apresentador testa leitura de recibo e descrição de vídeo em uma GPU de notebook com 8 GB de VRAM.
06:50	Compatibilidade, conclusões e limitações	O vídeo comenta fine-tuning e suporte a hardware e software, resume o que foi confirmado e sugere cautela com as alegações.

Citações

As previsões só decidem o que pré-carregar. — 02:05

A manchete mistura as duas colunas. — 04:13

Considere isso uma primeira impressão, não um benchmark. — 06:50

O 5,2 em 16x é, na verdade, o número de 4x. — 07:51

Conceitos e entidades

• MiniCPM-V 4.7 (modelo): Modelo de visão e linguagem cujas alegações de desempenho e requisitos são analisados no vídeo.
• OpenBMB (empresa): Organização associada ao repositório apresentado para o MiniCPM-V.
• Hugging Face (empresa): Plataforma onde estão hospedados os pesos e as versões do modelo mencionadas no vídeo.
• look-ahead expert scheduling (LES) (conceito): Método que prevê os especialistas necessários na próxima camada e antecipa seu carregamento.
• Mixture of Experts (conceito): Arquitetura em que apenas parte dos parâmetros, organizada em especialistas, é ativada para cada token.
• RTX 4060 (ferramenta): GPU de notebook com 8 GB de VRAM usada nos testes locais do modelo 1B.
• Transformers (ferramenta): Biblioteca usada no exemplo de execução e nos testes descritos pelo apresentador.
• llama.cpp (ferramenta): Software listado na documentação como compatível com versões GGUF do modelo.
• SGLang (ferramenta): Software listado na documentação entre as opções de suporte ao modelo.
• vLLM (ferramenta): Software listado na documentação entre as opções de suporte ao modelo.
• Ollama (ferramenta): Software listado na documentação como compatível com versões GGUF do modelo.

Tradução completa (pt-BR)

00:00 Este é um modelo com 35 bilhões de parâmetros, e o repo diz que ele gera mais de 13 tokens por segundo em um iPhone usando apenas 3 GB de memória. Essa é uma gravação de tela feita no próprio celular. Certo, neste vídeo vou conferir essa afirmação comparando-a com a página oficial no GitHub, a página do Hugging Face e as tabelas de benchmark; depois, vou executar a versão de 1B nesta GPU de laptop com 8 GB e mostrar os números reais. E um dos números do anúncio não corresponde ao gráfico. Vou mostrar qual. Então, este é o repo do Open BMV. Mini CPMV, você pode

00:31 ver cerca de 26,5 mil estrelas, 2,1 mil forks, 37 colaboradores, e a licença diz Apache 2.0. O readme foi atualizado duas horas antes de eu capturar esta página, e o lançamento mais recente no GitHub ainda é do ano passado. Então, ainda não há uma tag de lançamento 4.7. Os pesos estão no Hugging Face. Se abrirmos a coleção do Hugging Face, podemos ver o modelo 35B A3B, o modelo 1B, versões GGUF de ambos, um modelo pequeno chamado Deep Spark e versões quantizadas em FP8, GPTQ, AWQ,

01:03 e INT4. Vale lembrar que tudo isso foi atualizado cerca de duas horas antes de eu fazer esta captura de tela. Então, os números de downloads aqui são minúsculos. É o primeiro dia. O readme diz que o 35B A3B é o primeiro modelo de mistura de especialistas da série Mini CPMV. A3B significa que cerca de 3 bilhões de parâmetros ficam ativos para cada token, de um total de 35,2 bilhões; e o 1B não tem exatamente 1 bilhão. A página da coleção arredonda para 2B, e os dados do modelo indicam cerca de 1,55 bilhão. Aqui está o problema.

01:33 O readme descreve que um modelo de mistura de especialistas precisa manter todos esses pesos dos especialistas em algum lugar, e um celular não consegue manter 35 bilhões de parâmetros na memória. Você pode deixar os pesos no armazenamento e carregar um especialista sempre que o roteador solicitar. Mas, nesse caso, cada camada espera por uma leitura, e a decodificação fica lenta demais para ser útil. Outra opção é congelar um pequeno conjunto de especialistas para todo o prompt. Isso é rápido. Mas o readme ressalta que isso pode excluir especialistas que o modelo teria escolhido, o que reduz a capacidade. A solução se chama agendamento de especialistas com antecipação, LES. Enquanto o celular calcula a camada N, ele

02:05 prevê de quais especialistas a camada N + 1 vai precisar e começa a carregá-los naquele momento. Assim, o carregamento e a computação se sobrepõem. Esta é a parte que eu queria verificar. Se a previsão estiver errada, a resposta muda? O readme diz que não. As previsões só determinam o que será pré-carregado. A computação continua seguindo o roteador real, e qualquer especialista que não tenha sido previsto é carregado e usado normalmente. O anúncio diz que as saídas são idênticas byte por byte. Não encontrei essa frase exata nas páginas, mas o fato de o pré-carregamento ser a única função do sistema torna isso plausível. Então, vou tratar isso como uma afirmação.

02:35 Aqui está a gravação do repo, antes e depois da otimização, lado a lado. Olhe o indicador de velocidade de decodificação abaixo da resposta. Antes da otimização, ele fica em 2,0 tokens por segundo. Depois, varia entre cerca de 6 e 12. E aqui está o 35B 83B no iPad, sem edição. O prompt é um gráfico de 1812 que pergunta qual foi a temperatura mais baixa em Celsius, com uma breve explicação da conversão. Ele encontra -30° Réaumur em 6 de dezembro, multiplica por 1,25 e responde -37,5 Celsius. Está correto.

03:07 O aumento de velocidade de 5x mencionado no anúncio foi medido em um iPad Pro M4 com 16 GB, e o anúncio diz que ali a velocidade passa de 17 tokens por segundo. A própria página do repo só informa o número do iPhone. E lembre-se: os 13 tokens por segundo resultam da combinação de LES, quantização por camada e amostragem especulativa do DeepSpark. Então, não dá para aplicar LES a outro modelo e esperar um aumento de 5x. A segunda ideia são os tokens de imagem. O modelo comprime os tokens visuais logo no início, dentro do codificador visual, e você escolhe 4x para obter detalhes ou 16x para uma

03:40 inferência mais barata. No exemplo com Transformers, basta uma linha: downsample mode = 16x. Agora, a tabela de benchmark. Este é o gráfico de visão e linguagem do repo: 35B 83B em comparação com QN 3.6 35B 83B, QN 3.27B, QN 3.8 27B e Gemma 431B. Veja a linha do OCR bench: em 4x, a pontuação é 91,2; em 16x, 90,4. O QN 3.6 35B A3B marca 86,0. Então, há um número que

04:13 não corresponde. O anúncio diz que, mesmo em 16x, a vantagem é de 5,2 pontos. 90,4 - 86 = 4,4. Os 5,2 são da pontuação em 4x: 91,2 - 86; ainda é uma vantagem. Mas a manchete mistura as duas colunas. Nos dois gráficos, há 26 linhas de visão e oito linhas de linguagem. Portanto, os 34 benchmarks mencionados no anúncio conferem. O gráfico de visão destaca o novo modelo como o melhor em 15 das 26 linhas. No gráfico de linguagem, ele é o melhor em duas das oito: CMMLU e Towel Squared bench. E fica

04:44 atrás no AIM, no Life Code bench e no IF bench. Então, é um modelo de visão forte e competitivo em texto, mas não vence em tudo. E estes são os números dos próprios laboratórios, de relatórios públicos e avaliações locais, como diz a nota de rodapé. Agora, vamos testar. Vale lembrar que tudo aqui está sendo executado no meu sistema local: uma GPU de laptop RTX 4060 com 8 GB de VRAM. O 35B não vai caber aqui, então vou testar o 1B. E todos os números a partir de agora são do 1B. Ele carrega em cerca de 15 segundos quando os arquivos

05:15 estão no disco e ocupa 3,11 GB de VRAM em BFloat16. Primeiro teste: eu mesmo gerei uma imagem de recibo, com texto pequeno em fonte monoespaçada, quatro itens, um subtotal, GST, um total e uma referência UPI. O mesmo prompt, com duas configurações. Com compressão de 16x, dá para ver que ele coloca cifrões antes de todos os preços, embora não haja cifrões neste recibo. Também coloca um subtotal abaixo de cold brew e outro abaixo de veg sandwich, e continua até atingir meu limite de 300 tokens. Ele acertou o total, 26,51, e a referência UPI,

05:48 certo? Com 4x, o mesmo modelo lê os quatro itens com os preços corretos, o subtotal, o GST, o total e a referência. Sem cifrões, e termina em 111 tokens, em 12,7 segundos. A execução em 16x levou 35 segundos porque foi até o limite. A velocidade fica em cerca de 8,6 tokens por segundo nos dois casos, nesta placa. Não instalei os kernels rápidos recomendados pelo Transformers.ai, então ele está usando um caminho alternativo mais lento, e eu não interpretaria isso como o máximo que esta placa consegue fazer. Segundo teste: vídeo, o

06:20 clipe de futebol dos exemplos do Hugging Face, com 37 segundos, compressão de 16x e até 128 quadros. Isso dá 2.607 tokens de prompt, e o pico de VRAM chega a 4,23 GB. Olhe o placar: BHA contra MCI, 00, com o selo de jogo ao vivo. Nos quadros que amostrei, o relógio vai de 22:32 a 23:02, e as estimativas dos modelos vão de 22:29 a 23:05. É bem próximo. Ele acertou o placar, o selo de jogo ao vivo e as siglas dos times. Também inventou um nome. Ele

06:50 chamou BHA de Blue Helmets, e o restante da descrição é genérico. A bola avança, os jogadores se aproximam. 8,81 tokens por segundo. Então, neste laptop, o 1B é utilizável e, no meu teste do recibo, 4x foi a melhor configuração para texto pequeno. Isso é apenas uma imagem e um clipe. Portanto, considere isto uma primeira impressão, não um benchmark. Mais duas coisas da página: fine-tuning por autorrepetição. O readme diz que isso permite adicionar uma capacidade a baixo custo, esquecendo menos do que o modelo já sabe. Não treinei nada,

07:20 então não posso dizer o quanto funciona bem. E, quanto ao hardware, o readme lista iOS, Android e Harmony OS, além de suporte desde o primeiro dia para Intel, AMD, ARM, Rockchip e Homo. O anúncio também cita Flag OS, mas não encontrei isso nas páginas que consultei. Para software, lista SGLang, vLLM, llama.cpp e Ollama com versões GGUF, AWQ, GPTQ e FP8. Então, foi isto que concluí. Confirmados nas páginas: Apache 2.0, 35B, LES 3B mais 1B apenas como pré-carregamento, mais de 13

07:51 tokens por segundo com 3 GB no iPhone e 34 benchmarks nos dois gráficos. Não constam nas páginas: saídas idênticas byte por byte, mais de 17 no iPad e a diferença de 5,2 em 16x, que na verdade corresponde ao número em 4x. No meu teste, o 1B usa cerca de 3 GB de VRAM em um laptop, lê corretamente um recibo em 4x e cometeu erros em 16x. Se você quer um modelo de visão pequeno em um laptop, experimente o 1B e use 4x para imagens com muito texto. Se você quer o 35B, precisa de uma GPU potente ou de um modelo recente

08:22 iPhone ou iPad, e este é o primeiro dia, então espere algumas arestas. Se você está procurando GPUs baratas e confiáveis, eu uso RunPod, e o link está na descrição. Então, neste vídeo, verificamos as afirmações sobre o MiniCPM-V 4.7 comparando-as com o repo, a página do Hugging Face e os gráficos, e testamos o modelo 1B neste laptop. Experimente no seu próprio sistema e me conte como foi. Em seguida, vou colocar o modelo 35B em uma GPU alugada e executar os mesmos prompts. Vejo você no próximo.

Transcrição original

[00:00] This is a 35-billion parameter model, and the repo says it generates 13 plus tokens per second on an iPhone using just 3 GB of memory. That is a screen recording from the phone itself. All right, in this video I’m going to check that claim against the actual GitHub page, the Hugging Face page, and the benchmark tables, and then run the 1B version on this 8-GB laptop GPU and show you the real numbers. And one number in the announcement does not match the chart. I’ll show you which one. So, this is the Open BMV repo. Mini CPMV, you can

[00:31] see about 26 and 1/2 thousand stars, 2.1 thousand forks, 37 contributors, and the license says Apache 2.0. The readme was updated 2 hours before I captured this page, and the latest GitHub release is still from last year. So, there’s no 4.7 release tag yet. The weights are on Hugging Face. If we open the Hugging Face collection, you can see the 35B A3B model, the 1B model, GGUF versions of both, a small one called Deep Spark, and quantized versions in FP8, GPTQ, AWQ,

[01:03] and INT4. Mind you, all of this was updated about 2 hours before I took this screenshot. So, the download numbers here are tiny. It is day one. The readme says the 35B A3B is the first mixture of experts model in the Mini CPMV series. A3B means about 3 billion parameters are active for each token out of 35.2 billion in total, and the 1B is not exactly 1 billion. The collection page rounds it to 2B, and the model data says about 1.55 billion. Here is the problem.

[01:33] The readme describes a mixture of experts model has to keep all those expert weights somewhere, and a phone cannot hold 35 billion parameters in memory. You can leave the weights in storage and load an expert whenever the router asks for it. But then, every layer waits for a read, and decoding becomes too slow to use. You could also freeze a small set of experts for the whole prompt. That is fast. But the readme points out it can exclude experts the model would have chosen and that costs capability. The fix is called look-ahead expert scheduling, LES. While the phone is computing layer N, it

[02:05] predicts which experts layer N + 1 will need and starts loading them right then. So, loading and computing overlap. Here is the part I wanted to check. If the prediction is wrong, does the answer change? The readme says no. Predictions only decide what to prefetch. The computation still follows the real router and any expert the prediction missed is loaded and used as normal. The announcement says the outputs are byte for byte identical. I could not find that exact phrase on the pages, but the prefetch only design is why it is believable. So, I’ll call it a claim.

[02:35] Here’s the recording from the repo before and after optimization side by side. Look at the decode speed label under the answer. Before optimization, it stays at 2.0 tokens per second. After, it moves between about 6 and 12. And here is the 35B 83B on the iPad unedited. The prompt is a chart from 1812 asking for the coldest temperature in Celsius with a short explanation of the conversion. It finds -30° Réaumur on December 6th, multiplies by 1.25, and answers -37.5 Celsius. That is correct.

[03:07] The 5x speedup in the announcement was measured on an iPad Pro M4 with 16 GB, and the announcement says 17+ tokens per second there. The repo page itself only gives the iPhone number. And remember, 13 tokens per second is LES, layer-wise quantization, and DeepSpark speculative sampling stacked together. So, you cannot copy LES onto another model and expect 5x. Second idea is image tokens. The model compresses visual tokens early inside the vision encoder, and you pick 4x for detail or 16x for cheaper

[03:40] inference. In the Transformers example, it is one line, downsample mode = 16x. Now, the benchmark table. This is the vision-language chart from the repo, 35B 83B against QN 3.6 35B 83B QN 3. 27B, QN 3.8 27B, and Gemma 431B. Look at the OCR bench row at four times, it scores 91.2 and at 16 times, 90.4. QN 3.6 35B, A3B scores 86.0. So, here’s a number that

[04:13] does not match. The announcement says that even at 16 times, it is 5.2 points ahead. 90.4 - 86 is 4.4. The 5.2 is the four times score, 91.2 - 86, still ahead. But, the headline mixes the two columns. Across the two charts, there are 26 vision rows and eight language rows. So, the 34 benchmarks in the announcement checks out. The vision chart highlights the new model as best in 15 of the 26 rows. On the language chart, it is best in two of eight, CMMLU and Towel Squared bench. And it is

[04:44] behind on AIM, Life Code bench, and IF bench. So, it is a strong vision model that is competitive on text, not a clean sweep. And these are the labs’ own numbers from public reports and local evaluation, which is what the footnote says. Now, let’s go ahead and test this. Mind you, everything here is running on my local system, an RTX 4060 laptop GPU with 8 GB of VRAM. The 35B will not fit here, so I’m testing the 1B. And every number from now on belongs to the 1B. It loads in about 15 seconds once the files

[05:15] are on disk and sits at 3.11 GB of VRAM in BFloat16. First test, I generated a receipt image myself, small monospace text, four items, a subtotal, GST, a total, and a UPI reference. Same prompt, two settings. At 16 times compression, you can see it writes dollar signs in front of every price, and there are no dollar signs on this receipt. It also puts a subtotal under cold brew and again under veg sandwich, and then it runs all the way to my 300 token limit. It did get the total 26.51 and the UPI

[05:48] reference, right? At four times, the same model reads all four items with the correct prices, the subtotal, GST, the total, and the reference. No dollar signs, and it finishes in 111 tokens, 12.7 seconds. The 16 times run took 35 seconds because it ran to the limit. Speed is about 8.6 tokens per second in both cases on this card. I did not install the fast kernels that Transformers.ai asks for, so it is running a slower called back path, and I would not read this as the best this card can do. Second test video, the

[06:20] football clip from the Hugging Face examples, 37 seconds, 16 times compression, up to 128 frames. That is 2607 prompt tokens, and peak VRAM goes to 4.23 GB. Look at the scoreboard, BHA against MCI 00 with the live badge. In the frames I sampled, the clock runs from 22:32 to 23:02, and the models range 22:29 to 23:05. is close. It got the score, the live badge, and the team codes. It also invented a name. It

[06:50] called BHA the Blue Helmets, and the rest of the description is generic. The ball moves forward, players converge. 8.81 tokens per second. So, on this laptop, the 1B is usable, and in my receipt test, four times was the better setting for small text. That is one image and one clip. So, take it as a first look, not a benchmark. Two more things from the page, self-replay fine-tuning. The readme says it lets you add a capability cheaply while forgetting less of what the model already knows. I did not train anything,

[07:20] so I cannot tell you how well it works. And hardware, the readme lists iOS, Android, and Harmony OS, and day zero support for Intel, AMD, ARM, Rockchip, and Homo. The announcement also names Flag OS, and I could not find that on the pages I checked. For software, it lists SGLang, vLLM, llama.cpp, and Ollama with GGUF, AWQ, GPTQ, and FP8 versions. So, here’s where I landed. Confirmed on the pages, Apache 2.0, 35B, 3B plus 1B LES as prefetch only, 13 plus

[07:51] tokens per second with 3 GB on iPhone, and 34 benchmarks across the two charts. Not on the pages, byte-for-byte identical outputs, 17 plus on the iPad, and the 5.2 gap at 16 times, which is really the four times number. From my test, the 1B runs in about 3 GB of VRAM on a laptop, reads a receipt correctly at four times, and made mistakes at 16 times. If you want a small vision model on a laptop, try the 1B and use four times for text-heavy images. If you want the 35B, you need a big GPU or a recent

[08:22] iPhone or iPad, and it is day one, so expect rough edges. If you are looking for cheap and reliable GPUs, I use RunPod, and the link is in the description. So, in this video, we checked the MiniCPM-V 4.7 claims against the repo, the Hugging Face page, and the charts, and tested the 1B on this laptop. Try it on your own system, and let me know how it goes. Next, I’ll put the 35B on a rented GPU and run the same prompts. I’ll see you in another one.