Error messages

RuntimeError: Engine core initialization failed. See root cause above.

RuntimeError: Engine core initialization failed. See root cause above.

This is the last line vLLM prints when a model fails to load, whether you ran vllm serve or built an LLM(...) object in Python:

RuntimeError: Engine core initialization failed. See root cause above. Failed core proc(s): {}

It's one of the most quoted vLLM errors on GitHub. As of September 25, 2026, 735 issues and pull requests in the vllm-project/vllm repo contain it, 113 of them opened in the last 90 days. That number is high because the line itself carries no reason, so everyone who hits any startup failure ends up quoting it.

What the message is telling you

vLLM runs the model in a child process called the engine core, separate from the API server or your Python script. We read the startup code in vLLM 0.30.0: the parent waits for the engine core to report that it's ready, and if that process exits first, the parent raises this error. The engine core has already logged the real exception by then, under the line EngineCore failed to start., which is what "root cause above" points at.

The part in braces lists the engine processes that had exited, with their exit codes, such as {'EngineCore': 1} (or EngineCore_DP0 when you run data parallel). Empty braces don't mean nothing went wrong. vLLM only lists a process once it has an exit code, so it can notice the crash before it can name one.

Finding the real error

Search the log upward for EngineCore failed to start. The traceback right under it ends in the actual exception. A report from September 2026 (issue #56197) shows the shape well: the last line was the generic one above, and higher up sat

(EngineCore pid=...) ERROR [core.py:1374] Traceback (most recent call last):
  ...
AssertionError: Requires power-of-2 dim, got 96

In a notebook the child's output sometimes doesn't reach the cell (which is how a lot of "there is no root cause above" reports start), so run the same thing as a plain script in a terminal. Setting VLLM_LOGGING_LEVEL=DEBUG gives more detail, and the vLLM troubleshooting docs list it first for this kind of hunt.

The causes that come up most

Not enough GPU memory. By default vLLM reserves room for the model's full context length. A vLLM maintainer answering issue #17618 put it this way: "This means you don't have enough memory to run the model with the full sequence length. I suggest setting a lower value of max_model_len." The earlier traceback will usually show one of vLLM's KV cache errors or a CUDA out of memory. Lower --max-model-len, and if another program already holds GPU memory, lower --gpu-memory-utilization (0.92 of the card by default in 0.30.0). The same maintainer mentioned --enforce-eager, which skips CUDA graphs (recorded GPU call sequences that speed up decoding but take memory), at some cost in speed.

A GPU the model's kernels don't support. Most reports from the last three months are this kind: an FP8 model on an A100, a new architecture on a card from an older generation, a kernel that fails on a specific chip. The traceback names the kernel or data type. Those are bugs or hardware limits, and searching the repo's issues for the last line of the traceback is faster than trying settings.

Python multiprocessing in a script. If the earlier error says a process started "before the current process has finished its bootstrapping phase", put your vLLM code under if __name__ == '__main__':, as the troubleshooting docs show.