Modèles de décision en local : JEV-35B et le System 1 à 3 Md actifs

Un seul passage, aucune génération

Il y a une tâche que les grands LLM accomplissent, et dont vous n'avez pas besoin qu'ils la fassent ainsi : décider. Classifier un ticket, choisir à quelle équipe l'envoyer, attribuer un score de risque, répondre oui ou non. Pour ça, il ne vous faut pas un modèle qui écrit des phrases : il vous en faut un qui répond à une question précise avec une probabilité par option, en un seul passage, sans décoder un seul jeton.

C'est un modèle de décision. Il ne génère pas de texte : il lit l'état, lit la question, et renvoie une distribution de probabilités sur les options. C'est le System 1 — rapide, intuitif, calibré — face au System 2 du LLM qui raisonne, écrit et prend son temps.

L'idée n'est pas nouvelle, mais deux sorties d'octobre la rendent concrète en local. JEV-35B d'Autotrust est un MoE de 35 Md de paramètres (3 Md actifs par jeton) qui tourne quantisé en NVFP4 sur une GPU de 32 Go. ej est l'inverse : 11,4 Mo, pic de mémoire résidente de 128 Mo, tourne sur CPU. Deux extrêmes, même catégorie : des modèles qui décident, pas qui écrivent.

Ce qu'est un modèle de décision (et ce qu'il n'est pas)

Un LLM génératif prend un prompt et produit une séquence de jetons, un par un. Un modèle de décision ne fait qu'une chose : donné un état et des questions typées, il renvoie une probabilité par option.

Les questions typées sont de trois types :

Type	Entrée	Sortie
choice	instruction + liste d'options	une probabilité par option
noul (oui/non)	une affirmation	P(false), P(true)
score	instruction + niveaux ordonnés	une distribution sur les niveaux

