看到 nvidia-smi 里的显存接近满载，很多团队会以为卡已经吃满。真正该看的，是一次训练或推理任务的时间线：GPU 花了多少时间执行计算，又有多少时间在等数据、等其他卡、等内存分配。
假如利用率长期停在约 40%，先别急着扩容。把一个 Step 拆开，往往比继续加卡更快找到成本漏洞。
一篇讨论 2026 年 GPU 供需的知乎文章称，算力需求同比增长超过 300%，GPU 产能增速约 40%。该文同时写到，GPU 成本曾下降 30%，但 2024—2025 年降幅只有 5%—8%，并预计 2026 年平稳或小幅上升。
摘要没有说明 GPU 型号、采购还是租赁等计价口径，这组数字不宜直接套进预算。它至少提醒了一个现实：卡闲着的代价正在变高。
显存占用只是空间账
模型权重、优化器状态、KV Cache 和框架预留区都能占住显存。这些数据放在卡上，并不代表计算单元一直有活可干。
在 7B—14B 模型微调或推理任务中，动态 Shape、长度变化较大的输入，以及 KV Cache 的频繁申请和释放，都可能让显存分配变得零散。常见现象是框架保留了大量显存，真正可用的大块空间却不足。随后可能出现分配器反复清理缓存、缩小 Batch、OOM 和任务重试，有效吞吐也会跟着下降。
排查时，应该把峰值显存、保留量与实际分配量、OOM 记录、重试次数和 Batch 变化放到同一条任务时间线上。输入长度相近的请求可以分组处理；形状较稳定的任务，可以测试静态 Shape 或内存池方案，减少反复分配。
如果项目正在迁移昇腾 910C/910D，还要检查自定义算子、动态 Shape 和算子回退。某个算子落到 CPU 执行时，显存依旧可能占着，NPU 的执行时间线却会出现明显空档。
利用率的谷底，常藏在 Step 之间
多机多卡训练中，反向传播期间或结束后需要进行梯度同步。昇腾集群会用到 HCCL，英伟达集群则可能经 NVLink 等互联传输。只要一个节点慢下来，其他节点就要在同步点等待。
利用率曲线如果在每个 Step 末尾周期性下坠，可以优先检查 All-Reduce 和网络拓扑；如果空档出现在 Step 开始前，数据读取、CPU 预处理和存储 I/O 更值得怀疑；只有个别节点长期落后，则要继续查单机状态、链路和任务分布。这些现象只是线索，最终仍要用性能分析工具对齐各张卡的时间线。
混合芯片集群还要避免随意跨节点拼任务。更稳妥的做法，是把同类芯片和高速互联范围内的卡组成“计算岛”，优先在岛内完成任务，减少跨芯片、跨节点通信。调度器不能只看还有几张空闲卡，也要识别卡与卡之间的连接关系。
算子在跑，吞吐仍可能很差
高层框架的默认算子未必适合目标硬件。部分算子会产生大量重复的显存读写，任务受内存带宽限制，矩阵计算单元没有被充分调用。此时面板可能显示 GPU 正在工作，实际每秒处理量依然不理想。
如果软硬件栈支持，可以对比 FlashAttention-3 或同类优化算子，检查算子融合、内存访问和回退情况。评估 Llama 4、Qwen 3.5 这类模型时，也应在目标硬件上测任务完成时间、有效吞吐、显存峰值和算子执行记录。榜单分数与理论 TFLOPS 无法代替这些数据。
账要落到每个任务上
FinOps 算力审计不应停在月度总账单。更有用的记录方式是把任务 ID、占卡时间、有效产出、报错重试和最终成本串起来。这样才能看清钱花在了正常计算、排队等待，还是失败任务上。
Agent 类任务尤其需要给 API 路由设置预算、超时和重试上限，避免报错链路持续占用算力。离线任务可以测试容器级动态切分或多任务并行；在线服务则要保留必要余量，不能为了拉高利用率把响应时间和失败率一起推高。TCO 最终应落到每个已完成任务的成本上。
租用算力时，还要确认问题是否来自平台本身。一份 2026 年 GPU 算力租用指南称，当前平台超过五十家，并设置了五个准入门槛，其中第一项就是算力真实性：实测性能要与标称参数一致，不能存在降频或超售。
这类指南带有自身筛选口径，但“先验算力”这个检查项值得保留。签约前用同一任务做多时段抽测，比只比较每小时单价更可靠。单价看起来便宜，任务完成时间却更长，实际成本未必更低。
涨价数字先看计价口径
一篇文章转引 Counterpoint 的预测，称内存价格在 2026 年第二季度前还将额外上涨 40%。另一篇 2026 年 4 月发布的 GPU 租用文章则提到，部分云厂商 AI 模型算力价格涨幅高达 463%。
这两个数字都不能直接换算成某支团队的续费涨幅。前者是内存价格预测，后者的摘要没有列出具体厂商、GPU 规格和计费方式。采购或续租时，应在相同硬件规格、任务配置和计费口径下比较，并把降频、超售和实际完成时间一起算进去。
74% 可以参考，别当盈亏线
一篇 2026 年 GPU 平台选型文章称，其方案的算力利用率可达到 74% 以上，并进一步降低综合成本。这个数字可以作为平台案例参考，不能直接设成所有集群的盈亏线。
训练、在线推理和离线批处理的负载形态不同。把任务塞得过满，可能带来排队、超时和重试，账单反而更难控制。利用率目标需要和有效吞吐、任务完成时间、重试情况及单任务成本一起看。
当面板显示约 40% 利用率时，可以按这个顺序处理：
- 抓取完整任务时间线，先定位 GPU 在哪里等待；
- 对照实际分配与框架保留显存，检查碎片、OOM 和 Batch 变化；
- 查看多卡同步、数据供给、存储 I/O 和慢节点；
- 对目标硬件做算子分析，确认是否存在低效实现或 CPU 回退；
- 复核调度策略，以及租用平台是否降频或超售。
完成调整后，再用同一任务、同一配置复测。只有计算阶段持续饱和，任务队列仍无法消化时，增加卡数才有充分理由。约 40% 的利用率只是表面症状，真正需要找到的是 GPU 究竟在等什么。
