运行时架构#

运行时架构部分关注的是模块边界，而不是请求顺序。请求生命周期章节已经回答了“请求怎么走”，这一部分要回答的是“走到哪里时，系统为什么把职责切成这些层”。这是两个不同问题：一个是路径问题，一个是边界问题。

对 SGLang 来说，这个问题尤其重要。因为从目录看，python/sglang/srt 下面同时有 entrypoints、managers、model_executor、models、tokenizer、mem_cache、observability 等区域。如果不先把这些区域的职责关系讲明白，后面任何局部章节都很容易写成一堆文件名列表。

这一部分的写作抓手，不是给每个目录找一句 marketing 式定义，而是沿着几个稳定事实来划分层次：http_server.py 和 engine.py 的文档字符串明确说明了进程与组件拆分；schedule_batch.py 明确给出了 ScheduleBatch -> ModelWorkerBatch -> ForwardBatch 的数据结构转换；memory_pool.py 又把 ReqToTokenPool、TokenToKVPoolAllocator 和 KVCache 之间的关系写成了显式注释。把这些事实拼起来，分层边界就不再只是目录直觉。

本节包含什么#

本节第一章是 3.1 Serving 层与 SRT 分层。它会先把对外入口、运行时编排层和更底层执行相关模块区分开来，再说明为什么“入口文件存在”并不等于“核心逻辑也在那里”。正文会继续落到 TokenizerManager、Scheduler、DetokenizerManager、ScheduleBatch、ModelRunner 与 memory_pool 这几组关键对象上，让目录结构能映射到真正的职责关系。

这一章与请求生命周期章节的关系，是互补而不是重复。前者讲穿透路径，后者讲分层边界；如果后续执行得当，读者应该能把“请求经过哪里”和“每层负责什么”放在同一张图里看。到这一步，你就不再只是背文件名，而是在脑中形成一张有进程边界、数据结构边界和模块职责边界的工作图。