Moondream 3 vs MiniCPM-V 4.7: A conta de armazenamento do MoE que ninguém menciona

Tanto Moondream 3 Preview quanto MiniCPM-V 4.7 são modelos de visão e linguagem com mistura de especialistas, e ambos são anunciados com um pequeno número de parâmetros ativos que faz parecer que cabem em hardware modesto. O Moondream 3 Preview ativa 2B de seus 9B parâmetros por token. A variante principal do MiniCPM-V 4.7, MiniCPM-V 4.7 35B-A3B, ativa cerca de 3B de 35B. Ao ler essas duas frases, você esperaria que o checkpoint do Moondream fosse o mais fácil de implantar. Se isso é verdade depende inteiramente de uma pergunta com a qual nenhum post de lançamento abre: onde ficam os especialistas adormecidos?

Essa pergunta é onde esses dois modelos realmente divergem, e a resposta é a razão de existir do MiniCPM-V 4.7 na forma como existe. Seu lançamento — MiniCPM-V 4.7 35B-A3B e MiniCPM-V 4.7 1B, da OpenBMB, publicado em 6 de outubro de 2026 — foi construído em torno de executar um MoE de 35B suavemente em um telefone sem degradá-lo. O Moondream 3 Preview, que a Moondream lançou em 18 de setembro de 2025 e que agora faz parte da Prime Intellect após a aquisição de outubro de 2026, seguiu o caminho oposto: manter o MoE pequeno e executá-lo em GPUs com o Photon, o próprio motor de inferência da Moondream. Nenhuma das escolhas está errada. Elas são respostas a restrições diferentes, e a restrição sob a qual você está decide a comparação para você.

Os parâmetros ativos são um número de computação, não um número de armazenamento.

Esta é a aritmética que torna o MoE no dispositivo difícil, e a OpenBMB deixa isso claro em seu próprio cartão de modelo: um modelo MoE pode ter muito mais parâmetros totais do que ativa para um único token, mas seus requisitos de armazenamento no dispositivo não se limitam a esses parâmetros ativos. Tokens diferentes selecionam especialistas diferentes em camadas diferentes, e a memória do dispositivo muitas vezes não consegue armazenar todos eles.

• Moondream 3 Preview — 9B no total, 2B ativos. 24 camadas, as primeiras quatro densas, o restante blocos feed-forward MoE com 64 especialistas e 8 ativados por token. Dimensão oculta 2048, dimensão interna/gate GeGLU 1024.

• MiniCPM-V 4.7 35B-A3B — 35B no total, aproximadamente 3B ativos. O primeiro MoE da série MiniCPM-V. A variante de 1B do mesmo lançamento é densa, não MoE, o que será relevante mais adiante.

• A disparidade — divida os ativos pelo total e o Moondream 3 Preview parece o modelo mais leve por uma grande margem. Divida bytes por bytes e o MiniCPM-V 4.7 35B-A3B é o que carrega quatro vezes os pesos.

• Por que isso não resolve nada — o conjunto residente é o que restringe o dispositivo, e o conjunto residente está mais próximo do total do que a contagem ativa. Um MoE de 9B não cabe na memória em que um modelo denso de 2B cabe, não importa o que o roteador acione.

Portanto, “2B active” é uma afirmação sobre a computação por token. Não é uma afirmação sobre a memória de que você precisa, e tratá-la como se fosse é a forma mais comum de as equipes dimensionarem mal uma implantação de MoE.

A OpenBMB atacou diretamente o problema de armazenamento

O design do MiniCPM-V 4.7 é melhor interpretado como três técnicas voltadas exatamente para essa lacuna. O Lookahead Expert Scheduling usa previsão de roteamento entre camadas para pré-carregar especialistas que a próxima camada provavelmente vai querer, e prioriza os que foram pré-carregados com sucesso entre aqueles que o roteador real selecionou — a previsão orienta apenas o pré-carregamento e o escalonamento, enquanto a computação continua seguindo o roteamento original em nível de token do modelo, e qualquer especialista necessário que a previsão tenha deixado passar é carregado e avaliado normalmente. A quantização refinada por camada reduz a pegada de armazenamento e o tráfego de memória dos pesos dos especialistas. A amostragem especulativa DSpark é integrada ao caminho no dispositivo para melhorar a eficiência de decodificação além das duas anteriores.

