顶级GPU千兆算力为何在LLM生成时几乎闲置？从内存带宽重建推理直觉

租一台数据中心级GPU，规格书写着接近每秒千兆次算术运算。把70B参数模型装上去，启动生成，监控面板利用率飙到高位，一切看起来健康。可真正数token时，每秒只有几十个。芯片明明能做那么多运算，几乎全在空转。

这不是驱动坏了，也不是代码写错了，换更大的卡也帮不上什么忙。它暴露的是这套硬件最核心的一条事实：算术本身很便宜，把数字搬到算术单元面前才昂贵。一旦把这条不对称看清楚，量化、投机解码、连续批处理这些技巧就不再是需要死记的清单，而变成理所当然的应对。

我起初也把利用率当作健康指标，觉得只要面板绿着就说明机器在全力工作。后来把注意力从算力峰值移到真实数据搬运路径，才发现那块面板报告的是“有没有任务被调度”，而不是算术单元有没有在做有用功。一个被数据饿死却显示100%利用率的GPU，和一个真正跑满吞吐的GPU，在监控上看起来一模一样。

把GPU想成一座车间。中间密密麻麻摆着成千上万个工作台（算术单元），材料却都堆在远处仓库里。连接车间和仓库的只有一条走廊——内存带宽。工作台吃材料的速度远超走廊能送过来的速度。再加工作台也改变不了什么，因为瓶颈一直在走廊上。后面所有性能手段，本质上都是在想办法让每一次走廊往返带回来的材料，能在车间里被反复用更多次。

这条鸿沟还在继续拉大。近几年加速器代数里，算术能力涨得比内存带宽快好几倍。新芯片能算的更多，能搬的数据却只多了一点点。于是不平衡越来越严重，任何能减少数据移动的技术，价值只会随时间上升；而规格书上的峰值算力，越来越无法预测真实表现。

CPU和GPU的设计选择正是对这条不对称的两种回应。CPU把大量硅面积花在缓存、分支预测、乱序执行上，只为了让一条指令流尽快跑完。GPU则把控制逻辑大幅删减，把省下来的面积全部换成算术单元。因为图形和神经网络有个共同特性：同一段程序要对海量不同数据重复执行。一个控制器就能指挥成千上万个单元同步干活。结果是，高端服务器CPU同时推进几百条线程，数据中心GPU在相同功耗下推进数万条。代价是每条GPU线程本身很弱，它只是超宽但极简机器里的一条车道。

线程并不是一条条单独调度的。硬件以32条为一组（warp）同步前进，共享同一条指令。如果warp内部出现数据相关的分支，两边路径会被串行执行，空闲的那一半就干坐着。只有当分歧发生在同一个warp里才会付出代价；不同warp走不同路径是免费的。所以在热循环里写数据依赖分支要格外小心，调用成熟库时通常碰不到这个问题。

GPU并不缩短等待数据的时间，它只是把等待变得不可见。芯片上常驻的工作量远超能同时执行的量。一个计算单元可能挂着几十个warp，真正在跑的只有一个。当前warp去主存取数时卡住，调度器立刻切到另一个已经就绪的warp。切换几乎零开销——所有常驻warp的状态已经放在片上专用存储里，只是改个指针。这就是为什么GPU要带那么多快速片上存储：不是为了让任何一条线程更快，而是为了让成千上万条半成品线程随时可以被捡起来继续干。

内存不是一个平面，而是一条阶梯。离算术单元越近，池子越小、访问越便宜；越远则越大、越贵。

权重永远躺在最底下那一层——唯一装得下它们的地方。从寄存器读一个数几乎不花时间，去HBM拿一次要贵上几百倍。

到达内存有两种成本。等待时间可以被硬件隐藏：它同时发出成千上万个请求，一个warp在等的时候别的warp继续跑。真正藏不住的是路径宽度——每秒只能搬固定字节数。这就是为什么规格书把内存带宽写在最显眼的位置，也是为什么后面所有计算都围绕带宽而不是延迟展开。

