MiniCPM-V 4.7-35B-A3B-DSpark: o Draft de 389M da OpenBMB chega com um card que seu modelo base nunca recebeu

MiniCPM-V-4.7-35B-A3B-DSpark é um modelo de rascunho com 389.223.169 parâmetros. Ele não responde a perguntas, não vê imagens e, por si só, é inútil. Sua única função é adivinhar os próximos quinze tokens para que o MiniCPM-V-4.7-35B-A3B possa verificar um bloco inteiro em uma única passagem direta, em vez de gerar um token por vez. Isso é decodificação especulativa, e a OpenBMB lançou um modelo de rascunho para seu novo modelo de visão e linguagem de 35B há onze dias, sem dizer uma palavra sobre isso publicamente.

O que faz valer uma página não é o rascunho. É a papelada que veio junto. O checkpoint DSpark tem um cartão de modelo: uma licença, uma tabela de especificações, uma receita de treinamento e uma tabela de comprimento de aceitação para sete categorias de tarefas. Seu modelo pai de 35 bilhões de parâmetros não tinha nada disso quando apareceu. Então, pela primeira vez, há números concretos associados a um lançamento do MiniCPM-V 4.7 — e são números sobre o modelo pai, medidos indiretamente, por um arquivo de 0,78 GB cujo propósito declarado é fazê-lo ir mais rápido.

Tudo abaixo separa o que está no cartão daquilo que o cartão não estabelece. Os números de aceitação são do próprio OpenBMB e ninguém fora do laboratório os reproduziu. A tabela de benchmark do modelo base ainda não existe.

O que o checkpoint do DSpark realmente é

O repositório openbmb/MiniCPM-V-4.7-35B-A3B-DSpark data de 8 de outubro de 2026. É um checkpoint de arquivo único — model.safetensors, mais um config.json e um README — sob Apache-2.0, marcado para inglês e chinês. Um segundo rascunho, openbmb/MiniCPM-V-4.7-1B-DSpark, foi criado um segundo antes, então os dois foram enviados ao hub no mesmo lote, em vez de descobertos um de cada vez.

Cada draft fica à frente de um único alvo e apenas desse alvo. O cartão diz isso claramente: este checkpoint é "treinado para emparelhamento exato com o MiniCPM-V-4.7-35B-A3B e seu tokenizador". O vocabulário é o do modelo pai, todos os seus 248.144 tokens, o que é um requisito e não uma otimização — um drafter cujos tokens não mapeiam um para um com os do alvo não pode propor nada que o alvo possa aceitar. Essa mesma restrição é o motivo pelo qual o draft irmão existe separadamente, em vez de um único drafter atender à família.

A arquitetura não é uma cópia menor do modelo pai. É uma pilha de atenção de cinco camadas, largura oculta de 2.048, 8 cabeças de consulta contra 2 cabeças de chave/valor, tamanho intermediário de 6.144 e RoPE com theta de 10.000.000. O campo architectures exibe Qwen3DSparkModel — o mesmo backbone da família Qwen3 de onde vem a pilha de linguagem do modelo pai, reduzido a um stub.

A parte interessante é como o stub conversa com o alvo. Ele não lê a camada final do alvo. Ele extrai estados ocultos de cinco camadas intermediárias — [3, 11, 19, 27, 35] das 40 do pai — e os projeta através de um projetor do tipo dspark. Extrair do meio da pilha em vez do fim é intencional: estados intermediários da rede são mais baratos de alinhar e carregam informações que a camada final já comprimiu em logits do próximo token. A configuração também equipa uma cabeça de confiança com um componente de Markov de posto 256, que é o mecanismo do artigo DSpark para decidir quanto de um bloco proposto vale a pena verificar.

A tabela de aceitação é um cartão, não uma medição

Aqui está tudo o que a OpenBMB publicou de numérico sobre o quão bem este par funciona, expresso em tokens aceitos por etapa de verificação, com terminação EOS natural e max_new_tokens=8192:

