dowands

NeoJev-Qwen3.8-27B-L56

README

License: apache-2.0

Quick start (NVIDIA GPU)

This repository is the CUDA build: the official Qwen/Qwen3.8-27B-FP8 checkpoint cut to its first 56 decoder layers (27 GB), plus the readout head and the inference code. It needs an FP8-capable GPU (Ada, Hopper or newer) with about 26 GB of memory. For Apple Silicon use dowands/NeoJev-Qwen3.8-27B-L56-MLX.

bash

pip install torch==2.11.0 transformers==5.16.1 kernels==0.16.0 flash-linear-attention causal-conv1d==1.7.0 acceleratehuggingface-cli download dowands/NeoJev-Qwen3.8-27B-L56 decider_cuda.py --local-dir .

python

from decider_cuda import Deciderd = Decider("dowands/NeoJev-Qwen3.8-27B-L56")         # downloads the weights and the readout head on first used.ask(    "Customer emailed twice about a failed refund for order #4417 and says they will dispute the charge tomorrow.",    {        "queue":   {"type": "choice", "options": ["Billing and Payments", "Technical Support", "Sales"],                    "prompt": "Which team should handle this ticket?"},        "urgency": {"type": "score", "levels": ["low", "medium", "high"], "prompt": "How urgent is it?"},        "churn":   {"type": "noul", "statement": "The customer is likely to leave."},    },)

The config.json here already has 56 layers and the gate_proj fix below. Plain transformers 5.16 still needs the small FP8 quantizer patch in decider_cuda.py (_patch_fp8_dense) to load a dense FP8 model. The answers come from decider_cuda.py's readout, not from generate().

decider_cuda.py works around two problems in transformers 5.16 with this checkpoint. Both are handled in code; if you port the method yourself, watch for them:

The FP8 quantizer crashes on dense models because it looks up an MoE experts setting.
More seriously, the official FP8 checkpoint's modules_to_not_convert lists MoE router names (...mlp.gate). These prefix-match the dense mlp.gate_proj, so every gate projection is loaded as raw FP8 bytes without its scales. The model then runs without errors but produces garbage. The config.json in this repository already has those entries removed.

Serving (TypeSafe-compatible API)

