FIG_GPU · An interactive simulation
Inside an LLM Serving GPU
Decode reads every weight for every token. Watch the bytes leave the memory chips, and see why memory bandwidth sets the speed. L4 or GB10. BF16 or FP8. Fill the pool. Break the cooling.
The big ideaMemory, not math, sets the speed of decode, and the KV pool sets how many users fit.
NowReady
What the machine shows
Decode is a memory read. On the L4, one decode step of Qwen3-8B in BF16 reads 16.41 GB of weights. At the peak 300 GB/s that takes 54.7 ms, and the measured step at one user took 60.16 ms. The SMs wait for the bytes.
Fewer bytes, faster steps. FP8 weights are 8.81 GB on the L4. The step at one user fell to 39.66 ms, and the freed memory grew the KV pool from 24,094 to 142,369 tokens. At 64 users the output went from 250.85 to 735.91 tok/s.
The pool decides who runs. The scheduler admits a request only when the pool has room. At 64 users the BF16 pool holds 37 requests and the rest wait. At a memory fraction of 0.74, four 2,048-token prefixes no longer fit, and the median first token took 12.6 s, against 0.47 s at 1,024 shared tokens.
Launch gaps are small. Without CUDA graphs, each kernel launch crosses from the host. On the L4 that added 0.47 ms to a 60 ms step at one user. Next to the weight read, the launch path barely matters.