GLiNER2.5 Drops Span Enumeration, Opens 4,096-Token Context
In this article
Fastino has shipped GLiNER2.5, a named-entity recognition framework that discards span enumeration entirely in favour of boundary prediction. Where prior GLiNER releases scored every (start, width) pair against a candidate grid, GLiNER2.5 scores start positions, end positions, and inside tokens independently, then uses a sparse proposal stage to pair the most promising boundaries without any distance restriction. The change makes computation linear in sequence length for a fixed schema and candidate budget, removes the hard ceiling on entity length that constrained GLiNER2, and opens the context window to 4,096 tokens. Three checkpoints — 74M, 194M, and 287M parameters — ship on Hugging Face under Apache 2.0, all runnable on CPU, CUDA, or MPS.
Under span enumeration, a forty-word indemnification clause was either invisible (if it exceeded the maximum width, typically around twelve words for GLiNER2) or expensive (if the width ceiling was raised, since candidates grow with every additional width step). GLiNER2.5's boundary scorer treats a forty-word clause identically to a two-word proper noun in terms of candidate budget. That property, combined with software-defined extraction becoming a competitive lever, gives small teams running on standard CPU boxes a path to production NER that previously required either GPU budgets or per-token LLM API costs.
Boundary Prediction Mechanism
The shared encoder still processes text and schema queries in a single forward pass. The departure is in what the decoder does with encoder outputs: instead of materialising a span tensor, GLiNER2.5 emits three score streams — start scores and end scores over token boundaries, and inside scores over tokens. A sparse proposal stage selects high-confidence starts and ends per query and pairs them. A reranking head then rescores each candidate using both boundary evidence and span content, but only sees proposals the sparse stage admits.
Five capabilities follow directly from removing the width axis. First, the 4,096-token context becomes trainable because explicit span representations no longer consume memory that scales with width. The library exposes chunking helpers (extract_entities_long, extract_long, Classifier.classify_long, JointIE.extract_long) that remap spans to character offsets in the source document; a span is retained only when both of its boundaries land within the same chunk. Second, joint entity-relation extraction becomes tractable: relation candidates are drawn from the same boundary-pair pool, and a beam search assembles a globally consistent graph under user-declared structural rules such as unique_head=True and no_self_loops(). Invalid typed edges are never admitted. Third, constrained classification allows C.implies and C.excludes rules to bind labels across tasks during decoding — a document cannot simultaneously receive a "safe" label and a "prompt injection" flag; the decoder raises rather than returning a contradictory result. Fourth, span attributes such as sentiment attach to specific entity types via applies_to and are decoded in the same forward pass, returning qualified rather than flat entity records. Fifth, there is no longer any maximum entity width to tune.
Checkpoint Specifications
| Checkpoint | Parameters | Encoder backbone | Language scope |
|---|---|---|---|
| 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 and load via AutoExtractor. The legacy GLiNER2 span loader is not compatible. Installation is pip install "gliner2[local]" on Python 3.10 or later. No inference provider currently hosts the checkpoints, so self-hosting is the only deployment path. The 74M and 194M checkpoints run without GPU budget, relevant for small teams or latency-constrained edge deployments.
Zero-Shot Benchmarks Across 16 Datasets
Fastino evaluates all checkpoints zero-shot across 16 public datasets, reporting macro F1 against matched-size GLiNER2 baselines. The multilingual checkpoint reaches an overall average of 56.17 macro F1 versus 56.09 for GLiNER2 Multi. The base checkpoint moves from 53.34 to 54.87. The headline individual-task result is XNLI, where the multilingual checkpoint jumps from 37.55 to 62.30 — a 24.75-point improvement. Few-NERD improves for the base checkpoint from 47.22 to 55.14. Romanian RONEC, a language outside training distribution, improves for both checkpoint sizes. The extraction-task average for the multilingual checkpoint dips slightly relative to GLiNER2 Multi, a trade-off Fastino attributes to the architectural shift prioritising long-context and relation capabilities over raw flat-NER throughput.
GLiNER2.5 is a concrete example of pipeline architecture outpacing raw model scaling as the primary lever for extraction quality. By eliminating span enumeration as a structural constraint, Fastino has made entity length a non-issue and opened joint extraction to schema-constrained decoding — both of which directly address the engineering friction that pushes teams toward heavier, costlier LLM-based pipelines. Apache 2.0 licensing across all three checkpoints means those architecture gains are immediately forkable, fine-tunable, and deployable without negotiating access tiers.