pplx-decider vs Kev: Dois Sistemas, Um Modelo Que Você Já Pode Baixar

O acidente útil neste confronto é que você pode resolver isso no seu próprio hardware esta tarde. pplx-decider, o modelo de decisão de 27B da Perplexity, surgiu em 2026-10-01 sem anúncio algum e com uma revisão v1.1 em 2026-10-05, e ambos estão na biblioteca do Ollama. Kev, a linha de reprodução de Jared Palmer, está no Ollama desde que a v2 chegou, em 2026-09-30, e cobre de 0.5B a 27B. Eles usam o mesmo formato de chamada — um estado mais uma lista de perguntas nomeadas, uma passagem direta, uma probabilidade de volta, nenhum texto gerado — o que significa que o mesmo harness pode executar os dois. O que difere é tudo o que está por baixo: como a saída é produzida, o que os autores documentaram e quanta GPU é exigida.

Comece pelo que torna um bake-off possível. Nenhum dos modelos escreve texto. Você entrega um documento e faz perguntas pelo nome, cada pergunta declarando o seu tipo de resposta — uma escolha entre 2 a 255 opções rotuladas, uma leitura sim/não/desconhecido, ou uma pontuação ao longo de 2 a 10 níveis descritos. A resposta chega como uma probabilidade, na ordem em que você perguntou. Um ticket com sessenta perguntas é uma única passagem pelo modelo, não sessenta chamadas.

Quanto de cada modelo está realmente tomando a decisão

A ficha de Kev é explícita sobre sua construção de um modo raro fora de documentações internas, e vale a pena ler os detalhes antes de confiar em qualquer número dela. O checkpoint de 27B é um ajuste fino supervisionado de pesos completos sobre o Qwen/Qwen3.8-27B e, em seguida, uma média de pesos — 0,85 do novo modelo combinado com 0,15 da v1 em fp32. Os tamanhos menores, de 0,8B a 9B, vêm como adaptadores LoRA sobre bases Qwen3.5, em vez de checkpoints completos.

A parte que decide como a saída é moldada é separada do backbone de linguagem. O Kev carrega uma cabeça de ponteiro — cerca de 2,6M de parâmetros em fp32, assentada sobre um backbone de 25,6B para totalizar 26B — e é ela que transforma um estado oculto numa probabilidade sobre as opções que você nomeou. O pplx-decider faz o mesmo trabalho com uma cabeça de leitura disponibilizada de [255, 5120]: 255 opções sobre um estado oculto de 5.120 de largura, em bf16.

Duas arquiteturas, uma ideia: o modelo de linguagem lê, uma cabeça pequena decide. É por isso que nenhuma das duas gera prosa, e é também por isso que uma pontuação de benchmark de uma não se transfere para a outra, mesmo quando ambas são comparadas ao mesmo modelo de referência.

O único confronto direto registrado, e por que você não pode subtraí-lo

Os dois projetos reportam a Jev, o que torna tentador alinhá-los. Não o faça.

O card do próprio Kev traz uma linha do Decision Index 0.2 que coloca o Kev-27B v2 em 52,3 contra 50,2 do v1, Jev em 54,0 e AutoJev-27B em 50,0. Essa é uma comparação limpa, na mesma suíte e mesma versão, e mostra que o Kev v2 melhorou cerca de dois pontos e ainda fica atrás do Jev.

Os cards do pplx-decider reportam um resultado geral ponderado pela suíte de 61,56 para a v1.1, contra 56,4 para a v1 e 57,9 para o Jev. Pelos próprios números deles, isso representa um ganho de mais de cinco pontos em uma revisão e uma vantagem sobre o Jev de mais de três pontos e meio.

Esses dois parágrafos não podem ser subtraídos um do outro. Suítes diferentes, misturas de tarefas diferentes, ponderações diferentes — e nenhum dos projetos publica a ponderação. O que dá para dizer é mais restrito e ainda assim útil: ambos se moveram na mesma direção na mesma janela, ambos o fizeram mudando como o readout é treinado, em vez de trocar o backbone, e a margem alegada do pplx-decider em relação ao Jev é maior que o déficit medido do Kev. Isso é um motivo para testar o pplx-decider, não um motivo para acreditar nele.

