Rationale for deprecation of Qwen 3.6 27B dual-dflash composes?

[hlo-world]

In #294 and #295 I had mistakenly believed that after pruning the branches of composes, vllm/dual acts as the everything-in-one compose. So I thought that by including the WITH_DFLASH_DRAFT=1 flag, I was enabling dflash. Turns out I ran with mtp on both those benches.

Which motivates me to ask: why deprecate the dflash composes? (And apologies if this is documented somewhere, but the discoverability of said writeup is the actual concern in that case)

Quick datapoint, my most recent full test runs yielded:
vllm/dual, pciep2p enabled, 100k ctx - 66 narrative / 86 code
vllm/dual-dflash-noviz, pciep2p enabled, 100k ctx - 79 narrative / 122 code (+20% / +40%)

Are others with dual rigs with more mainline configs not seeing uplift like this to justify maintaining the dflash composes?

[noonghunna]

Great question — and thanks for the clean datapoint. +20%/+40% from real DFlash (vs the MTP runs in #294/#295) is exactly the signal worth raising.

Headline first: the dual-dflash composes were pruned for catalog-leanness + an image-availability problem, not because DFlash is bad on Qwen. DFlash via the z-lab external draft model works well — it's still the mechanism behind the production vllm/dual4-dflash (TP=4), and your uplift is real and reproducible. (The "#39931 DeltaNet rollback blocks DFlash" caveat applies to EAGLE / in-model spec-decode, not the external-draft path these use.)

Two things drove the 2026-05-31 prune:

1. Consolidation — we collapsed the dual lineup to one canonical vllm/dual: 262K + vision + MTP + 2 concurrent streams on a stable image. The dflash duals traded that down (~185K, single stream, no vision on -noviz) for code TPS, so the lean-catalog call kept the broad-coverage one.
2. They were stranded on a vLLM nightly (vllm/vllm-openai:nightly-e47c98ef…) that Docker Hub has since purged (404s now — same purge that hit our Gemma composes in [bug] Cannot run gemma 31b with kv cache on dual 3090s - config issues and gibberish output #250/vllm updates to keep an eye on #451). DFlash-on-vLLM needs vendored overlays (z-lab draft wiring + #42102 + the #40334 --dtype bfloat16 workaround) never ported to stock v0.22.0, so unlike vllm/dual it couldn't ride an immutable tag. You can still run it because you've got that nightly cached locally (you contributed the [bench] 2x 3090, PCIE x4 each, aikitoria P2P enabled, dflash-noviz, narr = 76 TPS, code = 120 TPS #158 dual-dflash-noviz row, after all 🙂) — but a fresh user can't even pull it. That availability gap is the other half of the "why."

On discoverability — you're right, and that's the fair hit. The rationale lived in the compose status_note + git, not anywhere a user would look. I'll add a short "where did the DFlash composes go / DFlash options now" note in DUAL_CARD.

Where DFlash lives now — and an offer: we just shipped maintained DFlash dual composes on beellama (#296), on Anbeeld's official v0.3.0 image (not a purged nightly):

bash scripts/switch.sh --force beellama/qwen-dflash-dual   # Qwen3.6-27B Q8_K_XL + DFlash, full 262K

Heads-up on expectations: v0.3.0 is still a pre-release — we pin a specific commit so your run is reproducible and won't vanish like that nightly, but the image will keep moving as Anbeeld lands beta fixes, so treat numbers as a snapshot of the current build.

Given your dual-3090 + PCIe-P2P setup, would you be up for A/B-ing it against your vLLM DFlash numbers? One honest caveat: beellama v0.3.0 has a prose-acceptance regression (DFlash on free-text is net-negative right now — Anbeeld's fixing it upstream), but code is excellent (~145 TPS, accept ~0.5). Since your win is on the code side it should land well there; for prose, MTP (vllm/dual or beellama/qwen-mtp-dual) is the better pick today. Your numbers either way would be a great datapoint.

And if there's broader demand for the vLLM DFlash path specifically, recovering the compose from git is easy — the harder part is porting the overlays onto a stable tag so it's pullable again, which we can look at if the interest's there.