GLM-5.3 推理全链路（十）：CPU 侧的那一半——模板、分词、ZMQ 与调度器控制面

先读这一篇的场景：谁在什么配置下跑

全篇以一条具体请求为准绳，后面所有代码与数字都围绕它：

• 部署：单节点 8×H200，SGLang 主干，--tp-size 8 --attn-dp-size 8 --ep-size 8（即 TP8 + DP Attention + EP），GLM-5.3 FP8 权重，默认端口；
• 请求：POST /v1/chat/completions，单轮对话，带 3 个工具定义，不带图片；输入约 1,024 token（含模板），要求生成 256 token；
• 客户端：stream=true，n=1，未设置 stop 与 stop_token_ids；
• 观测：--enable-metrics 关闭，只看默认回传的 queue_time、first_token_latency、decode_throughput。

选这个配置有两个原因。第一，TP8 + DP Attention 是 GLM-5.3 在单机上的常见形态，也必然经过 DP 控制器那一跳；第二，1K 输入意味着模板与分词的开销不会被长度淹没，便于看清每一站的比例。文中凡是涉及长度的讨论，都会单独指出放大到 100K 时的变化。

前九篇的起点，其实选在了半山腰

前九篇的空间从 ForwardBatch 开始：调度器选出 batch，ModelRunner 把它变成 GPU 张量，然后是 78 层、MoE、索引器、采样、KV 回收。这条路径里的每一步都发生在调度进程内，所有数据结构都是 Python 对象或 GPU 张量。

但在一次真实的 HTTP 请求里，ForwardBatch 既不是起点，也不是终点。起点是 socket 上的字节，终点是另一段 socket 上的 SSE 帧。中间隔着至少三个进程、三条 ZMQ 数据通道、一张请求状态表和两个 tokenizer（一个把文本变 id，一个把 id 变文本）。这一半的工作不产生任何 FLOP，却决定了三件事：

• 请求能否被正确地“翻译”成模型认识的形式（模板与分词）；
• 请求在多个并行组之间如何被路由、排队、取消（控制面）；
• 生成出来的 token 如何变回文本，并在什么时刻停止（输出面）。

第十篇补上这一段。GPU 内部的算子与通信已经在前九篇里拆过，本篇不再重复；所有关于前向细节的结论，都只作为“下一站”引用。

先把部署拓扑画出来：谁在哪个进程

SGLang 的 sglang serve 拉起来的不是一个进程，而是一组。entrypoints/engine.py 的注释把默认布局写得非常直接：

1
1. TokenizerManager: Tokenizes the requests and sends them to the scheduler.
2
2. Scheduler (subprocess): Receives requests from the Tokenizer Manager, schedules batches,
3
   forwards them, and sends the output tokens to the Detokenizer Manager.
4
3. DetokenizerManager (subprocess): Detokenizes the output tokens and sends the result
5
   back to the Tokenizer Manager.

由此得到默认形态下的四个角色：

注意第一行与第二行同属主进程：HTTP 与 TokenizerManager 之间没有 ZMQ，它们通过 asyncio 直接调用。真正跨进程的边界只有两条：主进程 ↔ 调度进程，调度进程 ↔ 反分词进程。若开启 --tokenizer-worker-num N（N > 1），主进程里只剩一个 MultiTokenizerRouter，分词被拆到 N 个 TokenizerWorker 进程里，边界会再多一条。

通道名定义在 server_args.py 的 PortArgs 里，每个名字都指明了方向：

1
class PortArgs:
2
    tokenizer_ipc_name: str          # detokenizer -> tokenizer
3
    scheduler_input_ipc_name: str    # tokenizer -> scheduler(rank 0)
4
    detokenizer_ipc_name: str        # scheduler -> detokenizer
5
    nccl_port: int                   # torch.dist 初始化
6
    rpc_ipc_name: str                # Engine 与 Scheduler 之间的 RPC
7
    metrics_ipc_name: str            # Scheduler 上报 metrics

三条数据通道都用 ZMQ 的 PUSH/PULL 组合：发送端 PUSH、接收端 PULL。managers/scheduler_components/ipc_channels.py 把调度器这一侧的套接字一次建齐：

1
recv_from_tokenizer = get_zmq_socket(context, zmq.PULL, port_args.scheduler_input_ipc_name, False)
2
send_to_tokenizer  = get_zmq_socket(context, zmq.PUSH, port_args.tokenizer_ipc_name, False)
3
send_to_detokenizer = get_zmq_socket(context, zmq.PUSH, port_args.detokenizer_ipc_name, False)

