Trace how one slow request stalls every co-batched generation step.

**Continuous batching** runs many requests through one shared decode loop. Every iteration of that loop, the scheduler issues one forward pass that produces the next token for every active sequence at once. After the GPU step finishes, the server runs some bookkeeping for each sequence and then starts the next step. The coupling problem is that the bookkeeping runs on the same thread as the step. If one request's bookkeeping is slow, the whole step waits for it. Every other request in the batch is now stalled too, not because the GPU is busy but because the loop cannot advance to the next forward pass. Common offenders are CPU work that the scheduler does after the GPU returns: turning token IDs into text for streaming, running a grammar check for structured JSON output, computing extra log-probabilities the caller requested, or any Python callback that holds the global lock. The fix is always the same shape: move the slow work off the step thread. Push CPU bookkeeping to a worker pool, put a hard timeout on any per-step hook so a misbehaving request fails fast, and send latency-sensitive traffic to a replica that does not run the heavy hooks alongside it.

**Continuous batching couples requests through a shared step thread.** Every iteration, the scheduler issues one forward pass for the whole batch, then runs per-sequence bookkeeping before the next step. That step is one synchronized barrier; if anything on the step thread blocks, every co-batched request blocks with it. The usual culprits are CPU-side hooks that sneak onto the step path. Detokenization can stall on a rare multi-byte token. A logprob hook may serialize an extra scoring pass per step. A structured-output grammar check can spend tens of milliseconds reconciling the next-token mask against a deep schema. A Python callback can simply hold the GIL. None of these touch the GPU, so a flame graph that focuses on tensor ops will look healthy while p99 explodes. The signal is decode step time that varies request to request even though the model is identical. The fixes share one shape: get the slow work off the step thread. Move CPU bookkeeping to a worker pool that runs concurrently with the next forward pass. Hard-timeout each per-step hook so a misbehaving request fails fast rather than holding the barrier. Isolate latency-sensitive traffic on a replica that does not run logprob or structured-output workloads beside it. Keep the step thread short, predictable, and pure GPU launch.