ghcr.io/aeon-7/vllm-spark-omni-q36:v2.0

Qwen3.6-35B-A3B-heretic NVFP4 + DFlash on DGX Spark

在NVIDIA DGX Spark（GB10 / sm_121a）上使用DFlash推测解码的AEON-7/Qwen3.6-35B-A3B-heretic-NVFP4的生产稳定部署。

AEON-7/Qwen3.6-35B-A3B-heretic-NVFP4

[!IMPORTANT] 请先阅读要求部分。此镜像及其权重专为DGX Spark（GB10 / sm_120-121 Blackwell）优化。未经重新构建，它将无法在Hopper、Ampere、B200或其他Blackwell变体上运行。

[!IMPORTANT] 请先阅读要求部分。此镜像及其权重专为DGX Spark（GB10 / sm_120-121 Blackwell）优化。未经重新构建，它将无法在Hopper、Ampere、B200或其他Blackwell变体上运行。

AEON-7/Qwen3.6-35B-A3B-heretic-NVFP4

z-lab/Qwen3.6-35B-A3B-DFlash

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

:2026-06-18-v0.23.0-dflashfix

:2026-06-11-pr41703

Quickstart (copy-paste)

完整步骤 — 拉取容器、NVFP4权重和最新的DFlash drafter，然后使用经过验证的DGX-Spark标志启动服务。（此35B-A3B drafter不需要--mamba-block-size — 它是全注意力模型。）在DGX Spark（GB10 / sm_121a）上运行；请先查看硬件要求。

--mamba-block-size

# 1. 拉取统一vLLM容器（匿名拉取）
docker pull ghcr.io/aeon-7/aeon-vllm-ultimate:latest

# 2. 拉取NVFP4模型权重（此仓库权重）
huggingface-cli download AEON-7/Qwen3.6-35B-A3B-heretic-NVFP4 --local-dir ./aeon-model

# 3. 拉取DFlash drafter — 确保最新（2026-04-19前克隆的需重新拉取）
huggingface-cli download z-lab/Qwen3.6-35B-A3B-DFlash --local-dir ./aeon-drafter

# 4. 启动服务（ENTRYPOINT为/bin/bash，因此需传递--entrypoint vllm后接serve命令...）
docker run --gpus all --rm -p 8000:8000 \
-v ./aeon-model:/model:ro \
-v ./aeon-drafter:/drafter:ro \
--entrypoint vllm \
ghcr.io/aeon-7/aeon-vllm-ultimate:latest serve /model \
--served-model-name qwen36-35b-heretic qwen36-fast qwen36-deep \
--host 0.0.0.0 --port 8000 \
--quantization compressed-tensors \
--max-model-len 262144 \
--max-num-seqs 64 \
--max-num-batched-tokens 16384 \
--gpu-memory-utilization 0.85 \
--enable-chunked-prefill \
--enable-prefix-caching \
--trust-remote-code \
--limit-mm-per-prompt '{"image":4,"video":2}' \
--enable-auto-tool-choice --tool-call-parser qwen3_coder \
--reasoning-parser qwen3 \
--attention-backend flash_attn \
--speculative-config '{"method":"dflash","model":"/drafter","num_speculative_tokens":11}'

[!NOTE] 可选 — 更快重启：在docker run命令中添加-v ./vllm-cache:/root/.cache/vllm（需先执行mkdir -p ./vllm-cache），以在容器重启时保留FlashInfer NVFP4 GEMM自动调谐器和CUDA图捕获。首次启动仍需约10–12分钟，但后续重启可缩短至约3–5分钟。

可选 — 更快重启：在docker run命令中添加-v ./vllm-cache:/root/.cache/vllm（需先执行mkdir -p ./vllm-cache），以在容器重启时保留FlashInfer NVFP4 GEMM自动调谐器和CUDA图捕获。首次启动仍需约10–12分钟，但后续重启可缩短至约3–5分钟。

