不增加 GPU，首 Token 延迟下降 50%｜LLM 服务负载均衡的新实践-低调大师

不增加 GPU，首 Token 延迟下降 50%｜LLM 服务负载均衡的新实践

2025-08-26 136

作者：钰诚

简介

传统的负载均衡算法主要设计用于通用的 Web 服务或微服务架构中，其目标是通过最小化响应时间、最大化吞吐量或保持服务器负载平衡来提高系统的整体效率，常见的负载均衡算法有轮询、随机、最小请求数、一致性哈希等。然而，在面对 LLM 服务时，这些传统方法往往暴露出以下几个关键缺陷：

忽略任务复杂度差异：LLM 推理请求的复杂度差异极大。例如，一个长文本生成任务可能需要数十倍于短文本分类任务的计算资源。而传统负载均衡器无法感知这种差异，容易导致某些节点过载，而其他节点空闲，造成资源浪费和响应延迟。
缺乏对 GPU 资源水位的感知：在 LLM 推理服务中，计算瓶颈主要集中在 GPU 上，传统负载均衡器往往无法感知到这一细粒度的资源消耗情况，导致某些 GPU 节点因显存不足而拒绝请求或响应缓慢，而其他节点却处于空闲状态。
缺乏对 KV Cache 的复用能力：在并发请求处理中，如果多个请求具有相似的前缀，则它们的 KV Cache 可能存在重叠部分，可以通过共享或压缩的方式减少显存占用并提升生成速度。传统负载均衡策略并未考虑请求之间的语义相似性或 KV Cache 的可复用性，难以将具有潜在复用价值的请求分配到同一 GPU 实例上，从而错失优化机会。

针对 LLM 服务的特点，Higress AI 网关以插件形式提供了面向 LLM 服务的负载均衡算法，包括全局最小请求数负载均衡、前缀匹配负载均衡以及 GPU 感知负载均衡，能够在不增加硬件成本的前提下，提升系统的吞吐能力、降低响应延迟，并实现更公平、高效的任务调度。

以前缀匹配负载均衡为例，压测工具使用 NVIDIA GenAI-Perf，设置每轮输入平均为 200 token，输出平均为 800 token，并发为 20，每个会话包含 5 轮对话，共计 60 个会话，性能指标前后对比如下：

技术选型

目前已经有很多优秀的开源项目，例如 Envoy AI Gateway、AIBrix 等，基于 Envoy External Processing 机制外接一个负载均衡器实现面向 LLM 的负载均衡，负载均衡器以 sidecar 或者 K8s 服务形式部署。

Higress AI 网关以 wasm 插件形式提供了面向 LLM 服务的核心负载均衡能力，具有如下特点：

免运维：以 wasm 形式提供负载均衡能力，不需要用户额外维护 sidecar，只需要在 Higress 控制台开启插件即可，部署运维成本大大降低。
热插拔：即插即用，用户仅需要在控制台进行策略配置即可，开启插件时采用面向 LLM 服务的专属负载均衡策略，关掉插件后自动切换为服务基础的负载均衡策略（轮询、最小请求数、随机、一致性哈希）。
易扩展：插件本身提供了多种负载均衡算法，并且在不断丰富完善中，采用 go 1.24 编写，代码开源，如果有特殊需求，用户可以基于现有插件进行定制。
全局视野：借助 Redis，网关的多个节点具有全局视野，负载均衡更加公平、高效。
细粒度控制：插件可以在实例级、域名级、路由级、服务级等不同粒度进行生效，方便用户做细粒度的控制。

负载均衡算法介绍

接下来，本文会介绍 Higress AI 网关提供的三种负载均衡算法：全局最小请求数负载均衡、前缀匹配负载均衡、GPU 感知负载均衡。

全局最小请求数负载均衡

在分布式环境中，网关实例往往具有多个节点，传统的负载均衡策略是每个节点做局部的负载均衡，缺乏全局视野。在 Higress AI 网关中，我们借助 Redis 实现了全局最小请求数负载均衡算法，根据每个 LLM Pod 上正在处理的请求数进行负载均衡。

选取 Pod 的大致流程如下：

在全局最小请求数负载均衡中我们重点关注了请求异常（例如后端服务不可访问、客户端断连、服务端断连等）情况下的处理，通过在 HttpStreamDone 阶段统一进行计数的变更可以保证异常中断的请求也能够得到计数的更新，避免因请求异常导致服务计数异常情况。

