作品指南：设计文档、里程碑与开源贡献¶
作品集、简历与学习计划一章列出了项目方向；这一章把其中最有区分度的三个作品——PD 感知的推理网关、GPU 算子、推理性能可视化工具——拆成可执行的计划：先写什么样的设计文档、分几个里程碑、每个里程碑用什么数字验收。最后是开源贡献的入门路线：几个主要项目的代码怎么读、怎样挑第一个 issue、PR 怎么写才容易被合入。
先写设计文档¶
动手之前花半天写一页设计文档，面试时它就是你讲项目的提纲。建议的结构：
| 部分 | 写什么 | 例子（网关） |
|---|---|---|
| 背景与目标 | 解决什么问题，给出可量化的目标 | "多实例部署下，缓存感知路由让 TTFT P99 比轮询低 50%" |
| 非目标 | 明确不做什么，控制范围 | 不做鉴权、不做多模型路由 |
| 设计 | 架构图、关键数据结构、接口、请求的完整路径 | 近似前缀树、实例健康状态机、PD 配对流程 |
| 取舍 | 至少两个"可以这样也可以那样"的决定和理由 | 路由器内存里维护近似索引 vs 订阅实例的 KV 事件 |
| 验证计划 | 正确性怎么测、性能怎么测、对照组是什么 | 轮询、最少连接两个基线；三档负载 |
| 里程碑 | 每一步的交付物和验收数字 | 见下文 |
| 风险 | 最可能失败的地方和备选方案 | 真实引擎的 PD 接口变化 → 先对接一个固定版本 |
写完之后请人读一遍，对方能不看代码复述出设计，就说明写清楚了。
作品 B：PD 感知的推理网关（Rust）¶
目标：一个放在多个推理实例（SGLang 或 vLLM）前面的网关，支持 OpenAI 兼容接口、缓存感知路由、PD 分离的实例配对，以及生产环境需要的健康检查、重试和指标。相关章节：前缀缓存、PD 分离、分离式架构的全局调度。
| 里程碑 | 交付 | 验收 |
|---|---|---|
| M1：代理 | OpenAI 兼容的 /v1/chat/completions，SSE 流式转发，请求日志 |
流式输出与直连实例逐字节一致；网关自身增加的延迟 P99 < 1 ms |
| M2：路由 | 轮询、最少连接、缓存感知（每个实例一棵近似前缀树）三种策略；负载差距超过阈值时退化为最少连接 | 在多轮对话负载下，缓存命中率和 TTFT 相对轮询的改善有数字；给出阈值的敏感性曲线 |
| M3：PD 与可靠性 | prefill / decode 实例配对（对接 SGLang 的 PD 模式）；健康检查、熔断、重试、优雅下线 | 故障注入：杀掉一个实例后请求自动切走，失败率和恢复时间有数字 |
| M4：可观测与压测 | Prometheus 指标（每个实例的队列、命中率、TTFT / TPOT 分位数）；压测脚本与报告 | 三档负载 × 三种策略的对比表；README 能让陌生人 10 分钟跑起来 |
加分：按"预计 TTFT"统一代价并在过载时提前拒绝（全局调度一章的模拟可以直接当设计依据）；把思路或代码贡献给 SGLang 的 Rust 网关。
作品 C：GPU 算子¶
目标：一个能说明你"下得到硬件"的算子，二选一：MLA 的 decode kernel（参考 FlashMLA 的思路，先 Triton 后 CUDA），或者分块缩放的 FP8 GEMM（参考 DeepGEMM）。相关章节：MLA 推理、FP8 与分组 GEMM，CUDA 手册的 Hopper 异步编程与 CUDA 作品集。
| 里程碑 | 交付 | 验收 |
|---|---|---|
| M1：正确 | 朴素实现 + 与 PyTorch 参考实现对拍的测试（多种形状、边界情况） | 最大误差在约定范围内（FP8 GEMM 用相对误差，MLA 用 bf16 的容差） |
| M2：快 | 分块、共享内存、Tensor Core（WGMMA / mma）、流水线 | 带宽受限的配置给出"占峰值带宽的比例"，计算受限的给出"占峰值 TFLOPS 的比例" |
| M3：解释 | Nsight Compute 报告：剩下的差距在哪（访存、流水线气泡、bank conflict、占用率） | 至少一次"根据 ncu 的结论做出修改并测得提升"的记录 |
| M4：集成 | 作为自定义算子接入 PyTorch（或直接替换 mini-sglang 里的对应 kernel） | 端到端的 decode 延迟或 prefill 吞吐有变化的数字 |
面试时最有说服力的不是"达到了多少 TFLOPS"，而是"我知道剩下的 30% 差在哪里，以及为什么没有继续优化"。
作品 D：推理性能可视化工具（可选）¶
目标：把 PyTorch profiler 的 trace 和推理引擎的日志变成一条可交互的时间线：每一步的 batch 组成、KV 占用、CPU 与 GPU 的空闲、每个请求 TTFT 的分解。相关章节：Profiling 推理引擎。
| 里程碑 | 交付 | 验收 |
|---|---|---|
| M1：解析 | 读取 Chrome trace 格式的 profiler 输出和引擎日志，对齐时间轴 | 能在 SGLang 和 vLLM 的输出上都跑通 |
| M2：视图 | 时间线、每步的 batch 与 KV 占用、请求级的 TTFT 分解 | 在线 demo |
| M3：诊断 | 自动发现常见问题：CPU 调度占比过高、CUDA Graph 未命中、prefill 打断 decode、通信没有重叠 | 用它定位一个真实问题，并写成案例文章 |
开源贡献入门¶
读代码的入口。 先读本手册的vLLM 源码导读和 SGLang 源码导读，再从下面的位置进入各个项目：
| 项目 | 从哪里读起 | 适合的第一类贡献 |
|---|---|---|
| SGLang | python/sglang/srt/managers/（调度器与 TokenizerManager）、srt/model_executor/、srt/layers/；Rust 网关在独立的子项目里 |
新模型支持、文档与示例、可复现的 bug、网关的小功能 |
| vLLM | vllm/v1/core/（调度与 KV 管理）、vllm/v1/worker/、vllm/model_executor/、csrc/ |
测试补全、文档、模型支持、性能回归的定位 |
| FlashInfer | include/flashinfer/（CUDA 头文件形式的 kernel）、python/flashinfer/ |
kernel 的测试与基准、新形状的支持 |
| Mooncake | mooncake-transfer-engine/、mooncake-store/ |
传输引擎的测试、与推理框架的集成 |
挑 issue。 从标记为 good first issue / help wanted 的开始；更好的是自己在使用中发现的问题——你已经能复现它，这是被合入的最大优势。先在 issue 里留言说明你打算怎么做，避免和别人重复。
写 PR。 标题说清楚改了什么；描述里写动机、复现步骤、修改的思路、测试方法，性能相关的修改一定附上前后对比的数据和测量方法；PR 越小越容易被合入，大的改动拆成几个。提交前按项目要求跑格式检查（通常是 pre-commit）和相关测试；有的项目要求提交签名（例如 vLLM 要求每个提交带 Signed-off-by）。评审意见要及时回复，不同意时讲理由和数据。
节奏。 冲刺计划里的目标是 3～5 个 PR，其中至少 1～2 个是非文档的实质修改。路径：文档与测试 → 复现并修一个 bug → 一个小功能。每个合入的 PR 都能在面试里讲成一个完整的故事：发现问题、定位、修复、验证。
怎么讲清楚
介绍作品时用"问题 → 方案 → 数字 → 取舍"的顺序，每个作品准备一个"失败的尝试"：试过什么、为什么不行、学到了什么。面试官追问细节时，设计文档里的"取舍"一节就是你的答案来源。
小结¶
- 先写一页设计文档：目标、非目标、设计、取舍、验证计划、里程碑、风险。
- 作品 B（网关）、C（GPU 算子）、D（可视化工具）各分四个左右的里程碑，每个里程碑都有可量化的验收。
- 开源贡献从读代码的入口、自己能复现的问题开始；PR 小而完整，附复现步骤、测试和前后对比的数据。
发现错误或有更好的写法？在 GitHub 上编辑此页提交问题