快速结论
将硬件、镜像摘要、插件与上游 vLLM、CANN、torch_npu、权重和量化配置作为一组记录。某个包安装成功不足以说明整组配置受到验证。
- 本文基于已发布的 vLLM Ascend RC 文档，属于版本管理方法。
- RC1 声明上游 vLLM v0.30.0、CANN 9.2.0 等依赖。
- RC2 对官方镜像 Dockerfile 的 CANN 构建标识作了修正。
本次更新：10 月 15 日核验后新增，区分原始发布日期、适用范围与方法建议。
部署 DeepSeek 时，“软件版本”通常不止一项。本文以 vLLM Ascend v0.30.0rc1和 rc2为例，提供记录模板，没有在 NPU 上运行安装或性能测试。
按层建立对照
| 层次 | 应保存的信息 | 避免的问题 |
|---|---|---|
| 设备 | NPU 型号、卡数、主机与驱动 | 把某一代设备验证推到所有设备 |
| 镜像 | 标签、摘要、架构、来源 | 滚动标签更新后无法复现 |
| 服务栈 | vLLM 与 Ascend 插件版本 | 混用不同发布线 |
| 依赖 | CANN、PyTorch、torch_npu | 单独升级后改变配套关系 |
| 模型 | 仓库、修订、量化格式 | 同名权重实际不同 |
| 运行配置 | 并行、缓存、上下文与调度 | 优化开关改变结果或资源需求 |
一份发布记录中的具体例子
RC1 文档列出上游 vLLM v0.30.0、CANN 9.2.0、PyTorch / torch_npu 2.10.0 / 2.10.0.post4。RC2 单独修复镜像构建，将 Dockerfile 中 CANN 设为 9.2.0_20260930220649。这些是相应发行记录中的配套信息，不能当作未来版本的通用安装命令。
固定后再比较
编辑建议先使用与目标设备和模型相符的发布方案，保存所有配置，再做短请求、长输入、工具输出及目标并发等检查。比较时一次改变一项，保留正确性和失败样本。
若采用预填充与解码分离、KV Pool 或量化，分别核对该模型和硬件是否在声明范围内。项目首页中的特性名称不能代替具体版本的兼容范围。
服务栈与算子库分开判断
算子微基准、通信测试与端到端推理回答不同问题。即便底层性能改善，服务仍可能受到调度、数据搬运和请求形状影响。已有方法见昇腾算子评估教程。
发布状态、模型和硬件的范围都记录清楚后，结果才更容易复现与对比。
参考资料
本文依据以下资料整理，版本与接口信息请以来源页面的现行说明为准。
阅读至此返回学习中心