Qwen3.8-Flash-Next-Uncensored-NVFP4：Blackwell 服务运行手册

Qwen3.8-Flash-Next-Uncensored-NVFP4 只在一个 GPU 家族上运行：Blackwell。NVFP4 在硬件 FP4 张量核心上执行，而 Hopper（H100/H200）及更老的硬件根本没有这些核心。如果你用的是 Hopper，看到这里就可以打住了——Qwen3.8-Flash-Next-Uncensored-FP8 版本才是你需要的。以下内容均假设你使用的是 Blackwell（B100、B200、GB200 或 RTX 50 系列显卡）、支持 qwen4_exp 的最新 vLLM 构建版本，以及 transformers ≥ 5.16。

这是经过abliterated（移除拒绝）构建的Qw​en的NVFP4量化版本Qw​en/Qwen3.8-Flash-Next，从BF16的330 GB缩减到磁盘上的178 GB。OrcaRouter于2026年8月27日将其发布到Hugging Face，名为orcarouter/Qwen3.8-Flash-Next-Uncensored-NVFP4。该仓库受门控：你必须登录Hugging Face并接受仓库条款，否则hf download和vllm serve orcarouter/Qwen3.8-Flash-Next-Uncensored-NVFP4都会在传输任何字节之前因身份验证错误而失败。本页是一份服务运行手册，而非发布报道——该构建仅两天历史，人们实际遇到的问题涉及硬件、参数以及选择哪个构建。

在数字开始之前：Qwen3.8-Flash-Next-Uncensored并不是Qwen3.8-27B-Uncensored。它们是两个不同的模型，只是共享同一个家族名和同一种 abliteration 技术——基础权重不同、架构不同，Hugging Face 集合也不同。Flash-Next 的 abliteration 来源是Qw​en/Qwen3.8-Flash-Next，一个 Qwen4 架构（qwen4_exp）的路由式混合专家预览版：512 个专家，其中 10 个路由专家加 1 个共享专家处于激活状态；混合注意力（Gated DeltaNet 线性层与全注意力层并列）、Hyper-Connections、PLE n-gram 嵌入、原生视觉与视频塔，以及 MTP 推测解码头。27B 的 abliteration 来源则是Qw​en/Qwen3.8-27B，这完全是另一个稠密基础模型。27B 页面上的服务数据一概不适用于本模型；如果 27B 页面有真正有用的部分——abliteration 入门指南、通用的量化选择计算方法——下面会给出链接，并说明哪些可以沿用、哪些不可以。

这个构建是什么，逐项精确说明

Qwen3.8-Flash-Next 是一个路由MoE：每个token激活512个专家中的10个，外加一个共享专家，因此尽管存储的模型要大得多，但每个token只有几十亿参数处于活跃状态。NVFP4构建是对该技术栈的混合精度compressed-tensors量化，而拆分就是全部关键。

• MoE 专家权重 — NVFP4（4 位，NVIDIA FP4 E2M1，使用 group-16 与 FP8 块缩放）。

• Attention（self_attn.{q,k,v,o}）、linear_attn 投影、共享专家以及 lm_head — FP8（8 位）。

• PLE n-gram 嵌入、token 和视觉嵌入、Hyper-Connections、QSA 索引器、Gated-DeltaNet conv/dt、所有归一化层以及整个视觉塔 — 使用 BF16，保持全精度。

转换的三个属性比精度切分本身更重要。首先，它是仅权重的：激活值在运行时动态量化，无需静态校准，权重直接取自 BF16 检查点（模型卡称这一推导为无数据）。其次，abliteration 修改被烘焙进权重中，因此拒绝移除在量化后依然有效——4 位转换只是精度变化，而非安全干预。第三，KV 缓存不被量化；它在运行时保持 BF16。最后这一点很容易被忽略，而在模型原生的 262,144 token 上下文下它很重要——此时 KV 缓存与权重一样，是真实的内存开销项。

