Piccoli modelli decisionali arrivano on-device: Liquid AI, PostHog e Qevi presentano i loro classificatori

Tre modelli piccoli e specifici per un compito sono arrivati a poche ore di distanza l'uno dall'altro il 29 settembre. Tutti e tre partono dalla stessa idea: saltare la generazione di testo, leggere le probabilità direttamente dal modello e farlo girare su hardware che controlli tu.

La pagina di documentazione di Liquid AI descrive d1 come "a new class of AI model purpose-built for structured decisions". Invece di generare token uno alla volta, si legge nella pagina, un modello decisionale "evaluates a situation and returns calibrated probabilities across a fixed set of outcomes in a single call with zero generated tokens". La risposta di esempio fornita dall'azienda mostra usage.output_tokens: 0 per una query di rilevamento dei reclami che ha restituito un valore noul di 0.999.

Tre forme di domanda, nessun testo generato

Liquid divide le domande decisionali in tre tipi. Un noul è una domanda sì o no che restituisce una probabilità tra 0 e 1, che la documentazione descrive come "a boolean on a sliding scale". Una choice restituisce una distribuzione su opzioni denominate, per esempio {"billing": 0.65, "technical": 0.30, "account": 0.05}. Uno score restituisce una posizione ponderata per probabilità su una scala ordinata, quindi una domanda sull'urgenza a tre livelli può tornare come 1.85, tra "Medium" e "High".

La documentazione è esplicita: noul e score non sono intercambiabili. Un noul a 0.5 significa massima incertezza tra sì e no e "says nothing about degree or intensity". Se il codice deve confrontarsi con una soglia su un continuum, la documentazione rimanda a score. Se invece serve un gate booleano, noul. L'API prende uno stato più una o più domande denominate e risponde a tutte in un'unica chiamata. Le librerie client esistono per Python (typesafe-sdk) e JavaScript (@typesafe-ai/sdk), e le chiavi hanno il prefisso liquid_.

La pagina di Liquid è documentazione, non un paper di benchmark, quindi non riporta cifre di accuratezza per d1. La cosa conta, perché la stessa settimana ha prodotto due modelli che invece pubblicano numeri, e il divario tra loro è istruttivo.

Jeeves aggiunge il ragionamento alla formula Jev

Il repository GitHub di PostHog per Jeeves lo descrive come "a reasoning Jev-style classifier with a diffusion drafter, trained with SFT and CISPO". È un modello da 9B costruito su Qwen3.5-9B con LoRA e una pointer head, più un diffusion drafter a blocchi di 4 e il codice di training completo con i dati. Il repository sostiene che batte Kev-9B e Jev su dati di test su cui non è mai stato addestrato, con 0.889 contro 0.822 e 0.857, e sui tier pubblici di JevBench con 0.935 contro 0.866 di Jev.

Il repository pubblica una tabella più completa, e non è uniformemente lusinghiera. Jeeves segna 0.746 sui task di transfer che coprono MMLU-Pro e buried state, sotto lo 0.800 di Jev. Su MMLU scende a 0.793 contro lo 0.900 di Jev, e su MMLU-Pro 10-way cala a 0.739 contro 0.840. Vince su PAWS (0.875 contro 0.788), sulle strutture di regole tenute fuori (1.000 contro 0.885) e sulle policy contrastive (1.000 contro 0.963). Risponde poi a domande inconoscibili con p pari o superiore a 0.9 meno spesso di Jev, 0.055 contro 0.090, dove un valore più basso è meglio.

Il repository nota anche che, senza thinking, lo stesso checkpoint segna 0.804 sul suo split di test da 2.962 elementi, contro 0.840 con il thinking. La latenza è il prezzo: circa 0.3 secondi per richiesta senza thinking, e una mediana di 3.3 secondi con il thinking, su una H100 a precisione fp8. Su un M4 Pro una domanda pensa a circa 20 token al secondo. I pesi occupano 21 GB in bf16, e le cache predefinite ne aggiungono altri 28 GB, motivo per cui il README consiglia impostazioni di cache più piccole su un Mac da 48 GB.

Una avvertenza è stampata nella tabella stessa. Non è pubblicato alcun risultato di Kev-9B su JevBench, e le due righe con l'asterisco sono Kev-8B su Qwen3, quindi parte del confronto avviene con un modello diverso da quello che suggerisce l'intestazione della colonna.

Qevi-2B porta lo stesso trucco sulle immagini

La scheda del modello Qevi-2B su Hugging Face descrive un fine-tune completo di Qwen3-VL-2B-Instruct che risponde a domande chiuse e tipizzate sulle immagini "by reading the model's own logits instead of generating text". Chiedi se in una foto c'è una scala e restituisce P(Yes) = 0.97, non una frase. La scheda è netta: non è un modello conversazionale, e chiamare .generate() e analizzare il testo non riprodurrà i numeri pubblicati, perché non è il percorso su cui il modello è stato messo a punto.

