一个请求错配了GPU，AI推理可能慢100倍

在进行大模型推理集群运维的时候，你有没有遇到过这样的现象？同样的模型、同样的GPU配置，甚至是同一个用户的连续对话请求，前一次响应或许只需要几百毫秒，下一次却突然变慢，延迟拉开数十倍甚至上百倍。 排查GPU利用率、显存占用、网络状态等常规指标后，往往很难找到明显异常。其实，问题并不一定来自于算力不足或者网络延迟，而是请求被发送到了哪里。 这听上去是不是有些奇怪？在传统计算场景，一个请求被发送到哪台服务器上、对大多数Web服务而言，只要目标节点具备足够的计算资源，请求就可以正常处理。 为什么一次请求的去向，会成为影响AI推理效率的关键因素？近日，云原生软件公司Buoyant CEO、开源项目Linkerd创始人William Morgan在一档播客中分享了他对AI推理时代Infra变化的观察。 在他看来，大模型没有让Kubernetes立刻失效，却在改变它熟悉的基础设施逻辑，计算任务不再彼此独立，代理不只是负责转发，调度也不再是“谁有空就分给谁”的简单问答。 在传统互联网服务中，服务器更多承担的是提供计算能力的角色。一个请求到来后，只要目标节点具备足够的CPU、内存以及网络资源，就能够完成对应任务。 因此，在很长一段时间里，对于应用而言，运行在哪台服务器上并不重要，只要服务能够正常工作即可。这种模式支撑了过去云计算和云原生体系的发展。 但大模型推理正在改变这一逻辑。Morgan认为，AI推理并不是传统应用计算需求的简单放大，而是一类具有不同特征的新型工作负载。 其中一个重要区别在于，大语言模型推理并不是一次简单的输入和输出过程。人和大模型聊天的时候，很容易产生一种错觉：模型记得我刚刚说过的一切。 但Morgan提到，大语言模型（LLM）本身是无状态的（stateless），它只是在每一次推理请求都会携带完整的上下文窗口。模型重新读完前文内容，才能继续回答这些问题。 当下，LLM经常会携带超长上下文，为了降低重复计算成本，GPU会留下大量中间计算结果，其中最重要的一类的叫key和value，它们被一起保存在显存里，合称为KV Cache（键值缓存）。 这样的方式，就像GPU在前一次对话结束时留下的一份“计算笔记”，帮助下一次调用GPU时，可以依靠这份笔记省下大量计算。在推理系统内部，KV Cache是否命中，已经成为影响响应速度的重要因素。 问题的关键在于，LLM的完整对话可以随着请求移动，但KV Cache往往只保存在单一GPU内。简单来说，如果第一轮对话由GPU A进行计算，A会留下KV Cache；但下一轮请求却被分配给了GPU B，B无法看见A留下的“计算笔记”，于是B必须完整阅读用户的对话，然后再去处理请求。 这种传统应用中并不明显的差异，在AI推理的过程中，却凸显得较为明显。传统互联网服务关注的是“哪台机器有资源处理请求”，而AI推理关注的是“哪台机器已经为这个请求准备好了计算状态”。 过去，一台服务器和另一台服务器的主要区别，是硬件资源多少。而现在，一台GPU节点可能已经加载了对应模型，并保存了此前计算过程中的相关信息；另一台GPU即使拥有相同的硬件配置，也可能需要重新完成计算。 这也是AI Infra与传统基础设施最大的区别之一。现在，每次请求开始与模型、GPU和此前的计算历史绑定。调度分配的不再是空闲算力，还决定一段已经完成的计算能否被接着使用。 当计算资源本身开始携带状态，传统基础设施中的一些默认假设也开始受到挑战。这类型的推理任务被放到Kubernetes中，首先撞上的就是旧有架构的“不协调”。 Kubernetes诞生于云原生时代，它解决的是一个核心问题：如何管理大量可以快速创建、销毁和替换的计算实例。Kubernetes过去最擅长管理的是传统微服务：它们通常启动快、彼此可以替换。一个实例退出，系统很快便能拉起新的实例接管请求。 但AI推理改变了这个假设。在AI场景下，它最核心的作用是统一调度GPU资源。但它的原生调度逻辑处理的核心问题是资源调配，在面对AI推理时，推理引擎往往需要独占大量GPU，启动和预热可能耗费更多时间；更重要的是，不同实例还保存着不同的模型和KV Cache，彼此不能随意替换。 但这样的实例并非不能由Kubernetes管理。Morgan强调，Kubernetes生态已经能够承载这些“奇怪”的任务。真正的难点是调度依据，系统不仅要知道哪张GPU空闲，还要知道它加载了哪个模型，保留了哪些缓存。如何让请求分配到已经加载缓存的GPU上。 除了推理工作负载本身，Agent也正在从软件生产环节改变Kubernetes面对的压力。开发者借助AI工具更快地产生代码，原本通过人工完成的一天10次部署，未来可能增加到数百甚至数千次。 Morgan提到，AI 智能体的智能增长曲线增速极快，但推理延迟优化目前并未受到足够重视。但他相信，未来这个痛点未来一定会被攻克，毕竟大家都不希望实际使用时，智能体完成简单网页操作的耗时和手动操作一样漫长。 为适应AI工作负载，Kubernetes生态也开始增加针对GPU调度的能力。在新的版本里，调度器可以识别任务需要的显卡类型，而不只是笼统地要几张卡。如果没有最高端的芯片，系统能自动改用性能稍弱的芯片继续跑，而不是让任务干等着。同时还支持把一张显卡切分成多份，分给不同任务使用。 至于请求到底该发给哪个模型实例，Kubernetes为此又加了一层路由机制，把同一个模型的多个运行实例归为一组，然后根据每个实例当前的排队情况、显存余量、缓存状态，选出处理当前请求代价最小的那个。 但改革的方向，并不意味着行业已经形成了成熟的答案。Morgan也表示，现阶段过早推出统一行业标准、标准化代理规范并不现实。因为整个技术赛道迭代速度太快，他认为应该让行业生态充分试错，从海量方案里筛选可行路线。 这种变化也正在影响请求处理链路。过去，代理层（Proxy）的主要作用是将请求快速转发到后端服务；但在AI推理场景中，一次请求往往需要经过更多判断，例如选择模型、识别请求类型、执行安全检查，以及根据GPU状态和缓存情况决定最佳处理位置。 AI代理网关赛道的处境也非常类似：市场热度高涨，但大量成品落地体验很差。即使抛开MCP协议不谈，仅处理推理请求就衍生出大量全新工程难题，这让工程师们不得不重构代理网关的底层架构。 Morgan观察到，真正把Agent放进生产集群的企业目前仍不多，很多讨论走在实践前面。一个Agent不只调用一次模型，还可能连续判断、调用工具、访问系统并执行操作。它带来的不是单次推理，而是结果难以完全预判的工作流。 届时，代理层要承担更多工作。请求发出前，系统可能先调用模型判断路由，再经过隐私信息过滤，随后查询整个集群的GPU状态，完成能够感知KV Cache的前缀路由。Morgan形容，代理可能要先执行七件事，判断哪些可以并行、哪些互为前提，然后才能派发请求。它不再只是转发组件，反而更像小型工作流编排器。 安全问题也随之改变。过去的权限控制回答“服务A能不能访问服务B”“这个身份能不能调用某个接口”；面对Agent，系统还要判断：在这项任务里，本次工具调用是否符合用户意图。权限需要随任务和上下文动态收窄，而不能登录时发一个令牌，之后一路放行。 这一问题在Agent开始具备工具调用能力后就逐渐显现。当一个Agent拥有读取邮件、调用日历甚至操作企业系统的权限时，真正的风险并不是它是否拥有这些权限，而是它是否会在错误场景下使用这些权限。例如，用户希望Agent整理邮件，但Agent是否应该因此获得删除数据库的能力。 静态的角色权限、网络策略乃至容器隔离因此开始显得不够。提示词注入没有彻底可靠的防线，沙箱只能层层加固；一旦Agent进入生产环境，AI Infra必须防止它在调用链中误触危险接口。过去因配置复杂而少被采用的细粒度访问控制，在不可预测的Agent面前，可能从“可选项”变成必需品。 AI并没有让Kubernetes过时。它真正淘汰的，是基础设施过去习以为常的假设：实例彼此等价、请求可以随意转发、代理只需追求更快、权限可以预先写死。 从知道“谁有空”，到知道“谁记得这段对话”，是从管理一次请求，到理解一条任务链的跨越。AI Infra的新问题之一，或许不是怎样再塞进更多GPU，怎样不把已经完成的计算状态、已经建立的安全边界，一次次丢掉。