两台机器跑 vLLM这个问题我琢磨了很久。起因是我手上有两台 4×A100 80G 的服务器一套 32B 模型单机跑得动但并发一高就开始排队于是想着把第二台加进来两机合体。可一查资料几乎所有 vLLM 多机部署的教程开头第一句话就是先启动一个 Ray 集群。启动 Ray 不难难的是搞清楚两台机器的规模真的需要 Ray 吗什么时候引入它是划算的什么时候它反而是给自己找麻烦这篇文章就把我在实际部署中验证过的结论、翻过的车、以及一套可以照着做的判断思路完整写下来希望对正在做 vLLM 多机部署的人有帮助。1. 两台机器跑 vLLM先搞清楚你缺的到底是显存还是吞吐1.1 模型能不能塞进单机是第一个硬门槛先说一个最容易被我身边同事忽略的前提。所谓两台机器跑 vLLM有两种完全不同的含义第一种是模型在单机里根本塞不下必须把一张大模型切成多块放到两台机器上协同推理第二种是模型在单机里放得下但请求太多、并发吞吐不够想通过第二台机器分担压力。这两种情况的解法完全不一样而你是否需要 Ray恰恰取决于你属于哪一种。怎么判断很简单启动一次模型看显存。以我用过的 Qwen2.5-72B 为例FP16/BF16 权重差不多有 144GB。一台 4×A100 80G 的机器总共 320GB 显存光权重就吃掉接近一半再算上 KV Cache、CUDA context、激活值跑短上下文勉强可以一旦上下文变长KV Cache 直接撑爆。这种情况下模型在单机里属于能跑但不富余如果还要开长上下文两台机器并成 8 卡就是刚需。反过来Qwen2.5-32B 的权重大约 64GB4×A100 单机绰绰有余。你加第二台机器本质上是再起一个一模一样的实例而不是两台机器合体成一个更大的模型。很多教程一上来就教你怎么搭 Ray、怎么做跨机张量并行压根没问过你的模型是不是真的需要跨机。结果就是把一堆可以简单解决的问题复杂化了。1.2 并发瓶颈扩吞吐不一定要合体如果你的瓶颈是吞吐那我要给的第一个建议就是先别急着合体。单机单实例的 vLLM在并发请求上来之后吞吐量会受到两个因素限制模型推理本身的算力GPU 利用率以及单实例内部的调度器处理能力。加一台机器如果只是部署两个完全独立的实例通过负载均衡把请求分散到两边吞吐差不多是原来的两倍。这个方案不需要 Ray、不需要跨机通信、不需要张量并行两台机器之间甚至不需要高速互联各跑各的就行。我在测试环境里做过对比Qwen2.5-32B单实例跑 4 卡 A100给足并发后大概能到 3800 tokens/s 左右的总吞吐。部署两个独立实例加一个 round-robin 网关总吞吐直接拉到 7000 tokens/s几乎线性扩展。而如果非要把两个 4 卡机器用 Ray 搞成一个 TP8 的实例跨机通信的损耗会吃掉一部分收益实测可能只有 6000 上下还得多维护一套集群。这个结论很反直觉但事实就是两台机器场景下合体通常不解决吞吐问题反而引入通信损耗。只有显存才是合体的真正理由。理解了这一点接下来就好办了你需要的到底是扩容吞吐还是合并显存直接决定了后续技术和方案的取舍。2. vLLM 多机推理的底层逻辑Ray 在这里到底干了什么活2.1 单机多卡 vLLM 是怎么工作的TP NCCL 就够了要判断值不值得引入 Ray核心是先搞明白 vLLM 在多机推理时遇到的真实问题是什么。vLLM 单机多卡推理默认走张量并行Tensor ParallelTP。所谓 TP就是把一个模型按矩阵切块分到多张 GPU 上。比如一个 Transformer 层的 self-attentionQKV 的权重可以竖着切成 N 份每张卡各算一部分再用 all-reduce 把结果拼起来。这中间各张卡需要频繁交换中间结果所以对 GPU 之间的带宽极其敏感。这也是为什么单机多卡要强调 NVLink——NVLink 的带宽是 600GB/s 级别而普通万兆网卡只有 1.25GB/s差距是三个数量级。vLLM 在单机多卡场景下用的是multiproc执行后端每个 GPU 对应一个 worker 进程进程之间通过 NCCL 通信。同一台机器内通信走 NVLink/PCIe速度快、延迟低。调度器scheduler决定一批请求进入当前 stepexecutor 把计算任务派发给各 workerworker 之间用 NCCL 做张量并行同步。这个过程里完全没有 Ray 什么事。因为进程都在同一台机器上不需要跨节点的服务发现也不需要外部调度器来管理谁在哪张卡上跑。只要显存够、单机能跑就不要给这个干净的系统引入多余组件。2.2 跨机器时突然多出来的调度层换成两台机器协同跑同一个模型情况就变了。假设你决定让两台 4×A100 的机器并成一个 TP8 的实例这时候有 8 个 worker 分布在两台物理机上。vLLM 的 driver 进程EngineCore需要知道每个 worker 分布在哪台机器上、哪个 IP、哪张 GPU、资源够不够当某个 worker 挂掉时要不要重启、如何在剩余节点上重新拉起。这些能力恰恰是 Ray 的核心功能。简单说Ray 在这里扮演的是调度台进程管家。它包括一个 head 节点相当于指挥中心和若干 worker 节点。head 节点上运行着 GCSGlobal Control Service和调度器负责维护集群状态、分配资源、发布任务。vLLM 把每个 GPU worker 封装成 Ray Actor由 Ray 跨节点拉起启动完成后真正的 tensor 数据交换走的是 NCCLRay 不参与逐 token 的数据搬运。所以一个很关键的理解是Ray 管的是谁在哪张卡上干活不是数据怎么在卡之间流动。数据交换是 NCCL 的事Ray 更像是一个资源编排与进程生命周期管理框架。这也是为什么说引入 Ray更多是在引入一套调度基础设施而不是为 vLLM 增加专门的推理能力。2.3 vLLM 和 Ray 的关系其实是默认搭档vLLM 对 Ray 的依赖在不同阶段是变化的。早期版本做多机推理Ray 几乎是唯一的路。后来的版本大约 0.6.6 之后引入了external-launcher执行后端允许你通过 Slurm、Kubernetes 这类外部工具自己拉起多机 worker不再强制要求 Ray。但直到我写这篇文章的版本官方文档里多机部署最省事、资料最多的路径依然是 Ray。这意味着一个微妙的事实对绝大多数人来说当模型真的需要跨机 TP 时用 Ray和不用 Ray不是一个自由选择题——vLLM 默认帮你在多机场景下依赖 Ray 的工作流。你更多需要考虑的是我的模型是不是真的到了必须跨机这一步如果没到就别让 Ray 进你的架构。另外要注意的是vLLM 的 EngineCore 调度逻辑分为 scheduler 和 executor 两段。scheduler 负责 KV Cache 管理、请求准入、preemption 决策executor 负责把当前 step 的计算发到各 worker。多机场景下 scheduler 仍只跑在 driver 进程里executor 则会把任务分发到由 Ray 管理的远端 worker 上。理解这条链路的重点在于当你想排查一个多机部署的性能问题时scheduler 层的排队和 executor 层的通信阻塞要分开看否则很容易把 Ray 的调度开销误判成模型推理本身的瓶颈。3. 两台机器规模下不引入 Ray的替代方案同样能解决问题3.1 方案 A双实例 网关负载均衡先说一个被很多人低估的方案也是我在两台机器场景下用得最多的方案两个独立的 vLLM 服务前面挂一个负载均衡入口。具体做法很简单。两台机器分别用 Docker 部署 vLLM OpenAI 兼容服务各加载同一份模型权重模型文件放在共享存储或各自本地都行然后在前端放一个 Nginx配 round-robin 把/v1/chat/completions的请求分发到两个上游。Nginx 配置核心部分长这样upstream vllm_backend { server 192.168.1.10:8000 max_fails2 fail_timeout10s; server 192.168.1.11:8000 max_fails2 fail_timeout10s; } server { listen 80; location / { proxy_pass http://vllm_backend; proxy_http_version 1.1; proxy_set_header Connection ; proxy_set_header Host $host; proxy_http_version 1.1; proxy_buffering off; } }两个实例各自维护自己的 KV Cache互不干扰。请求来了谁空闲谁处理。这个方案的好处是部署简单不引入任何新的分布式框架出了问题只需排查单机。故障域隔离一台机器宕机另一台继续服务Nginx 会自动摘掉故障节点。横向扩展自然以后从两台加到三台、四台只要在 upstream 里加一行服务器地址。我一直坚持一个观点如果每个实例都能完整放下模型那多实例负载均衡是远比跨机 TP稳定、高效的方案。跨机 TP 引入的通信依赖、调度耦合在这个场景下纯属自找麻烦。3.2 方案 B多模型按需拆分而不是按张量切分另一种常见需求是机器上要跑的不止一个模型而是多个模型比如一个对话模型、一个 Embedding 模型、还有一个 Rerank 模型。这时候的根本问题是所有模型加起来超出了单机显存但单个模型没那么大。很多人想到的第一件事是把一堆模型塞进一个 Ray 集群统一管理这是 Ray 官方很喜欢的演示场景但在只有两台机器的情况下未必划算。更务实的做法是按模型拆机器比如机器 A 跑对话模型的主服务机器 B 跑 Embedding 和 Rerank 等轻量服务。vLLM 支持在同一个进程内并发加载多个模型但显存池是共享的模型之间会互相挤占。独立实例的好处是显存边界清晰一个模型把显存吃满了不会拖垮另一个模型。如果某些模型的并发量很低完全不用在意复用 GPU 显存这件事因为空着就空着换来的是稳定性。只有当单机显存真的放不下某一个大模型时跨机切分才成为必选项。而多模型场景的另一个解法是配置多个 vLLM 实例按端口区分再由网关按 API 路径路由到不同后端这个思路和 3.1 的负载均衡是一致的只是路由规则从按请求数变成按模型名。3.3 这些方案的边界什么时候撑不住当然双实例负载均衡不是万能的。它有两个很明显的边界第一同一个模型的两个实例各自持有完整权重意味着显存占用翻倍。如果你的模型单机刚好塞满两个实例就没地方放了更极端的情况是显存本来就不够你压根没法部署第二个实例来扩容吞吐。第二如果你的业务需要所有请求共享同一份 KV Cache来提升命中率双实例是做不到的。不过对于对话、生成类场景KV Cache 本来就是按请求隔离的不存在跨请求共享收益。这条边界更多适用于检索增强类场景比如把大段文档的 KV Cache 常驻在显存中多机拆分后每个节点缓存不同文档块请求按需路由。这种场景属于少数派不是一般对话服务该考虑的事。所以替代方案的核心价值是让架构保持简单。不是为了炫技去上分布式框架而是用最小可行方案把业务跑通。只有当简单方案真的顶不住时才考虑下一步。4. 什么时候才值得引入 Ray三个可复现的判断信号4.1 信号一单个模型必须跨机张量并行最直接、也最正当的引入理由是单机显存放不下这个模型必须用到两台机器的全部 GPU 来跑一个 TP 实例。举个例子用两台 4×A100 80G 的机器跑 DeepSeek-R1 的蒸馏版本也好、跑 70B~100B 级别的开源模型也罢如果权重加 KV Cache 后超过单机 320GB那就不得不两机 TP。此时每个 worker 上的模型分片是单机上不可独立部署的跨机同步就成了刚需。具体到 vLLM 启动命令大致是这样# 假设 head 节点 IP 是 192.168.1.10 # 节点 1head ray start --head --port6379 --num-gpus4 # 节点 2worker ray start --address192.168.1.10:6379 --num-gpus4 # 在 head 节点启动 vLLMTP8 跨两台机器 python -m vllm.entrypoints.openai.api_server \ --model /models/Qwen2.5-72B-Instruct \ --tensor-parallel-size 8 \ --distributed-executor-backend ray \ --host 0.0.0.0 \ --port 8000注意--tensor-parallel-size 8意思是模型被切到 8 张卡上vLLM 发现 Ray 集群有 8 张可用 GPU会把 8 个 worker actor 分布到两台机器上。这个场景里 Ray 不只是可选项而是 vLLM 多机部署链条里不可缺的一环。这里有一个判断技巧看模型中 不可能被压缩 的部分。比如 FP16 权重是硬需求不管量化与否总有个下限KV Cache 跟上下文长度成正比越长越吃显存。把这些算清楚如果单机 A100 的量级明显不够跨机 TP 就是唯一出路Ray 也就没有值不值得的问题。4.2 信号二你需要跨节点的弹性资源和动态调度第二个信号是当稳定性和资源弹性成为硬需求时。两台机器虽然数量少但如果你在跑的生产服务要求任何一台机器崩了任务自动迁移到另一台而且不能手动重启那 Ray 的资源调度和自动重启能力就有价值。Ray 会监测 worker actor 的健康状态发现 GPU worker 挂了按告警策略重新调度。这个能力与 GPU 数量是否跨机没有必然关系但结合跨机模型分片后自动恢复就变得极具吸引力。另外如果你不只是跑 vLLM还在同一批机器上跑若干数据预处理、Embedding 批量计算、模型微调任务需要一个统一的资源调度层来动态分配 GPURay 可以承担这个角色。此时它的价值不是服务一个模型而是集群编排。判断信号很简单你这个环境里除了 vLLM 之外是否还有别的GPU 任务需要跑如果有而且它们会动态增减那 Ray 的统一调度值得投入如果这两台机器只跑一个 vLLM其他什么也不干那引入 Ray 就是在为一个非问题创造解法。4.3 信号三你的模型服务不只是一条直线第三个信号更隐蔽当推理链路里不止一个模型且它们之间有复杂的依赖关系时。在 RAG 类业务中一个请求会依次经过 Embedding 模型、Rerank 模型、生成模型在 Agent 类业务中还会按需调用多个不同大小的模型。vLLM 0.6 之后支持多模型并发加载但显存是共享池多个模型塞在同一个上下文里会互相影响 KV Cache、影响调度决策。这种场景下Ray 的价值在于你可以把不同模型分别部署为独立的 Ray Serving 应用并利用 Ray 的部署组把它们编排在一起模型间的调用由 Ray 统一路由。不过说句实话在只有两三台机器的时候用网关做服务编排往往比 Ray Serve 更轻、更可控。Ray 的这个价值要等到模型数量多、调用拓扑复杂之后才真正显现。我个人的底线判断是满足三条信号里至少一条以上Ray 才值得引入。只有一条且是可以绕开的那种比如弹性调度可以手动维护那还是踏踏实实用双实例方案更好。4.4 一个关键时间点网络带宽决定跨机 TP 值不值无论前三个信号怎么强烈还有一个被忽略的硬条件你的两台机器之间的网络带宽到底够不够。跨机张量并行每层 Transformer 计算完都要做 all-reduce数据量极其惊人。以 72B 模型、TP8 为例单次 all-reduce 需要同步的量就有数百 MB 到 GB 级别而且一个 batch 里会有很多层要做同步。如果用千兆网1GbE这个方案会慢到不可用万兆10GbE勉强能跑25GbE/40GbE 才算基本合格。我的实测数据是两台 A100 之间通过 25GbE 组网跨机 TP 的吞吐只有单机 NVLink 方案的 75% 到 85%延迟也会增加 10ms 左右。如果你用的还是千兆交换机那跨机 TP 纯属折磨。所以判断是否值得引入 Ray之前先量一量 netperf 的带宽。如果单机内 NVLink 互通没问题、两机网络带宽拉胯那就算模型放不下跨机 TP 也不是好选择。5. 实测同一组模型三种部署方式的性能与体验对比5.1 测试环境与基准配置为了把上面的判断落到数据上我在自己的测试环境做了一组对比。环境如下机器 A / B各 4×A100 80GNVLink 互联CPU 64 核内存 512GB两机间网络25GbE 网卡直连软件版本vLLM 0.8.4V1 引擎、Ray 2.31.0模型 1Qwen2.5-32B-Instruct单机 4 卡可跑模型 2Qwen2.5-72B-Instruct单机 4 卡可跑但 KV 余量不足单机 8 卡不现实因为只有 4 卡/机测试用一段固定 prompt平均 1200 tokens 输入请求并发 32输出长度限制 512 tokens统计总吞吐与 TTFT。5.2 场景 A32B 模型双实例 vs 单机单实例第一组对比解决的是吞吐瓶颈值不值得用 Ray 的问题。三个配置配置 1单机 4 卡 TP4单实例配置 2两机各启动一个 TP4 实例前面挂 Nginx 负载均衡配置 3两机 8 卡 TP8vLLM Ray 合体实例结果大致如下为了便于复现趋势数据做了取整部署方式总吞吐 (tokens/s)TTFT (ms)备注单机 4 卡3800350基准两机双实例 Nginx7100360约 1.87 倍线性扩展两机 TP8 Ray5900420跨机通信损耗明显这个结果很有代表性当模型不需要跨机时双实例负载均衡的吞吐遥遥领先因为它把两张机器的算力都榨干了而且没有跨机同步的额外开销。反过来两机 TP8 因为每层 Transformer 都要跨 25GbE 网做 all-reduce吞吐只剩单机 1.55 倍TTFT 还涨了 20%。所以看到这里可以下一个明确结论如果你的瓶颈是吞吐模型单机放得下不要用 Ray。双实例网关就是最优解。5.3 场景 B72B 模型跨机 TP 跑起来的实际表现第二组直接测试跨机 TP 的极限。Qwen2.5-72B 在单台 4×A100 上能加载权重但一旦把 max-model-len 拉到 64KKV Cache 显存就顶不住。为了跑长上下文只能两机 8 卡 TP。配置配置 4单机 4 卡 TP4短上下文max-token 8192配置 5两机 8 卡 TP8 Ray长上下文max-token 65536模型可稳定运行短上下文下配置 4 和配置 5 都能跑吞吐对比如下部署方式单请求吞吐 (tokens/s)并发 16 总吞吐显存峰值单机 4 卡 TP48202100283GB两机 8 卡 TP8 Ray7301900316GB跨机 TP 在短上下文时不仅没有优势还因为通信损耗导致单请求吞吐下降约 11%。但一旦把 max-model-len 拉到 64K配置 4 直接 OOM 起不来只有配置 5 能扛住。这时候 Ray 引入的价值就不应该在性能对比表里找而应该在能不能提供服务这件事上体现。5.4 数字背后的结论先看功能再看性能把这两组测试放一起可以提炼出几个很干脆的原则单机放得下的模型用双实例别碰 Ray。功能完全一样性能更好故障面更小。单机放不下但网络带宽足够的模型用 Ray 跨机 TP。它是你唯一能走的可靠路径。网络带宽不够的模型跨机 TP 跑起来的体验很差要么加网络设备要么降级换小模型/更多量化。另外提醒一点对比性能时一定要固定模型和请求长度再比。不同 max-model-len 下显存分配策略完全不同KV Cache 预留多少直接影响并发度和吞吐。我之前就见过有人拿 4K 上下文和 32K 上下文的配置比吞吐结果得出一堆自相矛盾的结论浪费时间。还有一个值得注意的问题版本升级对吞吐的影响。vLLM 同一模型不同镜像版本的吞吐差距可以超过 15%官方发新版时性能波动是常态。因此做对比测试时最好固定镜像版本避免把版本差异误判成架构差异。6. 引入 Ray 的部署步骤与排坑记录6.1 vLLM Ray 的最小化部署流程如果前面的判断都指向需要引入 Ray这里给一套我反复跑通过的最小化流程适用于两台 A100 机器。第一步在两台机器上装好 Docker 与 NVIDIA 驱动确认nvidia-smi正常。第二步分别启动 Ray 集群。head 节点命令ray start --head --port6379 --num-gpus4 --include-dashboardtrueworker 节点命令ray start --address192.168.1.10:6379 --num-gpus4注意--num-gpus必须显式写否则 Ray 不会上报 GPU 资源vLLM 在调度 worker 时会报 0 张可用 GPU。第三步在 head 节点的容器里启动 vLLM。官方镜像通常自带匹配的 Ray 版本如果用vllm/vllm-openai镜像需要注意容器内启动 Ray 时要把头节点的 6379 端口暴露出来docker run -d \ --gpus all \ --shm-size32g \ --ipchost \ --network host \ -v /models:/models \ -e RAY_ADDRESS192.168.1.10:6379 \ vllm/vllm-openai:v0.8.4 \ python -m vllm.entrypoints.openai.api_server \ --model /models/Qwen2.5-72B-Instruct \ --tensor-parallel-size 8 \ --distributed-executor-backend ray容器里启动 vLLM 时会自动连接到本机已有的 Ray 集群。这里我强烈建议用--network host避免容器网络转发增加额外延迟和 NAT 端口映射难题。6.2 排坑一Ray 版本与 vLLM 版本错位多机部署最容易踩的坑是 Ray 和 vLLM 的版本不匹配。vLLM 官方 Docker 镜像里固化了配套的 Ray 版本但很多人喜欢在容器里再pip install ray装最新版或者在一个裸 Python 环境手动装两个包结果导入时报一些奇怪错误比如RayActorError、object_ref相关性报错。我的建议是优先使用官方 vLLM 镜像自带的 Ray不要手动升级。如果必须自定义环境就用 pip 精确锁定版本。以 vLLM 0.8.x 为例官方要求 Ray 2.30但你去装一个 2.40 甚至更新的版本反而可能触发兼容问题。稳妥的做法是先安装 vLLM让它把依赖解析好再检查pip show ray的版本。另外vLLM 不同版本对--distributed-executor-backend的默认值有差异。早期版本默认 ray后期版本默认可能是 external-launcher 或 multiproc。多机场景下如果忘了显式传ray可能启动时会提示找不到足够的单机 GPU或者干脆报only one GPU detected之类的问题。6.3 排坑二跨机 NCCL 通信超时与网络配置跨机 TP 跑起来最典型的故障是NCCL timeout或者all-reduce卡住不动。大部分情况下不是 vLLM 的问题而是 NCCL 选错了网络接口。多机通信时NCCL 需要找到正确的网卡。如果你的机器有多个网口比如一个 1GbE 的管理网口一个 25GbE 的数据网口NCCL 很可能选到慢的那个表现为TP 初始化极慢、单请求延迟极高、偶尔报超时。解决方案是显式指定export NCCL_SOCKET_IFNAMEeth1 export NCCL_IB_DISABLE1 export NCCL_DEBUGINFONCCL_DEBUGINFO在排查问题阶段一定要开它能打印出 NCCL 实际用了哪个网卡、哪条路径省去很多猜测。另外如果用的是 RoCE/InfiniBand还要额外配置NCCL_IB_*参数这里不展开但思路一样先 debug看清楚它走的是哪条路。超时问题也很常见。在压力测试时如果请求并发过大跨机同步可能出现 NCCL 超时。合理设置export NCCL_ASYNC_ERROR_HANDLING1 export NCCL_SHM_DISABLE1 # 跨机场景下共享内存同步容易踩坑如果你的机器内存不足、/dev/shm太小还需要在容器里加--shm-size32g否则 Ray/NCCL 在共享内存上会频繁报错。6.4 排坑三head 节点成为新瓶颈Ray 集群的 head 节点负责所有调度决策、对象存储、状态同步。在只有两台机器时head 节点通常跑在其中一台业务机器上这本身没问题但要注意 head 节点所在机器的资源占用。有一个容易忽略的点head 节点会占用不小的内存Ray 各处的心跳、对象元数据、日志都会集中写到这里。如果你跑的是高并发推理vLLM 的请求处理本身会占用 CPU 和内存head 节点的进程再叠加进来偶尔会出现调度延迟抖动。我的习惯是把 head 节点放在负载较轻的那台机器上并在启动时限制 Ray 的内存占用ray start --head --port6379 --num-gpus4 --memory53687091200 # 50GB同时可以在vllm serve时加上--ray-num-cpus之类的参数限制 vLLM worker 占用的 CPU 数防止它把 head 调度的 CPU 抢光。这两步在只有两台机器时足够用了能明显降低系统抖动的概率。6.5 排坑四镜像版本与模型封装问题最后补充一个和模型文件相关的坑。多机部署时两台机器都要能访问同一份模型权重。如果你用的是普通磁盘每台机器单独下载一份最省事如果模型很大共享存储NFS、NAS是常见选择但要特别注意 NFS 到两机的带宽。还有一个细节vLLM 镜像本身不包含模型文件只包含推理引擎。所以别想着挂载一个模型进去就能跑得先把权重放到所有节点可见的路径。热门前像 glm5、deepseek 这类模型的权重动辄几百 GB如果只有一台机器能访问文件另一台从 NFS 读取时网络很容易成为瓶颈。这类问题排查起来很隐蔽表现出来是启动阶段卡在 loading model但实际是远端权重文件读太慢。关于挑镜像版本我的经验是固定大版本不追最新。热门模型通常会在社区讨论出比较稳定的 vLLM 镜像版本但我个人不建议直接上刚发布的小版本因为 vLLM 新版本的性能回归问题不是一次两次了。我的习惯是确认使用的模型和上下文长度再回看官方 release notes只要我用到的特性没有改动就不升版本。这样可以避免把vLLM 新版本性能下降的锅甩到 Ray 身上。最后说一个我自己判断多机方案的笨办法每次要不要上 Ray我都会把问题简化成一个清单模型能不能在单机内装下装得下默认不碰 Ray。如果只是吞吐不够优先加独立实例配一个负载均衡网关。只有显存真的不够、且两机网络带宽不低于 25GbE 时才启动 Ray 做跨机 TP。如果网络带宽低于 10GbE我会先尝试量化或换小模型而不是硬上跨机。这套办法看起来很保守但帮我避免了好几次无意义的架构升级。Ray 本身是个优秀的工具但它有它的适用面做大集群、做弹性调度、做多任务混跑。两台机器、一个 vLLM 服务的场景绝大多数时候不需要跳到集群这个维度去思考问题。把模型能不能装下、瓶颈在显存还是吞吐、网络够不够快这三个问题回答清楚该不该引入 Ray答案其实已经写在问题里了。 
长河君 · 2026/11/4 4:34:00 · 阅读 1.2k vLLM多机部署：两台机器要不要用Ray？看显存、吞吐与网络带宽
两台机器跑 vLLM这个问题我琢磨了很久。起因是我手上有两台 4×A100 80G 的服务器一套 32B 模型单机跑得动但并发一高就开始排队于是想着把第二台加进来两机合体。可一查资料几乎所有 vLLM 多机部署的教程开头第一句话就是先启动一个 Ray 集群。启动 Ray 不难难的是搞清楚两台机器的规模真的需要 Ray 吗什么时候引入它是划算的什么时候它反而是给自己找麻烦这篇文章就把我在实际部署中验证过的结论、翻过的车、以及一套可以照着做的判断思路完整写下来希望对正在做 vLLM 多机部署的人有帮助。1. 两台机器跑 vLLM先搞清楚你缺的到底是显存还是吞吐1.1 模型能不能塞进单机是第一个硬门槛先说一个最容易被我身边同事忽略的前提。所谓两台机器跑 vLLM有两种完全不同的含义第一种是模型在单机里根本塞不下必须把一张大模型切成多块放到两台机器上协同推理第二种是模型在单机里放得下但请求太多、并发吞吐不够想通过第二台机器分担压力。这两种情况的解法完全不一样而你是否需要 Ray恰恰取决于你属于哪一种。怎么判断很简单启动一次模型看显存。以我用过的 Qwen2.5-72B 为例FP16/BF16 权重差不多有 144GB。一台 4×A100 80G 的机器总共 320GB 显存光权重就吃掉接近一半再算上 KV Cache、CUDA context、激活值跑短上下文勉强可以一旦上下文变长KV Cache 直接撑爆。这种情况下模型在单机里属于能跑但不富余如果还要开长上下文两台机器并成 8 卡就是刚需。反过来Qwen2.5-32B 的权重大约 64GB4×A100 单机绰绰有余。你加第二台机器本质上是再起一个一模一样的实例而不是两台机器合体成一个更大的模型。很多教程一上来就教你怎么搭 Ray、怎么做跨机张量并行压根没问过你的模型是不是真的需要跨机。结果就是把一堆可以简单解决的问题复杂化了。1.2 并发瓶颈扩吞吐不一定要合体如果你的瓶颈是吞吐那我要给的第一个建议就是先别急着合体。单机单实例的 vLLM在并发请求上来之后吞吐量会受到两个因素限制模型推理本身的算力GPU 利用率以及单实例内部的调度器处理能力。加一台机器如果只是部署两个完全独立的实例通过负载均衡把请求分散到两边吞吐差不多是原来的两倍。这个方案不需要 Ray、不需要跨机通信、不需要张量并行两台机器之间甚至不需要高速互联各跑各的就行。我在测试环境里做过对比Qwen2.5-32B单实例跑 4 卡 A100给足并发后大概能到 3800 tokens/s 左右的总吞吐。部署两个独立实例加一个 round-robin 网关总吞吐直接拉到 7000 tokens/s几乎线性扩展。而如果非要把两个 4 卡机器用 Ray 搞成一个 TP8 的实例跨机通信的损耗会吃掉一部分收益实测可能只有 6000 上下还得多维护一套集群。这个结论很反直觉但事实就是两台机器场景下合体通常不解决吞吐问题反而引入通信损耗。只有显存才是合体的真正理由。理解了这一点接下来就好办了你需要的到底是扩容吞吐还是合并显存直接决定了后续技术和方案的取舍。2. vLLM 多机推理的底层逻辑Ray 在这里到底干了什么活2.1 单机多卡 vLLM 是怎么工作的TP NCCL 就够了要判断值不值得引入 Ray核心是先搞明白 vLLM 在多机推理时遇到的真实问题是什么。vLLM 单机多卡推理默认走张量并行Tensor ParallelTP。所谓 TP就是把一个模型按矩阵切块分到多张 GPU 上。比如一个 Transformer 层的 self-attentionQKV 的权重可以竖着切成 N 份每张卡各算一部分再用 all-reduce 把结果拼起来。这中间各张卡需要频繁交换中间结果所以对 GPU 之间的带宽极其敏感。这也是为什么单机多卡要强调 NVLink——NVLink 的带宽是 600GB/s 级别而普通万兆网卡只有 1.25GB/s差距是三个数量级。vLLM 在单机多卡场景下用的是multiproc执行后端每个 GPU 对应一个 worker 进程进程之间通过 NCCL 通信。同一台机器内通信走 NVLink/PCIe速度快、延迟低。调度器scheduler决定一批请求进入当前 stepexecutor 把计算任务派发给各 workerworker 之间用 NCCL 做张量并行同步。这个过程里完全没有 Ray 什么事。因为进程都在同一台机器上不需要跨节点的服务发现也不需要外部调度器来管理谁在哪张卡上跑。只要显存够、单机能跑就不要给这个干净的系统引入多余组件。2.2 跨机器时突然多出来的调度层换成两台机器协同跑同一个模型情况就变了。假设你决定让两台 4×A100 的机器并成一个 TP8 的实例这时候有 8 个 worker 分布在两台物理机上。vLLM 的 driver 进程EngineCore需要知道每个 worker 分布在哪台机器上、哪个 IP、哪张 GPU、资源够不够当某个 worker 挂掉时要不要重启、如何在剩余节点上重新拉起。这些能力恰恰是 Ray 的核心功能。简单说Ray 在这里扮演的是调度台进程管家。它包括一个 head 节点相当于指挥中心和若干 worker 节点。head 节点上运行着 GCSGlobal Control Service和调度器负责维护集群状态、分配资源、发布任务。vLLM 把每个 GPU worker 封装成 Ray Actor由 Ray 跨节点拉起启动完成后真正的 tensor 数据交换走的是 NCCLRay 不参与逐 token 的数据搬运。所以一个很关键的理解是Ray 管的是谁在哪张卡上干活不是数据怎么在卡之间流动。数据交换是 NCCL 的事Ray 更像是一个资源编排与进程生命周期管理框架。这也是为什么说引入 Ray更多是在引入一套调度基础设施而不是为 vLLM 增加专门的推理能力。2.3 vLLM 和 Ray 的关系其实是默认搭档vLLM 对 Ray 的依赖在不同阶段是变化的。早期版本做多机推理Ray 几乎是唯一的路。后来的版本大约 0.6.6 之后引入了external-launcher执行后端允许你通过 Slurm、Kubernetes 这类外部工具自己拉起多机 worker不再强制要求 Ray。但直到我写这篇文章的版本官方文档里多机部署最省事、资料最多的路径依然是 Ray。这意味着一个微妙的事实对绝大多数人来说当模型真的需要跨机 TP 时用 Ray和不用 Ray不是一个自由选择题——vLLM 默认帮你在多机场景下依赖 Ray 的工作流。你更多需要考虑的是我的模型是不是真的到了必须跨机这一步如果没到就别让 Ray 进你的架构。另外要注意的是vLLM 的 EngineCore 调度逻辑分为 scheduler 和 executor 两段。scheduler 负责 KV Cache 管理、请求准入、preemption 决策executor 负责把当前 step 的计算发到各 worker。多机场景下 scheduler 仍只跑在 driver 进程里executor 则会把任务分发到由 Ray 管理的远端 worker 上。理解这条链路的重点在于当你想排查一个多机部署的性能问题时scheduler 层的排队和 executor 层的通信阻塞要分开看否则很容易把 Ray 的调度开销误判成模型推理本身的瓶颈。3. 两台机器规模下不引入 Ray的替代方案同样能解决问题3.1 方案 A双实例 网关负载均衡先说一个被很多人低估的方案也是我在两台机器场景下用得最多的方案两个独立的 vLLM 服务前面挂一个负载均衡入口。具体做法很简单。两台机器分别用 Docker 部署 vLLM OpenAI 兼容服务各加载同一份模型权重模型文件放在共享存储或各自本地都行然后在前端放一个 Nginx配 round-robin 把/v1/chat/completions的请求分发到两个上游。Nginx 配置核心部分长这样upstream vllm_backend { server 192.168.1.10:8000 max_fails2 fail_timeout10s; server 192.168.1.11:8000 max_fails2 fail_timeout10s; } server { listen 80; location / { proxy_pass http://vllm_backend; proxy_http_version 1.1; proxy_set_header Connection ; proxy_set_header Host $host; proxy_http_version 1.1; proxy_buffering off; } }两个实例各自维护自己的 KV Cache互不干扰。请求来了谁空闲谁处理。这个方案的好处是部署简单不引入任何新的分布式框架出了问题只需排查单机。故障域隔离一台机器宕机另一台继续服务Nginx 会自动摘掉故障节点。横向扩展自然以后从两台加到三台、四台只要在 upstream 里加一行服务器地址。我一直坚持一个观点如果每个实例都能完整放下模型那多实例负载均衡是远比跨机 TP稳定、高效的方案。跨机 TP 引入的通信依赖、调度耦合在这个场景下纯属自找麻烦。3.2 方案 B多模型按需拆分而不是按张量切分另一种常见需求是机器上要跑的不止一个模型而是多个模型比如一个对话模型、一个 Embedding 模型、还有一个 Rerank 模型。这时候的根本问题是所有模型加起来超出了单机显存但单个模型没那么大。很多人想到的第一件事是把一堆模型塞进一个 Ray 集群统一管理这是 Ray 官方很喜欢的演示场景但在只有两台机器的情况下未必划算。更务实的做法是按模型拆机器比如机器 A 跑对话模型的主服务机器 B 跑 Embedding 和 Rerank 等轻量服务。vLLM 支持在同一个进程内并发加载多个模型但显存池是共享的模型之间会互相挤占。独立实例的好处是显存边界清晰一个模型把显存吃满了不会拖垮另一个模型。如果某些模型的并发量很低完全不用在意复用 GPU 显存这件事因为空着就空着换来的是稳定性。只有当单机显存真的放不下某一个大模型时跨机切分才成为必选项。而多模型场景的另一个解法是配置多个 vLLM 实例按端口区分再由网关按 API 路径路由到不同后端这个思路和 3.1 的负载均衡是一致的只是路由规则从按请求数变成按模型名。3.3 这些方案的边界什么时候撑不住当然双实例负载均衡不是万能的。它有两个很明显的边界第一同一个模型的两个实例各自持有完整权重意味着显存占用翻倍。如果你的模型单机刚好塞满两个实例就没地方放了更极端的情况是显存本来就不够你压根没法部署第二个实例来扩容吞吐。第二如果你的业务需要所有请求共享同一份 KV Cache来提升命中率双实例是做不到的。不过对于对话、生成类场景KV Cache 本来就是按请求隔离的不存在跨请求共享收益。这条边界更多适用于检索增强类场景比如把大段文档的 KV Cache 常驻在显存中多机拆分后每个节点缓存不同文档块请求按需路由。这种场景属于少数派不是一般对话服务该考虑的事。所以替代方案的核心价值是让架构保持简单。不是为了炫技去上分布式框架而是用最小可行方案把业务跑通。只有当简单方案真的顶不住时才考虑下一步。4. 什么时候才值得引入 Ray三个可复现的判断信号4.1 信号一单个模型必须跨机张量并行最直接、也最正当的引入理由是单机显存放不下这个模型必须用到两台机器的全部 GPU 来跑一个 TP 实例。举个例子用两台 4×A100 80G 的机器跑 DeepSeek-R1 的蒸馏版本也好、跑 70B~100B 级别的开源模型也罢如果权重加 KV Cache 后超过单机 320GB那就不得不两机 TP。此时每个 worker 上的模型分片是单机上不可独立部署的跨机同步就成了刚需。具体到 vLLM 启动命令大致是这样# 假设 head 节点 IP 是 192.168.1.10 # 节点 1head ray start --head --port6379 --num-gpus4 # 节点 2worker ray start --address192.168.1.10:6379 --num-gpus4 # 在 head 节点启动 vLLMTP8 跨两台机器 python -m vllm.entrypoints.openai.api_server \ --model /models/Qwen2.5-72B-Instruct \ --tensor-parallel-size 8 \ --distributed-executor-backend ray \ --host 0.0.0.0 \ --port 8000注意--tensor-parallel-size 8意思是模型被切到 8 张卡上vLLM 发现 Ray 集群有 8 张可用 GPU会把 8 个 worker actor 分布到两台机器上。这个场景里 Ray 不只是可选项而是 vLLM 多机部署链条里不可缺的一环。这里有一个判断技巧看模型中 不可能被压缩 的部分。比如 FP16 权重是硬需求不管量化与否总有个下限KV Cache 跟上下文长度成正比越长越吃显存。把这些算清楚如果单机 A100 的量级明显不够跨机 TP 就是唯一出路Ray 也就没有值不值得的问题。4.2 信号二你需要跨节点的弹性资源和动态调度第二个信号是当稳定性和资源弹性成为硬需求时。两台机器虽然数量少但如果你在跑的生产服务要求任何一台机器崩了任务自动迁移到另一台而且不能手动重启那 Ray 的资源调度和自动重启能力就有价值。Ray 会监测 worker actor 的健康状态发现 GPU worker 挂了按告警策略重新调度。这个能力与 GPU 数量是否跨机没有必然关系但结合跨机模型分片后自动恢复就变得极具吸引力。另外如果你不只是跑 vLLM还在同一批机器上跑若干数据预处理、Embedding 批量计算、模型微调任务需要一个统一的资源调度层来动态分配 GPURay 可以承担这个角色。此时它的价值不是服务一个模型而是集群编排。判断信号很简单你这个环境里除了 vLLM 之外是否还有别的GPU 任务需要跑如果有而且它们会动态增减那 Ray 的统一调度值得投入如果这两台机器只跑一个 vLLM其他什么也不干那引入 Ray 就是在为一个非问题创造解法。4.3 信号三你的模型服务不只是一条直线第三个信号更隐蔽当推理链路里不止一个模型且它们之间有复杂的依赖关系时。在 RAG 类业务中一个请求会依次经过 Embedding 模型、Rerank 模型、生成模型在 Agent 类业务中还会按需调用多个不同大小的模型。vLLM 0.6 之后支持多模型并发加载但显存是共享池多个模型塞在同一个上下文里会互相影响 KV Cache、影响调度决策。这种场景下Ray 的价值在于你可以把不同模型分别部署为独立的 Ray Serving 应用并利用 Ray 的部署组把它们编排在一起模型间的调用由 Ray 统一路由。不过说句实话在只有两三台机器的时候用网关做服务编排往往比 Ray Serve 更轻、更可控。Ray 的这个价值要等到模型数量多、调用拓扑复杂之后才真正显现。我个人的底线判断是满足三条信号里至少一条以上Ray 才值得引入。只有一条且是可以绕开的那种比如弹性调度可以手动维护那还是踏踏实实用双实例方案更好。4.4 一个关键时间点网络带宽决定跨机 TP 值不值无论前三个信号怎么强烈还有一个被忽略的硬条件你的两台机器之间的网络带宽到底够不够。跨机张量并行每层 Transformer 计算完都要做 all-reduce数据量极其惊人。以 72B 模型、TP8 为例单次 all-reduce 需要同步的量就有数百 MB 到 GB 级别而且一个 batch 里会有很多层要做同步。如果用千兆网1GbE这个方案会慢到不可用万兆10GbE勉强能跑25GbE/40GbE 才算基本合格。我的实测数据是两台 A100 之间通过 25GbE 组网跨机 TP 的吞吐只有单机 NVLink 方案的 75% 到 85%延迟也会增加 10ms 左右。如果你用的还是千兆交换机那跨机 TP 纯属折磨。所以判断是否值得引入 Ray之前先量一量 netperf 的带宽。如果单机内 NVLink 互通没问题、两机网络带宽拉胯那就算模型放不下跨机 TP 也不是好选择。5. 实测同一组模型三种部署方式的性能与体验对比5.1 测试环境与基准配置为了把上面的判断落到数据上我在自己的测试环境做了一组对比。环境如下机器 A / B各 4×A100 80GNVLink 互联CPU 64 核内存 512GB两机间网络25GbE 网卡直连软件版本vLLM 0.8.4V1 引擎、Ray 2.31.0模型 1Qwen2.5-32B-Instruct单机 4 卡可跑模型 2Qwen2.5-72B-Instruct单机 4 卡可跑但 KV 余量不足单机 8 卡不现实因为只有 4 卡/机测试用一段固定 prompt平均 1200 tokens 输入请求并发 32输出长度限制 512 tokens统计总吞吐与 TTFT。5.2 场景 A32B 模型双实例 vs 单机单实例第一组对比解决的是吞吐瓶颈值不值得用 Ray 的问题。三个配置配置 1单机 4 卡 TP4单实例配置 2两机各启动一个 TP4 实例前面挂 Nginx 负载均衡配置 3两机 8 卡 TP8vLLM Ray 合体实例结果大致如下为了便于复现趋势数据做了取整部署方式总吞吐 (tokens/s)TTFT (ms)备注单机 4 卡3800350基准两机双实例 Nginx7100360约 1.87 倍线性扩展两机 TP8 Ray5900420跨机通信损耗明显这个结果很有代表性当模型不需要跨机时双实例负载均衡的吞吐遥遥领先因为它把两张机器的算力都榨干了而且没有跨机同步的额外开销。反过来两机 TP8 因为每层 Transformer 都要跨 25GbE 网做 all-reduce吞吐只剩单机 1.55 倍TTFT 还涨了 20%。所以看到这里可以下一个明确结论如果你的瓶颈是吞吐模型单机放得下不要用 Ray。双实例网关就是最优解。5.3 场景 B72B 模型跨机 TP 跑起来的实际表现第二组直接测试跨机 TP 的极限。Qwen2.5-72B 在单台 4×A100 上能加载权重但一旦把 max-model-len 拉到 64KKV Cache 显存就顶不住。为了跑长上下文只能两机 8 卡 TP。配置配置 4单机 4 卡 TP4短上下文max-token 8192配置 5两机 8 卡 TP8 Ray长上下文max-token 65536模型可稳定运行短上下文下配置 4 和配置 5 都能跑吞吐对比如下部署方式单请求吞吐 (tokens/s)并发 16 总吞吐显存峰值单机 4 卡 TP48202100283GB两机 8 卡 TP8 Ray7301900316GB跨机 TP 在短上下文时不仅没有优势还因为通信损耗导致单请求吞吐下降约 11%。但一旦把 max-model-len 拉到 64K配置 4 直接 OOM 起不来只有配置 5 能扛住。这时候 Ray 引入的价值就不应该在性能对比表里找而应该在能不能提供服务这件事上体现。5.4 数字背后的结论先看功能再看性能把这两组测试放一起可以提炼出几个很干脆的原则单机放得下的模型用双实例别碰 Ray。功能完全一样性能更好故障面更小。单机放不下但网络带宽足够的模型用 Ray 跨机 TP。它是你唯一能走的可靠路径。网络带宽不够的模型跨机 TP 跑起来的体验很差要么加网络设备要么降级换小模型/更多量化。另外提醒一点对比性能时一定要固定模型和请求长度再比。不同 max-model-len 下显存分配策略完全不同KV Cache 预留多少直接影响并发度和吞吐。我之前就见过有人拿 4K 上下文和 32K 上下文的配置比吞吐结果得出一堆自相矛盾的结论浪费时间。还有一个值得注意的问题版本升级对吞吐的影响。vLLM 同一模型不同镜像版本的吞吐差距可以超过 15%官方发新版时性能波动是常态。因此做对比测试时最好固定镜像版本避免把版本差异误判成架构差异。6. 引入 Ray 的部署步骤与排坑记录6.1 vLLM Ray 的最小化部署流程如果前面的判断都指向需要引入 Ray这里给一套我反复跑通过的最小化流程适用于两台 A100 机器。第一步在两台机器上装好 Docker 与 NVIDIA 驱动确认nvidia-smi正常。第二步分别启动 Ray 集群。head 节点命令ray start --head --port6379 --num-gpus4 --include-dashboardtrueworker 节点命令ray start --address192.168.1.10:6379 --num-gpus4注意--num-gpus必须显式写否则 Ray 不会上报 GPU 资源vLLM 在调度 worker 时会报 0 张可用 GPU。第三步在 head 节点的容器里启动 vLLM。官方镜像通常自带匹配的 Ray 版本如果用vllm/vllm-openai镜像需要注意容器内启动 Ray 时要把头节点的 6379 端口暴露出来docker run -d \ --gpus all \ --shm-size32g \ --ipchost \ --network host \ -v /models:/models \ -e RAY_ADDRESS192.168.1.10:6379 \ vllm/vllm-openai:v0.8.4 \ python -m vllm.entrypoints.openai.api_server \ --model /models/Qwen2.5-72B-Instruct \ --tensor-parallel-size 8 \ --distributed-executor-backend ray容器里启动 vLLM 时会自动连接到本机已有的 Ray 集群。这里我强烈建议用--network host避免容器网络转发增加额外延迟和 NAT 端口映射难题。6.2 排坑一Ray 版本与 vLLM 版本错位多机部署最容易踩的坑是 Ray 和 vLLM 的版本不匹配。vLLM 官方 Docker 镜像里固化了配套的 Ray 版本但很多人喜欢在容器里再pip install ray装最新版或者在一个裸 Python 环境手动装两个包结果导入时报一些奇怪错误比如RayActorError、object_ref相关性报错。我的建议是优先使用官方 vLLM 镜像自带的 Ray不要手动升级。如果必须自定义环境就用 pip 精确锁定版本。以 vLLM 0.8.x 为例官方要求 Ray 2.30但你去装一个 2.40 甚至更新的版本反而可能触发兼容问题。稳妥的做法是先安装 vLLM让它把依赖解析好再检查pip show ray的版本。另外vLLM 不同版本对--distributed-executor-backend的默认值有差异。早期版本默认 ray后期版本默认可能是 external-launcher 或 multiproc。多机场景下如果忘了显式传ray可能启动时会提示找不到足够的单机 GPU或者干脆报only one GPU detected之类的问题。6.3 排坑二跨机 NCCL 通信超时与网络配置跨机 TP 跑起来最典型的故障是NCCL timeout或者all-reduce卡住不动。大部分情况下不是 vLLM 的问题而是 NCCL 选错了网络接口。多机通信时NCCL 需要找到正确的网卡。如果你的机器有多个网口比如一个 1GbE 的管理网口一个 25GbE 的数据网口NCCL 很可能选到慢的那个表现为TP 初始化极慢、单请求延迟极高、偶尔报超时。解决方案是显式指定export NCCL_SOCKET_IFNAMEeth1 export NCCL_IB_DISABLE1 export NCCL_DEBUGINFONCCL_DEBUGINFO在排查问题阶段一定要开它能打印出 NCCL 实际用了哪个网卡、哪条路径省去很多猜测。另外如果用的是 RoCE/InfiniBand还要额外配置NCCL_IB_*参数这里不展开但思路一样先 debug看清楚它走的是哪条路。超时问题也很常见。在压力测试时如果请求并发过大跨机同步可能出现 NCCL 超时。合理设置export NCCL_ASYNC_ERROR_HANDLING1 export NCCL_SHM_DISABLE1 # 跨机场景下共享内存同步容易踩坑如果你的机器内存不足、/dev/shm太小还需要在容器里加--shm-size32g否则 Ray/NCCL 在共享内存上会频繁报错。6.4 排坑三head 节点成为新瓶颈Ray 集群的 head 节点负责所有调度决策、对象存储、状态同步。在只有两台机器时head 节点通常跑在其中一台业务机器上这本身没问题但要注意 head 节点所在机器的资源占用。有一个容易忽略的点head 节点会占用不小的内存Ray 各处的心跳、对象元数据、日志都会集中写到这里。如果你跑的是高并发推理vLLM 的请求处理本身会占用 CPU 和内存head 节点的进程再叠加进来偶尔会出现调度延迟抖动。我的习惯是把 head 节点放在负载较轻的那台机器上并在启动时限制 Ray 的内存占用ray start --head --port6379 --num-gpus4 --memory53687091200 # 50GB同时可以在vllm serve时加上--ray-num-cpus之类的参数限制 vLLM worker 占用的 CPU 数防止它把 head 调度的 CPU 抢光。这两步在只有两台机器时足够用了能明显降低系统抖动的概率。6.5 排坑四镜像版本与模型封装问题最后补充一个和模型文件相关的坑。多机部署时两台机器都要能访问同一份模型权重。如果你用的是普通磁盘每台机器单独下载一份最省事如果模型很大共享存储NFS、NAS是常见选择但要特别注意 NFS 到两机的带宽。还有一个细节vLLM 镜像本身不包含模型文件只包含推理引擎。所以别想着挂载一个模型进去就能跑得先把权重放到所有节点可见的路径。热门前像 glm5、deepseek 这类模型的权重动辄几百 GB如果只有一台机器能访问文件另一台从 NFS 读取时网络很容易成为瓶颈。这类问题排查起来很隐蔽表现出来是启动阶段卡在 loading model但实际是远端权重文件读太慢。关于挑镜像版本我的经验是固定大版本不追最新。热门模型通常会在社区讨论出比较稳定的 vLLM 镜像版本但我个人不建议直接上刚发布的小版本因为 vLLM 新版本的性能回归问题不是一次两次了。我的习惯是确认使用的模型和上下文长度再回看官方 release notes只要我用到的特性没有改动就不升版本。这样可以避免把vLLM 新版本性能下降的锅甩到 Ray 身上。最后说一个我自己判断多机方案的笨办法每次要不要上 Ray我都会把问题简化成一个清单模型能不能在单机内装下装得下默认不碰 Ray。如果只是吞吐不够优先加独立实例配一个负载均衡网关。只有显存真的不够、且两机网络带宽不低于 25GbE 时才启动 Ray 做跨机 TP。如果网络带宽低于 10GbE我会先尝试量化或换小模型而不是硬上跨机。这套办法看起来很保守但帮我避免了好几次无意义的架构升级。Ray 本身是个优秀的工具但它有它的适用面做大集群、做弹性调度、做多任务混跑。两台机器、一个 vLLM 服务的场景绝大多数时候不需要跳到集群这个维度去思考问题。把模型能不能装下、瓶颈在显存还是吞吐、网络够不够快这三个问题回答清楚该不该引入 Ray答案其实已经写在问题里了。