MiniCPM-V-4.7-1B-DSpark: Um Modelo de Rascunho de 213M Lançado Sem Anúncio

MiniCPM-V-4.7-1B-DSpark é um checkpoint de 213.547.777 parâmetros que não consegue responder a uma pergunta. Ele não lê imagens, não mantém uma conversa e, quando servido sozinho, não produz nada que valha a pena ler. Seu trabalho inteiro é ficar na frente de um modelo — MiniCPM-V-4.7-1B — e adivinhar os próximos quinze tokens para que um pequeno modelo de visão-linguagem de classe de celular possa verificar um bloco deles em uma única passagem direta, em vez de gerá-los um de cada vez.

O arquivo tem 0,85 GB sob a licença Apache-2.0 e apareceu no Hugging Face às 04:26 UTC de 8 de outubro de 2026, no mesmo lote do rascunho do irmão maior 35B-A3B. Quatro dias depois, o card do modelo pai ainda o trata como uma nota de rodapé: o rascunho aparece uma única vez, como uma linha na tabela de pesos e atrás de um botão de alternância recolhido “Decodificação especulativa (DSpark)”. Não há post no blog da OpenBMB sobre ele, nem relatório técnico, nem entrada na documentação do próprio projeto no GitHub.

Esse silêncio é a parte interessante, por causa do que este arquivo específico torna possível. É o primeiro artefato da família MiniCPM-V 4.7 cuja alegação central — de que um modelo de visão de 1B roda de forma aceitável em um telefone — pode ser verificada por alguém fora da OpenBMB. Tudo abaixo mantém duas pilhas separadas: o que é um arquivo em disco que você pode abrir, e o que é um número que o fornecedor imprimiu ao lado dele.

O que está realmente no repositório

Quatro arquivos. É isso tudo: .gitattributes, README.md, config.json, e um único model.safetensors contendo 854.204.052 bytes de pesos BF16. Não há tokenizer no repositório, porque não precisa haver — o rascunho pega emprestado o do alvo, e o vocabulário em sua configuração é exatamente o do pai, com 248.094 tokens. Um rascunho cujos tokens não mapeiem um para um com os do alvo não pode propor nada que o alvo aceitaria, então compartilhar o vocabulário é um requisito, e não uma conveniência.

A API do Hub registra o repositório como criado em 2026-10-08T04:26:19Z e modificado pela última vez em 2026-10-12T14:29:57Z, marcado para inglês e chinês, licenciado como Apache-2.0, com três curtidas e um download no momento em que escrevo. O último número é o que devemos guardar. Um download, quatro dias depois, em um arquivo pequeno o suficiente para ser baixado por uma conexão de celular.

O campo de arquitetura indica Qwen3DSparkModel com um model_type de qwen3, o que é coerente, e não estranho: o backbone de linguagem do MiniCPM-V 4.7 descende da linha Qwen3, então um stub de cinco camadas recortado da mesma família é o que se esperaria. O que não é uma cópia menor do pai é como o stub conversa com ele. A configuração prepara um dflash_config com projector_type: "dspark", enable_confidence_head: true, confidence_head_alpha: 1.0, confidence_head_with_markov: true, markov_head_type: "vanilla" e markov_rank: 256. Essa cabeça de confiança é a parte extraída do método DSpark: é o mecanismo para estimar quanto de um bloco proposto vale a pena verificar, que é exatamente a razão pela qual a configuração de serving expõe um interruptor para desligar a verificação adaptativa.

A especificação, e por que cada número está aí

Do lado do rascunho, com base no cartão e na configuração, que concordam entre si:

• Parâmetros do draft — 213.547.777, todos em BF16, em um checkpoint de arquivo único de 0,85 GB

Profundidade do rascunho — 5 camadas, todas com atenção completa, tamanho oculto 1.024, tamanho intermediário 3.584, ativação SiLU

• Geometria da atenção — 8 cabeças de consulta contra 2 cabeças de chave/valor, dimensão de cabeça 256, atenção de consulta agrupada

• Tokens por passagem direta — 15, carregados na configuração como block_size: 15

