你测过同一套大模型在不同显卡上的推理速度之后大概率会有一个困惑为什么一张宣传算力很高的卡跑起来并不比“低端卡”快多少为什么官方给的算力数字那么漂亮自己一压测就现原形这里面的门道不是“GPU很厉害”一句话能说清的。LLM推理的性能表现本质上是显存容量、显存带宽、计算单元效率、数据搬运方式四者的综合结果。算力只是其中一环往往还不是瓶颈那一环。这篇文章我从硬件底层的视角把GPU运行LLM时的实际工作流程拆开来看。适合两类人一类是准备做LLM推理部署、正在选卡的工程师另一类是已经在跑推理但遇到性能瓶颈、想搞清楚该往哪个方向调优的开发者。1. LLM推理的瓶颈不在算法而在硬件配合方式首先得明确一个核心判断当前大模型推理的绝大多数场景真正的瓶颈并不是GPU的计算速度而是显存和带宽。打个比方。GPU就像一个大型厨房计算单元是灶台显存是冰箱。做菜的时候你得先从冰箱把食材拿出来再放到灶台上处理。如果冰箱离灶台远、搬运速度慢那么不管你灶台火多大、锅多热做菜速度都受限于“从冰箱到灶台”这段路的搬运效率。GPU处理LLM推理任务时情况非常类似而且这个“搬运效率”问题被放大了很多倍。原因在于Transformer架构本身的特性。1.1 自回归生成一个Token一个Token地算无论你用ChatGPT还是本地部署的llama.cppLLM生成文本的方式都是自回归的——一个Token一个Token地往外蹦。每生成一个Token都需要把模型的全部权重从显存里读一遍。以一个13B参数、FP16精度的模型为例。13B个参数每个参数占2字节那么光权重就是26GB。每生成一个Token这26GB数据都要从显存完整搬运到计算单元。注意是每一个Token都要搬一次。而这块GPU的计算单元处理这26GB数据需要多久我们拿一张比较主流的卡来算一下。假设它的理论算力是每秒几百TFLOPs那么对这26GB权重做完一遍矩阵乘加操作计算时间其实只用几毫秒。但从显存里把26GB数据搬出来的时间受限于显存带宽——假设带宽为1TB/s那就要26毫秒。也就是说计算单元大部分时间是在干等数据。真正的计算时间可能只占20%不到剩下的80%时间都在做数据搬运。这种情况下你换一张算力更高的卡提升会很小因为你增加的是灶台的火力缩短不了从冰箱搬菜的时间。1.2 Compute Bound与Memory Bound的分野业界把这种情况称为Memory Bound访存受限。与之相对的是Compute Bound计算受限指的是计算本身耗时远大于数据搬运耗时这时候提升算力才有明显效果。区分自己的场景属于哪种受限是性能调优的第一课。怎么判断就看你显存的利用率如果显存带宽被打满但计算单元利用率比如nvidia-smi里的GPU-Util只有百分之三四十那就是Memory Bound。如果计算单元长期高负载显存带宽还有大量空闲那就是Compute Bound。LLM推理在小batch size场景下几乎无脑属于Memory Bound。这也是为什么很多人在本地跑大模型时发现7B和13B的速度差距远小于参数量的差距——参数多了一倍但两者都卡在带宽上速度落后的比例并没有那么悬殊。1.3 为什么训练比推理更容易吃满算力观察过GPU训练模型的朋友可能发现了训练时GPU利用率往往能跑到90%以上而推理时常常只有20%-30%。这不是某个框架优化不到位而是任务本身的差异决定的。训练时是batch size很大的矩阵运算一次喂入成千上万个样本数据可以被大规模复用。计算强度和访存量的比值很高能吃到大量算力。而推理时是逐个生成Token每次只处理很少的数据但必须把全部权重读一遍。复用率极低自然就变成“搬运主导”了。明白了这个底层差异再去看各种推理框架的优化手段思路就会清晰很多。它们的目标基本都指向同一件事提高权重复用率或者降低权重复读量。2. 一张显卡的显存账本权重、KV Cache与激活值怎么瓜分容量前面提到的权重只是显存账本的一项。实际部署LLM时显存开支由三部分组成模型权重、KV Cache、激活值。每个部分都可以单独算也都值得单独算。2.1 模型权重有多少参数就有多少体积这部分是最直观的。模型权重占用的显存 参数量 × 每个参数的字节数。FP32精度4字节/参数FP16/BF16精度2字节/参数INT8量化1字节/参数INT4量化0.5字节/参数每两个参数共享1字节以最常见的7B模型为例FP16就是14GBINT8是7GBINT4是3.5GB。这个账很好算也是大家拿到一个新模型后第一件要估的事。但是要注意推理框架通常还要预留一部分显存做kernel执行和计算缓冲。所以不要看见模型文件是14GB就觉得14GB显存的卡一定装得下实际跑起来可能是14.5GB甚至15GB的占用再加上KV Cache的增量很容易爆显存。2.2 KV Cache被大多数人忽略的大头KV Cache是Transformer自注意力机制带来的特有显存开销。简单说模型每次生成一个新Token都要回过头去“重新看”之前生成过的所有Token。为了不重复计算之前Token的Key和Value矩阵框架会把这些中间结果缓存在显存里。KV Cache的大小可以精确计算。公式是KV Cache大小 2 × 层数 × 多头数 × 每个头的维度 × 序列长度 × 批大小 × 字节数其中乘以2是因为K和V各存一份。拿Llama 2 7B来举例32层32个注意力头每个头128维也就是隐藏维度4096。当序列长度是2048、batch size为1时2 × 32 × 4096 × 2048 × 1 × 2字节 1GB看起来还行。但把context length拉长到32768这一项就变成了16GB比模型权重还大。就知道为什么长上下文推理这么吃显存了。这也是为什么很多推理框架会提供--ctx-size参数让你自己控制上下文长度。你以为限制的是“对话记忆长度”其实限制的是KV Cache的显存消耗。2.3 激活值跑起来才知道的隐藏支出激活值是前向传播过程中各层输出的中间结果。这部分在训练时是个天文数字推理时由于batch小通常不是主要开销但在某些高并发场景也不能忽视。判断激活值大小有个经验公式每层激活值大概是隐藏维度 × 序列长度 × batch size × 若干系数。在实际部署中它通常只占显存的一小部分但如果你用很小的模型配合超长上下文激活值也可能成为压垮显存的那根稻草。2.4 算一笔总账部署前建议按这个顺序估算模型权重参数量 × 精度字节数KV Cache上限按你的最大序列长度和最大并发数计算激活值余量预留总显存的10%-20%框架开销预留几百MB到1GB以一张24GB显存的卡为例干跑一个FP16的13B模型26GB权重是不可能的但跑INT8量化后的13B13GB权重绰绰有余。再加上8K上下文的KV Cache约4GB一共17GB左右还剩6GB余量给激活和系统开销可行性很高。这张账算清楚很多选型问题就迎刃而解了。热搜里“gpu显存容量 是测算推理还是训练用的”这个问题就是这个账没算明白的表现——训练和推理的显存构成逻辑完全不同必须分开算。3. 算力没有跑满的真相访存延迟、并发粒度与SM占用率很多人在nvidia-smi看到GPU-Util只有30%第一反应是“卡没吃满是不是代码写得有问题”。实际上这个数字的语义和一般的CPU利用率完全不同它反映的只是“最近一段时间内有计算任务在跑的时间比例”并不代表计算单元的真实负载率。想要真正理解GPU干活的状态得往芯片内部再走一步。3.1 SM、CUDA Core与Tensor CoreGPU的工作单元GPU内部有若干SMStreaming Multiprocessor流式多处理器每个SM相当于一个小型计算组。每个SM里有两类计算单元CUDA Core负责通用的标量计算Flexible但相对慢Tensor Core专门为矩阵乘加设计的加速单元吞吐量远高于CUDA Core现代LLM推理框架几乎全部依赖Tensor Core干活。Transformer里大量的矩阵乘法映射到Tensor Core上就是高效的乘加运算。CUDA Core更多是处理Elementwise操作、激活函数、LayerNorm这类杂活。衡量Tensor Core利用率有个公式实际FLOPs / 理论FLOPs。理论FLOPs是一张卡出厂就定死的上限实际能跑到多高取决于你在什么精度下运行、矩阵大小是否够大、数据是否已对齐等。3.2 线程束WarpGPU调度的最小单位GPU的调度以**Warp线程束**为单位每个Warp通常包含32个线程。SM以Warp为粒度分配计算任务而不是一个线程一个线程地分配。当SM收到一个计算任务时会把它拆成多个Warp调度执行。每个Warp内部32个线程做同一个指令、操作不同数据——这就是**SIMT单指令多线程**模型。为什么这会影响LLM推理性能因为你的batch size和序列长度决定了矩阵大小而矩阵大小直接影响了有多少个Warp可以被调度。矩阵太小Warp数量不足SM内部的调度器就喂不饱执行单元算力自然上不来。这也解释了为什么同一张卡跑大batch size更快——单纯从计算角度讲大batch产生了更大、更规则的矩阵让SM的每个执行单元都忙起来了。3.3 显存带宽真正的第一资源前面反复说到带宽这里再量化一下它的重要性。以H100 SXM为例它有3.35TB/s的显存带宽这是业界顶尖水平。但当你要在8K上下文、batch size 1的情况下跑一个7B模型时每生成一个Token就需要从显存搬运约14GB-20GB的数据取决于KV Cache命中情况。粗略算一下14GB / 3350GB/s ≈ 4.2毫秒也就是说硬件层面的数据搬运下限就是4.2毫秒。计算部分即使优化到极限也只是在这个4.2毫秒上叠加很小的边际。而实际部署中我们看到的Token生成速度往往就卡在这个量级附近。这也说明了为什么提升推理速度最有效的手段永远是减少搬运量而不是提升算力。量化、剪枝、蒸馏本质上都是为了让每次搬运的数据变少从而突破带宽瓶颈。3.4 OccupancySM占用率的真实含义GPU性能调试工具里常见的Occupancy指标指的是SM中活跃Warp数量与最大可容纳Warp数量的比值。很多人刚接触时把它理解为“GPU用了几成”其实它反映的是“SM的资源分配情况”。每个Warp运行时需要占用一定数量的寄存器和共享内存。如果一个kernel的寄存器用量很大SM能同时容纳的Warp就少Occupancy就低。Occupancy低不一定是坏事——有时候你的计算量就这么大不需要那么多Warp同时跑。但如果你发现Occupancy很低、访存延迟又高那就说明SM里的“并行度”不足难以用并发掩盖访存延迟。看LLM推理性能时与其盯着GPU-Util这个粗粒度指标不如同时观察Memory Controller Utilization显存控制器的繁忙程度Tensor Core ActiveTensor Core被激活的周期占比OccupancySM上的Warp活跃度三者综合才能判断出你的场景到底卡在哪一环。4. Tensor Core与精度策略从FP32到FP16/INT8/INT4的性能账搞懂了硬件结构回到日常部署中最常做的一个决策——用什么精度跑模型。这个决策直接影响权重体积、KV Cache体积、计算速度和生成质量是LLM推理调优里杠杆最高的一步。4.1 不同精度的吞吐差异Tensor Core对不同精度的计算吞吐是截然不同的。以一张消费级显卡RTX 4090为例FP32约83 TFLOPsFP16 Tensor Core约330 TFLOPsINT8 Tensor Core约660 TFLOPs从FP32换到FP16算力直接翻4倍。因为Tensor Core本身就是为低精度矩阵运算设计的它在FP32模式下甚至不能充分发挥。而INT8在16进制模式下又能再翻一倍。这也解释了为什么所有推理框架默认都跑FP16或BF16——不是因为FP32效果不好而是Tensor Core在FP32下根本跑不了多快。4.2 精度降低带来的连锁收益降低精度不只是提速还连锁改善了一堆问题权重体积减半FP16比FP32少一半显存INT8再少一半KV Cache变小KV Cache也可以以低精度存储比如FP16 KV Cache比FP32省一半带宽压力减小每次Token生成需要搬运的数据变少Memory Bound问题的压力直接下降并发能力提升显存省下来了同一张卡能塞进的并发请求就多了这就是为什么INT8/INT4量化部署在LLM推理领域几乎是必选项。你放弃了一些精度换来的是成倍的吞吐提升。4.3 量化的代价不在精度而在分布量化没有想象中那么简单直接调低精度往往会导致输出质量明显下降。问题不在于精度数值的减小而在于数值分布的不均匀。LLM的权重和激活值通常遵循一种近似高斯分布的形态大部分值集中在零附近少数值非常大。如果均匀量化比如把最大值映射到127其余等比例缩放大部分数值会落在极低的量化分辨率区域精度损失非常大。这也是为什么现在流行混合精度量化和Per-channel量化。Per-channel是指对矩阵的每一行channel单独计算缩放因子而不是整个矩阵共用一个。这样每一行的数值范围都能得到精确映射INT8量化后的损失可以从不可接受降到几乎无感。如果你在部署中遇到“量化后效果崩了”的情况不要急着断言“量化不可用”先检查量化方式是不是均匀量化整个权重矩阵。换成Per-channel或Per-group量化往往能救回来。4.4 FlashAttention注意力计算的算力复辟前面反复强调LLM推理是Memory Bound但也有例外。当序列特别长、batch size特别大时注意力部分的计算量会急剧上升。这时注意力计算本身可能变成新的瓶颈。标准Attention的实现里需要把完整的注意力分数矩阵写入显存再读出来。序列长度是2048时这个矩阵是2048×2048还好序列长度是32768时就是32768×32768也就是10亿个元素。写入再读出两次显存往返数据搬运量极其夸张。FlashAttention的做法是分块计算让注意力分数的计算和Softmax在SRAM片上缓存里完成不经过显存。它减少的不是计算量而是显存读写量。实测中FlashAttention能把长序列下的注意力计算速度提升数倍同时大幅减少显存占用。用一句话说FlashAttention的本质就是意识到“计算一下”比“存取一次”便宜得多从而把访存密集型算子改写成了计算密集型算子。4.5 推理框架怎么选精度实际操作中不同框架对精度的支持有差别。llama.cpp支持从FP16到INT4的全链路量化vLLM对INT8/FP8的支持越来越完善TensorRT-LLM则追求极致性能支持FP8 KV Cache等高级配置。选精度没有银弹我的经验是显存够用权重和KV Cache放得下优先FP16/BF16省心且效果好显存临界上INT8用Per-channel量化损失通常不明显显存实在不够INT4但要充分测试输出质量必要时用有损度更小的量化方案5. 实际部署中的性能台阶从单卡到多卡的调度问题前面聊的都是单卡场景但实际部署里多卡并行非常常见。多卡的关键问题在于你的工作负载适不适合多卡以及怎么分配才最高效。5.1 单卡放不下多卡怎么切当模型权重超过单卡显存时有两种切分思路张量并行和流水线并行。张量并行是把一个矩阵运算拆成多块分别在不同GPU上计算再汇总结果。比如一个4096维的矩阵乘法切到4张卡上每张卡算1024维算完集合通信合并。这种方式通信频繁但显存利用均匀适合卡间高速互联的场景比如NVLink。流水线并行则是按层切分——第1-8层放卡1第9-16层放卡2。数据按顺序流过各卡。这种方式通信次数少但存在“串行气泡”——后面的卡在等前面的卡算完才能接手利用率会有损失。对于推理场景我个人的倾向是能单卡就别多卡能张量并行就别流水线并行。推理的单Token延迟对通信延迟极其敏感张量并行虽然通信多但至少所有卡同时在工作流水线并行在batch size小时几乎必然出现空转。5.2 并发推理与动态BatchingGPU推理服务器比如vLLM提升吞吐的核心手段是动态Batching。思路很简单多个用户的请求到达时间不同但GPU必须攒够了数据才高效。于是服务器把前后脚的请求拼在一起组成一个更大的batch同时送入GPU计算算完再各回各家。如果每个请求单独处理8K上下文、batch size 1的Memory Bound问题会一直卡着不动。动态Batching让多个请求共享权重搬运权重只要读一次可以服务多个请求。这从本质上提高了权重复用率也就是提升了算力利用率。部署层面这个机制对显存提出了额外要求。多个请求的KV Cache会同时驻留显存并发数越高KV Cache总需求越大。所以优化并发吞吐时最常遇到的瓶颈反而不是算力而是KV Cache的显存占用。5.3 显存不够时的终极备选Offload网上热搜词里有个“gpu虚拟内存”其实就是显存不够时把部分数据放在内存甚至硬盘里需要时再搬到显存。这个思路的代价是CPU内存的带宽远低于GPU显存带宽数据搬运速度会慢一个数量级以上。所以Offload只适合“跑起来就行不太在意速度”的场景。像llama.cpp提供的--mlock和offload比例参数就能控制多少层放显存、多少层放内存。如果显存能覆盖绝大部分层只有少数层offload到内存就可以承受这个带宽损失——毕竟内存也要通过PCIe和CPU交互但比把整块模型都放在内存里跑要快得多。5.4 监控与定位瓶颈到底在哪里聊了这么多回到工程实操。当你部署完一个服务发现吞吐低于预期时建议按以下路径排查先看nvidia-smi的显存占用——是不是已经接近卡的上限如果是大概率是显存不足导致的swap或OOM看显存带宽利用率和GPU-Util的对比——如果GPU-Util低、带宽高是Memory Bound调优重点放在降低KV Cache和权重精度上如果GPU-Util高但吞吐上不去看看是不是模型权重精度太高、Tensor Core吃不消或者batch size过小导致并发度不足如果是多卡环境检查NVLink通信占比——通信占比过高的话切割方案可能需要调整最后再考虑batch size、并发度等业务层参数这套排查路径不一定直接指向最优解但一定能把问题圈定在一个可量化的范围内。比盲目换卡、盲目调参要有效得多。6. 选卡逻辑与长期运维视角最后聊一聊选卡这件事。热搜词里“gpu租用”“gpu服务器运维都做哪些工作”“manjaro nvidia gpu 监控”这类问题其实指向同一个需求怎么用成熟可靠的基础设施而不是自己苦哈哈地折腾硬件。6.1 按场景选卡的思路不要先看卡再想干什么先明确你的场景再选卡本地个人跑模型7B-13B规模24GB显存的消费级卡是最佳甜点INT4/INT8下能跑大部分开源模型单卡就能cover企业级推理服务高并发、低延迟优先考虑数据中心卡H20、H100这类关键是看显存带宽和NVLink互联超大模型微调更看重显存容量和卡间通信这时候多卡集群是标配长上下文应用重点看显存容量因为KV Cache对显存的消耗不像权重那样可量化6.2 运维视角的GPU关键指标跑推理服务时日常巡检建议重点盯这几个指标显存温度与功耗长期满负载运行散热和功耗漂移会导致性能下降显存错误率ECC error数据中心卡的ECC内存出现可纠正错误越来越频繁时说明显存寿命到期该换卡了PCIe/NVLink链路稳定性多卡通信链路出问题是性能突降的头号元凶每张GPU都有自己的生命周期显存颗粒的物理老化是实实在在的。与其等卡出故障去排查不如养成周期性记录性能基线的习惯。比如每周跑一次标准的推理benchmark记录P50/P99延迟。哪天发现同样的工具链下P99延迟比基线高了20%以上大概率就是硬件层面出问题了。6.3 一份实用的快速验证清单在正式部署前花十五分钟跑一遍这个清单能省掉后续很多麻烦确认驱动和CUDA版本与框架匹配用nvidia-smi -q检查GPU当前状态、功耗上限、温度用一个小模型先跑一次推理确认精度和数据结果没有异常连续跑10分钟压力测试观察温度曲线是否稳定有没有触发降频检查多卡场景下的通信情况确认NVLink全部up这套清单相当于给你手里的“灶台”做一个全面体检。灶台没问题后面做菜部署调优才谈得上味道。很多新手一开始就盯着模型效果调提示词模型效果调好了又发现推理速度跟不上这时候才回头怀疑硬件有问题。反过来先把硬件底座验明白再往上调模型和框架能少走一半弯路。
你测过同一套大模型在不同显卡上的推理速度之后大概率会有一个困惑为什么一张宣传算力很高的卡跑起来并不比“低端卡”快多少为什么官方给的算力数字那么漂亮自己一压测就现原形这里面的门道不是“GPU很厉害”一句话能说清的。LLM推理的性能表现本质上是显存容量、显存带宽、计算单元效率、数据搬运方式四者的综合结果。算力只是其中一环往往还不是瓶颈那一环。这篇文章我从硬件底层的视角把GPU运行LLM时的实际工作流程拆开来看。适合两类人一类是准备做LLM推理部署、正在选卡的工程师另一类是已经在跑推理但遇到性能瓶颈、想搞清楚该往哪个方向调优的开发者。1. LLM推理的瓶颈不在算法而在硬件配合方式首先得明确一个核心判断当前大模型推理的绝大多数场景真正的瓶颈并不是GPU的计算速度而是显存和带宽。打个比方。GPU就像一个大型厨房计算单元是灶台显存是冰箱。做菜的时候你得先从冰箱把食材拿出来再放到灶台上处理。如果冰箱离灶台远、搬运速度慢那么不管你灶台火多大、锅多热做菜速度都受限于“从冰箱到灶台”这段路的搬运效率。GPU处理LLM推理任务时情况非常类似而且这个“搬运效率”问题被放大了很多倍。原因在于Transformer架构本身的特性。1.1 自回归生成一个Token一个Token地算无论你用ChatGPT还是本地部署的llama.cppLLM生成文本的方式都是自回归的——一个Token一个Token地往外蹦。每生成一个Token都需要把模型的全部权重从显存里读一遍。以一个13B参数、FP16精度的模型为例。13B个参数每个参数占2字节那么光权重就是26GB。每生成一个Token这26GB数据都要从显存完整搬运到计算单元。注意是每一个Token都要搬一次。而这块GPU的计算单元处理这26GB数据需要多久我们拿一张比较主流的卡来算一下。假设它的理论算力是每秒几百TFLOPs那么对这26GB权重做完一遍矩阵乘加操作计算时间其实只用几毫秒。但从显存里把26GB数据搬出来的时间受限于显存带宽——假设带宽为1TB/s那就要26毫秒。也就是说计算单元大部分时间是在干等数据。真正的计算时间可能只占20%不到剩下的80%时间都在做数据搬运。这种情况下你换一张算力更高的卡提升会很小因为你增加的是灶台的火力缩短不了从冰箱搬菜的时间。1.2 Compute Bound与Memory Bound的分野业界把这种情况称为Memory Bound访存受限。与之相对的是Compute Bound计算受限指的是计算本身耗时远大于数据搬运耗时这时候提升算力才有明显效果。区分自己的场景属于哪种受限是性能调优的第一课。怎么判断就看你显存的利用率如果显存带宽被打满但计算单元利用率比如nvidia-smi里的GPU-Util只有百分之三四十那就是Memory Bound。如果计算单元长期高负载显存带宽还有大量空闲那就是Compute Bound。LLM推理在小batch size场景下几乎无脑属于Memory Bound。这也是为什么很多人在本地跑大模型时发现7B和13B的速度差距远小于参数量的差距——参数多了一倍但两者都卡在带宽上速度落后的比例并没有那么悬殊。1.3 为什么训练比推理更容易吃满算力观察过GPU训练模型的朋友可能发现了训练时GPU利用率往往能跑到90%以上而推理时常常只有20%-30%。这不是某个框架优化不到位而是任务本身的差异决定的。训练时是batch size很大的矩阵运算一次喂入成千上万个样本数据可以被大规模复用。计算强度和访存量的比值很高能吃到大量算力。而推理时是逐个生成Token每次只处理很少的数据但必须把全部权重读一遍。复用率极低自然就变成“搬运主导”了。明白了这个底层差异再去看各种推理框架的优化手段思路就会清晰很多。它们的目标基本都指向同一件事提高权重复用率或者降低权重复读量。2. 一张显卡的显存账本权重、KV Cache与激活值怎么瓜分容量前面提到的权重只是显存账本的一项。实际部署LLM时显存开支由三部分组成模型权重、KV Cache、激活值。每个部分都可以单独算也都值得单独算。2.1 模型权重有多少参数就有多少体积这部分是最直观的。模型权重占用的显存 参数量 × 每个参数的字节数。FP32精度4字节/参数FP16/BF16精度2字节/参数INT8量化1字节/参数INT4量化0.5字节/参数每两个参数共享1字节以最常见的7B模型为例FP16就是14GBINT8是7GBINT4是3.5GB。这个账很好算也是大家拿到一个新模型后第一件要估的事。但是要注意推理框架通常还要预留一部分显存做kernel执行和计算缓冲。所以不要看见模型文件是14GB就觉得14GB显存的卡一定装得下实际跑起来可能是14.5GB甚至15GB的占用再加上KV Cache的增量很容易爆显存。2.2 KV Cache被大多数人忽略的大头KV Cache是Transformer自注意力机制带来的特有显存开销。简单说模型每次生成一个新Token都要回过头去“重新看”之前生成过的所有Token。为了不重复计算之前Token的Key和Value矩阵框架会把这些中间结果缓存在显存里。KV Cache的大小可以精确计算。公式是KV Cache大小 2 × 层数 × 多头数 × 每个头的维度 × 序列长度 × 批大小 × 字节数其中乘以2是因为K和V各存一份。拿Llama 2 7B来举例32层32个注意力头每个头128维也就是隐藏维度4096。当序列长度是2048、batch size为1时2 × 32 × 4096 × 2048 × 1 × 2字节 1GB看起来还行。但把context length拉长到32768这一项就变成了16GB比模型权重还大。就知道为什么长上下文推理这么吃显存了。这也是为什么很多推理框架会提供--ctx-size参数让你自己控制上下文长度。你以为限制的是“对话记忆长度”其实限制的是KV Cache的显存消耗。2.3 激活值跑起来才知道的隐藏支出激活值是前向传播过程中各层输出的中间结果。这部分在训练时是个天文数字推理时由于batch小通常不是主要开销但在某些高并发场景也不能忽视。判断激活值大小有个经验公式每层激活值大概是隐藏维度 × 序列长度 × batch size × 若干系数。在实际部署中它通常只占显存的一小部分但如果你用很小的模型配合超长上下文激活值也可能成为压垮显存的那根稻草。2.4 算一笔总账部署前建议按这个顺序估算模型权重参数量 × 精度字节数KV Cache上限按你的最大序列长度和最大并发数计算激活值余量预留总显存的10%-20%框架开销预留几百MB到1GB以一张24GB显存的卡为例干跑一个FP16的13B模型26GB权重是不可能的但跑INT8量化后的13B13GB权重绰绰有余。再加上8K上下文的KV Cache约4GB一共17GB左右还剩6GB余量给激活和系统开销可行性很高。这张账算清楚很多选型问题就迎刃而解了。热搜里“gpu显存容量 是测算推理还是训练用的”这个问题就是这个账没算明白的表现——训练和推理的显存构成逻辑完全不同必须分开算。3. 算力没有跑满的真相访存延迟、并发粒度与SM占用率很多人在nvidia-smi看到GPU-Util只有30%第一反应是“卡没吃满是不是代码写得有问题”。实际上这个数字的语义和一般的CPU利用率完全不同它反映的只是“最近一段时间内有计算任务在跑的时间比例”并不代表计算单元的真实负载率。想要真正理解GPU干活的状态得往芯片内部再走一步。3.1 SM、CUDA Core与Tensor CoreGPU的工作单元GPU内部有若干SMStreaming Multiprocessor流式多处理器每个SM相当于一个小型计算组。每个SM里有两类计算单元CUDA Core负责通用的标量计算Flexible但相对慢Tensor Core专门为矩阵乘加设计的加速单元吞吐量远高于CUDA Core现代LLM推理框架几乎全部依赖Tensor Core干活。Transformer里大量的矩阵乘法映射到Tensor Core上就是高效的乘加运算。CUDA Core更多是处理Elementwise操作、激活函数、LayerNorm这类杂活。衡量Tensor Core利用率有个公式实际FLOPs / 理论FLOPs。理论FLOPs是一张卡出厂就定死的上限实际能跑到多高取决于你在什么精度下运行、矩阵大小是否够大、数据是否已对齐等。3.2 线程束WarpGPU调度的最小单位GPU的调度以**Warp线程束**为单位每个Warp通常包含32个线程。SM以Warp为粒度分配计算任务而不是一个线程一个线程地分配。当SM收到一个计算任务时会把它拆成多个Warp调度执行。每个Warp内部32个线程做同一个指令、操作不同数据——这就是**SIMT单指令多线程**模型。为什么这会影响LLM推理性能因为你的batch size和序列长度决定了矩阵大小而矩阵大小直接影响了有多少个Warp可以被调度。矩阵太小Warp数量不足SM内部的调度器就喂不饱执行单元算力自然上不来。这也解释了为什么同一张卡跑大batch size更快——单纯从计算角度讲大batch产生了更大、更规则的矩阵让SM的每个执行单元都忙起来了。3.3 显存带宽真正的第一资源前面反复说到带宽这里再量化一下它的重要性。以H100 SXM为例它有3.35TB/s的显存带宽这是业界顶尖水平。但当你要在8K上下文、batch size 1的情况下跑一个7B模型时每生成一个Token就需要从显存搬运约14GB-20GB的数据取决于KV Cache命中情况。粗略算一下14GB / 3350GB/s ≈ 4.2毫秒也就是说硬件层面的数据搬运下限就是4.2毫秒。计算部分即使优化到极限也只是在这个4.2毫秒上叠加很小的边际。而实际部署中我们看到的Token生成速度往往就卡在这个量级附近。这也说明了为什么提升推理速度最有效的手段永远是减少搬运量而不是提升算力。量化、剪枝、蒸馏本质上都是为了让每次搬运的数据变少从而突破带宽瓶颈。3.4 OccupancySM占用率的真实含义GPU性能调试工具里常见的Occupancy指标指的是SM中活跃Warp数量与最大可容纳Warp数量的比值。很多人刚接触时把它理解为“GPU用了几成”其实它反映的是“SM的资源分配情况”。每个Warp运行时需要占用一定数量的寄存器和共享内存。如果一个kernel的寄存器用量很大SM能同时容纳的Warp就少Occupancy就低。Occupancy低不一定是坏事——有时候你的计算量就这么大不需要那么多Warp同时跑。但如果你发现Occupancy很低、访存延迟又高那就说明SM里的“并行度”不足难以用并发掩盖访存延迟。看LLM推理性能时与其盯着GPU-Util这个粗粒度指标不如同时观察Memory Controller Utilization显存控制器的繁忙程度Tensor Core ActiveTensor Core被激活的周期占比OccupancySM上的Warp活跃度三者综合才能判断出你的场景到底卡在哪一环。4. Tensor Core与精度策略从FP32到FP16/INT8/INT4的性能账搞懂了硬件结构回到日常部署中最常做的一个决策——用什么精度跑模型。这个决策直接影响权重体积、KV Cache体积、计算速度和生成质量是LLM推理调优里杠杆最高的一步。4.1 不同精度的吞吐差异Tensor Core对不同精度的计算吞吐是截然不同的。以一张消费级显卡RTX 4090为例FP32约83 TFLOPsFP16 Tensor Core约330 TFLOPsINT8 Tensor Core约660 TFLOPs从FP32换到FP16算力直接翻4倍。因为Tensor Core本身就是为低精度矩阵运算设计的它在FP32模式下甚至不能充分发挥。而INT8在16进制模式下又能再翻一倍。这也解释了为什么所有推理框架默认都跑FP16或BF16——不是因为FP32效果不好而是Tensor Core在FP32下根本跑不了多快。4.2 精度降低带来的连锁收益降低精度不只是提速还连锁改善了一堆问题权重体积减半FP16比FP32少一半显存INT8再少一半KV Cache变小KV Cache也可以以低精度存储比如FP16 KV Cache比FP32省一半带宽压力减小每次Token生成需要搬运的数据变少Memory Bound问题的压力直接下降并发能力提升显存省下来了同一张卡能塞进的并发请求就多了这就是为什么INT8/INT4量化部署在LLM推理领域几乎是必选项。你放弃了一些精度换来的是成倍的吞吐提升。4.3 量化的代价不在精度而在分布量化没有想象中那么简单直接调低精度往往会导致输出质量明显下降。问题不在于精度数值的减小而在于数值分布的不均匀。LLM的权重和激活值通常遵循一种近似高斯分布的形态大部分值集中在零附近少数值非常大。如果均匀量化比如把最大值映射到127其余等比例缩放大部分数值会落在极低的量化分辨率区域精度损失非常大。这也是为什么现在流行混合精度量化和Per-channel量化。Per-channel是指对矩阵的每一行channel单独计算缩放因子而不是整个矩阵共用一个。这样每一行的数值范围都能得到精确映射INT8量化后的损失可以从不可接受降到几乎无感。如果你在部署中遇到“量化后效果崩了”的情况不要急着断言“量化不可用”先检查量化方式是不是均匀量化整个权重矩阵。换成Per-channel或Per-group量化往往能救回来。4.4 FlashAttention注意力计算的算力复辟前面反复强调LLM推理是Memory Bound但也有例外。当序列特别长、batch size特别大时注意力部分的计算量会急剧上升。这时注意力计算本身可能变成新的瓶颈。标准Attention的实现里需要把完整的注意力分数矩阵写入显存再读出来。序列长度是2048时这个矩阵是2048×2048还好序列长度是32768时就是32768×32768也就是10亿个元素。写入再读出两次显存往返数据搬运量极其夸张。FlashAttention的做法是分块计算让注意力分数的计算和Softmax在SRAM片上缓存里完成不经过显存。它减少的不是计算量而是显存读写量。实测中FlashAttention能把长序列下的注意力计算速度提升数倍同时大幅减少显存占用。用一句话说FlashAttention的本质就是意识到“计算一下”比“存取一次”便宜得多从而把访存密集型算子改写成了计算密集型算子。4.5 推理框架怎么选精度实际操作中不同框架对精度的支持有差别。llama.cpp支持从FP16到INT4的全链路量化vLLM对INT8/FP8的支持越来越完善TensorRT-LLM则追求极致性能支持FP8 KV Cache等高级配置。选精度没有银弹我的经验是显存够用权重和KV Cache放得下优先FP16/BF16省心且效果好显存临界上INT8用Per-channel量化损失通常不明显显存实在不够INT4但要充分测试输出质量必要时用有损度更小的量化方案5. 实际部署中的性能台阶从单卡到多卡的调度问题前面聊的都是单卡场景但实际部署里多卡并行非常常见。多卡的关键问题在于你的工作负载适不适合多卡以及怎么分配才最高效。5.1 单卡放不下多卡怎么切当模型权重超过单卡显存时有两种切分思路张量并行和流水线并行。张量并行是把一个矩阵运算拆成多块分别在不同GPU上计算再汇总结果。比如一个4096维的矩阵乘法切到4张卡上每张卡算1024维算完集合通信合并。这种方式通信频繁但显存利用均匀适合卡间高速互联的场景比如NVLink。流水线并行则是按层切分——第1-8层放卡1第9-16层放卡2。数据按顺序流过各卡。这种方式通信次数少但存在“串行气泡”——后面的卡在等前面的卡算完才能接手利用率会有损失。对于推理场景我个人的倾向是能单卡就别多卡能张量并行就别流水线并行。推理的单Token延迟对通信延迟极其敏感张量并行虽然通信多但至少所有卡同时在工作流水线并行在batch size小时几乎必然出现空转。5.2 并发推理与动态BatchingGPU推理服务器比如vLLM提升吞吐的核心手段是动态Batching。思路很简单多个用户的请求到达时间不同但GPU必须攒够了数据才高效。于是服务器把前后脚的请求拼在一起组成一个更大的batch同时送入GPU计算算完再各回各家。如果每个请求单独处理8K上下文、batch size 1的Memory Bound问题会一直卡着不动。动态Batching让多个请求共享权重搬运权重只要读一次可以服务多个请求。这从本质上提高了权重复用率也就是提升了算力利用率。部署层面这个机制对显存提出了额外要求。多个请求的KV Cache会同时驻留显存并发数越高KV Cache总需求越大。所以优化并发吞吐时最常遇到的瓶颈反而不是算力而是KV Cache的显存占用。5.3 显存不够时的终极备选Offload网上热搜词里有个“gpu虚拟内存”其实就是显存不够时把部分数据放在内存甚至硬盘里需要时再搬到显存。这个思路的代价是CPU内存的带宽远低于GPU显存带宽数据搬运速度会慢一个数量级以上。所以Offload只适合“跑起来就行不太在意速度”的场景。像llama.cpp提供的--mlock和offload比例参数就能控制多少层放显存、多少层放内存。如果显存能覆盖绝大部分层只有少数层offload到内存就可以承受这个带宽损失——毕竟内存也要通过PCIe和CPU交互但比把整块模型都放在内存里跑要快得多。5.4 监控与定位瓶颈到底在哪里聊了这么多回到工程实操。当你部署完一个服务发现吞吐低于预期时建议按以下路径排查先看nvidia-smi的显存占用——是不是已经接近卡的上限如果是大概率是显存不足导致的swap或OOM看显存带宽利用率和GPU-Util的对比——如果GPU-Util低、带宽高是Memory Bound调优重点放在降低KV Cache和权重精度上如果GPU-Util高但吞吐上不去看看是不是模型权重精度太高、Tensor Core吃不消或者batch size过小导致并发度不足如果是多卡环境检查NVLink通信占比——通信占比过高的话切割方案可能需要调整最后再考虑batch size、并发度等业务层参数这套排查路径不一定直接指向最优解但一定能把问题圈定在一个可量化的范围内。比盲目换卡、盲目调参要有效得多。6. 选卡逻辑与长期运维视角最后聊一聊选卡这件事。热搜词里“gpu租用”“gpu服务器运维都做哪些工作”“manjaro nvidia gpu 监控”这类问题其实指向同一个需求怎么用成熟可靠的基础设施而不是自己苦哈哈地折腾硬件。6.1 按场景选卡的思路不要先看卡再想干什么先明确你的场景再选卡本地个人跑模型7B-13B规模24GB显存的消费级卡是最佳甜点INT4/INT8下能跑大部分开源模型单卡就能cover企业级推理服务高并发、低延迟优先考虑数据中心卡H20、H100这类关键是看显存带宽和NVLink互联超大模型微调更看重显存容量和卡间通信这时候多卡集群是标配长上下文应用重点看显存容量因为KV Cache对显存的消耗不像权重那样可量化6.2 运维视角的GPU关键指标跑推理服务时日常巡检建议重点盯这几个指标显存温度与功耗长期满负载运行散热和功耗漂移会导致性能下降显存错误率ECC error数据中心卡的ECC内存出现可纠正错误越来越频繁时说明显存寿命到期该换卡了PCIe/NVLink链路稳定性多卡通信链路出问题是性能突降的头号元凶每张GPU都有自己的生命周期显存颗粒的物理老化是实实在在的。与其等卡出故障去排查不如养成周期性记录性能基线的习惯。比如每周跑一次标准的推理benchmark记录P50/P99延迟。哪天发现同样的工具链下P99延迟比基线高了20%以上大概率就是硬件层面出问题了。6.3 一份实用的快速验证清单在正式部署前花十五分钟跑一遍这个清单能省掉后续很多麻烦确认驱动和CUDA版本与框架匹配用nvidia-smi -q检查GPU当前状态、功耗上限、温度用一个小模型先跑一次推理确认精度和数据结果没有异常连续跑10分钟压力测试观察温度曲线是否稳定有没有触发降频检查多卡场景下的通信情况确认NVLink全部up这套清单相当于给你手里的“灶台”做一个全面体检。灶台没问题后面做菜部署调优才谈得上味道。很多新手一开始就盯着模型效果调提示词模型效果调好了又发现推理速度跟不上这时候才回头怀疑硬件有问题。反过来先把硬件底座验明白再往上调模型和框架能少走一半弯路。
)