注意只有 rank 0 的调度进程创建收件套接字，其余 rank 的 recv_from_tokenizer 为 None：请求只进 rank 0，调度结果再由 rank 0 按 TP 组的同步方式分发给同组其余 rank。这样避免了同一请求在多个 rank 上被重复解析、重复排队。

PUSH/PULL 没有应答，发送成功只代表消息进了队列，不代表对端处理完。这一点决定了后面所有“超时”“取消”“背压”的行为方式——它们都不是靠通道本身实现的，而是靠上层的状态表与轮询。还有一个例外值得记住：send_to_tokenizer 在 --skip-tokenizer-init 下被复用为“直发 API 侧”的通道，send_to_detokenizer 也指向同一个地址，因为没有反分词这一步。代码里对此有明确注释，改输出协议时两处要一起看。

如果开启 DP Attention（新参数是 --attn-dp-size N，旧写法 --dp-size N --enable-dp-attention 会被归一化成它），拓扑里还会多出一个 DataParallelController 进程。它站在 TokenizerManager 与各 DP 调度器之间，只做一件事：给每条请求选一个 DP rank。此时路径变成“主进程 → DP 控制器 → 第 r 个调度进程”，多了一跳。

1
self._multi_tokenizer_shm = write_data_for_multi_tokenizer(
2
    port_args, server_args, scheduler_info
3
)

1
tokenizer_manager.max_req_input_len = scheduler_info["max_req_input_len"]
2
tokenizer_manager.set_startup_time(scheduler_info["startup_time"])

1
class ServerStatus(Enum):
2
    Up = "Up"
3
    Starting = "Starting"
4
    UnHealthy = "UnHealthy"

1
task = asyncio.create_task(gen())
2
tic = time.time()
3
while time.time() < tic + HEALTH_CHECK_TIMEOUT:
4
    await asyncio.sleep(1)
5
    if _global_state.tokenizer_manager.last_receive_tstamp > tic:
6
        task.cancel()
7
        ...
8
        return Response(status_code=200)

第 1 站：从 socket 到 ChatCompletionRequest

先补一层协议栈。TCP 连接、TLS、HTTP/1.1 或 HTTP/2 的解析都由 uvicorn 与 h11/httptools 完成，这一层不在 SGLang 的代码里，但它决定了第 1 站的输入形态：

• HTTP/1.1 与 keep-alive：同一条连接上的多个请求顺序解析，队头阻塞在协议层就存在；SSE 流式响应会占住整条连接直到结束，所以浏览器对同一域名的并发请求数有上限（通常是 6）。压测高并发时，连接复用比协议本身更重要。
• HTTP/2：--enable-http2 会把 ASGI 服务器从 uvicorn 换成 Granian，由它做 HTTP/1.1 与 h2c 的自动协商，并给出 http2_max_concurrent_streams 与连接级窗口两个参数。多路复用让一个连接承载多个流，但每个流的读仍落在同一个进程的事件循环里；一条大请求体的读取照样会与分词竞争同一线程。
• Content-Length 与 chunked：SGLang 的入口层用一个 ORJSONRequest 覆盖 Request.json()，走 orjson.loads(await self.body())，必须先拿到完整请求体才能解析，因此流式上传的请求体也要全部读完。一个慢速客户端发送 1MB 的 tools 定义，会把这条连接的事件循环时间拉长。

协议层之后才是 FastAPI 的路由与 pydantic 校验。这一段的时间往往被低估：pydantic v2 的模型校验在带嵌套 tools、messages 数组与多模态内容时，单次可达几百微秒。对 TTFT 敏感的服务，把 tools 的 schema 提前编译缓存是常见做法。

HTTP 服务跑在主进程的 uvicorn 事件循环里。一个 POST /v1/chat/completions 到达后，先经过 FastAPI 的路由与依赖注入，再进入 OpenAIServingChat.chat_completion。这一段是纯 CPU、纯 Python：

