SGLang模型加载过程笔记

文章目录

- 一、总体架构

一、总体架构

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

量化方法