GPU 利用率很高，为什么用户仍然觉得慢？Token 吞吐翻倍，为什么业务效果没有提升？问题往往不在指标算错了，而在于我们拿一个设备层指标，替代了整条算力价值链的结果。本文尝试给出一套产品经理能直接使用的四层指标框架：基础设施、计算资源、推理服务和业务结果。

一、一个看起来很漂亮、实际上很危险的数字

假设你负责一套企业内部的大模型平台。

运维看板显示，GPU 利用率长期在 90% 左右。这个数字很漂亮，至少说明昂贵的卡没有闲着。可另一边，客服团队不断反馈首字等待时间太长；知识助手在高峰期频繁超时；财务也在追问，算力投入增加后，到底多解决了多少问题。

三方说的都是真话。

GPU 的确很忙，用户也的确在等，业务结果同样可能没有变化。矛盾来自一个常见误区：我们用“设备有没有在工作”，代替了“系统有没有交付结果”。

NVIDIA 对 GPU utilization 的定义很直接：在采样周期内，至少有一个计算任务正在 GPU 上执行的时间占比[3]。它能说明 GPU 忙不忙，却不能单独说明这段时间里有多少计算单元真正发挥了效率，更不能说明用户得到了一次快速、正确、有价值的回答。NVIDIA 的 DCGM 文档也明确提醒，SM 处于 active 状态时，warp 可能只是在等待内存请求；较高的 SM Activity 是有效利用 GPU 的必要条件，但不是充分条件[4]。

这就像餐厅后厨一直在冒烟。冒烟说明厨师没闲着，却不代表顾客出餐快，也不代表菜做对了，更不代表这家店赚钱。

所以，GPU 利用率可以是重要的运营指标，但不适合成为算力平台的北极星指标。

二、算力不是一台设备，而是一条转化链

一篇关于企业本地 Token 平台的报道提出过“FLOPS→Token→Agent→业务价值”的思路[8]。在梳理算力平台指标时，我沿着这个方向继续向前追了一层，把它整理成一条更完整的转化链：

电力和机房条件 → 可用计算资源 → 可消费的推理服务 → 完成的业务任务。

任何一段转化效率低，前面的投入都会在后面打折。

第一段，是把电力、制冷、网络和硬件转化为稳定可用的计算资源。

AI 基础设施已经很难再被理解成“找个机房，把服务器放进去”。以 NVIDIA 官方文档中的 GB200 NVL72 为例，一套机架包含 72 块 GPU、NVLink 交换系统、独立的供电组件和液冷歧管，整机架功耗约 120kW[2]。高功率密度直接推高了供配电和冷却压力；机架级通信和集群扩展，又对高速网络提出了更高要求。电、冷、网不再只是机房团队的后台事务，而会共同决定算力是否真的可用。

国际能源署在《Energy and AI》的基准情景中预计，全球数据中心用电量将在 2030 年达到约 945TWh，约为 2024 年的两倍。报告同时指出，冷却等基础设施也会贡献一部分新增用电[1]。算力竞争首先是一场资源约束下的系统工程：卡买得到，不等于电接得进来；电接得进来，也不等于热排得出去。

第二段，是把计算资源转化为 Token 和稳定的模型服务。

同样的 GPU、同样的模型，采用不同的显存管理、批处理和调度策略，实际吞吐可能完全不同。大模型推理会为历史上下文保存 KV Cache。它减少了重复计算，却会随着上下文和并发增长持续占用显存。如果显存被碎片化或分配不合理，GPU 看起来很忙，真正能同时服务的请求却上不去。

2023 年的 vLLM 论文提出 PagedAttention，用类似操作系统分页的方式管理 KV Cache。在论文测试的特定模型和工作负载下，采用 PagedAttention、调度等设计的 vLLM 系统，相较 FasterTransformer 和 Orca 实现了 2～4 倍吞吐提升，并保持相近延迟[7]。这个案例说明，硬件没有变化，算力的可交付产出仍会因为软件栈而出现明显差距。

第三段，是把模型服务转化为用户可感知的体验。