• Intervalo de posição — RoPE theta 10.000.000 com um embedding rotativo de 256 dimensões, e max_position_embeddings definido como 262.144, correspondendo à janela de 256K do pai

• Camadas de toque — [3, 7, 11, 15, 19], das 24 do pai (num_target_layers: 24)

Vocabulário — 248.094, vinculado ao tokenizador do alvo, com um token de máscara dedicado em 248.076 para a etapa de rascunho semiautoregressiva

Duas dessas linhas merecem mais do que uma olhada. A primeira são as camadas de captura. O modelo de rascunho não lê a camada final do modelo pai; ele lê estados ocultos de cinco camadas espalhadas pela profundidade do modelo pai e os projeta através de um dspark projetor. Estados intermediários da rede são mais baratos de alinhar e ainda carregam informação que a última camada já colapsou em logits do próximo token. A segunda é a dimensão da cabeça de 256 contra um tamanho oculto de 1.024. Isso é uma cabeça deliberadamente larga em um modelo estreito, e a configuração define tie_word_embeddings: false — a matriz de embeddings é mantida separada em vez de compartilhada com a projeção de saída, então a contagem de parâmetros inclui ambas.

Em suma, é um modelo de rascunho com cerca de um quinto do tamanho do alvo, numa forma completamente diferente. Para comparação, o rascunho do irmão 35B-A3B tem 389.223.169 parâmetros, usando as camadas [3, 11, 19, 27, 35] de 40. Dois rascunhos, um por alvo, porque um rascunho só é válido para o vocabulário e a representação intermediária com os quais foi treinado.

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

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

• Visão, MMMU — 3,452 tokens aceitos por passo

• Vision, MathVista — 4.333

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

• Visão, OCRBench — 4.752

• Texto, matemática — 5.891

• Texto, código — 5.347

• Texto, geral — 3.370

A variação vai de 5,891 até 3,370, um fator de cerca de 1,75 entre a categoria mais fácil e a mais difícil. Essa ordenação não surpreende, de uma forma que lhe diz algo sobre os números: a matemática é a superfície mais regular que um modelo de linguagem produz, o texto geral, a menos regular, e a taxa de sucesso de um modelo de rascunho acompanha a previsibilidade da saída do alvo, e não a qualidade dela.

Três ressalvas deveriam constar naquela tabela, e o cartão não menciona nenhuma delas espontaneamente.

É autodeclarado, e há exatamente um download no repositório. Ninguém fora da OpenBMB produziu um número de aceitação para este checkpoint que qualquer outra pessoa possa consultar. Os números são do fornecedor, medidos no harness do fornecedor, no conjunto de tarefas do fornecedor.

O comprimento de aceitação é uma propriedade do par, não do modelo. Um alvo que se repete dá ao seu modelo de rascunho uma vitória fácil, então um número mais alto aqui não é evidência de que o MiniCPM-V 4.7-1B seja bom em alguma coisa. É evidência sobre o quão previsível é a sua saída, o que é uma pergunta diferente com uma resposta diferente.

E isso não é um ganho de velocidade. Um drafter que propõe 15 tokens e tem 3,4 deles verificados ainda está movendo vários tokens por passada forward do alvo, mas verificar um bloco de 15 tokens custa mais do que gerar um token, e toda proposta rejeitada é paga e descartada. Converter um comprimento de aceitação em um valor de tempo real exige o custo de verificação, o tamanho do lote e o hardware, nada do que o card fornece. A única receita de serving que ele fornece define --max-num-seqs 1, que é uma configuração ajustada para funcionar, e não para ser rápida.

Lida em comparação com o irmão, a tabela fica mais útil. O rascunho 35B-A3B registra 7,387 em código e 5,098 no MMMU; este rascunho 1B registra 5,347 e 3,452. Alvos menores com modelos de rascunho menores aceitam consideravelmente menos tokens por passo, que é o tipo de detalhe entre famílias que um único cartão não consegue mostrar e dois cartões conseguem.

Treinamento, e o detalhe que explica todo o design

