gliner-pam-pii-large

gliner-pam-pii-large — PAM/Jira PII & secret redaction, 50 labels

urchade/gliner_large-v2.1 fine-tuned to redact PII and secrets in Privileged Access Management support text: Jira tickets, log excerpts, config snippets, CLI transcripts, audit events. Turkish-weighted, bilingual (TR/EN).

Span-mode architecture, so unlike DeBERTa token-level GLiNER variants this one exports to ONNX with bit-level fidelity.

Results

3,000 held-out cases / 7,105 gold spans, threshold 0.4, type-aware overlap matching:

Of 50 labels: 16 reach F1 >= 0.95, 30 reach >= 0.90, only 3 fall below 0.70.

Numeric-identifier types are the weak spot (ACCOUNT_NUMBER, SGK_NO, TCKN) — an English-vocabulary tokenizer fragments Turkish digit-strings poorly.

---

Fastest inference — read this first

Everything below is measured on this checkpoint, not estimated. Hardware: RTX 4090 / Intel Xeon Gold 6330 (AVX512-VNNI, 16 threads) / Apple M4 Pro.

1. The single biggest lever is the number of labels you pass

GLiNER prepends every label description to the input sequence, so cost scales with label count, not just text length. This is free accuracy-wise:

Filter to the tiers you actually need. label_map.json in this repo groups the 50 labels; a two-pass design (secrets first, identity/infra only if needed) keeps you near 385 ms with no loss.

2. Device choice

On CPU, 8-16 threads is the sweet spot — more threads made it slower on both an M4 Pro (14 threads worse than 8) and a 48-core EPYC. Apple M4 Pro CPU beat a server EPYC 7K62 by 35%; this workload is bound by memory bandwidth and single-core speed, not core count.

3. ONNX: use it for portability, not speed

onnx/model.onnx (fp32) is numerically exact — verified end-to-end through the full decode pipeline: identical F1, precision, recall, and even identical prediction count (897 of 897) versus PyTorch. Tensor-level max|Δ| = 0.0004.

But it is 5.2x slower than PyTorch on CPU (4070 ms vs 762 ms at 50 labels). Root cause confirmed from onnxruntime source: its transformer optimizer's MODEL_TYPES list has no deberta entry, so the graph gets zero attention fusion and DeBERTa's relative-position machinery executes as a long unfused Gather/Einsum/Where chain.

Export it if you need C#/Java/Go or an ORT serving stack. Do not export it for speed.

Six ONNX inputs: input_ids, attention_mask, words_mask, text_lengths, span_idx, span_mask -> logits.

4. Do not quantize this model. No int8 files are shipped.

Seven configurations were measured. All seven destroy the model. The failure is always the same: logit scale collapses so the maximum logit goes negative, and nothing passes a sigmoid threshold — the model silently returns empty results rather than erroring.

Lowering the threshold does not rescue it: at 0.05 you get scattered predictions with F1 0.010-0.014.

Why, and when int8 does work

This is not an intrinsic DeBERTa property. The discriminating evidence is GLiNER issue #270: with the same script, gliner_small-v2.1 (deberta-v3-small) quantizes cleanly (0.98 -> 0.98), while gliner_multi-v2.1 (mdeberta-v3-base) collapses (0.99 -> 0.21). Same disentangled attention, different scale.

The mechanism is activation outliers in the post-LayerNorm residual stream, whose magnitude grows with model scale. Per-tensor activation quantization lets one outlier channel set the scale, leaving everything else 2-3 usable levels. Per-channel weight quantization cannot fix it because the damage is activation-side.

Note also that issue #218 reports this exact symptom and is open with no maintainer response, and that knowledgator/gliner-pii-large-v1.0's own published onnx/model_quint8.onnx shows max logit -1.56 — i.e. published quantized GLiNER artifacts are broken too. Shipping a quantized file is not evidence it works.

If you need int8, start from a -small backbone, which is the only size with published evidence of surviving quantization.

5. What we measured and rejected

ModernBERT's advantage comes from GPU unpadding + FlashAttention, neither of which applies on CPU; and its bi-encoder re-encodes labels per call in the predict_entities path, so you pay for two encoders instead of one. Its tokenizer is also worse for Turkish (18 tokens vs 14 for DeBERTa on the same sentence).

Untested but plausible for CPU: Intel Neural Compressor's accuracy-aware tuning, which took deberta-v3-base to int8 at +0.17% accuracy and 1.26x throughput on MRPC — but note MRPC is argmax-based and therefore insensitive to the exact logit-scale collapse that breaks this model.

---

Usage

from gliner import GLiNER
model = GLiNER.from_pretrained("omeryentur/gliner-pam-pii-large")

labels = ["password", "login account name or username",
          "private internal ip address", "database connection string with credentials",
          "password vault safe or object path"]

text = ("Environment : 10.20.42.121\nuser : admin@host\npasswd : kr10ipsla\n\n"
        "pamuser / kr10ipsla")
for e in model.predict_entities(text, labels, threshold=0.4):
    print(e["label"], "->", e["text"], round(e["score"], 2))

Labels are natural-language descriptions (GLiNER is open-vocabulary). All 50 strings used in training are in label_map.json — use them verbatim for best results. Threshold 0.4 is balanced; 0.3 raises recall for masking scenarios.

The max_width fix — essential if you retrain

Span-mode GLiNER only predicts spans up to max_width tokens. The base config is 12, which makes 12.6% of this dataset's entities structurally unlearnable — concentrated in exactly the PAM-critical labels (LDAP_DN 100% over, CONNECTION_STRING 98%, WEBHOOK_URL 88%, VAULT_PATH 57%).

SpanMarkerV0's weights are width-independent (no width embedding table), so max_width can be raised without breaking the pretrained checkpoint. This model uses max_width=48 (99.87% entity coverage). The result:

Cost: span candidates scale with seq_len x max_width, so batch size must drop (bs 16 with gradient checkpointing fits in 24 GB; without it, it OOMs).

Training

Trained with a manual training loop, not gliner.training.Trainer: on gliner 0.2.x + transformers 5.x that wrapper silently reports loss=0 and never updates weights. The loop asserts grad_norm > 0 in the first steps and verifies the weight delta at the end.

Limitations

• Effective context is 512 tokens, shared between label descriptions and text. With 50 labels only ~310-360 tokens remain for the text.
• Training data is ~87% synthetic (LLM-written templates filled by a deterministic generator); expect a drop on real ticket prose.
• The negative class is domain-specific: version strings, branch names, Jira keys, ports, CVE ids, PIDs and timestamps are deliberately not redacted. If your domain wants those masked, this is the wrong starting point.
• English-vocabulary tokenizer on Turkish-weighted data — Turkish fragments ~2.5x more than English, which costs context and hurts numeric-identifier labels.
• Evaluated only on in-distribution held-out data. No out-of-distribution benchmark.

Attribution

Fine-tuned from urchade/gliner_large-v2.1 (Apache-2.0). Training data derives from BTX24/turkish-privacy-pii-ner (CC-BY-4.0), gretelai/gretel-pii-masking-en-v1 (Apache-2.0), mooselab/SDLog (MIT) and ai4privacy/pii-masking-400k (license: other — review its terms before redistributing derivatives).