1. 请求体解析：orjson 把字节解析成字典，pydantic 模型 ChatCompletionRequest 做字段校验与类型转换。输入 1K token 的请求体通常只有几 KB，解析在几十微秒量级；带 logit_bias、大量 stop 字符串或 tools 定义时会放大到毫秒级。
2. 参数归一化：temperature、top_p、top_k、max_tokens、stop、stream、stream_options 被打包成 SamplingParams。max_tokens 缺省时按模型上下文上限与输入长度推算。
3. 约束解码准备：若 response_format 是 JSON schema，后端（xgrammar/outlines）会预编译一个 FSM，后续每个 step 生成 bitmask。这一步的代价与 schema 复杂度相关，和输入长度无关。
4. 模板选择：按模型 id 或 --chat-template 找到模板；GLM-5.3 走的是模型自带的模板（下一节展开）。
5. 请求对象构造：把渲染后的 prompt、sampling 参数、rid、stream 等装进 GenerateReqInput，交给 TokenizerManager。

这一段里最容易被误判为“开销很小”的是模板渲染。它不是字符串拼接：GLM-5.3 的模板要处理 reasoning effort、历史思考段、工具定义与多模态占位，逻辑量比普通 chat template 大得多。

第 2 站：GLM-5.3 的模板到底做了什么

SGLang 的 parser/glm53_chat_template.py 是 GLM-5.3 官方 Jinja 模板的 Python 等价实现，文件头写明“输出与 Jinja 模板逐字节一致”。把它读一遍，就能看清一个请求在进入 tokenizer 之前被改写成了什么。

1
effective_reasoning_effort = (
2
    reasoning_effort if reasoning_effort in ("low", "high") else "max"
3
)
4
f"Reasoning Effort: {effective_reasoning_effort.capitalize()}"

1
if (not clear_thinking or index > last_user_index) and (
2
    reasoning is not _UNDEFINED
3
):
4
    parts.append("<think>" + reasoning + "</think>")

1
# Tools
2

3
You may call one or more functions to assist with the user query.
4

5
You are provided with function signatures within <tools></tools> XML tags:
6
<tools>
7
...
8
</tools>
9

10
For each function call, output the function name and arguments within the
11
following XML format:
12
<tool_call>{function-name}<arg_key>{arg-key-1}</arg_key>
13
<arg_value>{arg-value-1}</arg_value>...</tool_call>

1
_IMAGE_TOKENS = "<|begin_of_image|><|image|><|end_of_image|>"
2
_VIDEO_TOKENS = "<|begin_of_video|><|video|><|end_of_video|>"
3
_AUDIO_TOKENS = "<|begin_of_audio|><|end_of_audio|>"

第 3 站：分词与请求对象的诞生

TokenizerManager.generate_request 是主进程里所有请求的总入口。它的骨架很短：

1
async def generate_request(self, obj, request=None):
2
    self.auto_create_handle_loop()
3
    obj.normalize_batch_and_arguments()
4
    self._set_default_priority(obj)
5
    ...
6
    self._init_req_state(obj, request)
7
    ...
8
    tokenized_obj = await self._tokenize_one_request(obj)
9
    ...
10
    await self._send_one_request(tokenized_obj)
11
    async for response in self._wait_one_response(obj, request):
12
        yield response

三件事值得展开。

1
if self.parallel_sample_num > 1 and self.is_single:
2
    self.is_single = False
3
    if self.text is not None:
4
        self.text = [self.text]
5
    ...

1
if obj.is_single:
2
    ...
3
    async for response in self._wait_one_response(obj, request):
4
        yield response
5
else:
6
    async for response in self._handle_batch_request(obj, request, request_states):
7
        yield response

第 4 站：ZMQ 之后，请求变成状态表里的一行

跨进程之后，“请求”不再是一个对象，而是状态表里的一个条目。TokenizerManager 用 rid_to_state 保存每条在途请求的 ReqState：

1
@dataclass
2
class ReqState:
3
    out_list: List[Dict[Any, Any]]
4
    finished: bool
5
    event: asyncio.Event
6
    obj: Union[GenerateReqInput, EmbeddingReqInput]
7
    time_stats: APIServerReqTimeStats
8
    dispatched: bool = False
9
    abort_sent: bool = False
10
    last_output_offset: int = 0
11
    text: str = ""
12
    text_chunks: List[str] = dataclasses.field(default_factory=list)

这张表承担了三个职责：

