不增加 GPU,首 Token 延迟下降 50%|LLM 服务负载均衡的新实践
作者:钰诚
简介
传统的负载均衡算法主要设计用于通用的 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 监控如下:
相关链接:
【1】gateway-api-inference-extension
https://github.com/kubernetes-sigs/gateway-api-inference-extension/tree/main
【2】阿里云 Redis 控制台
https://kvstore.console.aliyun.com/Redis/instance/cn-hangzhou
【3】Redis 快速入门概览
https://help.aliyun.com/zh/redis/getting-started/overview
🔥🔥拥抱 AI 原生!
8月29日深圳,企业实践工作坊火热报名中!
阿里云诚挚邀请您参加【AI 原生,智构未来------AI 原生架构与企业实践】工作坊,从开发范式到工程化实践,全链路解析AI原生架构奥秘,与AI先行者共探增长新机遇。
⬇️ 点击此处,立即了解完整议程!

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
性能瓶颈定位更快更准:ARMS 持续剖析能力升级解析
作者:铖朴、穆司 持续剖析介绍 随着软件技术发展迭代,很多企业软件系统也逐步从单体应用向云原生微服务架构演进,一方面让应用实现高并发、易扩展、高开发敏捷度等效果,但此外也让软件应用链路变得越来越长,依赖的各种外部技术越来越多,一些线上问题排查起来变得困难重重。 尽管经过过去十几年的发展,分布式系统与之对应的可观测技术快速演进,在一定程度上解决了很多问题,但有一些问题定位起来仍然很吃力,如下图是几个非常有代表性的线上常见问题: 持续性能剖析技术是一种通过采集应用相关线程在申请相关资源时的方法栈状态信息,再通过火焰图等可视化技术绘制出对应资源使用分布情况,最后,确定相关时段特定资源波动根因的一种强有力技术。 开箱即用的持续剖析能力 阿里云应用可观测产品 - 应用实时监控服务 ARMS 早在 2022 年就上线了持续剖析产品能力,帮助用户定位常见的性能方面疑难问题: 具体而言,其主要包含以下 3 块核心功能: 代码热点【1】:其通过墙钟热点关联 Trace 信息,可帮助用户定位: 当业务太复杂,偶发性慢调用无法复现时,代码热点可为您还原代码真实方法层面的执行轨迹。 当调用链中因为缺失对应用代...
- 下一篇
仓颉之I/O 操作的交互奥秘
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 开发者空间配置 面向广大开发者群体,华为开发者空间提供一个随时访问的“开发桌面云主机”、丰富的“预配置工具集合”和灵活使用的“场景化资源池”,开发者开箱即用,快速体验华为根技术和资源。 领取云主机后可以直接进入华为开发者空间工作台界面,...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- SpringBoot2编写第一个Controller,响应你的http请求并返回结果
- CentOS关闭SELinux安全模块
- Docker安装Oracle12C,快速搭建Oracle学习环境
- MySQL8.0.19开启GTID主从同步CentOS8
- Jdk安装(Linux,MacOS,Windows),包含三大操作系统的最全安装
- Windows10,CentOS7,CentOS8安装MongoDB4.0.16
- CentOS7编译安装Cmake3.16.3,解决mysql等软件编译问题
- CentOS7设置SWAP分区,小内存服务器的救世主
- Eclipse初始化配置,告别卡顿、闪退、编译时间过长
- Linux系统CentOS6、CentOS7手动修改IP地址