Qwen3.8-Flash-Next, EXL3 packs for mlx-serve

Each branch of this repo holds one of turboderp's EXL3 quantizations of Qwen3.8-Flash-Next, repacked into the file layout that mlx-serve loads on Apple silicon. turboderp made them with exllamav3 and publishes them in turboderp/Qwen3.8-Flash-Next-exl3. The quantizations are his and nothing is quantized again, so please credit turboderp when you use them. mlx-serve serves them with the turboexl3_qwen38 model plugin, or with full-EXL3 support for Qwen3.8 and the turboexl3 quant plugin, the route the packs were first measured on. The experts load into memory, while the n-gram table, 26 to 39 GB depending on the branch, stays on SSD and is read per token, so it costs disk and file cache rather than memory. Each bitrate is a branch, and main holds only this card and the license.

Branches

Sizes are in GB, where 1 GB is 10^9 bytes. The branches do not include the n-gram table, and The n-gram table says where each one comes from. KLD and PPL are turboderp's, measured with exllamav3 on his files, as Quality explains. Each branch's card says what is in its pack, where each file comes from and how to run it with mlx-serve.

Related repositories

Each branch holds its earlier repo's files, without ngram_embedding.safetensors and with a new card.

How to download and run

Requirements

The packs can be served in two ways. The first is the turboexl3_qwen38 model plugin. The second is the route the packs were first measured on, and every speed table on this card comes from it.

We tested these packs on one Apple M5 Max with 128 GB of memory and did not test other Macs. We tested text only, not image or video input. The packs do not load in exllamav3, transformers, vLLM, SGLang or mlx-lm. For exllamav3, use turboderp's repository.

The turboexl3_qwen38 model plugin

The main branch of CommunityServe/plugins has the turboexl3_qwen38 model plugin, which serves these four packs. Its source is in plugins/turboexl3_qwen38. It claims a qwen4_exp pack only when the pack's config has a trunk_quant block, as these packs' config.json does.

The plugin needs mlx-serve 26.11.1 or later and an M5-class GPU (NAX), and it refuses any other GPU by name at load. MTP needs mlx-serve with ddalcu/mlx-serve#1017, which is merged. Without it, serve with --no-mtp.

The plugin is built with scripts/build.sh turboexl3_qwen38 from the root of CommunityServe/plugins, and the plugin's README gives the build steps. The repo README and docs/using-plugins.md cover installing a plugin and turning it on.

qwen38-exl3-full and the turboexl3 quant plugin

The packs were first measured on this route, which takes two parts.

The first part is mlx-serve with full-EXL3 support for Qwen3.8, which means the trunk_quant block, the EXL3 n-gram table and the EXL3 MTP head. That support is the branch qwen38-exl3-full of davidtai/mlx-serve, the head of ddalcu/mlx-serve#997 before that pull request became the host support of the qwen38_exl3 model plugin.

The second part is the turboexl3 quant plugin. It is required, because it claims the pack's expert_quant and trunk_quant blocks. Build it from the plugin/ directory of davidtai/turboexl3.

Download a branch

Pass the branch name to --revision. This command downloads 5.05bpw, and the steps below continue with it:

hf download OpensourceWTF/Qwen3.8-Flash-Next-exl3 --revision 5.05bpw --local-dir ~/models/Qwen3.8-Flash-Next-EXL3-5.05-mlx-serve

Each branch's card gives the same steps with its own folder name.

The n-gram table

The branches do not include ngram_embedding.safetensors, the n-gram table, and each pack needs it in its folder. mlx-serve maps the file and reads the rows each token needs, so the table costs disk space and OS file cache, not resident memory.

For 4.05bpw and 5.05bpw, the table is turboderp's file, unchanged. Download ngram_embedding.safetensors from turboderp/Qwen3.8-Flash-Next-exl3 at branch 4.05bpw_h6_ng6 or 5.05bpw_h6_ng6 and put it in the pack folder as it is. Both branches ship the same file, with sha256 c63613666649014e668cdbd32a4e3f1e8beda697eb4f3a1874300d93a1bfbc75 and a size of 39,040,193,720 B. For the 5.05bpw folder above, these commands fetch the file and check it:

hf download turboderp/Qwen3.8-Flash-Next-exl3 ngram_embedding.safetensors --revision 5.05bpw_h6_ng6 \
  --local-dir ~/models/Qwen3.8-Flash-Next-EXL3-5.05-mlx-serve
