Skip to content

fix: allocate dspark target-verify buffers eagerly to avoid inference-tensor conflict - #30759

Closed
exyexin wants to merge 3 commits into
sgl-project:sglang-dsparkfrom
exyexin:fix-dspark-inference-tensor-buffer
Closed

exyexin wants to merge 3 commits into
sgl-project:sglang-dsparkfrom
exyexin:fix-dspark-inference-tensor-buffer

Conversation

@exyexin

@exyexin exyexin commented Jul 10, 2026

Copy link
Copy Markdown

Motivation

DSPARK target-verify buffers (extend_seq_lens_buffer, extend_start_loc_buffer)
were lazy-allocated by _ensure_verify_bs_buffers() on first use. The first use
is the FlashInfer autotune _dummy_run, which wraps the forward inside
torch.inference_mode(). Tensors allocated there are tagged as inference
tensors, and subsequent CUDA-graph capture (outside inference_mode) fails with:

Inplace update to inference tensor outside InferenceMode is not allowed.

Modifications

  • Allocate both buffers eagerly in DeepseekV4AttnBackend.__init__ (runs
    outside inference_mode).
  • Remove the now-unnecessary _ensure_verify_bs_buffers lazy-init method.

Checklist

  • pre-commit run --all-files
  • Unit tests — N/A (pure bugfix, no behavioral change)
  • Documentation — N/A
  • Accuracy / Speed — N/A (no model output or performance impact)

CI States

Latest PR Test (Base): ❌ Run #29077340808
Latest PR Test (Extra): ❌ Run #29077340909

@gemini-code-assist gemini-code-assist Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

This pull request refactors the allocation of extend_seq_lens_buffer and extend_start_loc_buffer in deepseek_v4_backend.py by moving it from a lazy-initialization helper directly into the __init__ method to avoid issues with in-place updates during CUDA-graph capture. The reviewer pointed out that this unconditional allocation will cause a startup crash when speculative decoding is disabled because self.speculative_num_draft_tokens is None. A guard condition was suggested to resolve this issue.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

Comment on lines +658 to +664
num_reqs = self.req_to_token.shape[0]
self.extend_seq_lens_buffer = torch.full(
(num_reqs,),
self.speculative_num_draft_tokens,
**self.cuda_int32_kwargs,
)
self.extend_start_loc_buffer = torch.zeros(num_reqs, **self.cuda_int32_kwargs)

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

critical

Unconditional allocation of extend_seq_lens_buffer and extend_start_loc_buffer in __init__ will crash SGLang startup for DeepSeek V4 models when speculative decoding is not enabled. This is because self.speculative_num_draft_tokens is None in non-speculative mode, causing torch.full to raise a TypeError (as fill_value cannot be None).

Please guard this allocation with if self.speculative_num_draft_tokens: to ensure it only runs when speculative decoding is active.

Suggested change
num_reqs = self.req_to_token.shape[0]
self.extend_seq_lens_buffer = torch.full(
(num_reqs,),
self.speculative_num_draft_tokens,
**self.cuda_int32_kwargs,
)
self.extend_start_loc_buffer = torch.zeros(num_reqs, **self.cuda_int32_kwargs)
if self.speculative_num_draft_tokens:
num_reqs = self.req_to_token.shape[0]
self.extend_seq_lens_buffer = torch.full(
(num_reqs,),
self.speculative_num_draft_tokens,
**self.cuda_int32_kwargs,
)
self.extend_start_loc_buffer = torch.zeros(num_reqs, **self.cuda_int32_kwargs)

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
@exyexin

exyexin commented Jul 10, 2026

Copy link
Copy Markdown
Author

/tag-and-rerun-ci

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants