GLiNER2.5: Fastino’s Boundary-Prediction Model Drops Span Width Limits

Fastino released GLiNER2.5 on August 24, 2026, a named entity recognition (NER) model that swaps span enumeration for boundary prediction. Instead of scoring every start-and-width combination against a schema, the model scores where entities begin and end, which removes the hard cap on entity length and expands context to 4,096 words. Three checkpoints (74M, 194M, 287M parameters) are available on Hugging Face under Apache 2.0 and run on standard CPUs. The multilingual checkpoint reaches 56.17 macro F1 across 16 zero-shot benchmarks, up from 56.09 for GLiNER2.

What happened

Detail	Value
Release date	August 24, 2026
Checkpoints	74M, 194M, 287M parameters
License	Apache 2.0
Max context	4,096 words
Overall macro F1 (Multi)	56.17 vs 56.09 (GLiNER2)
XNLI gain (Multi)	+24.75 points (62.30 vs 37.55)
Installation	pip install “gliner2[local]” (Python 3.10+)
Inference hardware	CPU, CUDA, or MPS

GLiNER2.5 is Fastino’s answer to a familiar tradeoff in information extraction: small encoder models are cheap but inflexible, while large language models are flexible but expensive to run per document. The new release targets the middle ground.

The core change is architectural. Older GLiNER models worked by enumerating candidate spans: every starting position paired with every allowed width (typically up to around twelve words), each scored against the schema. That tied memory and compute to a width axis and meant any entity longer than the cap simply could not be found.

GLiNER2.5 drops enumeration entirely. The shared encoder still processes text and schema queries in a single forward pass. Rather than scoring spans, it predicts start scores, end scores, and inside scores over token boundaries. A sparse proposal stage selects the most promising boundaries per query and pairs them. A reranking head then scores each candidate using both boundary evidence and span content. According to Fastino, computation stays linear in sequence length for a fixed schema and candidate budget.

What are the five new capabilities?

1. Long-context extraction

Removing explicit span representations cut memory enough to train on sequences up to 4,096 words. The library adds chunking helpers (extract_entities_long, extract_long, Classifier.classify_long, JointIE.extract_long) that remap spans back to character offsets in the original document. Note: a span is kept only when both boundaries fall within the same chunk.

2. Unlimited span length

A span can now open at the first token and close at the last. A forty-word indemnification clause costs the same to locate as a two-word name. This matters especially for legal and clinical text, where entities are frequently multi-sentence constructions.

3. Joint entity and relation extraction

Users declare entity types, typed relations, and structural rules such as unique_head=True or no_self_loops(). A beam search then assembles a globally consistent graph, rejecting invalid combinations by construction rather than in a post-processing step. Fastino advises checking result.feasible before consuming the graph.

4. Constrained classification

C.implies and C.excludes rules bind labels across tasks at decode time. Fastino’s own GLiGuard guardrail model illustrates why this matters: without constraints, a prompt could be labeled “safe” and simultaneously flagged for prompt injection. If no valid assignment exists, the classifier raises an error rather than returning a contradictory result.

5. Span attributes

Attribute groups such as sentiment can be attached to specific entity types via applies_to. They are decoded span-by-span in the same forward pass, so entities return with qualifiers attached rather than as flat labels.

The model family

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

All three share the same public API. Fastino specifies loading with AutoExtractor, not the legacy GLiNER2 span loader.

Benchmark results

Fastino evaluated all checkpoints zero-shot across 16 public datasets, reporting macro F1. The headline number for the multilingual checkpoint is 56.17 versus 56.09 for GLiNER2 Multi. The base checkpoint reaches 54.87, up from 53.34. The largest individual gain is on XNLI, where the multilingual model jumps 24.75 points to 62.30. Few-NERD improves for the base checkpoint from 47.22 to 55.14. Romanian RONEC, a language not seen in training, improves for both checkpoints. The extraction average for Multi does dip slightly, which Fastino acknowledges.

Why it matters

The practical barrier to structured extraction from documents has been cost and rigidity. Encoder models were fast but broke on long or unusual entities. LLMs handled those cases but charge per token and add latency. GLiNER2.5 sits in between: a 74M model that fits on a CPU box, processes 4,096 words at a time, and returns structured graphs with attributes. A two-person team can run it without a GPU budget.

The use cases are concrete: PII detection and redaction, contract clause extraction, knowledge graphs for agent memory, guardrail classification, clinical entity extraction with negation and dosage attributes. The constrained classification feature is particularly relevant for teams building AI integration pipelines where contradictory label outputs create downstream failures.

The one real limitation right now is deployment. No inference provider hosts GLiNER2.5 checkpoints at the time of release. Self-hosting is the only path, which means your team needs to manage the stack. For teams already comfortable with that, the Apache 2.0 license and CPU-runnable sizes remove most friction.

Our take

The boundary-prediction architecture is a genuine improvement in structure, not just a fine-tuned repackage. Removing the width axis and getting joint entity-relation decoding in one pass is the kind of change that actually affects what you can build. The benchmarks are modest in aggregate, but that XNLI jump of 24.75 points signals real multilingual improvement rather than noise.

The catch is deployment maturity. “Self-host via pip” works fine for a team with engineering capacity, but it means no managed fallback and no SLA. If you are evaluating this against an LLM API for extraction, factor in your own infrastructure cost honestly. For high-volume, schema-stable pipelines, especially legal or clinical text, GLiNER2.5 is worth testing now. For low-volume or highly variable schemas, an LLM call may still win on total effort.

We have seen similar extraction problems in enterprise AI infrastructure decisions: teams often reach for the biggest model by default when a smaller, faster one with the right architecture would serve better at a fraction of the cost. GLiNER2.5 is a good prompt to revisit that assumption.

If you want help evaluating where this fits in your document processing stack, talk to the Lumien team.

Source: Marktechpost