smdesai/GLiNER25-Multi-FP16-CoreML

GLiNER2.5 Multi — Core ML (iOS 18+ / macOS 15+)

Core ML port of fastino/gliner2.5-multi-v1, the multilingual GLiNER2.5 boundary extractor. It is built on mDeBERTa-v3-base and has 287M parameters. One on-device model covers:

• Entities
• Text classification (single- and multi-label)
• Relations
• Structured records
• Span attributes

It keeps the upstream decision behavior. All credit for the model goes to Fastino and the GLiNER2 authors. The original model card is included as model-card.md.

This is the Core ML counterpart of smdesai/GLiNER25-Multi-FP16-CoreAI. It uses the same stage graphs, functions, inputs and outputs, and the same tokenizer and constants. The same host code drives both.

Files

File	Purpose
GLiNER25-Multi-FP16.mlmodelc/	Compiled Core ML multifunction ML program, FP16 (711 MB). Sixteen functions share one set of weights
tokenizer.json, tokenizer_config.json	Checkpoint tokenizer: SentencePiece Unigram, 250k vocabulary, GLiNER2 special tokens
constants.json	Weights and settings used by the decoder: RecordHead.null_embed and the checkpoint's boundary_head settings
functions.json	Input and output names, shapes and dtypes of every function
model-card.md	Upstream model card (fastino/gliner2.5-multi-v1, Apache-2.0)
LICENSE	Apache License 2.0

Source:

• Checkpoint fastino/gliner2.5-multi-v1 at revision 12fc40399dae672ce840c5e3c50a92340bff3c8c.
• Upstream code: fastino-ai/GLiNER2 at commit 55656fb (for preprocessing and decoding).

Export:

• coremltools 9.0, Torch 2.11.0. The model was traced in FP32 and converted with FP16 compute precision. The minimum deployment target is iOS 18 / macOS 15 (multifunction models).
• Compiled with xcrun coremlcompiler (Xcode 27.2).
• Learned weights are unchanged apart from the FP16 cast. The export rewrites only the graph structure, exactly as for the Core AI asset:
  • Constant DeBERTa relative-position buckets.
  • A gather-free relative shift.
  • Fused SDPA.
  • Prefix-sum span features computed as span-membership matmuls.
• Three converter-side fixes, none of which changes the computation:
  • Folded one-element constants are cast with .item().
  • DeBERTa's scaled_size_sqrt becomes a float constant.
  • Boolean | maps to logical_or.

How the model is split

GLiNER2.5's boundary architecture has data-dependent steps between its neural parts, so the model is exported as four stages. The host runs the logic between them. For each sequence bucket T ∈ {128, 256, 512, 1024} tokens, the functions are a_t<T>, b_t<T>, c_t<T> and d_t<T>:

Function	Computes	Main inputs → outputs
a_t<T>	mDeBERTa encoder, word and marker gathers, classifier, boundary encoder, start/end/inside marginals, candidate-pool projections, null and count heads, record field projection	input_ids, attention_mask, word_idx/word_mask, query_idx/query_mask, cls_idx → states and logits
b_t<T>	Shared-pool pair scorer and record-head projections	stage-A outputs + 192 pool spans (pool_idx, pool_mask, pool_prior) → pair_logits [1,192,32], record projections
c_t<T>	Sparse relation scorer	text_states + up to 8 relation types and 512 pairs → relation_logits
d_t<T>	Explicit-span scorer, used by entity attributes and choices= fields	stage-A outputs + up to 64 spans → explicit_logits [1,32,64]

Integer inputs are int32 and float inputs and outputs are FP16. Stage-A output arrays can be passed unchanged into B, C and D. Exact shapes are in functions.json.

Static capacity per call: T tokens, 32 extractive queries (entity types, structure fields, relation roles), 32 classification labels in total, 8 relation types.

Host responsibilities:

• Tokenization and GLiNER2 prompt layout.
• Candidate-pool selection: top-32 start and end boundaries, per-query quota, deduplicated to 192.
• Relation pair generation.
• Every decoding step (thresholds, overlap resolution, records, attributes, formatting).

These must follow upstream exactly. A Swift implementation of all of them was validated against upstream: tokenizer, preprocessing, decoding and long-document chunking. It lives in the companion repository and runs this model and the Core AI asset interchangeably.

Loading: one function per MLModel, CPU + GPU

import CoreML
let config = MLModelConfiguration()
config.computeUnits = .cpuAndGPU
config.functionName = "a_t128"            // likewise b_t128, c_t128, d_t128, a_t256, ...
let stageA = try MLModel(contentsOf: mlmodelcURL, configuration: config)
let out = try stageA.prediction(from: MLDictionaryFeatureProvider(dictionary: inputs))

The model was validated with .cpuAndGPU. Neural Engine placement was not validated.

Validation

The reference is upstream GLiNER2 in PyTorch FP32, run through its public extraction API. The corpus, fixtures and pass gate are the same as for the Core AI asset. Its Core AI results are shown for comparison.

iPhone 17 Pro, iOS 27.2, GPU:

