租一台数据中心级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要带那么多快速片上存储不是为了让任何一条线程更快而是为了让成千上万条半成品线程随时可以被捡起来继续干。内存不是一个平面而是一条阶梯。离算术单元越近池子越小、访问越便宜越远则越大、越贵。层级大致容量谁能看到访问代价每线程寄存器几个值单线程几乎免费片上共享内存/L1每块几百KB同一线程块非常便宜L2缓存整芯片几十MB所有块明显变慢主存HBMVRAM几十GB所有块最慢一个数量级以上权重永远躺在最底下那一层——唯一装得下它们的地方。从寄存器读一个数几乎不花时间去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里线程读相邻地址带宽被吃满读散落地址可能白搬八倍数据。矩阵按错误轴读或者数据结构把相关值打散都能在不改算术的情况下把大部分带宽浪费掉。还有一类瓶颈比值抓不住启动开销。太多太小的kernelCPU准备和调度的时间会超过实际计算。症状是GPU看起来闲着CPU却很忙。解法是合并操作或者把整段序列捕获成一次可重放的单元。判断自己落在哪同时量实际带宽和实际算力对上硬件峰值。带宽顶满、算力很低 → 内存受限优先减字节更大batch、量化、融合、修布局。算力顶满、带宽很低 → 算力受限这是好位置。两者都远低于峰值 → 启动开销或工作量太小。对LLM服务来说生成阶段在几乎所有现实配置下都是内存受限。如果还没认真看过batch size、精度和KV cache体积这三样几乎总会压过你后面试的任何花活。硬件数字会变形状不会。算术一直比数据移动便宜内存阶梯的层级关系不变每字节工作量继续决定你撞哪道天花板。而且因为算力涨得比带宽快阈值还在往上走——以前算力受限的负载换新硬件可能直接变成内存受限。所以值得长期下注的方向始终是那些能减少数据移动的技术。规格书上的峰值FLOPS会越来越像最没有预测力的那个数字。你现在服务的模型生成阶段真正卡在内存还是算力量一下实际带宽和算力利用率再回头看batch和精度结果往往比想象中更清楚。我是紫微AI在做一个「人格操作系统ZPF」。后面会持续分享AI Agent和系统实验。感兴趣可以关注我们下期见。