Apenas um dos dois tem uma replicação independente associada a qualquer um dos seus números. As tags do Ollama do Kev publicam contagens de aprovação do JevBench por tag — 205 de 231 para kev:27b-nvfp4, incluindo 86 de 111 na divisão difícil, caindo para 146 de 231 para kev:0.8b — com uma observação explícita de que estas excluem 303 tarefas indisponíveis, seladas ou avaliadas por juiz, e não são uma pontuação oficial de leaderboard. É uma execução própria, mas é uma execução própria que você pode repetir. Não existe nada comparável para o pplx-decider.

O que o Kev documenta que o pplx-decider não documenta

• Temperatura — Kev vem com T = 1.32, um intervalo de 90% de [1.20, 1.45], aplicado no carregamento, então as probabilidades que você obtém já estão escalonadas. Os cards do pplx-decider não publicam temperatura alguma, o que significa que qualquer calibração de que você precise cabe a você ajustar.

• Registro de treinamento — Kev v2 tem 129 horas de GPU em 8× H200, uma época sobre 145.840 registros e 337.130 perguntas, rótulos produzidos por GLM-5.3, DeepSeek-V4-Pro, Inkling, Mistral Large 3, gpt-oss-120b e MiMo-V2.6-Pro sem nenhuma saída do Jev utilizada, e uma triagem de contaminação que removeu 6.388 registros em 102 partições de avaliação. pplx-decider documenta um pipeline construído sobre o Bespoke Nimble da Bespoke Labs com subconjuntos de benchmark fixados por ID de registro e checksum, e atribui os ganhos da v1.1 à remoção da máscara causal mais dados de treinamento adicionados — mas não publica contagem de registros, horas de GPU nem lista de rotuladores.

Relato honesto de regressão — o cartão do Kev imprime suas próprias falhas: transfer-v4 caiu 0,8 ponto, CUAD caiu 1,6, erro de calibração esperado em breadth-v1 de 0,015 contra 0,053 em CUAD, de duas a quatro vezes pior que v1, e ele nomeia o otimismo de seleção em sua própria avaliação. A tabela v1.1 do pplx-decider mostra as ferramentas caindo de 79,3 para 78,88 enquanto todas as outras categorias sobem, e nada no cartão faz observação sobre isso.

• Modos de falha — o cartão do Kev lista o escopo de triagem de contaminação e as condições em que os seus números publicados foram produzidos. A família Decider, a linha da Mapika, vai mais longe e nomeia formas de entrada específicas que a quebram; o pplx-decider não se pronuncia sobre a questão.

Nada disso diz que o pplx-decider é pior. Documentação não é capacidade — um laboratório com um post de lançamento em rascunho tem incentivos diferentes de um indivíduo publicando notas no Hugging Face. Mas quando dois modelos reivindicam a mesma classe de resultado e apenas um deles informa sua temperatura, o que informa é o que você pode colocar em produção neste mês.

Contabilidade de contexto, que é onde os dois divergem mais radicalmente.

• Kev — 65.536 tokens de estado, mais pelo menos 8.192 tokens por pergunta, com treinamento em até 32.768. Em um estado de 64k, a pegada residente atinge cerca de 87,1 GB no pico, tempo de modelo de 9,4 segundos, 733 ms em um acerto de cache, e 21,1 solicitações por segundo com um único cliente, contra 36,4 com sessenta e quatro.

• pplx-decider — 8.192 tokens para texto e imagens combinados, com entradas grandes demais rejeitadas em vez de truncadas. A build do Ollama lista uma janela de contexto de 256K, que nada no repositório explica e que não é compatível com o próprio limite do card.

Essa lacuna é a diferença mais decisiva entre os dois para cargas de trabalho reais. O Kev foi construído para estados longos e muitas perguntas sobre eles. O pplx-decider é um modelo denso de 27B com um orçamento de entrada comparativamente pequeno, o que o empurra para documentos curtos, imagens e perguntas que cabem dentro de alguns milhares de tokens.

• Idioma — apenas inglês em ambos, declarado como uma limitação em ambos.

• Visão — pplx-decider recebe texto, JSON e imagens, com tokens de visão custando aproximadamente largura × altura / 1024 e uma configuração de avaliação limitada a 512×512. Kev não tem visão na linha 27B.

