vLLM latest version in 2026 is v0.20.2

vLLM v0.20.2, tagged on May 10, 2026, available on PyPI and on the vllm-project/vllm GitHub releases page. It is a 6-commit patch on top of v0.20.0 (April 27, 2026), with v0.20.1 (May 4, 2026) as the intermediate patch. Three minor versions in 14 days; the cadence is unusual but reflects the DeepSeek V4 stabilization push. Confirmed by re-checking github.com/vllm-project/vllm/releases/tag/v0.20.2 and pypi.org/project/vllm on May 12, 2026.

Four fixes. (1) DeepSeek V4 sparse attention, PR #41665, re-enables the persistent topk path on Hopper and ensures the memset kernel runs at CUDA graph capture time, resolving MTP=1 hangs. (2) V1 engine KV cache, PR #41282, fixes a 'failure to allocate KV blocks' error in the V1 engine path. (3) gpt-oss MXFP4 plus torch.compile, PR #42002, passes hidden_dim_unpadded through the moe_forward fake op so MXFP4 functions under torch.compile. (4) Qwen3-VL, PR #40932, removes an invalid deepstack boundary validation that triggered errors under high load. Three of those four are CUDA-host server fixes; only Qwen3-VL touches anything a Mac-agent operator might be running through their server.

Almost certainly not, unless you specifically front your agent with Qwen3-VL or DeepSeek V4 on a Hopper card. The other three fixes are corrections to CUDA-side server behavior that only matter to the operator of the vLLM box, not the consumer of its API. The reason this is true is that the Fazm app does not talk to vLLM. It talks to an Anthropic-shaped shim (LiteLLM, claude-code-router, or vllm-mlx for the all-in-one case) that talks to vLLM. The shim absorbs every server-side change as long as the OpenAI Chat Completions protocol stays stable, which v0.20.x has not broken. The two-line block in ACPBridge.swift that points the bridge at the shim's URL has not had to change once across v0.18, v0.19, v0.20.0, v0.20.1, and v0.20.2.

Because the DeepSeek V4 work landed in v0.20.0 as 'shipping with known constraints on Hopper', the v0.20.1 release on May 4 stabilized the multi-stream pre-attention GEMM path, and v0.20.2 on May 10 was needed to fix the persistent topk regression that v0.20.1 did not catch. The trigger for v0.20.2 was customer reports of MTP=1 hangs on Hopper after pulling v0.20.1. The release was prepared by six contributors and shipped as a maintenance-only tag. There is no new model support, no API change, no kernel rewrite; it is the kind of patch you skip if you are not running into the specific symptom.

Yes to all three. pip install vllm==0.20.2 resolves on PyPI as of May 10, 2026. The vllm/vllm-openai:v0.20.2 container image is published. The GitHub release page at github.com/vllm-project/vllm/releases/tag/v0.20.2 has the source tag and the changelog. The vllm.ai/releases registry lists it as 'all versions'. None of the community Apple Silicon forks have caught up yet, as is normal for patch cadence; expect vllm-project/vllm-metal and waybarrios/vllm-mlx to pick up the relevant Qwen3-VL fix on their next planned cut, not within hours.

Two reasons. First, CVE-2026-0994 (deserialization vulnerability in the prompt_embeds handling of the Completions API, affecting versions 0.10.2 and later) was patched in the v0.19.x cycle. If your server exposes Completions to anything you do not fully trust, that is a real upgrade trigger. Second, v0.20.0 raised the dependency floor: CUDA 13.0.2, PyTorch 2.11.0, Transformers v5, Python 3.14 supported. If your host machine is still CUDA 12, you cannot pull v0.20.x without rebuilding the wheel, and that is a meaningful migration. There is no other operational reason to upgrade past v0.19.x unless you specifically need DeepSeek V4, Hunyuan v3 preview, or FA4 as default MLA prefill.

Vanilla vLLM still runs CPU-only on macOS Apple Silicon via the requirements/cpu.txt build path, and the v0.20.2 patches are GPU-side fixes that do not touch the CPU backend. The CPU build path works but is slow. For practical GPU use on a Mac you want the community vllm-project/vllm-metal plugin or the waybarrios/vllm-mlx fork. Neither of those tracks vanilla vLLM patch-for-patch; they cherry-pick the changes that matter (FA4, MLA prefill, MoE routing) and skip server-infra patches like the V1 engine KV block fix. v0.20.2 specifically is unlikely to land in either fork until they have a v0.20-tier merge to do anyway.

If you are on a CUDA 13 host and want the new model support, pin v0.20.2 and call it done; the fixes are strictly additive over v0.20.1. If you cannot move off CUDA 12, pin v0.19.1 and accept that you do not get DeepSeek V4 or FA4 prefill. If you are running the Hugging Face transformers stack on Apple Silicon and serving locally to your laptop, pin nothing; pull from vllm-project/vllm-metal main and accept that 'latest' means what their last green CI run produced, not what is on the vanilla GitHub releases page. None of those choices change the line in Fazm that wires your shim into the agent: ACPBridge.swift:468-469 reads customApiEndpoint and sets ANTHROPIC_BASE_URL, regardless.

pip index versions vllm prints the resolvable PyPI versions. curl -fsSL https://api.github.com/repos/vllm-project/vllm/releases/latest | jq -r '.tag_name' prints the tag on the GitHub release machinery, currently v0.20.2 as of May 12, 2026. docker pull vllm/vllm-openai:latest and docker inspect with a jq filter on RepoTags shows what the latest tag points at. The vllm.ai/releases page is the human-readable index. All four agree.