进程边界、IPC 与运行时控制面#

这章解决什么问题#

上一章已经解释了 serving surface、managers、execution layer、cache 和 observability 的分层关系，但还有一个很实际的问题没有展开：这些组件为什么要拆成不同进程，它们之间又靠什么通信。如果不理解这一层，运行时架构就仍然像一张静态分层图，而不是一个真实运行的系统。

这一章要解决的就是“边界为什么不是逻辑边界而已，而是真正的进程边界”。这件事直接关系到性能、稳定性、调试路径和部署复杂度，也会影响你如何理解后面的 trace、回包和 batch 管理。

为什么要把关键组件拆进不同进程#

python/sglang/srt/entrypoints/http_server.py 与 engine.py 的文档字符串已经给出非常明确的结构说明：HTTP server、Engine 和 TokenizerManager 在主进程里，而 Scheduler 与 DetokenizerManager 是子进程，并通过 IPC 通信。这里最重要的，不是“谁在主进程”，而是这种拆分在工程上意味着什么。

一个合理的工作性理解是：HTTP server 与 TokenizerManager 更接近调用表面和请求首尾收敛，因此保留在主进程更有利于对外接口控制；Scheduler 与 DetokenizerManager 则承担更持续、更偏运行时的工作，把它们拆出去有助于隔离状态推进和输出处理。这样做的代价当然是 IPC 带来的复杂度，但换来的是更清晰的运行时控制面。

IPC 为什么是理解运行时的关键#

很多时候，读者会把 IPC 当成实现细节，觉得“反正就是几个进程传消息”。但对 SGLang，这恰恰是运行时架构最值得重视的部分之一。因为请求一旦跨过 TokenizerManager -> Scheduler -> DetokenizerManager 这条链，它就不再只是函数调用，而是状态在多个进程里的接力。

这意味着排障思路也会随之变化。你不能只看某个函数有没有执行，还要看消息有没有真正送出去、有没有被下游进程接住、有没有沿着正确方向回来。因此，这一章的重点不是“IPC 使用了哪个库”，而是“边界一旦变成进程边界，系统的行为理解方式就跟单进程逻辑完全不同”。

一个更贴近真实运行时的进程图#

下面这张图的职责，是把前一章里的组件图压到进程层。相比单纯的模块分层，它多解释了“哪条边是真正的跨进程通信”。

flowchart LR
    subgraph Main["Main process"]
        A["HTTP server"]
        B["Engine"]
        C["TokenizerManager"]
    end

    subgraph Worker1["Scheduler process"]
        D["Scheduler"]
    end

    subgraph Worker2["Detokenizer process"]
        E["DetokenizerManager"]
    end

    A --> B
    B --> C
    C -->|IPC send_to_scheduler| D
    D -->|IPC send_to_detokenizer| E
    E -->|IPC send_to_tokenizer| C

这张图比前一章的组件图多解释了一点：TokenizerManager 既在主进程，又横跨了两条最关键的 IPC 回路。也就是说，它不是一个普通组件，而是运行时控制面和回包路径的桥。

为什么这会影响调试和运维#

一旦把架构理解成多进程控制面，你就会知道为什么 tracing、metrics、request dump 不能只看“某个函数有没有调用”，而要看“某个阶段跨进程后是否仍然成立”。这也是 observability 被单独拿出来的一个重要原因：它不是锦上添花，而是多进程 runtime 的必要外部可见性。

从运维角度看，这种拆分也会影响你理解异常现象的方式。比如一个问题如果只发生在某一段 IPC 之后，就很可能表现成“请求看似进来了，但就是不回包”或“scheduler 工作了，但调用方没有看到进度”。这不是接口 bug，而是控制面问题。

tradeoff：分层更清晰，但控制面更复杂#

把组件拆成不同进程的收益很清楚：职责更清晰，状态推进更可隔离，某些操作更容易并行化，观测面也更容易按阶段打点。但代价也同样明确：跨进程通信、心智复杂度、调试成本和一致性维护都会更高。

这正是好技术书应该讲出来的部分。如果只讲“拆成几个进程更优雅”，读者拿不到真正有用的判断框架；只有把收益和代价一起讲清楚，读者才会明白为什么这种设计既合理，又不免费。

本章对应哪些代码路径#

这一章最重要的锚点包括 python/sglang/srt/entrypoints/http_server.py、python/sglang/srt/entrypoints/engine.py、python/sglang/srt/managers/tokenizer_manager.py、python/sglang/srt/managers/scheduler.py、python/sglang/srt/managers/detokenizer_manager.py，以及这些文件里的 IPC 初始化与消息发送路径。

如果要继续下钻，最好的顺序是：先看入口文档字符串里的进程说明，再看 TokenizerManager 如何把请求送往 scheduler，最后看 detokenizer 如何把结果送回。这样你读到的不是三份分散实现，而是一套有控制面的 runtime。

小结#

把运行时架构讲成“几个目录分层”还不够，真正重要的是理解这些分层在 SGLang 里已经落成了进程边界和 IPC 回路。只有把这一层补清楚，后面的 observability、排障和维护章节才会真正有着力点。