ThinkFacility

Error messages

are not supported for now. Supported architectures:

The message

are not supported for now. Supported architectures:
vLLM 0.30.0 read September 26, 2026vLLMlocal modelsHugging Face

What it means

The architecture named in the model's config.json isn't in this vLLM's list of model classes, and vLLM couldn't run it through its Transformers fallback either.

What to do

Check the model against vLLM's supported models page and upgrade, or install a nightly if support landed after the last release. For a custom model, try --trust-remote-code.

vLLM stops before loading any weights. Recent versions wrap it in a config validation error, like this from issue #35344 (vLLM 0.15.1, February 2026):

pydantic_core._pydantic_core.ValidationError: 1 validation error for ModelConfig
  Value error, Model architectures ['Qwen3_5MoeForConditionalGeneration'] are not supported for now.

Older versions raise it bare, followed by a very long list (cut short here, from #22231):

ValueError: Model architectures ['Qwen3ForCausalLM'] are not supported for now. Supported architectures: ['AquilaModel', 'AquilaForCausalLM', 'ArcticForCausalLM', ...

The wording hasn't changed since at least v0.2.0. We checked it in vLLM 0.30.0 (released September 22, 2026), where it lives in vllm/model_executor/models/registry.py.

What the architecture name is

Every Hugging Face model has a config.json with an architectures field naming the Python class that implements it. vLLM keeps its own table of those names. The docs' advice is to open config.json and check that name against vLLM's supported models list. When the name is missing, vLLM tries to run the model through Transformers (the Hugging Face library) instead, and only if that fails too do you get this message.

Your vLLM predates the model

This is the case most issue threads land on. When Qwen3.5 came out, people on 0.15.1 hit this, and a maintainer answered: "Qwen3.5 is not included in version 0.15.1." Another pointed out that 0.16.0 didn't have it either, because the release was cut before the support PR merged, so the only way in was a nightly build. The script they posted:

uv venv
source .venv/bin/activate
uv pip install -U vllm \
    --torch-backend=auto \
    --extra-index-url https://wheels.vllm.ai/nightly

In #22231 the name was Qwen3ForCausalLM, a model vLLM already supported, and the printed list plainly didn't include it. The maintainer's first question was "What is your vLLM version?" An old install looks exactly like a missing model.

Custom models and remote code

If the model ships its own code on the Hub, vLLM's Transformers fallback can pick it up. The docs say config.json must contain auto_map.AutoModel, and you start the server with --trust-remote-code. Without that flag the custom class never loads and you land here. Some models won't work either way: vLLM's fallback needs a class it can plug its own attention into, and the check for that can fail.

Sibling messages from the same check

The same function in 0.30.0 can print a different line first. failed to be inspected. Please check the logs for more details. means the name is supported but loading the class crashed. A maintainer on #13216 said the real exception is printed further up the log, and in one reported case it was an incompatible Triton version.

Two more cover models that left the main package:

As of September 26, 2026, 102 issues in the vLLM repo contain "are not supported for now".

Other lines the same feature prints

Match yours against these if the one at the top of the page is not quite it. They come from the same code and mean related things.

  • Value error, Model architectures
  • ValueError: Model architectures
  • pydantic_core._pydantic_core.ValidationError: 1 validation error for ModelConfig
  • are not supported for now