1. The Processes One Request Passes Through
Open an LLM serving framework for the first time and you will probably go looking for the scheduler. But no amount of reading scheduler code …
Eight parts reading sgl-project/mini-sglang
,
pinned to commit 9a91cfa. Every quoted snippet links to a permalink at that commit.
It starts from the process boundaries one HTTP request crosses, then works through the Req/Batch state ledger, the chunked-prefill budget, page allocation, the radix cache and eviction that make prefix reuse possible, hiding CPU scheduling behind two streams, and how several TP ranks reach the same decision.
Each part assumes the previous one, so reading from part 1 works best.
Open an LLM serving framework for the first time and you will probably go looking for the scheduler. But no amount of reading scheduler code …
In chapter 1, what reached the scheduler was a 1-D int32 tensor on the CPU. While that token sequence grows into an answer, the system has …
In chapter 2 a request became a ledger expressed by three lengths. Now there is one question left: with several requests waiting, what goes …
In chapter 3 a request “secured its space”. What that space actually is, is this chapter’s subject. The KV cache is …
Chapter 4 showed how one request secures its space. But if a hundred requests arrive with the same system prompt and each repeats the same …
Across five chapters we have watched what the scheduler does. It receives messages, computes budgets, walks a tree, allocates pages, fills a …
At the end of chapter 6 we listed the seven lines of _prepare_batch and left two of them alone: pad_batch and prepare_metadata. This chapter …
Chapter 1 showed that one scheduler starts per TP rank, and the six chapters since read what happens inside one of them. Now all of it gets …