执行摘要
本PR通过将max-num-requests padding到mul-base倍数，避免在CUDA graph捕获过程中被过滤，从而在长上下文、小并发场景下提升性能覆盖范围，优化图形执行效率。
功能与动机
解决在长上下文、小并发情况下，由于mul-base过滤导致最大请求数未被CUDA graph捕获而引发的性能显著下降问题。PR body中明确表述：'For long-context scenarios with small concurrecy, the mul-base filtering could lead to the max-num-requests is not captured. leading to substantial perf drop.'，旨在通过padding策略确保最大请求数被正确捕获，防止性能损失。
实现拆解
修改位于python/sglang/srt/model_executor/cuda_graph_runner.py的get_batch_sizes_to_capture函数，关键改动包括：
- 计算
num_max_requests为model_runner.req_to_token_pool.size。
- 将
num_max_requests padding到mul_base的倍数：num_max_requests = (num_max_requests + mul_base - 1) // mul_base * mul_base。
- 检查
max(capture_bs) > num_max_requests，如果是，则将num_max_requests添加到capture_bs中。
- 添加assert确保
capture_bs非空且为正数：assert len(capture_bs) > 0 and capture_bs[0] > 0, f"{capture_bs=}"。
评论区精华
review讨论非常有限，只有审核者hnyls2002的approval评论：'LGTM'，没有深入讨论或争议点，因此缺乏技术洞察或设计权衡的交流。
风险与影响
风险包括：padding逻辑若错误计算可能导致CUDA graph捕获不准确，影响性能优化；assert添加可能干扰错误处理；由于PR body中未明确测试覆盖情况，可能存在回归风险。影响方面，预计在长上下文、小并发场景下提升推理性能，优化系统效率，对用户和开发者均有积极意义。
关联脉络
在当前仓库的近期历史PR中，未见直接相关的PR。不过，PR #20697修复了VRAM泄漏问题，也涉及性能优化，可能与本PR共同提升系统整体效率，但无直接代码或讨论关联。
参与讨论