对用户来说，“每秒总共生成多少 Token”仍然过于抽象。用户更容易感知两件事：点下发送后多久看到第一个字，以及开始输出后是否足够流畅。工程上通常用 TTFT（首 Token 延迟）和 TPOT（每个输出 Token 的平均耗时）衡量[5]。

这两个指标不能互相替代。长文档问答的输入很长，首 Token 可能慢，但生成阶段很流畅；短对话可能很快出现第一个字，后面却断断续续。如果平台只追求总吞吐，常见做法是把更多请求塞进批次，这可能让 GPU 更“饱”，但也可能增加单个用户的等待时间。

第四段，才是业务真正买单的结果。

一套客服模型生成了更多 Token，不代表它解决了更多问题；一个代码 Agent 运行了更多步骤，也不代表它交付了更多可合并的代码。Token 是产出物，也是成本载体，但它还不是最终价值。

如果把前三段看成生产线，业务结果才是合格品。产品经理真正要追问的是：这些算力最终完成了多少符合质量门槛的任务？

三、四层指标树：每一层只回答它该回答的问题

基于上面的转化链，我会把算力平台指标拆成四层。

1. 基础设施层：系统能不能稳定地跑

这一层关注的是供电、制冷、网络和硬件健康。典型指标包括：

• 可供电容量与实际功耗
• PUE 或更细的制冷能耗
• 机柜温度、液冷流量与告警
• GPU、交换机和链路故障率
• 集群可用性、故障恢复时间

它回答的是“算力底座是否稳定”。如果这一层出问题，上层所有指标都没有意义。但 PUE 很低，也不代表模型服务一定快；基础设施效率只能证明底座本身做得不错。

2. 计算资源层：硬件有没有被有效使用

这一层不能只放一个 GPU 利用率。至少还需要结合：

• SM Activity 与 Tensor Core 活跃度
• 显存占用、KV Cache 占用与缓存命中
• 显存带宽和互联带宽
• 排队时间、任务启动时间
• 单卡或单节点的有效 Token 吞吐

这些指标用来定位瓶颈究竟在计算、显存、网络还是调度。例如，对于预期大量使用 Tensor Core 的推理负载，如果 GPU 利用率很高、Tensor Core 活跃度却不高，原因可能是数据搬运、流水线等待、算子类型或精度路径；显存几乎占满，也可能只是缓存和碎片很多，不等于产出高。

3. 推理服务层：用户拿到的服务好不好

这一层应以服务等级目标（SLO）为中心，而不是追求孤立的峰值跑分。至少要看：

• TTFT 的 P50、P95、P99
• TPOT 或输出速度
• 在延迟目标内可承载的并发数
• 请求成功率、超时率与重试率
• 不同模型和上下文长度下的输入 Token 成本、输出 Token 成本
• 缓存命中后的成本，以及统一口径下的请求全成本

这里有一个很重要的产品原则：吞吐必须和服务门槛绑定。

如果一套系统通过延长用户等待时间换来了更高吞吐，这不是免费收益，只是把基础设施成本转嫁成了用户时间。NVIDIA 的 AIPerf 把“满足全部 SLO 的每秒请求数”称为 Goodput[6]。这个词比 Throughput 多问了一句：完成的请求里，有多少真正达到了可接受的体验？

所以，更有意义的问题应该是：“在首字延迟不超过 2 秒、超时率低于 1% 的条件下，系统最多能稳定服务多少请求？”这里的 2 秒和 1% 只是示例，具体阈值应由业务场景决定。实时客服、代码补全、离线报告生成，不应该共用同一套 SLO。

4. 业务结果层：这笔算力投入值不值

这一层需要业务指标，而不是继续堆技术指标。不同产品的结果定义并不相同：

• 智能客服：一次解决率、人工转接率、平均处理时长
• 企业知识助手：答案采纳率、事实正确率、任务完成率
• 代码 Agent：通过测试的任务数、可合并代码比例、人工返工时间
• 营销内容生成：合格稿件率、发布率、转化提升

受“单位有效产出成本”观点启发[9]，这里可以把口径再向基础设施侧扩展：

单位有效产出成本 = 一段周期内的全链路成本 ÷ 达到质量门槛的业务结果数。