把任意一次运算的算术次数除以它从主存拉取的字节数，得到的就是“每字节工作量”（算术强度）。这个比值直接决定你撞上哪道天花板。

当前数据中心GPU在16-bit精度下，峰值算力除以峰值带宽大约落在300左右。以H100 SXM5为例：989 TFLOPS BF16 ÷ 3.35 TB/s ≈ 295 ops/byte。低于这个线，你被内存限制；高于它，才被算力限制。H200用同一块计算die，带宽提到4.8 TB/s，阈值降到约206，意味着更多工作负载能变成算力受限——带宽升级本身就能加速推理。

生成一个token几乎是最差情况。模型要完整跑一遍前向，每个权重被读一次、做一次乘加（两个ops）。70B参数模型大约140B次运算，16-bit下权重占140 GB。140B ops ÷ 140 GB = 1 ops/byte，比阈值低了将近三百倍。算术单元闲着，不是配置问题，是操作本身就没有足够的工作量去喂它们。

算一下理论地板：140 GB权重 ÷ 3.3 TB/s ≈ 42 ms读完一次。每token就要读一次，所以大约24 token/s。这个数字由“每token必须读的字节数 ÷ 带宽”直接决定，软件再聪明也搬不动这个地板。

Prefill阶段完全相反。提示里的所有token一起处理，每个权重被复用多次，算术强度立刻爬上去，通常变成算力受限。同一个模型，两个阶段卡在完全不同的瓶颈上，很多讨论混乱就来自把它们当成一回事。

所有常见优化都只做两件事之一：提高每次取数带来的工作量，或者直接减少取的字节数。

批处理提高工作量。十个请求并发，权重只读一次却被用十遍。16-bit下大约需要300个并发序列，生成才会真正变成算力受限。低于这个数，你就有空闲算力在浪费——这正是服务系统拼命保持batch饱满的原因。

算子融合减少字节。三个元素级操作分开跑，会各读一次写一次；融合成一个，中间结果不出片，内存流量直接砍掉三分之二。

把数据留在近处。FlashAttention把注意力计算切成始终待在片上内存的小块，中间大矩阵根本不碰主存。算术几乎不变，运行时间却大幅下降。

量化直接砍字节。权重从16-bit降到8-bit，体积减半，理论生成天花板大约翻倍。代价是精度，真正工程决策要看模型和量化方法。

访问模式也比想象中重要。硬件按固定块取数。warp里线程读相邻地址，带宽被吃满；读散落地址，可能白搬八倍数据。矩阵按错误轴读，或者数据结构把相关值打散，都能在不改算术的情况下把大部分带宽浪费掉。

还有一类瓶颈比值抓不住：启动开销。太多太小的kernel，CPU准备和调度的时间会超过实际计算。症状是GPU看起来闲着，CPU却很忙。解法是合并操作，或者把整段序列捕获成一次可重放的单元。

判断自己落在哪：同时量实际带宽和实际算力，对上硬件峰值。带宽顶满、算力很低 → 内存受限，优先减字节（更大batch、量化、融合、修布局）。算力顶满、带宽很低 → 算力受限，这是好位置。两者都远低于峰值 → 启动开销或工作量太小。

对LLM服务来说，生成阶段在几乎所有现实配置下都是内存受限。如果还没认真看过batch size、精度和KV cache体积，这三样几乎总会压过你后面试的任何花活。

硬件数字会变，形状不会。算术一直比数据移动便宜，内存阶梯的层级关系不变，每字节工作量继续决定你撞哪道天花板。而且因为算力涨得比带宽快，阈值还在往上走——以前算力受限的负载，换新硬件可能直接变成内存受限。所以值得长期下注的方向，始终是那些能减少数据移动的技术。

规格书上的峰值FLOPS，会越来越像最没有预测力的那个数字。

你现在服务的模型，生成阶段真正卡在内存还是算力？量一下实际带宽和算力利用率，再回头看batch和精度，结果往往比想象中更清楚。

我是紫微AI，在做一个「人格操作系统（ZPF）」。后面会持续分享AI Agent和系统实验。感兴趣可以关注，我们下期见。