手里有昇腾卡、想把 vllm-ascend 跑起来，多半会卡在几件事上：驱动和固件版本对不对、CANN 和 torch_npu 装没装对、镜像从哪来、卡型和显存够不够、跑起来后报错看不懂。这篇按「先对齐环境、再选安装路径、最后跑通并测速」的顺序给一份可执行清单，并说明哪些情况不适合自己折腾。
手里有昇腾卡、想把 vllm-ascend 跑起来，卡点往往不在框架本身，而在前面几层：驱动和固件版本对不对、CANN 和 torch_npu 装没装配套、镜像从哪来、卡型和显存够不够、跑起来报错看不懂。这篇按「先对齐环境、再选安装路径、最后跑通并验证」的顺序给一份可执行清单。
先说清适用范围：这套流程适合想自己把推理服务跑在自己或租来的昇腾机器上的人。如果只是偶尔调一次模型、团队没有昇腾运维经验，或者对延迟敏感但没人做压测，直接走托管推理或调现成 API 更省事，不用硬啃环境。
动手前先确认四件事
这四件事任一没对齐，后面装什么都是白折腾。建议按顺序确认一遍，把结论记在纸上再动手，出问题时能快速判断是哪一层的锅。
- 卡型号与显存
- 用 npu-smi 类工具确认卡型、显存总量和健康状态；型号太老或显存偏小，别按标准方案估并发
- 驱动 / 固件 / CANN
- 三者版本要配套，不匹配是最常见的「装完了但一跑就崩」，装前记下当前版本再决定升还是就地适配
- 框架栈版本关系
- vllm-ascend 依赖特定版本的 vllm、torch、torch_npu，任一组件错位都会在 import 或首次推理时报错
- 使用形式
- 容器镜像、裸机 pip、云上预置环境三条路前提不同，先定路线再装东西
- 卡型与显存：不同昇腾卡支持的算子、并发差别很大，先确认再估容量
- 版本配套：驱动、固件、CANN 三者的对应关系去官方文档或镜像说明里对一遍
- 框架栈：vllm / torch / torch_npu 的版本关系错位，通常死在 import 阶段
- 使用形式：想快速验证走镜像；要长期跑、接业务代码走裸机；没机器就走平台预置
- 记录基线：把当前环境写成一个文本文件存好，出问题先 diff 这个文件
三条安装路线怎么选
选路线比装包本身更重要。选错了，后面改起来的成本远高于一开始就选对。下面这张对照表按「省事程度」和「可控程度」两个维度摆开。
| 路线 | 适合谁 | 代价 |
|---|---|---|
| 容器镜像 | 只想尽快验证能不能跑通 | 镜像大、下载慢，改源码或加自定义算子不灵活 |
| 裸机 pip | 要长期跑、接业务代码、改配置 | 环境变量、算子包、依赖冲突全得自己扛 |
| 平台预置 | 没自己机器、想按量试 | 先确认预置镜像的框架栈版本和预期是否一致 |
拿不准供给情况的话，先去 国产卡哪些是真能租到的（/compute/domestic） 和 算力从哪买（/compute/platforms） 对照一下，看清哪家给的是真卡、哪家只是转售，再决定是自建还是租。
- 先定路线按「要跑多久、要不要改代码」两个问题定；只跑一次选镜像，长期跑选裸机
- 再做最小环境不管哪条路，先装最小可运行集合，别一上来堆满依赖
- 跑通再扩展小模型小上下文跑通后，再换目标模型和目标量化档位
- 存好版本快照把这一版的包列表和环境变量存下来，后面升级出问题能回退
有些情况不适合自己折腾：只想偶尔调一次模型、团队没有昇腾运维经验、业务对延迟敏感但没人做压测。这几类优先考虑托管推理或直接调 API，把时间花在业务上更划算。
跑通之后先做的三项验证
「能出结果」不等于「能上线」。跑通之后必须做三件事，否则线上翻车时你会不知道是容量问题还是代码问题。
- 冒烟测试：小模型、小上下文、单请求跑一次完整生成，确认不报算子缺失
- 并发实测：按目标模型的量化档位和上下文长度，从 1 路逐步加压，记录显存占用与吞吐拐点
- 性能基线：首字延迟、单路吞吐、满载吞吐各测一轮，和之前用过的方案对齐口径
- 接口对齐：确认暴露的是 OpenAI 兼容协议还是自有格式，客户端接入前先对一遍
估并发别凭感觉。可以参考 一张卡能跑多少并发（/gpu-vram-concurrency-estimate） 和 部署测算（/models/deploy） 里的方法，把显存、上下文长度、量化档位三个变量代进去算，再拿实测校准。测延迟的方法借 接口测速（/tools/speed-test） 的记录习惯，别只凭一次体感下结论。
跑不起来时的排查顺序
报错看不懂时，按下面这个顺序往下走，从下往上查只会浪费时间。每一步都有明确的「过 / 不过」判断，别跳步。
- 查环境npu-smi 能否正常列出设备和显存；不能就先修驱动与设备可见性，别碰框架
- 查导入vllm、torch_npu 能否单独 import 成功；报依赖版本冲突就回安装路线那节重对齐版本
- 查算子报 unsupported op 多半是模型用了当前 CANN 还没支持的算子；换小模型或换量化档位验证
- 查资源进程被杀、卡在加载权重、跑到一半 OOM，按显存估算回查上下文长度、并发数、量化档位
- 查服务层本地跑得通但外部连不上，多半是监听地址、端口或反向代理问题，按本地网络排错思路查
如果排查到算子或卡型这一层发现确实不支持，别硬扛，回到前面的安装路线重选一次或者换卡型，比在错误的路线上继续调参省时间。卡型和显存的详细资料可以到 GPU / NPU 资料库（/gpu） 核对当时的数字，模型侧的依赖关系去 模型资料库（/models） 查。
下一步动手前先把卡型和已装版本记下来，装完跑一次冒烟测试再谈性能；测速和部署测算的口径以站内页面当时的数字为准，别拿旧印象估容量。→常见问题
没有昇腾卡，能先学 vllm-ascend 吗？
可以但收益有限。这套东西的坑大多在设备、驱动和算子层面，没有实卡就只能看文档，学到的部分和通用推理部署知识重叠。更划算的做法是先学通用的模型部署与显存估算，等真有卡再补昇腾特有的部分。
vllm-ascend 和直接用昇腾官方推理方案有什么区别？
主要差别在生态和接口。vllm-ascend 走的是 vllm 那套调度与 OpenAI 兼容接口，服务化和客户端接入选型更顺手；官方方案在自己算子与工具链上更完整。选哪个看你是要快速接业务，还是要吃满硬件特性，具体支持范围以你实际版本的文档为准，别照抄别人的结论。
装的时候版本到底怎么选？
不要凭「越新越好」拍板。先确认卡型和 CANN 版本，再按 vllm-ascend 对应版本的依赖说明反推 vllm、torch、torch_npu 的组合，整套一起装、一起验。单件升级最容易出现能 import 但一推理就崩的情况，升级前先把当前可用组合记下来。价格与规格相关的数字，去站内页面看当时的记录。
