SGLang 专项：28 天计划
白话导读：SGLang 单项目的 28 天计划：单机链路 → 调度与 KV 管理 → HiCache 与外部存储 → 分布式与面试。
- 优先执行全库统一计划。
- 文中给出了不同硬件条件下的执行方案。
每周末按“验收”小节自查。
这是 SGLang 单项目深读计划。跨项目学习优先执行全库统一计划，本表用于补充 Runtime、Radix 和 HiCache 专项任务。
1. 时间安排
总周期 28 天，不超过一个月；每天 2–3 小时。
推荐分配：
- 原理：30–45 分钟。
- 源码：45–60 分钟。
- 实验或复盘：45–60 分钟。
每天结束时，用五分钟记录“今天解释清楚的问题、仍未确认的假设、下一步验证方法”。源码阅读以问题为单位，不要求从头读完大文件。
2. 第一周：打通单机请求链路
| 天数 | 任务 | 资料 | 当天交付 |
|---|---|---|---|
| D1 | Transformer、因果 Attention、Prefill/Decode | 01、04、05 | 画出生成 3 个 token 的计算过程，解释为什么需要 KV |
| D2 | 准备环境，启动小模型，调用普通与流式 API | 07 实验一 | 保存环境、版本、启动命令与完整响应 |
| D3 | TTFT、ITL、TPOT、吞吐、Goodput | 04、07 实验一 | 跑一组基准，明确各指标的统计边界 |
| D4 | HTTP、Tokenizer、Scheduler、Detokenizer | 03 | 画进程图，区分 IPC 与进程内调用 |
| D5 | Req、ScheduleBatch、ForwardBatch | 03 源码路线 | 解释三类对象分别服务哪个阶段 |
| D6 | ModelRunner、模型层、Attention backend | 03、04 | 跟踪一次 Prefill 和一次 Decode forward |
| D7 | 第一周复盘 | 08 题 1–6 | 不看资料讲一次请求，完成 KV 容量计算 |
第一周验收
- 用 5–10 分钟解释从 Prompt 到输出 token 的路径。
- 能找到 Scheduler 主循环与模型执行入口。
- 能解释首 token 为什么通常来自 Prefill。
- 分清客户端 TTFT、GPU Prefill 时间与 E2E。
- 对指定模型手算每 token KV 字节数。
3. 第二周：调度与 GPU KV 管理
| 天数 | 任务 | 资料 | 当天交付 |
|---|---|---|---|
| D8 | Continuous batching、调度预算 | 04 | 手工调度 4 个不同长度请求 |
| D9 | Chunked prefill | 04、07 实验二 | 对比 chunk 大小与 TTFT/ITL/吞吐 |
| D10 | CPU/GPU overlap、CUDA Graph | 03、04、07 实验二 | 对照正常和重叠循环，列出同步依赖 |
| D11 | KV pool、allocator、地址映射 | 05 | 画 request → token slot → tensor 映射 |
| D12 | Radix 匹配、插入、拆分 | 05 | 模拟 3 个公共前缀请求 |
| D13 | 引用计数、淘汰、回退、取消 | 05 | 解释活跃状态与可回收缓存的区别 |
| D14 | Unified Cache、Full/SWA/Mamba | 03、05 | 复盘前缀命中实验与多组件有效性 |
手工调度练习
设有 4 个请求：
| 请求 | 输入长度 | 输出预算 | 到达顺序 |
|---|---|---|---|
| A | 512 | 256 | 1 |
| B | 8192 | 64 | 2 |
| C | 256 | 128 | 3 |
| D | 4096 | 256 | 4 |
不要求复刻 SGLang 的所有细节。用一个假设的 Prefill token 预算和 KV 总容量，逐轮说明：
- 哪些请求运行、哪些等待。
- 每轮新增多少 KV。
- 长 Prefill 如何影响 A 的 ITL。
- 使用 Chunked prefill 后如何变化。
- 缓存容量不足时哪些空闲前缀可淘汰，哪些不能。
第二周验收
- 区分 allocator、pool、prefix cache 和 Attention backend。
- 正确解释节点拆分、引用保护、请求结束与缓存保留。
- 能说明为什么某一种状态命中，不代表混合模型整体可以恢复。
- 能从源码指出正常循环和重叠循环的主要区别。
4. 第三周：HiCache、Mooncake 与 LMCache
| 天数 | 任务 | 资料 | 当天交付 |
|---|---|---|---|
| D15 | GPU、Host、外部存储层次 | 06 | 画查找、预取、加载、回写图 |
| D16 | 写策略、预取策略、页面与布局 | 05、06、07 实验三 | 解释高命中率却更慢的原因 |
| D17 | Mooncake Transfer Engine | 06、09 官方资料 | 解释注册内存、Segment、批量传输与完成 |
| D18 | Mooncake Store | 06、07 实验四 | 画控制/数据平面，完成外部复用实验 |
| D19 | LMCache MP 与 connector | 06、07 实验五 | 验证独立服务及推理进程重启后的复用 |
| D20 | 框架对比与兼容限制 | 06 | 写一页选型说明，列明当前版本限制 |
| D21 | 综合缓存实验 | 07 | 汇总冷缓存、GPU、CPU、外部命中结果 |
第三周验收
- 能清楚区分 Mooncake TE 与 Store。
- 知道 HiCache L2 的共享范围，以及 LMCache 的层级命名差异。
- 能解释兼容性、命名空间与缓存 key 的正确性要求。
- 不把“查到对象”当成“数据已就绪”。
- 用端到端时间和传输数据判断复用是否值得。
5. 第四周：分布式、性能与面试
| 天数 | 任务 | 资料 | 当天交付 |
|---|---|---|---|
| D22 | TP/DP/PP/EP/CP，GQA/MLA/MoE | 04、05 | 解释计算、权重与 KV 的实际分布 |
| D23 | PD 分离 | 06、07 实验六 | 完成 1P1D 或握手与带宽推演 |
| D24 | 量化、投机解码、结构化输出 | 04 | 分别写出收益来源、额外成本与正确性条件 |
| D25 | PyTorch Profiler、Nsight Systems | 07 实验七 | 分析 trace，找出主要瓶颈和一个验证实验 |
| D26 | 长上下文 RAG / Agent 服务设计 | 08 系统设计 | 完成容量、路由、缓存、SLO 与失败恢复方案 |
| D27 | 模拟面试 | 08 | 回答 36 题，为薄弱项补源码证据 |
| D28 | 最终验收 | 09 | 交付实验报告、架构图、源码笔记、项目讲述稿 |
6. 不同硬件条件下的执行方案
| 条件 | 可执行任务 | 限制 |
|---|---|---|
| 只有本地 macOS | 阅读、图示、计算模型、源码和测试分析 | 本手册 CUDA/RDMA 实验需要另配环境 |
| 一张 Linux NVIDIA GPU | 单机 serving、调度、GPU/CPU/外部缓存实验 | 跨实例可采用顺序重启；不能替代多节点网络验证 |
| 两张 GPU | 增加 1P1D、多卡基础实验 | 同机传输不代表跨节点性能 |
| 多节点及 RDMA | PD、共享缓存、网络拓扑与扩展性实验 | 需要记录网络、驱动、NUMA 与并行配置 |
没有 GPU 时，D2、D3、D9、D18、D19、D21、D23、D25 的执行部分可替换为：
- 阅读对应测试与官方示例。
- 分析已有公开 trace 或 benchmark。
- 完成容量和传输成本模型。
- 写出控制变量、测量指标与预期反例。
简历与面试必须区分“设计过”“阅读过”“模拟过”“实际运行验证过”。
7. 时间不足时的取舍
保留所有 P0：请求链路、指标、调度、KV、Radix、HiCache、Mooncake/LMCache 边界。
可以压缩 P2：不在首月深入全部多模态模型、全部 kernel 后端和 Diffusion。把一组缓存或调度实验做扎实，比同时启动很多服务却无法解释结果更有价值。
最终验收与报告模板见 09。