3.1 Serving 层与 SRT 分层

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

Serving 层与 SRT 分层#

这章解决什么问题#

这一章要解决的问题不是“请求怎样一步步流动”，而是“为什么 SGLang 要把入口、编排、执行和观测拆成不同层”。如果没有这层理解，读者看到 http_server.py、scheduler.py、model_executor、observability 这些区域时，会误以为它们只是按开发习惯分目录，而不是在划定真正的职责边界。

第一版在这里坚持一个保守原则：目录名和公开入口是事实，基于目录职责推断“分层意图”时，会明确说明这是工作性划分，而不是把目录结构直接等同于架构真相。这样可以避免过度解读源码布局。

事实锚点：进程边界本来就写在入口里#

从 python/sglang/launch_server.py 与 python/sglang/srt/entrypoints/* 看，SGLang 至少存在一层很明确的入口面：它负责接参数、选运行模式、接住 HTTP 或 gRPC 请求，并把后续工作交给 runtime path。这个层次更接近 serving surface，而不是底层生成机制本身。

更关键的是，python/sglang/srt/entrypoints/http_server.py 的 launch_server(...) 文档字符串已经把运行时拆分说得非常直接：HTTP server 负责路由请求；engine 由 TokenizerManager、Scheduler 和 DetokenizerManager 三个组件构成；HTTP server、Engine、TokenizerManager 在主进程里，而另外两个 manager 是子进程，并通过 ZMQ 做 IPC。python/sglang/srt/entrypoints/engine.py 的 Engine 类文档字符串重复了同样的描述，这不是推断，而是源码作者自己给出的结构说明。

如果只用文字，这里最容易混淆的点是“入口层、编排层、执行层、观测层到底怎么分”。下面这张组件图承担的职责，就是把这些层次放到一张边界图里，并明确哪些是 runtime 主线、哪些是横切能力。

flowchart TB
 subgraph Serving["Serving Surface"]
 A["launch_server.py"]
 B["entrypoints/http_server.py"]
 C["entrypoints/grpc_server.py"]
 D["entrypoints/engine.py"]
 end

 subgraph Managers["Runtime Orchestration"]
 E["TokenizerManager"]
 F["Scheduler"]
 G["DetokenizerManager"]
 H["ScheduleBatch / ModelWorkerBatch"]
 end

 subgraph Executor["Execution Layer"]
 I["model_executor / ModelRunner"]
 J["models / tokenizer"]
 end

 subgraph Cache["State & Cache"]
 K["mem_cache / ReqToTokenPool"]
 L["TokenToKVPoolAllocator / KVCache"]
 end

 subgraph Obs["Observability"]
 M["observability / req_time_stats.py"]
 end

 A --> B
 A --> C
 B --> D
 C --> D
 D --> E
 E --> F
 F --> H
 H --> I
 I --> J
 F --> K
 K --> L
 E -. stage / request stats .-> M
 F -. batch / phase stats .-> M
 I -. execution metrics .-> M

这张图比纯目录描述多解释了一点：observability 不是沿着主数据流串联的“下一跳”，而是覆盖多个层的横切面。理解这一点之后，后面的调试章节就不会再显得像附录，而会自然成为这张架构图的一个外侧切面。

3. 运行时架构 on Machine Learning 学习笔记

3.1 Serving 层与 SRT 分层

Serving 层与 SRT 分层#

这章解决什么问题#

事实锚点：进程边界本来就写在入口里#