跑训练、跑推理，第一反应都是 `watch nvidia-smi`：绿条顶到100%，觉得卡没白买；掉到20%，心里发毛。但从9月25日到10月2日这一周，知乎和B站连着出现几篇把这件事摊开讲的实测帖，合起来说的是同一件事——GPU-Util只回答"忙没忙"，根本回答不了"用没用满"。我把这周的数字拼成三把尺，以及三种"假忙"各自的处方。
先把定义钉死：100%只意味着"至少有一个kernel在跑"
nvidia-smi对GPU-Util的官方口径，是采样周期内"至少有一个kernel正在执行"的时间占比。翻译一下：哪怕一张H100的132个SM里只有一个在慢吞吞读权重，其余131个全闲着，绿条照样能给你顶满100%。知乎
9月28日"上海服务器老张"在这条回答里点得更直：这个数只说明"忙不忙"，不说明"忙得有没有用"。社区里吵"利用率低"的人，吵的往往是三个不同的东西——忙的时间占比、算力利用率、带宽利用率。这一周的两篇集中拆解（9月27日司南的"3个公式"、10月1日上古的"给后端工程师的GPU心智模型"），说的其实是同一件事：推理场景里，这三把尺经常各报各的账。知乎
第一把尺：148倍——带宽受限的decode，Util照样满格
司南那篇的手算我照抄一遍口径：70B模型、FP8精度，权重约70GB，每生成一个token要做约140 GFLOPs计算（2N规则）。放到H100上：把70GB权重从显存搬进计算单元要约20.9ms，真正"算"只要约0.14ms；等价验证是算术强度——decode每搬1字节只配2次浮点运算，而H100的机器平衡点是295，2对295，差147.7倍，和搬数、算数的差距完全吻合，三张卡无一例外全是重度访存受限。他的原话更狠：算力时间优化到0，整体提升也不到1%。老张给的经验区间同向：大batch训练利用率能到90%+，小batch逐条推理常常只有10%~30%。注意他注明了这要看任务和软件版本，不是定律。所以第一种"假忙"是：Util满格、算力其实只用了几个百分点。这不是卡坏了，是decode的本相。这时候加算力卡、换更高FLOPS的型号，钱大概率白花。知乎知乎
第二把尺：2μs——另一半时间花在"派活"上
上古10月1日那篇补了第二笔固定成本：每launch一次kernel，要走参数打包、驱动提交，开销在几μs量级，且不随kernel大小变化——算一个巨型矩阵和一个碎片小核，这笔钱一样。于是"一次decode前向要连续launch上千个小kernel，累加起来能占单步耗时的一大半"，GPU的算术单元大部分时间在等CPU提交下一个kernel，而不是在算。知乎
10月2日深夜发出的DeepJIT尝鲜手记是本周的实测样本：RTX 3060 Laptop上，同一颗saxpy核走驱动API、2万次连发只测入队，每次1757–1758ns——这就是"派一次活"的物理成本。
他的TensorRT合成图256行/批纯批2.03ms，墙不在"算"，就在核与核之间的发射、同步、显存往返。手改最见效的两步：把权重在主机侧转置、让warp内相邻lane地址连续，1.93ms直接砍到0.496ms，数学一行没变。另一段读出打分从4.557ms做到0.881ms定版，累计5.2×。知乎
推理侧的对应处方是CUDA Graph：把上千次派活塌缩成一次回放，常见能省30%~50%的单步CPU开销。vLLM v0.30.0里那套图捕获尺寸（小尺寸密捕1、2、4、8，大尺寸每16跳一格、默认最大512）就是这笔账的工程化：启动时"卡"那一阵是在逐尺寸录图，5个请求被补齐到8跑，是在给固定形状交税。第二种"假忙"：Util很高，但SM大部分时间在等下一个kernel。batch开不大、token/s又上不去时，先查发射开销和图捕获，别先换卡。知乎
第三把尺：86ms——反过来，Util好看也不等于健康
cc aa在9月25日把B200单卡跑Qwen3-8B（FP16权重约16GB）的并发曲线量得很全，第一笔账就扎眼：batch=1时TPOT 4.08ms，每token要把16GB权重读一遍，折回有效带宽约4TB/s——连B200标称带宽的一半都没吃满，缺的那部分正是小核跑不满HBM加上每步调度采样的固定开销。知乎
第二笔账是并发的红利：并发16时读一遍权重可以同时为16个请求各生成1个token，成本几乎不变、产出翻16倍，continuous batching的账这一句最清楚。但并发64起TPOT快速变长，因为每一步除了权重还要把所有请求的KV Cache读一遍（平均上下文约1150 token、单请求约0.17GB），FP8 KV能把这笔读取直接砍半。知乎
第三笔账才是"86ms"：并发128时ITL中位数只有7.7ms，P99却拉到86ms，用户体感"一卡一卡"；TTFT从30ms涨到773ms，根因是prefill和decode挤在同一个batch里互相踩——这正是llm-d、NVIDIA Dynamo做PD分离要解决的问题，也是这个月初PCP/DCP/KVPP一批长上下文并行方案集中出现的起点。知乎
第三种假象反过来：Util曲线很绿，但P99 ITL和TTFT炸了。要动的是调度和显存里的KV，不是加卡。
还有第四种"假忙"，和一张排查顺序表
训练侧的账B站9月7日那篇也量过：GPU利用率忽高忽低、周期性归零，大概率不是GPU的问题，是数据喂料跟不上——IO瓶颈。老张给科研用户最扎心的一条：先确认软件是GPU编译版、驱动和CUDA匹配、编译架构参数对不对，“这三步不对，换什么卡都白搭”。跑VASP这类FP64负载的还要记得，4090的双精度只有FP32的1/64，SM看着忙、单元根本不够用——这不是利用率的问题，是硬件规格的问题。哔哩哔哩知乎
所以先别拿Util吓自己去换卡：这轮算力租赁行情里，高端显卡租金半年内上涨近三成。双十一越来越近，换错、租错都是真金白银。按这个顺序量：知乎
GPU-Util只当"开机自检"，不当"值不值"的依据；
推理场景先看tokens/s和带宽利用率：decode撞的是带宽墙，换更高算力的卡没用，先加batch、量化、FP8 KV；
小batch提速不动：查kernel数量、launch开销，上CUDA Graph/图捕获；
并发一高P99 ITL、TTFT发散：动调度、动KV、PD分离，别动硬件；
训练利用率周期性归零：查数据供给；科研低利用率：查精度、软件版本，最后才轮到选型。
一句话版本：你要问的从来不该是"利用率多高"，而是"这一步撞的是哪堵墙"——带宽墙、发射墙、数据墙，三堵墙的处方里没有一张是"再买张卡"。
