文章目录
一、总体架构
1)架构图和线程关系
主进程(一个 PID)
├── 对象:HTTP Server(FastAPI app)
├── 对象:TokenizerManager
├── 用 Engine 的启动逻辑 fork/spawn 出下面这些
│
├── 子进程:Scheduler #1(里面有 ModelRunner,加载权重、跑前向)
├── 子进程:Scheduler #2 ← tp_size / pp_size 大了才会有多个
├── ...
└── 子进程:DetokenizerManager(一个)

2)模型加载流程
- 当服务启动时,用户可以通过 python -m sglang.launch_server 启动服务。该命令调用 prepare_server_args 解析命令行参数,构造 ServerArgs,其中包括 model_path、tp_size、dtype 等配置。
- 随后,服务启动 Scheduler 子进程。Scheduler 初始化时创建 ModelConfig 和模型 worker;模型 worker 再创建 ModelRunner。ModelRunner 根据 ModelConfig 确定模型架构与相关配置,准备模型加载器,实例化模型并加载权重。
- 模型加载完成后,服务继续完成 DetokenizerManager、TokenizerManager 和 HTTP Server 的初始化,进入可接收请求的状态。
3)模拟启动过程
1.如果dp_size大于1
PP = 2
TP = 2
DP = 1
因此会创建:
PP × TP = 2 × 2 = 4 个 Scheduler 进程
Scheduler(pp=0,tp=0)
Scheduler(pp=0,tp=1)
Scheduler(pp=1,tp=0)
Scheduler(pp=1,tp=1)
2.如果dp_size大于1
DP Controller 根据轮询、当前请求数或 Token 数,把每个请求交给负载较低的模型副本。
客户端请求
↓
DP Controller
├── DP副本0:4个Scheduler(PP2 × TP2)
├── DP副本1:4个Scheduler(PP2 × TP2)
└── DP副本N:4个Scheduler(PP2 × TP2)
执行流程就是

4)scheduler主循环
接收请求
↓
更新 waiting / running 队列
↓
选择当前 Prefill 或 Decode Batch
↓
提交当前 Batch 到 GPU
↓
结果暂存 result_queue
↓
CPU 处理上一 Batch 的结果
↓
更新 Token、完成状态与 KV Cache
↓
进入下一轮
-
具体ModelRunner流程
-> _initialize_model -> get_model_architecture -> get_packed_modules_mapping -> get_quant_config -> model_class(config, quant_config, ...) -> _get_all_weights -> load_weights_and_postprocess -> model.load_weights -> quant_method.process_weights_after_loading
量化方法
