Google Cloud Blog

Scaling Ray Serve LLM on GKE: Performance without losing the developer experience

8.5内容质量
Scaling Ray Serve LLM on GKE: Performance without losing the developer experience

TL;DR · AI 摘要

Google 与 Anyscale 合作优化 Ray Serve LLM 在 GKE 上的性能,实现吞吐量提升 5 倍、延迟降低 8 倍。

核心要点

  • 通过 HAProxy 集成,减少代理开销并提升吞吐量。
  • 直接 token 流式架构降低延迟,绕过 ingress 路由器。
  • v2 Ray executor 后端与 vLLM 结合,实现异步调度和性能优化。

结构提纲

按章节快速跳转。

  1. 介绍 Ray ServeGKE 的结合及其性能优化的必要性。

  2. 介绍 HAProxy 集成、流式架构和 v2 Ray executor 三方面优化。

  3. 通过 HAProxy 减少代理开销,提升吞吐量。

  4. 直接 token 流式架构降低延迟,绕过 ingress 路由器。

  5. v2 Ray executor 与 vLLM 结合,实现异步调度和性能优化。

  6. 在 GKE 上使用 Gemma 4 E2B 模型进行性能测试,验证优化效果。

思维导图

用一张图看清主题之间的关系。

查看大纲文本(无障碍 / 无 JS 友好)
  • Ray Serve LLM 性能优化
    • 架构优化
      • HAProxy 集成
      • 流式架构
      • v2 Ray executor
    • 性能测试
      • 吞吐量提升 5 倍
      • 延迟降低 8 倍

金句 / Highlights

值得收藏与分享的关键句。

#Ray Serve#GKE#LLM#性能优化#Kubernetes
打开原文

提升 GKE 上 Ray Serve LLM 的吞吐量和延迟 | Google Cloud 博客

容器与 Kubernetes

在 GKE 上扩展 Ray Serve LLM:兼顾性能与开发者体验

2026 年 6 月 19 日

##### Spencer Peterson

Google 软件工程师

##### Seiji Eicher

Anyscale 软件工程师

##### 今天试用 Gemini Enterprise Business Edition

工作场所人工智能的入口

立即试用

寻找 LLM 推理和模型服务的开发者通常会转向 Ray Serve,这是一个由 Anyscale 构建的可扩展模型服务库,提供开发者友好的、原生 Python API。结合 Google Kubernetes Engine(GKE),开发者拥有了一个功能强大且统一的平台,该平台针对苛刻的 LLM 服务使用场景进行了优化,覆盖从初始模型开发到在线生产服务的各个方面。

然而,这种灵活性和功能集过去曾以性能为代价。但今天,我们与 Anyscale 合作,推出了 Ray Serve 的性能优化,使吞吐量提高高达 5 倍,延迟降低高达 8 倍,满足了最先进的分布式推理对日益增长的需求和严格的性能要求,而无需牺牲易用性。

在不造成瓶颈的情况下扩展推理

通过我们的联合工程合作,我们引入了三项重大的架构优化,显著提升了 Ray Serve LLM 的性能特征:

  • Ray Serve HAProxy 集成:Ray Serve 现在内置 HAProxy 来管理内部请求路由和负载均衡。这种设置大大减少了代理开销,并防止 Python 运行时在高流量下饱和。
  • 直接令牌流架构:该架构将初始请求路径与返回流解耦。令牌直接从单个模型副本流回代理,完全绕过入口路由器,从而减少流数据路径的延迟。
  • 用于 vLLM 的 v2 Ray 执行器后端:vLLM 的全新 Ray 后端将 Ray 移出数据平面,以启用异步调度。这统一了代码路径与原生 vLLM 执行器,缩小了性能差距,并确保 Ray 用户能够从最新的引擎级优化中受益。

在 GKE 上评估性能

我们还与 Anyscale 合作,在使用下一代 AI 硬件的 GKE 集群上对更新后的 Ray Serve LLM 进行了基准测试,包括由 NVIDIA HGX B200 系统驱动的 Google Cloud A4 虚拟机。我们选择运行 Gemma 4 E2B 作为小型、高效的模型,以隔离由编排和路由引入的瓶颈。我们的基准测试将新的 Ray Serve LLM 与之前的性能进行了比较,并与使用 Ray 执行器的普通 vLLM 设置进行了比较。

这些技术改进对性能产生了变革性的影响,与之前的 Ray Serve 配置相比,吞吐量提高了高达 5 倍,延迟改善了高达 8 倍。

改进后的 Ray Serve LLM 在一个拥有八个副本的服务集群上表现出显著的性能提升,展示了远超之前性能的扩展模式,并且与原生运行 vLLM 的性能相当,但没有牺牲 Ray 提供的灵活性。

我们观察到,随着并发用户数量的增加,Ray 现在能够扩展吞吐量,同时保持较低的第 99 百分位首次令牌时间,而之前它在这一点上遇到了困难。现在,LLM 实践者无需牺牲 Ray 丰富的功能和生态系统,即可在 Kubernetes 上获得生产级性能。

为什么选择 GKE 用于 Ray Serve

GKE 提供了使这些软件优化发挥出色的基础架构。在使用 GKE 的 Ray Operator 插件时,您可以在 Google Cloud 的 AI 加速器上获得开箱即用的部署,包括自动水平扩展、监控、多集群扩展和内置的容错能力。GKE 抽象了协调分布式物理硬件的复杂部分,因此您的团队可以专注于使用 Ray 优化模型和应用逻辑。

在 GKE 上尝试 Ray Serve LLM

我们鼓励开发者在最新的 Ray 版本(2.56 及更高版本)中尝试这些增强功能,体验在 GKE 上高性能 LLM 服务的未来。

如需更多详细信息,请查看以下资源:

  • Anyscale 新闻:使用 Ray Serve LLM 进行高性能分布式推理
  • 使用 KubeRay 在 Ray Serve 上实现高吞吐量
  • 使用多集群 Ray Serve 和 GKE 推理网关部署 LLM
  • 在 GKE 上使用 Ray 部署 Gemma 开源模型

发布在

  • 容器与 Kubernetes
  • AI 基础设施
  • GKE