第四章运行时架构 on Machine Learning 学习笔记

4.1 `launch_server.py` 与 `http_server.py` 的入口分层

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

`launch_server.py` 与 `http_server.py` 的入口分层#

这一节解释启动入口为什么被切成现在这样，以及 CLI、bootstrap 和 HTTP server 怎样共同把运行时拉起来。重点不在“有几个入口文件”，而在“哪一层负责模式选择，哪一层负责拉起子进程，哪一层负责真正监听 HTTP”。

这一节解决什么问题#

如果只看文件名，SGLang 的启动入口似乎只是：

一个 python -m sglang.launch_server
一个 sglang serve
一个 http_server.py

但从运行时架构看，这三者的职责并不一样：

launch_server.py 负责选模式；
http_server.launch_server(...) 负责把 HTTP server 和 runtime engine 接起来；
_setup_and_run_http_server(...) 才真正让 uvicorn 对外监听。

把这三层分清楚，后面读 TokenizerManager、Scheduler 和 PortArgs 时才不会把启动装配逻辑和请求主链混在一起。

一张图先看入口分层#

flowchart TB
 A["launch_server.py<br/>run_server"] --> B["选择模式<br/>HTTP / gRPC / Ray / encoder-only"]
 B --> C["http_server.launch_server"]
 C --> D["Engine._launch_subprocesses"]
 C --> E["_setup_and_run_http_server"]
 E --> F["uvicorn / FastAPI"]

图里最重要的一点是：launch_server.py 不直接负责把 HTTP server 跑起来，它先做模式分发；真正把 SRT runtime 和 HTTP 入口缝在一起的是 http_server.launch_server(...)。

4.2 `TokenizerManager`、`Scheduler` 与 `DetokenizerManager` 的职责边界

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

`TokenizerManager`、`Scheduler` 与 `DetokenizerManager` 的职责边界#

这一节把最关键的 manager 边界讲清楚。它们不是简单的功能模块拼盘，而是一组为了把请求主链拆成可维护 handoff 点而设计出来的运行时边界。

这一节解决什么问题#

第三章已经把请求主链走通了，但还留下一个更基础的问题：为什么非得拆成 TokenizerManager、Scheduler 和 DetokenizerManager 三个 manager？如果只是“功能不同”这么简单，其实完全可以塞进一个大 process 里慢慢分函数写。

这一节真正要回答的是：

三个 manager 各自托管了什么状态；
为什么这些状态不能都堆在同一个对象里；
后面读调度、回包和调试时，应该先回到哪一个边界上。

一张图先看三条边界#

flowchart LR
 A["TokenizerManager<br/>请求接入 / 状态宿主 / tokenization"] --> B["Scheduler<br/>Req / queue / batch / runtime gate"]
 B --> C["DetokenizerManager<br/>token ids -> text delta"]
 C --> A

这张图更强调边界职责，而不是流向。三个 manager 不是主链上的三个“顺路函数”，而是三层不同的状态托管面。

`TokenizerManager` 站在 API server 一侧#

TokenizerManager 的初始化顺序已经很能说明它的定位：

读 ServerArgs
初始化 tokenizer / multimodal processor
建 IPC 通道
建运行时状态
建日志、LoRA 和 weight update 相关状态
最后建 request dispatcher

这意味着它托管的不只是 tokenize，还包括：

4.3 Process、rank、port 与 IPC 拓扑

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

Process、rank、port 与 IPC 拓扑#

这一节负责把进程、rank、port 和 IPC 拓扑稳定下来。很多行为差异根本不是业务逻辑分支，而是拓扑位置变化。

这一节解决什么问题#

前两节已经把入口分层和 manager 边界讲清楚了，但还缺最后一层：这些 manager 到底怎样跨进程互相说话？同样是 TokenizerManager -> Scheduler -> DetokenizerManager 这条链，单进程心智和多进程拓扑心智完全不是一回事。

这一节要解决的是三类问题：

PortArgs 到底在命名什么；
get_zmq_socket(...) 怎样把这些名字变成真正的 IPC 端点；
rank、worker 数和 enable_dp_attention 这些条件怎样改写拓扑。

一张图先看默认拓扑#

先看最普通的单 tokenizer、非 DP attention 拓扑：

