请求生命周期#

请求生命周期部分只做一件事：解释一次请求是如何穿过 SGLang 的。它关心的是主链路上的 handoff 点，包括入口解析、运行模式选择、HTTP 层接住请求之后交给谁、请求进入 runtime 之后由谁继续编排，以及结果怎样回到调用方，而不是把 sampling、speculative decoding、cache eviction 这些局部机制全部塞进同一章。

这样分工有两个好处。第一，读者会先得到一条完整但不过载的路径。第二，后续运行时架构、调度与内存、执行模型这些章节，可以围绕各自的核心问题展开，而不是不断重复“请求是怎么进来的”。

这一部分最重要的源码事实，不在某一个文件里，而在几个连续 handoff 上：python/sglang/launch_server.py 决定请求从哪种 server path 进入；python/sglang/srt/entrypoints/http_server.py 把 HTTP 路由接到 TokenizerManager.generate_request(...)；python/sglang/srt/managers/tokenizer_manager.py 再把 tokenized request 送给 Scheduler；最后 python/sglang/srt/managers/detokenizer_manager.py 把输出 token 转回文本并送回 TokenizerManager。只要这条链路建立起来，后面再看局部优化时就不会迷路。

本节包含什么#

本节第一章是 2.1 一次请求如何穿过 SGLang。这一章会从 python/sglang/launch_server.py 和 python/sglang/srt/entrypoints/* 出发，说明服务入口如何根据不同模式切入不同 server path，并把请求交给真正的运行时层。正文会继续落到 TokenizerManager.generate_request(...)、Scheduler.get_next_batch_to_run() 和 DetokenizerManager.event_loop() 这些更具体的位置，让你能把“入口层”“编排层”“回包层”放在同一张图里看。

本节故意不讨论 sampling 策略、ScheduleBatch 细节或 KV cache 分配策略。这些内容都属于后面章节的职责。请求生命周期章节的目标更朴素：先让你确定“请求先到哪里、再到哪里、最后由谁收尾”。没有这张图，读者很难判断 managers、model_executor、mem_cache 这些目录是在主链路的什么位置出现的。