2.1 一次请求如何穿过 SGLang

Mon, 01 Jan 0001 00:00:00 +0000

一次请求如何穿过 SGLang#

这章解决什么问题#

这一章解决的是“请求主链路在哪里开始，又在哪里发生关键 handoff”。如果只从零散模块出发阅读源码，你会看到 http_server.py、grpc_server.py、scheduler.py、tokenizer_manager.py 这些名字，却不知道它们是按什么顺序被接上的。生命周期章节的任务，就是先把这条主线画出来。

第一版在这里刻意控制范围。它会讲清入口、模式分支、进入运行时的 handoff，以及后续要去哪几类模块找实现；但不会在这一章里深入 sampling、speculative decoding 或 KV cache 的局部机制。那些问题会留给后面的执行模型和调度与内存章节。

请求先从哪一个入口进来#

从 python/sglang/launch_server.py 看，服务化入口首先会调用 prepare_server_args(...) 解析参数，然后交给 run_server(server_args) 做模式选择。这里的分支不是装饰性的：encoder_only、grpc_mode、use_ray 和默认 HTTP 模式分别导向不同实现，默认路径才会导入 sglang.srt.entrypoints.http_server.launch_server。

这一步最关键的结论是：launch_server.py 负责“选入口”，不负责“跑生成”。你可以把它理解成总调度台。它决定请求应该进入 HTTP、gRPC、Ray，还是 encoder disaggregation path；但一旦分支确定，真正接收请求、维护请求状态、驱动 batch 的逻辑就进入 srt 内部了。

如果只靠段落描述，这条主链路仍然有点抽象。下面这张时序图解决的障碍是：把“入口选路”“请求进入 runtime”“调度器推进 batch”“detokenizer 回包”放到同一时间轴上，让你能一眼区分谁在接请求、谁在编排、谁在收尾。

sequenceDiagram
 participant Client as Client / SDK
 participant Entry as launch_server.py
 participant HTTP as http_server.py
 participant TM as TokenizerManager
 participant SCH as Scheduler
 participant DET as DetokenizerManager

 Client->>Entry: CLI / HTTP / OpenAI-compatible request
 Entry->>HTTP: select HTTP / gRPC / Ray path
 HTTP->>TM: generate_request(...)
 TM->>TM: normalize, tokenize, build request state
 TM->>SCH: send_to_scheduler.send_pyobj(...)
 SCH->>SCH: build / update batch
 SCH->>DET: send_to_detokenizer.send_output(...)
 DET->>DET: detokenize / assemble text
 DET->>TM: send_to_tokenizer.send_pyobj(...)
 TM->>HTTP: streaming / final response
 HTTP->>Client: chunks or completed result

这张图多解释了一件纯文字不容易稳定表达的事：TokenizerManager 在链路里既是请求进入 runtime 的第一站，也是结果回到调用方之前的收敛点。后面你在架构章节里看到 TokenizerManager、Scheduler、DetokenizerManager 被并列成 engine 组件时，就更容易理解它们为什么不是随意拆成三个进程。

2. 请求生命周期 on Machine Learning 学习笔记

2.1 一次请求如何穿过 SGLang

一次请求如何穿过 SGLang#

这章解决什么问题#

请求先从哪一个入口进来#