[jason-fxz]

Bug

With --ple-backend disk in wait-sync mode (Qwen3.8-Flash-Next), the captured decode graph waits on a host flag at the PLE lookup, and the engine signals that flag only after replay() returns. torch captures the graph without uploading it, so the first replay() of each batch size also uploads it. When enough kernels follow the wait, that first replay() never returns: the engine thread stays in cuGraphLaunch, so the flag is never signaled. The Flash-Next GGUF decode graph on main does not hang as is; with 4000 more kernels after the lookup it does.

Reproduce

Put this sitecustomize.py on PYTHONPATH to add 4000 kernels after the PLE lookup in the captured graphs:

import torch
from freetoken.models.qwen4_exp import ple_disk

orig = ple_disk.DiskRowTable.lookup
pad = {}

def lookup(self, row_ids, out=None):
    res = orig(self, row_ids, out)
    x = pad.setdefault(res.device, torch.zeros(256, device=res.device))
    if torch.cuda.is_current_stream_capturing():
        for _ in range(4000):
            x.add_(1.0)
    return res

ple_disk.DiskRowTable.lookup = lookup

Serve ISTA-DASLab/Qwen3.8-Flash-Next-GSQ-RCO-GGUF IQ3_XXS with --moe-strategy fused --ple-backend disk and send one chat request. On main the request gets no response, GPU utilization stays at 0%, and py-spy shows the engine thread in GraphRunner.replay -> cudaGraphLaunch -> cuGraphLaunch -> sched_yield.

Fix

Upload each graph with cuGraphUpload right after capture, so the first replay() does not upload it. Linux with CUDA only (through ctypes on libcuda.so.1); Windows and ROCm are unchanged.

With the patch above, this branch answers the request, and its greedy output matches the run without the patch. Without the patch, greedy output and decode speed match main. Tested on H100 80GB, torch 2.14.1+cu130.