A production GLM5.2 deploy hit a permanent vLLM scheduler deadlock combining MTP with a KV connector.

PR #57104 fixes it, and the PR body walks a 7-block worked example that's worth reading if you run either feature. Two requests are admitted to skipped_waiting as WAITING_FOR_REMOTE_KVS, request A's transfer lands and it's promoted to WAITING, but its MTP block (allocated only after the async load) needs one block when zero remain, so allocate_slots returns None and the loop breaks with the queues in exactly their prior state. Forever. Under KV memory pressure, multi-token prediction plus a KV connector was a deadlock waiting for the right arrival order.