大模型推理vllm多机多卡分布式本地部署

单机多卡跑得好好的，卡一多、机器一上两台就各种起不来：进程互相等、显存看着够却 OOM、日志里全是通信超时。这篇不讲原理课，只按运维的排查顺序走一遍多机多卡要盯的那几件事，外加一份上线前自检清单，帮你把「能跑」和「稳定跑」分开。

单机多卡能跑通，不代表多机多卡能跑稳。很多团队第一次上第二台机器，遇到的现象都差不多：进程互相等、显存看着够却 OOM、日志里刷通信超时。这三个现象背后往往不是模型问题，而是拓扑、并行度和启动参数没对齐。

下面按运维的排查顺序走一遍：先把拓扑和通信定死，再决定并行度怎么切，然后才是配参数起服务，最后用一份自检清单把「能跑」和「稳定跑」分开。每节都给出可执行动作，具体数字到站内对应页面核对当时的口径。

先定拓扑：几张卡、跨不跨机、走什么通信

动手改命令前先回答三个问题：一共几张卡、分在几台机器上、机间走哪张网卡。这三个答案不同，最优并行策略不一样，别照抄别人博客里的启动命令，那些命令的拓扑前提通常和你不同。

• 先用不带模型的通信自检过一遍，确认各节点能互相握手、网卡选对，再谈模型加载
• 机器数增加不等于吞吐线性增长，节点越多通信占比越高，先小规模验证再扩
• 每台机器加节点标识写日志，否则排错时判断不出是哪台先断的
• 国产卡或其他加速卡走各自的适配分支，路径和官方 GPU 版不一致，硬件口径先到站内算力与加速卡页面确认

并行度怎么切：TP、PP 与副本三条线的分工

并行度不是「一个数字」，而是三条线叠加：张量并行负责把单层权重摊到多卡，流水线并行按层切，数据并行/多副本负责扛并发。三条线混成一个数调，是新手最常见的坑。

张量并行（TP）

摊单层权重，对卡间通信最敏感，优先放在同一台机器内

流水线并行（PP）

按层切，跨机扩展友好，但段数越多单条请求延迟越难看

数据并行/多副本

抗并发，与上面两条是叠加关系，不是替代关系

1. 先看显存显存放得下就少切，切得越细通信开销越大，先试单机多卡能不能装下
2. 再定延迟还是吞吐延迟优先就少切且尽量不跨机；吞吐优先就多副本，把单条请求的切分压到最小
3. 最后跨机必须跨机时优先用流水线并行把层切开，而不是把张量并行分散到多台机器
4. 组合验证几种组合先用站内部署测算页面按模型和量化档位算一遍，再挑两三种上机实测

切法没有唯一答案。显存、并发、延迟容忍度三者互相拉扯，同一个模型在不同业务下最优组合可能完全不同。判断标准只有一条：拿你自己的流量压一遍，看延迟和吞吐曲线拐点在哪，而不是信别人给的倍数。

起服务：参数怎么配、日志怎么看

参数配置有个原则：先固定几项再调其余。模型路径、精度或量化档位、最大上下文长度、显存占用比例，这几项一动，前面推导的并行度就白算了，得重新来。

• 跨机场景把每个节点的日志都留存，带节点标识，否则判断不出谁先断
• 参数名和默认值不同版本有差异，写完先小流量跑通再上生产
• 别一次改多个参数，改一个跑一轮，否则出了问题是哪个引起的说不清
• 启动后第一件事是打一条最简单的请求，确认端到端链路通，再压并发

上线前自检：延迟、并发与回退

到这一步服务能起来了，但「能跑」和「稳定跑」是两件事。上线前至少量三组数：延迟基线、并发拐点、回退路径。这三组数缺一个，出故障时就没有参照。

1. 量延迟基线分别记单条请求的首 token 时间和出字速度，跨机前后的变化最能说明通信开销
2. 找并发拐点并发往上加，记录吞吐拐点和错误率拐点，两者先后顺序决定安全水位定在哪
3. 备回退路径单机小并发能否顶住、故障时切副本还是切 API，上线前想好而不是挂了再想
4. 留对照记录参数与拓扑做一份对照记录，换卡换节点数时照着改，比重新试一遍省时间

自检清单适用多数常规场景；如果你的业务有明显波峰波谷，或者对首 token 延迟极其敏感，压测方式要按真实流量分布来设计，不能只压恒定的并发数，否则测出来的拐点没有参考价值。