O resultado declarado é de mais de 13 tokens por segundo com cerca de 3 GB de memória em um iPhone 17 Pro Max, que a OpenBMB descreve como o primeiro modelo MoE de código aberto a rodar suavemente no dispositivo sem comprometer o desempenho. Sua comparação é explícita e vale a pena observar pelo que é: no modo Instruct, o MiniCPM-V 4.7 35B-A3B alcança uma pontuação geral mais alta em menos tempo de inferência do que o Qwen3.6 35B-A3B. Essa é uma alegação, relatada pelo fornecedor, de mesma classe de tamanho, e é o tipo mais útil, porque ambos os modelos são medidos no mesmo harness.

O resto da história de implantação é incomumente amplo. iOS, Android e HarmonyOS são suportados, com suporte day-0 para plataformas de chips da Rockchip, Houmo, Intel, AMD e Arm. A inferência é executada em SGLang, vLLM, llama.cpp e Ollama; o ajuste fino, em SWIFT e LLaMA-Factory. As quantizações GGUF, BNB, AWQ e GPTQ são disponibilizadas, além de FP8. A variante de 1B é, mais uma vez, uma proposta separada — densa, não MoE — e a OpenBMB posiciona-a como um modelo que continua a melhorar o MiniCPM-V 4.6, ao mesmo tempo que supera substancialmente o Qwen3.5 0.8B tanto na pontuação geral quanto na eficiência de inferência, que é a comparação honesta para um modelo abaixo de 1B.

A resposta do Moondream foi mover o hardware, não os pesos.

O Moondream não tentou fazer um MoE de 9B caber em um celular. Ele manteve a arquitetura e mudou onde ela é executada: o Photon, seu motor de inferência, compila cada modelo em um único programa de GPU com kernels personalizados e roda localmente em GPUs NVIDIA a partir do Ampere e em Macs com Apple Silicon, com a mesma API do Moondream Cloud.

Esta é uma estratégia defensável, e o anúncio de aquisição da Prime Intellect explica por que ela era atraente: a equipe da Moondream criou o Photon e o compilador de megakernel por trás dele, e o argumento da Prime para comprar a empresa é que é a inferência, e não a arquitetura, que decide a utilidade de um modelo. Os números de throughput naquele post — mais de 60 inferências do Moondream por segundo em uma única H100, respostas em dezenas de milissegundos, Moondream 3.1 a 34 solicitações por segundo — são da própria Prime e agora são material de vendas, então rotule-os como tal. Mas a direção é inequívoca: a aposta da Moondream era que você preferiria ter um modelo rápido apoiado em GPU a um do tamanho de um celular.

Há uma segunda diferença, e ela não está na ficha do modelo de forma alguma. O endpoint hospedado do Moondream 3 Preview, o Moondream Cloud, será desativado em 13 de novembro de 2026 após a aquisição, com reembolso dos créditos comprados e não utilizados. O MiniCPM-V 4.7 não tem essa dependência, porque nunca foi primariamente um produto hospedado — é um conjunto de pesos com uma ampla história de implantação no dispositivo associada. Se a sua avaliação incluía a conveniência de chamar um endpoint, essa conveniência está expirando em um dos lados desta comparação.

Capacidade da tarefa: os dois cards são honestos sobre coisas diferentes

