The new vLLM release for developers serving language models expands support for memory-saving caches and adds a universal parser for model responses. Migration checks should cover browser access restrictions and request handling changes, not just performance gains.

1. Expanded NVFP4 cache support and performance conditions

A cache stores information from previously processed tokens for reuse. Support has expanded for NVFP4, a format that stores this information using fewer bits.

This format is also available on the SM8x and SM12x GPU architecture families.

SM90 is also supported. On SM12x, it also applies to a dedicated decode path that uses previously processed content to generate the next token. Broader support does not mean defaults have changed across all hardware.

GLM-5.x uses an 8-bit floating-point cache by default on SM100. The release notes report a throughput increase of 2.3~5.5% ([#60140](https://github.com/vllm-project/vllm/pull/60140), [#60281](https://github.com/vllm-project/vllm/pull/60281)).

An fp8_ds_mla cache path has been added on SM90.

Output throughput for GLM-5.3-Flash on this path reportedly rose by up to 31% ([#59246](https://github.com/vllm-project/vllm/pull/59246)). The source gives no specific baselines or load conditions for either throughput figure. Each should be treated only as a reported gain for its particular model and hardware path.

ROCm, the runtime environment for AMD GPUs, adds a 4-bit cache called ultraquant_4bit. Its storage density is about 2 times that of an 8-bit floating-point cache ([#57057](https://github.com/vllm-project/vllm/pull/57057)). The earlier throughput figures involve different models and paths and cannot be compared directly. Storage density is also a different metric from processing speed.

2. Structured decision-making and a universal parser

The new POST /v1/systemone is an API, available by default, that answers questions about choices or scores based on structured state. The release notes provide no request or response examples.

The hf parser reads response_template from saved model files. This effectively supplies response format instructions with the model. Models providing it do not need dedicated parsers for tool calls and reasoning content.

Both Python and Rust frontends are supported. Select this parser with --tool-call-parser hf for tool calls and --reasoning-parser hf for reasoning.

3. Security fixes and input restrictions

The release addresses 3 security advisories. Chat templates are checked before execution and given execution time limits to counter resource exhaustion ([Security #50300](https://github.com/vllm-project/vllm/pull/50300)).

CORS, which controls cross-origin browser access, no longer allows all origins by default. Connecting browser clients requires explicitly specifying allowed origins ([Security #61009](https://github.com/vllm-project/vllm/pull/61009)).

Untrusted images are limited to raster formats, which represent images as pixels. EPS and WMF formats are therefore rejected ([Security #60022](https://github.com/vllm-project/vllm/pull/60022)).

References in the shared-memory multimodal cache, which handles inputs such as images and audio, are signed to detect forgery. Forged references are rejected ([Security #59357](https://github.com/vllm-project/vllm/pull/59357)).

A JSON schema for structured output nested deeper than 64 levels returns HTTP 400. This rejects requests with excessively nested output format rules ([Security #60036](https://github.com/vllm-project/vllm/pull/60036)).

Higher cache density and the universal parser improve memory utilization and reduce model-specific integration work. Tighter access and input restrictions, however, may require changes to existing browser connections and image processing paths.

4. Installation environment and removed features

Python 3.10 support has ended, making 3.11 the minimum version.

CUDA source builds require GCC 13 and fail early if this requirement is not met.

Install the prebuilt package targeting CUDA 13.0 as follows.

pip install vllm

The optimization that split sequences for parallel processing during torch.compile compilation has been removed. Sequence parallelism implemented within models remains available.

5. Request and response compatibility changes

max_tokens is now an output cap rather than a value reserved in advance within the context window. Long inputs are no longer rejected to reserve output space. This does not make the model's total accepted length unlimited ([#57035](https://github.com/vllm-project/vllm/pull/57035)).

Clients that branch on Responses API reasoning event names should review their receiving code ([#59652](https://github.com/vllm-project/vllm/pull/59652)).

The start event has changed from response.reasoning_part.added to response.content_part.added.

The end event has changed from response.reasoning_part.done to response.content_part.done.

Reasoning content is identified by part.type="reasoning_text".

This upgrade should be treated as a transition that combines broader cache and parser support with checks on security defaults and compatibility with existing requests.