A receita tem quatro linhas: dois milhões de sequências de treinamento, seis épocas, AdamW e um objetivo combinado de entropia cruzada, um termo L1 e uma perda de confiança. A linha que importa é a que fala sobre de onde vieram os dados de treinamento — as respostas foram geradas pelo próprio MiniCPM-V-4.7-1B, a partir de uma mistura de prompts de visão e texto.

Isso é autodestilação, e define o piso do custo de construção de um rascunhador como este. Não se pode treinar um sem primeiro executar o modelo-alvo em grande volume, em ambas as modalidades, o que significa que o artefato de 0,85 GB que você pode baixar é o resíduo barato de um processo caro. Isso também explica por que o rascunhador é emparelhado um a um, em vez de compartilhado: o comportamento que ele está imitando é o comportamento deste modelo, e as saídas de um alvo diferente treinariam um rascunhador diferente.

O artigo do próprio método, arXiv 2607.05147, não é da OpenBMB. É um artigo de 33 autores, submetido em 6 de julho de 2026, que descreve o DSpark como uma estrutura de decodificação especulativa que combina um backbone paralelo com um módulo sequencial leve e agenda o comprimento de verificação a partir de probabilidades estimadas de sobrevivência de prefixo. Ele relata implantação dentro de um sistema de serviço DeepSeek-V4, adota uma linha de base de produção chamada MTP-1 e afirma geração por usuário de 60 a 85 por cento mais rápida com throughput equivalente. Essas alegações pertencem ao artigo e a essa implantação. Nada publicado as conecta a um modelo de rascunho de cinco camadas e 213M sobre um modelo de visão de 1B, e a tabela de aceitação acima é a única ponte que alguém já ofereceu.

Por que este arquivo importa mais do que seu tamanho sugere

A principal alegação da família MiniCPM-V 4.7 é a de execução no dispositivo. O cartão do 1B traz um gráfico de desempenho versus tempo de inferência, um gráfico de desempenho geral para a versão instruct do 1B, uma gravação de tela não editada capturada num iPhone 17 Pro Max e uma frase qualitativa dizendo que a variante 1B supera substancialmente o Qwen3.5 0.8B tanto na pontuação geral quanto na eficiência de inferência. Também lista uma família de quantização — int4, AWQ, GPTQ, GGUF, além de suporte a FP8 — e alvos de hardware desde o dia 0, abrangendo iOS, Android, HarmonyOS, Rockchip, Houmo, Intel, AMD e Arm.

Cada uma dessas é uma alegação de fornecedor sem nenhum número externo associado, e uma delas é internamente incongruente: o texto do cartão o chama de modelo 1B, enquanto a barra lateral do Hub informa um tamanho de modelo de 2B parâmetros. O checkpoint DSpark é de natureza diferente de tudo isso. Ele tem 0,85 GB, licença Apache-2.0 e vem com um comando de serving — o que significa que um terceiro com uma GPU de consumidor pode executá-lo esta semana e produzir o primeiro número medido externamente da família. Não uma pontuação de benchmark, mas algo quase tão útil: um comprimento de aceitação reproduzido.

Se alguém igualar 3,45 no MMMU e 3,37 em texto geral, a placa é crível e a história de execução no dispositivo tem seu primeiro ponto de dados externo. Se a aceitação vier substancialmente menor, a tabela foi medida sob condições que a receita publicada não contempla, e o gráfico de desempenho por tempo de inferência herda essa dúvida. Qualquer um dos resultados vale mais do que mais um gráfico de fornecedor, e esta é a única parte da família em que conseguir um é barato.

Executá-lo, e quanto custa tentar

O cartão traz uma única receita e ela é uma vllm serve, uma invocação, não uma vaga promessa. Ela carrega o alvo openbmb/MiniCPM-V-4.7-1B, serve-o sob o nome MiniCPM-V-4.7-1B, define --max-model-len 40960 e --max-num-batched-tokens 40960, fixa --attention-backend FLASH_ATTN e --mm-encoder-attn-backend FLASH_ATTN, passa um kwarg de processador multimodal de {"downsample_mode": "4x"}, confia em kwargs multimodais por solicitação e aponta uma configuração especulativa para o checkpoint DSpark com "method": "dspark", "num_speculative_tokens": 15 e verificação adaptativa desativada. Os kwargs padrão do template de chat deixam o raciocínio desativado.

