A new stable vLLM Ascend release is available for developers running large language models on Ascend accelerators. It expands model-specific execution, caching, and parallel processing support. Migrating existing deployments requires reviewing model-specific runner choices and the transition planned for the next release.

1. More execution paths tailored to major models

Released on October 29, vLLM Ascend 0.30.0 is built against upstream vLLM 0.30.0. It also fixes issues found after the release candidate involving attention, computations that reflect input importance, cache transfers, and new runner stability.

DeepSeek V4.1 gains TurboQuant support with a 4-bit latent KV cache in the new runner. This stores intermediate inference data at lower precision, while the existing runner can also use a packed KV cache.

Kimi K3 gains full execution support, including speculative decoding, which generates candidate answers before verifying them, and optimizations that combine operations. Ascend 950 also supports an attention path without position-aware rotation operations.

GLM-5.3-Flash gains sparse attention, which selectively computes relevant parts, and 8-bit packed KV cache support. Excessive cache page allocation in small slots has also been fixed.

Qwen3.8-27B has been enhanced to handle KV caches stored in separate locations. Fixes also address performance and kernel compatibility when deploying quantized models on 310P. Kernels are low-level code that performs device operations, making these changes relevant to developers using that hardware.

2. Prefetching caches and reducing unnecessary processing

The cache pool, which groups and manages cache data, can now prefetch upcoming regions when loading data for each model layer. Changes also reduce cache lookup and page management overhead and skip unnecessary CPU synchronization during parallel execution.

Support for combining speculative decoding with parallel execution has also expanded. PCP, which splits inputs for processing, now has improved request splitting for speculative decoding.

The project lists these changes as performance improvements. Developers assessing deployment can review which cache and parallel execution combinations are available for their models.

3. Keeping the default runner while preparing the next transition

V1 remains the default runner in this release, while the new runner is named V2. The runner is the component that executes model computations, and this release marks a period when both generations coexist.

Installation requirements are also specified. CANN is 9.2.1, and the release image uses Python 3.12.

PyTorch is set to 2.10.0 and torch_npu to 2.10.0.post7. Developers updating existing environments can check these underlying components alongside model support.

Users are directed to official tutorials linked in the release notes for model-specific deployment instructions. Matching the chosen model's execution path to the current environment is the starting point for testing new features.

4. More options require reviewing existing configurations

Reducing waste in cache management and expanding quantization and parallel execution combinations broadens model operation options. However, the project plans to phase out older, less-used models based on maintenance costs. Deprecated features, including layer splitting and FlashComm2, have already been removed.

The project plans to remove the existing runner and switch fully to the new runner in the next release. New deployments can use the added model support. Teams maintaining existing deployments must also identify configurations that depend on disappearing features or the old runner and schedule their transition.

5. Model-specific execution requirements and cache limits remain

The release notes say some models require enabling the new runner. Gemma-4-E4B-it fails to run due to an attention operator issue, while GLM-5.3 structured output differs from the same upstream version.

Mooncake-based cache pooling does not support SSD offloading on RoCE networks, which use Ethernet-based low-latency communication. SSD offloading moves cache data to SSDs for processing. An issue also remains where the SSD cache cannot be found when per-layer pooling combines SSD offloading with pipeline parallelism, which divides computation into sequential stages.

This release broadens model-specific execution choices while bringing forward the need for existing deployments to prepare for the next runner generation.