• Visão, MMMU — 5.098 tokens aceitos por etapa.

• Visão, MathVista — 6.126.

• Visão, raciocínio CharXiv (validação) — 5.479.

• Vision, OCRBench — 5.407.

• Texto, Matemática — 6.687.

• Texto, Código — 7.387.

• Texto, Geral — 3.501.

Três coisas sobre essa tabela merecem ser ditas em voz alta. Primeiro, ela é autorrelatada. Ninguém fora da OpenBMB executou esse checkpoint e publicou um número e, com um download registrado no repositório, ninguém fora da OpenBMB o executou de forma alguma. Segundo, o comprimento de aceitação é uma propriedade do par, não do modelo — ele mede o quão previsível é a saída do MiniCPM-V-4.7-35B-A3B, não quão boa essa saída é. Um alvo que se repete dá ao rascunhador uma vitória fácil. Terceiro, a dispersão é o ponto: 7,387 em código contra 3,501 em texto geral é um fator de dois entre a melhor e a pior categoria, e o código ser o mais fácil reflete a superfície de baixa entropia e altamente repetitiva do código mais do que qualquer força nos modelos.

Há também uma leitura de aritmética simples que o card deixa implícita. Um modelo de rascunho que propõe 15 tokens e tem de 5 a 7 aceitos ainda está movendo vários tokens por passagem direta do alvo, então o teto aqui é um grande ganho de vazão — mas não é a alegação ingênua de "5× mais rápido", porque verificar um bloco de 15 tokens custa mais do que gerar um único token, e as propostas rejeitadas são pagas e descartadas. É exatamente essa lacuna que o artigo do DSpark aborda, e é por isso que a configuração expõe um interruptor para desativar a verificação adaptativa.

O que o rascunho nos diz acidentalmente sobre o modelo base

O MiniCPM-V 4.7 rotulou seu lançamento como distribuído discretamente — pesos, sem post de lançamento. Isso agora mudou, de uma forma pequena, mas real. O repositório pai em openbmb/MiniCPM-V-4.7-35B-A3B foi criado em 7 de outubro de 2026. Até 12 de outubro, ele já continha um model card completo com um README, uma página de lançamento no estilo hugging-face, uma lista de afirmações, uma seção on-device e uma tabela de pesos. Desde então, o repositório ganhou uma família de quantização — builds FP8, int4, AWQ, GPTQ e GGUF, cada um em seu próprio repositório, todos alterados em 12 de outubro — e 27 curtidas contra 166 downloads.

Assim, o retrato preciso é de um lançamento em duas etapas, não de um lançamento silencioso. Os pesos chegaram em 6 e 7 de outubro. Os checkpoints preliminares vieram em seguida, em 8 de outubro. A documentação, os quants e a proposta de execução no dispositivo chegaram até 12 de outubro. OpenBMB ainda não publicou um post de blog nem um relatório técnico para a família, e ainda não há uma tabela de benchmark no card do modelo pai — as alegações de desempenho ficam dentro de imagens de gráficos vinculadas, em vez de como texto que um leitor possa citar.

A afirmação que de fato aparece no texto é a de manchete: com o "Lookahead Expert Scheduling", a quantização por camadas e a "integração de amostragem especulativa do DSpark", o modelo 35B-A3B é descrito como o primeiro modelo MoE de código aberto a rodar sem problemas no dispositivo, a mais de 13 tokens por segundo num iPhone 17 Pro Max. Esse número é reportado pelo fornecedor, não foi reproduzido e não vem acompanhado de qualificações — nenhum formato de quantização, nenhuma build, nenhum prompt, nenhum método de medição. O checkpoint do DSpark é uma das três técnicas nas quais essa afirmação se baseia, o que faz dele a única das três que você pode baixar e inspecionar. É também aquela cuja evidência é uma única linha de benchmark não lida por tarefa.

