ZenteiQ scales batch inference 4x with GKE Inference Gateway powered by llm-d

ZenteiQ 通过 GKE 和 llm-d 将物理 AI 推理扩展 4 倍 | Google Cloud 博客

容器与 Kubernetes

ZenteiQ 通过 GKE 推理网关（由 llm-d 提供支持）将批量推理扩展 4 倍

2026 年 10 月 22 日

##### Sashikumaar Ganesan 教授

ZenteiQ 创始人

##### Fisayo Feyisetan

Google Kubernetes Engine 产品经理

##### 立即体验 Gemini

职场 AI 的入口

立即体验

今天，我们邀请到 ZenteiQ 公司分享他们的经验。这是一家从印度科学研究所（IISc）衍生出来的人工智能初创企业，被印度 AI 使命计划选中，负责从零开始构建自主的科学基础模型。为了预训练能够理解物理定律、控制方程和数值求解器的模型，ZenteiQ 设计并构建了一个大规模的批量合成数据生成流水线，该流水线跨多个模型家族运行，并将经过验证的数据集输入到训练流程中。Google Kubernetes Engine（GKE）和 GKE 推理网关为 ZenteiQ 的流水线提供了推理路由层，使其聚合推理吞吐量扩展了 4.07 倍，每天每 1000 个加速器的输出量从 14.7 亿个生成标记增长至 59.7 亿个。——Google Cloud 产品经理 Fisayo Feyisetan

与主要基于网络文本和代码训练的通用语言模型不同，科学基础模型必须理解跨热力学、计算流体动力学和电磁学等领域的复杂物理系统、数学控制方程和数值求解器。在 ZenteiQ，我们从零开始构建自主的科学基础模型，这些模型能够解释模拟输出、评估方程形式，并通过符合物理定律的逐步数学推导进行计算。

在控制方程的大型数据集上预训练模型需要数百亿个推理标记。除了精选的科学文献和模拟数据集外，我们还依赖于自行设计并实现的批量合成数据生成流水线，在将候选推导和求解器验证问题输入到我们的 MaxText 预训练任务之前，该流水线会生成、评估并过滤这些数据。

由于我们使用固定的计算资源配额，加速器每小时用于生成和验证训练数据的时间，都会从预训练中被占用一小时。当数据生成滞后时，原本为预训练保留的多主机加速器集群将处于空闲状态，等待数据集就绪。

当数据生成拖慢预训练进度时

为了最大化数据生成速度，我们的流水线将工作负载拆分为两个独立流程：在工作负载 Pod 上准备提示内容，同时在 vLLM 的多节点加速器池中进行模型服务。每个批次需要经过四个阶段：将科学种子概念扩展为提示批次、使用生成模型创建候选推理轨迹、使用评估模型对响应进行评分，以及在打包验证数据集用于预训练前，使用独立模型家族运行护栏检查。

最初，我们通过 Kubernetes 在推理端点上使用标准 ClusterIP 轮询负载均衡来运行这些模型池。随着流水线扩展以支持我们 9B 和 35B 参数模型的调度需求，两个路由瓶颈开始减缓数据集的创建速度。

• 不均衡的引擎队列：我们的上游工作负载 Pod 将种子概念扩展为复杂程度和响应长度差异显著的提示。由于标准的轮询负载均衡无法感知 vLLM 引擎队列状态，它持续将新请求发送给正在处理长推理轨迹的繁忙服务 Pod，而相邻节点却仍有可用容量。

• 冗余的前缀计算：生成批次中的提示共享约 70% 到 80% 的指令上下文和任务规范。轮询路由将相同指令的请求分散到不同服务实例，迫使每个 Pod 从头开始重新计算共享提示前缀，而非复用加速器内存中的预热缓存。