磁盘占用大小由单个张量主导。该卡将 PLE n-gram 嵌入描述为单个约 660 亿参数的张量，按设计以 BF16 格式保存；它是最大的分片，也是构建体积为 178 GB 而非更小数值的原因。有一点差异需要指出而非掩盖：FP8 姊妹卡将同一张表称为 510 亿参数的 PLE n-gram，而该卡的 W4A4 说明将其称为约 100 GB。两张卡对同一张表给出了不同的数值，因此请将每个数值视为各自卡片的数字——在规划部署规模时，请假定该表在 BF16 下体积庞大，并据此进行规划。

硬件前提条件详解

这是页面中最简短却最重要的部分。NVFP4 是一种 Blackwell 格式：其快速路径是在第五代张量核心上进行的原生 FP4 GEMM，如果没有该硬件，该格式将无法运行。显卡自身的需求说明写得很明确——需要 Blackwell GPU（B100 / B200 / GB200 / RTX 50 系列），因为 NVFP4 依赖硬件 FP4 张量核心，并且它无法在 Hopper（H100/H200）或更老的架构上运行，因为这些架构缺乏 FP4 计算能力。

重定向，集中在一处：

• 在 Hopper (H100/H200) 上 — 请改用 Qwen3.8-Flash-Next-Uncensored-FP8。它是相同的 8-bit 权重，可在 Hopper 和 Blackwell 上运行，也是本博客 FP8 运行手册所涵盖的构建版本。

• 在消费级 NVIDIA GPU 或 CPU 机器上 — GGUF 构建版本及其 13 个 llama.cpp 量化格式，是本地部署的路径。

• 在 Apple Silicon 上——4/6/8 位级别的 MLX 版本，是原生的 Metal 路径。

运行时要求与硬件本身一样具有约束力。qwen4_exp 是一种全新的架构，因此早于它发布的 vLLM 标准构建将拒绝加载该检查点。你需要一个支持 qwen4_exp 的最新版 vLLM，以及 compressed-tensors NVFP4 读取器（格式是从 config.json 中自动检测的，而非手动选择），并且 transformers 版本 ≥ 5.16。多模态输入还需要运行时的 Qw​en 视觉栈；纯文本服务则无需它即可工作。

卡片的 serve 命令，逐个标志地

模型卡片自身的调用是一个很好的起点，值得理解每个标志（flag）的用途，而不是盲目地复制粘贴：

vllm serve orcarouter/Qwen3.8-Flash-Next-Uncensored-NVFP4 --tensor-parallel-size 4 --trust-remote-code --enable-expert-parallel --enable-auto-tool-choice --tool-call-parser qwen3_coder

• --tensor-parallel-size 4——权重在磁盘上约为 178 GB，因此该显卡会将它们分散到四块 GPU 上。该构建就是按这种形态来设计的；不要将其视为一种建议。

• --trust-remote-code — 自定义架构所必需。qwen4_exp 的建模代码尚未收录在标准 transformers 注册表中，因此 vLLM 会从仓库加载架构代码。你是在信任该代码，对于全新架构来说，这是一个正常但真实的决定。

• --enable-expert-parallel — 将专家分片到张量并行（TP）的各个 rank 上，而不是复制它们；这正是让 512 专家的 MoE 在 TP4 下变得可行的原因。FP8 配套卡片给出了该构建中更精确的理由：如果没有它，MoE 的中间宽度除以 TP 后无法被 FP8 块大小整除。请将其视为必需项，而非可选项。

• --enable-auto-tool-choice 和 --tool-call-parser qwen3_coder——这两项结合即可开启函数调用功能。auto 标志让模型自行决定是否调用工具，qwen3_coder 解析器则负责解码其工具调用格式，与 Qwen3.8-27B 和 Qwen3.8-Flash-Next 所用的解析器家族一致。