• 会合：请求侧在 _stream_one_response 里等 state.event，输出侧在 _handle_batch_output 里把结果追加到 out_list 后 set() 事件。ZMQ 是单向 PUSH/PULL，回程靠的就是这张表和事件对象。
• 断连检测：它有两条路径。排队中（还没有第一帧可发）时，asyncio.wait_for(state.event.wait(), timeout=_REQUEST_STATE_WAIT_TIMEOUT) 到点后检查 request.is_disconnected()（超时来自 SGLANG_REQUEST_STATE_WAIT_TIMEOUT，默认 4 秒）；出流中，每次准备发送下一帧之前也会检查一次。任何一条命中都会调用 abort_request(rid) 并向调度器发出 AbortReq。没有这一步，一个断开的客户端会留下一条永远在跑的请求，持续占 KV。
• 幂等取消：abort_request 用 state.abort_sent 去重。同一个 rid 的重复 abort（客户端断开与超时同时触发）只会向调度器发一次，避免调度器侧重复处理。

abort_sent 还有一层含义：取消是“尽力而为”。ZMQ PUSH 成功只说明消息进了队列；如果调度进程已经卡在 CUDA 同步里，abort 要等下一次 process_input_requests 才会被看到。在 decode 步长 5ms 的场景里这无感；在一条 1M prefill 正在跑的进程里，abort 可能要等一个 chunk 结束。

第 5 站：时间戳跨进程会“翻译”一次

在进入 DP 与调度之前，要先说清一个容易被忽略的细节：同一条请求在不同进程里，时间不是同一个时钟。

ReqState.time_stats 用 time.perf_counter() 记录 created_time、tokenize_finish_time、api_server_dispatch_time、api_server_dispatch_finish_time、first_token_time。perf_counter 是进程内的单调时钟，换一个 PID 就没有意义。

调度进程收到请求后，会换成自己的 perf_counter 口径。SchedulerReqTimeStats 因此把 API 侧的绝对时间字段标成占位：

1
# Placeholder: not used currently
2
# propagated from tokenizer/grpc_server or dp controller
3
created_time: float = 0.0
4
api_server_dispatch_time: float = 0.0
5
dpc_dispatch_time: float = 0.0

替代品是调度器自己测得的阶段时长：wait_queue_entry_time、forward_entry_time、prefill_finished_time，以及累计字段 queue_duration_s。注释里写得很清楚：queue_duration_s 必须在客户端一侧读出，因为“时间戳无法重建时长”。这也是为什么线上监控里 queue_time 是一个时长而不是时间点——它由调度器测，随 BatchTokenIDOutput 回传，最后被 TokenizerManager 写进 meta_info。

DP Attention 下还有第三种时钟：DPControllerReqTimeStats 记录 dpc_dispatch_time 与 dpc_dispatch_finish_time。它同样不向后传播原始时间戳，只做阶段计时。多一跳之后，“请求在控制器里停了多久”只能靠这一对字段算出来。

三类时间统计的传播方向也不同：API 侧统计随请求去调度器，调度器统计随输出回反分词与 API 侧。方向相反，字段不同，不能混在一张表里算总延迟。要看端到端，只能用 first_token_latency 这类由 API 侧单侧计算的值。

第 6 站：DP Attention 下多出来的一跳

前面说过，开启 DP Attention 会多一个 DataParallelController 进程。它的存在不是为了转发，而是为了选路。managers/data_parallel_controller.py 定义了四种策略：

total_tokens 的实现有一个细节值得注意：它用的“token 数”是请求到达时的估计值，也就是 len(req.input_ids)，而不是实际会被算的 token 数：

1
def total_tokens_scheduler(self, req: Req):
2
    if self.maybe_external_dp_rank_routing(req):
3
        return
4
    estimated_tokens = len(req.input_ids)
5
    target_worker = self.dp_budget.dispatch(
6
        LoadBalanceMethod.TOTAL_TOKENS, estimated_tokens=estimated_tokens
7
    )
8
    sock_send(self.workers[target_worker], req)

这意味着两件事。第一，前缀缓存命中不会反映在路由上：一条 100K 输入但命中 90K 前缀的请求，仍按 100K 计入负载，可能被分到一个其实很空的 rank。第二，DP 控制器看不到各 rank 的实时队列，它维护的计数按每条路由消息递增，靠调度器周期性上报的 Load 校正。高并发下，这个估计会短暂失真。

maybe_external_dp_rank_routing 允许调用方用请求头 x-override-routed-dp-rank 直接指定 rank。它主要给 PD 分离与调试用：调用方知道请求应该去哪一组，就不需要控制器再猜。

