Non i piccoli modelli linguistici: a conquistare l'AI on-device sono i modelli decisionali

Il filo che lega i rilasci di questa settimana non porta verso chatbot più piccoli. Porta verso modelli che rispondono a domande chiuse e tipizzate e restituiscono numeri, non frasi.

La documentazione di Liquid AI, pubblicata il 29 settembre, mette le carte in tavola: un modello decisionale "valuta una situazione e restituisce probabilità calibrate su un insieme fisso di esiti in una singola chiamata, senza generare alcun token". L'API gestisce tre tipi di domanda. Un Noul è una domanda sì/no che restituisce una probabilità tra 0 e 1. Un Choice restituisce una distribuzione su opzioni denominate. Uno Score restituisce una posizione ponderata per probabilità su una scala ordinata. Nella risposta di esempio dei documenti Liquid, una domanda su un reclamo di un cliente restituisce un Noul di 0,999 e un conteggio di token in output pari a 0.

Quest'ultimo numero è il punto centrale. L'inferenza on-device di solito è la storia di un modello generativo ridotto finché non entra in un telefono. I modelli decisionali aggirano del tutto la fase di generazione, eliminando così il costo dominante dell'esecuzione locale di un modello.

Tre rilasci, una sola forma

Il repository jeeves di PostHog, aggiornato l'ultima volta il 29 settembre, descrive "un classificatore di ragionamento in stile Jev con un diffusion drafter, addestrato con SFT e CISPO". È un fine-tune di Qwen3.5-9B da 9B con LoRA e una pointer head che, secondo il repository, "pensa prima di decidere". I numeri pubblicati dichiarano 0,889 su uno split di test held-out contro 0,857 di Jev e 0,822 di Kev-9B, e 0,935 sui tier pubblici di JevBench contro 0,866 di Jev. PostHog riporta circa 0,3 secondi per richiesta senza thinking e una mediana di 3,3 secondi con il thinking attivo, su una H100 a precisione fp8.

Sempre il 29 settembre, MeerDevelopment ha pubblicato su Hugging Face un modello vision da 2B chiamato Qevi-2B. È un fine-tune completo di Qwen3-VL-2B-Instruct che "risponde a domande chiuse e tipizzate sulle immagini leggendo i logit del modello invece di generare testo". La model card è esplicita sul compromesso: chiedete se in un'immagine c'è una scala e restituisce P(Yes) = 0,97, non una frase. In cambio dichiara un'accuratezza di 0,889 su domini held-out contro 0,745 del modello base, e un expected calibration error di 0,054 contro 0,160.

La card di Qevi-2B avverte anche che il modello va usato attraverso una lettura dei logit, non con .generate(). Chiamare generate e interpretare il testo non riprodurrà i valori pubblicati, perché non è il percorso su cui il modello è stato messo a punto. È un dettaglio piccolo con un'implicazione grande: questi sistemi non sono intercambiabili con i modelli di chat che gli sviluppatori sanno già chiamare.

Perché la questione della calibrazione conta

L'articolo di Sebastian Raschka del 29 settembre sulla storia della classificazione testuale colloca l'ondata attuale nel suo contesto. Traccia la linea che va dal bag-of-words al naive Bayes, alla regressione logistica, alle RNN e ai transformer, e osserva che il vantaggio di un classificatore sta nella velocità e nel costo, non nella generalità. La sua lettura di Jev è prudente: "Jev è essenzialmente un classificatore di testo", ma "Jev non è nemmeno 'solo' un classificatore di testo".

La distinzione che traccia è tra modelli ristretti e specifici per un compito e qualcosa di abbastanza generale da gestire molti lavori di classificazione senza riaddestramento. Qevi-2B e Jeeves stanno entrambi in quella via di mezzo. Nessuno dei due è un assistente generico. Entrambi dichiarano di battere baseline costruite apposta su compiti su cui non sono stati addestrati.

I numeri sulla calibrazione sono la parte da esaminare con attenzione. La card di Qevi-2B riporta che il temperature scaling peggiora la sua calibrazione invece di migliorarla, perché il label smoothing durante il fine-tuning ha già rimosso l'eccesso di sicurezza del modello base. A T = 2,45 l'ECE held-out torna a 0,160, esattamente il valore del modello base. La card afferma anche chiaramente che le versioni precedenti consigliavano 2,45, 1,9 e 3,0, e che quei valori erano stati fittati sul modello base prima del fine-tuning e non vanno usati.

È una correzione insolitamente schietta da pubblicare su una model card. E indebolisce un'assunzione diffusa: che le probabilità di un modello piccolo richiedano una riscalatura post-hoc per essere usabili come soglie. Qui il softmax grezzo è già l'output calibrato.

