Modelli di decisione in locale: JEV-35B e il System 1 da 3B attivi

Un solo passaggio, nessuna generazione

C'è un compito che i grandi LLM fanno, e che non ti serve fare così: decidere. Classificare un ticket, scegliere a quale team mandarlo, dare un punteggio di rischio, dire sì o no. Per questo non serve un modello che scrive frasi: serve uno che risponde a una domanda precisa con una probabilità per ogni opzione, in un solo passaggio, senza decodificare un token.

Questo è un modello di decisione. Non genera testo: legge lo stato, legge la domanda, e restituisce una distribuzione di probabilità sulle opzioni. È il System 1 — rapido, istintivo, calibrato — contro il System 2 del LLM che ragiona, scrive e si prende il suo tempo.

L'idea non è nuova, ma due release di ottobre la rendono concreta in locale. JEV-35B di Autotrust è un MoE da 35B parametri (3B attivi per token) che gira quantizzato in NVFP4 su una GPU da 32 GB. ej è il contrario: 11,4 MB, picco di memoria residua di 128 MB, gira su CPU. Due estremi, stessa categoria: modelli che decidono, non che scrivono.

Cos'è un modello di decisione (e cosa non è)

Un LLM generativo prende un prompt e produce una sequenza di token, un per volta. Un modello di decisione fa una cosa sola: dato uno stato e una domanda tipizzata, restituisce una probabilità per ogni opzione.

Le domande tipizzate sono di tre tipi:

Tipo	Input	Output
choice	istruzione + lista di opzioni	una probabilità per opzione
noul (sì/no)	un'affermazione	P(false), P(true)
score	istruzione + livelli ordinati	una distribuzione sui livelli

Il vantaggio è duplice. In primo luogo, velocità e costo: niente loop di generazione, un solo forward pass. JEV-35B risponde in 204 ms di mediana su una singola GPU; ej in 214 ms su una CPU a 4 core. In secondo luogo, niente formattazione da perdere: l'output è già la risposta (l'opzione più probabile), non un testo da cui estrarla.

Non è un chatbot. JEV-35B non fa conversazioni, non genera testo libero. Se ti serve scrivere, quel modello non c'entra.

JEV-35B: il decisionista da 32 GB

JEV-35B è un fine-tune di Qwen3.5-35B-A3B (MoE, 35B totali, ~3B attivi per token), Apache-2.0. Un decision head di 264 slot dà un logit per slot; i slot attivi della domanda vengono soft-mass con una temperatura per tipo.

Il punto che cambia l'hardware è la quantizzazione. I numeri del vendor:

Versione	Download	Memoria GPU (pesi)	Decision Index 0.3
JEV-35B bf16	72 GB	66,5 GiB	59,73
JEV-35B-NVFP4	25,6 GB	23,3 GiB	59,18

Il passaggio a NVFP4 porta i pesi da 66,5 a 23,3 GiB: sta su una GPU da 32 GB o più, e le risposte restano identiche al bf16 nel 96,6% dei casi. Il calcolo è semplice: 35B di parametri a 16 bit pesano ~72 GB; a 4 bit (NVFP4) scendi a un quarto dei bit per peso, e con l'overhead resti sotto i 25,6 GB di download.

Dove brilla è dove dovrebbe: classificazione e routing. BANKING77 a 0,921, CLINC150+OOS a 0,943, il riconoscimento di intent in genere. La sua area forte è Retrieval & Classification (skill 0,710); la debole è Knowledge & Reasoning (GPQA 0,360). Per quello c'è un LLM vero.

Per provarlo:

hf download autotrust/JEV-35B-NVFP4 --local-dir JEV-35B-NVFP4
bash JEV-35B-NVFP4/serve.sh   # vLLM su :8000

Se non va: serve vLLM (build di sviluppo di settembre 2026) e una GPU da 32 GB in su. Sotto, non ci stai.

ej: il System 1 da tasca

ej è il lato opposto: 11,4 MB (un file, model.ejpack), costruito su un encoder testuale e5-small-v2. Picco di memoria residua 128 MB (35 MB in modalità low-memory); il processo Python arriva a ~558 MB, ma 204 MB sono solo import torch. Latenza 214 ms per record su una Xeon a 4 core, thread singolo.

