[Bug]: GLM-5.3-Flash illegal memory access on long-context chucked prefill still reproduces on v 0.30.0 (B200, TP4+EP, MTP)

Your current environment

Still reproduces on the v0.30.0 release (4x B200, MTP enabled)

Adding a data point from a different config: official vllm/vllm-openai:v0.30.0 image, and with MTP speculative decoding (the reports above run without spec decode).

Environment

• 4x NVIDIA B200 (SM100), TP=4 + EP, Docker, air-gapped
• Image: vllm/vllm-openai:v0.30.0 (no custom patches)
• Model: zai-org/GLM-5.3-Flash (FP8 checkpoint)
• Driver / CUDA: v13.0

Serve args

--tensor-parallel-size 4 --enable-expert-parallel
--gpu-memory-utilization 0.88 --kv-cache-dtype fp8
--max-num-batched-tokens 16500 --max-num-seqs 32
--speculative-config '{"method":"mtp","num_speculative_tokens":5}'
--enable-auto-tool-choice --tool-call-parser glm47 --reasoning-parser glm45

Prefix caching left at the default (on). max_model_len left at the default (1048576). Resolved config: cudagraph_mode=FULL_AND_PIECEWISE, compilation mode NONE, Model Runner V2 (vllm/v1/worker/gpu/model_runner.py).

Describe the bug

Crash

CUDA error: an illegal memory access was encountered on all 4 ranks, followed by EngineDeadError.

Where it surfaced:

• All ranks: CUBLAS_STATUS_EXECUTION_FAILED in the MLA q_proj GEMM (glm5next/nvidia/attention.py:590 → layers/mla.py:221 → default_unquantized_gemm).
• TP0 also: kv_block_zeroer.zero_block_ids (model_runner.py:1206 → async_tensor_h2d).

As noted above, these are async reporting sites, not the origin.

Batch at the time of the crash (from dump_input)

req A: num_computed_tokens=100513, 6 tokens scheduled (MTP decode, 5 spec tokens)
req B: num_computed_tokens=490752, 16128 tokens scheduled (chunked prefill)
total_num_scheduled_tokens=16134
new_block_ids_to_zero=[1084, 1083, 1082, 1134, 1135, 1136, 1137]

So the batch was a mixed step: a ~490K-position chunked prefill combined with an MTP decode. The prefix cache hit rate was ~80% just before the crash. Draft acceptance fell from 95.7% to 45.7% to 28.5% across the last three 10-second intervals before the crash. That may or may not be related.

Takeaways

• The v0.30.0 release (2026-09-22) is still affected. This is consistent with the 2026-09-16 nightly repro above.
• MTP does not avoid it, and MTP adds spec-decode state paths to the mix.
• We have not yet isolated the cause by varying one setting at a time (prefix caching off, MTP off, --kv-cache-dtype auto, a smaller --max-num-batched-tokens). We will report back.

We have the full worker tracebacks and the scheduler dump, and can share them.

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.