-v ./vllm-cache:/root/.cache/vllm

docker run

mkdir -p ./vllm-cache

有关docker-compose部署、3个别名设置以及每个标志的原理，请参见下文的部署（compose + 完整步骤）。

Headline performance (measured)

v0.23.0 build — current production image

在当前生产镜像ghcr.io/aeon-7/aeon-vllm-ultimate:latest（vLLM 0.23.0 + AEON sm_121a构建 + DFlash num_speculative_tokens: 11）上按类别测量，单流（c=1）。混合领域提示集，enable_thinking=false以获得清晰的解码速率测量：

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

num_speculative_tokens: 11

enable_thinking=false

六个类别的单流解码平均约为97 tok/s（开放式散文最低75 tok/s，数学/推理最高124 tok/s，其中DFlash接受率最高）。此A3B MoE速度很快：数学/代码/推理提示的单流解码达到120+ tok/s，因为DFlash drafter接受了46–48%的提议；开放式散文/提取在较低接受率下稳定在75–92 tok/s左右。

[!NOTE] 标准基准待确定。目前尚无此模型的标准vanilla-vLLM基准 — 尚未在当前版本上运行全新的完全vanilla基准测试（无DFlash，无AEON/sm_121a优化），因此此处不引用标准与优化版本的速度提升倍数。上述数据是在优化的aeon-vllm-ultimate:latest（vLLM 0.23.0）构建上测量的。此镜像为DGX-Spark带来的优势是支持c=64并发（之前的镜像在推测解码下c≥32时崩溃）以及长上下文draft接受率的稳定性 — 详见DGX Spark的修复内容。

标准基准待确定。目前尚无此模型的标准vanilla-vLLM基准 — 尚未在当前版本上运行全新的完全vanilla基准测试（无DFlash，无AEON/sm_121a优化），因此此处不引用标准与优化版本的速度提升倍数。上述数据是在优化的aeon-vllm-ultimate:latest（vLLM 0.23.0）构建上测量的。此镜像为DGX-Spark带来的优势是支持c=64并发（之前的镜像在推测解码下c≥32时崩溃）以及长上下文draft接受率的稳定性 — 详见DGX Spark的修复内容。

aeon-vllm-ultimate:latest

Concurrency scaling (1 → 64)

聚合吞吐量平稳攀升至c=64且零崩溃 — 正是之前的镜像（vllm-spark-omni-q36:v1.2）在推测解码下c≥32时崩溃的场景。在c=64时，峰值聚合吞吐量约为740 tok/s（数学）、717 tok/s（提取/JSON）、669 tok/s（推理）；吞吐量由DFlash接受率驱动，因此创意文本类别较低（c=64时散文约430 tok/s，自然语言约474 tok/s，此时draft接受率约22–27%，而结构化文本约46–55%）。随着并发增加，每个活动流的解码和TPOT优雅降级。

vllm-spark-omni-q36:v1.2

长上下文（16k / 32k）

在相同镜像上，以真实的智能体历史对话深度测量单流（c=1）性能：

草稿接受率不会随上下文增长而下降——在32k上下文时，各分类的接受率保持在42–58%。（与27B草稿模型不同，z-lab Qwen3.6-35B-A3B DFlash草稿模型是8层全注意力模型，因此从一开始就不存在滑动窗口性能下降问题——此处长上下文性能的稳定性是草稿模型的固有特性，且前缀缓存安全的DFlash路径（PR #41703）使--enable-prefix-caching免受损坏影响。）预填充速度保持较快（~4.3–5.1k tok/s），因此在32k上下文、c=1时首词输出时间（TTFT）为个位数秒级。

