Error messages

vllm.v1.engine.exceptions.EngineDeadError: EngineCore encountered an issue. See stack trace (above) for the root cause.

vllm.v1.engine.exceptions.EngineDeadError: EngineCore encountered an issue. See stack trace (above) for the root cause.

This one shows up after a vLLM server has been running fine for a while. Requests were being answered, then a traceback ends with:

vllm.v1.engine.exceptions.EngineDeadError: EngineCore encountered an issue. See stack trace (above) for the root cause.

As of September 25, 2026, 558 issues and pull requests in the vllm-project/vllm repo mention EngineDeadError, and 383 carry the "EngineCore encountered an issue" line itself. We read the code at tag v0.30.0 to see where it comes from.

What died, and why it's after startup

vLLM runs the model in a separate process called the engine core, while the API server (or your Python script) hands it requests. If the engine core crashes while loading, you get a different error, "Engine core initialization failed", which has its own page. EngineDeadError is the other case: the engine had started, was serving, and then an exception escaped its main loop, or the process disappeared outright.

The class's own docstring in vllm/v1/engine/exceptions.py says it's "Raised when the EngineCore dies. Unrecoverable." That word matters. Once the flag is set, vLLM doesn't try to restart the engine. Every new request raises the same error, and in the reports we read people saw HTTP 500 on requests and 503 on /health. The server then shuts itself down within a few seconds (a watchdog checks every 5), unless you set VLLM_KEEP_ALIVE_ON_ENGINE_DEATH=1.

Where the real error is

When the crash is an ordinary Python exception, the engine core logs it before it tells the server it's dead. Search upward for this line:

EngineCore encountered a fatal error.

The traceback under it ends in the actual exception. If the crash happened while running the model, vLLM also logs a block starting "Dumping input data for V1 LLM engine" with the batch it was running, which helps when one request set it off. If the process vanished instead (killed by the kernel for memory, or a segfault), you'll see [shutdown] MPClient: engine core exited unexpectedly; starting cleanup with no Python traceback, and the answer is in dmesg or the container's exit reason.

What kills a running engine

Out of memory in the middle of a request. vLLM measures memory at startup, but a large prompt can still need more working memory than it set aside. Issue #52871 (August 2026, RTX 5090) shows it plainly: prompts of about 4,000 tokens were fine, about 6,000 killed the engine every time with torch.OutOfMemoryError. The reporter also found it depended on what had run before. Lowering --gpu-memory-utilization or --max-num-batched-tokens leaves more room.

A step that hangs. Each model step has a deadline, VLLM_EXECUTE_MODEL_TIMEOUT_SECONDS (300 by default in 0.30.0). A GPU stuck in a bad kernel produces "RPC call to execute_model timed out." or the same for sample_tokens, and the engine dies. In issue #48752, with speculative decoding (a small draft model guessing tokens ahead) on GB200s, a vLLM maintainer worked around it by switching the MoE backend to Triton, and the reporter found eager mode worked.

One bad request. Several open issues show a single malformed input taking the whole engine down: a multimodal item whose placeholder count didn't match its embeddings (#55546), or a penalty combined with prompt embeddings. Those are bugs, and the last line of the earlier traceback is the thing to search the issues for.

If it appears only on shutdown

Seeing it when you stop the server with Ctrl+C or SIGTERM is a known false alarm. Issue #48745 traced it to the cleanup code marking the engine dead before a background task is cancelled, and a fix is proposed in #49000. Nothing crashed, and there's nothing to fix on your side.