不同角色的建议阅读路径#

这一节不是在重新列目录，而是在回答“不同背景的工程师应该怎样进入这本书”。平台工程、推理 runtime 和框架工程读同一套材料时，最关心的切口并不一样。

为什么这层值得单独成节#

一本系统书一旦变厚，单纯给出目录顺序就不够了。读者还会自然问：

• 如果我是平台工程师，我最该先抓哪几章？
• 如果我最关心吞吐、batch 和 cache，该避开哪些前期噪声？
• 如果我更偏接口和结构化语义，应该先看哪里？

这一节的作用，就是把整本书按角色重新剪成几条更具体的阅读线。

路线一：平台工程 / serving 工程#

如果你的核心问题是：

• 服务怎样启动与装配
• 请求怎样穿过 managers
• 多 worker / rank / mode 怎样改变系统行为
• 线上故障怎样先回到正确的证据链

那么更稳的顺序通常是：

1. 第一章 系统概览
2. 第三章 请求路径
3. 第四章 运行时架构
4. 第五章 调度、批处理与 KV Cache
5. 第九章 可观测性与调试

这条路线的重点不是尽快钻执行细节，而是先把系统边界和控制面立住。

路线二：推理 runtime / 性能工程#

如果你的核心问题是：

• batch 为什么会长成这样
• prefix reuse、KV cache 和吞吐为什么会互相影响
• token selection、finish reason 和 output tail 为什么会这样工作
• 优化后应该拿什么证明它真的更快了

那么更稳的顺序通常是：

1. 第一章 系统概览
2. 第三章 请求路径
3. 第五章 调度、批处理与 KV Cache
4. 第六章 执行模型与采样
5. 第九章 可观测性与调试

这条路线会更快进入系统内部的“硬”部分，但仍然保留足够的入口和路径背景，避免一开始就把 scheduler.py 读散。

路线三：接口 / 框架 / agent workflow#

如果你的核心问题是：

• OpenAI-compatible、native、Responses 这些表面有什么真正差异
• 结构化生成怎样进入执行链
• parser、tool choice 和 built-in tools 怎样变成可用工作流

那么更稳的顺序通常是：

1. 第一章 系统概览
2. 第三章 请求路径
3. 第六章 执行模型与采样
4. 第七章 结构化生成与 API 表面
5. 第十章 扩展点与维护策略

这条路线不会绕开 runtime，而是先补足 enough runtime context，再进入更靠近表面语义的一层。

为什么三条路线最后都还要回到代码导读和维护层#

因为一本真正像“书”的技术作品，不应该让角色化阅读变成“各看各的分册”。三条路线虽然从不同章节进入，但最后都应该回到：

• 代码导读：把抽象重新压回源码树；
• 调试与维护：把理解重新落回证据链和维护动作。

否则它仍然更像主题文章合集，而不是一本能被不同角色共用的系统书。

如果时间很少，该怎样读#

可以用“角色 + 主线 + 验证”三段法：

1. 先选一条最贴近自己工作的角色路线；
2. 用这条路线把主心智模型立起来；
3. 最后至少回到一节调试或维护章节，确认这些理解能真正落到源码和证据链上。

这样读完以后，你带走的就不只是理解，还会多一条实际可用的进入路径。

小结#

这一节真正要补齐的，不是另一份目录，而是一本系统书应有的“第二层导航”：同一套内容可以按角色重新组织，但最后仍然回到同一条系统主线。