Docker cannot find the pinned nightly images: ERROR

[sudeposutemizligi]

Hi, I am trying to set up club-3090 on a fresh Linux system with 2x RTX 3090 GPUs.

My goal is to run my already-downloaded local Qwen3.6 27B models. I do not want the repo to download model weights.

System/model setup:

• GPUs: 2x NVIDIA RTX 3090, 24GB each
• Local model root:
  /media/ozgur/463A5DFB3A5DE907/Users/AICM/Desktop/model
• Main model:
  /media/ozgur/463A5DFB3A5DE907/Users/AICM/Desktop/model/qwen3.6-27b-autoround-int4
• DFlash model:
  /media/ozgur/463A5DFB3A5DE907/Users/AICM/Desktop/model/Qwen3.6-27B-DFlash

MODEL_DIR=/media/ozgur/463A5DFB3A5DE907/Users/AICM/Desktop/model \
HF_HUB_OFFLINE=1 \
TRANSFORMERS_OFFLINE=1 \
bash scripts/launch.sh --variant vllm/dual
The vllm/dual variant appears to use:



vllm/vllm-openai:nightly-bf610c2f56764e1b30bc6065f4ceace3d6e59036
That image exists and was downloaded.

However, when trying the other variants, Docker cannot find the pinned nightly images:



vllm/dual-turbo:
vllm/vllm-openai:nightly-01d4d1ad375dc5854779c593eee093bcebb0cada
Docker reports:


not found / no such manifest
And for DFlash:


vllm/dual-dflash:
vllm/vllm-openai:nightly-e47c98ef7a38792996e452ef53914e21e41928e9
Docker also reports that this image tag is not available.

My confusion is:

Are these pinned vLLM nightly images expected to still exist on Docker Hub?
If Docker Hub removed these tags, what is the recommended way to run dual-turbo and dual-dflash now?
Should users build these images locally?
Is ghcr.io/noonghunna/vllm-club3090:latest the intended replacement image for the missing Docker Hub nightlies?
If yes, which variants should use that image?
Is there a documented way to use local models through .env without patching the compose YAML files?
I want to keep the repo clean and original, using .env variables if possible, not modifying compose files manually.

Right now, vllm/dual seems usable with the available image, but the turbo / dflash variants fail because their pinned Docker images are missing. 
THANK YOU FROM NOW, İF SOMEONE CAN HELP

[noonghunna]

Thanks for the detailed report @sudeposutemizligi — you've diagnosed it exactly right, and it's nothing wrong on your end.

Yes, those nightly tags were purged by Docker Hub. vLLM rotates/expires its vllm/vllm-openai:nightly-<sha> images over time, and both SHAs you hit are gone: nightly-01d4d1ad… (used by dual-turbo + the TQ3/Genesis paths) and nightly-e47c98ef… (DFlash). vllm/dual keeps working for you because it routes through a different, still-live pin (bf610c2f…). We track the fix in #167 — it's deliberately not a one-line tag swap (dual-turbo is anchored to a specific Genesis v7.72.2 patch SHA, dual-dflash to a DFlash overlay), so the full plan + acceptance criteria live there.

What to run right now on 2× 3090

→ Stay on vllm/dual, which you already have working. It's the clean dual-card baseline, runs your existing autoround-int4 model with MTP, and needs no downloads. For nearly every workload this is the one to use until #167 lands — dual-turbo's incremental throughput isn't worth being blocked over.

Your specific questions

• Are the pinned nightlies expected to still exist? No. Docker Hub expires old nightlies; pinning to a nightly SHA is inherently fragile, which is the root problem vLLM nightly pin bump — Docker Hub purged nightly-01d4d1ad (Genesis v7.72.2 anchor); blocks every vllm-nightly-mtp compose #167 is about — not your setup.

• Is ghcr.io/noonghunna/vllm-club3090:latest the replacement? It's an override (VLLM_IMAGE=ghcr.io/noonghunna/vllm-club3090:latest, no compose edit needed) and it will likely boot plain dual. But ⚠️ dual-turbo and dual-dflash are precisely the variants that depend on the pinned substrate (Genesis TQ3 patches / DFlash overlay anchored to those exact SHAs) — on a different image their TQ3 / spec-decode behavior is unvalidated and can misbehave or OOM. So it is not a safe substitute for turbo/dflash specifically. And for plain dual you already have a working image, so you don't need the override at all.

• Local models via .env without patching composes? Yes — and you're already doing it correctly. MODEL_DIR=<your dir> HF_HUB_OFFLINE=1 TRANSFORMERS_OFFLINE=1 is the supported path: the composes mount MODEL_DIR and the offline vars stop any Hugging Face fetch. No compose edits required — keep the repo original.

One more option (only if you're open to a different weight file)

The llama.cpp path (bash scripts/switch.sh llamacpp/default) has zero Docker Hub dependency — the image is built locally by scripts/setup.sh, so it can never hit a purged nightly, and as of #181 it does the full 262K context with MTP. The catch: llama.cpp needs a GGUF, which is a different format from your autoround-int4 (vLLM) weights — so you'd have to fetch a Qwen3.6-27B GGUF (~16 GB). If you want to stay strictly no-download, skip this and stick with vllm/dual.

---

TL;DR: vllm/dual is your path today — it works, runs your existing model, no downloads. dual-turbo / dual-dflash are blocked on #167, and the GHCR override is not a safe stand-in for those two specifically. Thanks for the clear write-up 🙏