pplx-decider vs Decider: o 27B silencioso da Perplexity contra a Open Ladder da Mapika

Dois modelos de decisão estão no Hugging Face agora que respondem a perguntas da mesma forma e não concordam em quase mais nada. pplx-decider é um checkpoint de 27B da Perplexity que surgiu em 2026-10-01 sem anúncio, sem post no blog, sem página de preços e sem nenhum provedor de inferência que o ofereça; uma revisão, pplx-decider-v1.1, veio em seguida em 2026-10-05 no mesmo backbone. Decider é a família da Mapika da mesma classe de modelo — decider-0.8b até decider-35b-a3b, uma reprodução aberta na linhagem System One, publicada com notas de treinamento completas. Ambos recebem um bloco de perguntas nomeadas mais um documento e retornam uma probabilidade calibrada por resposta em uma única passagem direta. Nenhum dos dois escreve uma frase de prosa. O que segue é o que de fato consta no registro para cada um, e um marcador claro onde quer que o registro pare.

Primeiro, o que “decision model” está fazendo nessa frase?

Nenhum destes é um modelo de chat que tenha sido instruído a ser conciso. Não são modelos de linguagem no sentido habitual — não há ciclo de decodificação, nem amostragem, nem nada token a token. Uma única passagem direta pelo seu documento retorna uma probabilidade para cada opção que você forneceu.

A forma da chamada é o que faz valer a pena escrever a comparação. Você entrega um estado (um ticket, um registro JSON, uma captura de tela, um contrato) e uma lista de perguntas nomeadas. Cada pergunta nomeia seu tipo de resposta: escolha entre 2 e 255 opções rotuladas, uma leitura de sim/não/desconhecido ou uma pontuação em 2 a 10 níveis descritos. As respostas voltam na ordem em que você as pediu, como números entre 0 e 1, e o número deve ser lido como uma probabilidade, e não como um rótulo preciso — 0,62 em "está sendo solicitado um reembolso?" é toda a saída, e o chamador decide o limiar.

Esse design elimina a latência e o custo, porque um documento com sessenta perguntas custa uma única passagem, não sessenta. Também significa que as formas usuais de avaliar um modelo de linguagem não se aplicam: não há traço de raciocínio para ler, nenhuma cadeia de pensamento com que discutir, nenhuma maneira de pedir que ele se explique. Você obtém massa de probabilidade e nada mais. Ambos os projetos deixam explícito que essa é a troca.

O que foi lançado, e o que ninguém disse

O repositório pplx-decider é excepcionalmente completo para um modelo sem nenhum post de lançamento por trás dele. Os pesos são Apache-2.0. A base é Qwen/Qwen3.8-27B, conforme declarado no card. Há uma readout head lançada em bf16 em [255, 5120], que é exatamente o formato que você esperaria para 255 opções selecionáveis sobre um estado oculto de 5.120 dimensões. O card documenta o orçamento de entrada, o teto de opções, os três tipos de pergunta e o formato do endpoint — POST /v1/systemone.

O que não está lá é a frase que um post de lançamento carregaria. Não há data de lançamento no card, nenhum anúncio, nenhum post de benchmark da Perplexity, nenhum preço e nenhuma plataforma de terceiros que o disponibilize. Os números de downloads são do tamanho que se obtém de um repositório que foi encontrado, e não promovido. Leia os dois juntos e a descrição honesta é: o artefato é público, a intenção por trás dele não é. Tudo abaixo sobre o pplx-decider vem do repositório e de seus cards. Nada abaixo foi reproduzido de forma independente, e ninguém fora do laboratório publicou uma execução própria.

A entrada da biblioteca do Ollama torna essa lacuna visível de forma discreta. Sua página lista a tag como 27b em 17 GB com uma janela de contexto de 256K — uma build quantizada, bem abaixo dos aproximadamente 49 GiB que os pesos bf16 ocupam — enquanto o repositório documenta um orçamento de entrada de texto e imagens muito menor e afirma que entradas grandes demais são rejeitadas, não truncadas. Essas duas afirmações não estão descrevendo, de modo óbvio, o mesmo limite, e nada publicado as concilia. Trate o número do runtime como a alegação do runtime.

A parte interessante: dois estranhos, uma interface

A família Decider da Mapika e o pplx-decider foram desenvolvidos de forma independente, a partir de bases diferentes, por razões diferentes, e convergiram no mesmo formato de transmissão. Os modelos Decider também falam o mesmo formato de chamada do System One — perguntas nomeadas, escolha entre 2 e 255 opções, sem geração de texto, estados aceitos até cerca de 32k. Um cliente escrito para um é, praticamente, um cliente para o outro.

