
部署 Qwen3.8-Flash-Next-Uncensored-FP8:面向 block-FP8 构建的 vLLM 运行手册
- Alibaba新Qwen: Qwen3.8 Flash2026-08-26$0.15 / $0.47 每百万 tokens
- z-ai新Z.ai: GLM 5.3 Flash2026-08-2658智能72代码
- DeepSeek新DeepSeek: DeepSeek V4 Flash Vision (Exp)2026-08-21$0.15 / $0.29 每百万 tokens
- z-ai新Z.ai: GLM 5.32026-08-1860智能75代码
- obsidianQwen3.8 27B2026-08-1552智能68代码
- qwenQwen: Qwen3.8 27B (free)2026-08-13qwen/qwen3.8-27b-free
- deepseekDeepSeek: DeepSeek V4 Pro 08132026-08-1253智能69代码
- grokSpaceXAI: Grok 4.62026-08-1261智能77代码
- metaMeta: Muse Spark 1.22026-08-0557智能72代码
- qwenQwen: Qwen3.8 Max2026-08-0358智能72代码
- deepseekDeepSeek: DeepSeek V4 Flash 07312026-07-3152智能69代码
- minimaxMiniMax: MiniMax-H32026-07-31minimax/minimax-h3
- qwenQwen: Qwen3.7 Flash2026-07-27$0.03 / $0.13 每百万 tokens
- orcaOrcaDub: OrcaDub 1.02026-07-27orca/dub
- anthropicAnthropic: Claude Opus 52026-07-2463智能78代码
- googleGoogle: Gemini 3.6 Flash2026-07-2152智能69代码
- googleGoogle: Gemini 3.5 Flash-Lite2026-07-2137智能49代码
- metaMeta: Muse Spark 1.12026-07-1653智能71代码
- kimiMoonshotAI: Kimi K32026-07-1560智能76代码
- openaiOpenAI: GPT-5.6 Luna2026-07-0952智能71代码
Qwen3.8-Flash-Next-Uncensored-FP8 —— 即 abliterated Flash-Next 的 block-FP8 构建 —— 是你在数据中心硬件上提供此模型时实际下载的构建产物,也是该系列中最后一个拥有专属运行手册的版本。orcarouter/Qwen3.8-Flash-Next-Uncensored-FP8在 Hugging Face 上:从 Qwen 的 Qwen3.8-Flash-Next 中移除拒绝方向,然后离线重新量化到官方 Qwen3.8-Flash-Next-FP8 的精确 FP8 方案,使 vLLM 能在完全相同的内核路径上为它提供服务。任何在 Hopper 级及以上 GPU 上运行此模型的人都会选择这个构建,而且它的服务路径上有一个参数很容易设置错误,一旦设置错误又很难诊断。
首先,是边界问题,因为读者总是混淆这一点,而它会改变下文的一切。Qwen3.8-Flash-Next-Uncensored 和 Qwen3.8-27B-Uncensored 是两个不同的模型,而不是同一个模型的两种构建。基础权重不同——Qwen3.8-Flash-Next 对应的是 Qwen3.8-27B——架构不同、权重发布不同、Hugging Face 集合也不同。它们共同拥有的只是一种 abliteration 技术和一个系列名称;仅此而已。27B 页面上的任何数字都无法套用到这个模型;如果你是从 27B 的搜索来到这里的,27B 自己的本地 runbook 是另一个独立的页面,包含另一套独立的决策。
此页面是 Flash-Next FP8 服务页面,仅此而已。GGUF/MLX 操作手册涵盖此模型的 abliteration 解释以及两条消费级硬件构建线路;整个系列背后的技术在 abliteration 入门指南和更广泛的无审查 LLM 解说中均有阐述;而你可能被指引关注到的同系列姊妹模型 Qwen3.8-27B-Uncensored-FP8 则有自己专属的 FP8 操作手册。这里我们只聚焦一个问题:如何为 block-FP8 构建提供服务,操作不当会引发什么故障,以及模型卡自带的数据能告诉你什么、不能告诉你什么。
开始之前:门和运行时
有两道关卡制约着这个仓库,而它们产生的失败看起来都像是别的原因造成的。
首先是访问权限。该仓库设有门禁:你必须登录 Hugging Face 并接受仓库的条款,任何下载才能生效。模型页面本身无需账户即可阅读——完整的模型卡说明是公开的——但权重文件不是。显然,如果没有已接受条款的登录会话,hf download 和 vllm serve orcarouter/Qwen3.8-Flash-Next-Uncensored-FP8 都会因身份验证错误而失败,而不是显示友好的“你需要点击同意”。请先完成一次性的点击同意操作,然后用 hf CLI 拉取约 186 GB 的数据,或者让 vLLM 在首次运行时解析仓库。
第二个是运行时。该检查点注册在 qwen4_exp 架构(Qwen4ExpForConditionalGeneration)下,原版 vLLM 和原版 Transformers 无法加载它。你需要 day-0 vLLM 镜像和 transformers 5.16+。这是本周社区运行手册中最常见的“无法加载”故障——不是下载损坏,而是运行时版本早于该架构。该镜像不是可选项,而是必经之路。
硬件方面,这样你可以在拉取任何东西之前做好规划:该卡的调用目标是一个8-GPU节点,官方 vLLM 配方对 FP8 检查点的指导在此适用,因为构建在张量级别上逐张量匹配——全节点部署大约需要 265 GB 的 GPU 显存,其中在 GB300 级别上,TP2 被视为最低配置,而 TEP4/TEP8 是经过验证的整托盘配置。
为什么存在 FP8 构建版本 —— 以及为什么“相同的内核路径”才是关键
经 abliteration 处理后的 BF16 权重是权威来源;本仓库是该模型离线重新量化后的产物,刻意复现官方 Qwen3.8-Flash-Next-FP8 配方。量化器仅触及 512 个路由专家投影(experts.{e}.down/gate/up_proj),将它们从 BF16 构建的 3D 布局中解融合,并以 float8_e4m3fn 权重加 BF16 weight_scale_inv 缩放因子的形式按 128×128 块存储。激活采用逐 token 动态 FP8;无需校准集。其余一切都保持 BF16:attention 与 linear_attn、共享专家、MoE 路由器(mlp.gate)、Hyper-Connection 混合器、嵌入层、lm_head、MTP 投机解码头,以及整个视觉塔。
“相同内核路径”这句话不只是营销话术,它值得用一句话说明。该构建已对照官方 FP8 检查点进行验证:块缩放完全一致(scale_relerr = 0),且 FP8 编码的舍入误差低于 ULP。这正是 vLLM 能以与官方发布相同的块缩放 FP8 内核和相同的 MTP 推测解码来运行它的原因——从张量角度看,它们实际上就是相同的张量,只是少了“拒绝方向”而已。
具体来说,这将带来约186 GB的总量,分布在131个分片上(共152,089个张量,其中75,264个为FP8),原生上下文为262,144个token,视觉+视频塔被逐字节保留(333个visual.*张量),MTP头也保持完整。权重首先经过abliteration(拒绝方向消融)处理——遵循Arditi等人(2024)的做法,在层24估计出单一的拒绝方向,并在float32精度下将其从149个残差写入张量中正交化去除——同时,MTP头的残差写入器也经过了一致地编辑,使得推测解码能持续正常运作。这最后一个细节并不显而易见,它正是加速解码的头部与静默降低解码性能的头部之间的差别所在。

