Qwen3.6 27B 在新的 AEON ULTIMATE VLLM 镜像上备受关注 @NVIDIAAI DGX SPARK OPTIMIZED！https://github.com/AEON-7/Qwen3.6-27B-AEON-Ultimate-Uncensored-DFlash…

AEON-7/Qwen3.6-27B-AEON-Ultimate-Uncensored-DFlash

来源：https://github.com/AEON-7/Qwen3.6-27B-AEON-Ultimate-Uncensored-DFlash

Qwen3.6-27B-AEON-Ultimate-Uncensored

无损 abliferation · 能力增强 · 为 Blackwell 硬件量化的 NVFP4

BF16-yellow?logo=huggingface) (https://huggingface.co/AEON-7/Qwen3.6-27B-AEON-Ultimate-Uncensored-BF16) NVFP4-yellow?logo=huggingface) (https://huggingface.co/AEON-7/Qwen3.6-27B-AEON-Ultimate-Uncensored-NVFP4) 容器 (https://github.com/AEON-7/vllm-ultimate-dgx-spark/pkgs/container/aeon-vllm-ultimate) 许可证 ☕ 打赏 (https://github.com/AEON-7/AEON-7#-support-the-work)

拒绝数：0 / 100 · 与基线的 KL 散度：0.000492 · 压缩率：49% · 能力：增强

TL;DR

对 Qwen/Qwen3.6-27B (https://huggingface.co/Qwen/Qwen3.6-27B) 进行的完全无审查、能力增强的 abliteration，经过 72 小时连续研究，利用数百个并行 AI 研究代理、业界最佳已发表方法、定制内部技术以及尚未公开的下一代 abliferation 软件预发布分支而产生。

快速开始（DGX Spark / GB10）——复制粘贴

一步完成：拉取容器，拉取此模型（新版本，-Multimodal-NVFP4-MTP-XS 主体——参见模型变体），拉取 DFlash 草稿模型（新版），然后使用经过验证的 DGX Spark 标志提供服务。

# 1) 拉取统一的 AEON vLLM 容器（vLLM 0.23.0, sm_121a, DFlash）
docker pull ghcr.io/aeon-7/aeon-vllm-ultimate:latest

# 2) 拉取此模型（新版本）
huggingface-cli download AEON-7/Qwen3.6-27B-AEON-Ultimate-Uncensored-Multimodal-NVFP4-MTP-XS --local-dir ./aeon-model

# 3) 拉取 DFlash 草稿模型（新版本——z-lab 会推送更新；请始终重新拉取）
huggingface-cli download z-lab/Qwen3.6-27B-DFlash --local-dir ./aeon-drafter

# 4) 提供服务（ENTRYPOINT 为 /bin/bash → 传递 --entrypoint vllm，然后执行 serve ...）
docker run --gpus all --ipc host --network host \
    -v ./aeon-model:/model:ro -v ./aeon-drafter:/drafter:ro \
    --entrypoint vllm ghcr.io/aeon-7/aeon-vllm-ultimate:latest \
    serve /model \
    --quantization modelopt \
    --mamba-cache-dtype float16 \
    --mamba-block-size 256 \
    --reasoning-parser qwen3 \
    --tool-call-parser qwen3_coder \
    --enable-auto-tool-choice \
    --limit-mm-per-prompt '{"image":4,"video":2}' \
    --mm-encoder-tp-mode data \
    --gpu-memory-utilization 0.85 \
    --enable-chunked-prefill \
    --enable-prefix-caching \
    --trust-remote-code \
    --speculative-config '{"method":"dflash","model":"/drafter","num_speculative_tokens":12}'

OpenAI 兼容端点会在 http://localhost:8000/v1 启动。DFlash 草稿模型在首次下载时会自动门控（一键接受条款）。

有关完整的分步指南、docker-compose 配置文件、A100/H100 BF16 路径以及每个标志的详细说明，请参见下方的快速开始——DGX Spark和配置参考。

性能——DGX Spark DFlash 对比原始基线

这是重点。 在 DGX Spark / GB10 上，AEON DFlash 容器将默认的“能跑，但感觉很慢”的基线转变为可用的长上下文本地代理模型。

v0.23.0 构建——原始 vanilla 对比最大化优化

在当前生产镜像 ghcr.io/aeon-7/aeon-vllm-ultimate:latest（vLLM 0.23.0 + AEON sm_121a 构建 + DFlash num_speculative_tokens: 12）上测量，单流（c=1），按类别划分：

对比原始 vanilla vllm/vllm-openai 基线约 10.5 tok/s（无 DFlash，无 sm_121a 优化）→ 解码速度提升最高达 5.3 倍（平均约 4 倍），并且现在可以干净地扩展到 c=64 并发而不会崩溃（修复前的镜像在并发推测解码下会崩溃——参见我们为 DGX Spark 修复的问题）。

原始基线说明： 原始/未优化的数据来自 vanilla vLLM（无 DFlash，无 AEON/sm_121a 优化），并且是暂定的——将在当前版本上使用全新完全 vanilla 重新基准测试进行更新。

之前的 qwen36-v4 参考（DFlash k=15）

以下吞吐量表在较早的 qwen36-v4 镜像上测得，DFlash k=15。生产容器和配方现已统一到 ghcr.io/aeon-7/aeon-vllm-ultimate:latest，采用 DFlash num_speculative_tokens: 12（请参见下方的为何调整 Spark 配方以适配长上下文）。此处给出的单流吞吐量数据代表 Spark DFlash 路径；统一镜像的具体优势在于长上下文草稿接受率——在约 9k token 上下文时，从修复前镜像的 19.7% 提升至 45%（2.3 倍提升），而非短上下文 tok/s。

† 这些单流 tok/s（37.56 / 10.49）在较早的 qwen36-v4 镜像上测得，DFlash k=15，而非 aeon-vllm-ultimate:latest 的 n=12。统一镜像的具体优势在于长上下文草稿接受率（约 9k token 时 45% 对比 19.7%），而非这些短上下文 tok/s——参见为何调整 Spark 配方以适配长上下文。

平均单流解码提升： 相比原始静态 eager 基线提升 +258%。

单流解码

本节及下方并发表中的所有数据均在较早的 qwen36-v4 镜像上测得，DFlash k=15（参见上方说明）——代表 Spark DFlash 路径，而非在 aeon-vllm-ultimate:latest 的 n=12 上重新运行。

实际代理并发

在 c=16 时，优化后的容器使活跃流的响应速度大幅提升。总吞吐量在结构化代理/工具工作负载上提升最大，并且每个类别的 TPOT 均有下降。（以下标有 AEON 的列代表 AEON 容器上的 DFlash 路径。）

压力饱和

c=256 是压力测试，不推荐作为交互式设置。基线可以通过让每个流缓慢运行来报告较高的总吞吐量。AEON DFlash 路径使每个活跃流的 TPOT 远低于基线，但在 c=256 时请求会严重排队，TTFT 升至分钟级别。

AEON 容器新增内容

• 统一的生产镜像：ghcr.io/aeon-7/aeon-vllm-ultimate:latest（= 标签 :2026-06-11-pr41703；回滚标签 :2026-06-04-pr44389）。该单一镜像取代了较早的 qwen36-v3 / v4 / v5 逐版本容器系列。
• FlashInfer NVFP4 GEMM 路径
• 来自 vLLM PR #40898 的 DFlash 滑动窗口注意力兼容性补丁（草稿模型的 5 层中有 4 层使用滑动窗口；较早的镜像将它们作为全注意力运行，导致草稿在大约 2048 个 token 后失效）
• vLLM PR #41703 使 --enable-prefix-caching 在与 DFlash 配合使用时免受损坏
• 为 GB10 / sm_121a 选择的 CUTLASS NVFP4 快速路径
• DFlash num_speculative_tokens: 12（已验证的生产默认值），使用 z-lab/Qwen3.6-27B-DFlash，草稿模型后端保持默认
• 启用了 Qwen3 推理解析器和 Qwen3-Coder 工具调用解析器
• 打包了网关/生产/基准测试配置文件，使用户无需手动组装完整的 vLLM 命令

为何调整 Spark 配方以适配长上下文

z-lab Qwen3.6-27B DFlash 草稿模型是一个滑动窗口模型——其 5 层中有 4 层使用滑动窗口注意力（窗口大小 2048）。vLLM PR #40898（包含在 aeon-vllm-ultimate:latest 中）将这些层作为真正的 SWA 运行；较早的镜像将它们作为全注意力运行，因此一旦上下文超过约 2048 个 token，草稿就会失效。PR #41703 还使 --enable-prefix-caching 在与 DFlash 配合使用时免受损坏。结果：长上下文草稿保持有效；短上下文（2048 个 token 以下，一个窗口）保持不变。

DDTree v5 研究路线

DDTree 是下一个明显的性能目标，但它必须在不丢失多模态、推理、工具调用、NVFP4 或 OpenAI 兼容网关表面的情况下落地到 vLLM 中。DDTree 研究路线（较早的 qwen36-v5 实验性容器）已被统一的 ghcr.io/aeon-7/aeon-vllm-ultimate:latest 镜像取代用于生产环境——实际部署时请拉取该镜像：

docker pull ghcr.io/aeon-7/aeon-vllm-ultimate:latest

阅读完整的 DDTree 卡片和实验室记录：docs/qwen36-ddtree-card.md。当前状态一句话概括：扁平 DFlash 仍然是统一 AEON 容器上的生产路径；DDTree 仅用于研究。 统一镜像保留了相同的 NVFP4、DFlash、多模态、推理、工具调用和 OpenAI 兼容 vLLM 表面，但真正的非扁平分支提交仍仅用于研究。实施计划见 docs/ddtree-vllm-integration-plan.md。M1 脚手架和当前实验性 Docker 上下文位于 container/qwen36-v5-ddtree-experimental/。DDTree 卡片记录了：

• 当前容器标签和摘要，
• 当前可用的功能，
• 从 M1 到 M53 的试错路径，
• 当前 M53 非扁平探测状态，
• 已知的阻塞问题（分支状态 GDN 重放、融合分支注意力、已接受分支提交），
• 基准测试上下文和注意事项，
• 社区最有可能推动项目向前发展的方向。

原始基准测试文件：

• bench/results/qwen36_dirty_baseline_eager_20260510T034652Z.json
• bench/results/qwen36_v4_fi0611_noprefix_full_sweep_20260510T065838Z.json
• bench/results/qwen36_v4_fi0611_noprefix_true_single_20260510T065020Z.json

DFlash 扫描使用了涵盖编程、数学、推理、散文、日常语言和提取/JSON 的自然提示。故意使用了短上下文基准测试配置文件以隔离解码/调度器行为：--max-model-len 2048，--max-num-seqs 256，禁用前缀缓存，启用思考，200 个输出 token，每个点最少 16 个样本，20% 修剪中位数。对于生产 DFlash 网关使用，前缀缓存依赖于工作负载：当许多代理共享稳定的提示前缀时很有价值，但 DDTree 研究模式在分支状态正确性开发期间保持其关闭。

我们为 DGX Spark 修复的问题

所有 AEON 模型都运行在一个统一的容器上——ghcr.io/aeon-7/aeon-vllm-ultimate:latest（= :2026-06-18-v0.23.0-dflashfix；回滚 :2026-06-11-pr41703）——vLLM v0.23.0，从源代码为 GB10 / sm_121a 构建，并与 AEON 推测解码栈合并。

模型变体

六种发布格式，涵盖 DGX Spark、RTX PRO 6000、RTX 5090 和前 Blackwell 硬件：