L'avantage est double. D'abord, vitesse et coût : pas de boucle de génération, un seul forward pass. JEV-35B répond en 204 ms de médiane sur une seule GPU ; ej en 214 ms sur une CPU à 4 cœurs. Ensuite, aucune mise en forme à perdre : la sortie est déjà la réponse (l'option la plus probable), pas un texte dont il faut l'extraire.

Ce n'est pas un chatbot. JEV-35B ne tient pas de conversation, ne génère pas de texte libre. Si vous devez écrire, ce modèle n'est pas le bon.

JEV-35B : le décisionnaire de 32 Go

JEV-35B est un fine-tune de Qwen3.5-35B-A3B (MoE, 35 Md au total, ~3 Md actifs par jeton), Apache-2.0. Un decision head de 264 slots donne un logit par slot ; les slots actifs de la question sont soft-maxés avec une température par type.

Le point qui change le matériel, c'est la quantisation. Les chiffres du fournisseur :

Version	Téléchargement	Mémoire GPU (poids)	Decision Index 0.3
JEV-35B bf16	72 Go	66,5 Gio	59,73
JEV-35B-NVFP4	25,6 Go	23,3 Gio	59,18

Le passage en NVFP4 fait passer les poids de 66,5 à 23,3 Gio : ça tient sur une GPU de 32 Go ou plus, et les réponses restent identiques au bf16 dans 96,6 % des cas. Le calcul est simple : 35 Md de paramètres à 16 bits pèsent ~72 Go ; à 4 bits (NVFP4) on descend à un quart de bits par poids, et avec l'overhead on reste sous les 25,6 Go de téléchargement.

Où il excelle, c'est là où il devrait : classification et routage. BANKING77 à 0,921, CLINC150+OOS à 0,943, la reconnaissance d'intention en général. Son domaine fort est Retrieval & Classification (skill 0,710) ; le faible est Knowledge & Reasoning (GPQA 0,360). Pour ça, il faut un vrai LLM.

Pour l'essayer :

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

Si ça ne marche pas : il faut vLLM (build de développement de septembre 2026) et une GPU de 32 Go ou plus. En dessous, ça ne rentre pas.

ej : le System 1 de poche

ej est l'autre bout : 11,4 Mo (un fichier, model.ejpack), construit sur un encodeur textuel e5-small-v2. Pic de mémoire résidente 128 Mo (35 Mo en mode low-memory) ; le processus Python monte à ~558 Mo, mais 204 Mo ne sont que import torch. Latence 214 ms par enregistrement sur une Xeon à 4 cœurs, thread unique.

Ce n'est pas un LLM. Les « enseignants » ne servent qu'au moment de l'entraînement ; à l'inférence il tourne seul, sans générer de jetons. Donné un état et des questions typées, il renvoie une distribution par question, calibrée (mesurée, pas promise).

Ses chiffres honnêtes : 0,832 sur des intentions connues (zs_massive), 0,712 sur les tickets du domaine. Mais sur des workflows jamais vus, il descend à 0,419. Il est fait pour un workflow que vous connaissez et que vous mesurez sur vos propres cas étiquetés, pas pour la classification zéro-jeu de choses nouvelles.

En local (CPU) :

pip install -e .   # depuis le dépôt 5ak3t/ej

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

Si ça ne marche pas : c'est du Python + CPU, mais anglais uniquement. Pour le français, ce n'est pas le modèle adapté.

Quand un modèle de décision suffit (et quand non)

Le critère de sélection est celui-ci : votre question a-t-elle des options finies et une étiquette juste ? Si oui, le modèle de décision bat le LLM génératif sur trois points — coût, latence, et le fait que la sortie est déjà la réponse.

	JEV-35B (NVFP4)	ej	LLM génératif (ex. 8B)
Taille	25,6 Go	11,4 Mo	~5 Go (Q4)
Matériel	GPU 32 Go+	CPU, 128 Mo	GPU/CPU
Latence médiane	204 ms	214 ms	30–100 ms/jeton
Génère du texte	non	non	oui
Point fort	classification sur GPU	routage on-device	n'importe quelle tâche ouverte
Langues	anglais	anglais	dépend du modèle

Règles pratiques :

• Routage et tri sur un serveur avec GPU (ticket → équipe, risque 0–5) → JEV-35B. Classification forte, probabilités calibrées, une seule requête.
• Tri on-device, sans GPU, sans cloud (intention dans une app, gating avant escalade) → ej. 128 Mo, tourne partout.
• La réponse est ouverte, ou il n'y a pas d'étiquette juste → LLM génératif. Le modèle de décision n'existe pas pour ça.
• Décisions à fort risque sur des personnes (crédit, embauche, santé) → ni l'un ni l'autre seuls : il faut une revue humaine et un gating de confiance certifié sur vos données.

Les limites, dites clairement

• Anglais. Les deux sont centrés sur l'anglais. Pour du contenu en français, il n'y a pas aujourd'hui de modèle de décision ouvert équivalent.
• Nouveaux workflows = scores faibles. ej descend à 0,419 sur des workflows jamais vus ; JEV-35B est fort là où il est entraîné (classification) et faible sur le raisonnement ouvert (GPQA 0,360).
• Calibration par suite. Un seuil de confiance certifié sur un workflow peut échouer sur un autre. Certifiez-le sur vos propres cas étiquetés.
• Pas de texte. Si la tâche produit des mots, le modèle de décision n'est pas le bon.

Liens

• Combien coûte un jeton : cinq routes, les calculs et le point de bascule — le calcul complet quand un modèle génératif est vraiment ce qu'il vous faut.
• Ollama vs llama.cpp : sous le capot — les deux moteurs qui servent un modèle décisionnel comme JEV-35B.

En synthèse

• Un modèle de décision n'écrit pas : il répond à une question typée avec une probabilité par option, en un seul passage, sans décoder de jetons.
• JEV-35B est la voie GPU : 35 Md (3 Md actifs) en NVFP4, 25,6 Go de téléchargement, 23,3 Gio de mémoire, sur une GPU de 32 Go. Très fort en classification et routage.
• ej est la voie CPU : 11,4 Mo, 128 Mo de mémoire résidente, pour le tri on-device. Faible sur les nouveaux workflows.
• La règle : question aux options finies avec étiquette juste → modèle de décision. Réponse ouverte → LLM génératif. Jamais seul sur des décisions à fort risque.

Sources

• autotrust/JEV-35B — carte du modèle sur Hugging Face
• autotrust/JEV-35B-NVFP4 — variante quantifiée
• 5ak3t/ej — carte du modèle sur Hugging Face
• 5ak3t/ej — dépôt GitHub

Article généré par IA