昇腾910B上 vLLM 推理部署：max-num-seqs 和 worldSize 配错，性能直接腰斩

在昇腾 910B 上部署一个大模型推理服务，第一版跑通的时候延迟尚可，但吞吐始终上不去，并发一拉高就出现显存 OOM 和请求排队。排查了一圈，问题不在模型本身，而在两个最容易被“照搬 NVIDIA 经验”害了的参数上：max-num-seqs 的并发上限和worldSize 与卡数的对齐。昇腾的显存管理、CANN 版本约束和并行语义与 CUDA 生态存在实质差异，参数调错不是“慢一点”，而是直接不可用。

一、 max-num-seqs：910B 上的甜点区间比想象中窄

在 vLLM 的通用文档里，max-num-seqs 可以设到几百，但在昇腾 910B（64GB）上，这个参数的安全区间明显收窄。实测和社区经验都指向 32~64 是比较稳妥的区间，超过这个范围，显存溢出（OOM）的概率急剧上升，而不是像在 A100/H100 上那样可以通过更大的显存来“硬扛”。显存溢出的后果也不只是报错——在 vLLM-Ascend 上，OOM 之后常常伴随显存碎片化，后续请求持续失败，重启容器是最快的恢复手段，而不是指望框架自己整理碎片。

因此调参顺序应该是：先把 max-num-seqs 压在 32 起步，确认稳定后再小幅上调，同时用 npu-smi 盯住显存水位，而不是照搬 CUDA 环境下的并发配置。

二、 worldSize 必须与 npuDeviceIds 严格一致，少一张卡就起不来

MindIE Service 的配置约束非常硬：worldSize 配了 8，npuDeviceIds 里就必须给满 8 张物理卡，少一张启动阶段直接失败。这个约束在昇腾上比在 GPU 集群上更严格，因为 CANN 的并行初始化在启动时就完成了卡数绑定，不像某些 CUDA 框架允许运行中做弹性调整。部署多卡推理时，先把 npuDeviceIds 的卡号列全，再让 worldSize 与之对齐，不要反过来“先写一个 worldSize 再看能不能凑够卡”。

三、 版本绑定：MindIE / CANN / 驱动的三角约束

MindIE 与 CANN、昇腾驱动/固件之间存在强绑定关系，同一个 MindIE 版本只适配特定范围的驱动和 CANN，三者不匹配时会直接报“加载算子失败”或“驱动接口不兼容”，而不是优雅降级。这意味着升级任何一个组件之前，必须先查对应版本的兼容矩阵，而不是像 pip 升级那样随手 pip install -U。稳妥的起点是使用官方提供的匹配 Docker 镜像，在镜像内部再调参数，避免在裸机上陷入依赖地狱。

四、 一个容易被忽略的性能拐点：参数不是越大越好

maxBatchSize 和 maxPrefillBatchSize 这类吞吐旋钮存在明确的拐点。把 batch 拉到极大，TTFT（首 token 延迟）会显著恶化，在线交互场景的用户体验反而下降；放在离线批处理里可能无所谓，但在客服或对话场景中，延迟和吞吐的权衡必须按业务 SLA 来定，而不是取参数上限。昇腾平台上的调优没有银弹，正确做法是先跑通 baseline，再逐项做消融，用数据决定每个参数的位置。

五、 总结

昇腾 910B 上的大模型推理部署，踩坑密度最高的三个位置是：max-num-seqs 按 CUDA 经验设得过大导致 OOM、worldSize 与卡数未对齐导致启动失败、MindIE/CANN/驱动版本三角不匹配导致算子报错。先把这三个硬约束对齐，再去调 batch 和并行策略，服务才具备基本的可用性。参数调优是第二步，版本和并行语义的对齐是第一步。