Skip to content

qwen3.6-windows-server v1.3.8, portable Windows launcher

Choose a tag to compare

@github-actions github-actions released this 13 May 21:46
· 9 commits to main since this release

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_running no longer GC's a
    manifest younger than 60 seconds, even when both _port_listening
    and _pid_alive momentarily return False. Those signals can flap
    during vLLM's compile window (port bound but accept loop not yet
    running, slow tasklist returns 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.compile first-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.zip
  • SHA256SUMS.txt