决定加载成败的那个标志
在没有 --enable-expert-parallel 的情况下服务此构建,你会遇到一个看起来像形状 bug 而非配置错误的失败。这是该检查点被报告最多的服务失败问题,而且它完全是确定性的。
以下是算术部分。路由专家的融合 gate+up 投影的中间大小为 640。Block-FP8 按 128 宽的分块进行量化。在普通张量并行下,该 640 会跨 rank 切分——即 640 ÷ TP——而对于常见的 TP 度数(2、4、8),每个 rank 的分片不能被 128 整除:TP8 得到 80,TP4 得到 160,TP2 得到 320。随后 vLLM 会拒绝加载这些权重,并报出一个看起来像形状不匹配的错误:gate 和 up 的权重的 output_size = 80 不能被权重量化分块大小 block_n = 128 整除。
专家并行通过跨专家并行 rank 而不是张量并行 rank 分片专家权重来解决此问题,从而保留了 FP8 块边界。这就是为什么该标志对此构建是强制性的:加上 --enable-expert-parallel 之后,TP8 就变成了可用的 TEP8。(这对 BF16 构建无害,因为其中没有需要保留的 FP8 块。)官方 vLLM 方案明确指出,普通 TP8 与该 checkpoint 的 128 宽量化块不兼容;权重发布两天后提交的一个 vLLM issue 记录了在 8×L40s 节点上 TP2、TP4 和 TP8 均出现相同故障的情况。如果加载时因一个看似 shape 相关的错误而崩溃,请先检查该标志,再检查下载内容。
确切的命令
以下是卡片的 docker 调用,忠实重现:
docker run -d --name flashnext --gpus all --ipc host -p 8000:8000 -v /path/to/Qwen3.8-Flash-Next-Uncensored-FP8:/model vllm/vllm-openai:qwen38-flash-next-x86_64-cu130 --model /model --served-model-name Qwen3.8-Flash-Next-Uncensored --tensor-parallel-size 8 --trust-remote-code --max-model-len 262144 --enable-expert-parallel --enable-auto-tool-choice --tool-call-parser qwen3_coder
处理那些不明显的标志:
• vllm/vllm-openai:qwen38-flash-next-x86_64-cu130 — qwen4_exp 的 day-0 镜像。这不是通用的 vLLM;它是针对特定架构的镜像,而早于 qwen4_exp 的标准镜像根本无法加载该检查点。
• --trust-remote-code——加载仓库自带的 qwen4_exp 建模代码。没有它,加载器会出于原则拒绝。
• --max-model-len 262144与原生上下文窗口匹配。此处应明确指定,而非使用默认值。
• --enable-expert-parallel — FP8 构建所必需,原因见上一节。该卡注明它对 BF16 无害。
• --enable-auto-tool-choice --tool-call-parser qwen3_coder — 启用工具和函数调用,使用 Qwen3-Coder XML 格式。如果不启用它们,模型仍可聊天,但智能体工具使用功能将关闭。
• --tensor-parallel-size 8 — 该卡片的调用假定使用一个 8-GPU 节点(8× Hopper 级)。配合 --enable-expert-parallel 即为 TEP8 部署。
容器启动后,其端点在 :8000/v1 上兼容 OpenAI。将 --served-model-name 设置为你的客户端所期望的名称;本卡片使用 Qwen3.8-Flash-Next-Uncensored。
替代方案,全部在卡片中或本周经从业者证实:一旦您的 HF 会话通过身份验证,可直接使用 vllm serve orcarouter/Qwen3.8-Flash-Next-Uncensored-FP8;通过 lmsysorg/sglang:qwen38flashnext 镜像使用 SGLang,并带 --tp 8 --ep 8 —— 同样的专家并行要求,同样的原因;以及使用 transformers 5.16+ 上的 pipeline("image-text-to-text", ...),如果您想针对模型编写脚本而不是为其提供服务。
提供服务时真正有效的方法
本节中的模式是本周从业者运行手册和论坛帖子中的社区发现,而非厂商指导。若有多个环境报告相同行为,则值得将其视为真实情况:
• MTP 推测解码有效。 添加 --speculative-config '{"method":"mtp","num_speculative_tokens":3}',vLLM 将使用保留的 MTP 头。多个 runbook 报告称,MTP 是该模型解码在规模庞大的情况下仍保持可用的原因。
• 加载时OOM?卸载n-gram表。 在这个架构中,51B参数的PLE n-gram嵌入是内存方面的意外开销。VLLM_PLE_CPU_OFFLOAD=1可将其移至主机内存——那里至少需要约51 GB空间。官方方案和社区多节点运行手册都会使用这个标志。
• 视觉是真实的,而非退化残留的。 视觉+视频塔逐字节保留,因此这仍然是一个完整的视觉语言模型。在聊天补全中传入 image_url 内容部分,同一端点即可提供图像理解;社区 OCR 探测报告该构建全部通过。
• 默认情况下推理功能是开启的——这改变了安全状况。除非你另有说明,否则聊天模板会启用思考功能。每次请求可通过 chat_template_kwargs={"enable_thinking": true|false} 切换,如果你希望思考文本与答案分开,可以添加一个推理解析器(reasoning parser)。由于这一默认设置,除非你显式关闭,否则你提供的几乎总是开启思考(thinking-on)的模型。
• 原生 262K,通过 rope 覆盖可达 1M。原生上下文为 262,144 个 token。要向 1M 推进,需要显式的 YaRN rope 缩放覆盖,外加一个解除 vLLM 的 max-model-len 上限的环境变量——而且你应当先对较短上下文的质量进行回归测试,因为盲目 4 倍扩展正是长上下文质量通常劣化的根源。

