vLLM v0.16.0 shipped on February 25, 2026

February 25, 2026 on the vllm-project/vllm GitHub releases page, with the branch cut on February 8, 2026. Anything merged to main between February 8 and February 25 did not make the cut and landed in v0.17.x. The release totals 440 commits from 203 contributors, 7 of whom were new. Confirmed against github.com/vllm-project/vllm/releases/tag/v0.16.0 on May 17, 2026.

A new WebSocket-based Realtime API at /v1/realtime, mirroring the OpenAI Realtime interface. It was merged via PR #33187 and is built on the Voxtral realtime infrastructure that landed earlier in the cycle. The Realtime API speaks WebSocket and streams audio frames; it is not a new variant of the existing OpenAI Chat Completions or Anthropic Messages HTTP endpoints. The vLLM blog post 'Streaming Requests & Realtime API in vLLM' from January 31, 2026 covers the intent in detail at blog.vllm.ai/2026/01/31/streaming-realtime.html.

It moved real numbers, but they apply to a narrow path. Async scheduling with pipeline parallelism is now fully supported, and the release notes cite a 30.8 percent E2E throughput improvement and a 31.8 percent TPOT (time-per-output-token) improvement on that path. The qualifier matters: those gains are measured for workloads that use pipeline parallelism, not for a single-GPU single-tensor-parallel setup. If you run one card and one shard, the change is invisible. If you run multi-node pipeline parallelism for a large model, the change is real.

Five removals worth pinning before you upgrade. BitBlas quantization is gone. Marlin 24 quantization is gone. The deprecated reasoning_content message field is gone. Deprecated pooling items are gone. The VLLM_ALL2ALL_BACKEND environment variable is removed in favor of the new dispatch path. Separately, IPEX is deprecated for the Intel XPU backend in favor of vllm-xpu-kernels, which gains MoE, MXFP4 MoE, WNA16, scaled_mm, and FP8 MoE support. If your service still reads reasoning_content from streamed responses, that breaks on v0.16.0.

Yes, a protobuf-related CVE (tracked as CVE-2026-0994 in the vLLM advisory feed) was patched in the v0.16.0 cycle. The earlier prompt_embeds deserialization issue that affected the Completions API in 0.10.2 and later was patched in the v0.19.x cycle, not here. If your production server exposes the Completions endpoint or is on the v0.10 to v0.15 line, the v0.19.x cycle is the more important upgrade for that specific issue.

Probably not the way you are picturing it. The Realtime API at /v1/realtime is a WebSocket protocol that streams audio frames in and audio (or text) frames out. A voice-first desktop agent like Fazm does its speech-to-text on-device, then sends plain text to the model over Anthropic Messages HTTP. Those are two different protocols on two different connection types. The Fazm-to-vLLM path runs through an Anthropic-to-OpenAI shim (LiteLLM, claude-code-router, or a small custom FastAPI bridge) and only forwards HTTP requests speaking the Anthropic Messages shape. There is no place in that path to inject a WebSocket. To use the Realtime API end-to-end you need a client that opens a WebSocket directly to vLLM and streams microphone frames, which is a different application than a desktop coding agent.

Four lines at Desktop/Sources/Chat/ACPBridge.swift, lines 527 to 530, in the MIT-licensed Fazm repo at github.com/mediar-ai/fazm. The block reads UserDefaults.standard.string(forKey: 'customApiEndpoint'); if the string is non-empty it sets env['ANTHROPIC_BASE_URL'] on the Node ACP subprocess Fazm spawns. The Node subprocess is the @agentclientprotocol/claude-agent-acp bridge wrapping Claude Code. Because the block only sets ANTHROPIC_BASE_URL, the spawned bridge speaks HTTP Anthropic Messages to whatever URL you paste. v0.16.0 did not change that contract, so the four lines do not change either.

Only if one of three things is true. (1) You serve Voxtral or a similar audio model and you want the streaming WebSocket path. (2) You run multi-node pipeline parallelism and care about the async-scheduling throughput gain. (3) Something in your stack still uses BitBlas, Marlin 24, reasoning_content, or VLLM_ALL2ALL_BACKEND, in which case you need to plan a migration before pulling the tag. If none of those apply, the upgrade is fine but optional, and your downstream agent (which only consumes the HTTP endpoint) will not notice the difference.

Four sources I cross-checked on May 17, 2026. The GitHub release page at github.com/vllm-project/vllm/releases/tag/v0.16.0 has the tag, the date, and the changelog. PyPI lists v0.16.0 under pypi.org/project/vllm. The PR that introduced the Realtime API lives at github.com/vllm-project/vllm/pull/33187. The companion vLLM blog post on the design intent is at blog.vllm.ai/2026/01/31/streaming-realtime.html. The Red Hat day-zero writeup of Voxtral Mini 4B on vLLM is at developers.redhat.com/articles/2026/02/06/run-voxtral-mini-4b-realtime-vllm-red-hat-ai.