Radar · 27/07/2026 · survenu le 22/07/2026 · modèles

Cactus Hybrid: Gemma 4 apprend à dire « je ne sais pas », et le routage devient automatique

Cactus Compute a lancé Cactus Hybrid, un projet open source qui entraîne Gemma 4 E2B à reconnaître quand il se trompe. Chaque réponse porte un score de confiance entre 0 et 1, retourné comme donnée structurée, non extrait du texte généré. Au-dessus d’un seuil, le modèle local répond. En dessous, la requête passe à un modèle plus grand dans le cloud.

C’est la pièce qui manquait à l’infrastructure agentic en production. Un modèle local de 2 milliards de paramètres est rapide et privé, mais tu ne sais pas quand il se trompe. Avec le calibrage de l’incertitude intégré dans les poids, le routage devient une décision automatique basée sur un score vérifiable.

Cactus Hybrid fait correspondre Gemma 4 E2B avec Gemini 3.1 Flash-Lite sur les benchmarks courants, en ne routant que 15-55% des requêtes vers le modèle cloud. Le reste se résout localement. Les chiffres varient selon le benchmark et la quantization, mais le pattern est clair : la plupart des requêtes n’ont pas besoin du modèle frontier.

Comme nous l’expliquions à propos de l’économie des swarms de Cursor, le mix de modèles compte plus que la puissance isolée. Cactus Hybrid formalise le même principe du bas vers le haut : le petit modèle sait quand passer la main.

Pour ceux qui utilisent des modèles open en production, le calibrage de l’incertitude devient le deuxième critère de sélection après la qualité brute. Le repo est sur GitHub avec les modèles sur Hugging Face.

En détail

L’avant.

Les modèles locaux open-weight comme Gemma, Llama ou Qwen tournent sur l’appareil ou sur un serveur privé, mais ils ne peuvent pas te dire à quel point ils sont sûrs de ce qu’ils disent. Si tu demandes « quelle est la capitale de la France ? » et « quelle est la formule du ratio de Bennett ? », le modèle te donne une réponse avec le même ton assertif pour les deux. Aucun score de confiance, aucun signal d’incertitude.

Ceux qui construisent des systèmes agentic en production ont jusqu’à présent dû estimer l’incertitude par des trucs externes. Générer plusieurs réponses et les comparer, demander au modèle de s’auto-évaluer (une meta que les LLM font mal), ou utiliser un deuxième modèle comme juge. Toutes des solutions qui ajoutent de la latence et du coût sans garanties.

Comment ça marche.

Cactus Hybrid insère des sondes (probes) directement dans le checkpoint du modèle. Pendant le post-training, le modèle apprend à donner la réponse et à estimer sa fiabilité. Le score de confiance est un nombre entre 0 et 1 retourné comme donnée structurée, séparé du texte de la réponse. Il ne se parse pas à partir du texte généré : c’est un output séparé.

Le seuil de handoff est configurable. Le repo montre un exemple lisible : if confidence < 0.85: answer = ask_a_bigger_model(prompt). Au-dessus de 0.85, le modèle local répond, en dessous cela passe au cloud. Le modèle cloud au déploiement initial est Gemini 3.1 Flash-Lite.

Les chiffres.

Les benchmarks de Cactus montrent le pourcentage de handoff nécessaire pour correspondre à Flash-Lite. En FP16 : ChartQA 15-20%, MMBench 30-35%, LibriSpeech 25-30%, GigaSpeech 30-35%, MMAU 30-35%. À 4-bit, les valeurs augmentent de 10-15 points. MMLU-Pro nécessite 45-55% de handoff en FP16, presque le double des autres benchmarks.

La quantization augmente le pourcentage de handoff nécessaire, mais même les modèles les plus compressés résolvent plus de la moitié des requêtes localement. Le trade-off est lisible : tu économises la mémoire sur l’appareil, tu paies avec plus d’appels au cloud.

Limites.

Le projet est jeune. Trois forks et 189 stars sur GitHub, un seul modèle au déploiement initial. Les benchmarks sont fournis par l’équipe Cactus elle-même, pas par une évaluation indépendante.

La confiance calibrée est un problème connu et difficile. Un modèle peut être « confiant » et se tromper, ou être incertain et avoir raison. Le calibrage véritable se mesure avec l’ECE (Expected Calibration Error) sur des ensembles de validation, et le repo ne rapporte pas cette donnée.

Ceux qui veulent l’utiliser en production devraient construire leur propre banc de test : un ensemble de questions avec réponse connue dans ton domaine, comparer le score de confiance avec la justesse réelle, et vérifier que le seuil choisi sépare vraiment les bonnes réponses des mauvaises. Le playbook pour comparer deux modèles est un point de départ : même tâche, mêmes cas de test, tableau des résultats.

Tapez pour chercher dans cours, playbooks, skills, papers…