Fastino releases GLiNER2.5, removes entity length limits

The previous version, GLiNER2, found entities by listing out candidate spans one by one. It paired every starting position with every allowed length and matched each pair against the schema, which meant the compute cost was tied directly to the "length" axis. Without a cap on length, the computation becomes unmanageable, so spans were typically truncated at around twelve words. Anything longer — a forty-word liability clause, say — was effectively excluded from scoring from the start.

Predicting only the boundaries got rid of the length cap

Instead of enumerating spans, GLiNER2.5 predicts start and end scores at token boundaries and an internal score within each token. The shared encoder still processes text and schema queries together in one pass, but everything after that changes. A sparse proposal stage picks the most likely start and end points for each query and pairs them up without any distance restriction, and a reranking stage then scores the final result by weighing both the boundary evidence and the span's content together. Relation extraction candidates are drawn from the same pool, so they don't need a separate pipeline.

That single change eliminates the upper bound on entity length, and the Fastino team says that, within a fixed schema and candidate budget, compute now scales linearly with sentence length.

Five new capabilities

Because spans are no longer enumerated explicitly, there's more memory headroom, which allowed training and inference to scale up to 4,096 words. New chunking tools (extract_entities_long, extract_long, etc.) handle long documents by mapping spans found in truncated chunks back to their character positions in the original document.

The entity length cap is gone too. Where the old limit sat around twelve words, GLiNER2.5 can now find a span that opens at the first token and closes at the last, at the same cost as finding a two-word name. On top of that, there's a joint extraction feature: declare entity types, relations, and structural rules like unique_head=True, and a beam search assembles a graph that stays consistent with the schema.

Constrained classification is also new, using rules like C.implies and C.excludes to tie labels from different tasks together at the decoding stage. Take Fastino's guardrail model, GLiGuard, as an example: without constraints, a single prompt could end up labeled both "safe" and "prompt injection detected" at the same time, a contradiction this feature prevents. There's also a span attributes feature, which attaches an attribute group — sentiment, for instance — to a specific entity type and decodes it in the same forward pass.

Three checkpoints, and how the benchmarks turned out

Fastino put three checkpoints — 74M, 194M, and 287M parameters — on Hugging Face under an Apache 2.0 license. Hugging Face is the distribution hub where public models from companies like Meta or Alibaba get posted, and Fastino has now added its own checkpoints there too.

Model	Parameters	Encoder	Language
gliner2.5-small-v1	74M	DeBERTa-v3-xsmall	English
gliner2.5-base-v1	194M	DeBERTa-v3-base	English
gliner2.5-multi-v1	287M	mDeBERTa-v3-base	Multilingual

Comparing results across 16 zero-shot benchmarks against equivalent-size GLiNER2 models, the multilingual model's overall average macro F1 edged up to 56.17 from GLiNER2's 56.09, while the base model jumped to 54.87 from 53.34.

Metric	GLiNER2	GLiNER2.5
Overall average (multilingual)	56.09	56.17
Overall average (base)	53.34	54.87
XNLI (multilingual)	37.55	62.30
Few-NERD (base)	47.22	55.14

The biggest jump came on XNLI, where the multilingual model climbed 24.75 points, from 37.55 to 62.30. Fastino also reports improvements on both model sizes for the Romanian RONEC benchmark, a language that wasn't in the training data.

How to try it

The checkpoints ship as a local package installable via pip install "gliner2[local]", and inference runs on CPU, CUDA, or MPS under Python 3.10 or later. There's no inference hosting service currently offering these checkpoints as a managed option, though, so self-hosting — standing up and running your own server — is the only deployment path for now.

Loading the model requires the new AutoExtractor, not GLiNER2's old span loader, and all three checkpoints share the same public API. Use cases split by organization size: the 74M and 194M models run on ordinary CPU servers, so small teams without a GPU budget can plug in extraction capability right away, while larger organizations can treat this as a fine-tunable, self-hosted alternative. Fastino names legal and contract review, healthcare and clinical documents, financial services, insurance claims, customer support, and AI safety tooling as target industries, with specific use cases including PII detection and de-identification, contract clause extraction, knowledge graphs for agent memory, model routing, guardrail classification, and clinical entity extraction that captures negation and dosage attributes.

Editor's view

What's worth paying attention to here isn't the benchmark scores themselves, but what cost structure just got rewired. Running information extraction through a large language model means paying per document, per token. GLiNER2.5 moves that cost onto a different axis entirely. Making entity length irrelevant to compute cost means, in practice, that a forty-word contract clause and a two-character name cost the same to process — and that's a hard difference to ignore if your team is currently running a full-size LLM for this job.

Working with open models this size tends to lead to the same conclusion every time: the headline benchmark average moves by a point or two, nothing dramatic, but if you isolate the specific case your work actually depends on — long clauses, multilingual documents — the gap feels much bigger in practice. The 24.75-point jump on XNLI is easy to skim past if you're only looking at the overall average, but for any team working with multilingual documents, that's a real reason to consider switching.

For teams here weighing a practical baseline: a two- or three-person team without a GPU budget could reasonably start by plugging the 74M or 194M checkpoint into PII detection or contract clause extraction on CPU alone. Teams working with multilingual documents — especially ones that include Korean — should first validate the 287M multilingual checkpoint's actual accuracy against their own data. That said, without a dedicated hosting service available yet, plugging this straight into production without an infrastructure team may still be premature.

The thing to watch over the coming weeks is whether inference providers start offering these checkpoints as a hosting option. Once the burden of self-hosting eases up, adoption among smaller teams should pick up noticeably.