大模型推理为什么吃带宽？从底层给你讲明白

很多人有个误区：大模型推理，GPU 算力越强越快。
其实不对。大模型推理，真正的瓶颈不是算力，是显存带宽。
今天从底层原理讲起，给你算明白：为什么大模型推理吃带宽，到底吃多少，各种奇怪的现象背后都是什么原因。
一、先给结论：推理是带宽密集型，训练才是算力密集型
一句话总结：
训练：计算量大，数据复用率高，吃算力
推理：计算量小，数据复用率低，吃带宽
很多人不信，我们来算笔账。
二、为什么推理吃带宽？从底层原理讲

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

文末追加：带宽测算仿真代码
一、可直接运行 Python 带宽吞吐量测算代码
11. 单模型单 Token 带宽消耗 & 理论 Token 速度计算器

def calc_infer_bandwidth_speed(
    param_billion: float,  # 模型参数量 7/13/32/70
    bit_type: str,         # fp16 / fp8 / int4
    gpu_bw_gbs: float      # 显卡显存带宽 GB/s
):