vllm - ✅(Solved) Fix [Bug]: Index out of bounds in TurboQuant KV Cache kernel with Qwen3 during high-concurrency 32k context benchmark [2 pull requests, 1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
vllm-project/vllm#39998Fetched 2026-04-17 08:27:50
View on GitHub
Comments
0
Participants
1
Timeline
3
Reactions
0
Author
Participants
Timeline (top)
cross-referenced ×2labeled ×1

Error Message

The crash occurs when handling 8 concurrent requests with a 32k input context length on an NVIDIA RTX 4090. The error trace points to an assertion failure in a compiled Torch Inductor kernel, indicating an out-of-bounds memory access. Error Logs

Fix Action

Fixed

PR fix notes

PR #40073: Fix for Index out of bounds in TurboQuant KV Cache kernel with Qwen3 during high-concurrency 32k context benchmark

Description (problem / solution / changelog)

This PR fixes issue #39998


<details> <summary> Essential Elements of an Effective PR Description Checklist </summary>
  • The purpose of the PR, such as "Fix some issue (link existing issues this PR will resolve)".
  • The test plan, such as providing test command.
  • The test results, such as pasting the results comparison before and after, or e2e results
  • (Optional) The necessary documentation update, such as updating supported_models.md and examples for a new model.
</details>

Changed files

  • tests/models/multimodal/generation/test_vibevoice_asr.py (added, +264/-0)
  • vllm/model_executor/models/registry.py (modified, +2/-0)
  • vllm/model_executor/models/vibevoice_asr.py (added, +1091/-0)
  • vllm/v1/attention/ops/triton_turboquant_decode.py (modified, +5/-1)

PR #40074: [Bugfix] Fix TurboQuant KV cache index-out-of-bounds in Triton decode kernel

Description (problem / solution / changelog)

Purpose

Clamp masked-out SIMD lanes to page_idx=0 before block table pointer arithmetic. Triton's bounds checker fires on the address even when the output is masked, causing an index error on long (e.g. 32k) sequences.

Fixes issue #39998 https://github.com/vllm-project/vllm/issues/39998

Test Plan

Test Result


<details> <summary> Essential Elements of an Effective PR Description Checklist </summary>
  • The purpose of the PR, such as "Fix some issue (link existing issues this PR will resolve)".
  • The test plan, such as providing test command.
  • The test results, such as pasting the results comparison before and after, or e2e results
  • (Optional) The necessary documentation update, such as updating supported_models.md and examples for a new model.
</details>

Changed files

  • vllm/v1/attention/ops/triton_turboquant_decode.py (modified, +5/-1)

Code Example

VLLM_ALLOW_LONG_MAX_MODEL_LEN=1 \
vllm serve /model \
    --port 8000 \
    --tensor-parallel-size 1 \
    --reasoning-parser qwen3 \
    --enable-auto-tool-choice \
    --tool-call-parser qwen3_coder \
    --language-model-only \
    --gpu-memory-utilization 0.7 \
    --kv-cache-dtype=turboquant_4bit_nc \
    --max-model-len 73728 \
    --host 0.0.0.0 --port 8000

---

/root/.cache/vllm/torch_compile_cache/torch_aot_compile/.../inductor_cache/...py:53: 
unknown: block: [129,0,0], thread: [224,0,0] 
Assertion `index out of bounds: 0 <= tmp16 < 40960` failed.
RAW_BUFFERClick to expand / collapse

Your current environment

code: vllm main 2026-04-16 gpu: 4090 cuda: 12.6 command:

VLLM_ALLOW_LONG_MAX_MODEL_LEN=1 \
vllm serve /model \
    --port 8000 \
    --tensor-parallel-size 1 \
    --reasoning-parser qwen3 \
    --enable-auto-tool-choice \
    --tool-call-parser qwen3_coder \
    --language-model-only \
    --gpu-memory-utilization 0.7 \
    --kv-cache-dtype=turboquant_4bit_nc \
    --max-model-len 73728 \
    --host 0.0.0.0 --port 8000

🐛 Describe the bug

When running a performance benchmark on Qwen3-0.6B using TurboQuant 4-bit KV Cache (--kv-cache-dtype=turboquant_4bit_nc), the vLLM engine crashes during the prefill/decode phase.

The crash occurs when handling 8 concurrent requests with a 32k input context length on an NVIDIA RTX 4090. The error trace points to an assertion failure in a compiled Torch Inductor kernel, indicating an out-of-bounds memory access.

Error Logs

/root/.cache/vllm/torch_compile_cache/torch_aot_compile/.../inductor_cache/...py:53: 
unknown: block: [129,0,0], thread: [224,0,0] 
Assertion `index out of bounds: 0 <= tmp16 < 40960` failed.

Before submitting a new issue...

  • Make sure you already searched for relevant issues, and asked the chatbot living at the bottom right corner of the documentation page, which can answer lots of frequently asked questions.

extent analysis

TL;DR

The most likely fix is to adjust the --gpu-memory-utilization or --max-model-len parameters to prevent out-of-bounds memory access in the Torch Inductor kernel.

Guidance

  • Verify that the --max-model-len parameter (currently set to 73728) is not too high for the available GPU memory, considering the --gpu-memory-utilization setting (0.7) and the input context length (32k).
  • Check if reducing the --tensor-parallel-size or increasing the GPU memory allocation can mitigate the issue.
  • Investigate the Torch Inductor kernel compilation and caching process to ensure it is correctly handling the TurboQuant 4-bit KV Cache configuration.
  • Consider testing with a smaller input context length or a different GPU to isolate the issue.

Example

No code snippet is provided as the issue is related to a specific configuration and hardware setup.

Notes

The solution may depend on the specific version of the vLLM engine, Torch, and CUDA, which are not explicitly stated as problematic. Additionally, the issue might be related to a hardware limitation of the NVIDIA RTX 4090.

Recommendation

Apply a workaround by adjusting the --gpu-memory-utilization and --max-model-len parameters to find a stable configuration, as the root cause of the issue is likely related to memory management and utilization.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING