先抛个很多人容易绕进去的困惑一台服务器明明插着顶级显卡跑大模型预训练时算力拉满一上生成任务却发现 GPU 利用率忽高忽低速度远不如预期。我见过不少刚开始做 LLM 推理优化的朋友卡在这一步查了半天代码最后发现是自己对“GPU 到底怎么跑 LLM”缺少一个整体框架。今天想把这些年用 GPU 跑大模型推理的经验掰开揉碎讲清楚尤其是那张被很多人误解的“核心框架”图——它不只是一串架构名词而是你判断瓶颈、选卡、调参时真正依赖的坐标系。1. 内容整体设计与思路拆解1.1 为什么聊 LLM 推理必须从 GPU 原理讲起先说一个反直觉的事实LLM 推理的大部分耗时不是花在“计算”上而是花在“搬运数据”上。GPU 之所以适合跑深度学习不是因为它的每个核心比 CPU 快多少而是因为它同时挂着上万个核心能用极高的内存带宽把数据一波一波灌进来并行处理。LLM 推理和传统图像处理、科学计算最大的不同在于它的“计算密度”很低。打个生活化的比方GPU 像一家流水线餐厅CPU 是一个全能大厨。炒一大锅菜图像处理、矩阵乘法流水线优势巨大但如果客人只点一盘菜还得把整个仓库的食材先搬出来看一眼那流水线再快也快不过“把菜从冰箱直接端上桌”。LLM 生成 token 的过程本质上就是“只做一盘菜但每次都把整个冰箱搬出来”。所以理解 GPU 原理不是学术需求是你做推理性能分析的第一性原理。我在实际工作中判断一个推理框架好不好、一台机器够不够用从来不看它宣传的 TFLOPS 有多高而是先算一笔账模型权重有多大、显存带宽有多宽、一个 token 要读几次权重。这笔账算清楚性能大概是什么量级心里就有底了。1.2 揭秘“核心框架”的双层含义标题里的“核心框架”我的理解有两层。第一层是概念框架也就是你用什么样的思维模型去拆解 GPU 推理性能——GPU 的硬件架构如何组织、LLM 推理的不同阶段分别受什么资源限制、哪些指标能真实反映性能。第二层是工程框架也就是当前主流推理引擎如 vLLM、TensorRT-LLM、llama.cpp在 GPU 上究竟做了哪些关键优化它们的底层机制是什么。这两层缺一不可。只懂硬件不懂框架你看着 nvidia-smi 的指标不知道优化点在哪只懂框架不懂硬件别人跟你提“PagedAttention”你只能记住名字遇到显存碎片问题依然不知道怎么排查。下面我会先把第一层概念框架讲透再进入第二层工程框架最后落到实操和排障。2. GPU 硬件架构核心细节解析与实操要点2.1 从 SM 到内存层次GPU 算得快到底快在哪要理解 GPU 为什么“天生适合”LLM需要先认识它的基本组成单元。NVIDIA 的 GPU 由一组流式多处理器组成比如 A100 有 108 个 SMH100 有 132 个左右4090 有 128 个 SM。每一个 SM 内部又包含若干 CUDA 核心、Tensor Core专门做矩阵乘法的单元大模型时代的关键角色、共享内存和寄存器堆。CUDA 推崇的编程模型叫 SIMT单指令多线程即大量线程执行同一条指令但处理不同的数据。这跟 CPU 的多核并行很不一样CPU 是几个强核每个核能独立做复杂分支判断GPU 是大量弱核适合“无脑但量大”的并行任务。矩阵乘法、卷积这类深度学习算子本质上就是一堆相互独立、重复性极高的乘加运算正好命中 SIMT 的优势区。然后是内存层次。GPU 内部有多种存储寄存器最快然后是共享内存/一级缓存再然后是二级缓存最后是显存HBM 或 GDDR。每次要从显存读数据延迟比访问寄存器高出几个数量级。所以 GPU 性能的另一个关键指标是显存带宽GB/s。A100 80GB 的 HBM2e 带宽约 2TB/sH100 的 HBM3 带宽约 3.35TB/s而 4090 的 GDDR6X 带宽约 1TB/s。这个数字直接决定了“搬运权重”的速度上限也是后面所有分析的根基。2.2 Tensor Core 与混合精度为什么 AI 计算能如此高效2017 年前后NVIDIA 在 Volta 架构里引入了 Tensor Core这是 GPU 在 AI 计算上跨越式发展的关键硬件。Tensor Core 本质上是一个专用的矩阵乘累加单元能在单个时钟周期内完成 4×4 或 16×16 等小规模矩阵乘法并且原生支持 FP16、BF16、INT8 等低精度输入、FP32 累加。使用 Tensor Core 的前提是数据布局和精度要符合它的设计。比如 PyTorch 里只要把张量转成 FP16 或 BF16并且保证维度满足要求cuBLAS 就会自动调用 Tensor Core。这也是为什么大模型训练和推理几乎都要走混合精度FP16 不仅让显存占用减半更重要的是计算吞吐几乎翻倍。FP8 精度在 H100 上更进一步吞吐量达到 FP16 的两倍但训练稳定性要求更高目前更多用于推理场景的加速。有一个新手常踩的坑以为只要模型支持 FP16推理速度就会自动翻倍。实际上对于 decode 这样的带宽瓶颈阶段FP16 带来的提升主要来自“权重占用显存减半、读取字节数减半”而不一定来自 Tensor Core 算力变高。理解这一点后你就明白为什么实测某些模型 FP16 到 INT8在生成阶段能接近翻倍因为瓶颈从“算力”转移到了“带宽”。2.3 显存带宽与算力的关系Roof-line 模型速成Roof-line 模型是性能分析里最实用的工具它用一条“屋顶线”代表机器峰值性能算力上限另一条线代表内存带宽上限。一个算子在机器上的实际性能取决于它的算术强度每读取一个字节数据能执行多少次浮点运算如果算术强度低于屋顶转折点性能受带宽限制叫 memory-bound如果高于转折点性能受算力限制叫 compute-boundLLM 推理的两个阶段正好一个在这个区间一个在另一个区间。这也是为什么“GPU 到底如何工作”这个问题必须结合 LLM 的负载特征来回答。3. LLM 推理负载特征解析prefill 与 decode 的“性格差异”3.1 prefill输入解析阶段为什么它是计算密集型当用户输入一段提示词模型需要先把整个 prompt 并行处理一遍生成第一个输出 token。这个阶段叫 prefill或者叫“预填充”特点是对 prompt 里的所有 token 同时做计算本质上是一个很大的矩阵乘法。举个例子输入 2000 个 token权重矩阵是 14GB7B 模型 FP16GPU 只需要从显存读一遍权重然后对 2000 个 token 反复复用这批权重。算术强度约等于输入长度乘以某个系数2000 个 token 时算术强度能到几百远超硬件转折点所以此时 GPU 的 Tensor Core 和大量 SM 都能跑满算力利用率很高。这也是为什么 GPU 在 prefill 阶段通常表现为高利用率、高功耗、发热明显。批量越大、prompt 越长prefill 阶段越“吃算力”。如果你的 GPU 跑长文档总结任务时显存占用忽高忽低多半就是 prefill 阶段在做大量 GEMM。3.2 decode逐 token 生成阶段真正的性能杀手是带宽decode 阶段则是“一个 token 一个 token 地往外蹦”每生成一个 token都要把整份模型权重从显存搬到计算单元做一次矩阵向量乘。此时同一份权重只为一个 token 服务几次算术强度骤降到个位数甚至更低远低于带宽屋顶线的转折点。所以 decode 是典型的 memory-bound 阶段。我们可以直接算一笔账7B 模型 FP16 权重约 14GBA100 的显存带宽约 2TB/s理论上读取一遍权重的下限是 14GB / 2TB/s 7ms也就是单流 decode 极限约 140 token/s。这个数字跟实际 A100 上跑 7B 模型的效果很接近说明瓶颈确实在带宽。4090 带宽只有 1TB/s 左右单流速度就会掉到 70-100 token/s 的量级。理解这一点后很多现象就有了解释为什么 GPU 利用率在 decode 时不高因为大多数 SM 在等显存数据算力闲置但这不是调参能解决的是硬件物理限制为什么并发越高总吞吐越高但单用户延迟变大带宽是共享的大家分着用为什么量化能如此显著地提升解码速度因为权重变小了搬运的字节数变少了3.3 KV Cache那个吃掉显存的无形黑洞除了权重LLM 推理还有一个巨大的显存消费者KV Cache。计算注意力时每个 token 都要生成 Key 和 Value 两组向量并缓存在显存里供后续 token 做注意力计算。随着序列变长KV Cache 不断膨胀。KV Cache 大小的公式是单 token 的 KV Cache 字节数 层数 × KV头数 × 每头维度 × 2K和V× 2字节数以 LLaMA 2 7B 为例32 层8 个 KV 头它使用了 GQA 分组查询注意力每头维度 128FP16 下计算32 × 8 × 128 × 2 × 2 131072 字节 ≈ 128KB / token这意味着生成 8192 个 token 时KV Cache 就占用约 1GB 显存。如果并发 32 路请求每个都走到 8k 长度光 KV Cache 就要吃 32GB。很多 4090 跑大模型“一开长上下文就 OOM”不是模型权重放不下而是 KV Cache 把显存吃干净了。所以我一直建议团队做推理优化时KV Cache 的预算要跟权重预算一样重视。它直接决定了你能开多大 batch、多长上下文也决定了吞吐量的天花板。4. 工程框架的核心优化机制推理引擎在 GPU 上做了什么4.1 连续批处理与动态 batching把 GPU 吃满的关键传统静态批处理的做法是等一批请求凑够了再统一执行但 LLM 解码阶段每个样本长度不一样有的请求很快结束有的还在慢慢生成GPU 会频繁等待产生大量气泡。主流推理引擎vLLM、TensorRT-LLM 等普遍采用连续批处理也叫迭代级调度。它不再等整个 batch 完成而是每一步迭代后立即检查哪些请求完成把新请求插入空位。这样 GPU 在 decode 阶段始终有活干吞吐量提升非常明显这也是 vLLM 比原生 Transformers 快数倍的核心原因之一。4.2 PagedAttention 与显存管理像操作系统一样管理显存vLLM 提出的 PagedAttention 是另一项里程碑式优化。它把 KV Cache 划分成固定大小的块如 16 或 32 个 token 一块存进显存时不需要连续内存而是像操作系统的分页机制一样用索引表管理。它的优势有两个一是消除了传统显存预留导致的碎片化浪费显存利用率大幅提升二是天然支持前缀共享多个请求如果使用相同的前缀比如系统提示词可以共用同一份 KV Cache这在 Agent 场景中特别有用。SGLang 框架做的 RadixAttention 其实是类似思路的进一步延伸通过树状前缀树最大化复用。4.3 量化与推测解码从降低字节数到并行化生成量化是缓解带宽瓶颈最直接的手段。FP16 换成 INT8权重体积减半INT4 则进一步减到四分之一。对 decode 这种带宽瓶颈阶段理论速度提升接近体积缩减比例。但量化不是免费的INT4 精度损失需要靠校准数据集和 GPTQ、AWQ 等算法控制过低的精度还可能导致“崩坏输出”。推测解码是另一条完全不同的路。它的核心是用一个小模型draft model先草拟出 k 个 token再用大模型一次验证这些 token。验证可以并行进行等于把原来“一次验证一个 token”变成了“一次验证一串 token”有效绕开了 decode 的顺序瓶颈。代价是多耗显存放小模型并且草稿接受率直接决定加速比需要结合业务 prompt 分布来调。4.4 主流推理框架对比与选型建议铺开讲一下几个主流框架。我在项目里都实际跑过给出非常主观但基于实操的参考vLLMPagedAttention 连续批处理生态成熟OpenAI 兼容接口适合线上服务。如果新项目没有特殊理由我会默认选它。TensorRT-LLMNVIDIA 全套优化性能天花板最高但工程复杂度大编译时间长适合追求极致性能且团队有能力维护的场景。llama.cpp跨平台、对显存小的环境特别友好支持 CPU 推理和 GPU offload模型量化生态好。适合本地部署、边缘设备、个人学习。SGLangRadixAttention 前缀复用强多轮对话和共享前缀场景优势明显但相对年轻生态不如 vLLM 稳定。Hugging Face Transformers PyTorch实验最方便但生成吞吐低一般不建议直接作为生产方案。选型思路我一般看三点第一是否支持你要的量化格式第二对长上下文和连续批处理的优化是否成熟第三社区活跃度和兼容性。不要因为某个框架在某篇博客里刷了个高分就盲目迁移拿自己的模型和 prompt 分布实测才有说服力。5. 实操过程显存预估、性能评估与问题排查5.1 显存占用预估选卡和配卡前必做的算术题很多人选 GPU 只看“模型多大”实际显存需求由三部分组成权重、KV Cache、中间激活值。加上 CUDA context 和框架自身的开销真实占用会比想象多不少。我在项目里一般这样估算最小显存 ≈ 权重体积 KV Cache 预算 中间激活峰值 1GB 保底以 7B FP16 权重14GB 4K 上下文 32 并发为例KV Cache 就需要约 32 × 4096 × 128KB 16GB总需求轻松超过 30GB。这种情况下 24GB 的 4090 跑不住大并发得考虑 48GB 或 80GB 的卡。配多卡时还要决定并行策略。张量并行TP把单层权重切到多卡显存瓶颈缓解但在 decode 阶段每生成一个 token 都要做多卡通信通信开销可能抵消算力收益需要特别注意互联带宽NVLink 优于 PCIe。流水线并行PP按层切分卡间通信频率低但负载均衡难做。数据并行DP配合连续批处理则是提升吞吐最直接的方式。5.2 nvidia-smi 等监控指标的正确解读方法真实运维时最常被误解的指标就是 nvidia-smi 里的“GPU-Util”。这个数值表示的是 SM 在采样窗口内有任务执行的时间比例并不是算力利用率。decode 阶段 GPU-Util 可能只有 20%-40%但系统已经跑到带宽瓶颈了再优化也没有空间。我更建议同时看这几项Memory Usage显存占用是否接近上限判断 KV Cache 膨胀情况Power Usage功耗墙是否提前触发尤其是多卡机柜散热不足时Temperature温度过高导致降频性能会突然下滑NVLink 或 PCIe 吞吐多卡场景下通信是否是瓶颈另外可以利用 NVIDIA 的nvidia-smi dmon、ncuNsight Compute做更细的 profiling定位具体 kernel 是不是 memory-bound。Nanobench 类的工具也行核心是验证你的理论估算和实测是否吻合。5.3 经典故障排查实录OOM、慢生成、GPU 利用率异常最后分享几个高频问题的排查思路。第一个是CUDA out of memory。先看 termination 日志里是哪个阶段爆的。如果 prefill 阶段爆通常是 batch size、max_seq_len、激活值分配过大如果 decode 中途爆多半是 KV Cache 达到峰值。vLLM 可以通过限制gpu_memory_utilization或max_num_batched_tokens解决但这会牺牲吞吐需要按实际请求长度做压测再调。第二个是生成速度很慢。先看是否单流 decode 场景如果是那就从量化、推测解码、小模型蒸馏上想办法纯调 PyTorch 参数没用。如果是并发场景慢重点检查连续批处理是否生效、队列里是不是有长尾请求霸占了显存和带宽。第三个是GPU 利用率剧烈波动。常见原因有CPU 端数据预处理或 tokenizer 成了瓶颈数据来不及喂给 GPU或者框架里频繁同步导致 kernel 启动开销放大。排查方法是先做一轮纯生成压测排除数据加载干扰再逐步加回真实输入流程通常能很快定位到是哪个环节在“打嗝”。我自己实测过一个典型的坑用 vLLM 跑长上下文时如果max_model_len设得比实际需要的上限大很多KV Cache 预留会吃掉大量显存并发量上不去吞吐反而下降。这类问题不会报错但会让性能差一两倍排查起来最磨人。建议大家做压测时一定带着真实业务的最大长度和并发去测不要用“理想平均数”去配置。结尾写到这里我想起自己第一次用 GPU 跑大模型推理时的状态代码能跑通就觉得自己会了看到 nvidia-smi 数值波就发慌调了一周参数据说“优化”却没有任何理论依据。后来把 GPU 的内存层次、带宽限制、prefill/decode 的负载差异这些东西补上之后发现所有优化动作都有了解释为什么量化最有效、为什么 vLLM 快、为什么 4090 跑 7B 解码就那个速度、为什么加卡不能线性提升。这套框架越用越顺现在每到一个新环境我第一件事就是自己算一遍“权重体积 KV Cache 带宽”半天时间就能判断项目在性能上有没有搞头。如果你刚开始接触 LLM 推理我的建议是别急着上最复杂的部署方案。先在一张消费级显卡上用 llama.cpp 或 vLLM 把一个 7B 模型跑起来记录不同并发、不同上下文长度下的 token/s 和显存占用对照今天这篇的估算方法亲手算一遍。等你能大概预测出一个数字再去看真实数据GPU 在你眼里就不再是个“神秘黑盒”了。最后再分享一个小技巧所有推理性能问题先用“重量级命中的数据路径”去看——模型权重多大、要读几遍、带宽多宽、能不能复用——80% 的瓶颈都能在这几步里看出来。剩下的 20%才轮到框架参数和硬件细节去抠。