vLLM 如何用 --data-parallel-size 部署数据并行服务并配置跨节点 DP 与内部负载均衡【免费下载链接】vllmA high-throughput and memory-efficient inference and serving engine for LLMs项目地址: https://gitcode.com/GitHub_Trending/vl/vllm当单副本的 GPU 数量已经足够放下模型但吞吐量仍受限于单实例时可以用 vLLM 的数据并行Data Parallel部署模型权重在独立的 DP rankcore engine 进程之间复制各 rank 处理独立的请求批次。dense 和 MoE 模型都支持该模式对 DeepSeek 这类使用 MLA 的 MoE 模型文档还建议 attention 层用数据并行、expert 层用 EP/TP配合--enable-expert-parallel见 Expert Parallel Deployment。本文覆盖 vLLM 文档中“自包含”的在线部署方式只暴露一个 HTTP 入口负载均衡由 API server 进程内部完成以及跨节点拆分 DP rank 的配置。部署形态说明来自 Data Parallel Deployment。准备条件已安装 vLLM 并能执行vllm serve文档以 Linux GPU 环境为例单机多卡或多节点皆可。确定 GPU 数量--data-parallel-size N需要 N 张 GPU与张量并行组合时总数为 DP × TP例如--data-parallel-size4 --tensor-parallel-size2需要 8 张 GPU。容量规划注意区分作用域--max-num-seqs按 DP rank 生效而准入控制--max-num-queued-reqs和--max-num-queued-tokens作用于整个 server每个 API server 进程统计其路由到的所有 DP rank 的在途请求与 prefill 积压。文档举例--data-parallel-size4 --max-num-seqs256 --max-num-queued-reqs256时总请求数达到 256 就会开始拒绝新请求尽管 4 个 rank 合计可跑 1024 条。要让 rank 保持饱和文档建议把上限按data-parallel-size * max-num-seqs再加期望队列深度来设置。单机内部负载均衡内部负载均衡由 API server 进程完成依据是每个 engine 的运行中队列与等待队列对外只有一个 API 端点。单机 8 卡节点上跑 DP4、TP2vllm serve $MODEL --data-parallel-size 4 --tensor-parallel-size 2其中$MODEL替换为你要部署的模型Hugging Face 仓库 ID 或本地路径。MoE 模型的一个行为边界只要任一 rank 有请求在处理没有请求的 rank 也必须执行“dummy”前向以保持同步。这由一个独立的 DP Coordinator 进程管理它会与各 rank 通信并每隔 N 步做一次集合操作判断所有 rank 何时空闲、可以暂停。因此即使某些 rank 当前没有流量也不会真正空转释放资源。跨节点 DP 与内部负载均衡跨节点部署时每个节点各跑一个vllm serve用--data-parallel-size-local指明本节点承载几个 rank、用--data-parallel-start-rank指明起始 rank--data-parallel-address和--data-parallel-rpc-port在所有节点上保持一致。仍然只有一个 HTTP 入口API server 只在一个节点上运行且该节点不一定与 DP rank 同机。下面示例在两个节点上跑 DP4rank 0、1 在 head 节点IP 为 10.99.48.128rank 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 13345要点--data-parallel-size写的是全局 DP 总数所有节点相同--data-parallel-size-local是本节点的 rank 数各节点之和应等于全局总数。非 head 节点加--headless表示该节点不提供 API 入口只跑 engine。文档中 10.99.48.128 与 13345 是示例值替换为你的节点 IP 与 RPC 端口EP 文档注明该端口只要各节点可达即可$MODEL替换为模型。也可以让 API server 与 engine 完全分离head 节点用--data-parallel-size-local 0只挂 API server全部 rank 放在第二节点--data-parallel-size-local 4 --headless命令形式同上。可选分支Ray 后端DP 模式也可以用--data-parallel-backendray交给 Ray 管理只需在任意一个节点上执行单条启动命令所有本地与远程 DP rank 由 Ray 按集群节点资源分配vllm serve $MODEL --data-parallel-size 4 --data-parallel-size-local 2 \ --data-parallel-backendray与手动多节点方式的区别不需要--data-parallel-address执行命令的节点即地址也不需要--data-parallel-rpc-port。如果一个 DP group 需要跨多个节点单个模型副本要占至少两个节点需设置VLLM_RAY_DP_PACK_STRATEGYspan此时--data-parallel-size-local会被忽略并自动决定。Ray 是可选依赖需先安装见 Parallelism and Scaling。可选分支Hybrid 负载均衡Hybrid 模式介于内部与外部负载均衡之间每个节点跑自己的 API server只把请求排给本节点 colocated 的 DP engine由上游负载均衡器ingress 或流量路由器在节点端点间分发。用--data-parallel-hybrid-lb开启且每个节点仍要带全局--data-parallel-size。与内部负载均衡的差异必须提供--data-parallel-size-local和--data-parallel-start-rank让每个节点知道自己拥有哪些 rank与--headless不兼容因为每个节点都暴露 API 端点--api-server-count按本节点 rank 数单独设置。该模式把调度决策留在本地减少跨节点流量避免大 DP 规模下的单节点瓶颈。API server 扩进程--api-server-count用内部负载均衡做大 DP 时API server 进程本身可能成为瓶颈。此时用--api-server-count把 API server 横向扩出多个进程例如--api-server-count4对用户透明仍然只暴露一个 HTTP 端点/端口注意该扩展是“内部”的API server 仍限制在 head 节点。EP 文档在两节点示例中也推荐把--api-server-count放大到本地 rank 数--api-server-count8。结果验证服务启动后用文档列出的端点确认单入口正常工作# 健康检查 curl http://head节点IP:8000/health # 列出模型 curl http://head节点IP:8000/v1/models # 发送一条生成请求 curl http://head节点IP:8000/v1/completions \ -H Content-Type: application/json \ -d { model: $MODEL, prompt: San Francisco is a, max_tokens: 7, temperature: 0 }这些端点/health、/v1/models、/load服务器负载指标、/v1/completions在 Online Serving 中列明。内部负载均衡下所有节点上的 engine 都通过这一个入口接收请求hybrid 模式下则改为对每个节点的端点分别做同样检查由上游负载均衡器负责分发。排查与限制跨节点起不来、rank 间通信失败时先检查--data-parallel-address指向的节点 IP 与各节点上 RPC 端口是否互通分布式部署的通用问题见 Troubleshooting distributed deployments。MoE 模型下有请求在任一 rank 进行时其余 rank 会执行 dummy 前向保持同步——这是文档说明的设计行为不是故障。大 DP 规模下请求吞吐受限于 API server 单进程时加--api-server-count仅限 head 节点内部扩展。动态推测解码与 DP 不兼容--data-parallel-size 1时vLLM 会自动禁用num_speculative_tokens_per_batch_size回退到静态num_speculative_tokens见 Dynamic Speculative Decoding。当前内部负载均衡只基于各 engine 的运行/等待队列尚未纳入 KV cache 感知逻辑文档同时指出每个 DP engine 有独立 KV cacheprefix caching 的收益可通过更智能地导向 prompt 来最大化。外部负载均衡是另一种拓扑每个 DP rank 独立起服务、由外部路由器分发与本文的内部负载均衡方式不混用可参考 Data Parallel Deployment 的 External Load Balancing 一节。离线LLM类场景的 DP 示例见 data_parallel_offline.py。【免费下载链接】vllmA high-throughput and memory-efficient inference and serving engine for LLMs项目地址: https://gitcode.com/GitHub_Trending/vl/vllm创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 vLLM 如何用 --data-parallel-size 部署数据并行服务并配置跨节点 DP 与内部负载均衡
vLLM 如何用 --data-parallel-size 部署数据并行服务并配置跨节点 DP 与内部负载均衡【免费下载链接】vllmA high-throughput and memory-efficient inference and serving engine for LLMs项目地址: https://gitcode.com/GitHub_Trending/vl/vllm当单副本的 GPU 数量已经足够放下模型但吞吐量仍受限于单实例时可以用 vLLM 的数据并行Data Parallel部署模型权重在独立的 DP rankcore engine 进程之间复制各 rank 处理独立的请求批次。dense 和 MoE 模型都支持该模式对 DeepSeek 这类使用 MLA 的 MoE 模型文档还建议 attention 层用数据并行、expert 层用 EP/TP配合--enable-expert-parallel见 Expert Parallel Deployment。本文覆盖 vLLM 文档中“自包含”的在线部署方式只暴露一个 HTTP 入口负载均衡由 API server 进程内部完成以及跨节点拆分 DP rank 的配置。部署形态说明来自 Data Parallel Deployment。准备条件已安装 vLLM 并能执行vllm serve文档以 Linux GPU 环境为例单机多卡或多节点皆可。确定 GPU 数量--data-parallel-size N需要 N 张 GPU与张量并行组合时总数为 DP × TP例如--data-parallel-size4 --tensor-parallel-size2需要 8 张 GPU。容量规划注意区分作用域--max-num-seqs按 DP rank 生效而准入控制--max-num-queued-reqs和--max-num-queued-tokens作用于整个 server每个 API server 进程统计其路由到的所有 DP rank 的在途请求与 prefill 积压。文档举例--data-parallel-size4 --max-num-seqs256 --max-num-queued-reqs256时总请求数达到 256 就会开始拒绝新请求尽管 4 个 rank 合计可跑 1024 条。要让 rank 保持饱和文档建议把上限按data-parallel-size * max-num-seqs再加期望队列深度来设置。单机内部负载均衡内部负载均衡由 API server 进程完成依据是每个 engine 的运行中队列与等待队列对外只有一个 API 端点。单机 8 卡节点上跑 DP4、TP2vllm serve $MODEL --data-parallel-size 4 --tensor-parallel-size 2其中$MODEL替换为你要部署的模型Hugging Face 仓库 ID 或本地路径。MoE 模型的一个行为边界只要任一 rank 有请求在处理没有请求的 rank 也必须执行“dummy”前向以保持同步。这由一个独立的 DP Coordinator 进程管理它会与各 rank 通信并每隔 N 步做一次集合操作判断所有 rank 何时空闲、可以暂停。因此即使某些 rank 当前没有流量也不会真正空转释放资源。跨节点 DP 与内部负载均衡跨节点部署时每个节点各跑一个vllm serve用--data-parallel-size-local指明本节点承载几个 rank、用--data-parallel-start-rank指明起始 rank--data-parallel-address和--data-parallel-rpc-port在所有节点上保持一致。仍然只有一个 HTTP 入口API server 只在一个节点上运行且该节点不一定与 DP rank 同机。下面示例在两个节点上跑 DP4rank 0、1 在 head 节点IP 为 10.99.48.128rank 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 13345要点--data-parallel-size写的是全局 DP 总数所有节点相同--data-parallel-size-local是本节点的 rank 数各节点之和应等于全局总数。非 head 节点加--headless表示该节点不提供 API 入口只跑 engine。文档中 10.99.48.128 与 13345 是示例值替换为你的节点 IP 与 RPC 端口EP 文档注明该端口只要各节点可达即可$MODEL替换为模型。也可以让 API server 与 engine 完全分离head 节点用--data-parallel-size-local 0只挂 API server全部 rank 放在第二节点--data-parallel-size-local 4 --headless命令形式同上。可选分支Ray 后端DP 模式也可以用--data-parallel-backendray交给 Ray 管理只需在任意一个节点上执行单条启动命令所有本地与远程 DP rank 由 Ray 按集群节点资源分配vllm serve $MODEL --data-parallel-size 4 --data-parallel-size-local 2 \ --data-parallel-backendray与手动多节点方式的区别不需要--data-parallel-address执行命令的节点即地址也不需要--data-parallel-rpc-port。如果一个 DP group 需要跨多个节点单个模型副本要占至少两个节点需设置VLLM_RAY_DP_PACK_STRATEGYspan此时--data-parallel-size-local会被忽略并自动决定。Ray 是可选依赖需先安装见 Parallelism and Scaling。可选分支Hybrid 负载均衡Hybrid 模式介于内部与外部负载均衡之间每个节点跑自己的 API server只把请求排给本节点 colocated 的 DP engine由上游负载均衡器ingress 或流量路由器在节点端点间分发。用--data-parallel-hybrid-lb开启且每个节点仍要带全局--data-parallel-size。与内部负载均衡的差异必须提供--data-parallel-size-local和--data-parallel-start-rank让每个节点知道自己拥有哪些 rank与--headless不兼容因为每个节点都暴露 API 端点--api-server-count按本节点 rank 数单独设置。该模式把调度决策留在本地减少跨节点流量避免大 DP 规模下的单节点瓶颈。API server 扩进程--api-server-count用内部负载均衡做大 DP 时API server 进程本身可能成为瓶颈。此时用--api-server-count把 API server 横向扩出多个进程例如--api-server-count4对用户透明仍然只暴露一个 HTTP 端点/端口注意该扩展是“内部”的API server 仍限制在 head 节点。EP 文档在两节点示例中也推荐把--api-server-count放大到本地 rank 数--api-server-count8。结果验证服务启动后用文档列出的端点确认单入口正常工作# 健康检查 curl http://head节点IP:8000/health # 列出模型 curl http://head节点IP:8000/v1/models # 发送一条生成请求 curl http://head节点IP:8000/v1/completions \ -H Content-Type: application/json \ -d { model: $MODEL, prompt: San Francisco is a, max_tokens: 7, temperature: 0 }这些端点/health、/v1/models、/load服务器负载指标、/v1/completions在 Online Serving 中列明。内部负载均衡下所有节点上的 engine 都通过这一个入口接收请求hybrid 模式下则改为对每个节点的端点分别做同样检查由上游负载均衡器负责分发。排查与限制跨节点起不来、rank 间通信失败时先检查--data-parallel-address指向的节点 IP 与各节点上 RPC 端口是否互通分布式部署的通用问题见 Troubleshooting distributed deployments。MoE 模型下有请求在任一 rank 进行时其余 rank 会执行 dummy 前向保持同步——这是文档说明的设计行为不是故障。大 DP 规模下请求吞吐受限于 API server 单进程时加--api-server-count仅限 head 节点内部扩展。动态推测解码与 DP 不兼容--data-parallel-size 1时vLLM 会自动禁用num_speculative_tokens_per_batch_size回退到静态num_speculative_tokens见 Dynamic Speculative Decoding。当前内部负载均衡只基于各 engine 的运行/等待队列尚未纳入 KV cache 感知逻辑文档同时指出每个 DP engine 有独立 KV cacheprefix caching 的收益可通过更智能地导向 prompt 来最大化。外部负载均衡是另一种拓扑每个 DP rank 独立起服务、由外部路由器分发与本文的内部负载均衡方式不混用可参考 Data Parallel Deployment 的 External Load Balancing 一节。离线LLM类场景的 DP 示例见 data_parallel_offline.py。【免费下载链接】vllmA high-throughput and memory-efficient inference and serving engine for LLMs项目地址: https://gitcode.com/GitHub_Trending/vl/vllm创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考