Check	Core ML (this model)	Core AI
Stage outputs vs FP32	every output ≥ 60.5 dB PSNR	≥ 62 dB
Determinism	identical outputs across repeated runs	identical
54-case corpus, full Swift pipeline	54/54 exact, max confidence error 0.0048	54/54 pass: 53 exact, 1 boundary item; 0.0026
11 long documents (786–3,755 words, 7 languages, 87 chunks)	11/11 pass: 9 exact, 2 differ only on FP32 boundary items	11/11 pass: 8 exact, 3 boundary

Mac (GPU, macOS 27.2):

Check	Core ML (this model)	Core AI
54-case corpus, Python and Swift pipelines	54/54 exact, max confidence error 0.0044	54/54 exact, 0.0054
11 long documents	11/11 pass: 9 exact, 2 boundary	11/11 exact
Constrained classification (35 cases + 3 long)	35/35 + 3/3, max logit error 0.025	35/35 + 3/3, 0.022
Joint IE (17 cases + 2 long)	17/17 + 2/2; 1 FP32-sensitive edge in the 17 and 1 in the long set	17/17 + 2/2; 1 FP32-sensitive edge in the 17
1024 bucket: 6 documents cut to fit 1024 tokens (en, de, fr, zh, ru)	stage outputs ≥ 61.9 dB; 5/6 identical to upstream	≥ 61.7 dB; 5/6 identical

In the 1024-bucket check, the sixth document (German, about 30 organization and person mentions) differs from upstream in both formats. Each format gains or loses one borderline organization mention and the relation attached to it, and the two formats differ on different mentions.

Corpus coverage:

• Tasks: entities, descriptions, thresholds, regex validators, overlap policies, single- and multi-label classification, relations, legacy structures, natural/latent/anchorless records, exclusive fields, choice fields, entity attributes, joint tasks.
• Ten languages.
• The 128, 256 and 512 buckets, plus the 1024 check above.

Boundary items: GPU FP16 kernels differ slightly between devices and between Core ML and Core AI, by up to about 0.04 on boundary logits. Items that sit at a decision boundary can therefore flip. "FP32 boundary items" were precomputed at FP32 before any device run:

• Items whose confidence is within 0.02 of their threshold.
• Items that change under N(0, 0.01) noise on the stage outputs, which covers the candidate-pool cut and record assignment.

A result that differs from upstream passes only if every differing item is in that set.

Performance, end to end (iPhone 17 Pro; preprocessing + model + decoding, steady state):

Input	Core ML	Core AI
≤128 tokens	9.2 ms	13.4 ms
≤256 tokens	12.6 ms	19.6 ms
≤512 tokens	29.2 ms	39.3 ms
18-chunk long document	543 ms	684 ms

Memory (iPhone 17 Pro, process footprint): about 190 MB after load, about 325 MB after the first run of all 16 functions, and a peak of 575 MB over the whole check suite.

Load time:

• About 22 s on first launch, plus about 11 s for the first run of every function (on-device compilation for the GPU).
• About 1.7 s from the system cache, plus about 0.7 s to prime all functions.
• Load and prime once at app start.

Limitations

• A single call handles up to 1024 tokens. Longer texts need chunking. Upstream extract_long splits into overlapping word windows; with this model, windows of 256 words and 48 words of overlap, shrunk to fit 512 tokens, work well and keep every chunk in the faster 512 bucket.
• Constrained classification (Classifier) and JointIE from the upstream card are separate decoders on top of the same stages; the Swift runtime ports both.
• The model is larger than the Core AI asset (711 MB vs 550 MB). Core ML constant-folds each bucket's DeBERTa relative-position tables, which Core AI computes at run time.
• FP32 layer norm and softmax inside the FP16 graph were tried. They did not improve accuracy on the iPhone and ran about 10% slower, so FP16 throughout is the release configuration.
• Validated on iOS 27.2 and macOS 27.2 only. The deployment target allows iOS 18 / macOS 15.

License and attribution

• Weights: from fastino/gliner2.5-multi-v1 by Fastino, released under the Apache License 2.0. This repository redistributes them converted to Core ML format, unchanged in value apart from the FP16 cast, under the same license (LICENSE).
• Tokenizer: derived from microsoft/mdeberta-v3-base (MIT), as shipped with the upstream checkpoint.
• Citation: see the upstream card for the GLiNER2 paper (arXiv:2507.18546).

SHA-256

bf71f15e0a7c0a1390c73ab2c7e129379241d642da38a02435b497b88d8de92c  GLiNER25-Multi-FP16.mlmodelc/weights/weight.bin
265391ebed69a70bdc89b460d3e5fb88b61dcfd9b8c9d5a398e4a7c1575dd7ca  GLiNER25-Multi-FP16.mlmodelc/model.mil
dffd788adbe1e0b2dc7463a4e40fa6c15f91446f2a4d502456ba3afe0c9d3ff9  GLiNER25-Multi-FP16.mlmodelc/coremldata.bin
99ad54cc0b5800b5e91aceb7d9138afbdd048d35ffc763d1a8fef075c4d4aeef  GLiNER25-Multi-FP16.mlmodelc/metadata.json
c62446df87ae18ec98b133f8f84fc449a07cc89bbf8ef192a4cb5f9c53777a7a  tokenizer.json
1ea719a39e3b712b99a5d902feffc1a19114861305d8ac152f5a995579e39812  constants.json
e78eacdef5a72213d40ae556551763ce825a6918f7ca03e62cdb851118b669d7  functions.json