Follow the return path first, because that is where the timers usually sit. Submission runs LLM.generate(prompts) into LLMEngine.add_request(), through EngineCoreClient, onto an IPC input queue that terminates at scheduler.add_request() inside the child process [7]. On the way out, LLMEngine.step() retrieves output EngineCore has already produced via get_output(), detokenizes it, and assembles RequestOutput for the caller, rather than telling the GPU to perform a step [5][8].
That is two crossings of the process boundary per request, one each way [9]. A wall-clock number taken around generate() therefore contains queue wait, whatever the scheduler decided to admit, and detokenization in your own process. The reasons behind that admission decision are not part of this account.
The reclamation side is where the accounting bites. Stage three, update_from_output(), updates request state and releases the KV blocks of finished requests before writing EngineCoreOutputs to the output queue [4]. Only then can the next schedule() admit waiting work [10]. Admission is downstream of completion, inside the same loop, at step granularity. A request that keeps generating keeps its blocks, and the budget those blocks represent is not available to anything queued behind it.
Part one carries no timings. The author describes it as a source-code walkthrough of vLLM 0.22's V1 execution path from the public entry point to the CUDA boundary, not an API tutorial [11], and the kernel material is held back for the two later parts on CUDA kernels with paged attention and on FlashAttention from PyTorch to Triton [12]. This walkthrough does not rank scheduler overhead against kernel time, and any claim about that ordering does not draw on this article. What it does fix is which layer holds the decisions. The walkthrough names its own durable subjects as continuous batching, token budgets, paged KV allocation, and the separation between scheduling and execution [13]. It also states the gap it was written to close: the virtual-memory analogy for PagedAttention does not tell you how a request is admitted, how variable-length requests become a flat token batch, or what the page table looks like at the kernel boundary [14].
Read that as a scoping claim rather than a performance one. The paths a serving team can actually change without writing CUDA are the budget schedule() spends and the block supply update_from_output() returns to it. Both sit behind the IPC boundary, in a loop the caller does not drive [2]. When latency degrades and no kernel changed, those are the two quantities that did.