server.py exposes POST /v1/systemone in the TypeSafe request/response shape, so clients written for that API (and JevBench's TypeSafeAdapter) work unchanged:

bash

python server.py --backend cuda --model dowands/NeoJev-Qwen3.8-27B-L56 --port 8000curl -s localhost:8000/v1/systemone -H 'content-type: application/json' -d '{"state": "My card was charged twice.",  "questions": {"route": {"type": "choice", "instructions": "Which team?", "criteria": {"billing": "charges", "technical": "bugs"}}}}'

It serves one request at a time. --layout state_first (the default, used for the JevBench numbers) caches nothing; --layout schema_first caches the question prefix per schema (LRU, 64 schemas), which is faster when the same questions repeat.

Question types:

Table with columns: type, fields, returns
type	fields	returns
`choice`	`options` (2 to 16), `prompt`	the chosen option, per-option probabilities
`score`	`levels` (ordered), `prompt`	the chosen level, per-level probabilities, `expected_index`
`noul`

cache_schema=True (default) puts the questions first and caches them across calls with the same question set; use it when you ask the same questions about many texts. Use cache_schema=False for one-off questions whose options change every call (for example multiple-choice QA).

How it works

Layout. The questions are prefilled once per schema and cached. Each call only runs the state plus one short trigger per question (Q1:, Q2:, ...), all in a single forward pass. The answer for each question is read at its trigger position.
Early exit. Only the first 56 of the 64 decoder layers are kept (13.4 GB of weights instead of about 16 GB), which cuts compute by 12.5%.
Label-free readout head. Reading the option logits directly from layer 56 is poor (the plain "logit lens" gets 0.663 mean accuracy on our evaluation set). A small head, h + (h U) V + b + c[position] (rank 1024, followed by the model's own final norm and LM head), maps the layer-56 state to the option distribution. It was trained by self-distillation: the target is the full 64-layer model's option distribution in the original prompt layout, on 4,000 texts x randomly generated questions (10,035 questions). No labels are used, so the head is task-agnostic and you do not need any data to use it.
Calibration. One global temperature (T = 1.373), fitted once on public labels from the distillation sources.
Token budget. Each call is capped at 160 tokens by default; longer states keep their first 40% and last 60% of tokens.

Distillation sources (texts only, none overlap the evaluation tasks below): SetFit bbc-news, 20_newsgroups, enron_spam, subj, sst5, toxic_conversations, amazon_counterfactual_en, student-question-categories, CR, rte, mrpc, qnli; cais/mmlu; allenai/qasc; ehovy/race; openlifescienceai/medmcqa.

Evaluation

These 11 tasks are held out from training: none of their texts, questions or labels were used. There are 500 test items per task and 5,500 calls in total. The baseline is the same base model with all 64 layers, reading the option logits zero-shot in the natural layout (state first, one question at a time).

Table with columns: task / question, baseline acc / ECE, this model acc / ECE
task / question	baseline acc / ECE	this model acc / ECE
customer-support-tickets / queue (10-way)	0.264 / 0.480	0.322 / 0.060
customer-support-tickets / priority	0.420 / 0.341	0.380 / 0.251
customer-support-tickets / type	0.584 / 0.207	0.454 / 0.138
yelp_review_full / stars (1-5)	0.592 / 0.240	0.534 / 0.079
yelp_review_full / 4-5 stars (yes/no)	0.916 / 0.020	0.850 / 0.189
ag_news / topic

The mean accuracy is 2.7 points lower than the baseline (paired bootstrap 95% CI: -3.6 to -1.9).

NVIDIA backend (same 11 tasks, 500 items each, Qwen/Qwen3.8-27B-FP8 with the first 56 layers, NVIDIA L20 48 GB, torch 2.11 + cu128, transformers 5.16.1, flash-linear-attention, causal-conv1d): mean accuracy 0.724, mean ECE 0.103, latency median 107 ms / p90 132 ms / p99 133 ms, 99.96% of calls under 500 ms, peak GPU memory 25.8 GB. Two of the 5,500 calls took 9 to 14 s, most likely Triton autotuning on a new input shape. With a 1,000-token budget (no truncation) the accuracy was 0.724 and p99 208 ms, so the 160-token default costs almost nothing here.

Latency was measured on an Apple M5 Pro with 64 GB, MLX 0.32.2 and mlx-lm 0.31.3, one call at a time, with a remote-desktop session running during the measurement:

Table with columns: median, p90, p99, under 500 ms
	median	p90	p99	under 500 ms
baseline (64 layers, natural layout)	560 ms
this model	310 ms	475 ms	571 ms	93.2%

Latency is roughly linear in tokens per call. Short texts (tweets, one-line tickets) take 180 to 300 ms; the 160-token cap is what keeps long texts near 500 ms. Lower token_budget if you need a hard ceiling. Background GPU load (screen sharing, other ML jobs) moves these numbers noticeably, because the display and the model share the GPU.

How it compares

All methods were run on the same machine and the same held-out items (the first 200 test items of each of the 11 tasks, 14 questions, 2,200 calls). Accuracy is averaged over the 14 questions.

Table with columns: method, mean accuracy, mean ECE, median latency per call, format errors
method	mean accuracy	mean ECE	median latency per call	format errors
Qwen3.8-27B, all 64 layers, option logits (upper reference)	0.745	0.160	563 ms	0%
this model	0.721	0.117	310 ms	0% (by construction)
Qwen3-Embedding-8B, similarity to each option	0.599	0.165	3,472 ms*

A second comparison adds the way most people use an LLM for this, which is to ask the full model to write a JSON answer. That is slower, so it ran on the first 100 items per task:

Table with columns: method (100 items/task), mean accuracy, median latency, format errors
method (100 items/task)	mean accuracy	median latency	format errors
Qwen3.8-27B, 64 layers, writes JSON (greedy, thinking off)	0.739	1,757 ms	0%
Qwen3.8-27B, 64 layers, option logits	0.736	562 ms	0%
this model	0.711	309 ms	0%

Reading the tables:

This model is 2.4 to 2.8 points below the full model (depending on the item subset; 2.7 on all 500 items per task), and 5.7 times faster than asking the full model for JSON.
It is 12 to 23 points above the other models that fit on a laptop and answer arbitrary questions zero-shot.
The customer-support-tickets labels are synthetic and noisy: every method sits near the majority baseline there.
bart-large-mnli was used through the generic zero-shot pipeline (options as labels in a template), not its native NLI format, so its MNLI score (0.33) does not reflect its NLI ability.

* The embedding baseline was served by a local llama.cpp server (Q4_K_M), one request per call; its latency is not optimized.

On standard public benchmarks within the held-out set (500-item zero-shot subsets, this model): ARC-Challenge 0.962, OpenBookQA 0.908, CommonsenseQA 0.804, SciQ 0.992, BoolQ 0.804, MNLI 0.838, AG News 0.874. These are not comparable to leaderboard numbers that use few-shot prompts, chain of thought or the full test sets.

Compared with other open Jev-style models (JevBench)

JevBench (MIT, Benchmark Heaven) is the independent benchmark most Jev-class projects report on. We ran NeoJev on its 231 public items the way JevBench runs TypeSafe-compatible systems: JevBench's own, unmodified TypeSafeAdapter sent every item to NeoJev's server.py, and JevBench's scoring code graded the answers (jevbench_via_server.py in this repo). The table below compares NeoJev with widely used open peers that JevBench measured. Peer numbers come from JevBench's published v1.4 results (repo commit 26eb72d, 24 Sep 2026).

Table with columns: system, base, weights (memory), public accuracy (231), p50 / p95 latency, where the latency was measured
system	base	weights (memory)	public accuracy (231)	p50 / p95 latency	where the latency was measured
NeoJev (this model), CUDA	Qwen3.8-27B, 56 layers	25.8 GB peak GPU (FP8)	0.861	0.132 / 1.33 s	NVIDIA L20, local HTTP, serial
NeoJev (this model), MLX	Qwen3.8-27B, 56 layers	13.4 GB (4-bit)	0.853	0.52 / 9.7 s	Apple M5 Pro, local HTTP, serial

How to read it:

Accuracy. On the public items NeoJev (0.861 CUDA, 0.853 MLX) is close to Jev 1.13.0 (0.866) and to the other Qwen3.8-27B systems (0.862 to 0.870). It is above the small models in the table (0.58 to 0.85; decider-2b 0.71, JevK5 0.85). Among open systems, only JevOne and NInfer Qwen3.8-Flash-Next (both 0.896, on 35B-class MoE models) and thinking-mode systems score higher. Frontier APIs (GPT, DeepSeek, Gemini) score higher as well.
Speed and memory. Among the 27B-class systems, NeoJev's p50 is 0.13 s on an L20. SimpleJev and reflex-27b show 1.0 s and 1.9 s in JevBench's runs (with a network hop, on other hardware, so treat this as an order of magnitude only). NeoJev also needs about half the memory of a BF16 27B, because it runs 56 of 64 layers of the FP8 checkpoint. Its p95 is dominated by the long documents of the hard tier; the easy and standard tiers take 0.11 s.
Option order matters. JevBench sends each choice question's options as a label-to-description map sorted by label, and NeoJev keeps the order it receives. When the options were instead put in each item's label order, NeoJev scored 0.866 (CUDA) and 0.870 (MLX); of the 119 choice items whose two orders differ, 8 flipped on MLX and 5 on CUDA. The table uses the JevBench path. Small or frozen decision models are generally order-sensitive, and JevBench documents this for other entrants too.
Latency is not directly comparable across rows. Many JevBench rows include a network round trip from JevBench's server, and every row ran on different hardware.
This is not the official JevBench score. The official score also needs the held-out and sealed items (which only JevBench runs; v1.4 adds 308 fresh sealed decisions), a judge tier, calibration and a cost figure.
Where the memory figures come from. They are the published repository size where one exists (decider-2b, JevK5); otherwise they are an estimate of parameters × precision, marked "est.".

Limitations

2.7 points below the full model on average, and worse on some questions: up to -13 points on the third question of a three-question schema (customer-support-tickets / type). Questions placed third or later in one call read less reliably, and answers change with question order (the same question can get a different confidence in position 1 and position 2). Keep the order fixed for a given use case, put the most important question first, or split long schemas across calls.
Yes/no statements are weaker than multiple choice in this layout (-5 to -7 points on boolq and yelp 4-5 stars).
Calibration is not uniform. The mean ECE is 0.114, but some questions sit at 0.19 to 0.25. If you have a few hundred labelled examples for your task, fit your own temperature on them.
Choice questions support at most 16 options. The model was evaluated on English only.
Long inputs are truncated to the token budget, so detail in the middle of a long text is lost.
Needs Apple Silicon (MLX, about 15 GB of free unified memory) or an FP8-capable NVIDIA GPU with about 26 GB of memory. On the NVIDIA side the FP8 kernel path was tested on an L20 (Ada) only.

License

Apache-2.0, derived from Qwen/Qwen3.8-27B (Apache-2.0) via mlx-community/Qwen3.8-27B-4bit. See LICENSE_NOTICE.md.

Available on FriendliAI

Dedicated Endpoints

Run this model inference on single tenant GPU with unmatched speed and reliability at scale.

Learn more

Model Details

Model Provider

dowands

Model Tree

Base

Qwen/Qwen3.8-27B-FP8

Quantized

this model

Input Modalities

TextImageVideo

Output Modalities

Text

Supported Functionality

Dedicated Endpoints

Explore FriendliAI today

Get started Talk to an engineer

README

License: apache-2.0

Quick start (NVIDIA GPU)

bash

pip install torch==2.11.0 transformers==5.16.1 kernels==0.16.0 flash-linear-attention causal-conv1d==1.7.0 acceleratehuggingface-cli download dowands/NeoJev-Qwen3.8-27B-L56 decider_cuda.py --local-dir .

python

from decider_cuda import Deciderd = Decider("dowands/NeoJev-Qwen3.8-27B-L56")         # downloads the weights and the readout head on first used.ask(    "Customer emailed twice about a failed refund for order #4417 and says they will dispute the charge tomorrow.",    {        "queue":   {"type": "choice", "options": ["Billing and Payments", "Technical Support", "Sales"],                    "prompt": "Which team should handle this ticket?"},        "urgency": {"type": "score", "levels": ["low", "medium", "high"], "prompt": "How urgent is it?"},        "churn":   {"type": "noul", "statement": "The customer is likely to leave."},    },)

decider_cuda.py works around two problems in transformers 5.16 with this checkpoint. Both are handled in code; if you port the method yourself, watch for them:

The FP8 quantizer crashes on dense models because it looks up an MoE experts setting.
More seriously, the official FP8 checkpoint's modules_to_not_convert lists MoE router names (...mlp.gate). These prefix-match the dense mlp.gate_proj, so every gate projection is loaded as raw FP8 bytes without its scales. The model then runs without errors but produces garbage. The config.json in this repository already has those entries removed.

Serving (TypeSafe-compatible API)

server.py exposes POST /v1/systemone in the TypeSafe request/response shape, so clients written for that API (and JevBench's TypeSafeAdapter) work unchanged:

bash

python server.py --backend cuda --model dowands/NeoJev-Qwen3.8-27B-L56 --port 8000curl -s localhost:8000/v1/systemone -H 'content-type: application/json' -d '{"state": "My card was charged twice.",  "questions": {"route": {"type": "choice", "instructions": "Which team?", "criteria": {"billing": "charges", "technical": "bugs"}}}}'

Question types:

Table with columns: type, fields, returns
type	fields	returns
`choice`	`options` (2 to 16), `prompt`	the chosen option, per-option probabilities
`score`	`levels` (ordered), `prompt`	the chosen level, per-level probabilities, `expected_index`
`noul`

How it works

Layout. The questions are prefilled once per schema and cached. Each call only runs the state plus one short trigger per question (Q1:, Q2:, ...), all in a single forward pass. The answer for each question is read at its trigger position.
Early exit. Only the first 56 of the 64 decoder layers are kept (13.4 GB of weights instead of about 16 GB), which cuts compute by 12.5%.
Label-free readout head. Reading the option logits directly from layer 56 is poor (the plain "logit lens" gets 0.663 mean accuracy on our evaluation set). A small head, h + (h U) V + b + c[position] (rank 1024, followed by the model's own final norm and LM head), maps the layer-56 state to the option distribution. It was trained by self-distillation: the target is the full 64-layer model's option distribution in the original prompt layout, on 4,000 texts x randomly generated questions (10,035 questions). No labels are used, so the head is task-agnostic and you do not need any data to use it.
Calibration. One global temperature (T = 1.373), fitted once on public labels from the distillation sources.
Token budget. Each call is capped at 160 tokens by default; longer states keep their first 40% and last 60% of tokens.

Evaluation

Table with columns: task / question, baseline acc / ECE, this model acc / ECE
task / question	baseline acc / ECE	this model acc / ECE
customer-support-tickets / queue (10-way)	0.264 / 0.480	0.322 / 0.060
customer-support-tickets / priority	0.420 / 0.341	0.380 / 0.251
customer-support-tickets / type	0.584 / 0.207	0.454 / 0.138
yelp_review_full / stars (1-5)	0.592 / 0.240	0.534 / 0.079
yelp_review_full / 4-5 stars (yes/no)	0.916 / 0.020	0.850 / 0.189
ag_news / topic

The mean accuracy is 2.7 points lower than the baseline (paired bootstrap 95% CI: -3.6 to -1.9).

Latency was measured on an Apple M5 Pro with 64 GB, MLX 0.32.2 and mlx-lm 0.31.3, one call at a time, with a remote-desktop session running during the measurement:

Table with columns: median, p90, p99, under 500 ms
	median	p90	p99	under 500 ms
baseline (64 layers, natural layout)	560 ms
this model	310 ms	475 ms	571 ms	93.2%

How it compares

All methods were run on the same machine and the same held-out items (the first 200 test items of each of the 11 tasks, 14 questions, 2,200 calls). Accuracy is averaged over the 14 questions.

Table with columns: method, mean accuracy, mean ECE, median latency per call, format errors
method	mean accuracy	mean ECE	median latency per call	format errors
Qwen3.8-27B, all 64 layers, option logits (upper reference)	0.745	0.160	563 ms	0%
this model	0.721	0.117	310 ms	0% (by construction)
Qwen3-Embedding-8B, similarity to each option	0.599	0.165	3,472 ms*

A second comparison adds the way most people use an LLM for this, which is to ask the full model to write a JSON answer. That is slower, so it ran on the first 100 items per task:

Table with columns: method (100 items/task), mean accuracy, median latency, format errors
method (100 items/task)	mean accuracy	median latency	format errors
Qwen3.8-27B, 64 layers, writes JSON (greedy, thinking off)	0.739	1,757 ms	0%
Qwen3.8-27B, 64 layers, option logits	0.736	562 ms	0%
this model	0.711	309 ms	0%

Reading the tables:

This model is 2.4 to 2.8 points below the full model (depending on the item subset; 2.7 on all 500 items per task), and 5.7 times faster than asking the full model for JSON.
It is 12 to 23 points above the other models that fit on a laptop and answer arbitrary questions zero-shot.
The customer-support-tickets labels are synthetic and noisy: every method sits near the majority baseline there.
bart-large-mnli was used through the generic zero-shot pipeline (options as labels in a template), not its native NLI format, so its MNLI score (0.33) does not reflect its NLI ability.

* The embedding baseline was served by a local llama.cpp server (Q4_K_M), one request per call; its latency is not optimized.

Compared with other open Jev-style models (JevBench)

Table with columns: system, base, weights (memory), public accuracy (231), p50 / p95 latency, where the latency was measured
system	base	weights (memory)	public accuracy (231)	p50 / p95 latency	where the latency was measured
NeoJev (this model), CUDA	Qwen3.8-27B, 56 layers	25.8 GB peak GPU (FP8)	0.861	0.132 / 1.33 s	NVIDIA L20, local HTTP, serial
NeoJev (this model), MLX	Qwen3.8-27B, 56 layers	13.4 GB (4-bit)	0.853	0.52 / 9.7 s	Apple M5 Pro, local HTTP, serial

How to read it:

Accuracy. On the public items NeoJev (0.861 CUDA, 0.853 MLX) is close to Jev 1.13.0 (0.866) and to the other Qwen3.8-27B systems (0.862 to 0.870). It is above the small models in the table (0.58 to 0.85; decider-2b 0.71, JevK5 0.85). Among open systems, only JevOne and NInfer Qwen3.8-Flash-Next (both 0.896, on 35B-class MoE models) and thinking-mode systems score higher. Frontier APIs (GPT, DeepSeek, Gemini) score higher as well.
Speed and memory. Among the 27B-class systems, NeoJev's p50 is 0.13 s on an L20. SimpleJev and reflex-27b show 1.0 s and 1.9 s in JevBench's runs (with a network hop, on other hardware, so treat this as an order of magnitude only). NeoJev also needs about half the memory of a BF16 27B, because it runs 56 of 64 layers of the FP8 checkpoint. Its p95 is dominated by the long documents of the hard tier; the easy and standard tiers take 0.11 s.
Option order matters. JevBench sends each choice question's options as a label-to-description map sorted by label, and NeoJev keeps the order it receives. When the options were instead put in each item's label order, NeoJev scored 0.866 (CUDA) and 0.870 (MLX); of the 119 choice items whose two orders differ, 8 flipped on MLX and 5 on CUDA. The table uses the JevBench path. Small or frozen decision models are generally order-sensitive, and JevBench documents this for other entrants too.
Latency is not directly comparable across rows. Many JevBench rows include a network round trip from JevBench's server, and every row ran on different hardware.
This is not the official JevBench score. The official score also needs the held-out and sealed items (which only JevBench runs; v1.4 adds 308 fresh sealed decisions), a judge tier, calibration and a cost figure.
Where the memory figures come from. They are the published repository size where one exists (decider-2b, JevK5); otherwise they are an estimate of parameters × precision, marked "est.".

Limitations

2.7 points below the full model on average, and worse on some questions: up to -13 points on the third question of a three-question schema (customer-support-tickets / type). Questions placed third or later in one call read less reliably, and answers change with question order (the same question can get a different confidence in position 1 and position 2). Keep the order fixed for a given use case, put the most important question first, or split long schemas across calls.
Yes/no statements are weaker than multiple choice in this layout (-5 to -7 points on boolq and yelp 4-5 stars).
Calibration is not uniform. The mean ECE is 0.114, but some questions sit at 0.19 to 0.25. If you have a few hundred labelled examples for your task, fit your own temperature on them.
Choice questions support at most 16 options. The model was evaluated on English only.
Long inputs are truncated to the token budget, so detail in the middle of a long text is lost.
Needs Apple Silicon (MLX, about 15 GB of free unified memory) or an FP8-capable NVIDIA GPU with about 26 GB of memory. On the NVIDIA side the FP8 kernel path was tested on an L20 (Ada) only.

License

Apache-2.0, derived from Qwen/Qwen3.8-27B (Apache-2.0) via mlx-community/Qwen3.8-27B-4bit. See LICENSE_NOTICE.md.