数据中心里有一句常见的话：GPU 利用率越高越好，空着就是浪费。这句话在多数情况下方向没错，但如果把它当成判断标准，很容易走偏。一块显示 95% 利用率的 GPU，可能正在满负荷地渲染画面，也可能在反复等待显存里的数据；两种情况下监控曲线几乎一样，电表上的读数也接近，产出的任务数却可能差出一大截。九游会在整理游戏数据中心的观测口径时，把“利用率”降为辅助指标，把吞吐量和每任务能耗放到前面，理由就在这里。
利用率这个数字到底在测什么
多数 GPU 监控里的“利用率”，指的是采样周期内至少有一个内核在执行的时间比例。它回答的是“这段时间有没有活在跑”，不回答“计算单元被填满了多少”。所以至少有三种情形会让利用率看上去很好，效率却不高。
- 受限于显存带宽或数据搬运：内核在执行，但大部分时间在等数据。计算单元没有满载，功率却因为显存和互连的活动而不低。
- 批处理过小：每次只送一点点任务，卡一直“忙”，但单次启动和调度的固定开销占比很高，每个任务分摊的能耗偏大。
- 被占用但低活动：2026 年 4 月一篇 arXiv 论文《The Energy Cost of Execution-Idle in GPU Clusters》讨论过一种“执行中空闲”状态，即任务仍占着 GPU，硬件却处于低活动。论文报告在其所研究的集群里，这种状态约占任务执行时间的两成、能耗的一成左右。这个比例属于他们的集群与负载，不能直接搬到游戏渲染或推理上，但它说明“被占用”与“在产出”是两回事。
反过来也成立：利用率并不高的 GPU 未必浪费。实时云渲染需要在每一帧的时间预算内完成，为了保证帧时间稳定，往往刻意不把卡压满。这类负载如果一味追求高利用率，卡顿和抖动的代价远比省下的电更大。
模拟示例：同一块卡，三种配置的每任务能耗
假设一块峰值功率 400W 的 GPU，用来做一类可以批处理的后台任务（例如资产处理或非实时的 AI 推理）。同样的任务用三种配置运行：
| 配置 | GPU利用率 | 平均功率 | 吞吐量 | 每任务能耗 |
|---|---|---|---|---|
| A：小批量，未调优 | 92% | 380W | 40 任务/小时 | 9.5 Wh |
| B：批量调优 | 85% | 330W | 60 任务/小时 | 5.5 Wh |
| C：B 基础上加功率上限 280W | 82% | 280W | 54 任务/小时 | 约 5.2 Wh |
这张示意表可以读出几件事。第一，配置 A 的利用率最高，每任务能耗却最差，约为 B 的 1.7 倍，所以“利用率高”并没有告诉我们它更省电。第二，B 到 C 的变化，吞吐下降了约一成，每任务能耗略有下降，说明功率上限带来的收益在这个假设下很有限；如果任务有截止时间，这一成的吞吐损失可能根本不值得。第三，如果把这个例子换成一个每帧都有时间预算的实时渲染任务，配置 C 就未必能用，因为降功率带来的时延增加会直接体现在玩家的画面上。
公开研究里也有类似的现象，但要小心比较。一项较早的研究在较旧的加速卡上做大模型推理，把功率上限降低约三成，推理时间增加了不到一成，总能耗下降了两成多，再往下压则时间成本急剧上升。这种“先划算、后不划算”的形状比具体的百分比更值得记住，因为具体百分比取决于硬件代际和任务类型，今天的新硬件不能照搬。
该看什么：把“效率”拆成能被复核的几个量
基于上面的观察，九游会数据中心AI在评估 GPU 使用情况时，倾向于同时看这几个量，而不是单独看一个：
- 吞吐量：单位时间内完成的有效任务数、渲染的有效帧数或处理的有效请求数。“有效”意味着满足质量要求，例如没有掉帧、结果没有被丢弃重跑。
- 每任务能耗（Energy per Task）：用一段时间内的电量除以完成的任务数。比“瓦数”更能反映效率，因为它把速度和功率放进同一个分子分母里。
- Performance per Watt：单位功率下能做的工作，是对每任务能耗的另一种表述，方便横向比较不同硬件。
- 延迟分布与服务等级：对实时任务，必须同时看 P95、P99 帧时间或响应时间。提升效率不能以突破这个约束为代价。
- 空闲与低活动时长：把整段“被占用但无产出”的时间单独统计，才能知道有多少电用在等待上。
其中前三项都依赖“任务”的定义。对云渲染来说，一个任务可能是“一位玩家在一小时里的渲染工作”；对批处理来说，可能是“一份资产包处理”。定义不同，结论就不同，所以同一张表里不要混着比。这种以每玩家小时作为分母的想法，和《4K、120帧和云渲染画质越来越高，游戏碳足迹为什么也需要“性能预算”》里讨论的性能预算是同一条思路。
游戏里的GPU负载，其实分成三类
实时渲染与视频编码
云渲染与实时编码负载对时延最敏感。这类负载的目标是在满足帧时间和画质的前提下，尽量让每位玩家占用的 GPU 时间更少，做法包括动态分辨率、按内容调整码率、按场景复杂度分配资源、多路会话在同一块卡上合理复用等。复用有一个上限：会话之间会争抢显存带宽和编码器，超过这个上限，帧时间会变得不可预测。因此这类负载的“高利用率”要以延迟分布是否达标为前提。
可批处理的 AI 推理
用于运营分析、内容审核、客服或非实时生成的推理，可以把请求攒成批次，在吞吐与延迟之间取舍。批量越大，每个请求分摊的固定开销越小，能耗往往先降后趋于平稳，再往上就只是让请求等得更久。这一类才是“提高利用率”通常真正有效的地方。
可延迟的离线任务
补丁构建、资产烘焙、模型训练和日志分析，可以推迟到设备空闲的时候，也可以选择电网碳强度更低的时段或地区。对这类任务，调度的目标是让 GPU 少空转，而不是要求每一分钟都占满。它们与低碳时段选择的关系，在《游戏数据中心为什么不能只追求最低PUE？九游会AI开始把玩家延迟、算力和碳排放一起优化》中有更完整的框架。
利用率提升有效的时候，通常发生在哪里
需要公平地说，提高利用率在很多场合确实是省电的，尤其是当原来大量 GPU 长期处于空闲，而空闲功率又不低的时候。这时把分散的小任务集中到较少的卡上，让空出来的卡休眠或转作他用，总功率就会下降。这部分逻辑与 CPU 服务器一致，《服务器利用率只有20%，电费会不会只剩20%？九游会为什么开始关注“空闲算力”的隐藏能耗》里用一个模拟示例演示过。区别在于，GPU 的空闲功率占比、唤醒时间和显存状态的保留成本都因型号而异，因此不能把 CPU 的经验直接套上去。
更准确的说法是：在“完成同样工作”的前提下，把没有产出的 GPU 时间减到最少，是有意义的；把利用率数字本身当成目标，是危险的。
节能，还是减碳
即使每任务能耗下降了，也只是 Energy Efficiency 的改善。碳排取决于这些电用在何处、何时。同一批任务，如果因为提升了效率而在原来的高碳时段多跑了，碳排也可能上升；相反，如果把可延迟的任务挪到可再生能源占比更高的时段，即使总耗电几乎不变，碳排也会下降。数据中心的整体设施能耗还要乘上冷却与配电的开销，也就是 PUE，但 PUE 同样只描述设施效率，不代表电力的低碳程度，这一点见《数据中心PUE很好看，为什么整体碳排还是可能很高？》。所以，评估一块 GPU 的使用效率，最终要给出每任务的电量，再乘以对应区域与时段的排放因子，才是 Carbon Efficiency 的口径。
九游会目前的做法与做不到的地方
九游会数据中心AI当前的设计取向，是把 GPU 相关指标按负载类型分开建模，而不是给全部 GPU 一个统一的“利用率目标”。它读取的输入包括 GPU 的功率与时钟、显存与编码器占用、任务队列和完成数，以及延迟指标；输出的是对不同类型负载的建议，例如哪些批任务可以合并、哪些卡的低活动时间过长、哪些实时会话在提高复用后可能触碰延迟红线。这些建议是否执行，需要经过延迟与容量约束的检查，而不是直接改动线上调度。
需要坦率承认的限制有这几条：
- 没有卡级功率读数时，每任务能耗只能靠模型估算，误差可能很大。
- 多租户或共享 GPU 时，把一块卡的电量准确分给每个任务，本身没有公认口径。
- 同一份硬件在不同的驱动、编码器设置和游戏内容下，功率与吞吐的关系会变化，模型需要定期重新校准。
- 目前不对任何具体的节电比例作出承诺，示意表里的数字不能被理解为九游会的运行结果。
读监控时，几个不该马上下的结论
- “利用率 90% 以上，所以这块卡用得很好”：先看吞吐和每任务能耗，再看是否有大量等待数据的时间。
- “降低功率上限就更省电”：能耗下降往往伴随耗时增加，对有截止时间或延迟约束的任务，需要按分布而不是平均值来算。
把 GPU 的账算清，最后落在两个问题上：这个任务值不值得跑，以及用最少的焦耳跑完它之后，玩家的体验有没有受损。利用率只是这两个问题的一个侧面。
