首页 文章 精选 留言 我的

精选列表

搜索[递归下降解析器],共10000篇文章
优秀的个人博客,低调大师

不增加 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先行者共探增长新机遇。 ⬇️ 点击此处,立即了解完整议程!

优秀的个人博客,低调大师

rt下降40%?程序并行优化六步法 | 京东云技术团队

1 背景 性能优化是我们日常工作中很重要的一部分,主要有以下原因: 降低服务器和带宽等硬件成本:用更少的资源处理更多的请求 提高现实世界的运行效率:人机处理效率存在数量级的偏差,同样机器世界的效率提升能带来现实世界效率提升的方法效果 提高用户的体验:解决响应缓慢、宕机等问题 而并行优化在改善程序接口响应时间和吞吐量指标方面是个利器,所以本次结合前段时间做的一段长链路执行逻辑代码的优化,给大家讲讲程序并行优化的步骤及方法论。 2 多线程优化六步法 2.1 定位优化点 一般是通过全链路监控、火焰图、自定义打点、生产报警等先找到耗时长的性能问题点,之后通过多线程并行化的方式达到优化程序响应时长和吞吐量的目的。 2.2 执行链路分析 对问题点的执行链路进行分析,主要分几方面: 链路里涉及的操作节点; 节点自身的耗时;是io密集型还是cpu密集型;是否依赖和修改外部变量;此节点是否是核心路径; 节点间彼此依赖关系; 2.3 异步链路设计 将链路根据依赖关系进行重排,把被依赖的放在前面; 彼此不依赖有相同起点的节点并行化;设计并行任务结果获取及后续依赖节点的通知机制 如果有指定响应时间目标的链路,为核心路径节点设计降级方案;根据响应时间要求及已耗时数据对非核心路径节点调用进行舍弃; 将对变量修改的逻辑收拢,且尽量在主线程中处理,避免需要做的多线程变量可见性和时序性同步 2.4 并发框架选择 1.线程池 描述:具体业务任务继承接口 Runnable、Callable ,在调用 ExecutorService.submit 接口时,会提交任务到 ExecutorService 内部的一个任务队列中。同时,在 ExecutorService 内部还存在一个预先申请的线程池(Thread Pool),线程池中的线程会从任务队列中领取一个任务来执行。 优点:复用线程,减少线程创建销毁成本及减少请求时延 注意点:cpu密集型和io密集型任务应进行不同的线程池配置;为避免不同任务相互干扰重要业务最好独立使用线程池;不同线程之间要注意操作的有序和数据的可见性 2.AKKA 描述:每个 Actor 代表的是可以被调度执行的轻量单元。如图中所示,Actor A 和 Actor C 在向 Actor B 发送消息时,所有消息会被底层框架发送到 Actor B 的 Mailbox 中,然后底层的 Akka 框架调度代码会触发 Actor B,来接收并执行消息的后续处理。这样,基于 Actor 模型的这套并发框架,首先就保证了消息可以被安全地在各个 Actor 之间传递,同时也保证了每个 Actor 实例可以串行处理接收到的所有消息。 优点:不需要关注多线程之间并发同步和数据一致性;轻量级高并发 注意点:actor任务粒度要小,避免承接太多业务逻辑;计算密集型任务更能发挥出AKKA的优势 3.REACTOR 描述:输入流 Flux 就是 Reactor 中典型的异步消息流,它代表了一个包含 0 个到 N 个的消息序列。另外,图中的 Rule 代表的是一个基于消息的处理逻辑或规则,输入流中的消息可以被中间多个处理逻辑组合连续加工之后,再生成一个包含 0 个到 N 个的输出消息流 Flux。 优点:rule采用pull处理消息,避免消息积压;异步非阻塞io,避免阻塞当前线程 注意点:函数式编程,会有一定的语法学习成本和理解成本;针对消息流处理的、基于 IO 密集型的异步交互场景比较有优势 2.5 并发工具选择 多线程执行涉及到一系列细节问题,如共享变量可见性,执行顺序,结果的获取、后续操作的通知等,所以要结合需求使用一系列相关的并发工具类做多线程执行正确性的保障 2.6 效果验证 1.压测 一般通过jmeter、loadrunner等后端性能测试软件,不断对系统施加压力,并验证系统化处于或长期处于临界饱和阶段的稳定性以及性能指标,并试图找到系统处于临界状态时的主要瓶颈点。 注意点: 完全相同的环境以及测试负载 注意混部情况其他服务可能对验证服务造成的影响 通过加压减压调整请求量观察服务器处理能力的变化及稳定性 2.性能指标验证 验证并发用户数、响应时间及吞吐量这种调优目标量; 观察服务器的负载指标,防止因优化带来服务器超出负载能力; 观察上下游服务的业务指标和服务器负载,防止因优化带来上下游超出负载能力 3.业务结果验证 一般通过diff工具通过采集相同请求的响应对比判别是否影响业务;也可通过qa辅助构建针对改动的测试集去做验证 3 举例 以我们前段时间进行的商品主数据下发消费能力调优进行举例说明整个优化过程: 3.1 优化点定位 主数据程序接收商品批量下发处理缓慢,触发下发积压报警 3.2 执行链路分析 梳理各步骤对入参和保存时需要的变量的处理,分析各步骤相互依赖关系,是否可并行,进行执行过程优化调整。 商品主数据处理步骤分析: 3.3 异步链路设计 1、 3、4、5异步并行处理,且因对其他变量修改逻辑无依赖,放在最前面提交。 2、7、8、9、10、11根据依赖关系,把相关性的逻辑收拢,把被依赖的逻辑提前。 13也异步提交。最后通过completionService.take().get()遍历获取各任务执行结果进行合并返回最终结果 3.4 并发框架选择 出于团队知识栈及框架应用场景综合考虑,这里选择了线程池作为并发框架,并结合多io场景做了线程池参数配置。 /** * io任务线程池 */ public static ThreadPoolExecutor threadPoolExecutorForIO= new ThreadPoolExecutor(Runtime.getRuntime().availableProcessors(),Runtime.getRuntime().availableProcessors()*2,1, TimeUnit.MINUTES,new ArrayBlockingQueue(2014),new ThreadPoolExecutor.CallerRunsPolicy()); 3.5 并发工具选择 这里使用CompletionService来获取多线程的执行结果,并进行结果归集。 CompletionService通过在线程结果完成时提交到阻塞队列,避免通过遍历future结果的方式导致先提交的任务耗时长造成的阻塞等待。 CountingExecutorCompletionService<Boolean> completionService= new CountingExecutorCompletionService(ExecutorCollector.threadPoolExecutorForIO); //任务提交 completionService.submit(callableA); //结果归集 boolean result=true; for(int i = 0; i<completionService.getSubmittedTaskCount(); i++) { result&=completionService.take().get(); } 3.6 效果验证 1.压测 采用jmeter对两台相同配置的服务器(分别部署优化版本和原始版本)加压,观察服务负载情况 2.性能指标验证 1)耗时和吞吐量异步版本要优于同步版本 异步版本耗时在80-100ms,同步版本耗时在120-160ms 异步版本吞吐量在17000/5分钟,同步版本吞吐量在15000/5分钟 2)cpu使用率异步版本略高一点,线程数异步版本比较高 线程数高的原因:用到了线程池,预置的核心线程数为逻辑核数64,因为涉及到io操作较多,最大线程数配成了128。 3.业务结果验证 因为公司框架不支持http的diff,此处采用了自己抽检请求结果及qa协助走查和code review的方式保证业务结果的准确性 4 总结 程序性能优化方法关系到方方面面,而多线程异步优化无疑是其中很重要的一种途径。它不光关系到并发框架的选择、多种线程工具类的使用,还关系到对整个处理链路的业务理解和编排分析。希望通过这一课可以帮大家理清相关的思路,作为日常优化工作的一个参考。 作者:京东物流 冯鸿儒 内容来源:京东云开发者社区

资源下载

更多资源
Spring

Spring

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

Rocky Linux

Rocky Linux

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

Sublime Text

Sublime Text

Sublime Text具有漂亮的用户界面和强大的功能,例如代码缩略图,Python的插件,代码段等。还可自定义键绑定,菜单和工具栏。Sublime Text 的主要功能包括:拼写检查,书签,完整的 Python API , Goto 功能,即时项目切换,多选择,多窗口等等。Sublime Text 是一个跨平台的编辑器,同时支持Windows、Linux、Mac OS X等操作系统。

WebStorm

WebStorm

WebStorm 是jetbrains公司旗下一款JavaScript 开发工具。目前已经被广大中国JS开发者誉为“Web前端开发神器”、“最强大的HTML5编辑器”、“最智能的JavaScript IDE”等。与IntelliJ IDEA同源,继承了IntelliJ IDEA强大的JS部分的功能。

用户登录
用户注册