不均衡的队列与冗余的预填充工作共同导致我们的生成吞吐量在单次运行中波动高达 50%，延长了数据集创建时间并延迟了计划预训练任务的启动。我们需要一种能理解实时 vLLM 队列深度和提示缓存的路由方案，而无需让研究人员脱离模型开发工作去构建和维护自定义推理调度器。

基于 GKE 推理网关（由 llm-d 支持）的构建

我们已经在 GKE 上运行数据准备和 MaxText 预训练任务，这使团队能够在同一 Kubernetes 平台上管理数据生成和模型训练。根据 Google Cloud 的建议，在不改变底层科学方法或流水线设计的前提下解决路由瓶颈问题，我们在 vLLM 加速器池前部署了由开源 llm-d 分布式推理框架支持的 GKE 推理网关。

在我们的流水线中，工作负载 Pod 从 Cloud Storage 拉取科学种子文档和领域分类法，将其扩展为多步骤提示批次。这些批次通过单一的 GKE 推理网关部署，该部署管理着所有模型家族和服务节点之间的流量。

我们不再为每个模型层级维护独立的路由，而是通过相同网关将生成请求、评估查询和防护检查路由到各自的模型池。一旦候选响应通过评估和防护检查，工作负载 Pod 会去重并打包验证后的数据集，直接供 GKE 上的下游 MaxText 预训练任务使用。

GKE 推理网关在将验证后的数据集输入 MaxText 预训练之前，会将批量生成、评估和防护请求路由到运行 vLLM 的多节点加速器池。

从轮询到基于负载和缓存感知的路由

借助 GKE 推理网关和 llm-d，路由决策使用来自 vLLM 实例的实时服务信号，而非静态轮询。GKE 推理网关持续监控所有 vLLM 端点的实时队列深度和键值（KV）缓存利用率。当某个服务节点正在解码长公式推导时，网关会将新请求路由到有可用容量的节点，从而避免重提示在繁忙工作节点后堆积，而相邻节点却空闲的情况。

同时，网关会将匹配科学指令的请求路由到已预加载该前缀KV缓存的计算节点。由于每个提示词中70%到80%是共享的指令上下文，而生成的推理轨迹在不同请求间存在差异，结合前缀缓存局部性与实时队列平衡技术，使我们的计算节点能够跳过重复的预填充工作，而不会导致任何单个副本过载。

更高的吞吐量，可预测的训练运行

采用由llm-d驱动的GKE推理网关后，我们的数据生成流水线速度和可预测性显著提升。在生产集群中，智能路由实现了以下成果：

• 舰队吞吐量提升4倍：每千个加速器的聚合吞吐量从16,964个标记/秒提升至69,114个标记/秒——每日输出量从14.7亿个生成标记增长至近60亿个。

• 单个模型池性能提升3.5倍至5.5倍：实时队列平衡技术在每次运行中保持服务节点负载均衡，防止了长推理推导导致的中途减速问题。

• 前缀缓存命中率提高14个百分点：将匹配科学指令的提示词路由到预热缓存，避免了每次请求分支前的冗余预填充工作。

对于我们的研究和基础设施团队而言，最重要的成果是实现了调度可预测性。每日输出量翻倍使验证数据集能按时就绪，从而使我们的多主机预训练运行能够按计划启动，而无需等待数据生成。

ZenteiQ物理AI的下一步发展

随着我们从9B参数扩展到35B参数及以上的科学基础模型，我们计划继续使用相同的GKE推理网关和llm-d路由架构，用于训练后强化学习（RL）和自动化数值求解器评估循环。由于这些多轮对话中的每一步都依赖于之前步骤的上下文，它们对实时队列平衡和预热前缀缓存的依赖程度更高。

要尝试在自己的工作负载中使用这些功能，请查阅GKE推理网关文档并查看开源llm-d项目。您还可以阅读Gemini平台团队如何通过GKE推理网关将延迟降低35%的案例。

Posted in

• 容器与Kubernetes

• GKE

• AI基础设施

• 客户案例

• llm-d