[!NOTE] 2026年6月19日基于确切发布的快速启动指南重新验证（全新拉取aeon-vllm-ultimate:latest镜像 + 修正权重，DFlash n=11）：多模态视觉功能端到端工作正常（图像探针测试7/7通过，0次视觉加载跳过），且在c=64时吞吐量分布零错误复现——推理分类在c=32时峰值800 tok/s，结构化分类在c=64时705–781 tok/s，创意文本在c=64时430–474 tok/s；短上下文下DFlash接受率为46–55%（结构化）/ 22–27%（创意文本），在16–20K tokens时保持40–45%。

完整基准测试结果见HF模型卡片：AEON-7/Qwen3.6-35B-A3B-heretic-NVFP4。

⚠️ 硬性要求（请先阅读）

硬件（必须满足——镜像专为以下配置构建）

镜像无法在以下设备上运行：

• H100/H200（sm_90 — Hopper架构）
• A100/A40（sm_80 — Ampere架构）
• B200/GB200（sm_100 — 不同Blackwell变体；需从源码重新构建）
• L40S/RTX 4090/RTX PRO 6000（sm_89/sm_120桌面级变体 — 参见docs/build.md）

软件（必须满足）

DFlash草稿模型（无需授权）

DFlash草稿模型z-lab/Qwen3.6-35B-A3B-DFlash现已成为公开HF仓库——可直接通过hf download下载，无需令牌。

[!WARNING] 若您在2026年4月19日前克隆过草稿模型，必须重新拉取。早期草稿模型存在长上下文bug，会在超过~16K tokens后导致cudaErrorIllegalAddress崩溃。修复版本已于2026年4月19日在HF发布。

部署（Compose + 完整步骤）

如需一键复制粘贴完成所有拉取和服务部署，请参见顶部的“快速启动（复制粘贴）”部分。本节涵盖docker-compose流程、标准磁盘布局及各参数的使用理由。

# 1. 预检 — 确认匿名拉取正常
docker pull ghcr.io/aeon-7/aeon-vllm-ultimate:latest

# 2. 将两个模型拉取到标准布局
sudo mkdir -p /opt/qwen36 && sudo chown $USER:$USER /opt/qwen36
cd /opt/qwen36
export HF_HUB_ENABLE_HF_TRANSFER=1
hf download AEON-7/Qwen3.6-35B-A3B-heretic-NVFP4 --local-dir ./qwen36-nvfp4 &
hf download z-lab/Qwen3.6-35B-A3B-DFlash --local-dir ./qwen36-dflash &
wait

# 3. 获取compose文件
curl -fsSL https://raw.githubusercontent.com/AEON-7/Qwen3.6-35B-A3B-heretic-NVFP4-DFlash/main/examples/docker-compose.yml \
-o docker-compose.yml

# 4. 启动服务（3-5分钟后显示"Application startup complete"）
docker compose up -d
docker compose logs -f

# 5. 冒烟测试（使用temperature=0启用贪婪解码→最大化DFlash加速）
curl http://localhost:8000/v1/chat/completions \
-H 'Content-Type: application/json' \
-d '{
"model": "qwen36-fast",
"messages": [{"role":"user","content":"What is 17 × 23?"}],
"max_tokens": 2048,
"temperature": 0
}'

已验证的vLLM配置（aeon-vllm-ultimate:latest）

统一镜像的ENTRYPOINT为/bin/bash，因此直接使用docker run时必须传递--entrypoint vllm，然后执行serve ...（compose使用entrypoint: vllm + command: serve ...）。在DGX Spark上针对此模型的已验证生产环境参数如下：

vllm serve /models/qwen36 \
--served-model-name qwen36-35b-heretic qwen36-fast qwen36-deep \
--host 0.0.0.0 --port 8000 \
--quantization compressed-tensors \
--max-model-len 262144 \
--max-num-seqs 64 \
--max-num-batched-tokens 16384 \
--gpu-memory-utilization 0.85 \
--enable-chunked-prefill \
--enable-prefix-caching \
--trust-remote-code \
--limit-mm-per-prompt '{"image":4,"video":2}' \
--enable-auto-tool-choice --tool-call-parser qwen3_coder \
--reasoning-parser qwen3 \
--attention-backend flash_attn \
--speculative-config '{"method":"dflash","model":"/models/qwen36-dflash","num_speculative_tokens":11}'