原观点关注 Token 成本与业务结果的联动，本文进一步把分子扩展到全链路成本：它不只是模型 API 账单或 GPU 折旧，还应包含电力与制冷、带宽、运维，以及失败重试带来的额外消耗。“有效产出”也不能直接用 Token 数量代替，而要预先定义质量门槛。

这个指标只有在同一业务场景、统一质量门槛和一致成本分摊规则下才适合横向比较。否则，任务结构发生变化，数字也会跟着失真。

举一个纯粹用于说明口径的假设：一套客服系统每月成本下降 20%，但人工转接量上升 40%，单位有效产出成本很可能反而更高。反过来，如果一次复杂任务多消耗了 30% Token，却显著降低人工返工，它仍可能是更好的产品方案。这些比例不是行业基准，也不是实际客户数据。

这能避免团队把“降本”做成“降配”。

四、产品经理最容易踩的三个坑

坑一：把设备指标直接拿给业务负责人

GPU 利用率、显存带宽、缓存命中率都很重要，但业务负责人很难据此做决策。产品经理需要完成一次翻译：这个指标变化，会让多少用户更快完成任务，会改变多少成本，会带来什么风险。

如果翻译不出来，它更适合留在诊断看板，而不是经营看板。

坑二：只看平均值，不看尾部体验

平均首字延迟 1 秒，可能掩盖少量用户等待 10 秒以上。对客服、搜索和代码补全这类高频场景，P95、P99 往往比平均值更接近真实口碑。

同样，月度可用性很高，也可能掩盖每天高峰期的集中超时。指标必须按场景、租户、模型和时间段下钻，否则问题会被平均掉。

坑三：先建大而全的驾驶舱，再想如何行动

看板不是终点。每一个核心指标都应该对应一个动作：延迟升高后是扩容、限流，还是切换模型？成本异常后是检查重试、缓存，还是调整路由？任务成功率下降后由谁判断是模型、知识库还是业务流程的问题？

没有动作和责任人的指标，只会制造一种“系统已被管理”的错觉。

五、一套最小可用的落地方法

如果团队刚开始建设算力平台，不必一上来做完整的全栈观测。可以先跑通一个最小闭环。

第一步，选一个高频且结果可判断的业务场景。比如客服问答，不要同时覆盖十几类 AI 应用。

第二步，为每次请求补齐关联信息：来自哪个团队、哪个场景、调用什么模型、输入输出 Token、TTFT、TPOT、状态码和本次成本。

第三步，增加一个业务结果标签。哪怕初期依赖抽样人工标注，也要判断这次任务是否真正完成。没有结果标签，就无法把算力和价值接起来。

第四步，建立一张贯穿四层的看板，但每层只保留少数指标：

• 基础设施层：可用性、功耗、故障
• 计算资源层：GPU 活跃度、显存、有效吞吐
• 推理服务层：TTFT、TPOT、成功率、SLO 内并发
• 业务结果层：任务成功率、单位有效产出成本

第五步，每周只追一个最大的损耗点。可能是重复请求，可能是超长上下文，也可能是模型太大、调度不合理，甚至是原本就不该使用大模型的需求。优化后同时观察成本、体验和结果，避免按下葫芦浮起瓢。

这套方法的关键不在看板，而在于把“观测—定位—策略—复盘”跑成一个持续循环。

六、结语：算力平台交付的不是忙碌，而是结果

GPU 利用率当然要看。就像工厂要看设备开机率，餐厅要看翻台率，任何昂贵资产都不该长期闲置。

但一个指标越靠近设备，就越难代表最终价值。

对算力平台而言，从电力和制冷，到 GPU 和高速网络，再到推理引擎、模型服务和业务应用，每一层都有自己的局部最优。产品经理的价值，是把这些局部指标串成一条完整的因果链，并确保优化没有在层与层之间转嫁问题。

下一次看到“GPU 利用率达到 90%”时，不妨继续问三句：

1. 用户等了多久？
2. 任务完成了吗？
3. 每完成一次合格任务，我们到底花了多少钱？

能回答这三个问题，算力才真正从一堆昂贵设备，变成了一项可运营、可衡量的产品能力。