shasum -a 256 ~/models/Qwen3.8-Flash-Next-EXL3-5.05-mlx-serve/ngram_embedding.safetensors
#   expected: c63613666649014e668cdbd32a4e3f1e8beda697eb4f3a1874300d93a1bfbc75 (39,040,193,720 B)

For 2.05bpw and 3.05bpw, turboderp stores the table as 128 row shards in his ngram_embedding.safetensors, on branches 2.05bpw_h4_ng4 and 3.05bpw_h5_ng5. mlx-serve reads one tensor, so the converter makes the pack's table from his file. The converter's scripts/restack_exl3_q2_full.py, in its --phase finalize with --ngram <his file>, clones the file with APFS clonefile, so no data is copied, and rewrites only its header to name the same bytes as one tensor. The converter README describes this in "What the conversion does", in the n-gram table bullet.

Our results are a 3.05 table of 32,640,183,408 B (sha256 f7fa0ddfe932…) and a 2.05 table of 26,240,152,672 B (sha256 1f5d5d099b46…). Each branch's card has the exact steps.

Build the turboexl3 quant plugin and start the server

For the second way, build mlx-serve with the support listed in Requirements and its plugin kit, then build the turboexl3 plugin from plugin/:

# in the mlx-serve checkout
zig build -Doptimize=ReleaseFast
zig build kit      # stages zig-out/kit/mlx-serve-plugin-kit-<version>/

# in a checkout of github.com/davidtai/turboexl3
cd plugin
ln -s <mlx-serve checkout>/zig-out/kit/mlx-serve-plugin-kit-<version> kit
zig build          # writes zig-out/lib/libturboexl3.dylib
mlx-serve plugin check zig-out/lib/libturboexl3.dylib --model ~/models/Qwen3.8-Flash-Next-EXL3-5.05-mlx-serve
#   expected: claims expert_quant (by_marker), trunk_quant (by_marker)
mlx-serve plugin install zig-out/lib/libturboexl3.dylib
# then set "enabled": true in ~/.mlx-serve/plugins.json

Then start the server:

MLX_SERVE_NOCACHE_LOAD=1 mlx-serve --model ~/models/Qwen3.8-Flash-Next-EXL3-5.05-mlx-serve --serve

MLX_SERVE_NOCACHE_LOAD=1 reads the shards past the OS file cache, so the load does not also fill memory with cached copies of the shards. Our measurements used it.

The default numerics use turboexl3's kernels, which reorder some sums. MLX_SERVE_BIT_EXACT=1 selects exact numerics: the routed experts run on Sushi, the EXL3 kernels built into mlx-serve, and no sum is reordered. The two modes give different text.

turboexl3 runs the routed experts only on an Apple M5 or later with macOS 26.2 or later. On other Macs, the plugin leaves the routed experts to Sushi, but we did not test this.

The plugin links no MLX of its own, so the MLX version of the kit must be the same as the server's.

Quality

The KLD and PPL columns are turboderp's. They are the mean KL divergence D_KL(p_BF16 ‖ p_quant) and the perplexity over a self-generated in-domain trace of 14,496 input and 45,588 output tokens, measured by turboderp with exllamav3 on his files. On that trace BF16 has a perplexity of 1.38474, and the KLD noise floor is 0.00262. The packs hold his quantized bytes, but these numbers were not measured through mlx-serve.

The EvalPlus columns are our end-to-end check through mlx-serve: EvalPlus on each pack, greedy pass@1, with the number of problems passed in parentheses. The setup is in the coding evals of turboexl3's results.

The charts below are turboderp's, linked from his model card. In them, the EXL3 series is his plain quants, and our packs are its 2.05, 3.05, 4.05 and 5.05 points. EXL3-SC is his self-calibrated quants, and the other series are other formats he measured.

Speed

The speed tables were measured on one Apple M5 Max with 128 GB under macOS 27.0.1. The server was our mlx-serve tree with turboexl3, before its port to the current mlx-serve, on two builds. 5.05bpw ran on build S21, which is build PR17B plus the later decode optimizations that the branch qwen38-exl3-full ports, at MTP depth 4. 4.05bpw, 3.05bpw and 2.05bpw ran on build PR17B at MTP depth 3, and they were not re-measured on build S21. Compare branches within one build only. These tables come from the second way that Requirements describes, not from the turboexl3_qwen38 plugin.