Executando-o, se você quiser

O card traz uma única receita, e ela é um comando vLLM, não uma vaga promessa. Ela serve o alvo com tensor-parallel size 2 e comprimento máximo de modelo de 40.960, FLASH_ATTN em ambos os backends de atenção do codificador de linguagem e multimodal, modo de downsample visual de 4x, enable_thinking definido como false, e a configuração especulativa apontada para o checkpoint DSpark com 15 tokens especulativos e verificação adaptativa desativada. Dois detalhes nessa linha merecem atenção por si sós: --max-num-seqs 1 significa que a configuração publicada serve uma sequência por vez, e --disable-custom-all-reduce com o passo de fusão all-reduce desligado significa que esta é uma configuração que foi ajustada para funcionar, e não para ser maximamente rápida. Trate a receita como um ponto de partida que a OpenBMB conseguiu fazer rodar, não como uma alegação de throughput.

O envelope de hardware é a verdadeira barreira. O alvo é cerca de 70 GB de pesos BF16 antes da KV cache, e o draft acrescenta aproximadamente 0,78 GB por cima. Dois aceleradores é o mínimo indicado, o que coloca isto bem fora do telefone no qual o marketing da família se apoia — uma implementação no dispositivo para um modelo 35B-A3B significa quantização agressiva e offloading, que é para isso que serve o trabalho de LES e de quantização por camadas, e nenhum dos dois está na receita vLLM acima.

Essa assimetria é a decisão prática para a maioria das equipes. Servir o MiniCPM-V 4.7 custa duas GPUs que você possui; recorrer a um MoE multimodal hospedado comparável não tem custo inicial. O Qwen3.6 35B A3B é a comparação direta mais próxima — mesma configuração de 35B no total e 3B ativos, mesmo contexto de 262K, entrada de imagem e vídeo — e é servido por meio do OrcaRouter a partir de US$ 0,248 por milhão de tokens de entrada e US$ 1,485 por milhão de tokens de saída, dependendo da rota do provedor, com failover automático se uma dessas rotas degradar. O MiniCPM-V 4.7 não é um modelo hospedado no OrcaRouter, e este artigo não vai fingir o contrário; o enquadramento honesto é que os dois são alternativas em um ponto de decisão, e o hospedado é aquele que você pode medir hoje à tarde.

O que tornaria isto verificável?

O checkpoint DSpark é Apache-2.0, tem menos de um gigabyte e vem com um comando de serving que alguém com duas GPUs poderia colar em um terminal hoje. Essa combinação faz dele a rota mais barata para um número independente no MiniCPM-V 4.7 — não uma pontuação de benchmark, mas algo quase tão útil: um comprimento de aceitação reproduzido. Se uma parte externa igualar 5,1 no MMMU e 3,5 em texto geral, o card é crível e a história de eficiência da família ganha seu primeiro ponto de dados externo. Se a aceitação vier substancialmente menor, a tabela publicada foi medida sob condições que a receita não reproduz, e a alegação de 13 tokens por segundo herda essa dúvida.

O que ainda falta é justamente aquilo para que um model card normalmente serve. Não há pontuação no MMMU, nem no OCRBench, nem resultado de compreensão de documentos, nem número de grounding e nem valor de latência para o próprio MiniCPM-V 4.7 — nada que responda se este modelo é bom. A tabela do modelo de rascunho não pode substituir isso, e interpretar um comprimento de aceitação alto como sinal de qualidade é precisamente o erro que os números convidam a cometer. Uma previsão no formato do ChatGPT é fácil para um rascunhador e não diz nada sobre se a previsão estava correta.

Então: um artefato real, uma licença real, uma evidência publicada genuinamente nova sobre um modelo que não tinha nenhuma — e uma lacuna de avaliação exatamente tão ampla quanto era em 7 de outubro. O próximo arquivo a ser atualizado continua sendo o cartão de modelo do modelo pai.