A 340-million-parameter model released on September 24 beats a 4-billion-parameter language model on the same classification task, and it does it without a GPU. That is the claim behind GLiNER2.5-Decide, Fastino's latest addition to the GLiNER family. The gap between encoder and decoder models for structured decisions is rarely framed this starkly, and it is worth understanding - including the parts Fastino does not lead with.
What GLiNER2.5-Decide actually is
GLiNER2.5-Decide is a 340M-parameter open-weight model for schema-defined decision-making. It is not a chat model, not a reasoning model, and not a general assistant. The release is explicit about this: the model does not reason, explain, or answer open questions - it is a specialist for operational decisions: customer and banking intent, travel and clinic requests, review sentiment, document type, email and ticket routing, human handoff, agent completion, moderation, severity, urgency, and spam.
What makes the architecture different from using a small decoder is how it produces answers. An app often needs a small judgment inside a larger program - which handler gets this request, is this message urgent, which words in it are a date. Asking a chat model for JSON works, but the output is text that still needs parsing and can drift off the allowed labels. GLiNER2.5-Decide skips generation entirely: you supply the candidate labels and get back a probability for each one.
The other practical detail is label flexibility. You pass any label set at call time: intent, routing, sentiment, priority, policy, and multi-label tags, in a single forward pass.
That means adding a new category does not require retraining anything. For a support team that evolves its routing taxonomy quarterly, that matters more than a marginal accuracy point.
A shared mailbox needing three answers before a message is filed - what the sender wants, how urgent it is, which team owns it - can score all three heads on the same text in one call, so the router does not run the model three times.
The benchmark numbers, read carefully
GLiNER2.5-Decide scores 60.1% average accuracy on Fastino's own 17-dataset Fast Decisions suite, ahead of JevK5 at 57.5%, and answers in 167ms on a 48-core CPU with no graphics card. The comparison table is striking:
| Model | Type | Fast Decisions avg | GPU required? |
|---|---|---|---|
| GLiNER2.5-Decide | 340M encoder | 60.1% | No |
| JevK5 | 4B-class decoder | 57.5% | Typically yes |
| SemIf (Qwen3.5-4B) | 4B decoder | 56.4% | Typically yes |
| Laya (ModernBERT 421M) | 421M encoder | 46.6% | No |
GLiNER2.5-Decide led 9 of 17 datasets. Intent routing was its strongest area: 75.3% on support intent and 64.3% on banking intent - 18.6 and 8.6 points ahead of the next-best models.
Here is what Fastino does not lead with: the headline benchmark is Fastino's own, and the "Jev" it beat is an open imitation of Jev, not the real TypeSafe product. That is not an obscure footnote - it changes the competitive claim materially.
These figures are Fastino's numbers on Fastino's test set: 5,100 examples across 17 domains. The company says plainly it is an internal benchmark. It does not say where the figures for the rival models came from, so read the gaps as the vendor's framing rather than an independent result.
An independent evaluation on Hugging Face tested the model against a different benchmark and found a harder picture. On DecisionBench, the published result shows 38.9% accuracy on supported rows, but only 25.4% across all rows, with more than a third marked unsupported - versus Fastino's reported 60.2% on its own Fast Decisions benchmark. The gap between those two numbers is the most important thing to know before deploying this model.
The evaluator found a format gap: the evaluation call supplies an input string and a classification schema with a task name and label names, but there is no separate description attached to every label in the public rows.
In one documented case, removing only the appended descriptions from a 252-token input caused the model to pick the correct label - the deletion changed the answer even though both versions fit the encoder's context window. Prompt structure is load-bearing with this model in a way it is not with a chat model that can lean on instruction-following.
Where it fits in a real workflow
The model is not a replacement for an LLM in a conversation - it is a replacement for the LLM you are currently using to answer a question that has a fixed answer set. The model does not reason, explain, or answer open questions. What it does instead is decide, the same way every time - which is what most production classification actually needs.
Consider a Slack-integrated support bot triaging incoming tickets. Today, many teams send each message to a frontier model to extract intent, urgency, and owner. This is the third small specialist model in a month built on being cheap and narrow rather than capable and general. The frontier labs compete on what a model can do; a growing tier underneath them competes on what you no longer have to pay them for.
Fastino also published GLiNER2.5-Decide-1B, built on the Ettin 1B encoder, scoring 59.6% on the same suite - just under the 340M model. For multilingual input, the GLiNER2.5-multi-Decide at 287M scores 56.7%.
The model is available at fastino/GLiNER2.5-Decide on Hugging Face under Apache 2.0.
It runs locally on CPUs or GPUs through GLiNER2, and returns constrained answers with probabilities and confidence scores instead of generating free-form text.
There is also a hosted endpoint at agent.fastino.ai for teams that do not want to self-host.
The architecture reason this works
The GLiNER family is built on DeBERTa-v3-large, a bidirectional encoder, not a decoder. Two changes drive the 2.5 release: the architecture replaces span enumeration with boundary prediction, scoring entity start and end positions directly, so inference scales linearly with document length. For short routing inputs - a support message, a Slack thread, an email subject line - this is the right shape. A decoder generates tokens sequentially; an encoder reads the whole input at once and scores labels against it.
The training data was generated with the Fastino Data Agent rather than assembled from existing datasets, covering task combinations, document formats, and languages that no public dataset does. That matters for the benchmark evaluation but also introduces a risk: the model may have been optimized for the kinds of examples it was trained on, which would explain some of the gap between internal and external benchmarks.
A teammate like Beagle - which already reads Slack threads to draft answers - could call a local GLiNER2.5-Decide endpoint as a fast pre-filter before deciding whether a thread needs a full LLM response at all.
Beagle in action#customer-support, 10:02amOn-device AI text classification: common questions
What is GLiNER2.5-Decide and what does it do?
GLiNER2.5-Decide is a 340M-parameter open-weight encoder model released by Fastino on September 24, 2026. It classifies text against a label set you supply at call time - intent, urgency, routing destination, sentiment - and returns probabilities rather than generated text. It runs on CPU in about 167ms, requires no GPU, and is licensed Apache 2.0.
How accurate is GLiNER2.5-Decide compared to larger language models?
On Fastino's own 17-dataset benchmark it scores 60.1%, ahead of 4B-parameter decoder models. On an independent evaluation using DecisionBench, accuracy dropped to 38.9% on supported rows and 25.4% across all rows. The gap is large enough that you should benchmark on your own label taxonomy before committing.
Can GLiNER2.5-Decide run without a GPU on a standard server?
Yes. Fastino reports p50 latency of 167ms on a 48-vCPU Intel Xeon Platinum with no GPU required. On an NVIDIA T4 or L4, latency drops to around 43ms. The model is small enough that a single inference server can handle high-volume routing without specialized hardware.
When should a team use a small classifier instead of an LLM for routing?
When the answer is a fixed label, not a generated string. If you are calling an LLM to extract intent from a support message, score urgency, or assign an owner - and those answers come from a defined list - a dedicated classifier is faster, cheaper, and less likely to drift off-schema than a prompted decoder. The tradeoff is that you lose fallback reasoning for inputs that do not fit any label.
Is GLiNER2.5-Decide suitable for private or air-gapped deployments?
Yes. The weights are available on Hugging Face under Apache 2.0, run locally via the gliner2 Python library, and never require a network call. A community Swift port also runs on Apple Silicon. That makes it viable for teams with strict data-residency requirements or workflows where text cannot leave the local machine.