很多人有个误区：大模型推理，GPU 算力越强越快。其实不对。大模型推理，真正的瓶颈不是算力，是显存带宽。今天从底层原理讲起，给你算明白：为什么大模型推理吃带宽，到底吃多少，各种奇怪的现象背后都是什么原因。一、先给结论：推理是带宽密集型，训练才是算力密集型一句话总结：训练：计算量大，数据复用率高，吃算力推理：计算量小，数据复用率低，吃带宽很多人不信，我们来算笔账。二、为什么推理吃带宽？从底层原理讲推理的本质：一遍一遍读参数大模型推理，每生成一个 token（一个字），都要做这么一件事：把模型的全部参数，从显存里读出来拿到计算单元里算一遍把结果写回去注意关键词：每生成一个字，就要读一遍全部参数。7B 模型，全部参数读一遍，就是 70 亿个数字。70B 模型，全部参数读一遍，就是 700 亿个数字。你算算，这得多少数据？计算量其实很小读这么多数据，计算量有多大呢？其实不大，就是矩阵乘、向量加，对 GPU 来说都是小儿科计算单元很快就把活干完了，然后就闲着等下一批数据等数据的时间，比计算的时间长多了就好比你搬砖：搬砖的过程很快，但砖在很远的地方，大部分时间都花在运砖路上了。算力就是搬砖的力气，带宽就是运砖的路。路太窄，力气再大也没用，砖运不过来，你只能闲着等。三、量化一下：到底吃多少带宽？我们来算笔细账，用大家最熟悉的几个模型：先统一单位1 个 FP16 参数 = 2 字节1 个 FP8 参数 = 1 字节1 个 4bit 量化参数 = 0.5 字节7B 模型（最常用的）FP16 精度：7B × 2B = 14GB 数据 / 每 token4bit 量化：7B × 0.5B = 3.5GB 数据 / 每 token13B 模型FP16：26GB/token4bit：6.5GB/token32B 模型FP16：64GB/token4bit：16GB/token70B 模型FP16：140GB/token4bit：35GB/token什么概念？RTX 5090 显存带宽是多少？1792GB/s。理论上，7B 模型 4bit 量化，每秒能生成：1792 ÷ 3.5 ≈ 512 token/s听起来很快？但这是理论上限，实际上：有计算开销有调度开销有显存碎片有带宽冲突还有 KV 缓存要读写实际能跑到 200-300 token/s 就不错了。那 70B 模型 4bit 量化呢？1792 ÷ 35 ≈ 51 token/s实际能跑到 20-30 token/s 就不错了。你看，是不是带宽说了算？四、这些现象，都能用 “带宽瓶颈” 解释很多你觉得奇怪的现象，其实都是带宽瓶颈导致的：为什么量化之后，速度提升这么明显？很多人发现，7B 模型从 FP16 改成 4bit 量化，速度直接翻了三四倍。为什么？不是计算变快了，计算量没少多少是要读的数据量变小了，带宽压力小了原来读 14GB，现在读 3.5GB，少了 75%带宽够用了，自然就快了量化的本质，就是用精度换带宽。为什么 batch size 小的时候，GPU 利用率很低？batch size=1 的时候，GPU 利用率可能只有 30-40%，很多人觉得浪费。为什么？因为计算单元太快了，数据供不上算完一批，等下一批数据等半天GPU 大部分时间在闲着等数据利用率当然低了batch size 开大一点，一次算多个请求，数据复用率高了，利用率就上去了。但这是推理，不是训练，哪来那么多 batch？为什么 HBM 显存的卡，推理比 GDDR 快这么多？H200 带宽 4.8TB/s，5090 带宽 1.8TB/s，差 2.6 倍。推理速度呢？可能差 3-4 倍。为什么差得比带宽还多？因为带宽越小，瓶颈越严重，浪费越多带宽足够大的时候，计算才能跑满带宽不够的时候，大部分时间都在等带宽就是木桶最短的那块板。为什么模型越大，速度越慢，而且不是线性的？7B 模型每秒 50token，13B 模型每秒 25token，32B 模型每秒 10token，70B 模型每秒 3-5token。不是线性下降，是越来越慢。为什么？模型小的时候，带宽还能凑合，计算还能跑个七八成模型大了，带宽彻底不够了，计算大部分时间都在等效率越来越低，速度下降得比模型大小还快五、怎么优化？几个思路知道了瓶颈在带宽，优化方向就很明确了：量化（最直接，效果最明显）从 FP16 降到 8bit，再降到 4bit，甚至 2bit精度损失一点，速度翻几倍，非常划算现在大家都这么干，4bit 量化基本是标配了KV 缓存优化推理的时候，前面生成的 token 的 KV 值要存起来每生成一个新 token，都要读一遍所有 KVKV 缓存也吃带宽，优化 KV 缓存能省不少带宽什么分页注意力、KV 缓存量化，都是干这个的模型并行一张卡装不下，或者带宽不够，就拆到多张卡上每张卡只读一部分参数，带宽加起来就大了但通信开销也会增加，得平衡批处理（batching）把多个请求攒到一起算一次读参数，算多个请求，数据复用率高了相当于同样的带宽，干更多的活但延迟会增加，得权衡吞吐和延迟六、总结最后总结几句：大模型推理，带宽才是真瓶颈，算力再高，带宽不够也白搭量化是最有效的优化手段，本质是用精度换带宽，性价比极高HBM 显存贵有贵的道理，带宽大，推理就是快模型越大，带宽瓶颈越明显，效率越低以后的优化方向，很多都是围绕带宽做文章以后再有人跟你说 “这卡算力这么强，跑大模型肯定快”，你就跟他说：先看看带宽多少。文末追加：带宽测算仿真代码一、可直接运行 Python 带宽吞吐量测算代码11. 单模型单 Token 带宽消耗 理论 Token 速度计算器defcalc_infer_bandwidth_speed(param_billion:float,# 模型参数量 7/13/32/70bit_type:str,# fp16 / fp8 / int4gpu_bw_gbs:float# 显卡显存带宽 GB/s):
很多人有个误区：大模型推理，GPU 算力越强越快。其实不对。大模型推理，真正的瓶颈不是算力，是显存带宽。今天从底层原理讲起，给你算明白：为什么大模型推理吃带宽，到底吃多少，各种奇怪的现象背后都是什么原因。一、先给结论：推理是带宽密集型，训练才是算力密集型一句话总结：训练：计算量大，数据复用率高，吃算力推理：计算量小，数据复用率低，吃带宽很多人不信，我们来算笔账。二、为什么推理吃带宽？从底层原理讲推理的本质：一遍一遍读参数大模型推理，每生成一个 token（一个字），都要做这么一件事：把模型的全部参数，从显存里读出来拿到计算单元里算一遍把结果写回去注意关键词：每生成一个字，就要读一遍全部参数。7B 模型，全部参数读一遍，就是 70 亿个数字。70B 模型，全部参数读一遍，就是 700 亿个数字。你算算，这得多少数据？计算量其实很小读这么多数据，计算量有多大呢？其实不大，就是矩阵乘、向量加，对 GPU 来说都是小儿科计算单元很快就把活干完了，然后就闲着等下一批数据等数据的时间，比计算的时间长多了就好比你搬砖：搬砖的过程很快，但砖在很远的地方，大部分时间都花在运砖路上了。算力就是搬砖的力气，带宽就是运砖的路。路太窄，力气再大也没用，砖运不过来，你只能闲着等。三、量化一下：到底吃多少带宽？我们来算笔细账，用大家最熟悉的几个模型：先统一单位1 个 FP16 参数 = 2 字节1 个 FP8 参数 = 1 字节1 个 4bit 量化参数 = 0.5 字节7B 模型（最常用的）FP16 精度：7B × 2B = 14GB 数据 / 每 token4bit 量化：7B × 0.5B = 3.5GB 数据 / 每 token13B 模型FP16：26GB/token4bit：6.5GB/token32B 模型FP16：64GB/token4bit：16GB/token70B 模型FP16：140GB/token4bit：35GB/token什么概念？RTX 5090 显存带宽是多少？1792GB/s。理论上，7B 模型 4bit 量化，每秒能生成：1792 ÷ 3.5 ≈ 512 token/s听起来很快？但这是理论上限，实际上：有计算开销有调度开销有显存碎片有带宽冲突还有 KV 缓存要读写实际能跑到 200-300 token/s 就不错了。那 70B 模型 4bit 量化呢？1792 ÷ 35 ≈ 51 token/s实际能跑到 20-30 token/s 就不错了。你看，是不是带宽说了算？四、这些现象，都能用 “带宽瓶颈” 解释很多你觉得奇怪的现象，其实都是带宽瓶颈导致的：为什么量化之后，速度提升这么明显？很多人发现，7B 模型从 FP16 改成 4bit 量化，速度直接翻了三四倍。为什么？不是计算变快了，计算量没少多少是要读的数据量变小了，带宽压力小了原来读 14GB，现在读 3.5GB，少了 75%带宽够用了，自然就快了量化的本质，就是用精度换带宽。为什么 batch size 小的时候，GPU 利用率很低？batch size=1 的时候，GPU 利用率可能只有 30-40%，很多人觉得浪费。为什么？因为计算单元太快了，数据供不上算完一批，等下一批数据等半天GPU 大部分时间在闲着等数据利用率当然低了batch size 开大一点，一次算多个请求，数据复用率高了，利用率就上去了。但这是推理，不是训练，哪来那么多 batch？为什么 HBM 显存的卡，推理比 GDDR 快这么多？H200 带宽 4.8TB/s，5090 带宽 1.8TB/s，差 2.6 倍。推理速度呢？可能差 3-4 倍。为什么差得比带宽还多？因为带宽越小，瓶颈越严重，浪费越多带宽足够大的时候，计算才能跑满带宽不够的时候，大部分时间都在等带宽就是木桶最短的那块板。为什么模型越大，速度越慢，而且不是线性的？7B 模型每秒 50token，13B 模型每秒 25token，32B 模型每秒 10token，70B 模型每秒 3-5token。不是线性下降，是越来越慢。为什么？模型小的时候，带宽还能凑合，计算还能跑个七八成模型大了，带宽彻底不够了，计算大部分时间都在等效率越来越低，速度下降得比模型大小还快五、怎么优化？几个思路知道了瓶颈在带宽，优化方向就很明确了：量化（最直接，效果最明显）从 FP16 降到 8bit，再降到 4bit，甚至 2bit精度损失一点，速度翻几倍，非常划算现在大家都这么干，4bit 量化基本是标配了KV 缓存优化推理的时候，前面生成的 token 的 KV 值要存起来每生成一个新 token，都要读一遍所有 KVKV 缓存也吃带宽，优化 KV 缓存能省不少带宽什么分页注意力、KV 缓存量化，都是干这个的模型并行一张卡装不下，或者带宽不够，就拆到多张卡上每张卡只读一部分参数，带宽加起来就大了但通信开销也会增加，得平衡批处理（batching）把多个请求攒到一起算一次读参数，算多个请求，数据复用率高了相当于同样的带宽，干更多的活但延迟会增加，得权衡吞吐和延迟六、总结最后总结几句：大模型推理，带宽才是真瓶颈，算力再高，带宽不够也白搭量化是最有效的优化手段，本质是用精度换带宽，性价比极高HBM 显存贵有贵的道理，带宽大，推理就是快模型越大，带宽瓶颈越明显，效率越低以后的优化方向，很多都是围绕带宽做文章以后再有人跟你说 “这卡算力这么强，跑大模型肯定快”，你就跟他说：先看看带宽多少。文末追加：带宽测算仿真代码一、可直接运行 Python 带宽吞吐量测算代码11. 单模型单 Token 带宽消耗 理论 Token 速度计算器defcalc_infer_bandwidth_speed(param_billion:float,# 模型参数量 7/13/32/70bit_type:str,# fp16 / fp8 / int4gpu_bw_gbs:float# 显卡显存带宽 GB/s):
