AI 推理为什么会出现 GPU 空闲但请求仍然变慢，系统瓶颈可能藏在哪里

【中国观察北京时间2026年08月16日】在 AI 推理服务中，一个很容易让人误判的问题是：GPU 利用率并不高，甚至监控上经常出现明显的空闲时间，但用户请求的响应速度却越来越慢。

直觉上，人们容易认为 GPU 既然没有跑满，就应该还有大量计算能力可用。但实际情况并不是这样。GPU 利用率只是整个推理链路中的一个指标，它反映的是某一时间段内 GPU 计算资源的使用情况，并不能直接代表一个请求从进入系统到返回结果所经历的全部时间。

对于大型模型推理，真正的瓶颈可能出现在 CPU、内存、网络、请求调度、批处理、显存访问、GPU 间通信，甚至只是服务程序本身的等待。

因此，遇到 GPU 空闲但请求变慢的问题，首先要改变一个思路：不要先问 GPU 为什么没有跑满，而应该问 GPU 为什么在等待。

请求进入 GPU 之前可能已经排队

一个推理请求并不是进入服务器以后马上就开始进行 GPU 计算。

典型流程通常包括网络接收请求、身份验证、请求排队、文本处理、分词、调度、批处理，然后才进入模型计算。

如果请求在这些环节等待，即使 GPU 完全正常，也不会因为 GPU 空闲而自动缩短用户等待时间。

例如，一台服务器同时收到大量请求。推理框架为了提高 GPU 利用率，通常不会让每个请求单独启动一次计算，而是会把多个请求组织成 batch，再交给 GPU 处理。

这种机制能够提高整体吞吐量，但也可能增加部分请求的等待时间。

特别是在请求量突然增加时，系统可能出现这样的情况：

请求不断进入队列，GPU仍然能够快速处理已经形成的 batch，但新的请求必须等待下一轮调度。

这时候 GPU 可能看起来并没有长期满载，但用户感受到的响应延迟却明显增加。

CPU 也可能成为 GPU 的瓶颈

AI 推理并不是纯粹的 GPU 工作。

CPU需要负责网络连接、请求处理、文本分词、任务调度、内存管理以及结果处理等工作。具体推理框架还可能在 CPU 上承担其他前后处理任务。

如果 CPU 某个核心或某一组线程已经成为瓶颈，就可能出现 GPU 等待任务的情况。

尤其需要注意的是，不能只看 CPU 总体利用率。

例如服务器有64个 CPU 核心，其中一个关键线程长期处于高负载状态，而其他核心大部分处于空闲状态。此时监控面板可能显示 CPU 总利用率并不高，但负责调度 GPU 工作的线程已经成为限制因素。

因此，判断 CPU 是否是瓶颈时，需要进一步观察线程、进程、上下文切换以及实际的应用处理时间，而不能只看一个总体百分比。

GPU利用率低，也可能是显存访问受限

GPU 的计算核心利用率和显存带宽利用率并不是同一个概念。

特别是在大型语言模型的生成阶段，GPU需要不断读取模型权重以及处理 KV Cache。某些工作负载并不是计算单元一直进行大量矩阵运算，而是受到数据读取和内存访问效率的限制。

这种情况下，GPU 的计算单元可能存在等待，而显存系统却承担着较大的压力。

因此，只看 GPU Utilization 并不能完整判断 GPU 是否成为瓶颈。

更合理的分析方法是同时观察计算利用率、显存使用量、显存带宽以及实际 kernel 执行情况。

如果计算利用率不高，同时显存访问已经非常繁忙，那么问题可能不是 GPU 算力不足，而是内存层级限制了计算速度。

LLM 推理还受到 KV Cache 的影响

大型语言模型生成文本时，需要保存此前已经处理过的上下文信息，这部分缓存通常称为 KV Cache。

随着上下文长度和并发请求数量增加，KV Cache 对显存的占用也会增加。

当服务器同时处理大量长上下文请求时，显存压力可能成为影响推理性能的重要因素。

如果显存空间不足，推理框架可能需要采取更复杂的缓存管理策略，甚至把部分数据移动到其他存储层级。

一旦数据需要在不同内存层级之间频繁移动，等待时间就可能增加。

这时候单纯增加 GPU 计算资源并不一定能够解决问题，因为真正限制系统速度的是数据如何保存、访问和移动。

这也是为什么大型模型推理不能简单理解为“GPU越快，响应就一定越快”。

Batch 策略可能同时影响吞吐量和延迟

推理系统通常需要在吞吐量和单个请求延迟之间做取舍。

