<aside> 📌
该文档由 AI 协助编写、人类阅读修正。
</aside>
学 SGLang 最容易走偏的方式，是对着 --help 一个参数一个参数地背。参数有几百个，而且每个月都在变，背下来也不知道什么时候该动哪个。这套笔记反过来走：先把一个请求从进来到出去的路径搞清楚（页面 00），这是骨架；然后每个主题往骨架上挂一块肌肉，参数只是这块肌肉对外露出来的旋钮。知道了旋钮后面连着哪段代码、哪个数据结构，调什么、怎么调就是自然推出来的。
另一个习惯是能算就算。「decode 是带宽受限的」这句话谁都会说，但能算出「128 并发、平均 1000 token 时一步读 KV 要 5 ms」「一个 8K chunk 会把 TPOT 从 7 ms 拉到 247 ms」，才说明真的懂了。每一页都尽量给了一笔这样的账。
| 顺序 | 页面 | 目的 |
|---|---|---|
| 1 | 00 请求生命周期与代码骨架 | 建立全局地图，后面所有参数都往上挂 |
| 2 | 02 显存与 KV Cache → 03 调度与批处理 → 04 前缀缓存 | SGLang 的核心三件套：内存池、连续批处理、RadixAttention |
| 3 | 01 并行策略 → 05 加速执行 | 多卡怎么切、单步怎么算得快 |
| 4 | 06 投机解码 → 07 量化 → 08 PD 分离 | 高级特性，面试加分项 |
| 5 | 09 输出与约束 → 10 多 LoRA → 11 可观测性与调优 | 工程落地能力 |
| 6 | 12 面试高频题（跨主题） | 用「权衡」而不是「参数名」答题 |
| 主题 | 代表参数 | 一句话 |
|---|---|---|
| 并行 | --tp-size --dp-size --pp-size --ep-size --enable-dp-attention --dcp-size |
权重、注意力、专家、流水怎么切到多卡 |
| 显存与 KV | --mem-fraction-static --max-total-tokens --page-size --kv-cache-dtype |
KV 池多大、按多大粒度管、存什么精度 |
| 调度 | --schedule-policy --schedule-conservativeness --chunked-prefill-size --max-prefill-tokens --max-running-requests |
谁先进 batch、一次进多少、怕不怕 OOM |
| 缓存 | --disable-radix-cache --radix-eviction-policy --enable-hierarchical-cache --hicache-* |
前缀复用与多级 KV 缓存 |
| 执行加速 | --attention-backend --cuda-graph-max-bs-decode --disable-overlap-schedule --enable-two-batch-overlap |
内核选择、消除 launch 开销、隐藏 CPU 与通信开销 |
| 投机解码 | --speculative-algorithm --speculative-num-steps --speculative-eagle-topk --speculative-num-draft-tokens |
用便宜的草稿换大模型的并行验证 |
| 量化 | --quantization --kv-cache-dtype --modelopt-quant |
省显存、提带宽利用率 |
| PD 分离 | --disaggregation-mode --disaggregation-transfer-backend --disaggregation-ib-device |
prefill 与 decode 拆开部署 |
| 输出与约束 | --stream-interval --grammar-backend --reasoning-parser --tool-call-parser |
流式粒度、结构化输出、推理与工具调用解析 |
| 多 LoRA | --enable-lora --lora-paths --max-lora-rank |
一个 base 模型同时服务多个适配器 |
| 可观测 | --enable-metrics --log-requests --enable-trace --decode-log-interval |
看得见才调得动 |
子页面见下方（按 00 到 12 编号）。
01 并行策略：TP / DP / PP / EP / CP / DP-Attention