Shared GPUs without shared latency: Priority-aware serving in Red Hat AI

无需共享延迟的共享 GPU：Red Hat AI 中的优先级感知服务

Component | Article_teaser

2026 年 10 月 20 日

6 分钟阅读

人工智能

Naina Singh

高级首席产品经理

Subpattern | social_share_set

Component | social_share

分享

Subpattern | subscribe

Component | social_icon

订阅 RSS

Component | Icon

© Red Hat, Inc. CC-BY-4.0 授权

Subpattern | results_nav

组布局

Component | Nav_links

• 返回所有文章

Component | Generic

聊天、批量和代理流量可以运行在同一个图形处理单元（GPU）上，而无需聊天机器人等待批量任务完成。基于 llm-d 流控制构建，并在 Red Hat AI 3.5 中正式发布，优先级感知服务在资源池满载时决定哪些请求优先处理，且应用程序无需做任何更改。在 NVIDIA H100 上，95% 的高优先级请求在不到半秒内就获得了第一个 token，批量任务拒绝率从 48,224 次降至 0。

每个独立池都要为其峰值付费

迟早，每个共享推理平台都会同时收到两个团队的相同问题：谁的请求应该优先处理？

目前，一个集群上的基础模型通常需要同时服务于客户聊天机器人、批量摘要流水线、代理式检索增强生成（RAG）工作流和内部助手。它们共享同一个模型，但性能需求却截然不同。聊天机器人需要在 1 秒内获得初始 token，批量文档流水线关注每美元的吞吐量而非单个请求，代理式工作流可能闲置数分钟，然后同时触发 5 个并发链。

没有优先级概念的共享池会以相同方式对待所有请求：一个队列，一个调度顺序。当批量任务在流量高峰期间淹没该队列时，聊天机器人的请求只能排在后面等待。

合理的解决方案是为每种工作负载类型设置独立的 GPU 池，每个池根据其自身峰值进行配置。这种方法虽然有效，但也意味着每个池都必须保留大量备用容量以应对不常出现的流量，且无法借用其他池的空闲资源。每新增一种工作负载类型，就需要新增一个池和相应的备用容量。这种冗余资源正是共享池可以回收的优势，前提是池能明确知道哪些请求应该优先处理。

应用程序保持原有端点，池自主决定优先级

那么池如何知道哪些请求应该优先处理？应用程序无需告知它。这一决策被转移到 llm-d 流控制层（位于模型服务器前端），而应用程序仍可继续调用原有端点。

操作员通过 Kubernetes 资源 InferenceObjective 为每个工作负载分配优先级，设置饱和阈值（池满载的判定点），并选择公平性策略。网关读取调用者的凭证，将每个请求标记为特定优先级和租户。

当池达到饱和后，请求将按优先级和租户排队，由以下 3 个规则决定后续处理顺序：

• 优先级：等待请求中优先级最高的组优先处理
• 公平性：同一优先级组内，调度器会在不同租户间轮转，防止某个租户的突发流量挤占其他租户资源
• 排序：同一租户队列内，请求按先进先出原则处理

低于阈值时，空闲容量从不被保留，当出现资源争用时，这些容量会自动分配给设计用于吸收此类负载的工作负载。

结果：在批量洪水测试中实现0次拒绝，相比无流量控制时的48,224次拒绝显著下降。在所有测试场景中，首次生成令牌时间（TTFT）的P95指标稳定在2.1至2.8秒之间（此前使用早期检测器时为6.7至8.3秒）。

首次生成令牌时间（TTFT）是聊天用户在看到响应开始生成前的等待时间。在Red Hat AI 3.5中，4个层级共享同一H100 GPU运行gpt-oss-20b模型，唯一变化的是检测器（决定连接池何时满载的流量控制组件）：

并发检测器（新）

• 白金（实时）：364毫秒
• 黄金（实时）：430毫秒
• 银色（标准）：699毫秒
• 铜级（批量）：3.0秒