前缀匹配负载均衡

在多轮对话场景下，一次会话会涉及多次 LLM 的调用，多次调用时请求携带了相同的上下文信息，如果能够感知上下文信息并将同属一个会话的多次请求路由到相同的 LLM Pod 中，将能够充分利用 LLM Pod 的 KV Cache，从而大幅提高请求的 RT、Token 吞吐等性能指标。

在 Higress AI 网关中，我们借助 Redis 实现了全局的前缀匹配负载均衡算法，能够充分适应分布式环境，在请求到达网关时，会根据当前的前缀树信息进行前缀匹配，如果能够匹配成功，则会路由至对应 LLM Pod，如果匹配不到前缀，则会根据全局最小请求数负载均衡方法选出当前处理请求最小的 LLM Pod。

选取 Pod 的大致流程如下：

接下来简单介绍如何在 Redis 中构建前缀树。

首先将 LLM 请求的 messages 以 user 为界限划分为不同的 block，并通过哈希获得一个 16 进制字符串，如下图所示，messages 被划分为两个 block，并且计算了每个 block 的 sha-1 值：

假设有一个请求被划分成了 n 个 block，在进行前缀匹配时：

1）在 redis 中查询 sha-1(block 1) 是否存在

如果不存在，前缀匹配失败，采用全局最小请求数选择 pod，pod 选取结束，根据当前请求内容更新前缀树
如果存在，前缀匹配成功，记录当前的 pod，转步骤 2

2）在 redis 中查询 sha-1(block 1) XOR sha-1(block 2) 是否存在

如果不存在，前缀匹配失败，步骤1中选出来的 pod 即为目标 pod，根据当前请求内容更新前缀树，pod 选取结束
如果存在，前缀匹配成功，转步骤 3

3）在 redis 中查询 sha-1(block 1) XOR sha-1(block 2) XOR ... XOR sha-1(block n) 是否存在

如果不存在，前缀匹配失败，步骤 2 中选出来的 pod 即为目标 pod，根据当前请求内容更新前缀树，pod 选取结束
如果存在，前缀匹配成功，pod 选取结束

通过以上过程，能够将同一个会话的多次请求路由至同一个 pod，从而提高 KV Cache 的复用。

GPU 感知负载均衡

一些 LLM Server 框架（如 vllm、sglang 等）自身会暴露一些监控指标，这些指标能够实时反应 GPU 负载信息，基于这些监控指标可以实现 GPU 感知的负载均衡算法，使流量调度更加适合 LLM 服务。

目前已经有一些开源项目基于 envoy ext-proc 机制实现了 GPU 感知的负载均衡算法，但 ext-proc 机制需要借助一个外部进程，部署与维护较为复杂，Higress AI 网关实现了后台定期拉取 metrics 的机制（目前支持 vllm），以热插拔的插件形式提供了 GPU 感知的负载均衡能力，并且场景不局限于 K8s 环境，任何 Higress AI 网关支持的服务来源均可使用此能力。

选取 Pod 的大致流程如下：

目前基于 metrics 的负载均衡策略遵循了 gateway-api-inference-extension【1】的 pod 选取算法，根据 LoRA Adaotor 亲和、队列长度、KV Cache 使用率进行负载均衡，选取过程如下图所示：

使用方法

以前缀匹配负载均衡为例：

准备 Redis 资源：登录阿里云 Redis 控制台【2】，创建Redis实例，并设置连接密码。具体操作，请参见 Redis 快速入门概览【3】。
准备 LLM 服务：以 ECS 形式基于 vllm 框架部署 llama3 模型，共 3 个节点。
在网关配置服务：在网关实例中导入 Redis 服务以及 LLM 服务，其中 redis 为DNS类型服务，llama3 为固定地址类型服务。

在网关配置 API：在网关中创建一个 LLM API，后端服务指向 llama3.

在网关配置插件：在插件市场找到 ai-load-balancer 插件进行安装，然后在 LLM API 粒度下给刚才创建的 LLM API 配置负载均衡策略。

插件配置示例如下：

lb_policy: prefix_cache
lb_config:
  serviceFQDN: redis.dns
  servicePort: 6379
  username: default
  password: xxxxxxxxxxxx
  redisKeyTTL: 60

附录：压测结果与 vllm 监控大盘

无负载均衡

