术语表与对象对照#

这一节解决“同一个词在不同层里是什么意思”这个问题。SGLang 的很多对象会在协议层、manager 层、scheduler 层和执行层反复出现，如果术语不先对齐，后面越深入越容易混淆。

为什么术语要先收口#

系统书一旦变厚，最先失稳的往往不是局部事实，而是对象边界。尤其对 SGLang 这种系统来说，很多词会在不同章节反复出现，但并不站在同一抽象层。只要口径稍微漂移，读者就会在章节之间反复重建对象模型，最后把“回扣”读成“混乱”。

所以这一节不是附录词典，而是整本书后面反复要回来的总坐标。

第一组：请求对象#

最先需要对齐的是请求对象这组词：

更稳的记法是：

• GenerateReqInput 负责统一输入形态
• ReqState 负责 API server 侧状态
• Req 负责 runtime 侧工作单元

第二组：batch 与执行对象#

第二组最容易混的是 batch 和执行对象：

这组对象是第三部分反复回扣的主轴。只要这组边界先稳住，后面读第五章和第六章就不会把调度与执行混成一层。

第三组：manager 边界#

第四章反复要回来的，是下面这组三层边界：

这三个名字如果一开始没对齐，后面无论读主链还是读调试章节，都会一直串层。

第四组：cache 与位置映射#

第五章之后，另一组很容易混的词是：

更稳的记法是：

• ReqToTokenPool 先解决“谁占了哪些位置”
• allocator 再解决“这些位置在哪”
• RadixCache 决定“哪些位置应该继续保留”

第五组：结构化语义对象#

到第七章时，最容易混的是：

这组对象如果一开始不拆开，后面读结构化生成时就很容易把“限制输出空间”和“解释输出结果”写成一件事。

第六组：证据链对象#

最后一组和第四部分最相关：

这些对象之所以要先对齐，是因为第四部分不会再从零解释它们，而是假定你已经知道它们属于哪条证据链。

最容易混淆的几组对照#

下面这些词最容易成对混读，后面尤其值得反查：

• ReqState vs Req
• ScheduleBatch vs ForwardBatch
• TokenizerManager vs DetokenizerManager
• response_format vs tool_choice
• grammar constraints vs parser
• response_sent_to_client_time vs finished_time

如果你在某一章里又开始把这几对词混起来，通常不是那一章本身有问题，而是需要先回到这里重新校准对象边界。

怎样使用这一节#

更实用的用法通常是：

1. 第一次遇到一个对象时，先回这里确认它站在哪一层；
2. 觉得两个词越来越像时，回这里看“不要和什么混读”；
3. 进入第三、第四部分以后，再回来看它们在源码层和证据层分别落在哪。

这一节真正提供的不是术语解释，而是认知止损能力。

小结#

如果把整本书看成一条不断回扣的系统主线，这一节的职责就是防止回扣变成漂移。它不提供新的实现细节，但负责让同一个对象在不同章节再次出现时，仍然站在同一条稳定坐标轴上。