利用率检测器（旧）

• 白金（实时）：1.3秒
• 黄金（实时）：1.5秒
• 银色（标准）：2.0秒
• 铜级（批量）：2.7秒

两种检测器都保持了层级顺序。只有Red Hat AI 3.5新增的并发检测器，让实时层级的等待时间始终低于1秒，而批量任务则承担了等待时间。

批量作业会排队而非失败。在无流量控制时，相同GPU上的批量洪水测试导致3次运行共产生48,224次拒绝，每次都是429错误代码（请求过多）返回客户端重试。启用流量控制后，拒绝次数归零。请求改为等待轮到自己执行，所有输出长度测试均如此。

在单个层级内，单个高负载租户无法挤占其他租户资源。当3个高级租户共享一个带宽时，1个租户突发至82请求/秒，其他两个保持在6请求/秒。两个低负载租户的等待时间保持稳定在约17毫秒，高负载租户等待时间稍长（45毫秒）但仍获得服务。

不同GPU、不同模型、相同效果。在内部测试中，当高级、标准和批量任务同时运行在4块NVIDIA A100上时，高级任务的首次生成令牌时间始终在2.1至2.8秒之间，且层级排名最低的始终承担等待。早期检测器在相同A100测试中几乎无法区分层级差异。正是并发检测器带来了显著提升。

批量任务可等待，因此无需专属连接池

回到3个独立连接池的场景。假设每个池有8块GPU，全天平均利用率30%。这意味着24块GPU仅执行约7块GPU的工作量，其余资源用于应对未发生的峰值。客户聊天和智能代理工作流在工作时间达到峰值，但批量流水线关注的是完成时间而非运行时间。将它们放入1个连接池后，批量任务以低优先级运行在交互层级空闲时段，当交互层级激增时自动退让。这样就不需要为批量任务的峰值单独配置GPU。

平台团队已开始按此规划。一家公共部门推理平台目标GPU利用率80%，计划以低优先级运行语音转录以填补工作时间峰值期间的资源空缺。

释放资源的幅度取决于峰值重叠程度，这需要基于自身利用率数据进行算术计算。流量控制确保资源共享的安全性，节省的资源来自这种共享机制。

当连接池满载时，调优能带来显著收益

优先级感知服务只需调整1个参数。饱和阈值设得过高，请求会在流量控制介入前在模型服务器内堆积；设得过低，GPU仍有空闲时请求就开始排队。要找到最佳数值，可逐步增加负载直到高级任务开始错过延迟目标，然后将阈值设为该值的某个比例。

在更早的上游扫描中，最佳设置位于中间位置。如果放宽设置，标准服务的延迟会从12.7秒下降到2.7秒，而高级服务则会损失几百毫秒。但如果设置过于严格，高级服务也会在达到上限时开始排队。在48个并发请求时，高级服务表现最快，而非32个。如果您的标准服务是运行数分钟的批处理任务，额外的几秒延迟会被任务本身吸收。但如果这是第二个聊天产品，这些秒级延迟就代表用户正在等待。

调整好设置后，您将在以下三种场景中看到优势：

• 如果您在同一个模型上同时运行交互式和批处理任务：批处理任务会填充空闲容量，当交互式流量激增时，新批处理请求会等待。OpenAI兼容的批量推理为这类任务提供了异步处理方式。

• 如果您从同一个资源池为多个团队或客户服务：同一优先级带内的租户不会相互抢占资源。

• 如果您提供分级服务：高级和标准服务共享同一个模型和GPU，而非运行独立部署。

如果您的所有流量都是同类型工作负载，或资源池从不饱和，那么无需优先级感知服务。

