qwen3.6-windows-server v1.3.11
Bugfix release: third pass on the LOADING-stuck dashboard (issue #12).
v1.3.8 added a 60-second grace before the runtime-manifest GC could
fire, v1.3.9 removed a separate silent-unlink path. Reporter still hit
it on v1.3.9: their cold Ampere boot takes ~135 seconds from click to
Application startup complete, longer than the 60-second grace, so the
GC fired during boot with port_up=False wrapper_up=False and wiped
the manifest mid-boot.
What changed
launcher/app/runtime.py: grace bumped from 60s to 300s. Cold
Ampere boots with torch.compile + warmup + weight load run 120-180s,
and a slowtasklistcall can flapwrapper_upto False for one
poll. 300s covers any realistic boot window without leaving truly
dead manifests around for long.- Per-poll diag log line. Every poll that sees a not-listening,
not-alive manifest now writes one line to
logs\launcher.diag.logsummarizing port_up, wrapper_up, age, and
the keep / GC decision. Makes future diagnosis a one-line paste. snapshots/_common.py:clear_manifest(called from each
snapshot'sfinallyblock when the wrapper python exits) now writes
a diag-log line too, so we can tell from logs whether the wrapper
ever exited and when.
Who is affected
- Anyone whose Ampere or Blackwell snapshot boot takes longer than 60
seconds (any cold boot does) and hit the LOADING-stuck card despite
v1.3.9 / v1.3.10.
Upgrading
update.bat
The launcher zip is replaced; venv\, models\, logs\,
cuda13_shim\ and user_config.json are preserved. The bundled wheel
is unchanged from v1.3.7, so the runtime install is not rerun.
Verification
After upgrading, launch any snapshot from the TUI and let it sit
through the full vLLM compile / autotune window. The card should
progress LOADING -> RUNNING and logs\runtime\<port>.json should
remain on disk for the whole session. If the card still sticks, paste
the contents of logs\launcher.diag.log in the issue.
Files
qwen3.6-windows-server-portable-x64-ampere.zipqwen3.6-windows-server-portable-x64-blackwell.zipSHA256SUMS.txt