flowchart LR
 A["TokenizerManager<br/>scheduler_input_ipc_name"] --> B["Scheduler"]
 B --> C["DetokenizerManager<br/>detokenizer_ipc_name"]
 C --> D["TokenizerManager<br/>tokenizer_ipc_name"]

这张图虽然简单，但已经足够说明一件事：请求主链的跨进程通信不是抽象概念，而是三个被明确命名的端点。

`PortArgs` 是拓扑字典#

PortArgs 的字段本身就很像一张拓扑表：

tokenizer_ipc_name
scheduler_input_ipc_name
detokenizer_ipc_name
rpc_ipc_name
metrics_ipc_name
tokenizer_worker_ipc_name

这些名字不是普通配置项，而是在给整张进程通信图命名。对读者来说，理解 PortArgs 最稳的方式不是记每个字段，而是先记住：后面每个 manager 读到的不是随意字符串，而是当前拓扑里的通信端点表。

PortArgs.init_new(...) 还进一步说明，拓扑不是固定不变的：

非 DP attention 时，默认用本地 ipc://...
开了 DP attention 以后，会切到 TCP + 明确端口

所以这里的“port”并不只是网络端口，而是整套通信方式选择的一部分。

4.4 Tensor Parallelism 执行路径

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

Tensor Parallelism 执行路径#

第四章前三节解释了 manager 边界和 IPC 拓扑。这一节回答另一个问题：当 tp_size > 1 时，同一个 forward pass 是怎样被分配到多张 GPU 上的？

这不是"多 GPU 各跑各的请求"，而是"同一个请求的同一次前向，被拆开在多张 GPU 上协同计算"。

这一节解决什么问题#

Tensor Parallelism 的权重切分方式——哪些矩阵被横切，哪些被纵切；
每次前向计算后，多个 rank 怎样通过 AllReduce 把结果合并；
ModelRunner 在多 rank 场景下怎样让所有 rank 保持动作一致；
调试 TP 相关问题时先看哪里。

一张图先看 TP 的权重切分#

对 Transformer 模型，TP 主要切分两类矩阵：

单 GPU（tp_size=1） 4 GPU（tp_size=4）
───────────────────── ──────────────────────────────────
Attention QKV projection 每 GPU 处理 1/4 的 attention heads
 [d_model, 3*d_model] → [d_model, 3*d_model/4] × 4 GPU

Attention output projection 每 GPU 处理 1/4 的行
 [d_model, d_model] → [d_model/4, d_model] × 4 GPU
 + AllReduce
MLP gate/up projection 每 GPU 处理 1/4 的 hidden_dim
 [d_model, 4*d_model] → [d_model, d_model] × 4 GPU

MLP down projection 每 GPU 处理 1/4 的输入维度
 [4*d_model, d_model] → [d_model, d_model] × 4 GPU
 + AllReduce

这种切分方式被称为 Megatron-LM 风格的 TP：attention heads 被均匀分配给各 rank（column parallel），输出矩阵按行切分（row parallel），每层结束时通过 AllReduce 合并各 rank 的部分结果。

第四章 运行时架构 on Machine Learning 学习笔记

4.1 `launch_server.py` 与 `http_server.py` 的入口分层

launch_server.py 与 http_server.py 的入口分层#

这一节解决什么问题#

一张图先看入口分层#

4.2 `TokenizerManager`、`Scheduler` 与 `DetokenizerManager` 的职责边界

TokenizerManager、Scheduler 与 DetokenizerManager 的职责边界#

这一节解决什么问题#

一张图先看三条边界#

TokenizerManager 站在 API server 一侧#

4.3 Process、rank、port 与 IPC 拓扑

Process、rank、port 与 IPC 拓扑#

这一节解决什么问题#

一张图先看默认拓扑#

PortArgs 是拓扑字典#

4.4 Tensor Parallelism 执行路径

Tensor Parallelism 执行路径#

这一节解决什么问题#

一张图先看 TP 的权重切分#

第四章运行时架构 on Machine Learning 学习笔记

`launch_server.py` 与 `http_server.py` 的入口分层#

`TokenizerManager`、`Scheduler` 与 `DetokenizerManager` 的职责边界#

`TokenizerManager` 站在 API server 一侧#

`PortArgs` 是拓扑字典#