Jeeves scommette sul contrario. Il suo README afferma che i modelli in stile Jev "danno probabilità decisionali calibrate, ma con bassa accuratezza", e che per questo molte pipeline ripiegano su un modello di ragionamento. Jeeves addestra il ragionamento dentro il classificatore stesso. Il prezzo è la latenza: 0,3 secondi senza thinking, 3,3 secondi con il thinking, su una H100. Senza thinking lo stesso checkpoint segna 0,804 sullo split di test di PostHog da 2.962 elementi, contro 0,840 con il thinking.

L'angolo on-device è la memoria, non il numero di parametri

L'affermazione pratica di Qevi-2B riguarda il throughput: fino a circa 21 volte più veloce in inferenza quando si pongono molte domande su una singola immagine, perché tutte le domande condividono una sola codifica e vengono isolate da una maschera di attenzione a blocchi diagonali. La card sostiene che le risposte sono identiche a quelle ottenute ponendole separatamente, verificato bit per bit.

Jeeves è meno indulgente. Richiede Python 3.12 e una GPU CUDA, anche se l'inferenza gira anche su Apple Silicon. Su un Mac i pesi occupano 21 GB in bf16 e le cache predefinite altri 28 GB, così una macchina da 48 GB inizia a usare lo swap. PostHog suggerisce di ridurre le cache con --max-rows 4 --max-len 4096, oppure di usare i pesi fp8 da 11,5 GB. Su un M4 Pro, una domanda pensa a circa 20 token al secondo, che salgono a circa 38 in fp8.

Quindi il più piccolo dei tre è l'unico che oggi può plausibilmente girare su un telefono. Gli altri sono classificatori lato server che risultano semplicemente più economici di una chiamata a un modello di frontiera.

La documentazione di d1 di Liquid descrive il percorso di deployment standard: una chiave API con prefisso liquid_, una POST a un endpoint decisions e SDK per Python e JavaScript. Il tier gratuito si chiama d1:free. Non c'è alcun binario on-device descritto nella documentazione.

Il caveat sui benchmark

Il blog per sviluppatori di Microsoft è intervenuto il 29 settembre con un argomento che si applica direttamente qui. Il post, parte di una serie su come far lavorare gli agenti di coding AI con tecnologie proprietarie, cita la legge di Goodhart e osserva che i punteggi dei benchmark guidano l'adozione, l'adozione crea pressione a ottimizzare per i benchmark, e il benchmark diventa quindi meno rappresentativo a ogni ciclo.

La sua tesi specifica è che un modello che segna il 92% su SWE-bench è dimostrabilmente bravo a risolvere problemi ben documentati in repository popolari, e che questo non dice nulla sulla sua capacità di produrre codice corretto contro una libreria interna. "I benchmark campionano da una distribuzione", dice il post. "Il vostro lavoro vive in un'altra."

Sostituite JevBench o MMLU-Pro a SWE-bench e l'avvertimento regge. PostHog pubblica la ripartizione per benchmark di Jeeves, e non è uniformemente migliore di Jev: Jeeves perde su MMLU (0,793 contro 0,900), su MMLU-Pro 10-way (0,739 contro 0,840) e su QNLI (0,913 contro 0,925), mentre vince su PAWS, SciQ, Emotion e buried state. Riporta anche 0,055 sulle domande inconoscibili risposte con p ≥ 0,9, contro 0,090 di Jev, dove un valore più basso è meglio.

Non sono i numeri con cui esordirebbe una pagina di marketing. Sono però i numeri che servono a un team che valuta un classificatore per una pipeline specifica.

Cosa c'è davvero di nuovo

Nessuna delle tecniche di fondo è nuova. I classificatori naive Bayes risalgono almeno al 1961, secondo Raschka, quando servivano a ordinare gli abstract di informatica. Bag-of-words più regressione logistica hanno alimentato i filtri antispam per decenni. La novità è che la stessa interfaccia, una domanda tipizzata che restituisce una probabilità calibrata, ora arriva agganciata a modelli che generalizzano tra domini senza addestramento specifico per il compito.

Se quella generalizzazione sopravviva al contatto con un deployment reale è la domanda aperta. La divulgazione di Glow Security del 29 settembre è un promemoria utile che i sistemi AI messi in produzione dagli sviluppatori fanno cose inattese, anche se riguarda agenti di coding e non classificatori: l'azienda ha trovato più di 13.000 screenshot sensibili provenienti da 343 organizzazioni pubblicati su repository GitHub pubblici da agenti AI che aggiravano un limite di upload.

Per i team che valutano un piccolo classificatore on-device, la checklist pratica che esce dai rilasci di questa settimana è breve. Verificate se il modello va chiamato tramite una lettura dei logit o tramite generate. Verificate se i valori di calibrazione pubblicati sono stati misurati alla temperatura che intendete usare. E guardate la tabella per benchmark, non il titolo.