pplx-decider vs Decider: il 27B silenzioso di Perplexity contro l'Open Ladder di Mapika

Due modelli decisionali sono su Hugging Face proprio ora che rispondono alle domande allo stesso modo e non concordano su quasi nient'altro. pplx-decider è un checkpoint da 27B di Perplexity arrivato il 2026-10-01 senza annuncio, senza post sul blog, senza pagina dei prezzi e senza alcun provider di inferenza che lo supporti; una revisione, pplx-decider-v1.1, è seguita il 2026-10-05 sullo stesso backbone. Decider è la famiglia di Mapika della stessa classe di modello — decider-0.8b fino a decider-35b-a3b, una riproduzione aperta nella linea System One, pubblicata con note di addestramento complete. Entrambi prendono un blocco di domande denominate più un documento e restituiscono una probabilità calibrata per risposta in un singolo passaggio in avanti. Nessuno dei due scrive una singola frase di prosa. Quello che segue è ciò che risulta effettivamente documentato per ciascuno, e un chiaro indicatore ovunque il resoconto si interrompa.

Innanzitutto, cosa ci fa "decision model" in quella frase?

Nessuno dei due è un modello di chat a cui è stato chiesto di essere conciso. Non sono affatto modelli linguistici nel senso usuale: non c'è alcun ciclo di decodifica, alcun campionamento, nulla token per token. Una singola passata in avanti sul tuo documento restituisce una probabilità per ogni opzione che hai fornito.

È la forma della chiamata a rendere il confronto degno di essere scritto. Si consegna uno stato (un ticket, un record JSON, uno screenshot, un contratto) e un elenco di domande denominate. Ogni domanda indica il proprio tipo di risposta: scelta tra 2 e 255 opzioni etichettate, una lettura sì/no/sconosciuto, o un punteggio su un numero di livelli descritti compreso tra 2 e 10. Le risposte vengono restituite nell'ordine in cui le hai chieste, come numeri tra 0 e 1, e il numero va letto come una probabilità anziché come un'etichetta netta — 0,62 su "è richiesto un rimborso?" è l'intero output, e il chiamante decide la soglia.

Quel design elimina latenza e costo, perché un documento con sessanta domande costa un'unica passata, non sessanta. Significa anche che i soliti modi di valutare un modello linguistico non si applicano: non c'è alcuna traccia di ragionamento da leggere, nessuna catena di pensiero con cui discutere, nessun modo di chiedergli di spiegarsi. Ottieni massa di probabilità e nient'altro. Entrambi i progetti dichiarano esplicitamente che questo è il compromesso.

Cosa è stato rilasciato, e cosa nessuno ha detto

Il repository pplx-decider è insolitamente completo per un modello senza un post di lancio alle spalle. I pesi sono Apache-2.0. La base è Qwen/Qwen3.8-27B, indicato sulla scheda. C'è una testa di readout rilasciata in bf16 a [255, 5120], che è esattamente la forma che ci si aspetterebbe per 255 opzioni selezionabili su uno stato nascosto largo 5.120. La scheda documenta il budget di input, il limite massimo di opzioni, i tre tipi di domanda e la forma dell'endpoint — POST /v1/systemone.

Ciò che non c’è è la frase che accompagnerebbe un post di lancio. Sulla scheda non c’è una data di rilascio, nessun annuncio, nessun post di benchmark da Perplexity, nessun prezzo e nessuna piattaforma di terze parti che lo serva. I conteggi dei download sono della dimensione che si ottiene da un repository che è stato trovato, non promosso. Leggendo le due cose insieme, la descrizione onesta è: l’artefatto è pubblico, l’intento dietro di esso no. Tutto ciò che segue su pplx-decider proviene dal repository e dalle sue schede. Nulla di ciò che segue è stato riprodotto in modo indipendente, e nessuno al di fuori del laboratorio ha pubblicato una propria esecuzione.

La voce della libreria Ollama rende quel divario visibile in piccola misura. La sua pagina elenca il tag come 27b a 17 GB con una finestra di contesto di 256K — una build quantizzata, ben al di sotto dei circa 49 GiB occupati dai pesi bf16 — mentre il repository documenta un budget di input testo-e-immagini molto più piccolo e afferma che gli input sovradimensionati vengono rifiutati anziché troncati. Queste due affermazioni non descrivono evidentemente lo stesso limite, e nulla di pubblicato le concilia. Considera il numero del runtime come l'affermazione del runtime.

La parte interessante: due sconosciuti, un'interfaccia

La famiglia Decider di Mapika e pplx-decider sono stati sviluppati in modo indipendente, da basi diverse, per ragioni diverse, e sono convergiti sullo stesso formato di trasmissione. Anche i modelli Decider parlano la forma di chiamata di System One — domande con nome, scelta tra 2 e 255 opzioni, nessuna generazione di testo, stati accettati fino a circa 32k. Un client scritto per uno è, all'incirca, un client per l'altro.

