快速结论
将硬件、镜像摘要、插件与上游 vLLM、CANN、torch_npu、权重和量化配置作为一组记录。某个包安装成功不足以说明整组配置受到验证。
- 本文基于已发布的 vLLM Ascend RC 文档，属于版本管理方法。
- RC1 声明上游 vLLM v0.30.0、CANN 9.2.0 等依赖。
- RC2 对官方镜像 Dockerfile 的 CANN 构建标识作了修正。
本次更新：10 月 26 日复核：10 月 26 日：把算子微基准作为独立附件。保留原网址和首次发布时间。
部署 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 或量化，分别核对该模型和硬件是否在声明范围内。项目首页中的特性名称不能代替具体版本的兼容范围。
服务栈与算子库分开判断
算子微基准、通信测试与端到端推理回答不同问题。即便底层性能改善，服务仍可能受到调度、数据搬运和请求形状影响。已有方法见昇腾算子评估教程。
发布状态、模型和硬件的范围都记录清楚后，结果才更容易复现与对比。
10 月 18 日：1017 权重需单独核对
vLLM 配方已列出新检查点，同时明确部分测量来自旧权重。昇腾场景应按自己所用后端与设备核对新修订，不把旧 V4.1 的兼容记录直接视为 1017 的全部组合均已验证。
10 月 22 日：DeepInfer 是另一条部署路线
DeepInfer 当前官方支持列表为 NVIDIA SM100 与华为昇腾 950，昇腾环境要求 CANN 9.2。它与上文 vLLM Ascend RC 的依赖矩阵属于不同框架，不能把一条发布线的安装命令拼到另一条线上。
当前公开内容以离线推理为主，完整在线服务还需 KV 缓存系统、分离部署与副本负载均衡等部分。昇腾 950 的声明不能扩展成其他 NPU 型号全部兼容；GPU 测量也不能直接当作昇腾性能。
准备步骤见DeepInfer 离线教程。记录模型修订、源码与子模块提交、驱动、CANN、设备及并行配置，再检查完整链路。
10 月 26 日：把算子微基准作为独立附件
本轮重读 DeepGEMM-Ascend 官方仓库，并补充近期昇腾研究解读。建议在现有版本矩阵旁另放算子测试附件：具体设备 SKU、dtype、矩阵形状、软件版本、计时与原始日志各占一列。
服务验收仍需提供模型请求的延迟、完成率与持续运行记录。单算子利用率无法替代该项证据；本文没有测试 NPU 或据研究报告改变兼容性结论。
参考资料
本文依据以下资料整理，版本与接口信息请以来源页面的现行说明为准。