与旧版vllm-spark-omni-q36:v1.2配置相比的主要变化：

针对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推测解码栈的容器。

TORCH_CUDA_ARCH_LIST=12.1a ENABLE_NVFP4_SM100=0 _C_stable_libtorch cudaErrorIllegalAddress --gpu-memory-utilization ≤0.70

本模型的修复结果：可扩展至64个并发请求且无崩溃（之前的vllm-spark-omni-q36:v1.2镜像在推测解码下c≥32时会崩溃），从短提示到32k token智能体历史均保持DFlash草稿接受率，单流服务速度约为75–132 tok/s，峰值聚合速度约为700–800 tok/s（跨类别由接受率驱动），并且——自2026-06-18视觉修复后——多模态图像输入功能正常（7/7验证通过）。本模型与原生vanilla-vLLM的对比仍需等待全新的纯原生重新基准测试，因此暂未引用原生与优化版本的加速倍数。

项目仓库 README（补充）

Qwen3.6-35B-A3B-heretic NVFP4 + DFlash on DGX Spark

在 NVIDIA DGX Spark（GB10 / sm_121a）上使用 https://github.com/z-lab/dflash 推测解码的 https://huggingface.co/AEON-7/Qwen3.6-35B-A3B-heretic-NVFP4 生产级稳定部署。

[!IMPORTANT] 请先阅读要求部分。 此镜像及其权重专为 DGX Spark（GB10 / sm_120-121 Blackwell）调优。在未重新构建的情况下，它无法在 Hopper、Ampere、B200 或其他 Blackwell 变体上运行。

---

快速启动（复制粘贴）

完整步骤 — 拉取容器、NVFP4 权重和全新的 DFlash 草稿模型，然后使用经过验证的 DGX-Spark 标志启动服务。（此 35B-A3B 草稿模型无需 --mamba-block-size — 它采用全注意力机制。）在 DGX Spark（GB10 / sm_121a）上运行；请先查看硬性要求。

# 1. Pull the unified vLLM container (anonymous pull)
docker pull ghcr.io/aeon-7/aeon-vllm-ultimate:latest

# 2. Pull the NVFP4 model weights (this repo's weights)
huggingface-cli download AEON-7/Qwen3.6-35B-A3B-heretic-NVFP4 --local-dir ./aeon-model

# 3. Pull the DFlash drafter — FRESH (re-pull if cloned before 2026-04-19)
huggingface-cli download z-lab/Qwen3.6-35B-A3B-DFlash --local-dir ./aeon-drafter

# 4. Serve (ENTRYPOINT is /bin/bash, so pass --entrypoint vllm then serve ...)
docker run --gpus all --rm -p 8000:8000 \
-v ./aeon-model:/model:ro \
-v ./aeon-drafter:/drafter:ro \
--entrypoint vllm \
ghcr.io/aeon-7/aeon-vllm-ultimate:latest serve /model \
--served-model-name qwen36-35b-heretic qwen36-fast qwen36-deep \
--host 0.0.0.0 --port 8000 \
--quantization compressed-tensors \
--max-model-len 262144 \
--max-num-seqs 64 \
--max-num-batched-tokens 16384 \
--gpu-memory-utilization 0.85 \
--enable-chunked-prefill \
--enable-prefix-caching \
--trust-remote-code \
--limit-mm-per-prompt '{"image":4,"video":2}' \
--enable-auto-tool-choice --tool-call-parser qwen3_coder \
--reasoning-parser qwen3 \
--attention-backend flash_attn \
--speculative-config '{"method":"dflash","model":"/drafter","num_speculative_tokens":11}'

