GPU 到底如何工作理解 LLM 推理性能的核心框架说到 GPT、Llama、Qwen 这类大语言模型很多人第一反应是“参数多、训练贵、跑起来慢”。但真正被反复挂在嘴边的三个字其实是 GPU。我最早接触 LLM 推理的时候踩过一个大坑买了一张显存很大的卡以为部署 70B 模型“绰绰有余”结果推理速度慢到怀疑人生。后来才意识到我对 GPU 的理解停留在“有好多核、显存很大”这种原始层面压根不知道大模型在 GPU 上跑的时候瓶颈究竟卡在哪个环节。这篇文章就把我在折腾 LLM 推理过程中积累的 GPU 认知体系整理出来。不吹概念不绕弯子直接讲清楚 GPU 凭什么能加速大模型、LLM 推理真正的性能瓶颈是什么、怎么用一套核心框架去评估和优化你的部署方案。无论你是刚入门的小白还是要做技术选型和性能优化的工程师读完都能建立一张清晰的“GPU 推理性能地图”。1. 为什么大模型离不开 GPU算力、显存和带宽的三角关系1.1 GPU 和 CPU 真正拉开差距的地方很多人知道 GPU 能做大规模并行计算但不理解它为什么能做到。拿 CPU 举例子一颗 16 核 32 线程的现代处理器单个核心的性能非常强适合处理复杂的逻辑判断、分支跳转、依赖关系紧密的任务。但它在同一时刻能执行的线程数撑死也就几十个。GPU 不一样一块消费级 RTX 4090 有 16384 个 CUDA 核心A100 有 6912 个 CUDA 核心加上 432 个 Tensor Core。哪怕每个核心的主频比 CPU 低不少但“人多力量大”的效果在并行计算里是压倒性的。LLM 里的算子——矩阵乘法、注意力机制、层归一化——本质上都是高度并行的数值计算。以 Transformer 结构中最核心的矩阵乘为例一次 QKV 投影要对输入向量做多次大矩阵乘这些计算天然可以被拆分到成千上万个 CUDA 核心上同时执行。你给 GPU 一万个独立的乘加任务它就真的能同时开一万个线程去算CPU 只能排队。1.2 显存容量决定“能不能跑”显存带宽决定“跑多快”聊 GPU 推理性能显存一定是绕不开的。网上讨论 GPU 时最常见的问题是“这张卡显存多大”但几乎没人提到“显存带宽有多高”。这个被忽视的参数恰恰是 LLM 推理性能的核心瓶颈之一。我举个例子你就懂了。假设你要部署一个 7B 参数量、以 FP16 精度加载的模型光模型权重就要占 14GB 显存。推理的时候每生成一个 tokenGPU 都要把模型的所有权重从显存里读一遍喂给计算单元做前向传播。这时候决定生成速度的不是 GPU 算得多快而是它读数据读得多快。我们算一笔账一张 RTX 4090 的显存带宽约为 1008 GB/s算力约 82.6 TFLOPSFP16。如果纯算力跑满一个 7B 模型生成一个 token 的复杂度大概是 2 × 参数量约等于 14 GFLOPs理论上每秒钟可以生成 82.6T/14G接近 5900 个 token。但实际情况呢受限于带宽它每秒钟能读取的模型权重才 1008GB/14GB 约等于 72 次也就是说每秒最多生成 72 个 token。理论算力上限和实际带宽上限差了 80 倍。这就是为什么业内会说 LLM 推理是 memory-bound 的任务内存带宽决定了推理速度的绝对上限。1.3 显存带宽为什么这么难提升你可能想问为什么不把显存带宽做高一点这背后是物理层面的约束。显存颗粒和 GPU 核心的距离越近带宽越高但成本和功耗也越高。HBM 显存之所以贵就是因为它把存储颗粒直接堆叠在 GPU 核心旁边通过硅通孔连接传输距离极短。H100 的 HBM3 带宽达到 3.35 TB/s但价格也是天文数字。消费级的 GDDR6X 走的是独立颗粒加长走线的方案带宽能到 1 TB/s 已经很不容易。所以你要记住一个结论大模型推理的性能框架本质是在算力、显存容量、显存带宽三者之间做权衡。容量不够就换大卡或者做量化带宽不够就只能尽量减少权重读取次数。2. LLM 推理的完整链路从输入到输出 GPU 做了什么2.1 Prefill 和 Decode 两个阶段的性质差异理解 LLM 推理性能首先要分清它的两个阶段Prefill 和 Decode。Prefill 阶段是处理输入提示prompt的过程。用户输入几百个 token模型要同时处理这些 token计算所有层的注意力分数一次性生成完整的 KV Cache。这个阶段是典型的 compute-bound因为要同时计算大量 token 的矩阵乘法GPU 的算力可以被充分压榨。你在部署服务时看到的“首 token 延迟”TTFT就是被这个阶段决定的。Decode 阶段是逐个生成输出 token 的过程。每一步只生成一个 token但每生成一个都要把整个模型的权重全读一遍再做一次前向传播。这个阶段是典型的 memory-boundGPU 大部分时间都花在“把数据从显存搬到计算单元”的路上计算单元反而是闲着的。用一句话总结Prefill 阶段算力利用率高Decode 阶段带宽利用率高。这两个阶段对硬件资源的需求完全相反所以做性能优化时必须分开考虑。2.2 计算量公式为什么生成一个 token 这么费劲LLM 推理的计算量可以用一个简化公式估算虽然不够精确但足够指导工程决策。假设模型参数量为 P处理 B 个 token前向传播需要的浮点运算次数大约是 2 × P × B。这个 2 倍的系数来自权重和输出的双向传播严格说是 forward 时权重矩阵乘激活值每个参数对应两次浮点运算。对于 7B 模型生成一个 token 需要约 14 GFLOPs对于 70B 模型这个数字跳到 140 GFLOPs。但这只是权重读取部分。Decode 阶段还有一个隐藏的大头——KV Cache 的读取和注意力计算。输入序列越长KV Cache 越大每一步需要读取的 KV 数据就越多注意力计算的耗时也会线性增长。这就是为什么同样的模型你塞进去一篇长文之后生成速度会明显变慢。2.3 从 GPU 视角看 Transformer 算子的执行模式站在 GPU 角度剖析 Transformer 的每一步你会发现不同算子的“性格”完全不同。Embedding 和 LayerNorm 属于轻量级操作计算量小但涉及完整的显存读写属于纯带宽操作。QKV 投影和 FFN 的线性层是大规模矩阵乘算力消耗大户GPU 的 Tensor Core 就是为这类操作设计的。注意力分数计算是 batched matrix multiply特殊之处在于要对每个 token 行做 softmax涉及到跨行的归纳操作需要额外的 Reduce 步骤。KV Cache 写入和读取在长上下文场景下会变成隐形的带宽杀手。我自己做 profiling 的时候发现一个反直觉的现象当 batch size 较小、单条请求解码时Attention 里的算子耗时占比能到 30% 以上甚至超过线性层。这是因为单条请求时 GPU 根本没有足够的并行度去喂饱计算单元算子切换的开销开始主导一切。所以在做性能优化时脑子里的第一反应不应该是“算子太慢就换新算子”而应该先问“并行度够不够”。3. 预测性能的利器Roofline Model 和指标体系3.1 用 Roofline Model 判断瓶颈在算力还是带宽每次做 GPU 性能分析和优化我都会先画一张 Roofline Model也就是“屋顶模型”。这是一张二维坐标图横轴是算术强度Arithmetic Intensity定义为总浮点运算次数除以总字节数单位是 FLOPs/Byte纵轴是可达性能单位是 FLOPS。每个 GPU 的算力上限Peak FLOPS画一条水平线显存带宽上限画一条斜线两条线围起来的区域就是这张 GPU 的理论性能峰值。某个算子落在这个图上的位置决定了它是被算力限制还是被带宽限制。斜线下方是带宽受限区水平线下方是算力受限区分界点就在“算力峰值除以带宽”这个横坐标值上。RTX 4090 的算术强度分界点大概是 82.6 TFLOPS / 1008 GB/s 约等于 82 FLOPs/Byte。而 7B 模型做 Decode 时读取 14GB 权重只产生 14 GFLOPs 的计算量算术强度只有 1 FLOPs/Byte远远落在带宽受限区。这就能准确解释为什么算力再高也快不起来。3.2 LLM 推理的核心性能指标不只有 TPS聊到 LLM 推理速度新手最容易犯的错是只看“每秒生成多少个 token”TPS。这个指标过于单一无法反映真实用户体验和系统吞吐能力。做性能评估时我更习惯看完整的指标体系。TTFTTime To First Token指的是用户发起请求到收到第一个输出 token 的耗时由 Prefill 阶段决定。大 prompt、长上下文场景对这个指标尤其敏感。TPOTTime Per Output Token指的是除第一个 token 外每生成一个 token 的平均耗时反映 Decode 阶段的流畅度用户体感上的“慢不慢”主要看它。吞吐量Throughput指的是系统在单位时间内能处理的总 token 数衡量服务端资源利用效率。并发数Concurrency指的是能同时处理的请求数量与显存容量、KV Cache 管理策略直接相关。做性能评测时必须同时记录这些指标不能只看单条请求速度。很多框架支持很高的吞吐但为了吞吐牺牲了单条延迟TTFT 飙到十几秒用户压根等不住。3.3 用一张表格建立 LLM 推理性能基线日常做性能基线的快速评估我会把 GPU 的关键参数和对应的推理能力预期做成一张速查表实际测试时和基线做对比很快就能定位是不是出现配置问题。GPU 型号显存容量显存带宽FP16 算力7B FP16 理论 Decode 速度上限RTX 409024GB1008 GB/s82.6 TFLOPS约 72 token/sRTX 309024GB936 GB/s35.6 TFLOPS约 67 token/sA100 80GB80GB2039 GB/s312 TFLOPS约 145 token/sH100 80GB80GB3350 GB/s989 TFLOPSFP16约 239 token/s这里插一句理论 Decode 速度上限是拿“带宽除以模型权重大小”粗略估算的它只考虑了读取全部权重的耗时不含 KV Cache 读取、算子切换损耗等开销。真实数值通常要打个七折到八折但作为选型参考已经足够。4. 显存管理是日常运维的核心战场4.1 模型权重之外还有哪些东西在吃显存模型权重只是显存占用的一部分很多人部署时把显存算得刚刚好一跑起来就爆显存就是因为漏算了其他开销。首先是 KV Cache。这是 Transformer 在推理时为避免重复计算而缓存的历史 token 的 Key 和 Value 向量。它的显存占用和“batch size × 序列长度 × 层数 × 头维度 × 每个值占的字节数”成正比。一个 7B 模型输入输出长度都是 2048处理 8 条并发请求KV Cache 大概要占几个 GB。对于 70B 模型加长上下文KV Cache 可以轻松吃掉二三十 GB 显存。其次是推理框架本身的运行时开销。激活值、中间缓冲区、CUDA context、CUDA 分配器的预分配池等加起来通常要占几百 MB 到几个 GB。另外如果你在同一个 GPU 上同时跑多个模型进程显存碎片问题会让你明明看着还有几百 MB 空闲却申请不到一块连续的大内存。4.2 量化是把双刃剑用精度换容量和带宽模型量化是 LLM 部署绕不开的话题它同时影响显存容量和带宽瓶颈。以 7B 模型为例FP16 需要 14GBINT8 需要 7GBINT4 只需要 3.5GB。对带宽受限的 Decode 阶段来说把权重从 FP16 换成 INT4每步需要读取的字节数直接降到原来的四分之一Decode 速度理论上能提升接近四倍。代价是精度损失通常用 perplexity 和下游任务指标来评估量化后的质量衰退。我在实际部署里常用的组合是权重用 4-bit 量化加载比如 GPTQ、AWQKV Cache 保持 8-bit 或更高精度计算阶段做反量化后再做矩阵乘。这样在显存容量和精度之间取得了相对均衡的折中。要注意的是你选的推理框架必须对量化格式有良好的 kernel 支持否则有些算子没有优化实现反量化开销反而让速度更慢。4.3 批处理是提高吞吐的第一手段现在假设你已经确定好模型精度、算好显存占用、选好 GPU接下来怎么提升吞吐核心思路是 batch 尽量大。Decode 阶段是带宽瓶颈但 batch 增大时模型权重还是只读一次但一个批次里多个请求可以共享这次权重读取相当于摊薄了权重读取成本。计算量虽然变成单请求的好几倍但算力利用率大幅上升总体 token 吞吐能提高好几倍。这也是 FlashAttention、PagedAttention 这类技术的价值所在——它们不仅优化了注意力计算本身更重要的是让大 batch 的 KV Cache 显存管理变得更高效。PagedAttention 把 KV Cache 切成固定大小的块类似操作系统的分页机制按需分配避免外部碎片因此可以塞下更大的 batch间接拉高吞吐。你去看 vLLM 的官方文档它会把“通过 PagedAttention 实现更高吞吐”作为核心卖点原因就在这里。5. 从数字到实操不同推理框架的 GPU 利用方式对比5.1 llama.cpp 在 GPU 上到底怎么跑llama.cpp 是单机推理里热度最高的开源项目之一它的 GPU 支持选项经常让人头晕。其实只需要搞清楚几个参数就够了。-ngl参数控制有多少层模型被加载到 GPU 上。如果你设成 1只有第一层在 GPU 上跑其他层全部在 CPU。如果你的显存足够放下一整个模型就设成-ngl 999把所有层都放到 GPU。如果显存不够就根据显存剩余量从后往前分配层数其余层留在 CPU。但你要有心理准备只要有一层在 CPU 上跑权重就要在 CPU 内存和 GPU 显存之间来回拷贝传输耗时会成为新的瓶颈速度会显著下滑。-b参数控制 batch size影响 Prefill 阶段的并行度。-ub是单次解码的 batch size。-ts是手动指定 GPU 计算能力比例。日常使用我的建议是先跑起来再用-ngl拉满 GPU 层数然后通过--verbose日志确认每层的设备分配是否正确。5.2 vLLM 和 TensorRT-LLM 这类高性能框架的优化逻辑如果你要做在线推理服务llama.cpp 不是最优选择。vLLM 和 TensorRT-LLM 代表了另一个优化方向。vLLM 的核心创新是 PagedAttention。它把 KV Cache 分割成固定大小的物理块通过块表映射到逻辑地址空间类似虚拟内存机制。这样做的好处是显存利用率大幅提升可以支持更大的并发。配合 Continuous Batching连续批处理在流的请求结束或新请求到达时动态调整 batch避免显存被空闲请求占着。TensorRT-LLM 走的是另一个路线把模型编译成 TensorRT Engine在编译阶段做算子融合、内核自动调优、精度校准。融合算子减少多次读写显存的开销自动调优让每个算子在硬件上跑得更快。典型性能提升相比基准实现能到 2 到 5 倍代价是模型修改后需要重新构建 Engine调试链路变长。选型时我的经验是单机自用、追求快速上手选 llama.cpp做小型私有服务、需要高并发选 vLLM对性能有极致要求、愿意付出编译调试成本选 TensorRT-LLM 或者更重的部署平台。5.3 多卡推理和显存不足时的应对思路单卡显存不够装下模型就要考虑多卡方案。朴素的做法是用模型并行Model Parallelism或者张量并行Tensor Parallelism把模型按层或按行切分到多张卡上。切分后每张卡存一部分权重Decode 每步分别从各卡读取各自分片再通过 AllReduce 汇总结果。多卡之间的通信开销不可忽视。NVLink 和 NVSwitch 带宽高跨机走 Infiniband 或万兆网延迟差距很大。做多卡方案时首要考虑的是通信拓扑和 GPU 之间的互联带宽其次是尽量避免在 Decode 阶段频繁做跨卡同步。我也试过用多张消费级 24GB 卡拼出一个 70B 的部署环境效果能用但张量并行时的通信开销让速度远低于同级别的单卡 A100。6. 性能监控与问题排查GPU 利用率不等于一切6.1 nvidia-smi 的输出你真的看懂了吗排查 GPU 问题时第一个工具永远是 nvidia-smi。但很多人只盯着 “Volatile GPU-Util” 那一列看看到利用率低就以为 GPU 没干活这个认知误区害人不浅。GPU-Util 只表示“有多少流处理器上有活动线程”不表示算力被利用得多么充分。LLM Decode 阶段是带宽瓶颈计算单元大部分时间在等待数据搬运GPU-Util 可能只有 20% 到 40%但推理速度已经接近硬件极限。反过来GPU-Util 拉到 100% 也可能是因为某个简单算子在反复占用核心实际吞吐并不高。要真正看懂这张表的全部信息你得关注这几个字段显存占用代表模型的权重加 KV Cache 的体量温度决定会不会开启降频保护过热会导致性能雪崩功耗反映实际负载强度如果功耗远低于 TDP 上限说明有硬件层面的瓶颈硬件利用率需要配合 NVIDIA DCGM 工具或者 nvtop 才能看到更细的 GPU 时钟、内存时钟、PCIe 带宽占用。6.2 常见问题速查从“慢”到“崩”的排查路径部署运行中我总结了一套问题排查优先级遇到异常时按这个顺序排查命中率很高。GPU 利用率持续极低同时模型响应慢先查数据加载和预处理链路。检查数据管道是否成了瓶颈比如 Python 读文件、分词线程阻塞。其次查 prompt 长度和 KV Cache 分配策略。GPU 显存充足速度还是上不去先确认是否跑在纯 CPU 的后备路径上例如某些操作符不受 GPU 支持自动落到 CPU再查看驱动和 CUDA 版本是否匹配。爆显存时先分清楚是权重显存还是 KV Cache 显存。用nvidia-smi看进程占用如果是 KV Cache 撑爆降低最大 batch 数、限制并发请求或换用更低的 KV Cache 精度。GPU 温度和功耗异常先看散热和供电清理灰尘、检查 PCIe 接口供电是否稳定服务器环境看重卡槽散热风道。推理速度突降怀疑被限流或降频用nvidia-smi -q -d CLOCK,PERFORMANCE查看 GPU 性能状态P0 到 P12数值越低性能越高。如果系统频繁报 CUDA out of memory但显存看着还有空余考虑显存碎片问题试试重启进程或调整框架的显存分配策略。6.3 一个实战案例我的 4090 上没有跑满速度的一次排障我印象最深的一次排障是部署 13B Qwen 模型时理论上带宽上限是 72 token/s我彼时用的 llama.cpp 只跑到 30 token/s差了整整一半。当时第一个怀疑对象就是 GPU 利用率一看 nvidia-smiGPU-Util 在 90% 以上心想利用率已经拉满问题应该出在别处。后来用ncuNVIDIA Nsight Compute对算子级运行时间做了 profiling发现耗时大头竟然是 softmax 和 RMSNorm。这两个算子计算密度低但每次都需要把整个激活矩阵读进读出在带宽受限的体系里比线性层还折磨人。排查到内存拷贝 API 的调用发现原来模型权重存储在 CPU 上每层都要做 H2D 拷贝额外消耗了大量带宽。修改配置把权重全部预加载到显存再把-b从 512 调到 2048速度直接逼近 55 token/s基本顶到了带宽上限。这次排障让我彻底相信排查瓶颈时永远先看显存带宽和数据流再看算力。7. 优化实战如何把每块 GPU 的潜力榨干7.1 选型阶段根据模型规模反推硬件需求做技术选型时我曾经走过“先有卡再换模型”的弯路正确的思路应该是“先定模型规模再倒推硬件”。第一步确认模型参数量、加载精度和上下文长度。第二步用公式估算显存需求权重显存 参数量 × 每个参数字节数KV Cache 显存 2K 和 V 分别一个 × 层数 × 每层 KV 头数 × 头维度 × 序列长度 × 每元素字节数 × batch。第三步根据显存带宽预估 Decode 速度是否达标。以部署 70B 模型、INT4 精度、上下文 8192 为例权重约 35GB70B × 0.5 字节KV Cache 约 10 到 20GB加上框架开销单卡不上 80GB 就别想跑A100 80GB 或双卡 48GB 方案起步。如果对 Decode 速度要求不高只做离线批量生成可以牺牲一些吞吐换更低的硬件成本。7.2 运行时优化从 batch 到精度再到算子运行时优化我一般按以下顺序做每一步都有明确的收益预期。先把 batch 和并发调到显存允许范围内的最大值。使用 vLLM 时通过--max-num-seqs控制并发连续批处理会动态优化调度。再根据误差容忍度选择量化方案。追求速度用 AWQ 4-bit 或 GPTQ 4-bit追求质量和速度均衡用 FP8 或 INT8KV Cache 精度可以单独设置。然后开启算子级优化FlashAttention 是最基础的它减掉了中间矩阵的显存写入既省带宽又省容量。最后检查是否开启了 CUDA Graph 和推理框架的预编译优化。CUDA Graph 把一次推理的 GPU kernel 启动序列捕获成一个图减少 kernel launch 的 CPU 开销。对短序列、低 batch 的小请求这项优化收益非常大因为它省掉的是每步推理里几千次 kernel 启动的固定成本。7.3 终极优化基于“权重复用”思想做部署上面所有优化都指向同一个方向最大程度复用权重读取。这也是我最终理解 LLM 推理优化本质的一刻。权重从显存到计算单元传输一次应该尽可能参与更多的有效计算。所以 batch 越大越好一个请求和一百个请求共用一个权重读取过程单位 token 的带宽成本会大幅下降。KV Cache 则相反它和请求一对一绑定一旦请求完成它就应该立刻释放让显存及时回到池中。这也是为什么 PagedAttention 这类技术能显著提升性能——它让 KV Cache 的分配和释放更接近“刚刚好”。当你把推理过程理解成“权重是稀缺的复用资源、KV Cache 是需要精细管理的临时资源、带宽是最大的物理约束”这三个维度时GPU 上的 LLM 部署优化就不再是黑盒了你拿到任何框架和硬件组合都能一眼看出性能瓶颈和优化方向。最后分享一个我至今觉得最实用的经验拿到新卡或新框架的第一件事不是跑复杂的 benchmark而是先用一个固定 prompt、固定输出长度做单串延迟测试再用ncu做一次算子级 profiling。这两步能让你在十分钟之内判断出当前环境是算力受限、带宽受限还是配置问题。这个简单流程帮我省下的折腾时间远超任何一份官方性能白皮书的价值。