Quella convergenza è il dato utile in questo confronto. Quale dei due scegli non è una riscrittura; è uno scambio di un URL di base e di una stringa di modello. La domanda interessante smette di essere "quale API integro" e diventa "di quale lettura mi fido sui miei documenti" — e i due progetti rispondono a quella domanda in modi molto diversi.

Un checkpoint contro una scala

La differenza strutturale è la più facile da notare. Perplexity ha rilasciato una sola dimensione. Mapika ha rilasciato una gamma e pubblicato la tabella delle dimensioni:

• Catalogo — ppl-decider: un checkpoint 27B, più una revisione v1.1 sullo stesso backbone. Decider: oltre sette dimensioni pubblicate, da decider-0.8b a 1,4 GB fino a decider-2b, decider-2b-vision, decider-4b, decider-12b e decider-35b-a3b a 65 GB bf16 o 19,6 GB in nvfp4.

• Basi — pplx-decider: Qwen/Qwen3.8-27B, un'unica discendenza. Decider: un mix — Qwen3.5-0.8B, Qwen3.5-2B e Qwen3.5-4B per le dimensioni piccole, Qwen3.5-35B-A3B per quella grande, e gemma-4-12B-it e gemma-4-31B-it nelle varianti chat.

• Attivazione — pplx-decider: denso 27B, quindi ogni parametro viene eseguito a ogni chiamata. Decider: decider-35b-a3b è una miscela — 34,7B totali con circa 3B attivi su 256 esperti instradati, 8 dei quali attivi per token.

• Vision — pplx-decider: multimodale, e il repository lo dice; testo, JSON e immagini inclusi screenshot, ricevute e moduli, con i token di visione che costano all'incirca larghezza × altezza / 1024. Decider: un checkpoint separato decider-2b-vision invece di un flag sulla linea principale, quindi il lavoro sulle immagini è una scelta di modello diversa, non un argomento diverso.

• Licenza — Apache-2.0 su entrambi i lati, che è l'unico punto in cui questo confronto è noioso.

• Informativa sull'addestramento — pplx-decider: una pipeline di dati basata su Bespoke Nimble di Bespoke Labs, con sottoinsiemi di benchmark fissati tramite ID record e checksum, e i miglioramenti della v1.1 attribuiti alla rimozione della maschera causale e all'aggiunta di dati, tra cui tasksource. Decider: note per versione con conteggi degli elementi, hardware e tempo reale — decider-35b-a3b addestrato su 4× B300 per 394 minuti su 1.543.567 elementi — più modalità di errore denominate e la quota di parametri effettivamente addestrati, 2,45B su 34,7B.

Nessuno dei due è un vantaggio decisivo. Un singolo checkpoint è più semplice da comprendere, più facile da servire e impossibile da ridimensionare. Una scala ti permette di mettere decider-0.8b dietro un pre-filtro economico e spendere i 35B solo sugli elementi che ne hanno bisogno — ma solo se sei disposto a mantenere la logica di routing che decide quale sia quale.

I numeri, e chi li ha prodotti

Entrambe le serie di cifre principali sono comunicate dai fornitori, e nessuna delle due è accompagnata da una replica indipendente. Questo qui conta più di quanto non accada di solito, perché non esiste una classifica di modelli decisionali di terze parti che abbia l’autorevolezza delle arene per le immagini o per il linguaggio.

I dati forniti da Perplexity stessa per pplx-decider lo collocano all'85,7% su 11 benchmark pubblici, contro l'84,5% di Jev e il 74,8% della base Qwen3.8-27B da cui è stato addestrato. Tra le singole voci riportate figurano RAGTruth 88,8, FinancialPhraseBank 84,2, TabFact 90,6, JudgeBench 78,3 e WinoGrande 83,3, mentre l'insieme più completo comprende Circa, Belebele, TruthfulQA binary, BBH, ContractNLI e una suddivisione hard pubblica di JevBench. La revisione v1.1 riporta un punteggio complessivo ponderato sulla suite di 61,56 contro 56,4 per la v1 e 57,9 per Jev, con il maggiore incremento in una singola categoria nei compiti linguistici. Il confronto con Jev è quello del fornitore, calcolato sulla suite dello stesso fornitore, e la ponderazione non è pubblicata.

Il reporting di Mapika ha una consistenza diversa: le cifre arrivano accompagnate da avvertenze che le ridimensionano. decider-35b-a3b riporta 0,855 in-task e 0,810 held-out rispetto a una base zero-shot di 0,732, e 0,676 sulla suddivisione hard pubblica di JevBench — al di sotto dello 0,730 di Jev 1.13.0. La scheda afferma inoltre che non esiste una fase di reinforcement, quindi il sampled play si attesta all'86,4% contro il 93,2% di decider-2b v10, e che il modello è troppo sicuro di sé sugli elementi più difficili, con un errore di calibrazione atteso di 0,15 sul livello hard. decider-2b v11 è riportato a 0,802 in-task e 0,752 held-out con un ECE di 0,156 rispetto a una linea guida di rilascio dichiarata di 0,08 — un obiettivo mancato, messo per iscritto dagli autori.