选完 rank 后，请求被 PUSH 给对应调度进程。此后的所有调度、KV 分配、GPU 前向都只发生在那个进程里；DP 组之间不共享请求队列，也不共享 KV。

第 7 站：调度器的收件箱

调度进程的主循环在 managers/scheduler.py。默认的 event_loop_normal 每轮做四件事：

1
while True:
2
    self.ingest_requests()
3
    plan = self.get_next_batch_to_run(running_batch=self.running_batch, last_batch=self.last_batch)
4
    ...
5
    if batch:
6
        result = self.run_batch(batch)
7
        self.process_batch_result(batch, result)
8
    else:
9
        self.on_idle()

对一条新请求来说，它首先出现在 ingest_requests() 里。这个函数从 ZMQ 收一批消息，再交给 process_input_requests 分发。分发的分支不多，但每个都对应一类控制面行为：

• 普通生成请求：构造 Req，调用 init_next_round_input 做前缀匹配，再进入 waiting_queue；
• 健康检查：/health_generate 的请求有一个特殊 rid 前缀，若服务正忙，调度器直接把“健康”结果回给对应的 HTTP worker，不占用调度步；
• abort：找到 Req 并从队列或 running batch 中移除，释放 KV；
• 控制类请求：flush cache、暂停/继续、导出指标等。

前缀匹配发生在排队之前

init_next_round_input 里最重的一步是 prefix cache 匹配：

1
match_result = match_kv_cache(
2
    self, tree_cache, token_ids_to_match, key_limit, ...
3
)

匹配结果决定 prefix_len，也就是这次 prefill 需要算多少 token。对一条命中 90% 前缀的请求，extend_len 只剩 10%，GPU 时间与 KV 写入都按 10% 计。但匹配本身是 CPU 工作：radix tree 按块比较 token，块越多、命中越深，比较次数越多。1M token 的请求在 64 token/块的粒度下是 16384 次块级比较，量级在毫秒到十几毫秒。

排队之后，请求还要等 KV 页

进入 waiting_queue 不等于马上被调度。get_next_batch_to_run 按策略取请求，取到之后要为新 token 分配 KV 页；池子不够时，请求留在队列里。对 1M 上下文的请求，这一步是硬门槛：57GB 的主 KV 加索引器缓存必须能在目标 rank 上凑齐，否则它永远不会被选中。前一篇文章算过这笔容量账，这里只强调一点——准入判断发生在 CPU 侧，早于任何 GPU kernel。

1
class CachedTokensDetails(BaseModel):
2
    device: int = 0   # Tokens from device cache (GPU)
3
    host: int = 0     # Tokens from host cache (CPU memory)
4
    storage: Optional[int] = None        # Tokens from L3 storage backend
5
    storage_backend: Optional[str] = None

1
"""Idle housekeeping: guard, check, metrics, reset, sleep."""

1
def send_abort_output(self, abort_req: AbortReq, req: Req) -> None:
2
    """Report a request the scheduler ends outside the output stream
3
    (aborted while queued, preempted, retracted or rejected)."""
4
    ...
5
    self.ipc_channels.send_to_tokenizer.send_output(abort_req, req)

1
finish_reason = out["meta_info"]["finish_reason"]
2
status_code = finish_reason.get("status_code")
3
if (
4
    finish_reason.get("type") != "abort"
5
    or status_code is None
6
    or not HTTPStatus.BAD_REQUEST <= status_code < 600
7
):
8
    return None
9
...
10
if not is_stream:
11
    if status_code == HTTPStatus.BAD_REQUEST:
12
        raise ValueError(finish_reason["message"])
13
    raise fastapi.HTTPException(status_code=status_code, detail=finish_reason["message"])
14
return out

第 8 站：GPU 回来时，输出先经过一道“节流阀”

一次 step 结束，调度器拿到 GenerationBatchResult，process_batch_result 更新每条 Req 的输出状态，然后调用 output_streamer.stream_output。这一步不是“有 token 就发”，而是先经过一道节流：

1
if req.stream:
2
    stream_interval = req.sampling_params.stream_interval or self.default_stream_interval
3
    num_unsent = len(req.output_ids) - req.send_token_offset
4
    should_output = (
5
        stream_interval == 1
6
        or num_unsent >= stream_interval
7
        or (req.send_token_offset == 0 and num_unsent > 0)
8
    )
9
    if should_output:
