qwen3.6-windows-server v1.3.8, portable Windows launcher
qwen3.6-windows-server v1.3.8
Bugfix release: the launcher TUI's dashboard could get stuck on
LOADING while vLLM was actually up and serving requests, because the
runtime-manifest GC was too aggressive during the snapshot's boot
window.
What changed
launcher/app/runtime.py:detect_runningno longer GC's a
manifest younger than 60 seconds, even when both_port_listening
and_pid_alivemomentarily return False. Those signals can flap
during vLLM's compile window (port bound but accept loop not yet
running, slowtasklistreturns under load) and a single bad poll
used to delete the manifest. Once deleted, the dashboard had no way
to associate the running engine with its card, so the LOADING banner
stuck forever.- Diagnostic log when GC fires. After the grace period, if both
signals still say the snapshot is gone, the reader now prints
[runtime] GC manifest <path> port=<port> wrapper_pid=<pid> port_up=<bool> wrapper_up=<bool>to the launcher's stdout before
unlinking. If anyone hits this again, that line tells us which
signal failed. windows_tools/wipe_caches.py: prints a clear "recovery tool,
not pre-launch cleanup" banner up front before the cache scan, so
users do not run it before every boot and trip the 11-25 min cold
FlashInfer rebuild. Related: issue #15.
Who is affected
- All users who launch snapshots via the TUI on hosts where the
vLLM boot window is long enough for the polling loop to fire before
the engine accepts connections, that is, anyone on Blackwell NVFP4
(FlashInfer fp4_gemm autotune) and anyone with a long
torch.compilefirst-boot. Reported on Russian Windows 11 with the
Ampere zip on issue #12. - Direct snapshot launches (
snapshots\start_*.bat) were
unaffected, the bug was in the launcher reader only. If you have
been working around the problem by running the bat directly, you can
go back to using the TUI after this update.
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 sticks on LOADING
again, the launcher stdout will now contain a [runtime] GC manifest ... line, please paste it in a fresh issue.
Files
qwen3.6-windows-server-portable-x64-ampere.zip(and the unsuffixed
alias for legacy in-place updates from pre-v1.2.3 installs)qwen3.6-windows-server-portable-x64-blackwell.zipSHA256SUMS.txt