Due modalità di errore documentate vale la pena tenerle presenti in qualsiasi valutazione si esegua. La selezione di un record in base alla sua posizione in un lungo array JSON è descritta come la forma di input meno accurata gestita dalla famiglia, e raggruppare diverse domande indipendenti in un'unica chiamata può ribaltare fino al 12% delle risposte quando il flag independent è disattivato. Entrambe sono il tipo di cosa che una scheda tecnica nasconde e una card menziona una volta sola.

Quanto costa far funzionare l'uno o l'altro

• Il Decider più piccolo utilizzabile — decider-0.8b è 1,4 GB. pplx-decider non ha una variante piccola, quindi il suo minimo è il 27B completo.

Il Decider più grande — decider-35b-a3b a 65 GB in bf16 o 19,6 GB in nvfp4, con solo circa 3B parametri attivi per token.

Latenza, lato Decider — decider-2b viene eseguito in 4 ms per richiesta con CUDA graphs su un B300, in calo rispetto a 18,9 ms in modalità eager, e circa 2.700 decisioni al secondo con batch 32. Il 35B è un altro mondo: circa 47 ms per un ticket da 92 token con tre domande, 368 ms per 64 ticket.

• Latenza, lato pplx-decider — nessuna pubblicata. Le schede non forniscono alcun valore di throughput o latenza, il che è normale per un repository che non è stato lanciato.

• Costo per decisione — è qui che il design ripaga su entrambi i fronti. Sessanta domande su un unico documento equivalgono comunque a un solo forward pass, quindi il costo per decisione crolla man mano che si fanno più domande sullo stesso documento.

Ecco il quadro onesto del routing. OrcaRouter non serve pplx-decider e non serve la famiglia Decider di Mapika — nessuno dei due compare nel catalogo, e nulla in questo articolo deve essere letto come un'affermazione contraria. Ciò che il catalogo offre in questa classe oggi è typesafe/jev-1.13, un modello decisionale della stessa forma System One con una finestra di 65.536 token esposta attraverso lo stesso endpoint POST /v1/systemone a 0,042 $ per milione di token di input, il che è un utile punto di riferimento per quanto costa un modello decisionale instradato. Se stai valutando un checkpoint non annunciato come pplx-decider, il modo per farlo senza puntare un percorso di produzione su di esso è eseguirlo tu stesso accanto a un modello instradato dietro un'unica API per oltre 200 modelli — il prezzo di listino del provider passato con 0% di markup, quindi quando questi progetti raggiungeranno un fornitore di inferenza, il prezzo di listino è il prezzo qui lo stesso giorno. Fino ad allora, un pplx-decider self-hosted accanto a un typesafe/jev-1.13 instradato è il confronto che ti dirà davvero qualcosa.

Quale scegliere

Se ti serve oggi un modello decisionale, sul tuo hardware, di una dimensione che scegli tu, con note di addestramento che puoi verificare e una licenza che non ti chiede nulla, la risposta è un checkpoint Decider, e l'unica vera domanda è quale gradino. Parti da decider-2b; i numeri della v11 mostrano che la famiglia migliora rispetto alla propria v10 proprio sulla split difficile che ti interesserebbe, e il divario ECE documentato ti dice di rifare il fit di una temperatura prima di fidarti delle probabilità in produzione.

Affidati a pplx-decider se vuoi la stessa interfaccia con un modello denso più grande alle spalle, se gli input immagine contano e preferisci non eseguire un secondo checkpoint, o se sei il tipo di team che preferirebbe valutare da sé la testa di lettura di un laboratorio di frontiera piuttosto che aspettare un post di lancio che potrebbe non arrivare mai. I suoi vantaggi sono reali ma non verificati: una backbone più grande, una tabella di benchmark che lo favorisce, e una pipeline di addestramento documentata fino ai checksum a livello di record.

Ciò a cui fare attenzione non è un benchmark. È se pplx-decider riesce affatto a raggiungere un provider di inferenza. Un repository con i pesi e nessun annuncio è un segnale, non un prodotto; nel momento in cui compare su un endpoint ospitato, la questione prezzo-contro-latenza a cui le card di Decider già rispondono diventa un confronto reale anziché un'aspirazione.

Esegui un pplx-decider self-hosted accanto a un modello decisionale instradato dietro prezzo di listino del provider riportato con markup dello 0% , così quando uno dei due progetti raggiunge un provider di inferenza, il prezzo di listino è il prezzo qui lo stesso giorno.

Un nuovo checkpoint misurato rispetto a una scala pubblicata è anche un buon momento per verificare lo storico: gli incidenti AI documentati e i fallimenti degli agenti relativi ai modelli di questa classe sono raccolti in the OrcaRouter AI Incident Archive, dove ogni voce riporta le proprie fonti, la gravità, il grado di confidenza e il flag di contestazione.