10
        should_output &= not req.check_match_stop_str_prefix()
11
else:
12
    should_output = (len(req.output_ids) % self.default_force_stream_interval == 0)

四行逻辑，四个设计点：

1. 流式默认每步都发（stream_interval == 1）。这就是为什么观察 SSE 时，帧的节奏通常与 decode step 对齐。
2. 首个 token 立即发。投机解码或扩散式解码一步能产出多个 token，若只按 interval 判断，首帧可能被推迟，TTFT 变差。
3. 停止串前缀检查。如果当前已生成文本的尾部恰好是某个 stop 字符串的前缀，就先不发，等下一步确认。否则客户端会先看到半截停止串，再看到它被裁掉。
4. 非流式请求按固定间隔落一次输出。客户端要的是最终结果，但服务端不能把整段输出攒到最后才发：中间态要按 default_force_stream_interval 周期性发给反分词进程，否则一条长输出的全部 token 都压在调度进程内存里。

stream_output 的产物是 BatchTokenIDOutput，一批请求共用一个消息。managers/io_struct.py 里的字段可以分成五组：

注意它带的是 token id 与增量偏移，不是文本——文本要由反分词进程生成。而“配置字段也逐请求携带”是一个容易被忽略的设计：同一个 batch 里，不同请求的 skip_special_tokens 可能不同，反分词进程不能对整批用一套设置，这也是后面 _grouped_batch_decode 要分组的直接原因。

reasoning_tokens 单独计数，而不是混在 completion_tokens 里。对 GLM-5.3 这类推理模型，思考段的长度往往远超最终回答；把两者分开，才能在计费与 SLO 上区分“算得多”和“说得多”。

投机解码让输出一次多走几步

开启 MTP 或 EAGLE 后，一个 verify step 可以接受多个 token，output_ids 一次增长 1 到 $k+1$ 个。stream_output 对此的处理是“按未发送数量判断”，而不是“按是否正好到了间隔”：

1
num_unsent = len(req.output_ids) - req.send_token_offset
2
should_output = (
3
    stream_interval == 1
4
    or num_unsent >= stream_interval
5
    or (req.send_token_offset == 0 and num_unsent > 0)
6
)

注释里解释了原因：一个 step 可能追加多个 token，若只判断“是否恰好等于间隔”，就会跳过多个间隔点，导致输出积压。按“累计未发送量”判断，保证无论一步产出几个 token，客户端都不会等过久。

这也解释了为什么投机解码下 SSE 帧的节奏不是均匀的：接受长度随内容波动，有的 step 一次发 4 个 token，有的只发 1 个。对客户端来说，帧的数量比 token 的数量更不规律，做前端动画或打字机效果时要注意这一点。

第 9 站：反分词进程——把 token 流拼回字符

DetokenizerManager 是独立进程，主循环只有三行：

1
while True:
2
    recv_obj = sock_recv(self.recv_from_scheduler)
3
    output = self._request_dispatcher(recv_obj)
4
    if output is not None:
5
        sock_send(self.send_to_tokenizer, output)

真正的逻辑在 _request_dispatcher 指向的处理函数里。每条请求维护一个 DecodeStatus，用四个游标记录“解码到哪、读到哪、发到哪”。增量解码的做法是：

1. 把从 surr_offset 到 read_offset 的 token 解码成“上一次看到的文本”；
2. 把从 read_offset 到末尾的 token 解码成“这次看到的文本”；
3. 取两者的差集，作为本次新增文本。

1
pending = s.sent_offset - s.decoded_text_len
2
if new_text and not new_text.endswith("�"):
3
    s.append_decoded_text(new_text)
4
    ...
5
    output_strs.append(new_text[pending:] if pending else new_text)
6
else:
7
    printable = find_printable_text(new_text)
8
    s.sent_offset = s.decoded_text_len + len(printable)
9
    output_strs.append(printable[pending:] if pending else printable)

第 10 站：反分词进程的内部机制——裁剪、偏移与批解码

1
self._request_dispatcher = TypeBasedDispatcher(
2
    [
3
        (BatchEmbeddingOutput, self.handle_batch_embedding_out),
4
        (BatchTokenIDOutput, self.handle_batch_token_id_out),
5
        (FreezeGCReq, self.handle_freeze_gc_req),
6
        (ConfigureLoggingReq, self.handle_configure_logging_req),
7
    ]
8
)

1
class DecodeStatus:
2
    decoded_text: str