Dois detalhes nessa linha merecem ser lidos duas vezes. --max-num-seqs 1 significa que a configuração publicada atende uma sequência por vez, então a receita descreve uma configuração de latência de fluxo único, não uma configuração de throughput. E o modo de downsample visual 4x é o mais barato dos dois que o cartão pai anuncia — o mesmo cartão oferece um esquema misto 4x/16x que troca detalhe por velocidade, e a receita seleciona o lado dessa troca que favorece a velocidade.

O envelope de hardware é o oposto do marketing da família. O alvo de 1B ocupa cerca de 2 GB em BF16, mais um cache KV, e o draft acrescenta 0,85 GB por cima, pelo que esta é uma tarefa para uma única GPU — um cartão de consumidor ou uma workstation com memória unificada suficiente — e não uma tarefa para telemóvel. O percurso no dispositivo, na documentação do modelo principal, passa por builds quantizados e frameworks que não constam desta receita, e o checkpoint DSpark, tal como publicado, é um artefacto BF16 do lado do servidor.

Isso deixa uma lacuna que a maioria das equipes vai encontrar: a versão interessante do MiniCPM-V 4.7-1B é a no dispositivo, e a versão que você pode executar hoje sem ter o conjunto de ferramentas do telefone é uma do lado do servidor. Se o que você realmente precisa agora é de inferência multimodal pequena, o equivalente hospedado mais próximo é um modelo diferente — Qwen3 VL 8B Instruct está no OrcaRouter a US$ 0,18 por milhão de tokens de entrada e US$ 0,70 por milhão de saída, com uma janela de contexto de 128K e entrada de texto, imagem e vídeo, sem pesos locais e sem receita de serviço para manter funcionando. 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 essas são duas maneiras de fazer um trabalho, e apenas uma delas é mensurável no catálogo nesta tarde.

Onde algo como o DSpark se justifica é no caso do modelo não comprovado, e isso é uma questão de encaminhamento, e não uma questão de modelo. Um drafter que ninguém reproduziu é exatamente o tipo de componente que se quer atrás de um endpoint do qual se possa fazer fallback. Executar mais de 200 modelos por trás de uma única chave, com os preços de tabela dos fornecedores repassados com 0% de margem, e com failover automático quando uma rota se degrada, significa que um experimento de serving que corra mal custa-lhe uma nova tentativa em vez de uma indisponibilidade — e, como nada tem margem acrescentada, uma alteração de preço de um fornecedor para qualquer modelo do catálogo fica ativa no próprio dia, e não no ciclo de faturação seguinte.

O que tornaria isto verificável?

Três coisas estão faltando, e uma delas requer a OpenBMB.

O fornecedor não anunciou nada. O repositório tem um cartão de modelo, uma licença e uma receita de treinamento, mas nenhuma postagem de blog, nenhum relatório técnico e nenhuma linha na documentação do GitHub do projeto — que, na primeira semana da família, ainda descrevia a geração anterior como a atual. Quatro dias depois que o checkpoint chegou, o cartão do modelo pai 1B o referencia apenas como uma linha de tabela, e nada mais.

Ninguém reproduziu os números de aceitação, e o número de downloads é um. Essa é a lacuna mais barata de fechar e a que mais importa, porque é o único ponto em que uma medição externa teria um impacto significativo na história da família.

E a questão da qualidade permanece completamente intocada. Não há nenhuma pontuação MMMU, nenhum resultado do OCRBench, nenhum número de compreensão de documentos e nenhuma métrica de grounding para o MiniCPM-V 4.7-1B em lugar algum do lançamento — a tabela de aceitação é uma tabela sobre decodificação, e interpretar um alto comprimento de aceitação como um sinal de qualidade é exatamente o erro que esses números convidam a cometer.

Então: um artefato de verdade, uma licença permissiva, um comando de serving que funciona e uma peça de evidência genuinamente nova sobre um modelo que não tinha nenhuma. O próximo arquivo que vale a pena atualizar ainda é o model card do modelo pai.