1. 从“GPU利用率10%”的困惑说起如果你正在部署或使用一个大语言模型LLM比如Llama、ChatGLM或者Qwen然后满怀期待地打开nvidia-smi看到的GPU利用率Volatile GPU-Util却只有个位数或者可怜的10%心里肯定会咯噔一下。这感觉就像买了一台顶级跑车结果发现它大部分时间都在怠速油门踩到底也跑不起来。这个现象在LLM推理场景中极其普遍尤其是当你从本地运行一个7B模型到尝试部署一个70B甚至更大模型时这种“有力使不出”的憋屈感会愈发强烈。很多人第一反应是是不是我的代码写错了模型没加载对还是GPU驱动有问题实际上在绝大多数情况下你的配置和代码可能都没问题。低GPU利用率恰恰是LLM推理任务本身特性与当前软硬件架构之间固有矛盾的直接体现。它不是一个Bug而是一个需要深入理解的Feature。简单地将GPU利用率等同于“计算速度”或“性能”是我们在优化LLM推理时第一个需要破除的误解。那么LLM推理到底慢在哪为什么强大的GPU算力无法被充分利用这背后是一连串相互关联的瓶颈在起作用。从最宏观的角度看我们可以把LLM推理想象成一场精心策划的接力赛。GPU的CUDA核心负责矩阵乘法和卷积等密集计算是队伍里最强壮的短跑选手但它不能一直跑。它需要等待其他“队员”把接力棒也就是数据准备好。这些“队员”包括负责从内存搬运数据的“搬运工”内存带宽、负责协调任务和逻辑判断的“教练”CPU和软件调度以及负责在不同队员间传递信息的“通讯员”PCIe总线等。任何一个环节的延迟或阻塞都会导致我们的“短跑冠军”大部分时间在等待从而拉低了整体的平均速度即GPU利用率。接下来我们就深入这场“接力赛”的每一个环节拆解那些拖慢LLM推理速度的“隐形杀手”。2. 理解LLM推理的核心计算模式自回归解码要定位瓶颈首先必须理解LLM是如何工作的。LLM的推理特别是文本生成任务本质上是一个自回归Autoregressive的解码过程。这个过程可以简化为一个循环给定一段已有的文本称为“上下文”或“prompt”模型计算下一个词token的概率分布。根据某种策略如贪心搜索、集束搜索从这个分布中选出一个词追加到已有文本之后。将新的、更长的文本再次输入模型重复步骤1生成下一个词。如此循环直到生成结束符或达到最大长度。这个循环中的每一步模型都需要执行一次完整的“前向传播Forward Pass”。而一次前向传播的计算量绝大部分都集中在模型中的线性层即矩阵乘法和注意力机制上。这里就出现了第一个关键矛盾GPU擅长的是大规模的、并行的矩阵运算。在训练阶段我们可以通过大批量large batch数据同时输入让GPU的成千上万个核心满载运行利用率轻松达到90%以上。但在推理阶段特别是对话、问答这类交互式场景请求往往是串行到达的每个请求的批量batch size通常很小经常为1。这就好比让一个巨型工厂只为生产一颗螺丝钉而全功率运转大部分机器必然处于闲置状态。更深入一层即使在处理单个请求时自回归解码本身也是串行的。生成第N个token必须依赖于前N-1个token的结果无法并行。因此GPU在计算完一个token后必须等待CPU完成采样、数据拼接等操作准备好下一次计算的输入才能开始下一次计算。这个“准备数据-计算-等待-再准备数据”的循环中GPU真正进行高强度计算的时间占比很低大部分时间花在了数据搬运和等待上这就直接导致了我们看到的低利用率。注意这里说的“串行”是指token生成的逻辑顺序。在计算单个token的前向传播时模型内部的矩阵乘法等操作依然是高度并行的这正是GPU发挥所长的地方。瓶颈在于两次前向传播之间的间隙。3. 内存墙显存带宽是更致命的瓶颈当我们谈论GPU性能时除了计算能力TFLOPS每秒浮点运算次数另一个同等甚至更重要的指标是显存带宽Memory Bandwidth单位是GB/s。它衡量的是GPU芯片从其显存VRAM中读取或写入数据的速度。对于LLM推理尤其是参数量巨大的模型“内存墙”问题比“计算墙”更为突出。原因如下3.1 模型权重巨大访存频繁一个拥有70亿参数的FP16模型仅权重本身就需要占用大约14GB显存70亿 * 2字节。在推理的每一次前向传播中GPU需要从显存中读取这些权重数据到芯片上的高速缓存Cache和寄存器中才能进行计算。即使计算一个token只需要几毫秒但搬运这数十GB的权重数据所需的时间可能更长。如果显存带宽不足GPU核心就会长时间处于“数据饥饿”的等待状态。3.2 自注意力机制的“KV Cache”技术为了加速自回归解码业界普遍采用KV Cache技术。其原理是在生成第一个token时模型会计算并保存每个Transformer层中Key和Value矩阵的中间结果即KV Cache。在生成后续token时就不再需要为之前的所有token重新计算Key和Value只需计算新token的部分并与Cache拼接即可。这极大地减少了计算量。但是KV Cache需要消耗额外的显存。其大小与批次大小batch size、上下文长度context length、模型层数、注意力头数以及精度成正比。对于长上下文模型如支持128K的即使批次很小KV Cache也可能占用数十GB显存。每一次生成新token都需要读取和更新这个庞大的Cache这对显存带宽构成了巨大压力。一个简单的对比NVIDIA A100 GPU的FP16计算峰值约为312 TFLOPS而其显存带宽约为2TB/s约2000GB/s。在LLM推理中由于计算访存比每次计算操作需要访问的数据量不理想实际性能往往受限于后者。当带宽成为瓶颈时无论你的计算核心有多快都只能以带宽允许的速度“喂”数据GPU利用率自然上不去。3.3 量化带来的带宽收益这也解释了为什么量化Quantization是提升推理效率最有效的手段之一。将模型权重从FP162字节量化到INT81字节或INT40.5字节直接效果是模型显存占用减半或更多可以加载更大的模型或更大的批次。最关键的是所需搬运的数据量也同比减少相当于变相提升了有效显存带宽。在带宽瓶颈的场景下这能显著减少GPU核心的等待时间提升利用率。4. 系统与调度开销被忽略的“暗时间”即使解决了计算和内存的问题还有一个无形的“吞噬者”在消耗着时间这就是系统与调度开销。这部分时间GPU可能完全处于空闲状态nvidia-smi显示0%但它实实在在地拖慢了整个生成流程。4.1 CPU端预处理与后处理在GPU开始计算之前CPU需要做大量工作Tokenization分词将输入文本转换为模型能理解的token ID序列。对于中文或复杂文本分词可能涉及查表、匹配等操作并非纯计算密集型。数据准备与拷贝将token ID、位置编码等数据组装成Tensor并通过PCIe总线从主机内存CPU RAM拷贝到设备显存GPU VRAM。PCIe的延迟和带宽即使是PCIe 4.0 x16带宽约32GB/s也远低于显存带宽在此成为瓶颈。采样SamplingGPU计算出下一个token的概率分布后需要将这个分布传回CPU或由GPU直接采样CPU执行Top-p、Top-k或温度调节等采样算法决定最终生成的token。这个交互过程会产生延迟。4.2 深度学习框架与内核启动开销我们使用的PyTorch、TensorFlow等框架在底层需要调用CUDA内核来执行GPU运算。每次启动一个CUDA内核都有微小的开销。在自回归解码中成千上万次地启动小型计算内核尤其是当模型层数多、但每层计算量因批次小而不饱和时这些开销累积起来就非常可观。这被称为“内核启动延迟Kernel Launch Latency”。4.3 动态输入与计算图与训练时固定的输入尺寸不同推理时每个请求的输入长度和生成长度都是动态的。这意味着PyTorch等动态图框架需要在每个生成步骤中重新进行一些图优化和调度无法像静态图那样进行一次性的极致优化。虽然TorchScript、ONNX或TensorRT可以部分解决这个问题但它们又可能引入模型支持度、操作符兼容性等新的复杂度。5. 针对性的性能优化策略与实践理解了瓶颈所在我们就可以有的放矢地进行优化。目标不是单纯追求“GPU利用率100%”而是在给定硬件和延迟要求下最大化吞吐量Tokens per Second。5.1 提高硬件利用率批处理Batching这是提升GPU利用率和吞吐量最直接有效的方法。将多个独立的用户请求输入可能不同打包成一个批次Batch同时进行前向传播。优点矩阵乘法等操作可以更好地利用GPU的并行能力摊薄权重加载和内核启动的开销。挑战请求需要“凑批”可能引入排队延迟。不同请求的输入输出长度不一致需要处理填充Padding和注意力掩码可能造成一定的计算浪费。动态批处理如vLLM、TGI等推理服务器采用的技术可以较好地平衡延迟与吞吐。5.2 突破内存墙量化与KV Cache优化量化如前所述优先采用GPTQ、AWQ、SmoothQuant等成熟的INT4/INT8量化方案。对于推理精度损失在可控范围内但带来的带宽和显存收益是巨大的。优化KV Cache分页注意力PagedAttention由vLLM提出像操作系统管理内存一样管理KV Cache极大减少了由于碎片化导致的内存浪费从而在相同显存下支持更大的批次或更长的上下文。KV Cache量化对KV Cache也进行量化如FP8进一步减少其内存占用和带宽消耗。多查询注意力MQA或分组查询注意力GQA使用这类结构的模型如Llama 2/3其KV Cache本身就更小对带宽更友好。5.3 减少系统开销使用专用推理运行时和服务器专用推理运行时使用TensorRT、FasterTransformer、ONNX Runtime等针对推理优化的运行时。它们会对计算图进行融合Kernel Fusion、常量折叠等优化将多个小操作符合并成一个大的CUDA内核显著减少内核启动开销和内存访问次数。高性能推理服务器vLLM以其高效的内存管理PagedAttention和调度著称特别适合高吞吐量的在线服务场景。Text Generation Inference (TGI)由Hugging Face开发支持动态批处理、持续批处理Continuous Batching并集成了FlashAttention等优化开箱即用体验好。使用这些服务器而不是自己用原生PyTorch写推理循环往往能获得数倍的性能提升。5.4 模型架构与工程权衡模型选型在满足效果需求的前提下选择更“推理友好”的模型架构。例如使用MQA/GQA的模型或者像Gemma、Qwen等在某些操作上进行了优化的模型。连续请求的上下文缓存对于多轮对话场景可以将上一轮的KV Cache缓存下来下一轮只需计算新的用户输入部分避免重复计算整个历史上下文。6. 诊断工具与实操定位你的性能瓶颈当遇到性能问题时如何判断瓶颈到底在哪以下是一些实操方法6.1 使用性能剖析工具Nsight SystemsNVIDIA的系统级性能剖析器。它可以给你一个时间线视图清晰地展示在推理过程中CPU在做什么GPU在做什么数据拷贝花了多少时间内核执行花了多少时间以及GPU是处于计算状态还是空闲等待状态。这是最强大的终极诊断工具。PyTorch Profiler内置于PyTorch使用相对简单。通过torch.profiler可以记录每个操作符的执行时间、CPU/GPU时间帮助发现最耗时的层或操作。6.2 进行简单的控制变量实验增大批次大小在固定输入输出长度下逐步增大batch_size。如果吞吐量随之线性增长且GPU利用率显著上升说明之前处于计算不饱和状态批处理有效。调整输入输出长度测试短文本和长文本的生成速度。如果生成长文本时速度急剧下降或GPU利用率变化不大瓶颈可能在注意力计算或KV Cache的访存上。对比不同运行时用相同的模型和输入分别测试原生PyTorch、torch.compile、ONNX Runtime或TensorRT的速度。如果后者快很多说明框架开销是你的主要瓶颈之一。6.3 监控关键指标除了nvidia-smi看利用率和显存更应关注吞吐量Tokens/s这是衡量推理性能的终极业务指标。延迟Latency首个Token生成时间Time to First Token, TTFT和后续Token生成时间Time per Output Token, TPOT。GPU SM利用率通过nvidia-smi dmon或Nsight Compute查看流多处理器SM的活跃周期百分比这比整体的GPU-Util更能反映计算核心的忙碌程度。7. 总结与个人心得接受不完美聚焦有效吞吐经过以上分析我们再回头看“GPU利用率10%”这个问题心态应该平和许多。在LLM推理尤其是小批次、交互式场景下中低GPU利用率是常态而非异常。这是由任务本身的串行特性和现代GPU的并行架构之间的根本性错配所决定的。优化的核心思路不是强行让GPU“空转”到100%而是通过批处理、量化、高效内存管理、优化运行时等手段减少GPU核心的等待时间让它在必须工作的时候能全速工作从而提升整体的有效吞吐量。在实际工作中我有以下几点体会不要盲目追求GPU利用率一个在30%利用率下达到500 tokens/s吞吐的系统远比一个在80%利用率下只有100 tokens/s的系统更有价值。始终以业务指标吞吐、延迟为导向。量化是第一选择在效果损失可接受的情况下优先尝试量化。它带来的性能提升通常是立竿见影且代价最小的。善用成熟推理服务器不要重复造轮子。像vLLM、TGI这样的项目已经集成了大量最佳实践直接使用往往比自己从零搭建要高效稳定得多。理解你的工作负载你的服务是面向高并发的短对话还是少数用户的长文档处理不同的场景主要瓶颈不同。短对话可能更受CPU预处理和内核启动延迟影响而长文档则可能受限于显存带宽和KV Cache大小。端到端剖析性能问题往往是一个链条。使用Nsight Systems这样的工具进行一次端到端的剖析从用户请求进入到Tokenization到数据拷贝到GPU计算再到采样返回完整地看一遍时间都花在哪了比猜测要准确一百倍。LLM推理优化是一个涉及算法、系统、硬件的深水区。看到低GPU利用率不再焦虑而是能系统地分析其背后的原因并采取正确的优化路径这才是从入门走向精通的标志。这个过程本身也是深入理解深度学习系统如何工作的绝佳机会。