3
    decode_ids: List[int]
4
    surr_offset: int
5
    read_offset: int
6
    sent_offset: int = 0
7
    decoded_text_len: int = dataclasses.field(init=False)

1
surr_texts = self._grouped_batch_decode(surr_ids, ...)
2
read_texts = self._grouped_batch_decode(read_ids, ...)
3
new_text = read_texts[i][len(surr_texts[i]):]

1
if isinstance(matched, str) and isinstance(output, str):
2
    pos = output.find(matched)
3
    ...
4
    return output[:end] if no_stop_trim else output[:pos]

第 11 站：回到 HTTP 进程——SSE 的最后一公里与三种停止条件

文本回到 TokenizerManager 后，_handle_batch_output 从输出消息里抽取 finish_reason，构造 meta_info，再把文本追加到 ReqState.out_list。等待中的 _stream_one_response 被事件唤醒，取走这一批输出，转成 OpenAI 格式的 chunk，交给 FastAPI 的 StreamingResponse。

这里的“最后一公里”不是比喻。一条 SSE 帧要走完下面这条链：

1
调度进程 → 反分词进程 → TokenizerManager → serving_chat 的生成器 → StreamingResponse → uvicorn → socket

其中只有第一跳与第二跳是跨进程的，后面全在主进程的 asyncio 里。一个慢客户端会在最后两跳上堆积：uvicorn 的写缓冲满时，StreamingResponse 的 send 会等待 drain，生成器被反压，_stream_one_response 不再从 out_list 取数据；out_list 增长到一定程度，内存占用上升。流式接口没有“背压信号”回传给调度器，因此服务端唯一能做的限制是“单连接在途输出量”。

一个常见的工程做法是：客户端侧限制 max_tokens，网关侧限制单连接并发，服务端侧把 stream_interval 调到大于 1，减少帧数。三者都是在减少最后一公里的帧数，而不是减少 token 数。

一条 100K 请求的 CPU 侧账

前面的量级都按 1K 输入算。把输入放大到 100K、并假设前缀缓存命中 90%（命中在 device 上），CPU 侧的账会变成另一种形状：

两个结论：

第一，100K 输入下分词是 CPU 侧的大头。100–300ms 的分词时间已经接近小 chunk prefill 的 GPU 时间；如果 HTTP 与分词同进程，这段时间里事件循环被占住，其他请求的 SSE 帧、健康检查、甚至 keep-alive 的心跳都会延迟。--tokenizer-worker-num 正是为这种场景准备的。

第二，前缀命中把 GPU 时间砍掉 90%，但砍不掉 CPU 时间。模板渲染仍要遍历全部消息，分词仍要处理全部 100K 文本，前缀匹配仍要比较全部块。命中省的是“算”，不是“读”。这就是为什么长上下文场景里，CPU 侧优化（分词批处理、模板缓存、前缀索引）与 GPU 侧优化同样重要。

观测：三个数就能定位

线上排查时，不需要把上面的每一站都打点。三个数就能把问题归到一段：

1. queue_time：从请求进入调度器队列到被调度。它大，说明 GPU 侧被占满或 KV 不足，不是入口层的问题。
2. first_token_latency - queue_time：首 token 延迟减去排队时间，剩下的是“入口 + prefill + 输出首帧”。它大而 queue_time 小，说明瓶颈在分词、模板、前缀匹配或 prefill 本身。
3. decode_throughput：decode 阶段的 token 速率。它低而前两项正常，说明问题在 decode 的 batch 组成或输出侧。

这三个数分别来自三处：

• queue_time 由 SchedulerReqTimeStats.queue_duration_s 回传，注释里明确说“时间戳无法重建时长”；
• first_token_latency 由 API 侧的 APIServerReqTimeStats 计算，是唯一跨进程仍可用的端到端指标；
• decode_throughput 也是 API 侧算的，用 completion_tokens 除以 decode 时长。

要更细的分解，就得打开 --enable-metrics 或 tracing；否则调度器侧的 SchedulerReqTimeStats 在序列化时会直接返回空字典——__getstate__ 的第一行就是：

1
if not (self.enable_metrics or self.has_timing_data):
2
    return {}

这个设计是有意的：默认情况下不把每条请求的详细阶段数据搬过进程边界，避免输出消息膨胀。代价是“默认观测只能看到粗粒度”，细粒度必须显式开启。

