pp_max_micro_batch_size 是可选 CLI 参数，默认 None 时调度器自动计算为 max(self.max_running_requests // self.pp_size, 1)。但显式传入 0 会绕过 is None 检查，导致 get_num_allocatable_reqs 始终返回 ≤0，任何请求都无法从等待转为运行，generate() 无限挂起。该 bug 属于同一家族（与 prefill_max_requests=0 类似）。相关 Issue #23789。
值得合入的快速 bugfix，设计精巧（双重防护）。可作为防御性编程的示例。
PR 审核人 ShangmingCai 快速批准（LGTM），无实质性讨论。
server_args.py 的 check_server_args 方法中新增 assert，确保 pp_max_micro_batch_size 为 None 或 ≥1，否则在启动阶段抛出清晰错误信息。scheduler.py 的 init_model_worker 中，将条件判断从 is None 改为 not pp_max_micro_batch_size，使得显式 0 也会进入自动计算路径，覆盖程序化调用 Engine() 绕过 CLI 校验的场景。| 文件 | 模块 | 状态 | 重要度 |
|---|---|---|---|
python/sglang/srt/server_args.py |
启动配置 | modified | 5.47 |
python/sglang/srt/managers/scheduler.py |
调度器 | modified | 5.1 |
python/sglang/srt/server_args.py
core-logic
新增启动时断言，拒绝非正数值，提供清晰的错误消息。这是第一道防线。
# python/sglang/srt/server_args.py (head 版本 )
def check_server_args(self):
# ... 之前的校验 ...
assert (
self.pp_max_micro_batch_size is None or self.pp_max_micro_batch_size >= 1
), (
"pp_max_micro_batch_size must be a positive integer or None (for auto-compute). "
f"Got: {self.pp_max_micro_batch_size}"
)
# ... 后续校验 ...
check_server_args 方法中新增断言，确保只有 None 或 ≥1 的值才能通过。当传入 0 时，会立即抛出 AssertionError 并附带清晰提示，在模型加载和 CUDA 图捕获之前快速失败。python/sglang/srt/managers/scheduler.py
core-logic
将条件从 `is None` 改为 `not pp_max_micro_batch_size`，使 `0` 也能触发自动计算，作为第二道防线。
# python/sglang/srt/managers/scheduler.py (head 版本 )
def init_model_worker(self):
# ... 从 tp_worker 获取配置 ...
if not get_global_server_args().pp_max_micro_batch_size:
# 原为 get_global_server_args().pp_max_micro_batch_size is None
# 现在 0 也会进入此分支，自动计算安全值
get_global_server_args().pp_max_micro_batch_size = max(
self.max_running_requests // self.pp_size, 1
)
is None 扩展为 not，使得值 0 也会被视为“未设置”而触发自动计算。这作为防御性措施，覆盖通过编程接口 Engine() 绕过 CLI 校验的情况。当前评论区没有形成足够清晰的争议点或结论，后续有更多讨论时会体现在这里。
风险极低。改动仅涉及数值范围检查和布尔条件放宽，不改变正常使用流程（None 或正数）的行为。唯一潜在风险是若其他代码错误地将 pp_max_micro_batch_size 设为 0，现在会快速失败而非静默死锁，实际是改进。
影响范围小，仅影响错误配置 pp_max_micro_batch_size=0 的用户。修复后用户会立即看到清晰的断言错误消息，而非无响应的死锁。对正常用户无影响。
参与讨论