As quatro habilidades nativas do Moondream 3 Preview são query, caption, point e detect, todas retornando saída estruturada, e o post de lançamento abre destacando a detecção e o apontamento. A habilidade query roda em modo de raciocínio por padrão, com uma flag reasoning=False documentada para perguntas simples, e os traços de raciocínio são fundamentados — eles fazem referência a partes específicas da imagem, razão pela qual a Moondream chama isso de raciocínio visual com fundamentação, em vez de raciocínio em geral. O contexto é de 32K tokens, acima dos cerca de 2K da geração anterior, usando um tokenizador SuperBPE personalizado; o post de lançamento é franco ao afirmar que o pós-treinamento não explora totalmente a janela longa e que os 32K completos estão lá principalmente para fine-tuning.

O card do MiniCPM-V 4.7, em vez disso, lidera em eficiência e amplitude: compreensão de imagem única, de múltiplas imagens e de vídeo, com compressão mista de tokens visuais de 4x/16x que permite trocar detalhe visual por custo de inferência por tarefa, e compressão precoce intra-ViT do LLaVA-UHD v4, que reduz a computação nas camadas posteriores do codificador. Ele também traz um método de ajuste fino — Self-Replay Fine-Tuning —, voltado a ampliar as capacidades de um modelo a baixo custo enquanto reduz o esquecimento daquilo que ele já sabia.

• Detecção e apontamento fundamentados — Moondream 3 Preview: habilidades nativas na arquitetura, coordenadas estruturadas, traços de raciocínio fundamentados. MiniCPM-V 4.7: compreensão de múltiplas imagens e de vídeo são os pontos fortes declarados; o card não lidera em detecção de vocabulário aberto.

• Vídeo — MiniCPM-V 4.7 oferece suporte a entrada de vídeo, com um exemplo documentado usando 128 quadros. O card do Moondream 3 Preview documenta habilidades de imagem com cache de codificação de imagem para consultas repetidas na mesma imagem.

• Detalhe controlável — MiniCPM-V 4.7: um parâmetro downsample_mode, 16x por padrão e 4x para maior detalhe, escolhido a cada chamada. Moondream 3 Preview: concatenação de canais de múltiplos recortes no codificador de visão, com o post de lançamento observando que o codificador pode ser prejudicado por fontes muito pequenas.

• Licença — MiniCPM-V 4.7: Apache 2.0, ambas as variantes. Moondream 3 Preview: Business Source License 1.1 com uma Concessão de Uso Adicional, que permite uso comercial e em produção e proíbe oferecer o Moondream hospedado para uso geral. O Moondream 3.1 passou para a Moondream Model License 1.0, com a mesma restrição central declarada de forma mais clara.

A linha da licença não é uma nota de rodapé nesta comparação. Se você pretende hospedar o modelo para outras pessoas, o Apache 2.0 e os termos de código disponível do Moondream não são, nem de longe, a mesma posição de partida, e isso é verdade independentemente de qual deles se sai melhor nos benchmarks da sua tarefa.

O ajuste fino é para onde ambos os cartões apontam, por razões opostas

Ambos os fornecedores dizem que o modelo base não é o produto, o que é refrescante e também uma dica sobre onde está o valor.

O post de lançamento do Moondream lista a treinabilidade como um dos quatro objetivos, com o argumento de que tarefas reais de visão exigem especialização — interpretar um raio-X, identificar pessoas em dificuldade numa multidão — e que até os humanos precisam de treino para isso. A empresa lançou o Lens para essa finalidade, e o lançamento do Moondream 3.1 foi além: as pontuações de benchmark publicadas para o 3.1 foram produzidas por meio do ajuste fino de LoRAs por tarefa, sobre a própria divisão de treino de cada benchmark, através do Lens, e depois incorporando o que aprenderam de volta aos pesos base por destilação on-policy, de modo que o checkpoint disponível para download obtém bons resultados sem nenhum ajuste. Vale a pena ler isso duas vezes. É um fluxo de trabalho legítimo e uma divulgação excepcionalmente transparente, e também significa que esses números não são valores frios de uso imediato — as divisões de treino das tarefas em questão foram fornecidas ao modelo.

O equivalente da OpenBMB é o Self-Replay Fine-Tuning, voltado para um problema diferente: adicionar capacidade sem esquecer a capacidade existente, a baixo custo. Sua principal alegação é sobre retenção, e não sobre pontuação máxima.

