Fastino Labs 周三发布 GLiGuard——一个 3 亿参数的开源安全审核模型,Apache 2.0 在 Hugging Face 上发布,专门为修复 decoder 为底的 guardrails 给生产 LLM 系统带来的延迟税而构建。架构选择是承重决策:LlamaGuard4(12B)、WildGuard(7B)、ShieldGemma(27B)、NemoGuard(8B)所采用的 decoder-only 设计——它们都是自回归地、一个 token 一个 token 地生成安全裁决——GLiGuard 反其道而行,以 encoder 模型把安全审核重构为一个多标签分类问题。它把输入文本与任务标签一起编码,在单次 forward pass 里同时给每个候选标签打分。四个安全任务并发评估:prompt/response 安全分类;jailbreak 策略检测(11 类策略,包括 prompt injection、roleplay 绕过、指令覆盖、社工);harm category 检测(14 类,涉及暴力、性内容、仇恨、PII 暴露、misinformation、儿童安全、版权);refusal detection(合规 vs 拒绝,单独追踪以衡量 over-refusal)。
benchmark 数字讲了一个干净的故事。九个标准安全 benchmark 上,以 macro-averaged F1 为度量:GLiGuard 在 prompt 分类上拿 87.7,比最佳模型(PolyGuard-Qwen 89.4)落后 1.7 分;在 response 分类上拿 82.7,仅次于 Qwen3Guard-8B 的 84.1。尽管体量小 23 到 90 倍,它在 LlamaGuard4-12B、ShieldGemma-27B、NemoGuard-8B 之上。在 NVIDIA 单卡 A100 上的吞吐与延迟基准:GLiGuard 吞吐最高 16.2×(batch=4 时 133 vs 8.2 samples/s),延迟最高低 16.6×(seq len=64 时 26 ms vs 426 ms)。对生产 builder,26ms vs 426ms 这一差距是真正改变部署经济性的部分——在用户每一回合、模型每一条回复上都要跑的 guardrail,负担不起在用户与模型之间多压几百毫秒。架构层面,GLiGuard 由 Fastino 自研的多任务分类底座 GLiNER2-base-v1 全量 fine-tune 20 个 epoch,AdamW 优化器。训练数据混合了 WildGuardTrain(8.7 万条人工标注)用于安全与拒绝标签,以及 GPT-4.1 生成的 harm category 与 jailbreak strategy 标签,再用合成数据补充细颗粒度边界样本。
这里的生态读法是:"小 encoder 做分类、大 decoder 做生成"是一种早就藏在明面上的结构性模式。安全审核本质上是分类问题——这条 prompt 是否匹配某种 jailbreak 策略、这条 response 是否含 harm——decoder 模型之所以早期在 guardrail 市场胜出,是因为它们灵活。但灵活的代价正是吞吐,而且这种代价恰恰落在你最负担不起的那个表面:用户与模型之间、每一次请求上。GLiGuard 16× 的吞吐优势,是这个领域一直在用错架构、为审核多花钱的实证。在生产里跑 LLM 系统的 builder 该认真看这件事——节省会复利累加。在 7B 级模型上耗 426ms 的 guardrail 难以规模部署;26ms 的 300M encoder 能塞进与模型推理本身一起的延迟预算里。
对 builder:从 Hugging Face 克隆 GLiGuard 权重,先在你自己的真实流量混合上 benchmark 一遍再决定换不换。三条要保留的诚实 caveat:(1) GLiGuard 在 prompt 分类上比最佳低 1.7 F1,在 response 分类上比最佳低 1.4 F1——如果你的应用足够高风险,以致小的精度差也重要(受监管的医疗建议、儿童安全、法律合规),延迟收益未必抵得上精度损失;(2) encoder 模型在适应新安全策略上不如 decoder 灵活——当 harm 分类法变化时,你得重训而不是改 prompt;(3) "四任务一次性"的设计很优雅,但意味着一次训练就把你的安全分类法编进去了——加类别要重训。encoder-classification 这个模式本身是可推广的;预期未来一年里会陆续看到类似的内容审核、意图分类、路由模型出来。Pioneer 上托管了 benchmark 跑的那条推理路径,你也可以先在那上测,再决定要不要拉权重。