执行摘要

• 一句话：解除DS V4 PD prefill的SWA上限
• 推荐动作：该PR改动虽小，但揭示了继承层次导致的容量管理bug，值得研读。对PD分离部署和SWA pool设计感兴趣的工程师可以重点关注。

功能与动机

DS V4 PD prefill此前被SWA pool size限制，因为DeepSeekV4TokenToKVPool继承自通用SWA pool，prefill阶段错误地使用SWA pool容量作为admission上限，导致长请求被拒。类似问题已在解码阶段通过PR#24857修复，但prefill仍未修复。

实现拆解

1. 修改max_total_num_tokens来源：在prefill.py的PrefillServer.__init__中，将原先从构造参数赋值改为从self.scheduler.tp_worker.model_runner.max_token_pool_size获取，该值代表全量KV pool容量，不受SWA pool限制。
2. 移除SWA容量cap：删除对is_hybrid_swa的判断，不再将max_total_num_tokens与swa_max_total_num_tokens取小，因为DS V4在prefill时仅为sliding window分配SWA KV，不应对长prompt进行SWA pool限制。
3. 与解码侧保持一致：该逻辑与schedule_policy.py中非PD场景的判断对齐，确保prefill和decode使用相同的容量边界。

关键文件：

• python/sglang/srt/disaggregation/prefill.py（模块 解聚层；类别 source；类型 core-logic；符号 init）: 核心逻辑修复，解除SWA pool对prefill的容量限制

关键符号：init

关键源码片段

python/sglang/srt/disaggregation/prefill.py

核心逻辑修复，解除SWA pool对prefill的容量限制

# 文件 : python/sglang/srt/disaggregation/prefill.py
# 类 PrefillServer 的 __init__ 方法
​
def __init__(
    self,
    token_to_kv_pool: KVCache,
    draft_token_to_kv_pool: Optional[KVCache],
    req_to_metadata_buffer_idx_allocator: ReqToMetadataIdxAllocator,
    metadata_buffers: MetadataBuffers,
    tp_rank: int,
    tp_size: int,
    gpu_id: int,
    bootstrap_port: int,
    gloo_group: ProcessGroup,
    max_total_num_tokens: int, # 此参数不再使用，保留兼容性
    scheduler: Scheduler,
    pp_rank: int,
    pp_size: int,
    transfer_backend: TransferBackend,
):
    # ... 其他属性赋值 ...
    self.scheduler = scheduler
​
    # 变更 : 从 model_runner 获取真实的 max_token_pool_size
    # 原代码使用传入的 max_total_num_tokens 参数，该参数可能被 SWA pool 限制
    self.max_total_num_tokens = (
        self.scheduler.tp_worker.model_runner.max_token_pool_size
    )
​
    # ... transfer_backend 相关代码 ...
    self.kv_manager = self._init_kv_manager()
​
    # 删除以下代码 : 不再用 SWA pool 大小 cap prefill 容量
    # if self.scheduler.tp_worker.is_hybrid_swa:
    # self.max_total_num_tokens = min(
    # self.max_total_num_tokens,
    # self.scheduler.tp_worker.model_runner.swa_max_total_num_tokens,
    # )

评论区精华

Review中reviewer ispobock提出了两个核心问题：

• 是否将此修复推广到其他SWA模型？ ispobock质疑所有SWA模型是否都只传输sliding window states，并建议引入一个flag区分。作者未直接回应，该问题保持开放。

• 对齐model_runner的max_token_pool_size：ispobock建议直接使用max_token_pool_size以与decode侧一致，该建议被作者采纳。
  此外yhyang201给出了LGTM认可。

• 是否将此修复扩展到其他SWA模型 (design): 作者未明确回应，PR仅修改了prefill.py且未改动基类和flag，该问题留待后续验证。

• 对齐model_runner的max_token_pool_size (correctness): 作者采纳建议，直接使用model_runner.max_token_pool_size。

风险与影响

• 风险：本变更仅涉及PD prefill场景，主要风险在于其他混合SWA模型（如MiMo、Gemma4）可能仍需要此cap。如果这些模型在PD prefill时也依赖swa_max_total_num_tokens作为上限，则可能因容量过高导致OOM。但由于非PD场景已使用类似逻辑，此风险较低。建议在测试中覆盖其他SWA模型的PD场景。
• 影响：对DeepSeek V4用户：修复了PD prefill无法处理长上下文的阻断bug，吞吐提升。对系统：减小了监控指标中prefill拒绝率的误报。对其他SWA模型：潜在回归风险需进一步验证。总体影响范围局限于PD分离部署模式。
• 风险标记：其他SWA模型潜在回归, 缺少测试覆盖

关联脉络

• PR #24857 Related fix for decode SWA: 此PR修复了解码阶段的类似问题，本PR是其在prefill阶段的对应修复。