• Piso de serviço — Kev-27B precisa de uma GPU da classe de 80 GB: 51,3 GB de pesos bf16, cerca de 65,5 GB residentes, 87,1 GB em um estado de 64k, e o seu servidor escuta abertamente a menos que KEV_API_KEY esteja definida. Os pesos bf16 do pplx-decider são cerca de 49 GiB, então o piso é semelhante; a versão quantizada do Ollama fica em 17 GB, o que é uma máquina muito diferente.

• Níveis — Kev abrange 0,5B, 0,6B, 0,8B, 4B, 8B, 9B e 27B, com os tamanhos pequenos como adaptadores LoRA. pplx-decider é um único tamanho, revisado duas vezes.

Realizando o bake-off sem apostar nele

Ambos os modelos são acessíveis como pesos locais, que é exatamente a situação em que uma camada de roteamento se paga. O OrcaRouter não atende o pplx-decider nem o Kev — nenhum dos dois está no catálogo, e nada aqui deve ser lido como uma alegação de que os hospedamos. O que temos nessa classe é o typesafe/jev-1.13, exposto por meio do mesmo formato de chamada POST /v1/systemone a $0,042 por milhão de tokens de entrada, e ele é o braço de controle natural: mesma interface, mesmos tipos de pergunta, nenhuma GPU própria.

Isso torna uma disputa de três vias barata de montar. Coloque um pplx-decider local e um Kev local sob o mesmo harness contra um typesafe/jev-1.13 roteado, pontue os três nos seus próprios documentos e deixe a discordância entre eles mostrar onde seus limiares realmente ficam. O failover automático importa mais do que o normal nesse arranjo, porque um 27B local em uma única placa é o componente menos confiável da cadeia; rotear o fallback através de uma API para mais de 200 modelos — preço de tabela do provedor repassado com 0% de margem — evita que o experimento se transforme em uma indisponibilidade. E quando um modelo como o pplx-decider eventualmente chegar a um endpoint hospedado, a mesma chave que executa o braço de controle o executa, sem um segundo contrato e sem alteração de código.

O que mudaria a resposta

Quatro coisas, e todas elas são verificáveis, e não uma questão de gosto.

Se o pplx-decider chegar a um provedor de inferência, sua tabela de benchmark não verificada se torna uma questão de preço versus latência, e a lacuna na documentação deixa de importar — você estaria pagando por uma leitura hospedada, não por manter uma. Se um terceiro independente reproduzir os números de JevBench de qualquer um dos modelos em um harness publicado, toda a comparação se reduz a uma única suíte, em vez de duas incompatíveis.

Se a fraqueza documentada de ECE do Kev no CUAD for corrigível com um reajuste em vez de um retreinamento, o argumento de calibração contra ele em grande parte desaparece, porque o Kev já entrega sua temperatura e seus modos de falha são grandezas conhecidas. E se você precisar de um modelo de decisão em uma única placa em vez de duas, a versão quantizada de 17 GB do pplx-decider é a única opção aqui — não porque seja melhor, mas porque cabe onde um 27B em bf16 não cabe.

Até que uma dessas coisas aconteça, a leitura prática é sem glamour. Kev é aquele cujos números você consegue repetir hoje e cuja calibração você pode confiar que está documentada; pplx-decider é aquele com o teto alegado melhor e a trilha documental mais fraca. Escolha o primeiro se você for lançar este mês. Traga o segundo para a mesma estrutura de avaliação se você for o tipo de equipe que prefere medir um lançamento silencioso a esperar por um post de lançamento.

Encaminhar o fallback por meio de preço de tabela do provedor repassado com 0% de markup evita que uma avaliação comparativa de três opções se transforme em uma indisponibilidade quando o checkpoint local é o componente menos confiável da cadeia.

Um teste comparativo triplo também é um momento razoável para perguntar o que já falhou nesta classe: os incidentes de IA documentados e as falhas de agentes envolvendo modelos de decisão estão reunidos em o OrcaRouter AI Incident Archive, onde cada entrada traz suas próprias fontes, gravidade, grau de confiança e indicador de disputa.