vllm-ascend多机多卡部署

单机单卡跑通 vLLM 之后，模型放不下或者并发顶不住，就得往多机多卡走。昇腾这一路和英伟达差别不小：卡间怎么互联、通信走什么协议、启动参数怎么写、镜像从哪来，都会直接决定你能不能跑起来。这篇按准备、组网、起服务、排查四步讲清配置逻辑和判断标准，具体版本号、显存余量和价格口径请到站内对应页面核对当时的数字。

单机单卡跑通 vLLM 之后，模型放不下或者并发顶不住，就得往多机多卡走。昇腾这一路和英伟达差别不小：卡间怎么互联、通信走什么协议、启动参数怎么写、镜像从哪来，都会直接决定你能不能跑起来。

这篇按准备、组网、起服务、排查四步讲清配置逻辑和判断标准。具体版本号、显存余量和价格口径请到站内对应页面核对当时的数字，别拿别人截图里的旧数字直接套。

开工前先确认四件事

多机部署失败，一大半原因不在配置本身，而在开工前的信息没对齐。先花二十分钟把这四件事确认清楚，比后面反复重启省时间。

• 驱动、固件、CANN 与 vllm-ascend 分支的版本要对齐，先到 /compute/gpus 查加速卡规格、到 /compute/domestic 看哪些国产卡真能租到，别在版本不匹配的机器上硬试
• 按模型参数量和量化档位反推需要几张卡：显存账用 /models/deploy 的部署测算页跑一遍，再看 /compute/sizing 对齐「几张卡够用」的口径
• 确认卡间互联方式，片内互联还是跨机走网络，这一步决定后面是单机多卡还是必须多机
• 明确你要的是高吞吐批处理还是低延迟在线服务，两者的并行切分策略不一样

组网与节点角色怎么定

多机场景下，节点角色和环境一致性是两件必须提前定死的事。角色混乱会导致通信初始化卡住，而环境不一致通常表现为「某台机器日志停在原地不动」。

1. 定主从节点指定一个节点当主节点，其余为工作节点，主节点负责集合通信的初始化。多机场景下所有节点必须能互相解析主机名或 IP，且对应端口要放通。
2. 统一环境变量统一各节点的卡可见范围、通信网卡、集合通信超时。任何一台不一致都会卡在初始化阶段不动。
3. 量跨机带宽机器间网络如果比卡间互联慢一个量级，张量并行跨机就会拖垮整体吞吐，这时更适合按机器切分流水并行。
4. 小规模连通性验证先用小模型或少量层做一次连通性验证，再上真模型，能省掉大量反复重启的时间。

起服务的参数与验证顺序

并行参数填错最常见的表现是显存看起来够但直接报错退出。张量并行度对应单机内的卡数，流水并行度对应机器数，两者相乘等于总卡数，先把这个乘法关系对上一遍再启动。

• 把并行配置、模型路径、量化方式、最大序列长度、显存占用比例写成一份启动脚本，多机场景下每台机器都要用同一份
• 服务起来后先做三件事：单条请求能不能回、并发上去吞吐是否线性增长、长输入是否触发显存溢出
• 吞吐和延迟的基线可以到 /tools/speed-test 量一遍再对比，别凭感觉说变快了
• 需要跑多家模型对比时，先到 /inference 看开源模型比价与部署口径，避免选了一个在这套硬件上适配很差的权重格式

# 示意：两台机器各若干卡，用同一份启动脚本
# 每台机器上先确认卡可见范围一致
ASCEND_RT_VISIBLE_DEVICES=0,1,2,3
# 主节点与工作节点的角色按各自脚本区分
# 并行度乘积需等于总卡数，启动前手算校验一次

卡住不动时按这个顺序排查

多机部署卡住，症状往往只有一句「没反应」。不要从改参数开始，按下面的顺序往下走，能最快定位到哪一环断了。

1. 看进程与初始化日志先看各节点进程是否都在、主节点有没有输出通信初始化日志。有一个节点起晚了，其余节点通常会一直等。
2. 查端口与网卡绑定容器里网卡名和宿主机不一致是多机部署的高频坑，确认通信用的网卡名在容器内可见。
3. 降配复现把显存与序列长度配置降到最小可用配置跑通，再逐项加回去，定位是哪一项越界。
4. 换权重格式验证确认是不是权重格式与当前 vllm-ascend 分支不兼容，换一个已适配的量化格式或权重来源，比继续调参更快见效。
5. 记录依赖对应关系镜像与依赖尽量用官方适配版本，自建环境时把 CANN、驱动、Python 依赖的对应关系记成一张表，下次复现能省事。

另外提醒一句：多机多卡能跑通不等于这套配置适合长期在线服务，节点越多、故障面越大。如果只是验证性用途，单机多卡往往更省心。