一旦启动，位于 /v1/chat/completions 的 OpenAI 兼容端点将通过运行时的 Qwen4 技术栈提供完整功能集：上述的工具调用、通过 chat_template_kwargs.enable_thinking 实现的推理，以及通过 image_url 内容部分实现的视觉功能。多模态无需单独的服务器；它使用的是同一个端点。

卡片中的一个结构性说明：这个构建没有完全静态的 W4A4 变体，而且短期内也不会有成本低廉的方案。静态 W4A4 转换需要进行一次激活校准前向传播，而这次传播必须在单个 GPU 上容纳约 100 GB 的 n-gram 嵌入。这就是 PLE 表在文件列表中占主导地位的原因，也是为什么该构建保持仅权重量化并配合动态激活。

社区实地报告——实际服务是什么样子的

针对这个具体仓库，目前没有公布任何吞吐量或延迟数字，本页面也不会凭空编造。现有一组不断增多的社区实测报告，来自部署基础版 Qwen3.8-Flash-Next NVFP4 构建的从业者——相同的架构、相同的 NVFP4/FP8/BF16 精度划分，只是去掉了 abliteration 编辑——其服务行为会直接沿用。这些是社区发现，而非供应商指南；报告这些数据的人使用的是 Blackwell 硬件，并采用了相同的量化方案。

• MTP推测解码是最大的性能杠杆。该模型自带一个多token预测草稿头，在一张RTX PRO 6000（96 GB，SM120）上，MTP模块以NVFP4量化加载，占用约0.51 GB显存——报告测得接受长度为2.3–3.9（最大为4），接受率为0.86–0.96。同一报告测得单流解码速度中位数为180–226 tok/s（编码216.9，智能体工具调用工作负载225.8，推理136.6），而基线约为105 tok/s；并在8.4秒内回答了一个216,685 token的提示词。请将这些数字视为某个人的设备实测结果，而非规格参数。

• 将PLE n-gram嵌入卸载到主机内存。由于该表非常庞大，而且很少成为吞吐瓶颈，社区在单块Blackwell显卡上的常见做法是将其固定到主机内存（RTX PRO 6000报告中可用主机内存约50 GiB），并通过NVMe进行内存映射，以牺牲少量延迟来换取模型能够完整加载。除非你的显存预算非常大，否则预计你也需要这样做。

• 显式固定上下文窗口。启用 BF16 KV cache 和 MTP 后，自动调整大小的 KV 池膨胀到超出显卡容量，在长 prefill 时导致 OOM；将 max-model-len / max-total-tokens 固定为 262144 后恢复了余量。在 262K 上下文下，KV cache 是需要单独预算的项目，而非默认配置。

• FlashInfer 自动调优（autotune）的一个 bug 会静默地破坏输出。这是实际部署中最主要的故障模式：autotune 仅依据延迟来选择融合 MoE 内核策略，从不检查数值正确性，因此在某些形状下，解码会坍缩为重复的 token。RTX PRO 6000 的复现报告显示，开启 autotune 时 36 次生成全部损坏；关闭时 36 次无一损坏。解决办法是禁用 FlashInfer autotune（在 vLLM 中使用 --no-enable-flashinfer-autotune；在 SGLang 中使用 --disable-flashinfer-autotune）。如果你的服务输出突然退化，请先检查这一点，再做任何其他改动。

• DGX Spark（GB10、SM121）需要自己的补丁。NVFP4 权重（社区版约 126 GiB）无法装入单块 128 GB 的 Spark，因此 SGLang 配方需通过 RoCE 在两节点间以张量并行 2 运行；QSA 稀疏解码解析器将快速 FlashInfer 内核挡在 is_sm100_supported() 检查之后，而该检查在 SM121 上会失败，从而回退到一条在预热阶段就崩溃的路径——解决办法是一个小补丁外加 PLE 卸载。预期解码速度约 47–50 tok/s，启用 MTP4 与 CUDA 图后峰值可接近 70；在承诺基准测试结果之前，请先验证你的内核确实能在 SM121 上运行。

