最近在给一个 LLM 推理服务做性能压测时我遇到一个很有意思的现象同样的模型换了 GPU 型号后预期中的“算力翻倍”并没有带来 decode 速度的翻倍反而被显存带宽卡得死死。后来我意识到如果一开始就用第一性原理把 LLM 性能的上下界算清楚很多调优工作其实在动手前就能预判结果。这篇文章我会从最基础的物理和数学约束出发完整拆解 LLM 推理性能建模的方法。文章会覆盖Prefill 与 Decode 两个阶段的本质差异、算力与内存带宽如何决定推理上限、KV Cache 显存估算、FP16/BF16/INT8 等精度对性能的影响以及一个可以直接复制运行的性能估算 Python 脚本。无论你是做大模型应用开发、推理引擎选型还是只想弄清楚“为什么我的模型跑不快”这篇文章都值得收藏细读。1. 先理解为什么要给 LLM 性能建模1.1 只靠实测调优效率太低很多开发者优化 LLM 性能的方式是“先部署再压测哪慢调哪”。这种做法不能说错但效率很低原因在于LLM 推理的性能瓶颈不是单一的可能是算力、显存带宽、显存容量、通信开销、调度策略中的任何一个。盲目调参缺少理论指导比如把 batch size 调大发现显存爆了把并发调高发现延迟反而恶化了。每一轮压测都需要重新部署、加载模型、跑数据周期长、成本高。性能建模能帮你在写代码之前用纸笔和简单的公式估算出当前硬件条件下的性能上界。如果实测远低于上界说明系统有优化空间如果实测接近上界说明瓶颈在硬件本身继续调软件收益有限。1.2 第一性原理的思维所谓“第一性原理”是从最基础的事实出发推演而不是依赖经验类比。对 LLM 推理来说最基础的事实是模型推理必须做矩阵乘法计算量由参数量和 token 数量决定。模型的权重必须存在显存里每次生成一个 token 都要把全部权重读一遍。显存容量是有限的KV Cache 会随序列长度和并发数增长。GPU 的工作方式决定了它要么被计算打满要么被数据搬运打满。基于这几个事实我们能推导出 LLM 推理的两类核心瓶颈计算瓶颈Compute-boundGPU 算力成为限制因素。内存瓶颈Memory-bound显存带宽或显存容量成为限制因素。理解这两个概念是读懂后面所有性能公式的基础。1.3 LLM 推理的两个阶段在深入公式之前你还需要清楚 LLM 推理服务的完整流程。它分为两个阶段阶段英文名称作用特点预填充阶段Prefill并行处理用户输入的 Prompt生成 KV Cache计算密集需要高算力解码阶段Decode逐个生成输出 Token每次只生成一个访存密集受显存带宽限制Pre fill 和 Decode 的性能瓶颈完全不同。如果你用“每秒生成多少 token”这一个指标去衡量整个服务很容易掩盖 Prefill 阶段的长尾延迟问题。后面第 4 章的代码会分别计算这两个阶段的理论性能。2. 核心概念算力、带宽与模型大小2.1 算力FLOPs算力指的是 GPU 每秒能执行的浮点运算次数单位是 TFLOPS每秒万亿次浮点运算。对 LLM 来说一次前向推理的计算量约等于[ \text{计算量} \approx 2 \times N \times T ]其中(N) 是模型参数量。整个模型有几个参数例如 7B 就是 70 亿个参数。(T) 是处理的 token 数量。系数 2 表示每个参数大约需要 2 次浮点运算一次乘法和一次加法。举例7B 模型处理 1 个 token 的计算量约为[ 2 \times 7 \times 10^9 1.4 \times 10^{10} \text{ FLOPs} ]如果 GPU 的 FP16 算力是 312 TFLOPS那理论上每秒最多能处理约 22000 个 token。2.2 内存带宽Memory Bandwidth内存带宽指的是 GPU 每秒能从显存中读取或写入的数据量单位是 GB/s。Decode 阶段的关键公式[ \text{最大输出速度token/s} \frac{\text{内存带宽GB/s}}{\text{模型权重大小GB}} ]为什么 decode 阶段受带宽限制因为自回归生成的特点就是生成第 (t1) 个 token 时必须读取全部模型权重参与计算。NN虽然单个 token 的计算量不多但权重必须被搬运一次。GPU 的算力再高如果数据来不及从显存搬到计算单元性能天花板就是带宽决定的。以 7B 模型为例FP16 精度下权重占用约 (7 \times 10^9 \times 2 14 \text{ GB})。A100 的 HBM2e 带宽约 2 TB/s。理论最大 decode 速度约为 (2000 / 14 \approx 142 \text{ token/s})。这个数字是不是和你在实际部署中看到的差不多7B 模型在 A100 上大概就是 100~150 token/s 的水平。这就是第一性原理建模的价值。2.3 显存容量显存容量约束了“这个模型能不能跑起来”以及“最多支持多长的上下文”。权重显存这部分很好算。但 LLM 推理还有一个大头是 KV Cache它随序列长度和并发数线性增长热词里提到的“KV Cache 显存增长快”是长上下文场景下最常见的坑。KV Cache 显存计算公式[ \text{KV Cache 大小} 2 \times L \times H_{kv} \times D_{head} \times S \times B \times P ]其中(L)Transformer 层数。(H_{kv})KV 头的数量。如果是 GQA/MQA 架构这个值会远小于注意力头总数这也是为什么新模型都用 GQA。(D_{head})每个头的维度。(S)序列长度。(B)batch size即并发请求数。(P)每个元素占用的字节数。FP16 是 2 字节FP8 是 1 字节。系数 2 是因为要同时缓存 K 和 V。后面我会用代码实际算一个 7B 模型在不同上下文长度下的 KV Cache 占用你会直观感受到长上下文对显存的巨大压力。3. 精度选择FP16、BF16、INT8 与 INT4 的影响3.1 不同精度占用字节数大模型训练和推理中常见的精度有 FP32、FP16、BF16、INT8、INT4。它们的主要区别在于数值范围、精度、占用字节数以及对硬件算力的利用率。精度占用字节说明FP324 字节训练默认精度显存占用大推理很少直接用FP162 字节推理常用精度适合数值范围稳定的情况BF162 字节与 FP32 相同的指数位更适合大模型训练INT81 字节量化推理常用精度损失较小INT40.5 字节显存占用最低精度损失相对明显3.2 精度如何影响性能建模精度对性能的影响主要通过两个路径路径一影响权重大小进而影响 decode 速度。7B 模型权重大小FP1614 GB。INT87 GB。INT43.5 GB。不考虑量化带来的计算开销单看带宽瓶颈decode 速度理论上可以翻倍甚至翻四倍。路径二影响 GPU 算力利用率。GPU 对低精度的计算通常有更高的算力。比如 H100 的 FP16 算力约 990 TFLOPSFP8 算力翻倍到约 1980 TFLOPS。但要注意INT4 等低比特量化并不总是带来线性加速因为反量化dequantization操作本身会消耗算力。3.3 关于 BF16 和 FP16 的选择建议热词中提到的“LLM大模型之精度问题(fp16,fp32,bf16)详解与实践”是很多 LLM 开发者都会遇到的问题。这里给出一个务实的建议如果你的模型权重数值分布比较集中、没有极端大值FP16 没问题。如果你训练过程中发现 loss 不收敛或梯度爆炸优先检查是否数值溢出可以换成 BF16。推理服务如果追求显存节省和速度INT8 是性价比不错的选择。追求极致低显存可以使用 INT4但要注意精度回退评估。一句话总结精度选择是性能建模中最重要的输入参数之一。在开始调优之前先固定精度再谈后续。4. 完整实战用 Python 脚本建模 LLM 推理性能4.1 环境准备与版本说明本文示例代码基于 Python 3.9不需要安装任何第三方库使用标准库的 dataclass 和 typing 即可直接运行。操作系统不限Windows、macOS、Linux 都可以运行。如果你是在云服务器或本地开发机上使用直接新建一个performance_model.py文件即可。版本需要根据你的项目实际情况调整本文示例以常见环境为例重点演示配置思路。4.2 代码结构设计我们先定义几个数据结构HardwareSpec硬件规格包括算力、带宽、显存容量。ModelSpec模型规格包括参数量、层数、KV 头数、头维度。InferenceConfig推理配置包括精度、batch size、序列长度。然后写三个核心函数calc_weight_memory计算权重显存。calc_kv_cache_memory计算 KV Cache 显存。estimate_decode_speed估算 decode 阶段最大速度。estimate_prefill_time估算 prefill 阶段的耗时。最后用表格输出对比结果。4.3 编写核心代码# 文件路径performance_model.py LLM 推理性能建模脚本 基于第一性原理估算 Prefill / Decode 阶段的性能上界 from dataclasses import dataclass # 精度与字节数对应关系 PRECISION_BYTES { fp32: 4, fp16: 2, bf16: 2, int8: 1, int4: 0.5, } dataclass class HardwareSpec: 硬件规格 name: str fp16_tflops: float # FP16 算力单位 TFLOPS memory_bandwidth_gbps: float # 显存带宽单位 GB/s memory_capacity_gb: float # 显存容量单位 GB dataclass class ModelSpec: 模型规格 name: str params_billion: float # 参数量单位 B10 亿 num_layers: int # Transformer 层数 num_kv_heads: int # KV 头数GQA/MQA 架构下的数量 head_dim: int # 每个头的维度 dataclass class InferenceConfig: 推理配置 precision: str # 精度fp16/bf16/int8/int4 batch_size: int # 并发请求数 seq_len: int # 序列长度 prefill_tokens: int # 输入 token 数用于估算 prefill 耗时 def calc_weight_memory(model: ModelSpec, precision: str) - float: 计算模型权重显存占用 参数 model: 模型规格 precision: 精度 返回 float: 权重显存大小单位 GB bytes_per_param PRECISION_BYTES[precision] params model.params_billion * 1e9 memory_bytes params * bytes_per_param return memory_bytes / 1e9 def calc_kv_cache_memory(model: ModelSpec, cfg: InferenceConfig) - float: 计算 KV Cache 显存占用 KV Cache 大小 2 * L * num_kv_heads * head_dim * seq_len * batch_size * bytes bytes_per_element PRECISION_BYTES[cfg.precision] kv_cache_bytes ( 2 * model.num_layers * model.num_kv_heads * model.head_dim * cfg.seq_len * cfg.batch_size * bytes_per_element ) return kv_cache_bytes / 1e9 def estimate_decode_speed(hardware: HardwareSpec, model: ModelSpec, cfg: InferenceConfig) - float: 估算 Decode 阶段的最大速度 Decode 阶段主要受内存带宽限制 speed memory_bandwidth / model_weight_size weight_memory_gb calc_weight_memory(model, cfg.precision) # 考虑 KV Cache 的读写开销实际可用带宽只有一部分用于权重读取 # 这里我们先按纯权重计算后面用实际效率系数修正 speed hardware.memory_bandwidth_gbps / weight_memory_gb return speed def estimate_prefill_time(hardware: HardwareSpec, model: ModelSpec, cfg: InferenceConfig) - float: 估算 Prefill 阶段耗时 Prefill 阶段主要受算力限制 计算量 2 * N * input_tokens 耗时 计算量 / 算力 params model.params_billion * 1e9 total_flops 2 * params * cfg.prefill_tokens flops_per_second hardware.fp16_tflops * 1e12 time_seconds total_flops / flops_per_second return time_seconds def print_report(hardware: HardwareSpec, model: ModelSpec, cfg: InferenceConfig): 打印性能估算报告 weight_gb calc_weight_memory(model, cfg.precision) kv_cache_gb calc_kv_cache_memory(model, cfg) decode_speed estimate_decode_speed(hardware, model, cfg) prefill_time_s estimate_prefill_time(hardware, model, cfg) print( * 60) print(f硬件{hardware.name}) print(f模型{model.name}) print(f精度{cfg.precision}并发数{cfg.batch_size}序列长度{cfg.seq_len}) print(- * 60) print(f权重显存占用{weight_gb:.2f} GB) print(fKV Cache 显存占用{kv_cache_gb:.2f} GB) print(f总显存占用不含激活值{weight_gb kv_cache_gb:.2f} GB) print(f显存容量{hardware.memory_capacity_gb:.0f} GB) if weight_gb kv_cache_gb hardware.memory_capacity_gb: print([警告] 预估显存超过硬件容量请降低并发数或序列长度) print(fDecode 理论最大速度{decode_speed:.1f} token/s) print(fDecode 实际参考速度60% 效率{decode_speed * 0.6:.1f} token/s) print(fPrefill 理论耗时输入 {cfg.prefill_tokens} token{prefill_time_s * 1000:.1f} ms) print(fPrefill 实际参考耗时60% 效率{prefill_time_s * 1000 / 0.6:.1f} ms) print( * 60) if __name__ __main__: # 示例硬件A100 80GB a100 HardwareSpec( nameNVIDIA A100 80G, fp16_tflops312, memory_bandwidth_gbps2039, memory_capacity_gb80, ) # 示例模型7B 规模采用 GQA 架构 model_7b ModelSpec( name7B Model, params_billion7, num_layers32, num_kv_heads8, head_dim128, ) # 推理配置 config InferenceConfig( precisionfp16, batch_size1, seq_len4096, prefill_tokens1024, ) print_report(a100, model_7b, config)4.4 运行与验证在命令行中运行python performance_model.py预期输出数值会因浮点精度略有差异 硬件NVIDIA A100 80G 模型7B Model 精度fp16并发数1序列长度4096 ------------------------------------------------------------ 权重显存占用14.00 GB KV Cache 显存占用5.37 GB 总显存占用不含激活值19.37 GB 显存容量80 GB Decode 理论最大速度145.6 token/s Decode 实际参考速度60% 效率87.4 token/s Prefill 理论耗时输入 1024 token46.0 ms Prefill 实际参考耗时60% 效率76.6 ms 4.5 结果说明这个脚本的输出包含三层信息显存够不够权重 KV Cache 是否超出显存容量。如果超出要么降并发要么降序列长度要么换量化精度。Decode 快不快理论最大速度是硬件的上限。实际部署中算子实现、框架调度、内存搬运开销都会造成效率损失通常达不到理论值。60% 的效率是一个经验参考值你可以根据实际 profiling 结果替换。Prefill 快不快Prefill 是计算密集型理论耗时与输入 token 数成正比。如果你做 RAG 应用输入很长这个数字特别关键。注意这里的数值是“理想上界”不包含激活值显存、CUDA context、框架缓冲等额外开销。实际部署时显存占用通常会比模型估算高出 10% 到 30%。5. 扩展不同配置下的对比结果5.1 调整精度把精度改成int8观察变化config InferenceConfig( precisionint8, batch_size1, seq_len4096, prefill_tokens1024, )预期结果权重显存7.00 GB降低一半。KV Cache2.68 GB。Decode 速度理论约 291 token/s。这个对比很好地说明了一个现象为什么很多推理服务优先选择量化。在带宽受限的 decode 阶段权重瘦身是提升速度最直接的手段。5.2 调整 KV Cache 相关参数把序列长度从 4096 调整到 32768KV Cache 显存42.95 GB 总显存56.95 GBA100 80G 还能扛住如果再叠加 batch size 4KV Cache 显存171.79 GB 总显存185.79 GB直接爆显存这就是为什么大模型服务普遍用 GQA分组查询注意力来缩减 KV 头数。如果模型是 MHA 架构比如 num_kv_heads 32KV Cache 会再大 4 倍长上下文下根本无法落地。5.3 对比不同模型规模如果你把模型换成 70B 参数规模FP16 精度下权重就是 140 GB单张 A100 80G 根本放不下。这时候你就会理解为什么 70B 级别的模型必须走多卡张量并行或量化路线。这个脚本最大的价值不是给出精确的性能数字而是帮你快速回答三个问题当前硬件能不能塞下这个模型性能瓶颈在算力还是带宽优化方向应该是选量化、改架构、加并发还是加卡6. 常见问题与排查思路建模只是第一步实际部署中你会遇到各种和理论值对不上的情况。下面整理一份排查表。问题现象常见原因解决思路Decode 速度远低于理论值算子实现效率低或显存带宽没有打满使用ncu、nsys等工具 profiling查看内核的 memory throughput尝试升级推理框架或使用 TensorRT-LLM、vLLMPrefill 阶段耗时过长输入 token 数大且没有用并行计算优化拆分成多个短请求限制单请求的最大输入长度使用 chunked prefill显存比估算多出很多忽略了激活值、CUDA context、框架缓冲在实际部署时预留 20% 到 30% 的显存余量开启框架的显存复用功能长上下文后显存暴涨KV Cache 线性增长启用 KV Cache 量化改用 GQA 架构的模型限制最大上下文长度使用远程 KV Cache 卸载多并发时延迟明显恶化batch size 增大后 KV Cache 增大同时调度开销增加使用连续批处理Continuous Batching提升 GPU 利用率限制最大并发数对超长请求单独走一条通道INT4 量化后速度反而变慢反量化操作消耗额外算力优先用 INT8如果必须用 INT4选择支持权重复用的推理后端用 profiling 确认是否计算瓶颈模型可以加载但生成效果变差量化精度损失导致对比量化前后的困惑度或下游任务指标对敏感场景使用混合精度7. 最佳实践与工程建议7.1 先建模再实验每次性能调优开始前先用本文的脚本或类似方法算一次理论值。如果实测离理论值很远说明框架或内核有优化空间如果实测接近理论值说明你的瓶颈在硬件增加预算买卡比调参数更有效。7.2 根据瓶颈选择优化方向判断方法很简单Prefill 阶段慢优先看 GPU 算力是否打满。Decode 阶段慢优先看显存带宽是否打满。显存不够优先看是权重占大头还是 KV Cache 占大头。如果是权重占大头走量化。如果是 KV Cache 占大头走 GQA 架构、KV 量化、长上下文裁剪、或调低并发。7.3 精度选择要结合业务量化不是越低位越好。INT8 对绝大多数业务场景来说是无损或近似无损的。INT4 需要你在推理前做完整的评测集验证不要拿一两条测试数据判断效果。如果模型涉及数学推理、代码生成等对数值敏感的任务量化后要格外谨慎尽量保留 FP16 或者用 INT8。7.4 监控指标要分层不要只用“平均生成速度”一个指标。建议至少监控TTFTTime To First Token首 token 延迟反映 prefill 速度和系统调度效率。TPOTTime Per Output Token单个输出 token 的平均耗时反映 decode 速度。端到端延迟用户从发请求到收到完整回复的总时间。GPU 利用率区分算力利用率和内存带宽利用率。热词里提到“拿到了 performance 截图怎么查看 performance 面板”这类问题本质上是你在 profiling 面板里看到利用率数字但不知道它代表什么。只要抓住“算力利用率”和“带宽利用率”两个维度大部分 perf 面板都能看懂了。7.5 生产环境一定要预留余量建模算出来的显存是理论下界。生产环境建议预留激活值显存根据输入输出长度动态变化。CUDA context约 300 MB 到 1 GB。推理框架的 KV Cache 预分配vLLM 等框架通常按最大支持序列长度预分配。综合来看按模型权重和 KV Cache 总和再多留 20% 到 30% 的显存余量是较稳健的估算方式。8. 总结从第一性原理出发去理解 LLM 性能建模核心就三句话LLM 推理分为 Prefill 和 Decode 两个阶段前者受算力限制后者受显存带宽限制。显存容量决定了模型能不能跑以及上下文和并发能做多大。精度选择直接影响权重大小、KV Cache 大小和 GPU 算力利用率是性能优化的第一杠杆。本文给出的 Python 脚本可以直接用于日常性能估算帮助你在选型、容量规划和参数调优时快速验证方案。你可以继续深入研究的内容包括vLLM 的 Continuous Batching 调度原理、TensorRT-LLM 的算子优化、KV Cache 量化实现、以及多机多卡场景下的通信瓶颈分析。如果这篇文章对你有帮助可以收藏备用。你在部署 LLM 推理服务时遇到最大的性能瓶颈是什么欢迎在评论区交流。