El GLiGuard 300M de Fastino iguala guardrails 27B con 16× el throughput

Fastino Labs lanzó GLiGuard el miércoles — un modelo open-source de moderación de seguridad de 300M parámetros, con licencia Apache 2.0 en Hugging Face, construido explícitamente para arreglar el impuesto de latencia que los guardrails basados en decoder imponen sobre sistemas LLM en producción. La decisión de arquitectura es la decisión cargante: en lugar del diseño decoder-only usado por LlamaGuard4 (12B), WildGuard (7B), ShieldGemma (27B) y NemoGuard (8B) — los cuales generan veredictos de seguridad autorregresivamente, un token a la vez — GLiGuard es un modelo encoder que reformula la moderación de seguridad como un problema de clasificación multi-etiqueta. Codifica el texto de entrada junto con las etiquetas de tarea en un solo forward pass, puntuando cada etiqueta candidata simultáneamente. Cuatro tareas de seguridad se evalúan concurrentemente: clasificación de seguridad prompt/response, detección de estrategia de jailbreak a través de 11 estrategias (incluyendo inyección de prompt, bypass por roleplay, override de instrucción, ingeniería social), detección de categoría de daño a través de 14 tipos (violencia, contenido sexual, odio, exposición de PII, desinformación, seguridad infantil, copyright), y detección de rechazo (cumplimiento vs rechazo, rastreado separadamente para medir sobre-rechazo).

Los números de benchmark cuentan una historia limpia. Sobre nueve benchmarks de seguridad estándar usando F1 macro-promediado: GLiGuard saca 87,7 en clasificación de prompt — 1,7 puntos detrás del mejor modelo (PolyGuard-Qwen a 89,4) — y 82,7 en clasificación de response, segundo solo detrás de Qwen3Guard-8B a 84,1. Supera a LlamaGuard4-12B, ShieldGemma-27B y NemoGuard-8B a pesar de ser 23 a 90× más pequeño. En throughput y latencia, medidos en un solo NVIDIA A100: GLiGuard alcanza hasta 16,2× más throughput (133 vs 8,2 muestras/s a batch size 4) y 16,6× menos latencia (26 ms vs 426 ms a longitud de secuencia 64). Para builders en producción, la brecha 26ms-vs-426ms es la parte que cambia materialmente la economía de despliegue — un guardrail que corre en cada turno de usuario y en cada respuesta del modelo no puede permitirse sentarse entre el usuario y el modelo agregando cientos de milisegundos. La arquitectura fue entrenada como full fine-tuning de GLiNER2-base-v1, la base multi-tarea de clasificación propia de Fastino, durante 20 epochs con AdamW. Los datos de entrenamiento son una mezcla de WildGuardTrain (87K ejemplos anotados humanos para seguridad/rechazo) y etiquetas generadas por GPT-4.1 para clasificación de categoría de daño y estrategia de jailbreak, suplementadas con casos sintéticos para distinciones de grano fino.

La lectura ecosistémica acá es que "encoder pequeño para clasificación, decoder grande para generación" es un patrón estructural que ha estado escondido a plena vista. La moderación de seguridad es fundamentalmente un problema de clasificación — ¿este prompt coincide con una estrategia de jailbreak, esta respuesta contiene daño — y los modelos decoder ganaron el mercado early de guardrails porque eran flexibles. Pero la flexibilidad te cuesta throughput exactamente en la superficie donde menos puedes permitírtelo: entre el usuario y el modelo, en cada solicitud. La ventaja 16× de throughput de GLiGuard es la demostración empírica de que el campo ha estado pagando de más por moderación al usar la arquitectura equivocada. Los builders corriendo sistemas LLM en producción deberían mirar esto seriamente — los ahorros componen. Un guardrail que toma 426ms en un modelo clase 7B es difícil de desplegar a escala; un encoder 300M a 26ms encaja en el presupuesto de latencia junto a la inferencia del modelo en sí.

Para builders: clona los pesos de GLiGuard de Hugging Face y benchmárcalo contra tu guardrail actual sobre tu mezcla de tráfico real antes de desplegar. Tres caveats honestos a aplicar: (1) GLiGuard está a 1,7 F1 detrás del mejor clasificador de prompt y 1,4 F1 detrás del mejor clasificador de response — si tu aplicación tiene suficiente en juego como para que pequeñas brechas de precisión importen (consejo médico regulado, seguridad infantil, cumplimiento legal), la victoria en latencia puede no justificar la pérdida en precisión; (2) los modelos encoder son menos flexibles que los modelos decoder para adaptarse a nuevas políticas de seguridad — cuando tu taxonomía de daño cambia tienes que reentrenar en lugar de reescribir un prompt; (3) el diseño cuatro-tareas-en-un-pass es elegante pero significa que un solo training run codifica tu taxonomía de seguridad — agregar categorías requiere reentrenamiento. El patrón encoder-clasificación en sí es generalizable; espera ver modelos similares para moderación de contenido, clasificación de intención y enrutamiento aparecer en el próximo año. Pioneer hospeda el camino de inferencia sobre el cual se corrieron los benchmarks si quieres probar antes de bajar los pesos tú mismo.