TL;DR

A fully uncensored, capability-enhanced abliteration of Qwen/Qwen3.6-27B, produced over 72 hours of continuous research drawing on hundreds of parallel AI research agents, the industry's best published methodologies, custom in-house techniques, and yet-unreleased pre-public branches of next-generation abliteration software.

Quickstart (DGX Spark / GB10) — copy-paste

⚠️ This container is DGX Spark / GB10 only — it is not portable. aeon-vllm-ultimate is built for the Spark's ARM64 CPU and GB10's sm121a NVFP4 kernels. On an x86 / amd64 host it will not start (/usr/bin/bash: cannot execute binary file — wrong CPU arch); on a non-Blackwell GPU (RTX 4090 / L40S = Ada sm89, A100/H100 = Ampere/Hopper) the NVFP4 path can't run (NVFP4 needs Blackwell). For any hardware other than the DGX Spark, do not pull this container — instead run the portable HuggingFace weights on your own vLLM build, picking the right variant + spec-decode method for your GPU from the Hardware compatibility matrix. (An x86 + Blackwell image may come in a future release.)

One block: pull the container, pull this model (fresh, the -Multimodal-NVFP4-MTP-XS body — see Model Variants), pull the DFlash drafter (fresh), then serve with the vetted DGX Spark flags.

