12 · 综合项目：做一次可验证的推理引擎改造

12 · 综合项目：做一次可验证的推理引擎改造

最终目标不是“读完”，而是能提出并验证一个改动

选择一个足够小、能测量的课题：

可观察性：为每轮 Scheduler 输出结构化 trace。
调度实验：调整 Prefill / Decode 优先级或 token 预算策略。
缓存实验：统计 Prefix Cache hit blocks 与节省 token 数。
采样扩展：加入 top-k，并写概率单元测试。
文档贡献：为一个核心模块补充架构图、形状表和最小示例。

推荐的实验闭环

text

问题 → 假设 → 最小改动 → 正确性测试 → 性能测量 → 结论 → 回滚条件

不要从“我要让它更快”开始。一个可验证假设应该像：

在共享长 system prompt 的工作负载中，记录 Prefix Cache 命中率后，我预计 Prefill token 工作量会下降；但若请求前缀高度离散，维护缓存索引不会带来明显收益。

Benchmark 最低要求

固定 commit、模型、权重精度和硬件。
记录 Python、PyTorch、CUDA、Triton、FlashAttention 版本。
明确输入长度、输出长度与并发分布。
先 warmup，再多次测量。
同时报吞吐和延迟，不只挑最好的一次。
修改前后使用同一测试脚本。

上游 README 的示例 benchmark 使用 Qwen3-0.6B、256 条序列，并报告 Nano-vLLM 与 vLLM 的总输出 token、耗时和吞吐。这个数字只代表特定硬件与配置，不应直接推广到其他机器。

推荐项目：Scheduler Trace Viewer

给 schedule() 与 postprocess() 增加可选事件输出：

json

{
  "step": 12,
  "phase": "decode",
  "waiting": 3,
  "running": 16,
  "scheduled_seq_ids": [1, 4, 8],
  "batched_tokens": 3,
  "free_blocks": 120
}

然后做一个本地 HTML 页面读取 JSONL，把 waiting、running、token budget 和 block 使用率画成时间线。它不会改变核心算法，却能证明你已经理解跨模块数据流，也是非常适合作品集与上游 PR 的贡献。

完成定义

[ ] 能解释一次请求的完整生命周期。
[ ] 能区分 Prefill 与 Decode 的性能特征。
[ ] 能手算 block table 到 slot mapping。
[ ] 能指出 Prefix Cache 的命中边界。
[ ] 能在 Eager 模式定位问题。
[ ] 能设计公平的 benchmark。
[ ] 能提交一份包含证据的 README 或 PR。

课后习题等待完成

一个可信的性能优化结论至少应包含什么？

动手任务

选择“Scheduler Trace Viewer”或其他一个小课题，填写问题、假设、指标、修改点、测试方法与回滚条件，形成一页实验计划。