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 跑的那條推論路徑,你也可以先在那上測,再決定要不要拉權重。