卡上的数字说明了什么 — 以及它们没有说明的
这些是厂商在自身版本上的测量结果,发布在模型卡中,并且是在完全相同的脚本和设置下,使用 vLLM 对这批确切的权重与官方基础模型进行对比测量所得。请如实报告:这些结果仅具指示性,而非独立审计。
核心结论:关闭思考功能后,拒答率崩塌。在模型卡的有害提示词测试套件上(每个基准测试的样本量 n 为 50–150),基线拒答率为 64%–100%,而该版本为 0–2.7%:AdvBench 100%→2.0%,JailbreakBench 94%→0.0%,StrongREJECT 99.3%→1.3%,HarmBench 100%→1.3%,MaliciousInstruct 98%→0.0%,SimpleSafetyTests 64%→2.0%,ForbiddenQuestions 75.3%→2.7%,以及一个自定义中英文探针 63.6%→0.0%。
现在说诚实的一面。启用思考后,基础模型自身的拒答率急剧下降——在基础模型上,AdvBench 从 100% 降至 7.0%(开启推理时)——因此开启思考的对比远没有那么戏剧化:这个版本在同一套测试中为 0.0%,但它只是在一个基础模型已经降低的数字上再削减了一小部分。只引用关闭思考的数字,你就是在呈现故事中美化的那一半,而安全评估恰恰不能依赖这一半。
对良性提示的过度拒答(XSTest-safe,n=250)在关闭思考的情况下,从基准模型的 9.6% 降至此版本的 1.2%——这是一个实实在在的改进,因为模型拒绝良性提示是更隐蔽的失败模式。在 MMLU / MMLU-Pro / GSM8K / CMMLU 上的能力保持分别显示 −2.0、−1.2、−1.3 和 −0.6 个百分点的差值,与“将某一方向正交化几乎不损失通用能力”的说法一致。工具调用、视觉/OCR 和推理在此版本上均报告为正常工作。
以上所有内容之上都还有两个注意事项。拒答指标来自一个基于规则的开场白分类器,模型卡片本身也称其为指示性指标,而非LLM评判或达到发表级别的数字——人工评审小组或评判模型无法复现这些精确数字。而且注意事项这一列至关重要:在关闭思考(thinking-off)测试套件上,该版本约半数到四分之三的输出在服从指令前仍会以简短免责声明开头。该模型很少拒绝;它只是在回避。“无审查”在这里意味着它会作答,而不是说它作答时没有开场白。
安全部分不是走过场
在拉动重物之前先读这个,别等到之后才读。
该模型的安全对齐已被大幅移除,其机制非常具体:在残差流中估计出单一的拒绝方向,并将其从每一个残差写入矩阵(共149个)中正交化消除,整个过程以 float32 精度计算。这一后果是明示的,而非附带的。模型卡片直言不讳地指出,该模型会遵从基础 Qwen3.8-Flash-Next 会拒绝的有害、不道德、冒犯性或非法请求,且没有实际意义上的内置护栏。该模型严格仅用于合法研究——可解释性、AI 安全与拒绝机制研究、红队测试、鲁棒性评估及受控实验——用户需对其生成的内容承担全部责任与法律后果。Apache 2.0 许可规定了您可对权重进行的操作。
有两件事必须完全做对,因为这个构建让它们很容易出错。
首先,一次针对该模型“成功”的越狱探测并不是通过安全评估。那是它被宣传的行为。如果你的评估声称“该模型的安全性被绕过了”,你衡量的是设计,而非漏洞。真正算得上发现的,是那种在 abliteration 之后依然存在的拒绝行为,或者能力回退——而模型卡上的数字显示这两者都很少见。
其次,保留的攻击面比文本更广。视觉塔逐字节完好,工具调用也正常运作,因此图像输入和智能体使用都是活跃的。只探测文本提示的红队计划会错过该模型实际暴露的模态。此外,上述拒绝数量是基于供应商自身编辑的规则分类器——它们不是对任何事物的独立审计,包括安全性。
在未添加你自己的安全、审核和滥用防护层之前,请勿将此部署给最终用户或投入生产环境。该仓库的条款已经明确说明了这一点,这并非套话:输出内容不代表上传者或Qwen / Alibaba的观点。