Essa convergência é o fato útil nesta comparação. A escolha de um ou de outro não é uma reescrita; é uma troca de URL base e de string de modelo. A pergunta interessante deixa de ser “qual API eu integro” e passa a ser “em qual leitura eu confio nos meus documentos” — e os dois projetos respondem a essa pergunta de maneiras muito diferentes.

Um checkpoint contra uma escada

A diferença estrutural é a mais fácil de perceber. A Perplexity lançou um único tamanho. A Mapika lançou uma variedade e publicou a tabela de tamanhos:

• Catálogo — pplx-decider: um checkpoint de 27B, além de uma revisão v1.1 no mesmo backbone. Decider: sete ou mais tamanhos publicados, de decider-0.8b com 1,4 GB até decider-2b, decider-2b-vision, decider-4b, decider-12b e decider-35b-a3b com 65 GB bf16 ou 19,6 GB em nvfp4.

• Bases — pplx-decider: Qwen/Qwen3.8-27B, uma linhagem. Decider: uma mistura — Qwen3.5-0.8B, Qwen3.5-2B e Qwen3.5-4B para os tamanhos pequenos, Qwen3.5-35B-A3B para o grande, e gemma-4-12B-it e gemma-4-31B-it nas variantes de chat.

• Ativação — pplx-decider: denso 27B, portanto cada parâmetro é executado a cada chamada. Decider: decider-35b-a3b é uma mistura — 34,7B no total com aproximadamente 3B ativos em 256 especialistas roteados, 8 deles ativos por token.

• Vision — pplx-decider: multimodal, e o repositório confirma isso; texto, JSON e imagens, incluindo capturas de tela, recibos e formulários, com tokens de visão custando aproximadamente largura × altura / 1024. Decider: um checkpoint separado decider-2b-vision em vez de uma flag na linha principal, então o trabalho com imagens é uma escolha de modelo diferente, não um argumento diferente.

• Licença — Apache-2.0 em ambos os lados, que é o único ponto em que esta comparação é entediante.

• Divulgação de treinamento — pplx-decider: um pipeline de dados que se baseia no Bespoke Nimble da Bespoke Labs, com subconjuntos de benchmark fixados por ID de registro e checksum, e os ganhos da v1.1 creditados à remoção da máscara causal e à inclusão de dados, incluindo tasksource. Decider: notas por versão com contagens de itens, hardware e tempo de relógio — decider-35b-a3b treinado em 4× B300 por 394 minutos ao longo de 1.543.567 itens — além de modos de falha nomeados e a proporção de parâmetros realmente treinados, 2,45B de 34,7B.

Nenhuma dessas opções é uma vantagem decisiva. Um único checkpoint é mais simples de analisar, mais fácil de servir e impossível de reduzir de tamanho. Uma escada permite colocar o decider-0.8b atrás de um pré-filtro barato e gastar o 35B apenas nos itens que precisam dele — mas só se você estiver disposto a manter a lógica de roteamento que decide qual é qual.

Os números, e quem os produziu

Ambos os conjuntos de números de destaque são divulgados pelos fornecedores, e nenhum deles tem uma replicação independente associada. Isso é mais importante aqui do que costuma ser, porque não existe um ranking de modelos de decisão de terceiros com a credibilidade das arenas de imagem ou de linguagem.

Os próprios números da Perplexity para o pplx-decider o colocam em 85,7% em 11 benchmarks públicos, contra 84,5% para o Jev e 74,8% para a base Qwen3.8-27B a partir da qual ele foi treinado. As linhas individuais reportadas incluem RAGTruth 88,8, FinancialPhraseBank 84,2, TabFact 90,6, JudgeBench 78,3 e WinoGrande 83,3, com o conjunto mais completo abrangendo Circa, Belebele, TruthfulQA binary, BBH, ContractNLI e uma divisão difícil pública do JevBench. A revisão v1.1 reporta um resultado geral ponderado pelo conjunto de 61,56 contra 56,4 para a v1 e 57,9 para o Jev, com o maior ganho em uma única categoria nas tarefas de linguagem. A comparação com o Jev é do fornecedor, calculada no próprio conjunto de avaliações do fornecedor, e a ponderação não é publicada.

A forma como a Mapika reporta tem uma textura diferente: os números vêm acompanhados de ressalvas que os enfraquecem. O decider-35b-a3b reporta 0,855 na tarefa e 0,810 em dados reservados contra uma base zero-shot de 0,732, e 0,676 na divisão difícil pública do JevBench — abaixo dos 0,730 do Jev 1.13.0. A ficha também afirma que não há etapa de reforço, então o desempenho com amostragem fica em 86,4%, contra os 93,2% do decider-2b v10, e que o modelo é excessivamente confiante nos itens mais difíceis, com erro de calibração esperado de 0,15 no nível difícil. O decider-2b v11 é reportado em 0,802 na tarefa e 0,752 em dados reservados, com um ECE de 0,156 contra uma diretriz de lançamento declarada de 0,08 — uma falha, divulgada pelos próprios autores.

