Papers
Topics
Authors
Recent
Search
2000 character limit reached

GLiNER Guard: Unified Encoder Family for Production LLM Safety and Privacy

Published 6 May 2026 in cs.CR | (2605.05277v1)

Abstract: Production LLM systems require both safety moderation and PII detection under strict latency and cost constraints. This creates a trade-off: autoregressive moderators are accurate but expensive, while lightweight encoders are faster but less capable. We present GLiNER Guard (GLiGuard), a unified encoder that performs safety classification and PII detection in a single forward pass, simplifying safety pipelines. We introduce three variants: compact uni- and bi-encoders (145-147M) for high-throughput serving, and GLiGuard Omni (209M) for stronger moderation quality. Under dynamic batching on a single A100, the compact model reaches 193 requests/sec with P99 latency below 1s, achieving 1.6x higher throughput than GLiNER2. Omni remains competitive with much larger moderators on public safety benchmarks. We also release PII-Bench, a span-level benchmark for evaluating PII detection in end-to-end pipelines. Overall, encoder-based guardrails offer a practical low-cost alternative for always-on moderation. Models and benchmarks are released on HuggingFace.

Summary

  • The paper introduces three schema-driven encoder models that combine safety moderation, attack detection, and PII extraction in one forward pass, with 467,273 multi-task training examples.
  • GLiNER Guard achieves competitive prompt-level safety performance, including up to 99.7 F1 on StrongReject, while the compact uni-encoder reaches 193.6 requests per second with 900 ms P99 latency on an A100.
  • The results support a tiered deployment strategy: fast encoders handle high-volume screening, while larger moderators review uncertain cases, although multilingual, response-level, and real-world PII performance remains limited.

GLiNER Guard (GLiGuard) is a family of schema-driven encoder models that unify safety moderation and PII detection in a single forward pass, targeting always-on first-stage moderation in production LLM systems. The work addresses a concrete deployment trade-off: autoregressive moderators such as LlamaGuard, WildGuard, and ShieldGemma offer strong moderation quality but incur autoregressive-decoding costs that make always-on screening expensive, while existing encoder guardrails (PromptGuard 2, DeBERTa-based prompt-injection classifiers) are fast but narrow in scope. GLiGuard builds on GLiNER2's schema-conditioned encoder design and demonstrates that one compact model can replace multiple first-stage components under realistic serving constraints.

Architecture and variants

The family comprises three variants. The compact uni-encoder (147M) uses mmBERT-small as backbone and follows standard GLiNER2 inference, concatenating input text and schema labels with full bidirectional attention; it provides the richest text–label interaction but re-encodes the schema per request. The shared-weight bi-encoder (145M) encodes text and labels separately into a shared embedding space, extending prior GLiNER bi-encoder work—which used two towers for single-task NER—to the multi-task setting with a single shared backbone. Because label representations are input-independent, they can be precomputed and cached, which is attractive when policy schemas are fixed, tenant-specific, or frequently updated. GLiGuard Omni (209M) is initialized from GLiNER2 Multi and fine-tuned on the same safety supervision, deliberately preserving general-domain transfer at the cost of some throughput.

Training uses 467,273 multi-task examples with up to six supervision signals per sample (span extraction, safety classification, adversarial attack detection, harmful-content categorization, intent, and tone). Span supervision covers 108,702 examples over 32 entity types; the mixture is classification-dominated due to the scarcity of high-quality PII annotations. The authors state that no evaluation benchmark data was included in training.

Safety moderation quality and efficiency trade-off

On Aegis 2.0, StrongReject, and PolyGuard (F1 on the unsafe class), GLiGuard Omni achieves the best encoder result at 76.9 F1 average, a 10.3-point improvement over GLiNER2 Multi and 12.0 over GLiClass. On prompt-level Aegis 2.0, the compact variants reach 80.2 F1—within 1.3 points of WildGuard (81.5) while outperforming LlamaGuard 3 (77.2) and Llama 4 Guard (71.5). On StrongReject the uni-encoder scores 98.5 and Omni 99.7, near the top of the comparison set. All variants lead the full comparison—including 7B–20B autoregressive moderators—on the parameter-normalized metric F1_avg/log₂P, with Omni at 2.78.

Two caveats temper these results. The largest quality gaps persist on response-level and multilingual moderation, where GPT-OSS-SafeGuard (83.3) and YuFeng-XGuard (86.4) remain well ahead; the authors attribute this to compact context windows and non-autoregressive inference, and address it via a cascade rather than claiming parity. Additionally, prior narrow encoder guardrails score very poorly in this evaluation (PromptGuard 2 at 35.7 average), so the comparison against them mainly establishes breadth rather than beating a strong encoder peer.