How the speed was measured

Each cell is one run, with no repeats. For each prompt length and mode, a warm-up server first ran the prompt for one token, which puts the prompt's n-gram rows into the OS file cache. Then the other pack files were evicted from the cache, a new server started, the SoC cooled below 40 °C, and one request ran.

The request was the prompt as one user message in Qwen's chat template with thinking on, greedy (temperature 0), with seed 1234 and at most 1,024 new tokens. The prompts are fixed texts, Python source code with one coding task, and they are the same bytes for every pack and mode.

The server flags were --ctx-size 262144 --max-concurrent 1 --mtp-max-depth 3 --mtp-typical 0.2 --prefix-cache-mem 1GB, with --mtp-max-depth 4 on build S21. The environment variables were MLX_SERVE_GPU_CEILING_MB=114688, MLX_SERVE_CACHE_LIMIT=2147483648, MLX_SERVE_NOCACHE_LOAD=1 and MLX_SERVE_NGRAM_WARM=0.

The prefill and decode rates come from the server's log line for the request. TTFT is the client's time from sending the request to the first streamed token. Peak memory is the server's peak phys_footprint, which includes Metal memory but not the file cache of the n-gram table.

turboexl3 reorders sums, so the two modes give different answers. With MTP, their decode rates also depend on how many drafts each answer accepts.

In the tables, "turboexl3" is the default numerics and "exact" is MLX_SERVE_BIT_EXACT=1. Prefill and decode are in tokens per second, and * marks a run whose answer reached the 1,024-token cap.

Build PR17B, MTP depth 3: 4.05bpw, 3.05bpw and 2.05bpw

None of the 18 runs of 4.05bpw reached the cap, against one of 18 for 3.05bpw and one of 18 for 2.05bpw.

Prefill, tok/s

Decode, tok/s

TTFT, s

Peak memory, GiB, turboexl3

Build S21, MTP depth 4: 5.05bpw

Three of the 18 runs reached the cap. At 256K the server narrowed its prefill chunk to 4,096 tokens, against 8,192 at the other lengths.

Serial decode

The serial-decode runs used --no-mtp in place of the two MTP flags and the same method otherwise. Four of the 18 runs reached the cap.

How the packs were made

In every branch, the quantized weights are turboderp's bytes, rearranged into mlx-serve's file layout. The n-gram table is his too, but it is not in the branches, as The n-gram table explains. The unquantized f16 tensors were rounded and are stored as bf16.

Three files are ours: the carry shard (trunk-exl3-carry.safetensors), config.json and model.safetensors.index.json. The vision shard (trunk-model-vision.safetensors) and the small files come from our earlier pack.

The conversion scripts do the repack, and each branch's card lists every file with its source and the change made to it.

Credits

The model, the tokenizer, the chat template and the license are Qwen's. turboderp made the EXL3 quantizations that these packs are made from, with exllamav3. EXL3 is based on QTIP by Cornell RelaxML.

ddalcu wrote mlx-serve and its Qwen3.8 model code, and made Sushi, the EXL3 kernels built into mlx-serve. The pack ddalcu/Qwen3.8-Flash-Next-MLX-Serve-mixed-4-8bit is the source of the packs' vision tower and base config.

turboexl3 provides the EXL3 Metal kernels of the default mode. The conversion scripts are OpenSourceWTF/qwen38-exl3-mlx-serve-converter.

License

The weights are derived from Qwen3.8-Flash-Next and stay under the Qwen Community License 1.0. That license is the LICENSE file, the same as in Qwen's repository, and turboderp's and ddalcu's repositories use the same license.

The LICENSE file is the license, and what follows is only a short summary of it. Keep the copyright notice and the permission notice with every copy. A commercial product or service that uses the model and has more than 100,000,000 monthly active users, or more than US$20,000,000 monthly revenue, must show the model name in its user interface.

A licensee that runs, or whose affiliate runs, a "Model as a Service" or "AI Work Assistant" business (as the license defines them) needs a separate license from Qwen before any commercial use. Internal use that gives third parties no access to the model, its outputs or its capabilities does not need one. There is no warranty.

The code (mlx-serve, Sushi, turboexl3, exllamav3 and the conversion scripts) has its own licenses.