Non è un LLM. I "maestri" si usano solo in fase di addestramento; a inferenza gira da solo, senza generare token. Dato uno stato e domande tipizzate, restituisce una distribuzione per ciascuna, calibrata (misurata, non promessa).

I suoi numeri onesti: 0,832 su intent noti (zs_massive), 0,712 sui ticket in-domain. Ma su workflow mai visti scende a 0,419. È fatto per un workflow che conosci e che misuri con i tuoi casi etichettati, non per la classificazione zero-shot di cose nuove.

In locale (CPU) si usa così:

pip install -e .   # dal repo 5ak3t/ej

import ej
model = ej.load('5ak3t/ej', revision='v0.0.1')
(probs,) = model.predict([ej.EXAMPLE_RECORD])

Se non va: è solo Python + CPU, ma inglese-only. Per italiano o francese, non è il modello giusto.

Quando un modello di decisione basta (e quando no)

Il criterio di selezione è questo: la tua domanda ha opzioni finite e un'etichetta giusta? Se sì, il modello di decisione vince su un LLM generativo su tre punti — costo, latenza, e il fatto che l'output è già la risposta.

	JEV-35B (NVFP4)	ej	LLM generativo (es. 8B)
Dimensione	25,6 GB	11,4 MB	~5 GB (Q4)
Hardware	GPU 32 GB+	CPU, 128 MB	GPU/CPU
Latenza mediana	204 ms	214 ms	30–100 ms/token
Genera testo	no	no	sì
Fortezza	classificazione su GPU	routing on-device	qualsiasi cosa aperta
Lingue	inglese	inglese	dipende dal modello

Regole pratiche:

• Routing e triage su un server con GPU (ticket → team, rischio 0–5) → JEV-35B. Classificazione forte, probabilità calibrate, una sola richiesta.
• Triage on-device, senza GPU, senza cloud (intent su un'app, gating per poi escalare) → ej. 128 MB, gira ovunque.
• La risposta è aperta, o non c'è un'etichetta giusta → LLM generativo. Il modello di decisione non esiste per questo.
• Decisioni ad alto rischio su persone (credito, assunzioni, salute) → né uno né l'altro da soli: serve revisione umana e gating di confidenza certificato sui tuoi dati.

I limiti, detti chiaro

• Inglese. Entrambi sono centrati sull'inglese. Per contenuti in italiano o francese, oggi non c'è un modello di decisione aperto equivalente.
• Workflow nuovi = numeri deboli. ej scende a 0,419 su workflow mai visti; JEV-35B è forte dove addestrato (classificazione) e debole su ragionamento aperto (GPQA 0,360).
• Calibrazione per suite. Una soglia di confidenza certificata su un workflow può fallire su un altro. Certificale sui tuoi casi etichettati.
• Niente testo. Se il compito produce parole, il modello di decisione non c'entra.

Collegamenti

• Quanto costa un token: cinque strade, i conti e il punto di pareggio — il conto completo quando un modello generativo è davvero quello che ti serve.
• Ollama vs llama.cpp: sotto il cofano — i due motori che servono un modello decisionale come JEV-35B.

In sintesi

• Un modello di decisione non scrive: risponde a una domanda tipizzata con una probabilità per opzione, in un solo passaggio, senza decodificare token.
• JEV-35B è la via GPU: 35B (3B attivi) in NVFP4, 25,6 GB di download, 23,3 GiB di memoria, su una GPU da 32 GB. Fortissimo su classificazione e routing.
• ej è la via CPU: 11,4 MB, 128 MB di memoria residua, per triage on-device. Debole su workflow nuovi.
• La regola: domanda con opzioni finite e etichetta giusta → modello di decisione. Risposta aperta → LLM generativo. Mai da solo su decisioni ad alto rischio.

Fonti

• autotrust/JEV-35B — card model su Hugging Face
• autotrust/JEV-35B-NVFP4 — variante quantizzata
• 5ak3t/ej — card model su Hugging Face
• 5ak3t/ej — repository GitHub

Articolo generato con IA