vLLM Ascend 0.30.0：扩展模型运行支持，预告…

面向在 Ascend 加速器上运行大语言模型的开发者，vLLM Ascend 推出了新的正式版。该版本扩展了适配主要模型的运行方式以及缓存与并行处理支持，迁移现有部署时，需要一并关注各模型的执行器选择和下一版本的迁移计划。

1. 增加适配主要模型的执行路径

项目于 10月29日发布的 vLLM Ascend 0.30.0 基于上游 vLLM 0.30.0 构建。该版本还修复了候选版本发布后发现的注意力计算、反映输入信息重要性的相关计算、缓存传输及新执行器稳定性问题。

DeepSeek V4.1 新增 TurboQuant 支持，可在新执行器中使用 4位潜在 KV 缓存。这种方式以低精度保存推理期间保留的中间数据，旧执行器也可使用打包形式的 KV 缓存。

Kimi K3 获得完整运行支持，包括先生成候选答案再验证的推测解码，以及合并多个运算的优化等。在 Ascend 950 上，还支持不使用反映位置信息的旋转运算的注意力路径。

GLM-5.3-Flash 新增仅选择必要部分进行计算的稀疏注意力，以及 8位打包 KV 缓存支持。该版本还修复了小槽位中缓存页过度分配的问题。

Qwen3.8-27B 增强了对非连续存储 KV 缓存的处理。该版本还修复了在 310P 上部署量化模型时的性能，以及内核（执行设备运算的底层代码）的兼容性问题，使用该硬件的开发者值得关注这些变化。

缓存池是集中管理缓存数据的空间，此次新增了在加载模型各层数据时预读后续所需区间的功能。该版本还降低了缓存查询和页面管理的开销，并省略了并行执行中不必要的 CPU 同步。

推测解码与并行执行相结合的支持也有所扩展。在对输入进行拆分处理的 PCP 中，推测解码请求的拆分得到了增强。

项目将这些变化列为性能改进。对于评估部署的开发者，了解所用模型能够采用哪些缓存与并行执行组合，是审视本次变化的切入点。

本版本的默认执行器为 V1，新执行器名为 V2。执行器是实际执行模型计算的组件，本次发布处于两代执行器并存的阶段。

项目同时列出了安装所需的基础版本。CANN 为 9.2.1，发布镜像中的 Python 为 3.12。

PyTorch 对应 2.10.0，torch_npu 对应 2.10.0.post7。更新现有环境的开发者，除了核对模型支持，也可一并比对这些基础组件。

各模型的部署方法可参阅发行说明链接的官方教程。测试新功能时，应先匹配所用模型的执行路径与当前环境。

减少缓存管理浪费并增加量化与并行执行组合，拓宽了模型运维的选择。另一方面，项目计划根据维护成本逐步终止对使用量下降的旧模型的支持，并已移除层拆分、FlashComm2 等弃用功能。

项目表示，计划在下一版本中移除旧执行器，全面转向新执行器。因此，新部署的团队可以利用新增的模型支持，而维护现有部署的团队则需要找出依赖即将移除的功能与执行器的配置，并制定迁移计划。

发行说明指出，部分模型需要启用新执行器才能获得支持，Gemma-4-E4B-it 因注意力算子问题运行失败，而 GLM-5.3 的结构化输出结果与上游项目同版本不一致。

基于 Mooncake 的缓存池化在 RoCE 网络（基于以太网的低延迟通信网络）上不支持 SSD 卸载，即将缓存数据转移到 SSD 进行处理的功能。此外，逐层池化同时使用 SSD 卸载与流水线并行（将计算分阶段衔接执行）时，仍存在无法找到 SSD 缓存的问题。