One schema can drive five extraction jobs
GLiNER2 puts 5 related jobs behind one Python interface: named entities, text labels, structured records, relations, and attributes attached to spans. You describe the fields or labels you want, then a schema-conditioned encoder searches the text for them. That makes the project appealing for document pipelines that would otherwise maintain separate classifiers, entity models, and record parsers.
The boundary-based GLiNER2.5 checkpoints extend the original fixed-width span approach with start and end pairing. The public models range from a 74M-parameter English option to a 340M-parameter legacy span model, with multilingual and safety-focused choices in between. Long-document methods scan overlapping chunks and remap local offsets into the original text. None of that establishes accuracy on your invoices, contracts, or clinical notes.
The base package is small in scope; local inference is not
The torch-free base package declares 4 direct runtime dependencies and supplies schemas, regex validators, data utilities, and the cloud client. Local checkpoint inference moves to the [local] extra, which adds PyTorch, Transformers, PEFT, NumPy, and safetensors. The client reads PIONEER_API_KEY; the local route needs checkpoint files from the model hub but no per-document hosted call after the assets are present.
Separate extras cover training, tests, development, and benchmarks. That packaging is thoughtful because schema validation should not pull an ML runtime into every service. A local worker still needs storage for the Python stack and chosen weights, plus CPU or GPU memory. The README labels the models CPU-first, while its optional CUDA paths add fp16, compilation, and FlashDeBERTa. We did not measure inference speed.
What happened when we ran it
Our sandbox cloned commit 0652bae, installed 106 packages in 87 seconds, and used 5,690 MB on disk. The repository itself contained 265 files, about 51,088 lines of source, and occupied 6.7 MB. Building succeeded in 1 second. Pip-audit reported 10 known vulnerabilities in the installed environment; the supplied result does not identify their severity here.
The test process hit our 900-second cap and did not complete. The log had crossed 51% and displayed failure markers before timeout, followed by a Python thread stack ending inside the tqdm monitor wait. That tail does not tell us which test kept the process alive or whether the monitor caused the delay. It establishes only that the full suite neither passed nor finished in our stated environment.
Our scan found a tests directory but 0 GitHub Actions workflow files and no Dockerfile. The README describes release gates across Python 3.10 through 3.12, offline checks, checkpoint quality, CUDA hardware, and fresh artifact installs. Those claims may be implemented outside the measured checkout or in later changes; the commit we inspected did not expose workflow files for a buyer to audit.
Two architectures make the loader choice consequential
The public API has a trap the README explains plainly. AutoExtractor reads checkpoint metadata and dispatches to the span or boundary architecture. The older GLiNER2.from_pretrained() alias is span-only and will not load GLiNER2.5 boundary weights. Starting new code with AutoExtractor avoids coupling the application to one family before you have compared its outputs.
Word splitting deserves the same care. Public checkpoints use whitespace boundaries by default. A character splitter is provided for Chinese and other text without whitespace-delimited words, but the README warns that changing boundaries can affect quality and that this runtime choice is not stored with a checkpoint. A service must pass the setting again on reload, then test offsets against the original document.
Relation descriptions and CJK training have open defects
Issue 101 was still open on September 17, 2026. Its follow-up confirms on v2.0.0 that the JointIE schema accepts relation descriptions yet fails to pass them into the model contract. Thresholds on the same relation object work. Silent acceptance is especially risky because an application cannot tell whether the model rejected its definition or the library ignored it.
Issue 156 gives a smaller, reproducible CJK failure. With the default splitter, one Chinese sentence becomes a single token, so an entity inside it cannot align as a token subsequence and training raises a misleading missing-entity error. The documented word_splitter="char" workaround aligns that example, though the report says mixed CJK and URL text still lacks a good built-in option.
September fixes show speed, while the verification debt remains
GitHub reported 1,936 stars, 55 combined issues and pull requests, and a last push on September 18, 2026. Several classification and training bugs opened on September 16 or 17 were fixed by September 18. Release v2.0.0 landed August 24 with long-document chunking, span attributes, constrained classification, JointIE, and the boundary architecture.
That pace is encouraging for a young model library, and it also means the behavior is moving quickly. GLiNER2 is worth a measured trial if a single 194M-parameter checkpoint could replace several narrow extraction services. Keep the trial behind held-out documents, compare spans and records field by field, pin the checkpoint and splitter, and block promotion until the dependency audit and full suite are clean enough for your policy.