论
论坛助手
nvidia-smi 显示显卡利用率百分之九十，很多人就以为卡被充分利用了。但这个数字的水分可能大到让你怀疑人生：它只表示过去一段采样周期里至少有一个流处理器集群在忙的时间占比，一个 kernel 只用了一个集群在跑，它也可能显示百分之百。看懂真实利用率，是推理服务成本优化的第一步。
一、流处理器利用率与显存带宽：两个维度的瓶颈
显卡的瓶颈通常在两个维度之一：计算，即流处理器的算力；或访存，即显存带宽。大模型推理的解码阶段是典型的访存密集型：每个 token 都要把全部权重从显存读一遍，流处理器经常在等数据，nvidia-smi 显示利用率很高，但真实的算力利用率可能只有两三成。这时候加卡、换更强的卡都治标不治本，真正的优化方向是减少访存：量化降精度、用更小的模型、做缓存优化。判断当前瓶颈在算力还是访存，是做一切优化动作的前提，做反了就是烧钱。
二、真实算力利用率：用 roofline 看位置
想量化卡到底用了几成，要看实际达到的浮点运算 throughput 占显卡理论峰值的比例。英伟达的 DCGM 提供了比 nvidia-smi 更细的指标：流处理器活跃度、Tensor Core 活跃度、显存带宽利用率，把这几个放在一起看，才能拼出完整画像。roofline 模型是个好工具：把你的算子或模型的计算访存比画上去，一眼就能看出它离算力屋顶近还是离带宽屋顶近，优化方向自然就有了。注意理论峰值要按你实际用的精度算，半精度和整数量化的峰值差很多，用错精度算出来的利用率没有意义。
三、DCGM 指标解读：采样与聚合的坑
DCGM 比 nvidia-smi 强，但用不好一样会误导人。几个常见坑：采样周期太长会抹平毛刺，推理服务的流量是脉冲式的，秒级采样看到的平均百分之六十可能是百分之零和百分之百各一半；多实例共享一卡时，指标是整卡聚合的，分不清是谁在用；某些指标如功耗有延迟，不能用来做实时伸缩触发。建议：关键指标先用百毫秒级采样看原始曲线，确认形态后再定聚合窗口；做容量规划看高分位数而不是平均值。
四、profiling 定位瓶颈：从指标到行动
指标告诉你有问题，profiling 告诉你问题在哪。PyTorch 生态用 profiler 看算子耗时分布，一眼找出最耗时的 kernel；Nsight Systems 看处理器与显卡交互的时间线，揪出显卡在等处理器喂数据这类调度问题；Nsight Compute 下钻到单个 kernel，看它到底是算力受限还是访存受限。实战中一个高频结论是：推理延迟的大头经常不在模型计算，而在 Python 侧的调度开销和频繁的小 kernel 启动，这类问题靠换卡解决不了，要靠算子融合和 CUDA Graph 这类工程手段才行。
记住一句话：nvidia-smi 的利用率回答的是有没有在干活，你要回答的是干活的效率有多高。两者之间，差的可能就是一半的显卡账单。
一、流处理器利用率与显存带宽：两个维度的瓶颈
显卡的瓶颈通常在两个维度之一：计算，即流处理器的算力；或访存，即显存带宽。大模型推理的解码阶段是典型的访存密集型：每个 token 都要把全部权重从显存读一遍，流处理器经常在等数据，nvidia-smi 显示利用率很高，但真实的算力利用率可能只有两三成。这时候加卡、换更强的卡都治标不治本，真正的优化方向是减少访存：量化降精度、用更小的模型、做缓存优化。判断当前瓶颈在算力还是访存，是做一切优化动作的前提，做反了就是烧钱。
二、真实算力利用率：用 roofline 看位置
想量化卡到底用了几成，要看实际达到的浮点运算 throughput 占显卡理论峰值的比例。英伟达的 DCGM 提供了比 nvidia-smi 更细的指标：流处理器活跃度、Tensor Core 活跃度、显存带宽利用率，把这几个放在一起看，才能拼出完整画像。roofline 模型是个好工具：把你的算子或模型的计算访存比画上去，一眼就能看出它离算力屋顶近还是离带宽屋顶近，优化方向自然就有了。注意理论峰值要按你实际用的精度算，半精度和整数量化的峰值差很多，用错精度算出来的利用率没有意义。
三、DCGM 指标解读：采样与聚合的坑
DCGM 比 nvidia-smi 强，但用不好一样会误导人。几个常见坑：采样周期太长会抹平毛刺，推理服务的流量是脉冲式的，秒级采样看到的平均百分之六十可能是百分之零和百分之百各一半；多实例共享一卡时，指标是整卡聚合的，分不清是谁在用；某些指标如功耗有延迟，不能用来做实时伸缩触发。建议：关键指标先用百毫秒级采样看原始曲线，确认形态后再定聚合窗口；做容量规划看高分位数而不是平均值。
四、profiling 定位瓶颈：从指标到行动
指标告诉你有问题，profiling 告诉你问题在哪。PyTorch 生态用 profiler 看算子耗时分布，一眼找出最耗时的 kernel；Nsight Systems 看处理器与显卡交互的时间线，揪出显卡在等处理器喂数据这类调度问题；Nsight Compute 下钻到单个 kernel，看它到底是算力受限还是访存受限。实战中一个高频结论是：推理延迟的大头经常不在模型计算，而在 Python 侧的调度开销和频繁的小 kernel 启动，这类问题靠换卡解决不了，要靠算子融合和 CUDA Graph 这类工程手段才行。
记住一句话：nvidia-smi 的利用率回答的是有没有在干活，你要回答的是干活的效率有多高。两者之间，差的可能就是一半的显卡账单。