从 benchmark 和 profiler 反向理解实现#

这章解决什么问题#

很多读者在读到 benchmark 或 profiler 输出时，会把它们当成“性能结果展示”。但对一本更厚的技术书来说，性能证据的价值远不止结果本身，它还应该反过来帮助读者更准确地理解 scheduler、cache、execution model 到底在哪里花时间、为什么会花时间。

这一章的目标，就是把 benchmark / profiler 从“结果页”重新变成“源码阅读入口”。

为什么性能证据不该停在图表上#

如果 benchmark 只是告诉你吞吐高低，它的价值仍然有限。真正高价值的部分在于：这些结果能否帮助你更快回到 scheduler.py、memory_pool.py、model_runner.py、ForwardBatch 或 graph runner 路径，解释“为什么会得到这样的曲线”。

这也是为什么好技术书喜欢把性能证据重新接回实现，而不是只展示结论。因为只有这样，读者拿到的才不只是数字，而是更强的判断框架。

一条更像维护者的反向路径#

benchmark / profiler 结果
  -> 判断更像 scheduler / cache / execution / protocol 表面问题
    -> 回到对应章节和源码锚点
      -> 验证假设

这条路径的关键是：不要让 profiler 和 benchmark 变成“最后才看的旁支材料”。它们应该反过来推动你重新读核心实现。

本章对应哪些代码路径#

这一章的锚点主要包括 python/sglang/bench_one_batch.py、python/sglang/bench_serving.py、python/sglang/profiler.py、docs/developer_guide/benchmark_and_profiling.md、docs/developer_guide/bench_serving.md，以及它们回指的 scheduler.py、memory_pool.py、model_runner.py 等核心实现。

小结#

性能证据不是附录。把 benchmark 和 profiler 重新接回源码主线之后，代码导读这一大节才更像一本成熟技术书，而不是一份“看完目录就结束”的导航。