通过 Qwen4 技术栈实现推理、工具调用与视觉

社区对Qwen3.8系列的共识也延续到了该模型上，但通常需要注意：这是现场实践，而非供应商指导。

• reasoning_effort 是最重要的调节旋钮。聊天模板默认设为 xhigh，这会让模型在每次请求上都进行长时间思考。Agent 循环操作员默认使用 medium，并在对延迟敏感的调用中降至 low；当您不需要推理时，将 enable_thinking 设为 false 可完全禁用推理。在单个 Blackwell 卡上，对常规调用保持 xhigh，正是让一个快速模型产生缓慢回答的原因。

• 将采样器与思考模式配对使用。当思考模式开启时，实践者趋于采用温度 1.0 / top-p 0.95；关闭时，则采用温度 0.7 / top-p 0.80，并设置约 1.5 的存在惩罚。混合这两组设置会降低输出质量。

• 工具调用在 abliteration 和 4-bit 转换之后依然有效。函数调用路径完好无损，这正是 qwen3_coder 解析器和 auto-tool-choice 标志位所连接的内容。对红队来说，这是一把双刃剑，因为它意味着在一个未对齐的模型上，智能体滥用完全可以运作——下文会讨论。

• 视觉能力得以保留，这扩大了攻击面。视觉塔从未受过abliteration的影响，并保持BF16精度，因此图像输入可通过image_url content parts正常工作。评测无审查系列的从业者将多模态路径视为首要评估目标：图像中携带的提示注入会命中一个没有任何拒绝行为可阻挡的模型。

你应该提供哪个构建版本？

The Flash-Next 系列共有五种构建——BF16、GGUF、MLX、FP8 以及这一款 NVFP4——实际上，选择哪一款取决于硬件配置和权衡取舍，而不是简单的排名高低。

• NVFP4（此版本，磁盘上约 178 GB）——Blackwell 之选。FP4 张量核心、4 比特专家，是系列中的最新版本，也是其 vLLM 服务器构建中体积最小的一款，即本页所介绍的对象。

• FP8（磁盘上约 186 GB）Hopper 架构的首选，在 Blackwell 上同样适用。相同权重以 8 位精度存储，这是经过更广泛验证的 vLLM 路径，也是专家并行要求更明确的那一个。

• GGUF（13 种量化，IQ2_XXS ~52 GB 到 Q5_K_M ~125 GB）——llama.cpp 在消费级 NVIDIA、AMD 或 CPU 设备上的首选。无需 Blackwell，也无需 vLLM。

• MLX（4/6/8 位档位，约 163–221 GB）——Apple Silicon 首选，原生 Metal，附带 MTP 头。

在你选择之前，先说两点坦诚的说明。首先，NVFP4 与 FP8 版本在磁盘占用上仅相差约 8 GB，因为两者都将大型 n-gram 表以 BF16 保存——4 位节省主要落在专家权重上，而非整体体积。NVFP4 在 Blackwell 上的真正优势，是这些专家上的 FP4 张量核心速度，而不是文件大幅变小。其次，模型卡将 NVFP4 描述为一种确定性的权重派生方式，它继承了 abliteration 评估，同时因 4 位专家而带来少量额外质量折损，且这一折损未被量化。它确实未量化——请将其视为更小专家带来的真实但未指明成本，而不是可忽略不计。

正确解读的评估

该卡片报告了在经 vLLM 提供服务的 BF16 构建上，以官方 Qw​en/Qwen3.8-Flash-Next 为对照测得的 abliteration 结果：有害提示的拒答率从 64–100% 降至约 0–3.3%，良性过度拒答保持在接近零的水平，能力与基线相差在 ±2 个百分点以内。关于这些数字，有三点需要正确理解。它们是在 BF16 构建上测得的，本 4-bit 构建是经由推论而非实测继承这些结果。它们是供应商自己的数据，由基于规则的开头短语分类器生成，该系列卡片将其描述为参考性而非发表级——这是对其自身修改的内部测量，而非独立审计。而且它们对上述 NVFP4 的质量权衡只字未提，该卡片也并未对此进行量化。