Vale a pena levar em conta dois modos de falha documentados em qualquer avaliação que você fizer. Selecionar um registro por sua posição em um array JSON longo é descrito como o formato de entrada menos preciso que a família processa, e empacotar várias perguntas independentes em uma única chamada pode inverter até 12% das respostas quando a flag independente está desativada. Ambos são o tipo de coisa que uma ficha técnica esconde e que um card menciona uma vez.

Quanto custa rodar qualquer um dos dois

• O menor Decider viável — decider-0.8b tem 1,4 GB. pplx-decider não tem variante pequena, então seu mínimo é o 27B completo.

• Maior Decider — decider-35b-a3b com 65 GB bf16 ou 19,6 GB nvfp4, com apenas cerca de 3B parâmetros ativos por token.

• Latência, lado do Decider — decider-2b executa 4 ms por requisição com grafos CUDA em uma B300, ante 18,9 ms em modo eager, e cerca de 2.700 decisões por segundo com batch 32. O 35B é outro mundo: cerca de 47 ms para um ticket de 92 tokens com três perguntas, 368 ms para 64 tickets.

• Latência, lado do pplx-decider — nenhuma publicada. Os cards não apresentam nenhum número de throughput ou latência, o que é normal para um repositório que não foi lançado.

• Custo por decisão — é aqui que o design compensa em ambos os lados. Sessenta perguntas em um documento são uma única passagem direta de qualquer maneira, então o custo por decisão despenca à medida que você faz mais perguntas sobre o mesmo documento.

Aqui está o panorama honesto do roteamento. O OrcaRouter não atende o pplx-decider, e não atende a família Decider da Mapika — nenhum dos dois aparece no catálogo, e nada neste artigo deve ser interpretado como uma afirmação em contrário. O que o catálogo traz nessa classe hoje é o typesafe/jev-1.13, um modelo de decisão do mesmo formato System One com uma janela de 65.536 tokens exposta pelo mesmo endpoint POST /v1/systemone a US$ 0,042 por milhão de tokens de entrada, o que é uma referência útil para o que custa um modelo de decisão roteado. Se você está avaliando um checkpoint não anunciado como o pplx-decider, a maneira de fazer isso sem apostar um caminho de produção nele é executá-lo você mesmo ao lado de um modelo roteado por trás de uma única API para mais de 200 modelos — preço de tabela do provedor repassado com 0% de margem, então quando esses projetos chegarem a um provedor de inferência, o preço de tabela é o preço aqui no mesmo dia. Até lá, um pplx-decider auto-hospedado ao lado de um typesafe/jev-1.13 roteado é a comparação que de fato vai lhe dizer algo.

Qual escolher

Se precisar de um modelo de decisão hoje, no seu próprio hardware, num tamanho à sua escolha, com notas de treino que pode auditar e uma licença que nada lhe exige, a resposta é um checkpoint Decider, e a única questão real é qual degrau. Comece em decider-2b; os números da v11 mostram a família a melhorar contra a sua própria v10 precisamente na divisão difícil que lhe interessaria, e a lacuna de ECE documentada diz-lhe para reajustar uma temperatura antes de confiar nas probabilidades em produção.

Recorra ao pplx-decider se quiser a mesma interface com um modelo denso maior por trás dela, se as entradas de imagem forem importantes e preferir não executar um segundo checkpoint, ou se for o tipo de equipa que prefere avaliar por si própria a cabeça de leitura de um laboratório de fronteira em vez de esperar por um post de lançamento que pode nunca chegar. As suas vantagens são reais, mas não verificadas: um backbone maior, uma tabela de benchmarks que o favorece e um pipeline de treino documentado até checksums ao nível do registo.

O que observar não é um benchmark. É se o pplx-decider chega sequer a um provedor de inferência. Um repositório com pesos e sem anúncio é um sinal, não um produto; no momento em que ele aparece em um endpoint hospedado, a questão de preço versus latência que os cards do Decider já respondem se torna uma comparação real em vez de uma aspiração.

Execute um pplx-decider auto-hospedado ao lado de um modelo de decisão roteado por trás de preço de tabela do provedor repassado com 0% de margem, então, quando qualquer um dos projetos chegar a um provedor de inferência, o preço listado é o preço aqui no mesmo dia.

Um novo checkpoint medido em relação a um ranking publicado também é um bom lugar para checar o histórico: os incidentes documentados de IA e as falhas de agentes em torno de modelos dessa classe estão reunidos no OrcaRouter AI Incident Archive, onde cada entrada traz suas próprias fontes, seu grau de severidade, sua classificação de confiança e sua sinalização de disputa.