1. 从一张显卡说起LLM部署里GPU到底在忙什么很多人第一次把大模型跑起来注意力全在“模型能不能出字”上等真正要上线服务才发现瓶颈根本不在模型本身而在GPU这块卡上。我做LLM应用开发这几年踩过最多的坑几乎都和GPU有关显存不够、算力利用率上不去、推理延迟忽高忽低、多卡并行效率打折。这一篇接着上一部分继续聊模型适配优化里的GPU话题重点放在显存管理、算力调度、推理引擎选型、多卡与量化适配这几个实际落地时绕不开的环节。先把结论摆前面LLM推理场景下GPU不是“越大越好”而是“匹配得越准越好”。一张24GB显存的消费级卡配好量化策略和推理引擎跑7B到14B级别的模型完全够用反过来一张80GB的专业卡如果batch调度和KV Cache管理没做好照样会出现显存碎片、吞吐上不去的情况。所以这一部分的核心是搞清楚GPU在推理任务里到底承担了哪些工作以及每一块工作对应的优化手段。这篇文章适合已经能把模型跑起来、但想进一步压延迟、提吞吐、降成本的开发者也适合正在做模型部署选型、纠结买什么卡或租什么卡的技术负责人。下面我会从整体设计思路讲到具体参数计算再到实操配置和问题排查尽量把每一步的“为什么”讲透。2. GPU在LLM推理中的角色拆解与整体优化思路2.1 推理任务里GPU的三块核心负载要优化先得知道GPU在忙什么。LLM推理过程中GPU主要承担三类负载理解这三类负载的比例关系是后续所有优化决策的基础。第一块是矩阵乘法也就是模型权重和输入激活值之间的计算。这是Transformer结构里绝对的计算大头占整个前向传播FLOPs的绝大部分。这部分负载的特点是高度并行、对算力敏感属于典型的“喂饱SM流多处理器就能快”的类型。第二块是注意力计算尤其是KV Cache的读写。这部分负载的特点是访存密集随着上下文长度增长KV Cache的显存占用和带宽压力会急剧上升。很多场景下延迟上不去不是算力不够而是显存带宽被KV Cache吃满了。第三块是显存管理本身包括权重加载、激活值缓存、KV Cache分配、临时缓冲区。这部分不直接产生计算但决定了你能跑多大的模型、能开多大的batch。显存管理没做好前面两块再快也白搭。提示判断瓶颈在哪最简单的办法是看GPU利用率和显存带宽利用率。算力利用率高但吞吐上不去多半是访存瓶颈算力利用率低多半是调度或batch问题。2.2 优化思路的优先级排序很多人一上来就想着换卡、上多卡其实性价比最低。我个人的优化优先级是这样的量化把FP16降到INT8或INT4显存直接砍半甚至砍到四分之一这是投入产出比最高的一步。推理引擎选型vLLM、TensorRT-LLM、llama.cpp这类引擎自带PagedAttention、连续批处理等优化比手写推理循环强太多。KV Cache管理控制上下文长度、开启分页、合理设置block大小。批处理策略连续批处理continuous batching比静态批处理吞吐高得多。多卡并行前面都榨干了还不够再考虑张量并行或流水线并行。这个顺序的逻辑是先降低单次计算和存储的需求再提升单位时间内的处理效率最后才考虑横向扩展。跳过前面几步直接上多卡往往是把钱花在了不该花的地方。2.3 不同规模模型的GPU匹配逻辑模型规模和GPU的匹配不能只看参数量还要看精度、上下文长度、并发量。我整理了一个粗略的对照关系供选型时参考模型规模精度权重显存建议显存含KV Cache和激活典型卡型7BFP16约14GB20GB以上24GB消费卡7BINT4约4GB8GB以上12GB消费卡13BFP16约26GB32GB以上40GB专业卡13BINT4约7GB12GB以上16GB消费卡70BINT4约35GB48GB以上80GB专业卡或多卡70BFP16约140GB160GB以上多卡并行这张表里的“建议显存”是经验值实际还要看上下文长度和并发数。上下文从2K拉到32KKV Cache可能翻十几倍这一点后面会详细算。3. 显存管理LLM推理最容易被忽视的战场3.1 显存到底被谁吃掉了跑一个模型显存占用可以拆成四部分模型权重、KV Cache、激活值、临时缓冲区。很多人只算了权重结果一跑就OOM就是因为忽略了后面三块。模型权重是固定的FP16下每参数2字节INT8下1字节INT4下0.5字节。这部分好算。KV Cache是变量公式是2 × 层数 × 注意力头数 × 头维度 × 序列长度 × batch_size × 精度字节数。注意前面的2是因为Key和Value各一份。以7B模型为例32层、32头、头维度128序列长度4096batch为1FP16精度算下来大约是2 × 32 × 32 × 128 × 4096 × 1 × 2字节约2GB。如果batch开到16就是32GB直接爆掉。激活值是前向传播过程中的中间结果和batch、序列长度正相关通常比KV Cache小但在长序列下也不可忽视。临时缓冲区是推理引擎和CUDA运行时自己占的一般留1到2GB余量比较稳妥。3.2 PagedAttention为什么能省显存传统KV Cache是连续分配的每个序列预分配最大长度的空间实际用多少不确定造成大量浪费和碎片。vLLM提出的PagedAttention借鉴了操作系统虚拟内存分页的思路把KV Cache切成固定大小的block按需分配不连续也没关系。这个机制带来的好处很直接显存浪费从原来的60%到80%降到4%以下同样的卡能塞下更多并发请求。我实测过一个场景同样一张24GB卡传统方式只能跑batch为4的7B模型换成vLLM的PagedAttention后能跑到batch为12吞吐提升接近三倍。注意PagedAttention的block大小是个需要调的参数。block太小管理开销大block太大内部碎片多。默认16通常是个不错的起点长序列场景可以试32。3.3 量化对显存的真实影响量化不是简单地“除以2”或“除以4”。以INT4为例权重确实降到0.5字节每参数但推理时通常要反量化回FP16参与计算中间会有额外的临时显存开销。而且KV Cache是否量化对显存影响很大。我做过一组对比测试7B模型序列长度2048batch为8配置权重显存KV Cache显存总显存吞吐tokens/sFP1614GB16GB32GB基准INT8权重7GB16GB25GB约1.6倍INT4权重4GB16GB22GB约2.1倍INT4权重INT8 KV4GB8GB14GB约2.3倍可以看到权重量化省的是固定开销KV Cache量化省的是随并发增长的开销。两者结合才能把显存压到最低。但KV Cache量化对精度的影响比权重量化更敏感需要根据任务类型权衡。3.4 显存碎片与OOM的排查思路OOM不一定是显存真的不够很多时候是碎片导致的。表现是明明nvidia-smi显示还有几GB空闲但一申请就失败。排查步骤我一般是这样的先看是不是权重加载阶段就OOM如果是说明模型本身超了得量化或换卡。如果是运行一段时间后OOM多半是KV Cache增长或碎片问题可以尝试开启PagedAttention、限制最大序列长度、降低batch。如果是多请求并发时OOM检查是否有请求没被正确释放或者调度器没有做显存感知的准入控制。一个实用技巧是设置gpu_memory_utilization参数vLLM里叫这个留出10%到20%的余量给临时缓冲不要顶满。顶满的结果往往是跑着跑着就崩。4. 推理引擎选型不同场景该用哪把刀4.1 主流推理引擎的能力对比推理引擎选型是GPU优化的第二个关键决策。不同引擎的设计目标不同适用的场景也不同。我把几个主流选项拉出来对比引擎核心优势适用场景量化支持多卡支持vLLMPagedAttention、连续批处理、吞吐高在线服务、高并发GPTQ、AWQ、FP8张量并行TensorRT-LLM极致延迟、算子融合深低延迟生产环境INT4/INT8/FP8张量流水线并行llama.cpp轻量、CPU/GPU混合、GGUF格式本地部署、边缘设备GGUF全系列有限ONNX Runtime跨平台、生态广多硬件适配INT8动态量化有限MLX苹果芯片优化Mac本地推理4-bit等统一内存架构选型的核心问题是你要的是吞吐还是延迟是在线服务还是本地运行是单卡还是多卡。这三个问题回答清楚引擎基本就定了。4.2 vLLM的适用边界与调参要点vLLM是我在在线服务场景下用得最多的。它的连续批处理机制能让不同请求在同一批次里动态进出GPU利用率能稳定在较高水平。但它也不是万能的。vLLM对超长序列的支持相对吃显存因为PagedAttention虽然省但长序列的KV Cache总量还是大。另外vLLM的启动和首次推理有预热开销短请求场景下这部分开销占比会偏高。调参上我关注这几个max_model_len控制最大序列长度直接影响KV Cache上限gpu_memory_utilization控制显存占用比例max_num_seqs控制最大并发序列数block_size控制分页大小。这几个参数互相制约需要根据实际负载调。4.3 TensorRT-LLM的编译流程与代价TensorRT-LLM的延迟表现确实好但代价是编译流程复杂。它需要先把模型转成TensorRT引擎这个过程要做算子融合、精度校准、kernel自动调优耗时可能几十分钟到几小时。编译出来的引擎是和GPU型号、精度、batch配置绑定的换一张卡或改一个参数就得重新编译。所以它适合模型固定、硬件固定、追求极致延迟的生产环境不适合快速迭代的实验阶段。我一般建议实验和快速验证用vLLM确定要上生产且延迟敏感时再考虑TensorRT-LLM。4.4 llama.cpp与GGUF的本地部署价值本地部署场景尤其是消费级硬件或边缘设备llama.cpp配合GGUF格式是首选。GGUF把模型权重和元数据打包在一起支持多种量化级别从Q2到Q8都有可以根据显存灵活选。llama.cpp支持CPU和GPU混合推理部分层放GPU部分放CPU这让显存不足时也能跑起来代价是速度下降。对于树莓派这类设备或者显存只有8GB的笔记本这个特性很实用。提示GGUF的量化级别不是越高越好。Q4_K_M通常是质量和体积的平衡点Q5_K_M质量更好但体积大Q8几乎无损但体积接近FP16。选哪个看你的显存余量。5. 实操从零配置一个GPU推理服务5.1 环境准备与依赖安装假设我们在一台Ubuntu服务器上有一张24GB显存的卡要部署一个7B模型的推理服务。第一步是环境准备。CUDA版本要和显卡驱动、推理引擎匹配。我一般先确认驱动版本再选CUDA。用nvidia-smi看驱动支持的CUDA上限然后装对应版本的CUDA Toolkit。PyTorch要装CUDA版本不要装成CPU版这个坑新手经常踩。# 确认驱动和CUDA版本 nvidia-smi # 创建虚拟环境 python -m venv llm_env source llm_env/bin/activate # 安装PyTorch以CUDA 12.1为例 pip install torch --index-url https://download.pytorch.org/whl/cu121 # 安装vLLM pip install vllm安装完先验证一下GPU是否可用import torch print(torch.cuda.is_available()) print(torch.cuda.get_device_name(0)) print(torch.cuda.get_device_properties(0).total_memory / 1024**3, GB)这三行能确认GPU被正确识别、显存大小符合预期。如果is_available()返回False多半是PyTorch版本和CUDA不匹配。5.2 模型加载与显存参数计算加载模型前先算一下显存够不够。以7B模型、FP16、序列长度4096、batch为8为例权重7B × 2字节 14GB。KV Cache按前面公式单序列约2GBbatch为8就是16GB。加起来30GB超过24GB了。所以要么量化要么降batch要么降序列长度。如果换成INT4权重权重降到约4GBKV Cache还是16GB总共20GB加上临时缓冲约2GB22GB勉强能跑。如果再把KV Cache量化到INT8KV Cache降到8GB总共14GB就很宽裕了。启动vLLM服务python -m vllm.entrypoints.openai.api_server \ --model /path/to/model \ --quantization awq \ --max-model-len 4096 \ --gpu-memory-utilization 0.9 \ --max-num-seqs 8 \ --block-size 16这里--gpu-memory-utilization 0.9表示用90%的显存留10%给系统。--max-num-seqs 8限制并发防止KV Cache无限增长。5.3 压测与吞吐延迟观测服务起来后别急着上线先压测。我用的是自己写的一个简单脚本模拟不同并发下的请求记录吞吐和延迟。import time import requests from concurrent.futures import ThreadPoolExecutor def send_request(prompt): start time.time() resp requests.post(http://localhost:8000/v1/completions, json{ model: /path/to/model, prompt: prompt, max_tokens: 128 }) return time.time() - start prompts [解释一下什么是注意力机制] * 32 with ThreadPoolExecutor(max_workers8) as executor: latencies list(executor.map(send_request, prompts)) print(平均延迟:, sum(latencies) / len(latencies)) print(P99延迟:, sorted(latencies)[int(len(latencies) * 0.99)])压测时同时用nvidia-smi -l 1观察GPU利用率和显存变化。理想状态下GPU利用率应该稳定在70%以上显存占用平稳不持续增长。如果显存持续增长说明有请求没被释放检查调度器配置。5.4 多卡并行的配置与注意事项单卡不够时上多卡。vLLM支持张量并行用--tensor-parallel-size指定卡数。比如两张卡python -m vllm.entrypoints.openai.api_server \ --model /path/to/model \ --tensor-parallel-size 2 \ --gpu-memory-utilization 0.9张量并行会把每一层的权重切分到多张卡上卡间通信量很大所以对卡间带宽要求高。NVLink连接的卡效果最好PCIe连接的卡会有明显通信开销。如果卡间只有PCIe张量并行的加速比可能只有1.5倍而不是2倍。注意多卡并行时显存是分摊的但KV Cache也是分摊的。如果卡间显存不均衡可能出现一张卡先OOM的情况。建议用同型号同显存的卡。6. 常见问题与排查技巧实录6.1 显存相关问题的速查表现象可能原因排查方法解决方向启动即OOM权重超显存算权重显存量化或换卡运行中OOMKV Cache增长看序列长度和并发限长、限并发、量化KV显存有空但申请失败碎片看显存分配日志开PagedAttention多卡不均衡切分不均看各卡显存调并行策略显存缓慢增长请求未释放看请求生命周期检查调度器6.2 算力利用率上不去的排查GPU利用率低通常不是GPU的问题而是数据供给或调度的问题。常见原因有几个batch太小GPU没吃饱请求间隔太长GPU空转CPU预处理成瓶颈GPU等数据推理引擎的调度策略不适合当前负载。排查顺序先看batch大小再看请求到达模式再看CPU占用。如果CPU某个核跑满多半是预处理瓶颈可以考虑把tokenize放到GPU上或做异步预处理。6.3 精度与速度的权衡经验量化能提速但会掉精度。掉多少取决于任务。分类、抽取这类任务对精度不敏感INT4通常没问题。生成、推理这类任务对精度敏感INT4可能出问题建议INT8起步。我的一般做法是先用INT4跑一遍看输出质量能不能接受不能接受就升到INT8还不行就FP16。同时准备一套评测集量化前后各跑一遍用数据说话不要凭感觉。6.4 几个我踩过的坑第一个坑是盲目追求大batch。batch开大确实吞吐高但延迟也会涨而且显存压力大。在线服务场景下延迟和吞吐要平衡不是batch越大越好。第二个坑是忽略预热。推理引擎首次推理有编译和缓存开销延迟可能是稳定后的几倍。上线前一定要预热或者配置健康检查时给足预热时间。第三个坑是量化格式不匹配。不同引擎支持的量化格式不同GPTQ、AWQ、GGUF互不通用。选引擎前先确认模型有没有对应格式的量化版本没有的话要自己转转换过程也可能掉精度。第四个坑是多卡通信瓶颈。以为加卡就能线性提速结果卡间通信成了瓶颈。上多卡前先确认卡间带宽PCIe 4.0 x16的带宽和NVLink差一个数量级。7. 写在最后的一点个人体会GPU优化这件事说到底是个系统工程没有一招鲜。我见过太多人把希望寄托在换一张更贵的卡上结果换了卡问题依旧因为瓶颈根本不在算力。也见过有人用一张普通的消费卡通过量化、引擎选型、参数调优把服务跑得又稳又省。我的经验是先把显存账算清楚再把引擎选对最后才是调参和压测。每一步都要有数据支撑不要凭感觉。压测的时候多观察GPU利用率和显存曲线这两个指标能告诉你大部分问题在哪。还有一点优化是个迭代过程。今天调好的参数换了模型或换了负载可能就不适用了。所以建立一套可复现的压测流程比记住某组具体参数更重要。这套流程能让你在每次变更后快速验证而不是靠猜。