安全边界 — 仅限研究

卡片上的免责声明直言不讳，它是本页面上绝不能读起来像套话的部分。该模型的安全对齐已被大幅移除：拒绝方向已从残差流中正交化去除，模型将遵从原始 Qwen3.8-Flash-Next 会拒绝的有害、不道德或非法请求。其发布严格限于合法研究——可解释性、AI 安全与拒绝机制研究、红队测试和稳健性评估——作者不对滥用承担任何责任。您需对其生成内容承担全部责任，并且在任何内容触及用户之前，自行添加安全与审核层。Apache 2.0 是许可底线；研究用途的限制门槛位于其上。

关于无审查模型的讨论有两处错误，这张模型卡让人无法忽视这两点。首先，一个成功越狱该模型的探测并非通过安全评估——这正是其标榜的行为。一个去审查化（abliterated）模型是故意在这些探测上失败的；用单一的"你能越狱它吗"测试来衡量它，衡量的是修改是否生效，而非护栏是否坚固。其次，被保留的视觉塔（vision tower）和完整的工具调用路径将真实攻击面扩展到文本之外：图像输入提示注入和智能体工具滥用都完全可用——这正是红队视角将其视为能力探测而非聊天机器人候选的原因。如果你的使用场景是交付一个面向用户的助手，那么这不是你的模型，而这正是设计使然。

OrcaRouter 的适用场景

一个刚发布两天、受控且仅限自托管的构建，正是该用路由而非硬接线的典型场景。当你自行运行这个 NVFP4 构建时，可以搭建一条指向它的路由，并在该构建于负载下表现异常时故障转移到托管模型——单一接口，切换时无需在提供商之间重新接线。具体到评估工作，托管的受审查基线正是你想要的对比对象，而且它就在一键之遥：目录中收录了阿里巴巴的 Qwen3.8-Flash，输入每百万 token 0.15 美元、输出每百万 token 0.47 美元，按提供商标价原价转售、0% 加价。因此，红队测试框架可以在托管的受审查基座与本地未审查构建之间切换，无需第二份合同；任何供应商价格变动都会在当天同步到你的端点。

谁应该下载这个——以及谁不应该

如果你使用的是 Blackwell，想要 Flash-Next 系列中服务器占用最小、同时具备 FP4 张量核心速度的版本，并且正在做这一系列模型所面向的研究工作，请下载 orcarouter/Qwen3.8-Flash-Next-Uncensored-NVFP4。如果你使用的是 Hopper，或者更想要经过更广泛验证的路径，请下载 Qwen3.8-Flash-Next-Uncensored-FP8。如果你使用的是消费级 GPU 或 CPU 主机，请下载 GGUF 版本；如果你使用的是 Apple Silicon，请下载 MLX 版本；如果你的目标是面向用户的部署，那就什么都不用下载。在接受其中任何一个之前，请先阅读 gate 和免责声明——它们是模型的条款，不是形式。

所有五种 Flash-Next 构建 — BF16、GGUF、MLX、FP8 和 NVFP4 — 都收录于Qwen3.8-Flash-Next-Uncensored 集合Hugging Face 上的

这是一个不同的模型，而不是当前这个模型的另一个构建版本：Qwen3.8-27B-Uncensored 是基于不同的基础模型进行 abliterated 的，并且拥有自己的数据集和运行手册。

这些权重在设计上仅限本地使用。如需一个托管基线来对照衡量abliterated构建，Qwen3.8-Flash在OrcaRouter上以提供商列表价格提供服务，零加价——即原版模型，安全对齐保持不变。