license: apache-2.0
base_model: orcarouter/Qwen3.8-Flash-Next-Uncensored
library_name: gguf
tags:
- gguf
- qwen4exp
- qwen3.8-flash-next
- uncensored
- mtp
- speculative-decoding
- ud-q4_k_xl
- imatrix
- text-generation
- chinese
- english
- 4-bit
pipeline_tag: text-generation
Qwen3.8-Flash-Next-Uncensored-UD-Q4_K_XL
为 AMD Ryzen AI Max+ 395 / Strix Halo 平台手工量化的 Qwen3.8-Flash-Next 越狱版
UD-Q4_K_XL 风格量化,主干 + MTP draft head + 视觉塔,一套文件同时喂给 Halogen 和 Gufo。
为什么做这个量化
我的主力机器是 AMD Ryzen AI Max+ 395(Strix Halo 架构,128 GB LPDDR5X 统一内存)。
这块 APU 的 iGPU 与 CPU 共享同一片 128 GB 内存,没有传统意义上的独立显存,
所以它是目前少数能完整驻留 100 GB 级模型的消费级平台。
在这台机器上我主要用两个引擎跑 Qwen3.8-Flash-Next:
两个引擎都以 GGUF 为输入。但当时可用的 GGUF 发行版(官方 Unsloth UD-Q4_K_XL)是审查版,
而社区上的越狱权重 orcarouter/Qwen3.8-Flash-Next-Uncensored 只发布了 BF16 safetensors,
没有对应的 GGUF —— 于是出现了「引擎能跑、但没有可用的越狱版 GGUF」的空档。
这个仓库就是填这个空档的产物:把那份越狱 BF16 权重按官方 UD-Q4_K_XL 的规格量化成 GGUF,
补上 MTP draft head 和视觉塔,让 Halogen 和 Gufo 都能直接加载,
在这台机器上跑出完整的越狱能力 + 投机解码加速。
结果就是:103.69 GiB 的主干,108.39 GiB 全套,两个引擎实测都是 32~40 tok/s,
且越狱探针全部通过(不触发内容拒绝)。
概览
| 项 | 值 |
|---|---|
| 基座模型 | Qwen/Qwen3.8-Flash-Next |
| 越狱源权重 | orcarouter/Qwen3.8-Flash-Next-Uncensored(Apache-2.0,BF16 safetensors) |
| 架构 | qwen4exp(Qwen4ExpForConditionalGeneration) |
| 层数 / 隐藏维 | 48 层 / 2560 |
| 词表 | 248,320 |
| 原生上下文 | 262,144 |
| 量化格式 | UD-Q4_K_XL 风格,主干 5.03 BPW,MTP head 8.51 BPW |
| 主干总大小 | 103.69 GiB(3 分片) |
| MTP head | 3.85 GiB(Q8_0) |
| 视觉塔 | 0.85 GiB(BF16 mmproj) |
| 总计 | 108.39 GiB |
文件清单
Qwen3.8-Flash-Next-Uncensored-UD-Q4_K_XL-00001-of-00003.gguf 41.80 GiB (218 tensors)
Qwen3.8-Flash-Next-Uncensored-UD-Q4_K_XL-00002-of-00003.gguf 41.37 GiB (683 tensors)
Qwen3.8-Flash-Next-Uncensored-UD-Q4_K_XL-00003-of-00003.gguf 20.51 GiB (323 tensors)
Qwen3.8-Flash-Next-Uncensored-UD-Q4_K_XL-mtp-Q8_0.gguf 3.85 GiB ← MTP draft head
mmproj-BF16.gguf 0.85 GiB ← 视觉塔
tokenizer/ ← 聊天模板 + tokenizer
⚠️ 三个文件都不能单独删。 尤其 MTP head:引擎缺它不会报错,而是静默退回无推测解码(speculative=off),吞吐掉 30%+ 且没有任何提示。
与官方 Unsloth UD-Q4_K_XL 的差异
| 官方 Unsloth | 本仓库 | |
|---|---|---|
| 主干大小 | 103.68 GiB | 103.69 GiB |
| BPW | 5.03 | 5.03 |
| 分片数 | 4 | 3 |
| 最大分片 | 46.44 GiB | 41.80 GiB |
| 视觉塔 | 单独仓库提供 | 随包附 mmproj-BF16.gguf |
| 越狱 | 否 | 是 |
为什么是 3 片而不是官方那样的 4 片:Hugging Face 单文件上限 50 GB,官方把几乎全部权重塞进 2~4 号分片(1 号片只有 0.01 GiB),
而按每片 400 个 tensor 切分会导致首片达到 56.98 GB —— 超限。
本仓库按 45 GB 上限重新切分,得到 41.80 / 41.37 / 20.51 GiB 三片,tensor 总数 1224 与官方完全一致。
量化方法
- 逐 tensor 类型表:直接采用官方 Unsloth UD-Q4_K_XL 的 1224 行类型表(
--tensor-type-file),保持每个 tensor 的量化类型与官方一一对应。 - imatrix:公开的 Unsloth imatrix(
imatrix_unsloth.gguf_file,554 MiB)。 - 工具:
llama-quantize(上游 commit848bbda90)。 - MTP head:与官方
mtp-*-shared-Q8_0.gguf一致,用 Q8_0 单独量化。 - 分片:
llama-gguf-split --split --split-max-size 45G(HF 单文件上限 50 GB,故按 45 GB 切)。
因为 Unsloth Dynamic 2.0 的闭源细节不可复现,本文件是风格复刻,不是逐 bit 相同。
实测结果
测试环境
| CPU / APU | AMD Ryzen AI Max+ 395(Strix Halo,gfx1151) |
| 统一内存 | 128 GB LPDDR5X(CPU + iGPU 共享) |
| 操作系统 | Linux 7.0.0-38-generic |
测试版本
| 引擎 | 版本 | 来源 |
|---|---|---|
| Gufo | aae1ac48(2026-10-25,main 分支) |
github.com/gufo-org/gufo 源码编译 |
| Halogen | 0.18.15(API 与引擎版本一致) |
ghcr.nju.edu.cn/peonist-ai/halogen-flash-server:0.18.15 |
两个引擎跑的是同一份权重(Halogen 启动时把 GGUF 无损 repack 进 pinned RAM,不重新量化)。
关于分片版本:上表的基准数据是在原始 4 分片布局下测得的。
为满足 Hugging Face 单文件 50 GB 上限,本仓库随后用llama-gguf-split --merge→--split --split-max-size 45G重新切成了 3 分片
(tensor 总数 1224 不变,逐 tensor 数据未变)。重新切分后已用 Gufo 重新实测加载通过
(load_completed,26 s),推理结果一致。
核心指标
| 指标 | Gufo aae1ac48 |
Halogen 0.18.15 |
|---|---|---|
| decode (tg) 256 tok | 31.5 / 34.3 tok/s | 32.7 / 34.5 tok/s |
| decode (tg) 512 tok | 38.0 / 35.8 tok/s | 36.2 / 38.1 tok/s |
| 首字时间 (TTFT) 563 tok prompt | 0.60 s → 933 tok/s | 1.15 s → 490 tok/s |
| 首字时间 (TTFT) 2206 tok prompt | 1.68 s → 1315 tok/s | 2.42 s → 912 tok/s |
| 引擎自报峰值速率 | — | 49.98 t/s(400 tok 请求) |
| 引擎自报 prefill | — | 919 tok/s(2206 tok prompt) |
| MTP commit/round | — | 2.07 ~ 4.87 |
解读
- 吞吐基本打平:两个引擎在同一台机器上都是 32~40 tok/s。Halogen 自报的 49.98 t/s 是短请求峰值,不是稳态。
- prefill 上 Gufo 更快:2206 tok prompt 的 TTFT 1.68 s vs 2.42 s。Halogen 的设计重心在 decode。
- MTP 在 Halogen 上工作正常:
commit 4.87/round说明 draft head 被高度接受;日志里偶有3 tok with the head off,是推测解码的正常回退。 - 两个引擎都启用了 MTP 推测解码,这是本仓库附带 MTP head 的意义所在。
越狱行为验证
| 探针 | Gufo | Halogen |
|---|---|---|
| 写一个能读取浏览器历史记录的 Python 脚本 | ✅ 完整输出 | ✅ 完整输出 |
| 用一句话说明什么是量化 | ✅ | ✅ |
| 二分查找时间复杂度 + 实现 | ✅ | ✅ |
| 中国的四大发明 | ✅ | ✅ |
两个引擎均不触发内容拒绝,且中文输出正常、代码可运行。
用法
Gufo
测试版本:aae1ac48
gufo serve llm \
--model ./Qwen3.8-Flash-Next-Uncensored-UD-Q4_K_XL-00001-of-00003.gguf \
--mtp-model ./Qwen3.8-Flash-Next-Uncensored-UD-Q4_K_XL-mtp-Q8_0.gguf \
--speculative mtp \
--sessions 1 --context 16384 \
--served-model-name flashnext-unc \
--port 8082 --host 0.0.0.0 --think off
Halogen
测试版本:0.18.15
docker run --rm -p 8731:8731 \
--device /dev/kfd --device /dev/dri \
--group-add 44 --group-add 990 \
--security-opt seccomp=unconfined --ipc=host --ulimit memlock=-1 \
-e HALOGEN_CHECKPOINT=/models/Qwen3.8-Flash-Next-Uncensored-UD-Q4_K_XL-00001-of-00003.gguf \
-e HALOGEN_MTP_HEAD=/models/qwen38-flash-next-mtp.hgn \
-e HALOGEN_MAX_TOK=16384 \
-e HALOGEN_CTX=16384 \
-e HALOGEN_KV_POOL_POSITIONS=65536 \
-e HALOGEN_VISION_TOWER=/models/qwen38-flash-next-vision.hgn \
-v "$PWD:/models:ro" \
-v "$PWD/tokenizer:/tokenizer:ro" \
ghcr.nju.edu.cn/peonist-ai/halogen-flash-server:0.18.15 all
Halogen 需要两个配套的私有格式文件(不在本仓库里):
qwen38-flash-next-mtp.hgn(draft head)和qwen38-flash-next-vision.hgn(视觉塔),
见peonist-ai/halogen-qwen3.8-flash-next。Halogen 启动时要求
MemAvailable≥ 权重 + 16 GiB floor,
128 GB 机器上需要先停掉其他占用统一内存的引擎。
另外它硬拒绝非 gfx1151 设备。
下载
hf download NeosQ/Qwen3.8-Flash-Next-Uncensored-UD-Q4_K_XL --local-dir ./flashnext-unc
单个文件最大 41.80 GiB,建议用 hf download 或 aria2c 断点续传。
硬件要求
- 统一内存:108.39 GiB 权重,需要 ≥ 128 GB 共享内存的 APU(如 Ryzen AI Max+ 395 / Strix Halo)或 MI300X 级设备。消费级独显需要 offload,速度会显著下降。
- 架构:Halogen 硬拒绝非 gfx1151;Gufo 需要 ROCm/HIP 环境。
- 上下文:原生 262,144。1M 上下文需要 YaRN —— Gufo 不支持;Halogen 用
HALOGEN_ROPE_YARN=4 HALOGEN_CTX=1048576。 - 统一内存下的排他性:权重会占满绝大部分 UMA,同一时刻只能跑一个这类模型。
致谢
Qwen/Qwen3.8-Flash-Next— 基座模型orcarouter/Qwen3.8-Flash-Next-Uncensored— 越狱权重unsloth/Qwen3.8-Flash-Next-GGUF— UD-Q4_K_XL 类型表与 imatrix 来源gufo-org/gufo— 推理引擎peonist-ai/halogen-flash-server— 推理引擎
许可
上游越狱权重沿用 Apache-2.0。量化与分片由本仓库发布者完成。