在 multi-http-worker 模式下，批处理请求的服务端健康检查一直停留在 Starting，/health 返回 503。经排查，原因是 _attach_multi_http_worker_info 在 _init_req_state 之后执行，导致子对象缓存了错误的 http_worker_ipc=None。该修复确保了 http_worker_ipc 在子对象构建前被正确设置。
值得立即合并。该修复定位准确、改动量小且修复了关键的生产阻塞问题。建议后续增加对 multi-http-worker 模式下批处理请求的集成测试，防止类似回归。
review 中仅有一个自动评论（gemini-code-assist[bot]），确认了变更内容但未提供额外反馈。无人工 reviewer 参与讨论。
generate_request 方法中的调用顺序：将 _attach_multi_http_worker_info(obj) 移到 _init_req_state(obj, request) 之前。python/sglang/srt/managers/tokenizer_manager.py，改动量极小（2行增加，2行删除）。| 文件 | 模块 | 状态 | 重要度 |
|---|---|---|---|
python/sglang/srt/managers/tokenizer_manager.py |
请求路由 | modified | 5.47 |
python/sglang/srt/managers/tokenizer_manager.py
core-logic
核心修复文件，调整了 `_attach_multi_http_worker_info` 和 `_init_req_state` 的调用顺序，解决多 tokenizer 批处理请求输出路由问题。
# ... 前略 ...
async def generate_request(
self,
obj: Union[GenerateReqInput, EmbeddingReqInput],
request: Optional[fastapi.Request] = None,
):
self.auto_create_handle_loop()
# Normalize the request
obj.normalize_batch_and_arguments()
self._set_default_priority(obj)
# ... DP rank validation ...
# fix: 在 _init_req_state 之前设置 multi-http-worker 信息
# 确保 _init_req_state 中通过 __getitem__ 缓存的子对象能拿到正确的 http_worker_ipc
if self.server_args.tokenizer_worker_num > 1:
self._attach_multi_http_worker_info(obj)
# 初始化请求状态（批处理时会构建并缓存子对象）
self._init_req_state(obj, request)
if self.server_args.language_only:
self._handle_epd_disaggregation_encode_request(obj)
# ... 后续日志、等待、tokenize 与发送 ...
当前评论区没有形成足够清晰的争议点或结论，后续有更多讨论时会体现在这里。
风险极低：仅交换两行代码的执行顺序，不引入新逻辑或新依赖。单 tokenizer 模式和非批处理请求不受影响。需要注意的是，如果 _init_req_state 后续依赖于某些在 _attach_multi_http_worker_info 中设置的状态，则可能引入新问题，但当前代码审查未发现此类依赖。
影响范围：修复了多 tokenizer worker 模式下批处理请求导致健康检查永远无法通过的问题，直接影响依赖该模式的部署（如 PD 分离架构中的 prefill 节点）。影响程度：对于未启用多 tokenizer 的用户无影响；对于已启用的用户，是必选修复。
当前没有检测到明确关联的 Issue 链接，后续同步到相关引用后会出现在这里。
参与讨论