在规划共享资源池时需要注意两个重要限制。优先级是严格规则，持续的高级负载会将批处理任务阻塞直到负载结束。批处理任务会填充现有空闲容量，当没有空闲时则需要等待。当响应长度达到数千个token时，已通过门禁的请求在生成过程中会主导延迟，此时流量控制已无法保证高级服务的优先级保护。如果您的代理或推理工作负载会产生长输出，应优先测试这种情况。Red Hat AI文档涵盖了其余内容，包括vLLM自身的并发限制必须与流量控制阈值对齐的实现方式。

如果您的GPU资源池大部分时间都低于峰值使用率，那么值得思考低优先级工作负载能填充多少空闲容量。

从"谁先执行"到每个层级的延迟目标

通过优先级感知服务，正确的请求会优先执行。下一步是确保每个请求都能满足其延迟目标。

优先级是一个排名，饱和阈值是操作员手动将延迟目标（或服务等级目标SLO）转换为数值的临界点。

SLO感知服务填补了这一差距。操作员为每个层级声明延迟目标，系统会向该目标靠拢。这将内部优先级设置转化为平台团队可提供的服务层级（包含延迟目标）。

"哪个请求先执行"的答案在3.5节。满足每个层级的延迟目标是llm-d接下来要解决的问题。

从单个GPU开始，再扩展共享资源池

• 在单个GPU上尝试：阅读Will Parker的《使用OpenShift AI和llm-d流量控制优化GPU效率》，学习如何部署两个优先级带，并运行可重复的基准测试

• 配置和调优：Red Hat AI文档

• 联系我们：如果您计划将工作负载整合到共享资源池，请联系您的Red Hat账户团队

资源

• Alexa Griffith的流量控制基准测试指南

• Rishabh Saini的llm-d流量控制：共享GPU推理的优先级排队

• llm-d流量控制官方指南和架构文档

Block | Dynamic pattern deluxe promo

Component | Band_header

Red Hat虚拟活动 | 开源安全的下一步

开源安全是我们"下一步"虚拟活动的第一个主题，向您展示如何将修复措施从人工速度提升到机器速度。

Component | spacer

Component | Cta_multi_basic

Subpattern | simple_cta

Component | CTA

继续阅读

高级 mbox

Component | Card_header

关于作者

Subpattern | speaker

卡片布局

Component | Image_embed

Component | Person

Naina Singh

Subpattern | social_links

Naina Singh 现任 Red Hat AI 推理产品战略负责人，专注于为企业客户提供生产环境中的大语言模型（LLM）推理解决方案。她致力于研究影响推理在规模化运行中盈利性的运营和经济决策，拥有两项专利及来自北卡罗来纳大学 Kenan-Flagler 商学院的工商管理硕士（MBA）学位。

阅读该作者的更多文章

类似内容推荐

Dynamic pattern

博客文章

跨越门槛：实现可靠的开源 AI 服务

边缘 AI 的 MLOps：管理分布式舰队中的 AI 模型

原始播客

自主 AI 能否修复互联网？

Red Hat 如何为可扩展 AI 清理 IT 债务

Subpattern | card_flex

Subpattern | text_basic

继续探索

• 什么是自主 AI？文章

• 预测性 AI 与生成性 AI 对比 文章

• 构建生产就绪 AI/ML 环境的关键考量 电子书

• 以 Ansible 方式实现生成性 AI 视频

• 通过现代应用平台实现创新与转型 电子书

继续探索 mbox

Subpattern | simple_text

按频道浏览

浏览所有频道

Pattern | raw_html

自动化

关于 IT 自动化的最新动态，涵盖技术、团队和环境

人工智能

关于赋能客户在任意环境运行 AI 工作负载的平台更新

混合云

探索我们如何通过混合云构建更加灵活的未来

安全

关于我们在各类环境和技术中降低风险的最新动态

边缘计算

关于简化边缘环境操作平台的最新动态

基础设施

关于全球领先的企业级 Linux 平台的最新动态

应用程序

深入探讨我们解决复杂应用挑战的方案

虚拟化

企业虚拟化的未来，适用于本地或跨云的工作负载