共享 AI 算力时，谁的请求可以等待？

2026年10月20日，llm-d 发布1.0版本，强调多租户运营。同日，Red Hat 介绍了 Red Hat AI 3.5的优先级感知服务。这些消息带出一个超越基础设施的问题：多个产品共用推理算力时，谁的工作可以等待，平台又向其他人承诺了什么？

以下是针对这个产品设计问题的独立分析，并非对项目性能宣传的独立验证，也不是部署指南。共享资源需要分配稀缺的时间。队列可以执行分配，但标签代表什么，仍须由运营服务的组织决定。

等待造成的损失并不相同

设想一家企业同时运行三类任务：帮助员工准备即将开始的会议的助手、为明天的搜索更新文档索引的作业，以及在后台生成可选建议的智能体。这是说明机制的假设案例，不是已报道的客户部署。它说明，把工作简单分成“交互式”和“批处理”，仍留下一个关键问题。

会议助手只有在答案还能影响讨论时才有价值。索引任务现在可以延后，但随着明天的营业时间临近，其重要性会上升。可选建议即使生成得很快，也可能完全可以放弃。速度要求、业务重要性，以及最晚仍有用的完成时间，是不同属性。Google 的 SRE 过载处理资料也区分请求的重要程度与延迟要求。这是背景工程经验，不证明某个推理产品已经实现截止时间策略。

我们建议从“延迟损失”入手：请求多等一段时间，什么会变差，由谁承担损失，结果何时不再有用？用户已经离开页面，助手就不该仅凭最初来自交互界面而继续保有紧急身份。反过来，夜间任务也不该在承诺的交付窗口即将关闭时，仍永久处于最低顺位。

接受请求，究竟意味着什么

在这个假设里，会议助手需要在三十秒内给出答案。这是示意性的产品要求，不是实测性能。如果大部分时间耗在排队，临近截止时才开始生成，系统可能得到一次技术上成功、却错过决策时点的响应。单纯统计完成的请求数，会把这种失败藏起来。

有用的服务约定应区分“已经收到”“接受执行”和“在仍然有用时完成”，并说明过期工作是否取消、部分输出能否使用，以及调用方能否改选延后交付。这些含义应当先于优先级档位的数量确定。否则平台与应用可能对一次缓慢成功是否兑现承诺，得出相反判断。

单靠优先顺序无法解决这些问题。Red Hat 明确提示，持续的高优先级流量及已放行的长输出会带来限制。业务截止时间还包含推理队列之外的时间：查找文档、等待工具结果，以及把答案交还用户。给模型调用贴上最高等级，并没有替其他环节预留时间。可信的完成承诺需要端到端时间预算，也需要实际工作负载的证据。

谁有权宣布紧急

优先级还带来激励问题。如果申请更高等级没有组织成本，每个团队都有理由争取最高级。标签最终描述的可能是谈判力度，而非延迟后果。调度器即使技术上完全正确，也可能忠实执行一套无助于业务的政策。

一种可行的治理方式，是让服务负责人承担分类责任，为例外保留理由，并复核长期占据紧急通道的流量。在假设企业里，会议助手可以获得有边界的紧急额度，索引负责人则能在临近交付期限时申请限时提升。这是本文提出的设计思路，不是对本次发布已有功能的描述。目的在于让优先级成为有人负责授予、范围有限的承诺。

智能体流程使边界更重要。假设一次用户请求派生出几个可选分支，若每个分支自动获得同等紧急身份，一个交互就可能占用原本留给多个交互的份额。应用应说明哪些分支必不可少、哪些可以取消，以及整个任务最多可以产生多少并发工作。只按单个请求衡量公平，会忽略父任务与后续分支之间的关系。

保留部分独立算力也有合理性。隔离可以使范围狭窄但重要的服务更容易判断和管理，代价是降低共享池的调配灵活性。选择取决于正在出售、或被业务依赖的服务承诺。是否合并应围绕承诺论证，而不宜把所有工作负载都合并视为当然目标。

测试承诺，也测试那些被要求等待的人

有意义的评估应重现假设企业的常规流量，再把需求高峰维持足够长的时间，观察被延后的工作。短暂突发可能证明紧急回答仍然迅速，却掩盖索引作业永远追不上的问题。评估应关注各类工作是否在各自有效窗口内完成，而不只是总体响应时间有没有下降。

还应区分有意延后与事实上被放弃。多少工作被接受后又取消？最老的待处理任务等了多久？可选智能体分支是否挤占独立用户的份额？错过期限究竟发生在推理之前、之中，还是之后？这些是本文建议追问的运营问题，不是厂商已经公布的测试结果。

不确定性不会消失。未来请求的长度、需求高峰是否重合、部分答案是否仍有价值，都无法提前完全掌握。平台可以收窄承诺，明确持续争用时如何处理，并给应用一条显式路径，处理无法及时完成的工作。优先级感知服务的实际意义，在于让分配规则可以配置；这种分配能否形成可信的服务，则取决于一项更难自动化的判断：每个正在等待的用户究竟有权期待什么，以及这一期待有没有经过检验。