https://docs.vllm.ai/en/latest/serving/data_parallel_deployment/#internal-load-balancing好的这是对 vLLM 文档中“混合负载均衡 (Hybrid Load Balancing)”部分的翻译和解释混合负载均衡 (Hybrid Load Balancing)混合负载均衡是介于内部负载均衡和外部负载均衡之间的一种方法。在这种模式下每个节点都会运行它自己的 API 服务器但这些 API 服务器只将请求分发给与它们位于同一个节点上的数据并行引擎。然后一个上游的负载均衡器例如Kubernetes 的 Ingress 控制器或专门的流量路由器负责将用户的请求分散到这些分布在不同节点上的 API 端点。你可以通过使用--data-parallel-hybrid-lb参数来启用此模式同时仍然需要在启动每个节点时指定全局的数据并行总规模。与内部负载均衡模式相比其关键区别在于你必须提供--data-parallel-size-local和--data-parallel-start-rank这两个参数以便每个节点都清楚地知道它负责管理哪些 rank引擎。此模式不兼容--headless参数因为每个节点都需要暴露一个自己的 API 端点来接收流量。你可以根据每个节点上本地 rank引擎的数量来调整--api-server-count的值。在这种配置下每个节点都将调度决策保持在本地这减少了跨节点的通信流量并避免了在数据并行规模较大时可能出现的单节点瓶颈问题。核心思想解读 (用一个例子来解释)想象一个有 2 个节点Node 0, Node 1、总共 4 个Engine Core的集群 (--data-parallel-size4)。内部负载均衡 (Internal LB) 的做法是只有Node 0运行 API 服务器。所有用户的 HTTP 请求都打到 Node 0。Node 0 上的 API 服务器会把请求分发给 Node 0 上的引擎rank 0, 1和Node 1 上的引擎rank 2, 3。这会产生大量的跨节点 ZMQ 通信。混合负载均衡 (Hybrid LB) 的做法是Node 0和Node 1都运行自己的 API 服务器。你在集群的最前面放一个简单的负载均衡器比如 Nginx 或云服务商提供的 LB它会把 50% 的用户请求发给 Node 0 的 API另外 50% 发给 Node 1 的 API。关键点当一个请求到达Node 0的 API 服务器时它只会在本地的引擎rank 0, 1之间做选择。它永远不会把请求发给 Node 1。同理当一个请求到达Node 1的 API 服务器时它也只会在本地的引擎rank 2, 3之间做选择。优点没有跨节点调度流量API 服务器和它调度的Engine Core都在同一台机器上通信通过更高效的本地 IPC 进行网络开销大大降低。扩展性更好没有一个单一的“主节点”来处理所有的 API 请求和调度决策避免了主节点成为性能瓶颈。每个节点都是一个自给自足的“小集群”。这个问题问得非常到位它被称为“Hybrid” (混合)是因为它巧妙地融合了“内部负载均衡”和“外部负载均衡”这两种模式的核心思想。我们可以把它理解为一个“两层”的负载均衡策略第 1 层 (外部的)一个独立于 vLLM 的、上游的负载均衡器。第 2 层 (内部的)vLLM 在每个节点内部自带的、本地化的负载均衡器。下面我们来分解一下它到底“混合”了什么。它从“外部负载均衡”那里借鉴了什么借鉴了“多入口、分散流量”的思想。在纯粹的外部负载均衡模式下你会启动多个完全独立的 vLLM 服务然后用一个外部工具如 Nginx、HAProxy 或云服务商的 LB将 HTTP 请求以轮询等方式分发给这些独立的服务。这个外部工具对 vLLM 内部一无所知。Hybrid 模式也这么做它同样依赖一个外部的、上游的负载均衡器来将用户的 HTTP 请求分发到不同的节点上。这是它的“外部”特性。[用户请求] - [外部 LB] - [Node 0 API] 或 [Node 1 API] 或 ...它从“内部负载均衡”那里借鉴了什么借鉴了“智能调度、感知引擎状态”的思想。在纯粹的内部负载均衡模式下只有一个 API 入口在主节点上这个 API 服务器非常“聪明”。它通过DP Coordinator了解集群中所有Engine Core包括远程的的实时负载然后做出最优的、精细化的调度决策。Hybrid 模式在每个节点内部也这么做每个节点上的API Server同样是“聪明”的但它的视野被限定在了本地。它会感知本节点上所有Engine Core的负载状态并智能地将请求分发给本地最空闲的那个引擎。这是它的“内部”特性。[Node 0 API] - (感知本地引擎负载) - [Node 0 Engine 0] 或 [Node 0 Engine 1][Node 1 API] - (感知本地引擎负载) - [Node 1 Engine 2] 或 [Node 1 Engine 3]总结混合的本质Hybrid Load Balancing (外部的、粗粒度的 HTTP 流量分发) (内部的、精细化的本地引擎调度)所以“Hybrid” 这个词非常贴切因为它不是单纯的外部模式因为节点内部有智能调度也不是单纯的内部模式因为流量的初次分发是由外部完成的且调度范围是本地化的。对比项内部负载均衡 (Internal)外部负载均衡 (External)混合负载均衡 (Hybrid)API 入口单一入口 (主节点)多个独立入口多个节点级入口负载均衡器vLLM 自身 (API Server Coordinator)外部工具 (Nginx, LB…)外部工具 vLLM 自身(混合)调度范围全局(所有节点的所有引擎)无(每个服务是孤岛)本地(仅限本节点的引擎)跨节点流量高(API Server需要与远程引擎通信)无(服务间不通信)低/无(调度流量都在节点内部)核心思想中央集权全局最优完全分散各自为政联邦制分而治之结论Hybrid模式取了两种模式的优点它通过外部负载均衡实现了流量入口的横向扩展避免了内部模式下的单主节点瓶颈。它通过内部本地化调度实现了对计算资源的高效利用避免了外部模式下“盲目”分发请求可能导致的资源不均。因此它是一种兼具扩展性和效率的“混合体”。好的这是对 vLLM 文档中“外部负载均衡 (External Load Balancing)”部分的翻译和解释。外部负载均衡 (External Load Balancing)特别是对于更大规模的部署将数据并行 (DP) rank 的编排和负载均衡交由外部系统来处理是一种更合理的方式。在这种情况下更方便的做法是将每一个 DP rank 都视为一个独立的 vLLM 部署让它拥有自己独立的 API 端点。然后由一个外部的路由器External Router在这些端点之间分发 HTTP 请求并可以利用从每个服务器获取的实时遥测数据或状态指标来做出路由决策。对于非 MoE混合专家模型这种方式已经可以非常简单地实现因为每个部署的服务器都是完全独立的。这种场景下甚至不需要使用任何数据并行的命令行选项。我们也为MoE DPEP数据并行专家并行模型支持了一种等价的拓扑结构可以通过以下命令行参数进行配置。如果 DP ranks 位于同一位置即同一个节点/IP 地址系统会使用一个默认的 RPC 端口但你必须为每个 rank 指定一个不同的 HTTP 服务器端口# Rank 0CUDA_VISIBLE_DEVICES0vllm serve$MODEL--data-parallel-size2--data-parallel-rank0\--port8000# Rank 1CUDA_VISIBLE_DEVICES1vllm serve$MODEL--data-parallel-size2--data-parallel-rank1\--port8001对于多节点的情况还必须指定 rank 0 的地址和端口# Rank 0 (IP 地址为 10.99.48.128)vllm serve$MODEL--data-parallel-size2--data-parallel-rank0\--data-parallel-address10.99.48.128 --data-parallel-rpc-port13345# Rank 1vllm serve$MODEL--data-parallel-size2--data-parallel-rank1\--data-parallel-address10.99.48.128 --data-parallel-rpc-port13345在这种场景下协调器Coordinator进程也会运行并与 DP rank 0 的引擎位于同一位置。核心思想解读这种模式的核心思想是**“完全去中心化”和“各自为政”**。你可以把每个vllm serve进程想象成一个独立的、自给自足的“小王国”。每个“小王国”DP rank都有自己的大门--port指定的 HTTP 端口。你作为“总指挥”在这些“小王国”的前面部署了一个“交通调度员”外部负载均衡器如 Nginx, Traefik, K8s Ingress 等。当一个外部请求到来时“交通调度员”会根据自己的规则比如轮询、或者查看哪个“小王国”的报告说自己比较空闲来决定把这个请求送进哪个“小王国”的大门。一旦请求进入某个“小王国”它就在内部被处理掉了vLLM 自身不再进行任何跨“王国”的负载均衡。与混合模式的关键区别混合模式 (Hybrid)外部 LB 把流量分发到节点。节点内部的 vLLM API Server 再智能地把请求分发给节点内的多个引擎。这是一个“外部粗分发 内部精细调度”的两级结构。外部模式 (External)外部 LB 直接把流量分发到每一个独立的引擎rank。vLLM 自身完全不参与负载均衡决策。每个vllm serve进程就是一个独立的、最小的服务单元。为什么 MoE 模型需要特别处理这是这篇文档中最关键、最微妙的一点。对于普通模型数据并行是“无共享”的每个 rank 都有模型的完整副本。它们之间不需要通信所以你可以把它们当作完全独立的服务器来运行根本不需要--data-parallel-size等参数。对于 MoE 模型情况完全不同。模型的“专家Experts”是被**分散sharded**在所有 DP rank 上的。例如rank 0 可能拥有专家 1-4rank 1 可能拥有专家 5-8。当处理一个请求时模型可能需要同时调用位于不同 rank 上的专家。这就意味着即使在外部负载均衡模式下这些看似独立的 MoE rank 之间也必须保持某种形式的通信和协调以同步它们的计算步骤比如“请求波次”。这就是为什么文档最后特意强调“协调器Coordinator进程也会运行”并且需要用--data-parallel-size,--data-parallel-address等参数来让它们找到彼此。Coordinator在这里的作用不是进行负载均衡而是确保所有 MoE rank 能够作为一个整体协同完成每一次推理计算。Hybrid Load Balancing 详解Hybrid Load Balancing 是 vLLM 数据并行部署的中间模式结合了内部和外部负载均衡的特点。每个节点运行自己的 API 服务器只处理本地数据并行引擎的请求通过上游负载均衡器分发用户请求。 1核心特征1. 架构设计本地调度每个节点的 API 服务器只调度本地引擎上游负载均衡外部负载均衡器如 ingress controller在节点间分发请求全局配置所有节点仍使用全局数据并行大小配置2. 必需参数# 配置验证逻辑ifself.data_parallel_hybrid_lbanddata_parallel_size_local1:# 自动切换到外部LB模式data_parallel_external_lbTrueself.data_parallel_hybrid_lbFalse[2](#22-1)### 3. API 服务器自动配置pythonelifis_hybrid_lb:args.api_server_countargs.data_parallel_size_localor1[3](#22-2)## 配置示例bash# Node 0vllm serve $MODEL--data-parallel-size4--data-parallel-size-local2\--data-parallel-start-rank0--data-parallel-hybrid-lb# Node 1vllm serve $MODEL--data-parallel-size4--data-parallel-size-local2\--data-parallel-start-rank2--data-parallel-hybrid-lb优势减少跨节点流量调度决策本地化避免节点间通信开销避免单点瓶颈每个节点独立处理请求无中心化瓶颈扩展性更好适合大规模 DP 部署场景 4实现机制系统通过data_parallel_hybrid_lb标志识别混合模式 5data_parallel_hybrid_lb:boolFalseWhether to use hybrid DP LB mode. Applies only to online serving and when data_parallel_size 0. Enables running an AsyncLLM and API server on a per-node basis where vLLM load balances between local data parallel ranks, but an external LB balances between vLLM nodes/replicas.Notes混合负载均衡模式特别适合多节点大规模部署它通过本地化调度和外部负载均衡的结合实现了高性能和高可扩展性的平衡。每个节点都需要暴露 API 端点因此不兼容--headless模式。 6Wiki pages you might want to explore:Overview (vllm-project/vllm)CitationsFile:docs/serving/data_parallel_deployment.md (L83-94)## Hybrid Load Balancing Hybrid load balancing sits between the internal and external approaches. Each node runs its own API server(s) that only queue requests to the>ifself.data_parallel_hybrid_lbanddata_parallel_size_local1:# Use full external lb if we have local_size of 1.logger.warning(data_parallel_hybrid_lb is not eligible when data_parallel_size_local 1, autoswitch to data_parallel_external_lb.)data_parallel_external_lbTrueself.data_parallel_hybrid_lbFalseFile:vllm/entrypoints/cli/serve.py (L89-90)elifis_hybrid_lb:args.api_server_countargs.data_parallel_size_localor1File:vllm/entrypoints/cli/serve.py (L148-149)ifengine_args.data_parallel_hybrid_lb:raiseValueError(data_parallel_hybrid_lb is not applicable in headless mode)File:vllm/config/parallel.py (L126-132)data_parallel_hybrid_lb:boolFalseWhether to use hybrid DP LB mode. Applies only to online serving and when data_parallel_size 0. Enables running an AsyncLLM and API server on a per-node basis where vLLM load balances between local data parallel ranks, but an external LB balances between vLLM nodes/replicas. Set explicitly in conjunction with --data-parallel-start-rank.