Information extraction teams face a recurring choice. Small encoder models are cheap but rigid, and large language models are flexible but expensive per document. Fastino released GLiNER2.5 to narrow that gap. The release replaces span enumeration with boundary prediction: the model scores where an entity starts and ends instead of scoring every candidate span against a width grid. That single change removes the maximum entity width, allows a 4,096-word context, and keeps computation linear in sequence length for a fixed schema. It also unlocks joint entity-relation decoding, cross-task label constraints, and per-span attributes. Across 16 zero-shot benchmarks, the multilingual checkpoint reaches 56.17 overall macro F1 against 56.09 for GLiNER2, with a 24.75-point gain on XNLI. Three checkpoints ship on Hugging Face under Apache 2.0 at 74M, 194M, and 287M parameters.
Is it deployable?
Yes, Fastino released three GLiNER2.5 checkpoints on Hugging Face under Apache 2.0, with local inference on CPU, CUDA, or MPS via pip install "gliner2[local]" (Python 3.10+). No inference provider currently hosts the checkpoints, so self-hosting is the deployment path.
- Company level: any tier. The 74M and 194M checkpoints run on standard CPU boxes, so a two-person team can ship extraction without GPU budget. Larger orgs get a fine-tunable, privately hosted alternative to per-token LLM extraction.
- Industries: legal and contract operations, healthcare and clinical documentation, financial services, insurance claims, customer support, and AI safety tooling.
- Applications: PII detection and redaction, contract clause extraction, knowledge graphs for agent memory, agent and model routing, guardrail classification, clinical entity extraction with negation and dosage attributes.
What changed
Earlier GLiNER models located entities by enumerating candidate spans: every start position paired with every allowed width, each scored against the schema. That design tied compute to a width axis and imposed a hard ceiling on entity length.
GLiNER2.5 removes enumeration. The shared encoder still processes text and schema queries in one pass. Instead of scoring spans, the model predicts start and end scores over token boundaries plus inside scores over tokens. A sparse proposal stage selects the most promising starts and ends per query and pairs them, with no restriction on distance. A reranking head then scores each candidate using boundary evidence and span content. Relation candidates are drawn from the same pool rather than a separate path.
Fastino team reports that computation stays linear in sequence length for a fixed schema and candidate budget.
Five capabilities that follow
- Long-context extraction: Removing explicit span representations cut memory enough to train on sequences up to 4,096 words. The checkpoints ship with
max_len=4096. The library also adds native chunking helpers (extract_entities_long,extract_long,Classifier.classify_long,JointIE.extract_long) that remap spans to character offsets in the original document. - Unlimited span length: GLiNER2 enumerated spans up to a fixed width, typically around twelve words; longer entities were never scored. In GLiNER2.5 a span can 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.
- Joint entity and relation extraction: Users declare entity types, typed relations, and structural rules (
unique_head=True,no_self_loops()), and a beam search assembles a globally consistent graph. Invalid combinations are never admitted, so output conforms by construction. Checkresult.feasiblebefore using the graph. - Constrained classification:
C.impliesandC.excludesrules bind labels across tasks during decoding. Fastino’s own GLiGuard guardrail model illustrates the problem being solved: without constraints, a prompt can be labeled safe while simultaneously flagged for prompt injection. If no valid assignment exists, the classifier raises an error. - Span attributes: Attribute groups such as sentiment attach to specific entity types via
applies_to, and are decoded span-by-span in the same forward pass. Entities return qualified rather than flat.
The model family
All three share the same public API. Load with AutoExtractor, not the legacy GLiNER2 span loader.
Benchmarks
Fastino team evaluates zero-shot on 16 public datasets, reporting macro F1 against GLiNER2 at matched sizes.
Overall average: GLiNER2.5 Multi reaches 56.17 versus 56.09 for GLiNER2 Multi. GLiNER2.5 Base reaches 54.87 versus 53.34. The headline gain is XNLI, where Multi jumps to 62.30 from 37.55, a 24.75-point increase. Few-NERD improves for Base to 55.14 from 47.22. Romanian RONEC, an untrained language, improves for both.
Key Takeaways
- Boundary prediction replaces span enumeration; entity width no longer costs compute.
- Three Apache 2.0 checkpoints: 74M, 194M, 287M, all CPU-runnable.
- Joint decoding returns schema-valid graphs, removing post-hoc validation layers.
- Overall F1 rises to 56.17 (Multi) and 54.87 (Base); extraction average dips for Multi.
- Chunking keeps a span only when both boundaries land in one chunk.
Check out the Fastino technical blog, the GitHub repo, and the boundary architecture docs. Feel free to check out our GitHub Page for Tutorials, Codes and Notebooks.
Also, feel free to follow us on Twitter and don’t forget to join our 150k+ML SubReddit and Subscribe to our Newsletter. Wait! are you on telegram? now you can join us on telegram as well.
Michal Sutter is a data science professional with a Master of Science in Data Science from the University of Padova. With a solid foundation in statistical analysis, machine learning, and data engineering, Michal excels at transforming complex datasets into actionable insights.