GenAI-Perf 统计结果如下：

vllm 监控如下：

前缀匹配负载均衡

GenAI-Perf 统计结果如下：

vllm 监控如下：

性能瓶颈定位更快更准：ARMS 持续剖析能力升级解析

作者：铖朴、穆司持续剖析介绍随着软件技术发展迭代，很多企业软件系统也逐步从单体应用向云原生微服务架构演进，一方面让应用实现高并发、易扩展、高开发敏捷度等效果，但此外也让软件应用链路变得越来越长，依赖的各种外部技术越来越多，一些线上问题排查起来变得困难重重。尽管经过过去十几年的发展，分布式系统与之对应的可观测技术快速演进，在一定程度上解决了很多问题，但有一些问题定位起来仍然很吃力，如下图是几个非常有代表性的线上常见问题：持续性能剖析技术是一种通过采集应用相关线程在申请相关资源时的方法栈状态信息，再通过火焰图等可视化技术绘制出对应资源使用分布情况，最后，确定相关时段特定资源波动根因的一种强有力技术。开箱即用的持续剖析能力阿里云应用可观测产品 - 应用实时监控服务 ARMS 早在 2022 年就上线了持续剖析产品能力，帮助用户定位常见的性能方面疑难问题：具体而言，其主要包含以下 3 块核心功能：代码热点【1】：其通过墙钟热点关联 Trace 信息，可帮助用户定位：当业务太复杂，偶发性慢调用无法复现时，代码热点可为您还原代码真实方法层面的执行轨迹。当调用链中因为缺失对应用代...

2025-08-26

110

1 概述 1.1 案例介绍仓颉编程语言作为一款面向全场景应用开发的现代编程语言，通过现代语言特性的集成、全方位的编译优化和运行时实现、以及开箱即用的 IDE工具链支持，为开发者打造友好开发体验和卓越程序性能。案例结合代码体验，让大家更直观的了解仓颉语言中的IO操作。 1.2 适用对象个人开发者高校学生 1.3 案例时间本案例总时长预计40分钟。 1.4 案例流程说明：进入华为开发者空间，登录云主机；使用CodeArts IDE for Cangjie编程和运行仓颉代码。 1.5 资源总览资源名称规格单价（元）时长（分钟）开发者空间 - 云主机鲲鹏通用计算增强型 kc2 | 4vCPUs | 8G | Ubuntu 免费免费 40 仓颉之I/O操作的交互奥秘👈👈👈体验完整版案例，点击这里。 2 运行测试环境准备 2.1 开发者空间配置面向广大开发者群体，华为开发者空间提供一个随时访问的“开发桌面云主机”、丰富的“预配置工具集合”和灵活使用的“场景化资源池”，开发者开箱即用，快速体验华为根技术和资源。领取云主机后可以直接进入华为开发者空间工作台界面，...

2025-08-27

121

资源下载

更多资源

优质分享App

近一个月的开发和优化，本站点的第一个app全新上线。该app采用极致压缩，本体才4.36MB。系统里面做了大量数据访问、缓存优化。方便用户在手机上查看文章。后续会推出HarmonyOS的适配版本。

Mario

马里奥是站在游戏界顶峰的超人气多面角色。马里奥靠吃蘑菇成长，特征是大鼻子、头戴帽子、身穿背带裤，还留着胡子。与他的双胞胎兄弟路易基一起，长年担任任天堂的招牌角色。

Spring

Spring框架（Spring Framework）是由Rod Johnson于2002年提出的开源Java企业级应用框架，旨在通过使用JavaBean替代传统EJB实现方式降低企业级编程开发的复杂性。该框架基于简单性、可测试性和松耦合性设计理念，提供核心容器、应用上下文、数据访问集成等模块，支持整合Hibernate、Struts等第三方框架，其适用范围不仅限于服务器端开发，绝大多数Java应用均可从中受益。

Rocky Linux

Rocky Linux（中文名：洛基）是由Gregory Kurtzer于2020年12月发起的企业级Linux发行版，作为CentOS稳定版停止维护后与RHEL（Red Hat Enterprise Linux）完全兼容的开源替代方案，由社区拥有并管理，支持x86_64、aarch64等架构。其通过重新编译RHEL源代码提供长期稳定性，采用模块化包装和SELinux安全架构，默认包含GNOME桌面环境及XFS文件系统，支持十年生命周期更新。