[!NOTE] 可选 — 更快重启： 在 docker run 命令中添加 -v ./vllm-cache:/root/.cache/vllm（需先执行一次 mkdir -p ./vllm-cache），以在容器重启时保留 FlashInfer NVFP4 GEMM 自动调谐器和 CUDA 图捕获。首次启动仍需约 10–12 分钟，但后续重启可缩短至约 3–5 分钟。

有关 docker-compose 部署、3 个别名设置以及各标志的原理说明，请参见下方的部署（compose + 完整步骤）。

---

主要性能指标（实测）

v0.23.0 构建版本 — 当前生产镜像

在当前生产镜像 ghcr.io/aeon-7/aeon-vllm-ultimate:latest（vLLM 0.23.0 + AEON sm_121a 构建 + DFlash num_speculative_tokens: 11）上按类别实测，单流（c=1）。混合领域提示集，enable_thinking=false 以确保解码速率测量准确：

单流解码在六个类别中的平均速度为 ~97 tok/s（开放式散文最低 75 tok/s，DFlash 接受率最高的数学/推理任务最高 124 tok/s）。此 A3B MoE 速度很快：数学/代码/推理提示的单流速度可达 120+ tok/s，因为 DFlash 草稿模型接受了 46–48% 的提议；开放式散文/提取任务在较低接受率下速度稳定在 75–92 tok/s。

[!NOTE] 标准基准待测定。 目前尚无此模型的标准 vanilla-vLLM 基准——当前版本的全新纯 vanilla 基准测试（无 DFlash、无 AEON/sm_121a 优化）仍待运行，因此此处不引用标准与优化版本的速度提升倍数。上述数据均在优化后的 aeon-vllm-ultimate:latest（vLLM 0.23.0）构建版本上测得。此镜像为 DGX Spark 带来的优势在于支持 c=64 并发（先前镜像在推测解码下 c≥32 时会崩溃）以及长上下文草稿接受率稳定性——详见我们为 DGX Spark 修复的问题。

并发扩展（1 → 64）

部署（compose + 完整步骤）

如需一键复制粘贴以拉取所有内容并启动服务，请参见顶部的快速开始（复制粘贴）。本节涵盖docker-compose流程、标准磁盘布局以及每个标志的原理说明。

# 1. 预检检查 — 确认匿名拉取正常
docker pull ghcr.io/aeon-7/aeon-vllm-ultimate:latest

# 2. 将两个模型拉取到标准布局中
sudo mkdir -p /opt/qwen36 && sudo chown $USER:$USER /opt/qwen36
cd /opt/qwen36
export HF_HUB_ENABLE_HF_TRANSFER=1
hf download AEON-7/Qwen3.6-35B-A3B-heretic-NVFP4 --local-dir ./qwen36-nvfp4 &
hf download z-lab/Qwen3.6-35B-A3B-DFlash --local-dir ./qwen36-dflash &
wait

# 3. 获取compose文件
curl -fsSL https://raw.githubusercontent.com/AEON-7/Qwen3.6-35B-A3B-heretic-NVFP4-DFlash/main/examples/docker-compose.yml \
-o docker-compose.yml

# 4. 启动服务器（首次显示“Application startup complete”需要3-5分钟）
docker compose up -d
docker compose logs -f

# 5. 冒烟测试（temperature=0以启用贪婪模式→最大化DFlash加速）
curl http://localhost:8000/v1/chat/completions \
-H 'Content-Type: application/json' \
-d '{
"model": "qwen36-fast",
"messages": [{"role":"user","content":"What is 17 × 23?"}],
"max_tokens": 2048,
"temperature": 0
}'

经过验证的vLLM配置（aeon-vllm-ultimate:latest）

统一镜像的ENTRYPOINT为/bin/bash，因此直接docker run必须传递--entrypoint vllm，然后是serve ...（compose使用entrypoint: vllm + command: serve ...）。在DGX Spark上针对此模型经过验证的生产环境标志如下：