一条请求的 CPU 预算

把上面的站点按时间顺序排一遍，给出 8×H200、TP8 + DP Attention、输入约 1K token、输出 256 token 的量级估计。数字是数量级，不是实测值：

这张表里只有分词与前缀匹配会进入毫秒级。它们都不在 GPU 上，也都不受 batch 大小摊薄——batch 从 1 涨到 64，这两项的成本按请求数线性增长。吞吐场景下，它们比单个 kernel 的优化更容易成为瓶颈。

三个不变量

跨进程之后，正确性依赖三条不变量。任何一条被破坏，症状都不是报错，而是“偶发的错字、错序、错请求”。

三类常见故障

与 vLLM V1 的控制面对照

同一段时间线，vLLM V1 用的是另一套切法：

差异的根源在“反分词放在哪”。vLLM 把反分词放进 API Server 进程，省掉一跳，代价是 API Server 进程要同时承担 HTTP、分词、反分词与输出合并；SGLang 把反分词拆出去，主进程只负责“翻译入口与出口”，代价是多一次跨进程。

两条路线在低并发下的延迟差别很小，在高并发下的资源竞争模式完全不同：vLLM 的 API Server 更容易成为 CPU 瓶颈，SGLang 的反分词进程则成为一个独立的、可单独扩容（多实例）的组件。选型时看的是“哪一段更容易被请求数压满”，而不是“哪条路径少一跳”。

五个框架的进程边界与通道细节，已在 前端与引擎之间的那道进程边界 里做过横向拆解；这里只把它作为 SGLang 控制面的参照。

与 GPU 侧的接口

把 CPU 侧做完的事压缩成三句话，就是它与 GPU 侧的接口：

1. 形状：ForwardBatch 的 input_ids、positions、out_cache_loc 由 CPU 侧决定，错一个字段，RoPE 相位或 KV 页地址就会错；
2. 容量：准入判断在 CPU 侧完成，GPU 只接受已经分配到页的请求；
3. 时序：abort、停止串、输出节流都在 CPU 侧生效，GPU 不知道“客户端已经走了”。

这也是为什么一条请求的端到端延迟不能只用 GPU 时间来估算。GPU 时间是下界，CPU 侧的分词、匹配、反分词、SSE 写出都是加法项；在低延迟场景里，加法项可能占掉 TTFT 的三分之一。

从 CPU 侧反推部署参数

这一篇拆的都是“默认路径”，但每一站都对应一个可以调的参数。下面这些是从 CPU 侧能直接影响的旋钮，部署时按瓶颈选择，而不是一次性全开：

这张表也解释了为什么“把 GPU 跑满”不等于“把服务跑好”。上面七个参数里，只有 KV 池大小与 GPU 容量直接相关，其余六个都在 CPU 侧。在吞吐已经接近硬件上限的场景里，继续调 kernel 的收益会变小，而把这几个参数调对，往往能拿回 10% 以上的有效吞吐。

小结

第十篇把镜头从 GPU 移开，沿着一条 GLM-5.3 请求的 CPU 路径走了十个站点：

• 主进程里完成协议解析、模板渲染与分词；
• ZMQ 把请求交给调度进程，回程靠 ReqState 的事件表；
• DP Attention 下多一个控制器进程做路由；
• 调度器在排队之前做前缀匹配与 KV 准入；
• 输出先过节流，再进反分词进程做增量拼接与停止串裁剪；
• 最后回到 HTTP 进程，变成 SSE 帧。

前九篇解释了“GPU 上算了什么”，这一篇解释了“GPU 之前与之后发生了什么”。两者合起来，才是一条请求的完整生命周期。

下一篇将讨论这套控制面在 PD 分离部署下的变形：当 prefill 与 decode 分属两个进程组，ReqState、abort 与输出节流分别落在哪一侧。

参考资料

1. SGLang GitHub 仓库
2. SGLang: Efficient Execution of Structured Language Model Programs（arXiv:2312.07104）
3. Taming Throughput-Latency Tradeoff in LLM Inference with Sarathi-Serve（arXiv:2403.02310）
4. Llumnix: Dynamic Scheduling for Large Language Model Serving（arXiv:2406.03243）
5. vLLM 官方博客：vLLM V1 的多步调度与批处理
6. DeepSeek-V3.2: Pushing the Frontier of Open Large Language Models（DSA 与 MLA 结构，arXiv:2512.02556）