vLLM 数据并行部署实战指南内部、混合与外部负载均衡三种拓扑【免费下载链接】vllmA high-throughput and memory-efficient inference and serving engine for LLMs项目地址: https://gitcode.com/GitHub_Trending/vl/vllmvLLM 的数据并行Data Parallel, DP部署允许将同一份模型权重复制到多组独立实例/GPU 上各自处理互不重叠的请求批次从而在吞吐敏感的场景下水平扩展服务能力。本篇结合 docs/serving/data_parallel_deployment.md 的官方部署说明与vllm/config、vllm/v1/engine中的源码实现完整覆盖 DP 部署的进程架构、三种在线负载均衡模式内部 LB、混合 LB、外部 LB的命令行配置、多机部署与 Ray 后端的差异以及离线LLM类用法帮助你在单机、多机乃至 Kubernetes 环境下正确落地数据并行服务。什么是 DP 部署权重复制与请求批次切分数据并行的核心思想是把模型权重完整复制到多个 DP rank 上每个 rank 独立持有自己的 KV cache并处理一批独立的请求。vLLM 同时支持稠密dense模型和 MoE 模型的 DP 部署两者在行为上有本质区别稠密模型各 DP rank 之间完全独立没有任何跨 rank 的同步要求。对非 MoE 模型而言外部负载平衡其实退化为启动多个彼此独立的 vLLM 实例即可。MoE 模型尤其是 DeepSeek 这类采用 MLAMulti-head Latent Attention 的模型常见且高效的组合是注意力层走数据并行专家层走专家并行EP或张量并行TP。此时各 DP rank 并不完全独立——前向传播必须对齐即使某些 rank 当前没有请求其专家层在每次前向中也必须参与同步即执行哑前向dummy forward pass。从源码结构看这一对齐机制落在引擎核心循环中vllm/v1/engine/core.py 显示当某 rank 本轮没有就绪请求时且引擎不处于休眠态会执行execute_dummy_batch()补齐空批次随后调用_has_global_unfinished_reqs()做 all-reduce 判断全局是否还有未完成的请求。该 all-reduce 做了优化每 32 步才执行一次见 vllm/v1/engine/core.py以避免每步同步带来的开销。默认情况下MoE 的专家层会形成一个大小为DP × TP的张量并行组如果想改用专家并行需要在多机场景的所有节点上都加上--enable-expert-parallel参数。EP 模式下注意力层与专家层的行为差异可参考 docs/serving/expert_parallel_deployment.md。进程架构Core Engine、ZMQ 与 DP Coordinator在 vLLM 的进程模型中每个 DP rank 都部署为一个独立的 core engine 进程通过 ZMQ socket 与前端front-endAPI server 进程通信。当 DP 与 TP 组合使用时每个 DP 引擎还拥有与其 TP size 相等的每 GPU worker 进程。支撑这套架构的关键组件是DP Coordinator进程其实现位于 vllm/v1/engine/coordinator.py。根据源码中的类注释它承担三类职责负载统计收集与发布从各 DP 引擎收集统计信息当前是 waiting 队列和 running 队列长度并发布给所有前端进程用于负载平衡决策。全局 request wave 状态跟踪引擎在全局运行/暂停两种状态之间交替wave 号是全体 worker 从运行态转入暂停态的累计次数由 DP rank 0 引擎上报、经 Coordinator 广播。广播START_DP_WAVE消息当某个引擎暂停时收到新请求前端会同时通知 Coordinator由它唤醒所有引擎进入运行态。MoE 部署中只要任一 rank 有请求在跑其余空闲 rank 必须执行 dummy 前向的语义正是由 Coordinator 与上述 all-reduce 共同保障的当 all-reduce 确认所有 rank 都空闲后引擎才会集体暂停以节省算力。在在线API server部署中各 DP 引擎的 KV cache 彼此独立因此在 rank 间做负载均衡是有价值的——尤其是把共享前缀的 prompt 智能地路由到同一个 DP rank以最大化 prefix caching 的收益。官方文档指出当前的内部负载均衡基于各引擎的 running/waiting 队列后续版本计划引入 KV cache 感知的路由逻辑。内部负载均衡单一 API 端点的自包含部署内部 LB 模式下vLLM 对外暴露单一 API 端点所有 DP rank 的调度与路由都封装在 API server 进程内部对客户端完全透明。单机部署只需在vllm serve命令中加入--data-parallel-size# DP4需要 4 张 GPU vllm serve $MODEL --data-parallel-size 4 # DP4 × TP2需要 8 张 GPU vllm serve $MODEL --data-parallel-size 4 --tensor-parallel-size 2DP 可以与张量并行任意组合所需 GPU 总数为DP × TP再乘以 PP/PCP 等。一个容易踩坑的细节--max-num-seqs是按每个 DP rank 生效的容量规划时要按 rank 数相乘计算全局并发上限。多机部署MP 后端跨多机运行单一 DP 部署时需要在每个节点上各启动一个vllm serve并指定该节点承载哪些 DP rank。此时仍然只有一个 HTTP 入口——API server 只在一个节点上运行但它不一定与 DP rank 同机。DP4、TP2head 节点承载 rank 0/1第二节点承载 rank 2/3# Node 0 (with ip address 10.99.48.128) vllm serve $MODEL --data-parallel-size 4 --data-parallel-size-local 2 \ --data-parallel-address 10.99.48.128 --data-parallel-rpc-port 13345 # Node 1 vllm serve $MODEL --headless --data-parallel-size 4 --data-parallel-size-local 2 \ --data-parallel-start-rank 2 \ --data-parallel-address 10.99.48.128 --data-parallel-rpc-port 13345DP4API server 全部放在第一节点、所有引擎放在第二节点--data-parallel-size-local 0表示本节点不承载引擎# Node 0 (with ip address 10.99.48.128) vllm serve $MODEL --data-parallel-size 4 --data-parallel-size-local 0 \ --data-parallel-address 10.99.48.128 --data-parallel-rpc-port 13345 # Node 1 vllm serve $MODEL --headless --data-parallel-size 4 --data-parallel-size-local 4 \ --data-parallel-address 10.99.48.128 --data-parallel-rpc-port 13345相关参数在 vllm/config/parallel.py 的ParallelConfig中定义关键默认值如下参数含义默认值源码--data-parallel-size全局 DP rank 总数1--data-parallel-size-local本节点承载的 rank 数0 表示本节点只跑前端/协调10 为哨兵值--data-parallel-start-rank本节点首个 rank 的全局编号推断--data-parallel-address协调用 head 节点 IPdata_parallel_master_ip127.0.0.1--data-parallel-rpc-port各节点共享的 DP 通信端口29550--headless本节点不启动 API serverFalse注意--data-parallel-size-local与--data-parallel-size的一致性校验__post_init__会校验data_parallel_size_local data_parallel_size见 vllm/config/parallel.py且--data-parallel-rank必须落在[0, data_parallel_size)区间内。使用 Ray 作为 DP 后端同一套内部 DP 模式也可以指定--data-parallel-backendray使用 Ray 来拉起所有 rankvllm serve $MODEL --data-parallel-size 4 --data-parallel-size-local 2 \ --data-parallel-backendrayRay 后端与 MP 后端的显著差异只需任意一个节点上执行一条启动命令即可拉起本地和远程的所有 DP rank省去逐节点手动启动无需指定--data-parallel-address以命令所在节点为准也无需--data-parallel-rpc-port当单个 DP 组需要跨节点即一份模型副本至少分布在两台机器上时必须设置环境变量VLLM_RAY_DP_PACK_STRATEGYspan此时--data-parallel-size-local会被忽略并自动推断。从源码看该策略下data_parallel_size_local被强制置为 1见 vllm/engine/arg_utils.py远程 DP rank 按 Ray 集群的节点资源自动分配。API server 横向扩展大 DP 规模下API server 进程本身可能成为瓶颈。正交的--api-server-count参数可以水平扩展 API server 进程数例如--api-server-count4对用户完全透明——仍然只暴露单一 HTTP 端点/端口。需要注意这一扩展是内部的仍被限制在 head 节点上。混合负载均衡节点内自治 节点间外部路由混合 LBhybrid load balancing介于内部与外部模式之间每个节点各自运行自己的 API server只把请求路由给本节点上共置的 DP 引擎跨节点的请求分布交给上游负载均衡器ingress controller、流量路由器等完成。启用方式是在所有节点仍按全局 DP size 启动的前提下加上--data-parallel-hybrid-lb与内部 LB 的关键区别必须提供--data-parallel-size-local和--data-parallel-start-rank让每个节点明确知道自己拥有哪些 rank与--headless不兼容因为每个节点都要暴露 API 端点--api-server-count需要按每个节点的本地 rank 数量来缩放。从源码看这一模式的判定逻辑在 vllm/engine/arg_utils.py非 headless 节点一旦提供了--data-parallel-start-rank就会自动推断启用 hybrid LB如果data_parallel_size_local 1则自动退化为纯外部 LB 并给出警告。混合模式的核心收益是每个节点保留本地调度决策减少跨节点流量、避免大 DP 规模下单节点 API server 瓶颈。外部负载均衡把每个 DP rank 当作独立部署面向更大规模的部署把 DP rank 的编排与负载平衡完全外置往往更合理把每个 DP rank 当作一个独立的 vLLM 部署有自己的 endpoint由外部路由器在各服务器之间分发 HTTP 请求并可以利用各 server 的实时遥测做路由决策。非 MoE 模型直接启动若干互相独立的 vLLM 实例即可不要附加任何--data-parallel-*参数——外部 DP CLI 选项仅对 MoE 部署开放。这一点也有源码级校验vllm/engine/arg_utils.py 中若data_parallel_size 1且处于外部 LB 模式但模型不是 MoE会直接抛出Non-MoE models do not support external data parallel mode错误。MoE DPEP 拓扑通过--data-parallel-rank等参数配置等价的外部拓扑显式提供--data-parallel-rank会自动置位data_parallel_external_lb见 vllm/config/parallel.py 的字段注释。DP rank 共置在同一节点同 IP时使用默认 RPC 端口但每个 rank 必须指定不同的 HTTP 端口# Rank 0 CUDA_VISIBLE_DEVICES0 vllm serve $MODEL --data-parallel-size 2 --data-parallel-rank 0 \ --port 8000 # Rank 1 CUDA_VISIBLE_DEVICES1 vllm serve $MODEL --data-parallel-size 2 --data-parallel-rank 1 \ --port 8001多机场景下还必须额外指定 rank 0 的地址与端口# Rank 0 (with ip address 10.99.48.128) vllm serve $MODEL --data-parallel-size 2 --data-parallel-rank 0 \ --data-parallel-address 10.99.48.128 --data-parallel-rpc-port 13345 # Rank 1 vllm serve $MODEL --data-parallel-size 2 --data-parallel-rank 1 \ --data-parallel-address 10.99.48.128 --data-parallel-rpc-port 13345外部 LB 模式下 Coordinator 进程依然存在与 DP rank 0 引擎共置。另外从源码看故障容忍fault tolerance特性明确要求外部 LB 模式--data-parallel-external-lb或--data-parallel-rank内部 LB 模式不受支持见 vllm/engine/arg_utils.py。上图中每个虚线框对应一次独立的vllm serve启动——在 Kubernetes 中这通常就是独立的 Pod。离线使用LLM 类与 SPMD 环境DP 部署不仅限于在线 API 服务离线推理LLM类同样支持 DPEP。官方示例 examples/features/data_parallel/data_parallel_offline.py 演示了完整用法# 单机 python examples/features/data_parallel/data_parallel_offline.py \ --modelibm-research/PowerMoE-3b -dp2 -tp2 # 多机 Node 0ip 10.99.48.128 python examples/features/data_parallel/data_parallel_offline.py \ --modelibm-research/PowerMoE-3b -dp2 -tp2 \ --dp-num-nodes2 --dp-node-rank0 \ --dp-master-addr10.99.48.128 --dp-master-port13345 # 多机 Node 1 相同仅 --dp-node-rank1该脚本的实现要点每个 DP rank 运行在独立进程中通过环境变量VLLM_DP_RANK、VLLM_DP_RANK_LOCAL、VLLM_DP_SIZE、VLLM_DP_MASTER_IP、VLLM_DP_MASTER_PORT传递 rank 信息见示例第 94–98 行各 rank 处理数据集的不同分片prompt 列表按 rank 均匀切分若某 rank 分到的 prompt 为空则填入占位 promptDP 语义下各 rank 需要保持前向对齐各 rank 可以使用不同的 sampling params——示例中按 rank 奇偶设置不同的max_tokens说明 DP rank 间参数可以彼此独立。选型建议与关键约束汇总场景推荐模式关键点单机快速横向扩吞吐内部 LB--data-parallel-sizeN单一端点最省事多机希望单一入口内部 LBMP 或 Ray 后端MP 需逐节点启动并指定--data-parallel-address/--data-parallel-rpc-portRay 一条命令拉起全局多机节点各自暴露端点混合 LB--data-parallel-hybrid-lb--data-parallel-size-local--data-parallel-start-rank上游再路由跨节点流量大规模、K8s 一 rank 一 Pod外部 LBMoE 专属每 rank 独立 endpoint 独立端口外部路由器 实时遥测决策稠密模型大规模扩展多个独立实例不加任何--data-parallel-*参数纯外部 LB离线批量推理LLM类 SPMD 环境变量参考离线示例脚本几条硬约束值得在容量规划前牢记--max-num-seqs按 DP rank 计数全局并发上限 max_num_seqs × DP内部/混合/外部三种 LB 模式互斥hybrid 与 external 不能同时开启vllm/engine/arg_utils.py 会直接报错hybrid 也不兼容--headless外部 DP CLI 选项仅适用于 MoE 模型Elastic EP 与data_parallel_external_lb/data_parallel_hybrid_lb不兼容见 vllm/config/parallel.py因为它依赖单一 API serverMoE 的 DP 部署天然要求跨 rank 前向对齐空闲 rank 也会消耗算力执行 dummy 前向评估成本时应将此计入。通过内部、混合、外部三种模式vLLM 的 DP 部署可以从小规模单机的单条命令平滑扩展到多机乃至 K8s 上一 rank 一 Pod的宽 EP 拓扑理解 Core Engine 进程、ZMQ 通信与 DP Coordinator 的 wave 协调机制是正确组合这些模式、排查跨 rank 同步问题的基础。【免费下载链接】vllmA high-throughput and memory-efficient inference and serving engine for LLMs项目地址: https://gitcode.com/GitHub_Trending/vl/vllm创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 vLLM 数据并行部署实战指南：内部、混合与外部负载均衡三种拓扑
vLLM 数据并行部署实战指南内部、混合与外部负载均衡三种拓扑【免费下载链接】vllmA high-throughput and memory-efficient inference and serving engine for LLMs项目地址: https://gitcode.com/GitHub_Trending/vl/vllmvLLM 的数据并行Data Parallel, DP部署允许将同一份模型权重复制到多组独立实例/GPU 上各自处理互不重叠的请求批次从而在吞吐敏感的场景下水平扩展服务能力。本篇结合 docs/serving/data_parallel_deployment.md 的官方部署说明与vllm/config、vllm/v1/engine中的源码实现完整覆盖 DP 部署的进程架构、三种在线负载均衡模式内部 LB、混合 LB、外部 LB的命令行配置、多机部署与 Ray 后端的差异以及离线LLM类用法帮助你在单机、多机乃至 Kubernetes 环境下正确落地数据并行服务。什么是 DP 部署权重复制与请求批次切分数据并行的核心思想是把模型权重完整复制到多个 DP rank 上每个 rank 独立持有自己的 KV cache并处理一批独立的请求。vLLM 同时支持稠密dense模型和 MoE 模型的 DP 部署两者在行为上有本质区别稠密模型各 DP rank 之间完全独立没有任何跨 rank 的同步要求。对非 MoE 模型而言外部负载平衡其实退化为启动多个彼此独立的 vLLM 实例即可。MoE 模型尤其是 DeepSeek 这类采用 MLAMulti-head Latent Attention 的模型常见且高效的组合是注意力层走数据并行专家层走专家并行EP或张量并行TP。此时各 DP rank 并不完全独立——前向传播必须对齐即使某些 rank 当前没有请求其专家层在每次前向中也必须参与同步即执行哑前向dummy forward pass。从源码结构看这一对齐机制落在引擎核心循环中vllm/v1/engine/core.py 显示当某 rank 本轮没有就绪请求时且引擎不处于休眠态会执行execute_dummy_batch()补齐空批次随后调用_has_global_unfinished_reqs()做 all-reduce 判断全局是否还有未完成的请求。该 all-reduce 做了优化每 32 步才执行一次见 vllm/v1/engine/core.py以避免每步同步带来的开销。默认情况下MoE 的专家层会形成一个大小为DP × TP的张量并行组如果想改用专家并行需要在多机场景的所有节点上都加上--enable-expert-parallel参数。EP 模式下注意力层与专家层的行为差异可参考 docs/serving/expert_parallel_deployment.md。进程架构Core Engine、ZMQ 与 DP Coordinator在 vLLM 的进程模型中每个 DP rank 都部署为一个独立的 core engine 进程通过 ZMQ socket 与前端front-endAPI server 进程通信。当 DP 与 TP 组合使用时每个 DP 引擎还拥有与其 TP size 相等的每 GPU worker 进程。支撑这套架构的关键组件是DP Coordinator进程其实现位于 vllm/v1/engine/coordinator.py。根据源码中的类注释它承担三类职责负载统计收集与发布从各 DP 引擎收集统计信息当前是 waiting 队列和 running 队列长度并发布给所有前端进程用于负载平衡决策。全局 request wave 状态跟踪引擎在全局运行/暂停两种状态之间交替wave 号是全体 worker 从运行态转入暂停态的累计次数由 DP rank 0 引擎上报、经 Coordinator 广播。广播START_DP_WAVE消息当某个引擎暂停时收到新请求前端会同时通知 Coordinator由它唤醒所有引擎进入运行态。MoE 部署中只要任一 rank 有请求在跑其余空闲 rank 必须执行 dummy 前向的语义正是由 Coordinator 与上述 all-reduce 共同保障的当 all-reduce 确认所有 rank 都空闲后引擎才会集体暂停以节省算力。在在线API server部署中各 DP 引擎的 KV cache 彼此独立因此在 rank 间做负载均衡是有价值的——尤其是把共享前缀的 prompt 智能地路由到同一个 DP rank以最大化 prefix caching 的收益。官方文档指出当前的内部负载均衡基于各引擎的 running/waiting 队列后续版本计划引入 KV cache 感知的路由逻辑。内部负载均衡单一 API 端点的自包含部署内部 LB 模式下vLLM 对外暴露单一 API 端点所有 DP rank 的调度与路由都封装在 API server 进程内部对客户端完全透明。单机部署只需在vllm serve命令中加入--data-parallel-size# DP4需要 4 张 GPU vllm serve $MODEL --data-parallel-size 4 # DP4 × TP2需要 8 张 GPU vllm serve $MODEL --data-parallel-size 4 --tensor-parallel-size 2DP 可以与张量并行任意组合所需 GPU 总数为DP × TP再乘以 PP/PCP 等。一个容易踩坑的细节--max-num-seqs是按每个 DP rank 生效的容量规划时要按 rank 数相乘计算全局并发上限。多机部署MP 后端跨多机运行单一 DP 部署时需要在每个节点上各启动一个vllm serve并指定该节点承载哪些 DP rank。此时仍然只有一个 HTTP 入口——API server 只在一个节点上运行但它不一定与 DP rank 同机。DP4、TP2head 节点承载 rank 0/1第二节点承载 rank 2/3# Node 0 (with ip address 10.99.48.128) vllm serve $MODEL --data-parallel-size 4 --data-parallel-size-local 2 \ --data-parallel-address 10.99.48.128 --data-parallel-rpc-port 13345 # Node 1 vllm serve $MODEL --headless --data-parallel-size 4 --data-parallel-size-local 2 \ --data-parallel-start-rank 2 \ --data-parallel-address 10.99.48.128 --data-parallel-rpc-port 13345DP4API server 全部放在第一节点、所有引擎放在第二节点--data-parallel-size-local 0表示本节点不承载引擎# Node 0 (with ip address 10.99.48.128) vllm serve $MODEL --data-parallel-size 4 --data-parallel-size-local 0 \ --data-parallel-address 10.99.48.128 --data-parallel-rpc-port 13345 # Node 1 vllm serve $MODEL --headless --data-parallel-size 4 --data-parallel-size-local 4 \ --data-parallel-address 10.99.48.128 --data-parallel-rpc-port 13345相关参数在 vllm/config/parallel.py 的ParallelConfig中定义关键默认值如下参数含义默认值源码--data-parallel-size全局 DP rank 总数1--data-parallel-size-local本节点承载的 rank 数0 表示本节点只跑前端/协调10 为哨兵值--data-parallel-start-rank本节点首个 rank 的全局编号推断--data-parallel-address协调用 head 节点 IPdata_parallel_master_ip127.0.0.1--data-parallel-rpc-port各节点共享的 DP 通信端口29550--headless本节点不启动 API serverFalse注意--data-parallel-size-local与--data-parallel-size的一致性校验__post_init__会校验data_parallel_size_local data_parallel_size见 vllm/config/parallel.py且--data-parallel-rank必须落在[0, data_parallel_size)区间内。使用 Ray 作为 DP 后端同一套内部 DP 模式也可以指定--data-parallel-backendray使用 Ray 来拉起所有 rankvllm serve $MODEL --data-parallel-size 4 --data-parallel-size-local 2 \ --data-parallel-backendrayRay 后端与 MP 后端的显著差异只需任意一个节点上执行一条启动命令即可拉起本地和远程的所有 DP rank省去逐节点手动启动无需指定--data-parallel-address以命令所在节点为准也无需--data-parallel-rpc-port当单个 DP 组需要跨节点即一份模型副本至少分布在两台机器上时必须设置环境变量VLLM_RAY_DP_PACK_STRATEGYspan此时--data-parallel-size-local会被忽略并自动推断。从源码看该策略下data_parallel_size_local被强制置为 1见 vllm/engine/arg_utils.py远程 DP rank 按 Ray 集群的节点资源自动分配。API server 横向扩展大 DP 规模下API server 进程本身可能成为瓶颈。正交的--api-server-count参数可以水平扩展 API server 进程数例如--api-server-count4对用户完全透明——仍然只暴露单一 HTTP 端点/端口。需要注意这一扩展是内部的仍被限制在 head 节点上。混合负载均衡节点内自治 节点间外部路由混合 LBhybrid load balancing介于内部与外部模式之间每个节点各自运行自己的 API server只把请求路由给本节点上共置的 DP 引擎跨节点的请求分布交给上游负载均衡器ingress controller、流量路由器等完成。启用方式是在所有节点仍按全局 DP size 启动的前提下加上--data-parallel-hybrid-lb与内部 LB 的关键区别必须提供--data-parallel-size-local和--data-parallel-start-rank让每个节点明确知道自己拥有哪些 rank与--headless不兼容因为每个节点都要暴露 API 端点--api-server-count需要按每个节点的本地 rank 数量来缩放。从源码看这一模式的判定逻辑在 vllm/engine/arg_utils.py非 headless 节点一旦提供了--data-parallel-start-rank就会自动推断启用 hybrid LB如果data_parallel_size_local 1则自动退化为纯外部 LB 并给出警告。混合模式的核心收益是每个节点保留本地调度决策减少跨节点流量、避免大 DP 规模下单节点 API server 瓶颈。外部负载均衡把每个 DP rank 当作独立部署面向更大规模的部署把 DP rank 的编排与负载平衡完全外置往往更合理把每个 DP rank 当作一个独立的 vLLM 部署有自己的 endpoint由外部路由器在各服务器之间分发 HTTP 请求并可以利用各 server 的实时遥测做路由决策。非 MoE 模型直接启动若干互相独立的 vLLM 实例即可不要附加任何--data-parallel-*参数——外部 DP CLI 选项仅对 MoE 部署开放。这一点也有源码级校验vllm/engine/arg_utils.py 中若data_parallel_size 1且处于外部 LB 模式但模型不是 MoE会直接抛出Non-MoE models do not support external data parallel mode错误。MoE DPEP 拓扑通过--data-parallel-rank等参数配置等价的外部拓扑显式提供--data-parallel-rank会自动置位data_parallel_external_lb见 vllm/config/parallel.py 的字段注释。DP rank 共置在同一节点同 IP时使用默认 RPC 端口但每个 rank 必须指定不同的 HTTP 端口# Rank 0 CUDA_VISIBLE_DEVICES0 vllm serve $MODEL --data-parallel-size 2 --data-parallel-rank 0 \ --port 8000 # Rank 1 CUDA_VISIBLE_DEVICES1 vllm serve $MODEL --data-parallel-size 2 --data-parallel-rank 1 \ --port 8001多机场景下还必须额外指定 rank 0 的地址与端口# Rank 0 (with ip address 10.99.48.128) vllm serve $MODEL --data-parallel-size 2 --data-parallel-rank 0 \ --data-parallel-address 10.99.48.128 --data-parallel-rpc-port 13345 # Rank 1 vllm serve $MODEL --data-parallel-size 2 --data-parallel-rank 1 \ --data-parallel-address 10.99.48.128 --data-parallel-rpc-port 13345外部 LB 模式下 Coordinator 进程依然存在与 DP rank 0 引擎共置。另外从源码看故障容忍fault tolerance特性明确要求外部 LB 模式--data-parallel-external-lb或--data-parallel-rank内部 LB 模式不受支持见 vllm/engine/arg_utils.py。上图中每个虚线框对应一次独立的vllm serve启动——在 Kubernetes 中这通常就是独立的 Pod。离线使用LLM 类与 SPMD 环境DP 部署不仅限于在线 API 服务离线推理LLM类同样支持 DPEP。官方示例 examples/features/data_parallel/data_parallel_offline.py 演示了完整用法# 单机 python examples/features/data_parallel/data_parallel_offline.py \ --modelibm-research/PowerMoE-3b -dp2 -tp2 # 多机 Node 0ip 10.99.48.128 python examples/features/data_parallel/data_parallel_offline.py \ --modelibm-research/PowerMoE-3b -dp2 -tp2 \ --dp-num-nodes2 --dp-node-rank0 \ --dp-master-addr10.99.48.128 --dp-master-port13345 # 多机 Node 1 相同仅 --dp-node-rank1该脚本的实现要点每个 DP rank 运行在独立进程中通过环境变量VLLM_DP_RANK、VLLM_DP_RANK_LOCAL、VLLM_DP_SIZE、VLLM_DP_MASTER_IP、VLLM_DP_MASTER_PORT传递 rank 信息见示例第 94–98 行各 rank 处理数据集的不同分片prompt 列表按 rank 均匀切分若某 rank 分到的 prompt 为空则填入占位 promptDP 语义下各 rank 需要保持前向对齐各 rank 可以使用不同的 sampling params——示例中按 rank 奇偶设置不同的max_tokens说明 DP rank 间参数可以彼此独立。选型建议与关键约束汇总场景推荐模式关键点单机快速横向扩吞吐内部 LB--data-parallel-sizeN单一端点最省事多机希望单一入口内部 LBMP 或 Ray 后端MP 需逐节点启动并指定--data-parallel-address/--data-parallel-rpc-portRay 一条命令拉起全局多机节点各自暴露端点混合 LB--data-parallel-hybrid-lb--data-parallel-size-local--data-parallel-start-rank上游再路由跨节点流量大规模、K8s 一 rank 一 Pod外部 LBMoE 专属每 rank 独立 endpoint 独立端口外部路由器 实时遥测决策稠密模型大规模扩展多个独立实例不加任何--data-parallel-*参数纯外部 LB离线批量推理LLM类 SPMD 环境变量参考离线示例脚本几条硬约束值得在容量规划前牢记--max-num-seqs按 DP rank 计数全局并发上限 max_num_seqs × DP内部/混合/外部三种 LB 模式互斥hybrid 与 external 不能同时开启vllm/engine/arg_utils.py 会直接报错hybrid 也不兼容--headless外部 DP CLI 选项仅适用于 MoE 模型Elastic EP 与data_parallel_external_lb/data_parallel_hybrid_lb不兼容见 vllm/config/parallel.py因为它依赖单一 API serverMoE 的 DP 部署天然要求跨 rank 前向对齐空闲 rank 也会消耗算力执行 dummy 前向评估成本时应将此计入。通过内部、混合、外部三种模式vLLM 的 DP 部署可以从小规模单机的单条命令平滑扩展到多机乃至 K8s 上一 rank 一 Pod的宽 EP 拓扑理解 Core Engine 进程、ZMQ 通信与 DP Coordinator 的 wave 协调机制是正确组合这些模式、排查跨 rank 同步问题的基础。【免费下载链接】vllmA high-throughput and memory-efficient inference and serving engine for LLMs项目地址: https://gitcode.com/GitHub_Trending/vl/vllm创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考