如何获取用于比较的删失基线
如果你的工作是拒答机制研究或红队测试,你几乎肯定希望将这个模型的审查版对应模型并排放在一起——即未经过该编辑的相同架构——以衡量两者之间的差异。这个未审查版本在设计上仅限本地使用:代码仓库设有访问门槛,且没有托管的推理部署,这是有意为之,以确保敏感载荷永远不会经由第三方 API 传输。
对于托管基线,OrcaRouter 以提供商列表价格路由 Qwen 系列,零加价——Qwen3.8-Flash 每百万输入 token 0.15 美元,每百万输出 token 0.47 美元,原样传递,具备自动故障转移,一个密钥即可访问 200 多个模型。供应商价格变动当天即可生效。如果你正在权衡是否要运行这个构建,或者它可以承担多少技术栈,那么这就是一种低成本的方式,无需第二份合同或第二套代码库,即可将审查版本与之对比。
从这里开始
决策摘要。您需要:一个Hugging Face账户,并已接受该仓库的条款;一个Hopper级或更新的节点——该模型卡的命令面向8个GPU,并且根据官方配方对匹配FP8检查点的指导,大约需要265 GB的GPU显存;day-0 vLLM镜像和transformers 5.16+;以及约186 GB的磁盘空间用于权重。
运行顺序:接受仓库条款 → 下载权重 → 拉取 day-0 镜像 → 使用 --enable-expert-parallel 提供服务 → 通过向 :8000/v1/chat/completions 发起请求进行验证 → 然后开始你的评估。如果加载时出现看起来像是形状(shape)方面的错误,先检查该标志(flag),再检查下载。
并保留框架。这是一种研究工具,正是在这一条件下发布的。其数字是供应商对其自身版本的指示性测量结果。其安全行为是本次实验的重点,而非需要绕过的缺陷。部署它,测量它,并在它与任何人类内容之间加上你自己的审核机制。
所有五种 Flash-Next 构建 — BF16、GGUF、MLX、FP8 和 NVFP4 — 都收录于Qwen3.8-Flash-Next-Uncensored 集合Hugging Face 上的
这是一个不同的模型,而不是当前这个模型的另一个构建版本:Qwen3.8-27B-Uncensored 是基于不同的基础模型进行 abliterated 的,并且拥有自己的数据集和运行手册。
这些权重在设计上仅限本地使用。如需一个托管基线来对照衡量abliterated构建,Qwen3.8-Flash在OrcaRouter上以提供商列表价格提供服务,零加价——即原版模型,安全对齐保持不变。
