Fastino Labs a publié GLiGuard mercredi — un modèle open-source de modération de sécurité à 300M de paramètres, sous licence Apache 2.0 sur Hugging Face, bâti explicitement pour corriger la taxe de latence que les garde-fous basés sur décodeurs imposent aux systèmes LLM en production. Le choix d'architecture est la décision porteuse : au lieu du design decoder-only utilisé par LlamaGuard4 (12B), WildGuard (7B), ShieldGemma (27B) et NemoGuard (8B) — qui génèrent tous des verdicts de sécurité de manière autorégressive, un token à la fois — GLiGuard est un modèle encodeur qui reformule la modération de sécurité comme un problème de classification multi-label. Il encode le texte d'entrée aux côtés des labels de tâche dans un seul forward pass, scorant simultanément chaque label candidat. Quatre tâches de sécurité sont évaluées concurremment : classification de sécurité prompt/réponse, détection de stratégies de jailbreak sur 11 stratégies (incluant prompt injection, bypass roleplay, override d'instruction, ingénierie sociale), détection de catégorie de préjudice sur 14 types (violence, contenu sexuel, haine, exposition PII, désinformation, sécurité enfant, copyright), et détection de refus (compliance vs refus, suivi séparément pour mesurer le sur-refus).

Les chiffres de benchmark racontent une histoire propre. Sur neuf benchmarks de sécurité standards utilisant F1 macro-moyenné : GLiGuard score 87,7 sur la classification de prompt — 1,7 point derrière le meilleur modèle (PolyGuard-Qwen à 89,4) — et 82,7 sur la classification de réponse, second seulement derrière Qwen3Guard-8B à 84,1. Il surpasse LlamaGuard4-12B, ShieldGemma-27B et NemoGuard-8B malgré le fait d'être 23 à 90× plus petit. Sur le throughput et la latence, mesurés sur un seul A100 de NVIDIA : GLiGuard atteint jusqu'à 16,2× plus de throughput (133 vs 8,2 échantillons/s à batch size 4) et 16,6× moins de latence (26 ms vs 426 ms à séquence length 64). Pour les builders en production, l'écart 26ms-vs-426ms est la partie qui change matériellement l'économie de déploiement — un garde-fou qui tourne à chaque tour utilisateur et à chaque réponse du modèle ne peut pas se permettre de s'asseoir entre l'utilisateur et le modèle en ajoutant des centaines de millisecondes. L'architecture a été entraînée en full fine-tuning de GLiNER2-base-v1, la base multi-tâche de classification de Fastino, pendant 20 epochs avec AdamW. Les données d'entraînement sont un mélange de WildGuardTrain (87K exemples annotés humains pour sécurité/refus) et labels générés par GPT-4.1 pour la classification de catégorie de préjudice et de stratégie de jailbreak, complétés par des cas synthétiques pour les distinctions fines.

La lecture écosystémique ici, c'est que « petit encodeur pour la classification, grand décodeur pour la génération » est un pattern structurel qui se cachait à la vue de tous. La modération de sécurité est fondamentalement un problème de classification — est-ce que ce prompt matche une stratégie de jailbreak, est-ce que cette réponse contient un préjudice — et les modèles décodeurs ont gagné le marché early des garde-fous parce qu'ils étaient flexibles. Mais la flexibilité te coûte en throughput exactement à la surface où tu peux le moins te le permettre : entre l'utilisateur et le modèle, à chaque requête. L'avantage 16× de throughput de GLiGuard est la démonstration empirique que le champ a sur-payé pour la modération en utilisant la mauvaise architecture. Les builders qui tournent des systèmes LLM en production devraient regarder ça sérieusement — les économies composent. Un garde-fou qui prend 426ms sur un modèle classe 7B est dur à déployer à l'échelle ; un encodeur 300M à 26ms s'insère dans le budget de latence aux côtés de l'inférence du modèle elle-même.

Pour les builders : clone les poids GLiGuard depuis Hugging Face et benchmark-le contre ton garde-fou actuel sur ton trafic réel avant de déployer. Trois caveats honnêtes à appliquer : (1) GLiGuard est à 1,7 F1 du meilleur classifieur de prompt et 1,4 F1 du meilleur classifieur de réponse — si ton application est suffisamment à enjeux pour que de petits écarts de précision comptent (conseil médical régulé, sécurité enfant, conformité légale), le gain de latence peut ne pas justifier la perte en précision ; (2) les modèles encodeurs sont moins flexibles que les modèles décodeurs pour s'adapter à de nouvelles politiques de sécurité — quand ta taxonomie de préjudice change, tu dois retrain plutôt que réécrire un prompt ; (3) le design quatre-tâches-en-un-pass est élégant mais signifie qu'un seul training run encode ta taxonomie de sécurité — ajouter des catégories demande retrain. Le pattern encodeur-classification lui-même est généralisable ; attends-toi à voir des modèles similaires pour modération de contenu, classification d'intention et routing apparaître au cours de l'année prochaine. Pioneer héberge le chemin d'inférence sur lequel les benchmarks ont été lancés si tu veux tester avant de tirer les poids toi-même.