vllm serve /models/qwen36 \
--served-model-name qwen36-35b-heretic qwen36-fast qwen36-deep \
--host 0.0.0.0 --port 8000 \
--quantization compressed-tensors \
--max-model-len 262144 \
--max-num-seqs 64 \
--max-num-batched-tokens 16384 \
--gpu-memory-utilization 0.85 \
--enable-chunked-prefill \
--enable-prefix-caching \
--trust-remote-code \
--limit-mm-per-prompt '{"image":4,"video":2}' \
--enable-auto-tool-choice --tool-call-parser qwen3_coder \
--reasoning-parser qwen3 \
--attention-backend flash_attn \
--speculative-config '{"method":"dflash","model":"/models/qwen36-dflash","num_speculative_tokens":11}'

与旧版vllm-spark-omni-q36:v1.2配置相比的主要变化：

DFlash草稿器是向统一镜像的无回归迁移——8层全注意力草稿器在各并发数下的表现与旧镜像一致（无长上下文崩溃问题，且n≈11以上无性能增益），因此本次改进的价值在于统一容器 + 修复c≥32并发崩溃问题，而非原始单流速度提升。

[!NOTE] 若设置max_tokens（当前）：vllm-spark-omni-q36的各版本系列（v1/v1.2/v2）已被统一镜像ghcr.io/aeon-7/aeon-vllm-ultimate:latest取代，适用于所有生产环境。拉取该镜像——它内置了GB10 CUTLASS NVFP4默认配置以及下文所述的v0.23.0修复集。

---

针对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推测解码栈。

该模型的修复结果： 可扩展至64个并发请求且无崩溃（旧版vllm-spark-omni-q36:v1.2镜像在推测解码下并发数c≥32时会崩溃），在从短提示到32k token智能体历史的场景中均保持DFlash草稿接受率，并以~75–132 tok/s单流速度 / ~700–800 tok/s峰值聚合速度（跨类别由接受率驱动）提供服务；且自2026-06-18视觉修复起，多模态图像输入功能正常（7/7验证）。该模型与原生vLLM的对比基准测试仍待最新原生版本重新执行，因此暂未提供原生与优化版本的速度提升倍数。

---

v2版本（当前发布版）的变更内容

早期v1权重从***键中移除了language_model.前缀，以匹配纯文本模型类——这需要vLLM注册器+键重命名补丁，且在生产环境中不稳定（实际对话会话中偶发cudaErrorIllegalAddress崩溃）。

v2（当前版本）直接从tvall43/Qwen3.6-35B-A3B-heretic使用AutoModelForImageTextToText重新量化，保留：

• 完整多模态架构（Qwen3_5MoeForConditionalGeneration）
• 27块ViT视觉编码器（BF16，未使用NVFP4量化）——⚠️这些视觉张量最初错误嵌套在model.language_model.visual.*下，导致vLLM静默跳过加载（图像输入→!!!!），直至2026-06-18视觉修复（见下文）
• 原始model.language_model.layers.X.*键结构——vLLM多模态类可原生加载，无需前缀移除补丁
• 30层线性注意力（Mamba/GDN，fp32）+ 10层全注意力
• 每层256个路由专家×8个激活专家 + 1个共享专家
• 所有122,880个专家级NVFP4键（每个专家均经过校准）

vLLM通过标准多模态类提供服务——推理热路径中的代码路径更少，负载下稳定性显著提升。Travis运行了多个实时对话会话（Celina），未出现单次崩溃，而v1版本几乎每次交互都会崩溃。

视觉修复（2026-06-18）—— 图像输入现已正常

v2保留了ViT的BF16权重，但量化时的ignore正则表达式将333个视觉张量嵌套深度多了一层——错误地命名为model.language_model.visual.*（语言模型的子节点），而非vLLM的Qwen3_5MoeForConditionalGeneration预期的同级节点model.visual.*。vLLM静默跳过加载整个视觉塔并以未初始化状态运行，因此文本输出正常，但任何图像输入都会返回!!!!乱码。