[TRTLLM-12403][fix] Fix deepseekv4 stall - #13650
Merged
Merged
Conversation
…IA#12208) Signed-off-by: Chien-Chun Hung <2679986+chienchunhung@users.noreply.github.com>
…VCache check In gen-only benchmark mode the executor calls _check_benchmark_disagg_gate every iteration and `continue`s when the fill phase is not yet complete. Before that the scheduler has already called try_allocate_generation, which grows each gen request's KV capacity by 1 (+draft_len). Without a matching revert the capacity drifts upward across the many retried iterations until it overflows the host page-index buffer, raising ValueError: User-provided base page indices is too short from KVCacheManagerV2._KVCache.resize. Revert the spurious growth on the should_retry path in both _executor_loop and _executor_loop_overlap, gated by _scheduler_manages_kv_suspend so V1 is unaffected. The previous "Insufficient KV cache for gen-only benchmark mode" guard compared the per-rank num_fetch_requests against the global benchmark_req_queues_size threshold. Under attention DP, prompts are routed across TP ranks via the ADP router, so per-rank fetch counts saturate well below the global threshold and the guard never fires -- deadlocks become silent walltime hangs. Replace it with a liveness watchdog that tracks the per-rank ready-to-forward gen request count (DISAGG_GENERATION_TRANS_COMPLETE + GENERATION_IN_PROGRESS); if the count does not change for >60s, log an explicit error, fail all active requests via _handle_errors, and return None to break the executor loop. The watchdog uses a local-only count so it does not introduce a collective at a point where rank participation can diverge under ADP. Signed-off-by: Iman Tabrizian <10105175+tabrizian@users.noreply.github.com>
Signed-off-by: Chuang Zhu <111838961+chuangz0@users.noreply.github.com>
chuangz0
requested review from
HuiGao-NV,
byshiue and
lancelly
and removed request for
a team
April 30, 2026 06:13
chuangz0
changed the title
Signed-off-by: Chuang Zhu <111838961+chuangz0@users.noreply.github.com>
lfr-0531
pushed a commit
that referenced
this pull request
May 7, 2026
Squash of three commits cherry-picked from #13650: * Fix gen-only benchmark for KVCacheManager V2 + improve insufficient KVCache check In gen-only benchmark mode the executor calls _check_benchmark_disagg_gate every iteration and `continue`s when the fill phase is not yet complete. Before that the scheduler has already called try_allocate_generation, which grows each gen request's KV capacity by 1 (+draft_len). Without a matching revert the capacity drifts upward across the many retried iterations until it overflows the host page-index buffer, raising ValueError: User-provided base page indices is too short from KVCacheManagerV2._KVCache.resize. Revert the spurious growth on the should_retry path in both _executor_loop and _executor_loop_overlap, gated by _scheduler_manages_kv_suspend so V1 is unaffected. The previous "Insufficient KV cache for gen-only benchmark mode" guard compared the per-rank num_fetch_requests against the global benchmark_req_queues_size threshold. Under attention DP, prompts are routed across TP ranks via the ADP router, so per-rank fetch counts saturate well below the global threshold and the guard never fires -- deadlocks become silent walltime hangs. Replace it with a liveness watchdog that tracks the per-rank ready-to-forward gen request count (DISAGG_GENERATION_TRANS_COMPLETE + GENERATION_IN_PROGRESS); if the count does not change for >60s, log an explicit error, fail all active requests via _handle_errors, and return None to break the executor loop. The watchdog uses a local-only count so it does not introduce a collective at a point where rank participation can diverge under ADP. * trim kv cache out of window after receive kv cache * fix stall Signed-off-by: Chuang Zhu <111838961+chuangz0@users.noreply.github.com>
lfr-0531
pushed a commit
that referenced
this pull request
May 14, 2026
Squash of three commits cherry-picked from #13650: * Fix gen-only benchmark for KVCacheManager V2 + improve insufficient KVCache check In gen-only benchmark mode the executor calls _check_benchmark_disagg_gate every iteration and `continue`s when the fill phase is not yet complete. Before that the scheduler has already called try_allocate_generation, which grows each gen request's KV capacity by 1 (+draft_len). Without a matching revert the capacity drifts upward across the many retried iterations until it overflows the host page-index buffer, raising ValueError: User-provided base page indices is too short from KVCacheManagerV2._KVCache.resize. Revert the spurious growth on the should_retry path in both _executor_loop and _executor_loop_overlap, gated by _scheduler_manages_kv_suspend so V1 is unaffected. The previous "Insufficient KV cache for gen-only benchmark mode" guard compared the per-rank num_fetch_requests against the global benchmark_req_queues_size threshold. Under attention DP, prompts are routed across TP ranks via the ADP router, so per-rank fetch counts saturate well below the global threshold and the guard never fires -- deadlocks become silent walltime hangs. Replace it with a liveness watchdog that tracks the per-rank ready-to-forward gen request count (DISAGG_GENERATION_TRANS_COMPLETE + GENERATION_IN_PROGRESS); if the count does not change for >60s, log an explicit error, fail all active requests via _handle_errors, and return None to break the executor loop. The watchdog uses a local-only count so it does not introduce a collective at a point where rank participation can diverge under ADP. * trim kv cache out of window after receive kv cache * fix stall Signed-off-by: Chuang Zhu <111838961+chuangz0@users.noreply.github.com> Signed-off-by: Fanrong Li <lfr-0531@users.noreply.github.com>
lfr-0531
pushed a commit
to lfr-0531/TensorRT-LLM
that referenced
this pull request
Jun 10, 2026
Squash of three commits cherry-picked from NVIDIA#13650: * Fix gen-only benchmark for KVCacheManager V2 + improve insufficient KVCache check In gen-only benchmark mode the executor calls _check_benchmark_disagg_gate every iteration and `continue`s when the fill phase is not yet complete. Before that the scheduler has already called try_allocate_generation, which grows each gen request's KV capacity by 1 (+draft_len). Without a matching revert the capacity drifts upward across the many retried iterations until it overflows the host page-index buffer, raising ValueError: User-provided base page indices is too short from KVCacheManagerV2._KVCache.resize. Revert the spurious growth on the should_retry path in both _executor_loop and _executor_loop_overlap, gated by _scheduler_manages_kv_suspend so V1 is unaffected. The previous "Insufficient KV cache for gen-only benchmark mode" guard compared the per-rank num_fetch_requests against the global benchmark_req_queues_size threshold. Under attention DP, prompts are routed across TP ranks via the ADP router, so per-rank fetch counts saturate well below the global threshold and the guard never fires -- deadlocks become silent walltime hangs. Replace it with a liveness watchdog that tracks the per-rank ready-to-forward gen request count (DISAGG_GENERATION_TRANS_COMPLETE + GENERATION_IN_PROGRESS); if the count does not change for >60s, log an explicit error, fail all active requests via _handle_errors, and return None to break the executor loop. The watchdog uses a local-only count so it does not introduce a collective at a point where rank participation can diverge under ADP. * trim kv cache out of window after receive kv cache * fix stall Signed-off-by: Chuang Zhu <111838961+chuangz0@users.noreply.github.com> Signed-off-by: Fanrong Li <lfr-0531@users.noreply.github.com>
Shixiaowei02
pushed a commit
to Shixiaowei02/TensorRT-LLM
that referenced
this pull request
Jun 10, 2026
Squash of three commits cherry-picked from NVIDIA#13650: * Fix gen-only benchmark for KVCacheManager V2 + improve insufficient KVCache check In gen-only benchmark mode the executor calls _check_benchmark_disagg_gate every iteration and `continue`s when the fill phase is not yet complete. Before that the scheduler has already called try_allocate_generation, which grows each gen request's KV capacity by 1 (+draft_len). Without a matching revert the capacity drifts upward across the many retried iterations until it overflows the host page-index buffer, raising ValueError: User-provided base page indices is too short from KVCacheManagerV2._KVCache.resize. Revert the spurious growth on the should_retry path in both _executor_loop and _executor_loop_overlap, gated by _scheduler_manages_kv_suspend so V1 is unaffected. The previous "Insufficient KV cache for gen-only benchmark mode" guard compared the per-rank num_fetch_requests against the global benchmark_req_queues_size threshold. Under attention DP, prompts are routed across TP ranks via the ADP router, so per-rank fetch counts saturate well below the global threshold and the guard never fires -- deadlocks become silent walltime hangs. Replace it with a liveness watchdog that tracks the per-rank ready-to-forward gen request count (DISAGG_GENERATION_TRANS_COMPLETE + GENERATION_IN_PROGRESS); if the count does not change for >60s, log an explicit error, fail all active requests via _handle_errors, and return None to break the executor loop. The watchdog uses a local-only count so it does not introduce a collective at a point where rank participation can diverge under ADP. * trim kv cache out of window after receive kv cache * fix stall Signed-off-by: Chuang Zhu <111838961+chuangz0@users.noreply.github.com> Signed-off-by: Fanrong Li <lfr-0531@users.noreply.github.com>
Shixiaowei02
pushed a commit
to Shixiaowei02/TensorRT-LLM
that referenced
this pull request
Jun 10, 2026
Squash of three commits cherry-picked from NVIDIA#13650: * Fix gen-only benchmark for KVCacheManager V2 + improve insufficient KVCache check In gen-only benchmark mode the executor calls _check_benchmark_disagg_gate every iteration and `continue`s when the fill phase is not yet complete. Before that the scheduler has already called try_allocate_generation, which grows each gen request's KV capacity by 1 (+draft_len). Without a matching revert the capacity drifts upward across the many retried iterations until it overflows the host page-index buffer, raising ValueError: User-provided base page indices is too short from KVCacheManagerV2._KVCache.resize. Revert the spurious growth on the should_retry path in both _executor_loop and _executor_loop_overlap, gated by _scheduler_manages_kv_suspend so V1 is unaffected. The previous "Insufficient KV cache for gen-only benchmark mode" guard compared the per-rank num_fetch_requests against the global benchmark_req_queues_size threshold. Under attention DP, prompts are routed across TP ranks via the ADP router, so per-rank fetch counts saturate well below the global threshold and the guard never fires -- deadlocks become silent walltime hangs. Replace it with a liveness watchdog that tracks the per-rank ready-to-forward gen request count (DISAGG_GENERATION_TRANS_COMPLETE + GENERATION_IN_PROGRESS); if the count does not change for >60s, log an explicit error, fail all active requests via _handle_errors, and return None to break the executor loop. The watchdog uses a local-only count so it does not introduce a collective at a point where rank participation can diverge under ADP. * trim kv cache out of window after receive kv cache * fix stall Signed-off-by: Chuang Zhu <111838961+chuangz0@users.noreply.github.com> Signed-off-by: Fanrong Li <lfr-0531@users.noreply.github.com>
Shixiaowei02
pushed a commit
to Shixiaowei02/TensorRT-LLM
that referenced
this pull request
Jun 10, 2026
Squash of three commits cherry-picked from NVIDIA#13650: * Fix gen-only benchmark for KVCacheManager V2 + improve insufficient KVCache check In gen-only benchmark mode the executor calls _check_benchmark_disagg_gate every iteration and `continue`s when the fill phase is not yet complete. Before that the scheduler has already called try_allocate_generation, which grows each gen request's KV capacity by 1 (+draft_len). Without a matching revert the capacity drifts upward across the many retried iterations until it overflows the host page-index buffer, raising ValueError: User-provided base page indices is too short from KVCacheManagerV2._KVCache.resize. Revert the spurious growth on the should_retry path in both _executor_loop and _executor_loop_overlap, gated by _scheduler_manages_kv_suspend so V1 is unaffected. The previous "Insufficient KV cache for gen-only benchmark mode" guard compared the per-rank num_fetch_requests against the global benchmark_req_queues_size threshold. Under attention DP, prompts are routed across TP ranks via the ADP router, so per-rank fetch counts saturate well below the global threshold and the guard never fires -- deadlocks become silent walltime hangs. Replace it with a liveness watchdog that tracks the per-rank ready-to-forward gen request count (DISAGG_GENERATION_TRANS_COMPLETE + GENERATION_IN_PROGRESS); if the count does not change for >60s, log an explicit error, fail all active requests via _handle_errors, and return None to break the executor loop. The watchdog uses a local-only count so it does not introduce a collective at a point where rank participation can diverge under ADP. * trim kv cache out of window after receive kv cache * fix stall Signed-off-by: Chuang Zhu <111838961+chuangz0@users.noreply.github.com> Signed-off-by: Fanrong Li <lfr-0531@users.noreply.github.com>
Shixiaowei02
pushed a commit
to Shixiaowei02/TensorRT-LLM
that referenced
this pull request
Jun 11, 2026
Squash of three commits cherry-picked from NVIDIA#13650: * Fix gen-only benchmark for KVCacheManager V2 + improve insufficient KVCache check In gen-only benchmark mode the executor calls _check_benchmark_disagg_gate every iteration and `continue`s when the fill phase is not yet complete. Before that the scheduler has already called try_allocate_generation, which grows each gen request's KV capacity by 1 (+draft_len). Without a matching revert the capacity drifts upward across the many retried iterations until it overflows the host page-index buffer, raising ValueError: User-provided base page indices is too short from KVCacheManagerV2._KVCache.resize. Revert the spurious growth on the should_retry path in both _executor_loop and _executor_loop_overlap, gated by _scheduler_manages_kv_suspend so V1 is unaffected. The previous "Insufficient KV cache for gen-only benchmark mode" guard compared the per-rank num_fetch_requests against the global benchmark_req_queues_size threshold. Under attention DP, prompts are routed across TP ranks via the ADP router, so per-rank fetch counts saturate well below the global threshold and the guard never fires -- deadlocks become silent walltime hangs. Replace it with a liveness watchdog that tracks the per-rank ready-to-forward gen request count (DISAGG_GENERATION_TRANS_COMPLETE + GENERATION_IN_PROGRESS); if the count does not change for >60s, log an explicit error, fail all active requests via _handle_errors, and return None to break the executor loop. The watchdog uses a local-only count so it does not introduce a collective at a point where rank participation can diverge under ADP. * trim kv cache out of window after receive kv cache * fix stall Signed-off-by: Chuang Zhu <111838961+chuangz0@users.noreply.github.com> Signed-off-by: Fanrong Li <lfr-0531@users.noreply.github.com>
Shixiaowei02
pushed a commit
to Shixiaowei02/TensorRT-LLM
that referenced
this pull request
Jun 11, 2026
Squash of three commits cherry-picked from NVIDIA#13650: * Fix gen-only benchmark for KVCacheManager V2 + improve insufficient KVCache check In gen-only benchmark mode the executor calls _check_benchmark_disagg_gate every iteration and `continue`s when the fill phase is not yet complete. Before that the scheduler has already called try_allocate_generation, which grows each gen request's KV capacity by 1 (+draft_len). Without a matching revert the capacity drifts upward across the many retried iterations until it overflows the host page-index buffer, raising ValueError: User-provided base page indices is too short from KVCacheManagerV2._KVCache.resize. Revert the spurious growth on the should_retry path in both _executor_loop and _executor_loop_overlap, gated by _scheduler_manages_kv_suspend so V1 is unaffected. The previous "Insufficient KV cache for gen-only benchmark mode" guard compared the per-rank num_fetch_requests against the global benchmark_req_queues_size threshold. Under attention DP, prompts are routed across TP ranks via the ADP router, so per-rank fetch counts saturate well below the global threshold and the guard never fires -- deadlocks become silent walltime hangs. Replace it with a liveness watchdog that tracks the per-rank ready-to-forward gen request count (DISAGG_GENERATION_TRANS_COMPLETE + GENERATION_IN_PROGRESS); if the count does not change for >60s, log an explicit error, fail all active requests via _handle_errors, and return None to break the executor loop. The watchdog uses a local-only count so it does not introduce a collective at a point where rank participation can diverge under ADP. * trim kv cache out of window after receive kv cache * fix stall Signed-off-by: Chuang Zhu <111838961+chuangz0@users.noreply.github.com> Signed-off-by: Fanrong Li <lfr-0531@users.noreply.github.com>
Shixiaowei02
pushed a commit
to Shixiaowei02/TensorRT-LLM
that referenced
this pull request
Jun 11, 2026
Squash of three commits cherry-picked from NVIDIA#13650: * Fix gen-only benchmark for KVCacheManager V2 + improve insufficient KVCache check In gen-only benchmark mode the executor calls _check_benchmark_disagg_gate every iteration and `continue`s when the fill phase is not yet complete. Before that the scheduler has already called try_allocate_generation, which grows each gen request's KV capacity by 1 (+draft_len). Without a matching revert the capacity drifts upward across the many retried iterations until it overflows the host page-index buffer, raising ValueError: User-provided base page indices is too short from KVCacheManagerV2._KVCache.resize. Revert the spurious growth on the should_retry path in both _executor_loop and _executor_loop_overlap, gated by _scheduler_manages_kv_suspend so V1 is unaffected. The previous "Insufficient KV cache for gen-only benchmark mode" guard compared the per-rank num_fetch_requests against the global benchmark_req_queues_size threshold. Under attention DP, prompts are routed across TP ranks via the ADP router, so per-rank fetch counts saturate well below the global threshold and the guard never fires -- deadlocks become silent walltime hangs. Replace it with a liveness watchdog that tracks the per-rank ready-to-forward gen request count (DISAGG_GENERATION_TRANS_COMPLETE + GENERATION_IN_PROGRESS); if the count does not change for >60s, log an explicit error, fail all active requests via _handle_errors, and return None to break the executor loop. The watchdog uses a local-only count so it does not introduce a collective at a point where rank participation can diverge under ADP. * trim kv cache out of window after receive kv cache * fix stall Signed-off-by: Chuang Zhu <111838961+chuangz0@users.noreply.github.com> Signed-off-by: Fanrong Li <lfr-0531@users.noreply.github.com>
Shixiaowei02
pushed a commit
to Shixiaowei02/TensorRT-LLM
that referenced
this pull request
Jun 11, 2026
Squash of three commits cherry-picked from NVIDIA#13650: * Fix gen-only benchmark for KVCacheManager V2 + improve insufficient KVCache check In gen-only benchmark mode the executor calls _check_benchmark_disagg_gate every iteration and `continue`s when the fill phase is not yet complete. Before that the scheduler has already called try_allocate_generation, which grows each gen request's KV capacity by 1 (+draft_len). Without a matching revert the capacity drifts upward across the many retried iterations until it overflows the host page-index buffer, raising ValueError: User-provided base page indices is too short from KVCacheManagerV2._KVCache.resize. Revert the spurious growth on the should_retry path in both _executor_loop and _executor_loop_overlap, gated by _scheduler_manages_kv_suspend so V1 is unaffected. The previous "Insufficient KV cache for gen-only benchmark mode" guard compared the per-rank num_fetch_requests against the global benchmark_req_queues_size threshold. Under attention DP, prompts are routed across TP ranks via the ADP router, so per-rank fetch counts saturate well below the global threshold and the guard never fires -- deadlocks become silent walltime hangs. Replace it with a liveness watchdog that tracks the per-rank ready-to-forward gen request count (DISAGG_GENERATION_TRANS_COMPLETE + GENERATION_IN_PROGRESS); if the count does not change for >60s, log an explicit error, fail all active requests via _handle_errors, and return None to break the executor loop. The watchdog uses a local-only count so it does not introduce a collective at a point where rank participation can diverge under ADP. * trim kv cache out of window after receive kv cache * fix stall Signed-off-by: Chuang Zhu <111838961+chuangz0@users.noreply.github.com> Signed-off-by: Fanrong Li <lfr-0531@users.noreply.github.com>
lfr-0531
pushed a commit
to lfr-0531/TensorRT-LLM
that referenced
this pull request
Jun 11, 2026
Squash of three commits cherry-picked from NVIDIA#13650: * Fix gen-only benchmark for KVCacheManager V2 + improve insufficient KVCache check In gen-only benchmark mode the executor calls _check_benchmark_disagg_gate every iteration and `continue`s when the fill phase is not yet complete. Before that the scheduler has already called try_allocate_generation, which grows each gen request's KV capacity by 1 (+draft_len). Without a matching revert the capacity drifts upward across the many retried iterations until it overflows the host page-index buffer, raising ValueError: User-provided base page indices is too short from KVCacheManagerV2._KVCache.resize. Revert the spurious growth on the should_retry path in both _executor_loop and _executor_loop_overlap, gated by _scheduler_manages_kv_suspend so V1 is unaffected. The previous "Insufficient KV cache for gen-only benchmark mode" guard compared the per-rank num_fetch_requests against the global benchmark_req_queues_size threshold. Under attention DP, prompts are routed across TP ranks via the ADP router, so per-rank fetch counts saturate well below the global threshold and the guard never fires -- deadlocks become silent walltime hangs. Replace it with a liveness watchdog that tracks the per-rank ready-to-forward gen request count (DISAGG_GENERATION_TRANS_COMPLETE + GENERATION_IN_PROGRESS); if the count does not change for >60s, log an explicit error, fail all active requests via _handle_errors, and return None to break the executor loop. The watchdog uses a local-only count so it does not introduce a collective at a point where rank participation can diverge under ADP. * trim kv cache out of window after receive kv cache * fix stall Signed-off-by: Chuang Zhu <111838961+chuangz0@users.noreply.github.com> Signed-off-by: Fanrong Li <lfr-0531@users.noreply.github.com>
Shixiaowei02
pushed a commit
to Shixiaowei02/TensorRT-LLM
that referenced
this pull request
Jun 12, 2026
Squash of three commits cherry-picked from NVIDIA#13650: * Fix gen-only benchmark for KVCacheManager V2 + improve insufficient KVCache check In gen-only benchmark mode the executor calls _check_benchmark_disagg_gate every iteration and `continue`s when the fill phase is not yet complete. Before that the scheduler has already called try_allocate_generation, which grows each gen request's KV capacity by 1 (+draft_len). Without a matching revert the capacity drifts upward across the many retried iterations until it overflows the host page-index buffer, raising ValueError: User-provided base page indices is too short from KVCacheManagerV2._KVCache.resize. Revert the spurious growth on the should_retry path in both _executor_loop and _executor_loop_overlap, gated by _scheduler_manages_kv_suspend so V1 is unaffected. The previous "Insufficient KV cache for gen-only benchmark mode" guard compared the per-rank num_fetch_requests against the global benchmark_req_queues_size threshold. Under attention DP, prompts are routed across TP ranks via the ADP router, so per-rank fetch counts saturate well below the global threshold and the guard never fires -- deadlocks become silent walltime hangs. Replace it with a liveness watchdog that tracks the per-rank ready-to-forward gen request count (DISAGG_GENERATION_TRANS_COMPLETE + GENERATION_IN_PROGRESS); if the count does not change for >60s, log an explicit error, fail all active requests via _handle_errors, and return None to break the executor loop. The watchdog uses a local-only count so it does not introduce a collective at a point where rank participation can diverge under ADP. * trim kv cache out of window after receive kv cache * fix stall Signed-off-by: Chuang Zhu <111838961+chuangz0@users.noreply.github.com> Signed-off-by: Fanrong Li <lfr-0531@users.noreply.github.com>
lfr-0531
pushed a commit
to lfr-0531/TensorRT-LLM
that referenced
this pull request
Jun 12, 2026
Squash of three commits cherry-picked from NVIDIA#13650: * Fix gen-only benchmark for KVCacheManager V2 + improve insufficient KVCache check In gen-only benchmark mode the executor calls _check_benchmark_disagg_gate every iteration and `continue`s when the fill phase is not yet complete. Before that the scheduler has already called try_allocate_generation, which grows each gen request's KV capacity by 1 (+draft_len). Without a matching revert the capacity drifts upward across the many retried iterations until it overflows the host page-index buffer, raising ValueError: User-provided base page indices is too short from KVCacheManagerV2._KVCache.resize. Revert the spurious growth on the should_retry path in both _executor_loop and _executor_loop_overlap, gated by _scheduler_manages_kv_suspend so V1 is unaffected. The previous "Insufficient KV cache for gen-only benchmark mode" guard compared the per-rank num_fetch_requests against the global benchmark_req_queues_size threshold. Under attention DP, prompts are routed across TP ranks via the ADP router, so per-rank fetch counts saturate well below the global threshold and the guard never fires -- deadlocks become silent walltime hangs. Replace it with a liveness watchdog that tracks the per-rank ready-to-forward gen request count (DISAGG_GENERATION_TRANS_COMPLETE + GENERATION_IN_PROGRESS); if the count does not change for >60s, log an explicit error, fail all active requests via _handle_errors, and return None to break the executor loop. The watchdog uses a local-only count so it does not introduce a collective at a point where rank participation can diverge under ADP. * trim kv cache out of window after receive kv cache * fix stall Signed-off-by: Chuang Zhu <111838961+chuangz0@users.noreply.github.com> Signed-off-by: Fanrong Li <lfr-0531@users.noreply.github.com>
Shixiaowei02
pushed a commit
to Shixiaowei02/TensorRT-LLM
that referenced
this pull request
Jun 12, 2026
Squash of three commits cherry-picked from NVIDIA#13650: * Fix gen-only benchmark for KVCacheManager V2 + improve insufficient KVCache check In gen-only benchmark mode the executor calls _check_benchmark_disagg_gate every iteration and `continue`s when the fill phase is not yet complete. Before that the scheduler has already called try_allocate_generation, which grows each gen request's KV capacity by 1 (+draft_len). Without a matching revert the capacity drifts upward across the many retried iterations until it overflows the host page-index buffer, raising ValueError: User-provided base page indices is too short from KVCacheManagerV2._KVCache.resize. Revert the spurious growth on the should_retry path in both _executor_loop and _executor_loop_overlap, gated by _scheduler_manages_kv_suspend so V1 is unaffected. The previous "Insufficient KV cache for gen-only benchmark mode" guard compared the per-rank num_fetch_requests against the global benchmark_req_queues_size threshold. Under attention DP, prompts are routed across TP ranks via the ADP router, so per-rank fetch counts saturate well below the global threshold and the guard never fires -- deadlocks become silent walltime hangs. Replace it with a liveness watchdog that tracks the per-rank ready-to-forward gen request count (DISAGG_GENERATION_TRANS_COMPLETE + GENERATION_IN_PROGRESS); if the count does not change for >60s, log an explicit error, fail all active requests via _handle_errors, and return None to break the executor loop. The watchdog uses a local-only count so it does not introduce a collective at a point where rank participation can diverge under ADP. * trim kv cache out of window after receive kv cache * fix stall Signed-off-by: Chuang Zhu <111838961+chuangz0@users.noreply.github.com> Signed-off-by: Fanrong Li <lfr-0531@users.noreply.github.com>
Shixiaowei02
pushed a commit
to Shixiaowei02/TensorRT-LLM
that referenced
this pull request
Jun 14, 2026
Squash of three commits cherry-picked from NVIDIA#13650: * Fix gen-only benchmark for KVCacheManager V2 + improve insufficient KVCache check In gen-only benchmark mode the executor calls _check_benchmark_disagg_gate every iteration and `continue`s when the fill phase is not yet complete. Before that the scheduler has already called try_allocate_generation, which grows each gen request's KV capacity by 1 (+draft_len). Without a matching revert the capacity drifts upward across the many retried iterations until it overflows the host page-index buffer, raising ValueError: User-provided base page indices is too short from KVCacheManagerV2._KVCache.resize. Revert the spurious growth on the should_retry path in both _executor_loop and _executor_loop_overlap, gated by _scheduler_manages_kv_suspend so V1 is unaffected. The previous "Insufficient KV cache for gen-only benchmark mode" guard compared the per-rank num_fetch_requests against the global benchmark_req_queues_size threshold. Under attention DP, prompts are routed across TP ranks via the ADP router, so per-rank fetch counts saturate well below the global threshold and the guard never fires -- deadlocks become silent walltime hangs. Replace it with a liveness watchdog that tracks the per-rank ready-to-forward gen request count (DISAGG_GENERATION_TRANS_COMPLETE + GENERATION_IN_PROGRESS); if the count does not change for >60s, log an explicit error, fail all active requests via _handle_errors, and return None to break the executor loop. The watchdog uses a local-only count so it does not introduce a collective at a point where rank participation can diverge under ADP. * trim kv cache out of window after receive kv cache * fix stall Signed-off-by: Chuang Zhu <111838961+chuangz0@users.noreply.github.com> Signed-off-by: Fanrong Li <lfr-0531@users.noreply.github.com>
Shixiaowei02
pushed a commit
to Shixiaowei02/TensorRT-LLM
that referenced
this pull request
Jun 16, 2026
Squash of three commits cherry-picked from NVIDIA#13650: * Fix gen-only benchmark for KVCacheManager V2 + improve insufficient KVCache check In gen-only benchmark mode the executor calls _check_benchmark_disagg_gate every iteration and `continue`s when the fill phase is not yet complete. Before that the scheduler has already called try_allocate_generation, which grows each gen request's KV capacity by 1 (+draft_len). Without a matching revert the capacity drifts upward across the many retried iterations until it overflows the host page-index buffer, raising ValueError: User-provided base page indices is too short from KVCacheManagerV2._KVCache.resize. Revert the spurious growth on the should_retry path in both _executor_loop and _executor_loop_overlap, gated by _scheduler_manages_kv_suspend so V1 is unaffected. The previous "Insufficient KV cache for gen-only benchmark mode" guard compared the per-rank num_fetch_requests against the global benchmark_req_queues_size threshold. Under attention DP, prompts are routed across TP ranks via the ADP router, so per-rank fetch counts saturate well below the global threshold and the guard never fires -- deadlocks become silent walltime hangs. Replace it with a liveness watchdog that tracks the per-rank ready-to-forward gen request count (DISAGG_GENERATION_TRANS_COMPLETE + GENERATION_IN_PROGRESS); if the count does not change for >60s, log an explicit error, fail all active requests via _handle_errors, and return None to break the executor loop. The watchdog uses a local-only count so it does not introduce a collective at a point where rank participation can diverge under ADP. * trim kv cache out of window after receive kv cache * fix stall Signed-off-by: Chuang Zhu <111838961+chuangz0@users.noreply.github.com> Signed-off-by: Fanrong Li <lfr-0531@users.noreply.github.com>
Shixiaowei02
pushed a commit
to Shixiaowei02/TensorRT-LLM
that referenced
this pull request
Jun 17, 2026
Squash of three commits cherry-picked from NVIDIA#13650: * Fix gen-only benchmark for KVCacheManager V2 + improve insufficient KVCache check In gen-only benchmark mode the executor calls _check_benchmark_disagg_gate every iteration and `continue`s when the fill phase is not yet complete. Before that the scheduler has already called try_allocate_generation, which grows each gen request's KV capacity by 1 (+draft_len). Without a matching revert the capacity drifts upward across the many retried iterations until it overflows the host page-index buffer, raising ValueError: User-provided base page indices is too short from KVCacheManagerV2._KVCache.resize. Revert the spurious growth on the should_retry path in both _executor_loop and _executor_loop_overlap, gated by _scheduler_manages_kv_suspend so V1 is unaffected. The previous "Insufficient KV cache for gen-only benchmark mode" guard compared the per-rank num_fetch_requests against the global benchmark_req_queues_size threshold. Under attention DP, prompts are routed across TP ranks via the ADP router, so per-rank fetch counts saturate well below the global threshold and the guard never fires -- deadlocks become silent walltime hangs. Replace it with a liveness watchdog that tracks the per-rank ready-to-forward gen request count (DISAGG_GENERATION_TRANS_COMPLETE + GENERATION_IN_PROGRESS); if the count does not change for >60s, log an explicit error, fail all active requests via _handle_errors, and return None to break the executor loop. The watchdog uses a local-only count so it does not introduce a collective at a point where rank participation can diverge under ADP. * trim kv cache out of window after receive kv cache * fix stall Signed-off-by: Chuang Zhu <111838961+chuangz0@users.noreply.github.com> Signed-off-by: Fanrong Li <lfr-0531@users.noreply.github.com>
Shixiaowei02
pushed a commit
to Shixiaowei02/TensorRT-LLM
that referenced
this pull request
Jun 21, 2026
Squash of three commits cherry-picked from NVIDIA#13650: * Fix gen-only benchmark for KVCacheManager V2 + improve insufficient KVCache check In gen-only benchmark mode the executor calls _check_benchmark_disagg_gate every iteration and `continue`s when the fill phase is not yet complete. Before that the scheduler has already called try_allocate_generation, which grows each gen request's KV capacity by 1 (+draft_len). Without a matching revert the capacity drifts upward across the many retried iterations until it overflows the host page-index buffer, raising ValueError: User-provided base page indices is too short from KVCacheManagerV2._KVCache.resize. Revert the spurious growth on the should_retry path in both _executor_loop and _executor_loop_overlap, gated by _scheduler_manages_kv_suspend so V1 is unaffected. The previous "Insufficient KV cache for gen-only benchmark mode" guard compared the per-rank num_fetch_requests against the global benchmark_req_queues_size threshold. Under attention DP, prompts are routed across TP ranks via the ADP router, so per-rank fetch counts saturate well below the global threshold and the guard never fires -- deadlocks become silent walltime hangs. Replace it with a liveness watchdog that tracks the per-rank ready-to-forward gen request count (DISAGG_GENERATION_TRANS_COMPLETE + GENERATION_IN_PROGRESS); if the count does not change for >60s, log an explicit error, fail all active requests via _handle_errors, and return None to break the executor loop. The watchdog uses a local-only count so it does not introduce a collective at a point where rank participation can diverge under ADP. * trim kv cache out of window after receive kv cache * fix stall Signed-off-by: Chuang Zhu <111838961+chuangz0@users.noreply.github.com> Signed-off-by: Fanrong Li <lfr-0531@users.noreply.github.com>
Shixiaowei02
pushed a commit
to Shixiaowei02/TensorRT-LLM
that referenced
this pull request
Jun 22, 2026
Squash of three commits cherry-picked from NVIDIA#13650: * Fix gen-only benchmark for KVCacheManager V2 + improve insufficient KVCache check In gen-only benchmark mode the executor calls _check_benchmark_disagg_gate every iteration and `continue`s when the fill phase is not yet complete. Before that the scheduler has already called try_allocate_generation, which grows each gen request's KV capacity by 1 (+draft_len). Without a matching revert the capacity drifts upward across the many retried iterations until it overflows the host page-index buffer, raising ValueError: User-provided base page indices is too short from KVCacheManagerV2._KVCache.resize. Revert the spurious growth on the should_retry path in both _executor_loop and _executor_loop_overlap, gated by _scheduler_manages_kv_suspend so V1 is unaffected. The previous "Insufficient KV cache for gen-only benchmark mode" guard compared the per-rank num_fetch_requests against the global benchmark_req_queues_size threshold. Under attention DP, prompts are routed across TP ranks via the ADP router, so per-rank fetch counts saturate well below the global threshold and the guard never fires -- deadlocks become silent walltime hangs. Replace it with a liveness watchdog that tracks the per-rank ready-to-forward gen request count (DISAGG_GENERATION_TRANS_COMPLETE + GENERATION_IN_PROGRESS); if the count does not change for >60s, log an explicit error, fail all active requests via _handle_errors, and return None to break the executor loop. The watchdog uses a local-only count so it does not introduce a collective at a point where rank participation can diverge under ADP. * trim kv cache out of window after receive kv cache * fix stall Signed-off-by: Chuang Zhu <111838961+chuangz0@users.noreply.github.com> Signed-off-by: Fanrong Li <lfr-0531@users.noreply.github.com>
Shixiaowei02
pushed a commit
to Shixiaowei02/TensorRT-LLM
that referenced
this pull request
Jun 23, 2026
Squash of three commits cherry-picked from NVIDIA#13650: * Fix gen-only benchmark for KVCacheManager V2 + improve insufficient KVCache check In gen-only benchmark mode the executor calls _check_benchmark_disagg_gate every iteration and `continue`s when the fill phase is not yet complete. Before that the scheduler has already called try_allocate_generation, which grows each gen request's KV capacity by 1 (+draft_len). Without a matching revert the capacity drifts upward across the many retried iterations until it overflows the host page-index buffer, raising ValueError: User-provided base page indices is too short from KVCacheManagerV2._KVCache.resize. Revert the spurious growth on the should_retry path in both _executor_loop and _executor_loop_overlap, gated by _scheduler_manages_kv_suspend so V1 is unaffected. The previous "Insufficient KV cache for gen-only benchmark mode" guard compared the per-rank num_fetch_requests against the global benchmark_req_queues_size threshold. Under attention DP, prompts are routed across TP ranks via the ADP router, so per-rank fetch counts saturate well below the global threshold and the guard never fires -- deadlocks become silent walltime hangs. Replace it with a liveness watchdog that tracks the per-rank ready-to-forward gen request count (DISAGG_GENERATION_TRANS_COMPLETE + GENERATION_IN_PROGRESS); if the count does not change for >60s, log an explicit error, fail all active requests via _handle_errors, and return None to break the executor loop. The watchdog uses a local-only count so it does not introduce a collective at a point where rank participation can diverge under ADP. * trim kv cache out of window after receive kv cache * fix stall Signed-off-by: Chuang Zhu <111838961+chuangz0@users.noreply.github.com> Signed-off-by: Fanrong Li <lfr-0531@users.noreply.github.com>
Shixiaowei02
pushed a commit
to Shixiaowei02/TensorRT-LLM
that referenced
this pull request
Jun 23, 2026
Squash of three commits cherry-picked from NVIDIA#13650: * Fix gen-only benchmark for KVCacheManager V2 + improve insufficient KVCache check In gen-only benchmark mode the executor calls _check_benchmark_disagg_gate every iteration and `continue`s when the fill phase is not yet complete. Before that the scheduler has already called try_allocate_generation, which grows each gen request's KV capacity by 1 (+draft_len). Without a matching revert the capacity drifts upward across the many retried iterations until it overflows the host page-index buffer, raising ValueError: User-provided base page indices is too short from KVCacheManagerV2._KVCache.resize. Revert the spurious growth on the should_retry path in both _executor_loop and _executor_loop_overlap, gated by _scheduler_manages_kv_suspend so V1 is unaffected. The previous "Insufficient KV cache for gen-only benchmark mode" guard compared the per-rank num_fetch_requests against the global benchmark_req_queues_size threshold. Under attention DP, prompts are routed across TP ranks via the ADP router, so per-rank fetch counts saturate well below the global threshold and the guard never fires -- deadlocks become silent walltime hangs. Replace it with a liveness watchdog that tracks the per-rank ready-to-forward gen request count (DISAGG_GENERATION_TRANS_COMPLETE + GENERATION_IN_PROGRESS); if the count does not change for >60s, log an explicit error, fail all active requests via _handle_errors, and return None to break the executor loop. The watchdog uses a local-only count so it does not introduce a collective at a point where rank participation can diverge under ADP. * trim kv cache out of window after receive kv cache * fix stall Signed-off-by: Chuang Zhu <111838961+chuangz0@users.noreply.github.com> Signed-off-by: Fanrong Li <lfr-0531@users.noreply.github.com>
Shixiaowei02
pushed a commit
to Shixiaowei02/TensorRT-LLM
that referenced
this pull request
Jun 23, 2026
Squash of three commits cherry-picked from NVIDIA#13650: * Fix gen-only benchmark for KVCacheManager V2 + improve insufficient KVCache check In gen-only benchmark mode the executor calls _check_benchmark_disagg_gate every iteration and `continue`s when the fill phase is not yet complete. Before that the scheduler has already called try_allocate_generation, which grows each gen request's KV capacity by 1 (+draft_len). Without a matching revert the capacity drifts upward across the many retried iterations until it overflows the host page-index buffer, raising ValueError: User-provided base page indices is too short from KVCacheManagerV2._KVCache.resize. Revert the spurious growth on the should_retry path in both _executor_loop and _executor_loop_overlap, gated by _scheduler_manages_kv_suspend so V1 is unaffected. The previous "Insufficient KV cache for gen-only benchmark mode" guard compared the per-rank num_fetch_requests against the global benchmark_req_queues_size threshold. Under attention DP, prompts are routed across TP ranks via the ADP router, so per-rank fetch counts saturate well below the global threshold and the guard never fires -- deadlocks become silent walltime hangs. Replace it with a liveness watchdog that tracks the per-rank ready-to-forward gen request count (DISAGG_GENERATION_TRANS_COMPLETE + GENERATION_IN_PROGRESS); if the count does not change for >60s, log an explicit error, fail all active requests via _handle_errors, and return None to break the executor loop. The watchdog uses a local-only count so it does not introduce a collective at a point where rank participation can diverge under ADP. * trim kv cache out of window after receive kv cache * fix stall Signed-off-by: Chuang Zhu <111838961+chuangz0@users.noreply.github.com> Signed-off-by: Fanrong Li <lfr-0531@users.noreply.github.com>
Shixiaowei02
pushed a commit
to Shixiaowei02/TensorRT-LLM
that referenced
this pull request
Jun 24, 2026
Squash of three commits cherry-picked from NVIDIA#13650: * Fix gen-only benchmark for KVCacheManager V2 + improve insufficient KVCache check In gen-only benchmark mode the executor calls _check_benchmark_disagg_gate every iteration and `continue`s when the fill phase is not yet complete. Before that the scheduler has already called try_allocate_generation, which grows each gen request's KV capacity by 1 (+draft_len). Without a matching revert the capacity drifts upward across the many retried iterations until it overflows the host page-index buffer, raising ValueError: User-provided base page indices is too short from KVCacheManagerV2._KVCache.resize. Revert the spurious growth on the should_retry path in both _executor_loop and _executor_loop_overlap, gated by _scheduler_manages_kv_suspend so V1 is unaffected. The previous "Insufficient KV cache for gen-only benchmark mode" guard compared the per-rank num_fetch_requests against the global benchmark_req_queues_size threshold. Under attention DP, prompts are routed across TP ranks via the ADP router, so per-rank fetch counts saturate well below the global threshold and the guard never fires -- deadlocks become silent walltime hangs. Replace it with a liveness watchdog that tracks the per-rank ready-to-forward gen request count (DISAGG_GENERATION_TRANS_COMPLETE + GENERATION_IN_PROGRESS); if the count does not change for >60s, log an explicit error, fail all active requests via _handle_errors, and return None to break the executor loop. The watchdog uses a local-only count so it does not introduce a collective at a point where rank participation can diverge under ADP. * trim kv cache out of window after receive kv cache * fix stall Signed-off-by: Chuang Zhu <111838961+chuangz0@users.noreply.github.com> Signed-off-by: Fanrong Li <lfr-0531@users.noreply.github.com>
Shixiaowei02
pushed a commit
to Shixiaowei02/TensorRT-LLM
that referenced
this pull request
Jun 24, 2026
Squash of three commits cherry-picked from NVIDIA#13650: * Fix gen-only benchmark for KVCacheManager V2 + improve insufficient KVCache check In gen-only benchmark mode the executor calls _check_benchmark_disagg_gate every iteration and `continue`s when the fill phase is not yet complete. Before that the scheduler has already called try_allocate_generation, which grows each gen request's KV capacity by 1 (+draft_len). Without a matching revert the capacity drifts upward across the many retried iterations until it overflows the host page-index buffer, raising ValueError: User-provided base page indices is too short from KVCacheManagerV2._KVCache.resize. Revert the spurious growth on the should_retry path in both _executor_loop and _executor_loop_overlap, gated by _scheduler_manages_kv_suspend so V1 is unaffected. The previous "Insufficient KV cache for gen-only benchmark mode" guard compared the per-rank num_fetch_requests against the global benchmark_req_queues_size threshold. Under attention DP, prompts are routed across TP ranks via the ADP router, so per-rank fetch counts saturate well below the global threshold and the guard never fires -- deadlocks become silent walltime hangs. Replace it with a liveness watchdog that tracks the per-rank ready-to-forward gen request count (DISAGG_GENERATION_TRANS_COMPLETE + GENERATION_IN_PROGRESS); if the count does not change for >60s, log an explicit error, fail all active requests via _handle_errors, and return None to break the executor loop. The watchdog uses a local-only count so it does not introduce a collective at a point where rank participation can diverge under ADP. * trim kv cache out of window after receive kv cache * fix stall Signed-off-by: Chuang Zhu <111838961+chuangz0@users.noreply.github.com> Signed-off-by: Fanrong Li <lfr-0531@users.noreply.github.com>
Shixiaowei02
pushed a commit
to Shixiaowei02/TensorRT-LLM
that referenced
this pull request
Jun 24, 2026
Squash of three commits cherry-picked from NVIDIA#13650: * Fix gen-only benchmark for KVCacheManager V2 + improve insufficient KVCache check In gen-only benchmark mode the executor calls _check_benchmark_disagg_gate every iteration and `continue`s when the fill phase is not yet complete. Before that the scheduler has already called try_allocate_generation, which grows each gen request's KV capacity by 1 (+draft_len). Without a matching revert the capacity drifts upward across the many retried iterations until it overflows the host page-index buffer, raising ValueError: User-provided base page indices is too short from KVCacheManagerV2._KVCache.resize. Revert the spurious growth on the should_retry path in both _executor_loop and _executor_loop_overlap, gated by _scheduler_manages_kv_suspend so V1 is unaffected. The previous "Insufficient KV cache for gen-only benchmark mode" guard compared the per-rank num_fetch_requests against the global benchmark_req_queues_size threshold. Under attention DP, prompts are routed across TP ranks via the ADP router, so per-rank fetch counts saturate well below the global threshold and the guard never fires -- deadlocks become silent walltime hangs. Replace it with a liveness watchdog that tracks the per-rank ready-to-forward gen request count (DISAGG_GENERATION_TRANS_COMPLETE + GENERATION_IN_PROGRESS); if the count does not change for >60s, log an explicit error, fail all active requests via _handle_errors, and return None to break the executor loop. The watchdog uses a local-only count so it does not introduce a collective at a point where rank participation can diverge under ADP. * trim kv cache out of window after receive kv cache * fix stall Signed-off-by: Chuang Zhu <111838961+chuangz0@users.noreply.github.com> Signed-off-by: Fanrong Li <lfr-0531@users.noreply.github.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
@coderabbitai summary
Description
Test Coverage
PR Checklist
Please review the following before submitting your PR:
PR description clearly explains what and why. If using CodeRabbit's summary, please make sure it makes sense.
PR Follows TRT-LLM CODING GUIDELINES to the best of your knowledge.
Test cases are provided for new code paths (see test instructions)
Any new dependencies have been scanned for license and vulnerabilities
CODEOWNERS updated if ownership changes
Documentation updated as needed
Update tava architecture diagram if there is a significant design change in PR.
The reviewers assigned automatically/manually are appropriate for the PR.
Please check this after reviewing the above items as appropriate for this PR.
GitHub Bot Help
To see a list of available CI bot commands, please comment
/bot help.