Se você pretende fazer ajuste fino em qualquer um dos modelos, a diferença prática é a mesma que permeia toda esta comparação. O caminho do Moondream pressupõe uma GPU e um serviço hospedado. O do MiniCPM-V 4.7 pressupõe que você pode fazer ajuste fino nos frameworks que já usa e depois implantar nos dispositivos que já visa, com uma história de quantização no dispositivo publicada para levá-lo até lá.

Onde uma camada de roteamento justifica seu lugar

Nenhum dos modelos aqui é servido pelo OrcaRouter — ambos são checkpoints de pesos abertos que você mesmo hospeda, e um deles vai perder seu endpoint hospedado no próximo mês. Isso faz a pergunta interessante ser justamente a que os dois cards evitam: o que acontece com as requisições que o modelo escolhido trata mal?

A resposta padrão é um segundo modelo, e o custo padrão de um segundo modelo é a integração: outro SDK, outro esquema de autenticação, outra política de repetição. É o tipo de trabalho que consome silenciosamente uma sprint e depois se torna manutenção permanente. A fusão de modelos da OrcaRouter existe para a versão mais restrita desse problema — um painel de modelos respondendo em conjunto nas chamadas em que a resposta de um único modelo não é confiável o suficiente sozinha — e o DSL de roteamento para a versão mais ampla, permitindo que você componha vários modelos em uma única chamada, de modo que um modelo local barato cuide da maioria fácil e algo maior assuma o resíduo.

Por trás de uma única chave há mais de 200 modelos pelo preço de tabela do provedor, sem acréscimo de margem, o que significa que um corte de preço do fornecedor chega até você no mesmo dia, em vez de no próximo ciclo de faturamento, e o failover entre provedores é automático quando um serviço upstream se degrada. Para um VLM auto-hospedado, a camada de roteamento fica acima do modelo, em vez de substituí-lo. Essa é a descrição honesta de onde ele se encaixa nesta comparação e, para um sistema em que o MiniCPM-V 4.7 35B-A3B está no dispositivo e um modelo hospedado cobre as falhas, é a parte que impede que os dois se tornem dois sistemas.

Qual deles, decidido pela restrição que você realmente tem

Se o modelo tiver que rodar no dispositivo, MiniCPM-V 4.7 35B-A3B é a resposta, e não é por pouco. A OpenBMB construiu todo o lançamento em torno do problema de armazenamento que impede um MoE de 35B de rodar em um celular — escalonamento de especialistas, quantização por camadas, decodificação especulativa — e publicou o número que decorre disso: mais de 13 tokens por segundo em cerca de 3 GB. Nada no Moondream 3 Preview aborda esse problema, porque a Moondream escolheu não tê-lo.

Se há uma GPU envolvida e a tarefa é a deteção fundamentada, Moondream 3 Preview é o instrumento mais especializado. Deteção nativa e point com coordenadas estruturadas e traces de raciocínio fundamentado inspecionáveis são um produto diferente de um modelo multimodal geral que também lê texto em imagens e, se um humano revir o resultado, o trace é a funcionalidade principal.

Se você está entre os dois, não decida pelas tabelas de benchmark. Rode suas próprias imagens pelos dois com seus próprios prompts e pontue as saídas, porque o único número nesta comparação que sobreviverá ao contato com sua carga de trabalho é o que você mesmo produzir. E verifique a licença antes do modelo, porque Apache 2.0 e uma licença source-available com restrição de serviço hospedado são uma decisão completamente diferente — uma delas pode encerrar a avaliação antes que os números de acurácia importem.

Também é em comparações como esta que os modos de falha aparecem: os incidentes de IA documentados e as falhas de agentes por trás de modelos nesta classe são coletados no OrcaRouter AI Incident Archive, onde cada entrada carrega suas próprias fontes, gravidade, grau de confiança e sinalização de disputa.