增加 batch size 往往能够让 GPU 更充分地进行并行计算，从而提高单位时间处理的请求数量。

但如果为了追求吞吐量，把大量请求积累到一个 batch 中，那么某些请求就可能需要等待更长时间。

反过来，如果 batch 太小，GPU可能无法充分发挥并行计算能力。

因此，一个性能良好的推理服务并不是简单追求 GPU 利用率越高越好，而是需要根据业务目标调整调度策略。

在线聊天服务通常更加关注用户等待时间，而离线批量生成任务可能更加关注单位时间完成多少 token。

这两个场景使用同一套性能指标，很容易得出错误结论。

网络也可能让 GPU 等待

在单 GPU、单服务器的简单推理环境中，网络通常不是最主要的问题。

但在大型 AI 集群中，模型可能分布在多个 GPU 或多个服务器上。

如果使用张量并行、流水线并行或其他分布式推理方式，GPU之间需要不断交换数据。此时网络延迟、网络带宽以及 GPU 与网络设备之间的数据传输路径都会影响推理速度。

例如某个 GPU 已经完成自己的计算，却必须等待另一个 GPU 返回结果，那么它在监控上可能表现为低利用率。

这并不意味着这个 GPU 性能不足，而是整个并行计算过程中的某个环节没有及时完成。

因此，在多 GPU 系统中，还需要观察 GPU 之间的通信情况，而不能只看每块 GPU 的利用率。

PCIe 也可能成为数据传输路径中的限制因素

CPU、GPU、网卡和高速存储之间的数据传输并不是凭空完成的，它们需要经过具体的硬件互联路径。

在一些系统中，GPU需要通过 PCIe 与 CPU、网卡或其他设备交换数据。如果数据频繁跨设备移动，而传输路径或带宽成为限制因素，GPU就可能出现等待。

不过，这并不意味着看到 GPU 空闲就应该首先怀疑 PCIe。

PCIe 是否成为瓶颈，需要结合实际的数据传输量、拓扑结构以及设备之间的通信方式进行判断。

专业的性能分析应该找到实际发生的数据传输和等待，而不是看到一个现象就直接指定某个硬件作为故障原因。

模型本身也可能决定性能表现

不同模型的计算特征差异很大。

模型大小、量化方式、上下文长度、并发量、输入输出长度以及模型架构都会影响推理性能。

例如，同一块 GPU 运行一个计算密集型模型和运行一个受到内存访问限制的模型，GPU利用率表现可能完全不同。

同样，一个请求输入很短但输出很长，与一个输入很长但输出很短的请求，其性能特征也不同。

因此，比较两个推理服务时，不能只比较 GPU 型号和 GPU 利用率，还需要控制模型、精度、上下文长度、并发数量以及输入输出规模等条件。

真正排查时应该怎么做

遇到 GPU 空闲但请求越来越慢，比较合理的排查顺序不是马上更换 GPU，而是从请求本身开始追踪。

首先看请求是否在进入推理引擎之前已经排队。

然后观察 tokenization、预处理和调度耗时，判断 CPU 是否出现瓶颈。

接着分别观察模型计算时间和 GPU 等待时间，同时查看 GPU 计算利用率、显存使用情况以及显存带宽。

如果使用多 GPU 或多服务器推理，还需要检查 GPU 间通信和网络传输。

最后再结合系统日志和推理框架的性能指标，确定到底是哪一个环节增加了等待时间。

对于大型语言模型，还应该区分首 token 延迟和后续 token 的生成速度。

首 token 等待时间较长，可能与请求排队、输入处理和模型预填充有关；而后续 token 生成速度较慢，则可能更多涉及模型计算、显存访问、KV Cache 和并发调度。

把这两种情况混在一起，往往会导致错误的优化方向。

GPU没有跑满，并不代表系统还有大量性能余量

AI 推理系统本质上是一条完整的数据和计算链路。

GPU只是其中最重要的计算设备之一，但请求必须经过网络、CPU、内存、调度系统、推理框架、显存以及不同设备之间的数据传输，最终才能形成用户看到的结果。

因此，GPU 空闲与请求变慢并不矛盾。

真正的问题可能是 GPU 在等待数据、等待调度、等待其他 GPU、等待 CPU，或者请求根本还没有进入 GPU。

性能优化的关键也不是简单地把 GPU 利用率提高到某个数字，而是找到整个请求生命周期中真正消耗时间的环节。

当系统能够回答清楚一个请求到底在哪里等待、为什么等待，以及等待时间占整个请求耗时的多少，GPU是否空闲这个表面现象才有真正的分析价值。