Summary
A frontend-legal multi-request speculative workload can make vLLM produce an out-of-vocabulary recovered token equal to vocab_size, convert that value to -1 when choosing the next live token for a request, and then feed that -1 back into the next drafter input ids. On Qwen3 GPTQ this reaches the worker-side drafting / attention path and crashes the engine with a GPU device-side assert.
The same issue is reachable through the public gRPC request surface by sending a specific overlapping Generate / Abort sequence.
Impact
- A remote client that can send public gRPC generation requests can crash the
shared vLLM engine worker
- The triggering request sequence aborts concurrent requests and prevents later
requests from completing until the worker is restarted
- In shared deployments, this is a service-wide denial of service for other
clients, not just a failure isolated to the attacking requests
- The failure is reproducible, so repeated request sequences can sustain the
outage
Affected version
- Confirmed on vLLM
0.17.1
- Earlier and later versions have not been checked yet in this report
Repro model
- Official Hugging Face repo:
- Anyone wants to reproduce the bug with my PoC scripts should download
Qwen3-0.6B-GPTQ-Int8 first
Trigger chain
- A legal multi-request speculative workload keeps structured-output state,
speculative decoding, overlap, and request cancellation active in the same
live engine.
- During rejection sampling, vLLM produces a recovered token equal to the
model
vocab_size boundary value.
- That recovered token appears in position 0 of the sampled speculative row
for a live request. The same row also contains trailing padding entries
equal to
-1, but those padding entries are not the key fault by
themselves.
- The next-token preparation step treats the position-0 recovered token as the...