Downloads · 30 days
385
55% of all-time downloads
munekazu/Qwen3.8-Flash-Next-exl3-CMP170HX-64GB
Qwen3.8-Flash-Next-exl3-CMP170HX-64GB is a image-text-to-text model from munekazu. Use it for the image-text-to-text task on the model card, and read the license before you ship it in a product. The card lists the license as other.
A single unlocked NVIDIA CMP 170HX 8GB (64 GB of VRAM) runs the full 262,144-token context with MTP speculative decoding, filling the card's VRAM to the last few hundred MiB.
Downloads · 30 days
385
55% of all-time downloads
All-time downloads
698
Public
Parameters
49.2B
98.6 GB on disk
Likes
10
Trending 1
Click a slice to open those files.
.safetensors98.5 GB · 100%
How the weights are stored.
I1647.5B · 96%
From the Hugging Face model README
A single unlocked NVIDIA CMP 170HX 8GB (64 GB of VRAM) runs the full 262,144-token context with MTP speculative decoding, filling the card's VRAM to the last few hundred MiB.
Mixed-bitrate EXL3 built from turboderp's EXL3 quants of Qwen3.8-Flash-Next: 4-bit routed experts on 20 of the 48 layers, 3-bit on the rest, 6-bit attention, shared experts and lm_head (details below). Requires ExLlamaV3 v1.5.1 or newer.
All measured on the machine described below, with the TabbyAPI config in this repo (one stream, MTP draft 3, 8-bit K/V cache, 262,144-token cache).
Full context — prompt = the first N tokens of wikitext-2 (test) + a summarization request, fresh prompt each time (no prefix cache), greedy, thinking off, up to 500 new tokens:
| Context | Prompt processing | Generation | MTP acceptance |
|---|---|---|---|
| 16,437 | 1,481 tok/s | 87.8 tok/s | 67% |
| 65,589 | 1,601 tok/s | 85.5 tok/s | 67% |
| 131,125 | 1,680 tok/s | 85.7 tok/s | 70% |
| 250,053 | 1,653 tok/s | 79.2 tok/s | 68% |
Short context — 500 new tokens, greedy, thinking off (median of 3 after 1 warm-up):
| tok/s | |
|---|---|
| Generation, code (a Python module) | 99.9 |
| Generation, prose (an essay) | 81.4 |
| Prompt processing, 16k tokens (synthetic word-list prompt) | 2,013 |
Greedy, thinking off. HumanEval code is run against its tests; GSM8K is scored on the final number.
| Benchmark | Score |
|---|---|
| HumanEval (base tests) | 157 / 164 (95.7%) |
| HumanEval+ (base + extra tests) | 152 / 164 (92.7%) |
| GSM8K (first 300 test problems) | 293 / 300 (97.7%) |
No new quantization. ExLlamaV3 stores every linear layer independently and reads its bitrate from the tensor shape, so tensors from two conversions of the same source model can be combined module by module. This repo takes:
| Part | Bits | Source branch |
|---|---|---|
| Attention, linear attention, shared experts, lm_head | 6 | 4.05bpw_h6_ng6 |
| Sparse-attention indexer | 4 | 4.05bpw_h6_ng6 |
| Routed experts, layers 0–9 and 38–47 | 4 | 4.05bpw_h6_ng6 |
| Routed experts, layers 10–37 | 3 | 3.05bpw_h5_ng5 |
| MTP head | 4–6 | 4.05bpw_h6_ng6 |
| Vision tower | 6 | 4.05bpw_h6_ng6 |
| n-gram (PLE) table, 39 GB | K=6 | 4.05bpw_h6_ng6 |
The 4-bit layers follow ExLlamaV3's own promotion order (closest to either end of the stack first). Experts
average 3.43 bpw. Only the tensors needed were fetched from turboderp's repo with HTTP range requests and
written straight into per-layer shards (experts-LNN.safetensors, dense.safetensors, …), so a different layer
choice is a one-file swap. The script and the exact recipe are in recipe/ — pick your own number of
4-bit layers for a different VRAM budget with build_mix.py.
recipe/tabbyapi-config.yml is the config every number above was measured with.
It uses the sampling defaults in recipe/sampler-override-flash-next.yml
(temperature 1.0, top_p 0.95, top_k 20, min_p 0, for thinking mode); copy that file to TabbyAPI's
sampler_overrides/flash-next.yml. The parts that matter:
model:
max_seq_len: 262144
cache_size: 262144
cache_mode: "8,8"
chunk_size: 2048
max_batch_size: 1
ngram_ram: false
vision: true
vision_offload: true
draft_model:
draft_mode: mtp
draft_cache_mode: "8,8"
draft_num_tokens: 3
MTP draft length, measured in a separate run (20 × 4-bit, one stream, 500 tokens, greedy):
draft_num_tokens | code (tok/s) | prose (tok/s) |
|---|---|---|
| 2 | 93.8 | 81.2 |
| 3 | 102.7 | 83.5 |
| 4 (model default) | 99.4 | 72.8 |
In ExLlamaV3's own example scripts the same settings are -cs 262144 -cq 8 -mtp -ndt 3.
By default the 39 GB n-gram table stays on disk, and only the rows each token needs are read, in parallel. The OS
keeps what has been read in free RAM (page cache), so frequently used rows come from RAM and you do not need enough
RAM to hold the whole table. To keep all 39 GB in RAM, use ngram_ram: true (TabbyAPI) or -ngr / --ngram_ram
(ExLlamaV3 scripts), which is slightly faster.
6b84a21), TabbyAPI main 7208273The card reports compute capability 8.0, so build for sm_80. With GCC 16, PyTorch 2.9's headers fail to compile
through nvcc (need 'typename' before ... in List_inl.h); GCC 15 plus -fpermissive works:
CC=gcc-15 CXX=g++-15 CUDAHOSTCXX=g++-15 \
NVCC_APPEND_FLAGS="-Xcompiler=-fpermissive" \
TORCH_CUDA_ARCH_LIST="8.0" \
python setup.py build_ext --inplace
recipe/.vision_offload: true) to leave its VRAM to the experts.