La lettura è di circa 30 righe di normale codice transformers senza trust_remote_code. Rispetto al base Qwen3-VL-2B-Instruct fatto passare dallo stesso identico percorso di lettura, Qevi-2B passa da 0.855 a 0.977 di accuratezza in-domain e da 0.745 a 0.889 su 12 domini tenuti fuori. L'errore di calibrazione atteso sui dati tenuti fuori scende da 0.160 a 0.054. La scheda dice che il vantaggio di velocità arriva a circa 21 volte quando si pongono molte domande su una sola immagine, perché una maschera di attenzione a blocchi diagonali permette a più domande di condividere una sola codifica dell'immagine, verificata bit per bit rispetto a porle separatamente.

La scheda mette in guardia dal temperature scaling che consigliavano le versioni precedenti: con T = 2.45 l'ECE sui dati tenuti fuori è 0.160, praticamente il valore del modello base, e "the entire calibration gain is cancelled out".

C'è una seconda nota di onestà. Il corpus di addestramento contiene solo domande noul e choice. Il motore supporta score e il modello base gestisce queste domande zero-shot, ma il fine-tune non ne ha mai vista una, quindi la scheda afferma che accuratezza e calibrazione di score non sono misurate e vanno considerate non testate.

Perché l'argomento on-device continua a tornare

Il pezzo che Sebastian Raschka ha scritto il 29 settembre sulla storia della classificazione di testo è utile qui, perché inquadra a cosa rinunciano davvero questi modelli. Nota che i modelli GPT più recenti e quelli a pesi aperti sanno fare gli stessi compiti di classificazione di Jev pur essendo molto più generali, ma che il vantaggio di un modello in stile Jev è velocità e costo. All'altro estremo, "for a narrow, well-defined problem, Jev probably won't classify anything better, faster, or cheaper than a special-purpose classifier". Il punto di forza è la via di mezzo: più generale di un modello specifico per un compito, più economico di uno di frontiera.

L'articolo di Raschka ripercorre la discendenza fino alle rappresentazioni bag-of-words che alimentavano naive Bayes, regressione logistica, SVM e XGBoost, e nota che il filtro antispam di Gmail era presumibilmente un modello naive Bayes su bag-of-words. La differenza ora è che il classificatore è un modello linguistico messo a punto con una testa di probabilità calibrata, e può essere distribuito come pesi invece che chiamato come servizio.

È qui che l'argomento on-device morde. Jeeves gira su CUDA in bf16 o fp8, e anche su Apple Silicon via MPS, con una build fp8 che riduce i pesi a 11.5 GB e porta il throughput del thinking su un M4 Pro da circa 20 a circa 31 token al secondo. Il repository dice che accuratezza e NLL non sono cambiate in modo misurabile sulle domande di sviluppo, ed è pubblicato un repo PostHog/jeeves-fp8 già quantizzato, così il download è circa la metà.

Qevi-2B è ancora più piccolo, con 2B parametri, il tipo di ingombro che sta su un portatile o su un telefono invece che su un rack. La documentazione di Liquid descrive il modello come capace di valutare stato e domande in una sola chiamata con zero token in output, ed è la proprietà che rende prevedibile il costo per richiesta.

Le misure restano scarse

Niente di tutto questo è privo di problemi. La ricerca adiacente più recente, un paper arXiv inviato il 28 settembre da Cameron Berg e Caspar Kaiser, ha rilevato che in sette modelli a pesi aperti di cinque famiglie i pattern di attivazione nascosti legati alla valenza governano in modo prevedibile le scelte successive, anche quando ogni token visibile è identico. Gli autori scrivono che se queste tracce siano accompagnate da una qualche esperienza soggettiva rilevante per il benessere del modello "remains unclear". È un promemoria del fatto che leggere lo stato interno di un modello è ormai un pattern di progettazione, non solo una diagnostica.

L'obiezione pratica arriva dal blog per sviluppatori di Microsoft, pubblicato il 29 settembre, secondo cui i benchmark pubblici dicono poco sul proprio carico di lavoro. Il post cita la legge di Goodhart e osserva che i task di SWE-bench provengono da repository pubblici, quindi la sovrapposizione con i dati di addestramento è inevitabile e cresce a ogni generazione. Un modello che segna il 92% su SWE-bench, dice il post, è dimostrabilmente bravo a risolvere problemi ben documentati in repository popolari, e questo non dice nulla sulla tua libreria interna.

La stessa logica vale per i modelli decisionali. La tabella di Jeeves mostra che perde contro Jev su MMLU e MMLU-Pro mentre vince sulle strutture di regole tenute fuori. La risposta a "quale è meglio" dipende quindi interamente da quale distribuzione arrivano i tuoi ticket, le tue immagini o i tuoi documenti. Liquid non pubblica alcuna cifra di accuratezza per d1. La scheda di Qevi-2B elenca score tra i non testati. I numeri che esistono sono per lo più auto-dichiarati dai team che distribuiscono i modelli, su split che hanno scelto loro.

La novità di questa settimana non è che esistano piccoli classificatori. È che tre team diversi li hanno distribuiti con la stessa idea di interfaccia, probabilità calibrate su un insieme fisso di risposte in un solo forward pass, e li hanno fatti abbastanza piccoli da girare senza un datacenter. Se questo basti a spodestare il pattern modello di frontiera con fallback descritto dal README di Jeeves è una domanda a cui i benchmark pubblicati non sanno ancora rispondere.