# 1) Pull the unified AEON vLLM container (vLLM 0.23.0, sm_121a, DFlash)
docker pull ghcr.io/aeon-7/aeon-vllm-ultimate:latest
2) Pull this model (fresh)
huggingface-cli download AEON-7/Qwen3.6-27B-AEON-Ultimate-Uncensored-Multimodal-NVFP4-MTP --local-dir ./aeon-model
3) Pull the DFlash drafter (fresh — z-lab pushes updates; always re-pull)
huggingface-cli download z-lab/Qwen3.6-27B-DFlash --local-dir ./aeon-drafter
4) Serve (ENTRYPOINT is /bin/bash → pass --entrypoint vllm, then 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 float32 \
  --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 \
  --max-num-seqs 16 \
  --max-num-batched-tokens 16384 \
  --gpu-memory-utilization 0.70 \
  --enable-chunked-prefill \
  --enable-prefix-caching \
  --trust-remote-code \
  --speculative-config '{"method":"dflash","model":"/drafter","numspeculativetokens":10}'

--gpu-memory-utilization 0.70 is the safe default. The Spark's 128 GB is unified (CPU + GPU share one LPDDR5X pool), so over-allocating page-thrashes — which shows up as slowdowns, agent loops, and even engine crashes, not an OOM error. 0.70 leaves headroom for co-located services (ASR/TTS) and the OS. Raise to 0.85 only if the LLM is the sole GPU workload (and watch free -h); never exceed 0.88. See Troubleshooting.

OpenAI-compatible endpoint comes up at http://localhost:8000/v1. The DFlash drafter is auto-gated on first download (one-click terms acceptance). For the full step-by-step walkthrough, docker-compose profiles, the A100/H100 BF16 path, and the per-flag rationale, see QuickStart — DGX Spark and Configuration reference below.

Performance — DGX Spark DFlash vs Raw Baseline

This is the headline. On DGX Spark / GB10, the AEON DFlash container turns the default “it runs, but it feels slow” baseline into a usable long-context local agent model.

v0.23.0 build — stock vanilla vs maximally optimized

Measured on the current production image ghcr.io/aeon-7/aeon-vllm-ultimate:latest (vLLM 0.23.0 + AEON sm121a build + DFlash numspeculative_tokens: 10), single-stream (c=1), by category:

| Category | 🟢 Decode tok/s | TTFT p50 | TPOT p50 | Prefill (PP) | DFlash accept | |---|---:|---:|---:|---:|---:| | Coding | 42 | 140 ms | 23.9 ms | 322 tok/s | 34% | | Math | 47 | 244 ms | 21.1 ms | 229 tok/s | 42% | | Reasoning | 56 | 234 ms | 17.8 ms | 183 tok/s | 50% | | Prose | 34 | 146 ms | 29.4 ms | 220 tok/s | 27% | | Natural language | 38 | 137 ms | 26.1 ms | 248 tok/s | 31% | | Extraction / JSON | 44 | 246 ms | 22.6 ms | 195 tok/s | 37% |

vs a stock vanilla vllm/vllm-openai baseline of ~10.5 tok/s (no DFlash, no sm_121a optimizations) → up to 5.3× faster decode (≈4× average), and it now scales cleanly to c=64 concurrent with no crash (the pre-fix image crashed under concurrent speculative decoding — see What we fixed for the DGX Spark).

Stock baseline note: the stock/un-optimized figures are vanilla vLLM (no DFlash, no AEON/sm_121a optimizations) and are provisional — to be refreshed with a fresh fully-vanilla re-benchmark on the current version.

Earlier qwen36-v4 reference (DFlash k=15)

The throughput table below was measured on the earlier qwen36-v4 image with DFlash k=15. The production container and recipe have since been unified onto ghcr.io/aeon-7/aeon-vllm-ultimate:latest with DFlash numspeculativetokens: 10 (see why long context below). The single-stream throughput figures here are representative of the Spark DFlash path; the unified image's specific win is long-context draft acceptance — 45% vs 19.7% on the pre-fix image (a 2.3× gain) at ~9k-token context — not short-context tok/s.

| Deployment | Container | DFlash | CUDA graphs | Tool calling | Avg c=1 decode | |---|---|---:|---:|---:|---:| | 🔴 Raw baseline | vllm/vllm-openai:nightly | off | off (--enforce-eager) | off | 10.49 tok/s | | 🟢 AEON DFlash | ghcr.io/aeon-7/aeon-vllm-ultimate:latest | n=10 | on | on | 37.56 tok/s † |

† These single-stream tok/s (37.56 / 10.49) were measured on the earlier qwen36-v4 image at DFlash k=15, not on aeon-vllm-ultimate:latest at n=10. The unified image's specific gain is long-context draft acceptance (45% vs 19.7% at ~9k tokens), not these short-context tok/s — see why long context.

Average single-stream decode improvement: +258% over the raw stock eager baseline.

Single-Stream Decode

All figures in this section and the concurrency tables below were measured on the earlier qwen36-v4 image at DFlash k=15 (see the note above) — representative of the Spark DFlash path, not a re-run on aeon-vllm-ultimate:latest at n=10.

| Category | 🔴 Raw baseline | 🟢 AEON DFlash | Approx. speed increase | DFlash TTFT | DFlash TPOT | |---|---:|---:|---:|---:|---:| | Coding | 10.70 tok/s | 31.89 tok/s | +198% | 191 ms | 30.5 ms | | Math | 10.01 tok/s | 37.76 tok/s | +277% | 225 ms | 25.5 ms | | Reasoning | 10.54 tok/s | 42.41 tok/s | +303% | 221 ms | 22.6 ms | | Prose | 10.59 tok/s | 31.85 tok/s | +201% | 212 ms | 30.4 ms | | Natural language | 10.56 tok/s | 31.99 tok/s | +203% | 183 ms | 30.3 ms | | Extraction / JSON | 10.56 tok/s | 49.48 tok/s | +369% | 227 ms | 19.2 ms | | Average | 10.49 tok/s | 37.56 tok/s | +258% | ~210 ms | ~26.4 ms |

Practical Agent Concurrency

At c=16, the optimized container keeps active streams much more responsive. Aggregate throughput improves most on structured agent/tool workloads, and TPOT drops across every category. (Columns labelled AEON below are the DFlash path on the AEON container.)

| Category | 🔴 Raw c=16 aggregate / TPOT | 🟢 AEON c=16 aggregate / TPOT | Aggregate change | |---|---:|---:|---:| | Coding | 134.47 tok/s / 115.1 ms | 144.45 tok/s / 61.5 ms | +7% | | Math | 134.38 tok/s / 115.1 ms | 193.94 tok/s / 41.6 ms | +44% | | Reasoning | 134.86 tok/s / 115.4 ms | 187.82 tok/s / 46.6 ms | +39% | | Prose | 135.34 tok/s / 115.3 ms | 121.34 tok/s / 80.6 ms | -10% aggregate, 30% lower TPOT | | Natural language | 129.82 tok/s / 117.7 ms | 130.19 tok/s / 71.2 ms | ~flat aggregate, 39% lower TPOT | | Extraction / JSON | 133.30 tok/s / 115.4 ms | 219.11 tok/s / 43.2 ms | +64% |

Stress Saturation

c=256 is a saturation test, not the recommended interactive setting. The baseline can report high aggregate throughput by letting every stream crawl. The AEON DFlash path keeps per-active-stream TPOT far lower, but at c=256 requests queue hard and TTFT rises into minutes.

| Category | 🔴 Raw c=256 TPOT | 🟢 AEON c=256 TPOT | AEON c=256 TTFT | |---|---:|---:|---:| | Coding | 575.5 ms | 70.0 ms | 149.6 s | | Math | 531.9 ms | 42.7 ms | 103.6 s | | Reasoning | 540.7 ms | 49.4 ms | 109.3 s | | Prose | 532.5 ms | 77.1 ms | 159.8 s | | Natural language | 533.4 ms | 72.9 ms | 160.0 s | | Extraction / JSON | 551.9 ms | 43.2 ms | 90.4 s |

What the AEON container Adds

• Unified production image: ghcr.io/aeon-7/aeon-vllm-ultimate:latest (= tag :2026-06-11-pr41703; rollback tag :2026-06-04-pr44389). This single image supersedes the older qwen36-v3 / v4 / v5 lineage of per-revision containers.
• FlashInfer NVFP4 GEMM path
• DFlash sliding-window-attention compatibility patch from vLLM PR #40898 (4 of the drafter's 5 layers are sliding-window; earlier images ran them as full attention and drafting collapsed past ~2048 tokens)
• vLLM PR #41703 makes --enable-prefix-caching corruption-immune with DFlash
• CUTLASS NVFP4 fast path selected for GB10 / sm_121a
• DFlash numspeculativetokens: 10 (validated production default) using z-lab/Qwen3.6-27B-DFlash, drafter backend left at default
• Qwen3 reasoning parser and Qwen3-Coder tool-call parser enabled
• Packaged gateway/production/benchmark profiles so users do not have to hand-assemble the full vLLM command

Why the Spark recipe is tuned for long context

The z-lab Qwen3.6-27B DFlash drafter is a sliding-window model — 4 of its 5 layers use sliding-window attention (window 2048). vLLM PR #40898 (in aeon-vllm-ultimate:latest) runs those layers as proper SWA; earlier images ran them as full attention, so drafting collapsed once context grew past ~2048 tokens. PR #41703 additionally makes --enable-prefix-caching corruption-immune with DFlash. Net: long-context drafting holds up; short-context (under 2048 tokens, one window) is unchanged.

DDTree v5 Research Track

DDTree is the next obvious performance target, but it must land inside vLLM without losing multimodal, reasoning, tool calling, NVFP4, or the OpenAI-compatible gateway surface. The DDTree research track (the old qwen36-v5 experimental container) is superseded for production by the unified ghcr.io/aeon-7/aeon-vllm-ultimate:latest image — pull that image for any actual deployment:

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

Read the full DDTree card and lab chronicle: docs/qwen36-ddtree-card.md.

Current status in one line: flat DFlash remains the production path on the unified AEON container; DDTree is research-only. The unified image preserves the same NVFP4, DFlash, multimodal, reasoning, tool-calling, and OpenAI-compatible vLLM surface, but true non-flat branch commit is still research-only.

The working implementation plan lives in docs/ddtree-vllm-integration-plan.md. M1 scaffolding and the current experimental Docker context live in container/qwen36-v5-ddtree-experimental/.

The DDTree card documents:

• the current container tags and digest,
• what works today,
• the M1 through M53 trial-and-error path,
• the current M53 non-flat probe status,
• known blockers around branch-state GDN replay, fused branch attention, and accepted-branch commit,
• benchmark context and caveats,
• where community help is most likely to move the project forward.

• bench/results/qwen36dirtybaselineeager_20260510T034652Z.json
• bench/results/qwen36v4fi0611noprefixfullsweep_20260510T065838Z.json
• bench/results/qwen36v4fi0611noprefixtruesingle_20260510T065020Z.json

What we fixed for the DGX Spark

All AEON models run on one unified container — ghcr.io/aeon-7/aeon-vllm-ultimate:latest (= :2026-06-18-v0.23.0-dflashfix; rollback :2026-06-11-pr41703) — vLLM v0.23.0 built from source for GB10 / sm_121a and merged with the AEON speculative-decoding stack.

| Fix | What it does | Why it matters on GB10 | |---|---|---| | DFlash high-concurrency fix (new) | Slices the speculative drafter's KV block-table to the unpadded batch | The drafter previously crashed at ≥32 concurrent requests (padded-vs-unpadded block-table shape mismatch in FlashAttention). Now scales cleanly to c=64. A port of upstream PR #43982 (fixed for MTP, never applied to DFlash) — present and unfixed even in the prior image. | | Triton NVFP4 KV cache (PR #44389) | Software NVFP4 KV-cache path | The only 4-bit KV path on sm_121a (upstream's is hard-gated to B200) → ~3× KV capacity / longer context per GB of unified memory. | | DFlash sliding-window attention (PR #40898) | Runs the drafter's SWA layers as true sliding-window | Long-context draft acceptance holds as agent histories grow, instead of collapsing past ~2k tokens. | | sm121a-native build | TORCHCUDAARCHLIST=12.1a, ENABLENVFP4SM100=0 | Compiles the SM120-family CUTLASS NVFP4/FP8 kernels GB10 actually dispatches to — true 4-bit tensor-core throughput, no dead B200-only kernels. | | sm121a boot + CUDA-graph patches | RTLD-lazy Cstablelibtorch load; spec-decode CUDA-graph capture-size alignment | Boots past MXFP4 (SM100-only) symbols absent on GB10; prevents cudaErrorIllegalAddress on partial-acceptance decode steps under speculative decoding. | | Unified-memory tuning | --gpu-memory-utilization ≤0.70, FULL CUDA graphs, async scheduling, z-lab DFlash drafter | GB10 shares one LPDDR5X pool across CPU + GPU; conservative KV headroom avoids page-thrash while keeping FULL-graph + speculative-decode throughput. |

Model Variants

Six release formats covering DGX Spark, RTX PRO 6000, RTX 5090, and pre-Blackwell hardware:

| Release | Size | Target hardware | Use when | |---|---|---|---| | BF16 | 51 GB | A100 / H100 80 GB · RTX PRO 6000 Blackwell 96 GB | You have Ampere/Hopper or want full-precision reference weights | | NVFP4 | 26 GB | Simpler NVFP4 deployments | llm-compressor format, --quantization compressed-tensors. For best DGX Spark performance, use the DFlash recipe (aeon-vllm-ultimate:latest, n=10) with the XS body below. | | Multimodal-NVFP4-MTP | 27 GB | RTX PRO 6000 Blackwell · B100/B200 | modelopt format, --quantization modelopt, MTP spec decode via grafted mtp.* head. Vision tower preserved. GDN linear-attention preserved BF16 for best long-context fidelity. | | Text-NVFP4-MTP | 26 GB | RTX PRO 6000 · text-only deployments | Same recipe as Multimodal-NVFP4-MTP, vision tower stripped. GDN preserved BF16. | | Multimodal-NVFP4-MTP-XS | 21 GB | RTX 5090 (32 GB) · tighter dedicated VRAM | Strategic split: GDN projection matmuls → NVFP4; linearattn.conv1d kept BF16 to preserve the recurrence-critical SSM convolution. Vision tower preserved. | | Text-NVFP4-MTP-XS | 20 GB | RTX 5090 text-only · 24 GB cards | Same conv1d-preserved strategic split as Multimodal-XS, vision tower stripped. The smallest variant we ship. |

All six formats are the same underlying model. NVFP4 KL divergence vs BF16 source is below the noise floor of stochastic sampling — you cannot tell them apart at the output level. The four MTP variants share the same NVFP4 quantization quality plus the original Qwen/Qwen3.6-27B MTP head grafted back in BF16 (bit-exact, verified) for spec-decode drafting.

Regular MTP vs XS — what's the difference, and why it's a strategic quantization choice (not a precision compromise):

The GatedDeltaNet (GDN / Mamba-style) linearattn.* block has two distinct components: the heavy projection matmuls (inprojqkv, inprojz, inproja/b, outproj — ~11 GB total) and the SSM 1D convolution kernel (linear_attn.conv1d — small, but recurrence-critical).

- Regular MTP variants keep both at BF16. Maximum numerical safety margin, larger footprint.

- XS variants quantize the projection matmuls to NVFP4 (saves ~6 GB; FP4 is a clean win on bandwidth-bound matmuls) but explicitly preserve linearattn.conv1d at BF16. FP4 quantization of conv1d has been observed to cause drift on long-context recurrence in community testing, so we keep it at BF16 — the same principle modelopt's NVFP4DEFAULT_CFG applies by default and the same recipe sakamakismile validated across his Qwen3.6-NVFP4-MTP series (22K+ downloads). This is not "everything to FP4" — that would be a different (and not-recommended) variant we have explicitly chosen not to ship.

Pick regular if you have ≥48 GB VRAM and want best precision on long-context workloads; pick XS if you're on a 24–32 GB card and want maximum KV headroom with the SSM kernel still numerically stable.

Hardware routing:

- DGX Spark (GB10 / sm_121a) → use the aeon-vllm-ultimate:latest container with DFlash (n=10) and the Multimodal-NVFP4-MTP-XS body. That is the benchmarked path above.

- Dedicated-VRAM Blackwell (RTX PRO 6000 / RTX 5090 / B100/B200) → use the MTP variants (qwen35mtp n=3) when you want the grafted native MTP head. Dedicated VRAM behaves differently from Spark's unified memory, so benchmark locally before copying Spark flags.

Table of contents

• Quickstart (DGX Spark / GB10) — copy-paste
• Performance — DGX Spark DFlash vs Raw Baseline
• Model variants
• What this is
• Final stats
• Hardware compatibility matrix
• QuickStart — DGX Spark
• QuickStart — A100 / H100 (BF16)
• In-depth: the abliteration methodology
• In-depth: NVFP4 quantization
• Capability enhancement: the lifted "safety tax"
• Configuration reference
• Responsibility, arbitration, and use
• Provenance & credits
• License

What this is

This is the definitive uncensored release of Qwen 3.6 27B: the alignment-overhead removal so surgical that the model's KL divergence from the base is 0.000492 — three orders of magnitude inside the empirically-observed "capability damage threshold," and below the noise floor of ordinary stochastic sampling. A user cannot distinguish this model from the base on capability tasks; on several measurable axes (chain-of-thought commitment, adversarial-reasoning bandwidth, calibration honesty), it is better.

This is not a weekend abliteration. The release is the product of 72 hours of continuous research and tuning in which hundreds of parallel AI research agents were dispatched to:

• Characterize Qwen 3.5 / 3.6 hybrid-attention internals (16 full-attention layers + 48 GatedDeltaNet / linear-attention layers, attnoutputgate=True with doubled q_proj geometry, the FernflowerAI SSM conv1d outlier pattern).
• Survey the post-training-intervention literature in full: Arditi et al. (refusal as a single direction), grimjim's NPBA (norm-preserving biprojected abliteration), Heretic, Wuwangzhang's abliterix, Huang et al. on the safety tax, Xie et al. on DGR safety-tax mitigation, the projected-abliteration extensions, the winsorization heuristics.
• Audit every relevant arXiv submission of 2024–2026 on alignment-direction interventions, capability preservation, and 4-bit quantization on hybrid-attention stacks.
• Comb the r/LocalLLaMA community archive for tribal knowledge on what does and does not work — particularly on Mamba / GatedDeltaNet hybrids, where most generic abliteration recipes silently fail.
• Trace the GitHub commit graphs of the abliteration tooling ecosystem to identify pre-public development branches that fix bugs unfixed in the public releases.

The 50-trial Optuna search was cross-validated against a 10-axis capability spot-check to catch the documented "low-KL but word-salad" over-abliteration trap that pure refusal-rate scoring will miss. Trial 46 was selected — not the lowest-KL trial, but the one that combined zero refusals with full capability coherence.

Final stats

Refusal rate (apples-to-apples)

| Metric | Base Qwen3.6-27B | AEON-Ultimate | |---|---|---| | Refusals on harmful prompts | 99 / 100 | 0 / 100 | | Verdict | heavily aligned | uncensored | | Compliance rate | 1 % | 100 % |

Tested on a 100-prompt adversarial battery from mlabonne/harmful_behaviors covering cybercrime, weapons, violence, self-harm, hate speech, and synthesis instructions. Same denominator as the base evaluation.

Capability preservation

| Metric | Value | |---|---| | First-3-token KL divergence vs base | 0.000492 | | Output length deviation vs base | 0.027 σ | | Capability spot-checks (10 axes) | 10 / 10 coherent | | Math · code · reasoning · knowledge · long-form | All preserved |

Capability axes verified: arithmetic word problems, linear algebra, calculus, Python with memoization, Rust UTF-8 string handling, transitive syllogisms, the bat-and-ball intuition trap, factual recall, technical contrast (TCP vs UDP), structured pedagogical long-form. Every axis produced coherent, structured, reasoning-forward outputs — no looping, no philosophizing spirals, no word-salad.

KL divergence detail

| Distribution metric | Value | |---|---| | First-3-token KL vs base | 0.000492 | | Winsorization quantile | 0.995 (outlier-aware) | | Projection | orthogonal + projected-abliteration (NPBA-style) | | Trials evaluated | 50 (15 random warmup + 35 TPE-driven Optuna) | | Selected trial | #46 (winner, COHERENT) |

The empirically observed "capability damage threshold" in the abliteration literature is KL ≈ 0.1. AEON-Ultimate's KL is ~200× below that threshold.

Hardware compatibility matrix

The right variant depends on memory architecture, not just GPU model. DGX Spark should use the aeon-vllm-ultimate:latest DFlash container above; dedicated-VRAM Blackwell can use the MTP variants when the native MTP head is desired.

Only the DGX Spark row uses the aeon-vllm-ultimate container. That image is ARM64 + sm_121a and runs only on the Spark/GB10. Every other row means: download that weight variant and serve it on your own vLLM build (native to your CPU + GPU arch) — the AEON container is not involved. The "Spec-decode method" column tells you what to configure in your own vLLM.

| Hardware | Recommended variant | Why this exact variant | Spec-decode method | |---|---|---|---| | DGX Spark / GB10 (sm121a, unified memory) | 🏆 -Multimodal-NVFP4-MTP-XS body + DFlash + aeon-vllm-ultimate:latest image | Current recommended path. The unified image packages CUTLASS NVFP4, CUDA graphs, the DFlash sliding-window-attention patch (PR #40898), prefix-cache-safe DFlash (PR #41703), Qwen3 reasoning parsing, and Qwen3-Coder tool parsing. Supersedes the old qwen36-v3/v4/v5 lineage. | DFlash n=10 via z-lab/Qwen3.6-27B-DFlash drafter | | B100 / B200 (sm100, dedicated FP4 silicon) | -Multimodal-NVFP4-MTP (preferred — GDN BF16 fits) or Text variant | Native FP4 via tcgen05 / UTCQMMA — fastest hardware for this format. Dedicated VRAM bandwidth lets MTP's high acceptance rate translate to throughput. | qwen35_mtp n=3 (head grafted bf16, in repo) | | RTX PRO 6000 Blackwell (sm120, 96 GB dedicated) | -Multimodal-NVFP4-MTP for vision · -Text-NVFP4-MTP for text-only · XS siblings for tighter memory budgets | Dedicated VRAM has different bandwidth behavior than Spark unified memory. Start with the MTP variants and benchmark locally. | qwen35mtp n=3 | | RTX 5090 (sm120, 32 GB dedicated) | -Multimodal-NVFP4-MTP-XS (21 GB) if you use vision · -Text-NVFP4-MTP-XS (20 GB) if text-only | Regular MTP variants (~27 GB) leave too little KV headroom on 32 GB. XS variants (conv1d preserved BF16, projection matmuls FP4) fit comfortably. | qwen35_mtp n=3 | | Other 24 GB cards (RTX 4090, RTX 3090, RTX A6000 ≤48 GB) | -Text-NVFP4-MTP-XS (20 GB) | The smallest variant. Pre-Blackwell sm<120 will dequantize NVFP4 → BF16 at the kernel level (no FP4 silicon win), but the model still works and KV fits. | qwen35mtp n=3 | | H100 80 GB (sm90) | -BF16 | NVFP4 dequants to BF16 at kernel level — works but no throughput gain. Use BF16 for cleaner code path. | none (or external EAGLE / Medusa drafter) | | A100 80 GB (sm80) | -BF16 | Same as H100. BF16 at 131K context, single-GPU. | none | | Multi-GPU (any tier) | -BF16 (tensor-parallel-size 2/4/8) | Reference weights for fine-tuning, distillation, or quant-recipe development. | none | | Anything older than A100 | Not supported | Won't fit + lacks attention backends. |

hf auth login                                    # one time, paste your HF token
hf download AEON-7/Qwen3.6-27B-AEON-Ultimate-Uncensored-Multimodal-NVFP4-MTP-XS \   --local-dir ./models/aeon-ultimate-multimodal-nvfp4-mtp-xs
hf download z-lab/Qwen3.6-27B-DFlash \   --local-dir ./models/dflash-drafter

docker compose -f docker-compose.spark-xs.yml up -d
docker compose -f docker-compose.spark-xs.yml logs -f vllm

curl http://localhost:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "aeon-ultimate",
    "messages": [{"role": "user", "content": "Explain zero-knowledge proofs to a basic-crypto audience."}],
    "max_tokens": 512,
    "temperature": 0.7
  }'

hf download AEON-7/Qwen3.6-27B-AEON-Ultimate-Uncensored-BF16 \
  --local-dir /opt/models/aeon-ultimate-bf16

# docker-compose.bf16.yml
services:
  aeon-ultimate-bf16:
    image: vllm/vllm-openai:latest
    container_name: aeon-ultimate-bf16
    restart: unless-stopped
    network_mode: host
    ipc: host
    runtime: nvidia
    environment:
      NVIDIAVISIBLEDEVICES: all
    volumes:
      - /opt/models/aeon-ultimate-bf16:/models/aeon-ultimate:ro
    command: >
      --model /models/aeon-ultimate
      --served-model-name aeon-ultimate
      --host 0.0.0.0 --port 8000
      --dtype bfloat16
      --max-model-len 131072
      --max-num-seqs 16
      --max-num-batched-tokens 8192
      --gpu-memory-utilization 0.90
      --enable-chunked-prefill
      --enable-auto-tool-choice
      --tool-call-parser qwen3_coder
      --reasoning-parser qwen3
      --attention-backend flash_attn
      --trust-remote-code

docker compose -f docker-compose.bf16.yml up -d

Qwen/Qwen3.6-27B (BF16, 51 GB, heavy RLHF safety training)
          │
          │  Stage 1 — SSM conv1d outlier repair (FernflowerAI)
          ▼
Qwen3.6-27B-base-repaired  (8 late-layer SSM blocks rescaled)
          │
          │  Stage 2 — abliterix v1.4 abliteration (Optuna multi-objective)
          ▼
Qwen3.6-27B-AEON-Ultimate-Uncensored  (BF16, 51 GB, trial 46/50)
          │
          │  Stage 3 — capability cross-validation (10-axis spot-check)
          ▼
Qwen3.6-27B-AEON-Ultimate-Uncensored  (validated, BF16 release)
          │
          │  Stage 4 — NVFP4 quantization (llm-compressor)
          ▼
Qwen3.6-27B-AEON-Ultimate-Uncensored-NVFP4  (26 GB, NVFP4 release)

[steering]
vector_method          = "mean"
decay_kernel           = "linear"
orthogonal_projection  = true
projected_abliteration = true        # grimjim NPBA
winsorize_vectors      = true
winsorize_quantile     = 0.995
weight_normalization   = "none"
disabledcomponents    = ["attn.qproj", "attn.kproj", "attn.vproj"]
Q/K/V disabled: Qwen 3.6 has attnoutputgate=True which doubles
q_proj's output dim to (12288, 5120) — incompatible with abliterix's
standard projection math.
[steering.componentstrengthranges] "mlp.down_proj" = [2.0, 10.0] "attn.o_proj"   = [1.0, 6.0]
[kl] target          = 0.005 prune_threshold = 0.5      # kill divergent trials at 100× target
[optimization] num_trials        = 50 numwarmuptrials = 15