Unified PII detection

A central claim is that moderation and PII handling can share one deployed model. Evaluation on PII-Bench—a new synthetic, human-verified Russian-language benchmark with 1,810 examples across 13 entity types and 9 domains—and the SPY benchmark reveals an instructive split between raw extraction and end-to-end pipeline behavior. Raw model-only extraction favors Omni and GLiNER2 Multi (e.g., 83.1 and 85.2 F1 on Name), reflecting broader NER pretraining. But after label mapping and span consolidation, the compact variants win: the uni-encoder reaches 75.7 F1 on Name (15.1 points above GLiNER2 Multi's pipeline result) and the bi-encoder 68.7 on Address versus 52.1. Raw Address scores are near zero for all models because models predict granular components (street, city, unit) that the pipeline must merge into a single consolidated span; the paper is explicit that these end-to-end numbers reflect hybrid model-plus-rules performance, not pure model capability, since structured entities (emails, card numbers, tax IDs) are handled by deterministic detectors identical across backbones. On SPY (recall only, since SPY's selective annotation precludes fair precision comparison), GLiGuard is strongest on structured entities while a SPY-fine-tuned DeBERTa-v3 dominates context-heavy labels such as names and usernames—an expected outcome given the zero-shot setting.

Generalization and serving efficiency

The specialization trade-off is stated plainly. The compact uni-/bi-encoders collapse outside their safety domain: 0.62/0.01 accuracy on SST-2 and Banking77 respectively, and 13.6–14.7 average strict F1 on CrossNER, confirming deliberate specialization rather than broad transfer. Omni partially retains GLiNER2's zero-shot ability (0.74 on SST-2, 0.59 on Banking77, 51.4 CrossNER F1), though below the base model (0.86/0.70/59.0), quantifying the cost of safety fine-tuning. Omni is therefore the appropriate variant when custom policy schemas or adjacent tasks are required.

Serving results are the strongest practical evidence. Under dynamic batching on a single A100 80 GB with ONNX TensorRT, the uni-encoder sustains 193.6 requests/second with 900 ms P99 latency and zero errors—58% higher throughput than GLiNER2 Multi under the same runtime, with 36% lower P99 latency. Notably, GLiNER2 under PyTorch exhibits a 12.95% error rate under load while GLiGuard maintains zero errors across all three backends, indicating improved runtime robustness independent of raw speed. At batch size 1, the bi-encoder achieves 0.019 s/request versus 0.744 for WildGuard.

Cascading

The paper frames the residual quality gap as a routing problem. Pairing the uni-encoder with YuFeng-XGuard 8B as a second stage on PolyGuard yields smooth quality–cost interpolation: at confidence threshold τ=0.95, escalating 43% of prompts and 35% of responses reaches 77.4/65.0 F1 (prompt/response), and at τ=0.99 (62%/58% calls) reaches 81.1/70.2, approaching XGuard standalone (85.8/79.2) while routing only part of the traffic to the LLM tier. Omni standalone (71.7/58.9) is a useful reference point but the cascade dominates it at moderate escalation rates.

Limitations

The authors concede several constraints. Response-level and multilingual moderation remain below the strongest large autoregressive baselines, and the compact context window limits very long inputs. PII-Bench is synthetic and Russian-only, so multilingual and real-world privacy evaluation is unresolved; moreover, because several entity categories rely on deterministic rules, reported PII results should be read as pipeline-level rather than model-level capability. Encoder-versus-LLM comparisons are complicated by differing inference paradigms and serving assumptions, and serving experiments are limited to A100-class GPUs, leaving CPU, edge, and low-memory deployments untested. Open questions include calibration analysis, cost-normalized comparisons under matched deployment constraints, longer-context backbones, and improved cascade routing.

Conclusion

GLiNER Guard demonstrates that a schema-driven encoder family can occupy a practical middle tier between narrow classifiers and large autoregressive moderators: competitive prompt-level moderation, useful span-level PII detection in one forward pass, leading quality-per-parameter efficiency, and 193.6 RPS with sub-second P99 latency on a single A100. The three variants serve complementary roles—uni-encoder for fixed-schema throughput, bi-encoder for cacheable large label spaces, Omni for transfer and custom schemas—and the cascade results support tiered architectures in which the encoder absorbs high-volume traffic while LLM moderators handle uncertain cases. The main unresolved issues are response-level and multilingual moderation quality, and validation of PII capability beyond synthetic Russian-language data.

Paper to Video (Beta)

No one has generated a video about this paper yet.

Whiteboard

No one has generated a whiteboard explanation for this paper yet.

Open Problems

We haven't generated a list of open problems mentioned in this paper yet.