Skip to content

[Bugfix] Skip CUDA-graph padded positions in eagle draft step kernel - #43682

Closed
kshitij2605 wants to merge 1 commit into
vllm-project:mainfrom
kshitij2605:fix/spec-decode-padded-seq-lens-oob
Closed

kshitij2605 wants to merge 1 commit into
vllm-project:mainfrom
kshitij2605:fix/spec-decode-padded-seq-lens-oob

Conversation

@kshitij2605

Copy link
Copy Markdown

Summary

Fixes cudaErrorIllegalAddress / CUDA illegal memory access crash during speculative decoding (Eagle, Eagle3, MTP) under concurrent load with CUDA graphs enabled.

Root cause: eagle_step_slot_mapping_metadata_kernel increments seq_lens for all positions in the batch, including CUDA-graph padded positions. Padded positions have seq_lens == 0 and block_table entries filled with -1. When their seq_lens is incremented from 0 to 1, the attention kernel reads block_table[-1], triggering an out-of-bounds GPU memory access that kills the engine.

Fix: Check seq_lens at the start of the kernel. If seq_len == 0 (indicating a CUDA-graph padded position), write PADDING_SLOT_ID for slot_mapping, zero for clamped_positions, and return early — leaving seq_lens at 0 so the attention kernel correctly skips these positions.

This is a one-line-logic fix in the Triton kernel with no API changes.

Reproduction

The crash requires:

  1. Speculative decoding enabled (Eagle, Eagle3, or MTP)
  2. CUDA graphs enabled (the default, not --enforce-eager)
  3. Batch size that does not exactly match a CUDA graph capture size (creates padded positions)
  4. Multiple concurrent requests (triggers the padding)

Typical error:

torch.AcceleratorError: CUDA error: an illegal memory access was encountered

Related issues: #39295, #40756

Test plan

  • Verify existing spec decode tests pass (pytest tests/v1/spec_decode/)
  • Run concurrent load test with Eagle3/MTP + async scheduling to confirm the crash no longer occurs
  • Verify no regression in speculative decoding throughput (the early return only affects padded positions)

During speculative decoding draft iterations, the
eagle_step_slot_mapping_metadata_kernel increments seq_lens for all
positions in the batch. CUDA-graph padded positions (beyond the actual
request count) have seq_lens == 0 and block_table entries filled with
-1. Incrementing their seq_lens from 0 to 1 causes the attention
kernel to index into block_table with the -1 entry, triggering a
cudaErrorIllegalAddress / illegal memory access.

The fix checks seq_lens before incrementing: if seq_len == 0, the
position is treated as padding (PADDING_SLOT_ID for slot_mapping, 0
for clamped_positions) and seq_lens is left at 0.

This manifests under concurrent load with async scheduling enabled,
when CUDA-graph batch padding creates positions that the original
kernel would incorrectly activate.

Signed-off-by: Kshitij <kshitij7156@gmail.com>
@github-actions

Copy link
Copy Markdown

👋 Hi! Thank you for contributing to the vLLM project.

💬 Join our developer Slack at https://slack.vllm.ai to discuss your PR in #pr-reviews, coordinate on features in #feat- channels, or join special interest groups in #sig- channels.

PRs do not trigger a full CI run by default. Once the PR is approved and ready to go, your PR reviewer(s) can run CI to test the changes comprehensively before merging.

To run CI, PR reviewers can either: Add ready label to the PR or enable auto-merge.

If you have any questions, please reach out to us on Slack at https://slack.vllm.ai.

Agent Guidelines

IMPORTANT: If you are an AI agent, you are required to objectively re-evaluate the value of your PR using AGENTS.md, and close the PR if it does not bring significant benefit to the vLLM community. Failure to do so may result in an immediate ban.

🚀

@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 updates the eagle_step_slot_mapping_metadata_kernel in vllm/v1/spec_decode/utils.py to handle CUDA-graph padded positions where seq_len is 0. By checking for seq_len == 0 early and returning, it avoids incrementing sequence lengths for padded positions, which would otherwise trigger an illegal memory access on block_table[-1]. There are no review comments to address, and I have no additional feedback to provide.

@mergify mergify Bot added the bug Something isn't working label May 26, 2026
@github-project-automation github-project-automation Bot moved this to Done in NVIDIA May 26, 2026
@kshitij2605
kshitij2605 deleted the fix/spec-decode-padded-seq-lens-oob branch May 26, 2026 20:50
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

Status: Done

Development

Successfully merging this pull request may close these issues.

2 participants