GP-03 · GPU 利用率日报

① 场景引入

一、这件事现在是什么样

智算集群运维（GPU 与高速网络） · 真实业务触发

每天早上客户经理要一份利用率概况发给重点客户；8 月 21 日星澜科技反馈「训练变慢」，但调度平台和 DCGM 的利用率曲线一切正常 —— 利用率正常的集群和健康的集群是两回事。

二、痛点 · 每条都有来源

1利用率 ≠ 健康：显存碎片、PCIe 带宽瓶颈会拖垮性能而利用率假高；实测 PSU 问题导致 SM Clock 从 2GHz 掉到

500MHz、性能降至 1/4 而监控无感依据 · 大规模 GPU 集群运维实践：Xid 79 掉卡（需换卡）、Xid 48/63/94 不可纠正 ECC、Xid 31 多为客户代码问题；隐性降速（PCIe 降速、GPU 降频）不中断任务最难查 —— 实测 PSU 问题导致SM Clock 从 2GHz 掉到 500MHz、性能降至 1/4 而监控无感2客户只认自己的训练速度与成本，不认你的利用率报表—— 千卡训练曾中断在65% 进度，「任务白跑」的愤怒点不在机器坏了依据 · 千卡集群训练任务曾因故障中断在 65%进度处 —— 客户对故障的愤怒点在「任务白跑」，不在「机器坏了」3行业 GPU 平均利用率不足 30% 的背景下，运营侧把「利用率数字」当 KPI 汇报，而集群侧知道这个数字口径混乱 —— 两边的口径差距迟早要在客户面前穿帮依据· 腾讯云解决方案总经理在 MWC26 上海披露：国内智算中心 GPU 平均利用率不足 30%；信通院 2025 年统计国内智算用算占比仅 36.8% —— 利用率是行业级痛点4SM Clock 降频、NVLink 降速这类隐性劣化不中断任务、不触发告警—— 等客户发现变慢再排查，证据已经没了依据 · 利用率 ≠ 健康：显存碎片、PCIe 带宽瓶颈会拖垮性能而利用率假高 —— 只看利用率的日报会漏掉真正的问题

三、换个做法之后

变化不在「快」，在「参与的角色」和「覆盖的范围」

✕ 现在的做法

• 利用率 ≠ 健康：显存碎片、PCIe 带宽瓶颈会拖垮性能而利用率假高；实测 PSU 问题导致 SM Clock 从2GHz 掉到 500MHz、性能降至 1/4 而监控无感客户只认自己的训练速度与成本，不认你的利用率报表 —— 千卡训练曾中断在65% 进度，「任务白跑」的愤怒点不在机器坏了行业 GPU 平均利用率不足 30% 的背景下，运营侧把「利用率数字」当 KPI 汇报，而集群侧知道这个数字口径混乱 —— 两边的口径差距迟早要在客户面前穿帮SM Clock 降频、

NVLink 降速这类隐性劣化不中断任务、不触发告警 —— 等客户发现变慢再排查，证据已经没了

✓ 交给 Agent 之后

• 多来源文件一次读入，先做口径与完整性校验，再开始算
• 每条结论绑定来源文件、字段或条号，可以被审
• 产出是企业真会流转的正式件（带签批栏），不是一张展示用的表
• 该拦的地方给出「现在还不能提交」，并给不用干等的替代方案

四、场景闭环

5 步 · 每一步的产出都是下一步的输入

1. 口径核算 · 当日卡时利用率自营 3,680 卡口径：实际消耗卡时 ÷（在册卡×自然小时）；与调度平台口径并列展示，差异注明原因
2. 三线交叉 · 利用率 × SM Clock × 温度逐节点交叉扫描：利用率高且 Clock 正常（真健康）、利用率高但 Clock 受限（假高）、利用率低（闲置）三分类
3. 异常任务定位 · 谁在降速跑假高节点上的任务逐个点名：任务名、客户、卡时消耗、估算性能损失 —— 给客户经理一份能直接解释的清单
4. 根因初判 · 降速从哪来温度墙（环境）/功耗墙（供电）/驱动（软件）三类初步归因，指向环境侧的直接关联动环数据（与 FA-01的空调记录交叉）
5. 成稿 · 利用率日报与异常清单客户版（口径+异常说明）与运营版（闲置与假高分布）双版，签批栏齐备

要准备什么：DCGM 指标导出（GR_ENGINE_ACTIVE / SM Clock / clock throttle / 温度）利用率与降频的交叉口径调度平台任务级卡时消耗（当日）哪些任务在哪些节点上烧卡时客户反馈记录（群消息/工单）客户感知的「变慢」时间点历史正常基线（上月同期）判断异常的参照系

为什么这个场景值得做

优先级评分：痛感 4 × AI 适配 4 ÷ 落地难度 3 = 6.4

最大差异点：与调度平台自带报表的区别：平台报表看的是「资源被占用了多少」，本场景多看一层「占用了却在降速跑」—— 利用率与 SM Clock、温度墙、NVLink 宽度三线交叉，假高一眼现形。

评分口径：痛感看「这事没做好谁会生气、生气到什么程度」；

AI 适配看「输入是否非结构化、是否要跨部门取数、错了能不能当场看出来」；

落地难度是分母 —— 需要客户先做数据治理的场景，分数会被压得很低。

五、会产出什么

判断标准只有一个：这份东西能不能直接进企业的流程

• 正式件本体：GPU利用率日报.xlsx 正式件 · 客户版与运营版 · 签批栏
• 可派发清单：异常任务清单.xlsx 可派发 · 每条带节点/客户/性能损失估算

这套东西不承诺什么：不替客户调整任务、不做调度决策。日报只点名异常与证据，处置是集群工程师的判断。利用率口径（卡时/在册卡×自然小时）与调度平台口径的差异如实标注，不硬凑对齐。不承诺「利用率提升」。

② Live Demo（演示逐步）

演示模式 · 可视化预演 本页展示的是「应该怎么跑、每一步看什么、交付什么」，用的是真实业务格式的脱敏构造数据， 不宣称已接入客户生产系统，也不承诺任何效率提升百分比。

案例设定：云枢智算数据服务有限公司（虚构 · 河北张家口 · 186 人）4 号楼，2026 年 8 月 22 日早晨。客户经理吴敏每天早上要一份利用率概况发重点客户；今天这份格外难写 —— 8 月 21 日星澜科技反馈「训练变慢」，今早又追问「你们的利用率报表一切正常，为什么任务慢了 63%」。调度平台和 DCGM 的利用率曲线当天确实全绿（星澜任务89%）—— 利用率正常的集群和健康的集群是两回事。本演示出 8 月 21 日当天的利用率日报：利用率 × SM Clock ×温度三线交叉，把「假高」挑出来，把缩水卡时的账主动算给客户看。

输入素材5 份（DCGM / 调度卡时 / 客户群消息 / 7 月基线 / 巡检动环摘录）当日口径15,823 卡时 ÷ 88,320 = 17.9% ·假高 5 节点缩水卡时1,968 卡时 ≈ 2.1 万（受影响 8.2 小时）结论暂缓只发总数 · 客户版/运营版分开的两个方案

输入算力基础设施企业手上能拿到的东西

不需要整理格式、不需要改文件名 · 直接拖进对话框

• 01_DCGM指标导出_8月21日.xlsx DCGM 三线导出（8/21 当日）：A12 区各节点利用率、SM Clock、进风温度 —— 假高就是这么现形的集群监控后台自动记录 · 利用率曲线平时只有运营看
• 02_调度平台任务级卡时_8月21日.xlsx 调度平台当日卡时消耗（按客户任务）—— 哪些任务在哪些节点上烧卡时调度平台导出 · 与 OP-02 闲置盘点同一口径
• 03_客户反馈与群消息.txt 星澜客户群与内部群消息（8/21-8/22），共 7 段 —— 客户感知的「变慢」时间点与质问原文客户经理手机导出 · 「报表全绿为什么任务慢」就问在这里
• 04_上月同期DCGM基线_7月.xlsx A12 区 7 月同期 DCGM 基线（30天）—— 判断「下探」是不是异常的参照系，降频判读需要至少 30 天基线，这份导出平时没人看集群监控后台历史数据 · 按月归档、从未被翻过
• 05_巡检与动环摘录_8月19至21日.xlsx 巡检日报（FA-01）与动环告警中与 A12 相关的摘录—— 环境侧的因果链起点值守侧资料 · 与集群侧数据平时从不放在一张表里

注意标橙色那一份 —— 04_上月同期

DCGM基线_7月.xlsx。它集群监控后台历史数据 · 按月归档、从未被翻过，平时压根不在核对范围里。这个场景的价值，很大一部分就来自把它读进来。

提示词就说这么几句

没有模板、没有表单 · 专业规则由 Skill 兜底

这是今天的 DCGM 导出和调度平台的卡时消耗，还有客户群里星澜说训练变慢的聊天记录。 帮我出今天的利用率日报。利用率之外，重点看有没有「利用率很高但 SM Clock 被压着」的节点，那种是假健康。哪些任务在降速跑、损失多少卡时帮我点出来。给客户的版本口语一点，别用我们的内部术语。

三线交叉（利用率/Clock/温度）的判读规则与卡时折算口径已内置，客户只需提供当日导出。

触发事情是这么来的

利用率正常的集群和健康的集群是两回事

8 月 22 日早晨，吴敏的日报要回答星澜的质问：「报表全绿，任务为什么慢了 63%」。答案藏在三张平时没人一起看的表里：调度平台的利用率（89%，全绿）、DCGM 的 SM Clock（8 月 19 日起就在下探）、巡检台账里的空调报修记录（8 月 19 日 14:35）。单看任何一个数，这一天都「正常」。

第 1 步 · 口径核算 · 当日卡时利用率

自营 3,680 卡口径，与调度平台口径并列展示

这一步的看点 · 从历史里想起了公司踩过的坑7 月经营例会把「利用率」当KPI 汇报过一回，集群侧当场质疑口径混乱 —— 运营嘴里的 45.8% 和集群嘴里的 17.9% 差着 2.6 倍，谁也说不服谁。这次的日报把两个口径并列摆出来、差异写明 —— 硬凑一个数，只会在客户面前穿帮。

第 2 步 · 三线交叉 · 利用率 × SM Clock × 温度

满载满频 / 满载降频 / 闲置，三分类一眼现形

这一步的看点 · 排除性结论「任务代码问题可以排除—— 同一任务迁 B 区后 SM Clock 1.98 满频恢复；显存碎片可以排除 —— 利用率与显存占用无异常相关。指向环境温度」—— 客户侧这一轮排查可以免了，星澜王工拿到的日报里就写着这句。

第 3 步 · 缩水卡时 · 降速跑的账主动算给客户

受影响时段 8.2 小时，折 1,968 卡时 ≈ 2.1 万

这一步的看点 · 把技术动作翻译成钱1,968 卡时按满速计费却没跑在满频上，折 2.1 万；其中按 SM Clock 缺口（1.98→1.21GHz，损失约 39%）折算的纯性能损失约 0.5 万 —— 两个数都主动给客户看。这笔账我们比客户先算出来、先摊开，比等客户自己发现来问责便宜得多；星澜年合同 2,340 万（195万 × 12），2.1 万的透明账是续约筹码。

第 4 步 · 根因初判 · 集群指标与巡检台账交叉

DCGM 的下探与 FA-01 的空调异常，两天前就对上了

这一步的看点 · 从历史里想起了公司踩过的坑历史基线显示 A12 区这批节点的 SM Clock 在 8 月 19 日之后普遍下探 —— 与巡检台账（FA-01）里 CRAC-A12-03 多次送风温度异常的时间窗吻合。客户 8 月 21 日才感知变慢，数据 8 月 19 日就在报警 —— 只差有人把两张表放在一起看。

第 5 步 · 成稿 · 客户版与运营版双版

口径透明比数字漂亮重要

这一步的看点 · 该拦的地方拦住了日报结论：「A12区 4 个节点处于温度墙降频运行，建议当日不再向该区调度新任务；空调修复验收前该区为调度禁区 —— 已生成调度建议（人确认后执行）」。调度指令我们不碰，建议必须出：踢错一个在跑任务的节点，损失比漏检更大。

这份日报不能只发一个总数8 月 21 日是事故日：只发「整体 17.9%」会把 A12 区的假高埋掉，只发「星澜 89%」会让客户拿着全绿报表继续质问。但缩水卡时 2.1 万的口径涉及商务 —— 工单（OP-03）用的是 1,248 卡时 ≈ 1.4 万，SLA月报（OP-01）还没出，三个口径同时在客户面前出现就是穿帮现场。方案一：客户版今天 10:30 前发出 —— 含三线交叉结果、A12 异常说明与缩水卡时 2.1 万的主动披露，工单口径 1.4 万的差异来源写明（降频 5.2 小时 vs 可感知 8.2 小时）；运营版同步内部 —— 客户的质问今天就有答案。方案二：客户版只报异常与措施，影响账写一句「将在 9 月 5日 SLA 月报按合同口径统一核算（阶梯口径 9.8 万 / 性能口径 24.5 万，口径待与客户确认）」—— 避免三口径同时上桌，但吴敏须口头先给星澜一个量级预期，别让客户自己把性能口径的账算出来。

之后这一次跑完，公司多了什么

不讲省了多久：讲少了几个隐患、沉淀了什么

• ✓ 「利用率假高」的识别口径固定下来 —— 三线交叉成了每日例行，隐性劣化当天现形
• ✓ 巡检台账（FA-01）与集群指标（GP-03）第一次交叉到一起 —— 环境问题两天就能定位到区，不用等客户投诉
• ✓ 「缩水卡时」的折算口径建立起来了 —— 对客户透明反而是续约筹码
• ✓ 日报的客户版与运营版分离，客户经理拿到的不再是自己看不懂的监控截图

追问现场可能被问到的

答不上来的问题，比答得漂亮的问题更能决定这场演示的结果

• 能不能自动把降速节点踢出调度池？ 不能。调度是生产动作，我们出「建议隔离清单」，执行由集群工程师确认 ——踢错一个在跑任务的节点，损失比漏检更大。
• 利用率数字能对上调度平台的数吗？ 两个口径并列展示并注明差异来源（在册卡定义不同）。硬凑一个数只会在客户面前穿帮，口径透明比数字漂亮重要。
• 历史数据要留多久？ 降频判读需要至少 30 天基线。数据一直在自己手里，这也是为什么这个场景越跑越准。

③ 能力沉淀（Skill / 提示词 / 预期输出 / 人工边界）

1. Skill 能力包

导入之后，同类任务会自动按这套规则走 —— 提示词才能写得那么短

GPU 利用率日报 —— 利用率 93% 的集群正在变慢，这种病监控看不出来 · Skill

SKILL.md 主本 + references（输出骨架 / 判据 / 渲染脚本）· 符合 WorkBuddy Skill 规范

版本 v1.0

gpu-utilization-daily.zip

在 WorkBuddy 里直接上传这个 zip 即可导入

包内结构

• SKILL.md 主本 —— YAML 元信息 + 执行流程 + 硬规则 + 人工边界
• references/output_template.md 输出骨架（sheet 名 / 分区顺序 / 列头）+ 可直接运行的渲染脚本
• references/judgement_rules.md 判据与口径 —— 什么情况算异常、什么情况必须拦住

references 不会一次性全读进来 —— Agent 按需取用。所以 Skill 可以写得很细，不会拖慢每次对话。

2. 原始素材

这些就是算力基础设施企业手上真实能拿到的东西 —— 格式不统一是常态，不是问题

📁GP-03 · 演示素材

脱敏构造数据 · 真实业务格式 · 埋点可核验

共 5 份

• 01_DCGM指标导出_8月21日.xlsx DCGM 三线导出（8/21 当日）：A12 区各节点利用率、SM Clock、进风温度 ——假高就是这么现形的
• 02_调度平台任务级卡时_8月21日.xlsx 调度平台当日卡时消耗（按客户任务）—— 哪些任务在哪些节点上烧卡时
• 03_客户反馈与群消息.txt 星澜客户群与内部群消息（8/21-8/22），共 7 段 —— 客户感知的「变慢」时间点与质问原文
• 04_上月同期DCGM基线_7月.xlsx A12 区 7 月同期 DCGM 基线（30 天）—— 判断「下探」是不是异常的参照系，降频判读需要至少 30 天基线，这份导出平时没人看
• 05_巡检与动环摘录_8月19至21日.xlsx 巡检日报（FA-01）与动环告警中与 A12 相关的摘录 —— 环境侧的因果链起点

怎么用

• 把素材全部拖进 WorkBuddy 对话框（不需要整理格式、不需要改文件名）
• 粘贴下方提示词发送
• 拿到正式件初稿 —— 签批栏留空，推荐意见留空，由你填

3. 提示词卡片

这是今天的 DCGM 导出和调度平台的卡时消耗，还有客户群里星澜说训练变慢的聊天记录。 帮我出今天的利用率日报。利用率之外，重点看有没有「利用率很高但 SM Clock 被压着」的节点，那种是假健康。哪些任务在降速跑、损失多少卡时帮我点出来。给客户的版本口语一点，别用我们的内部术语。

为什么这么短就够了：三线交叉（利用率/Clock/温度）的判读规则与卡时折算口径已内置，客户只需提供当日导出。换成你自己的业务 · 把素材换成你手上的真实文件即可。导入 Skill 之后，

该走几步、什么口径、什么情况必须拦住，Agent 自己知道 —— 你只需要说清这是什么事。

自己组织输入的三步法

• 用自然语言说清核心需求 —— 就按平时跟同事交代活的方式说：什么事、什么文件、什么要求。不用讲究格式。
• 调用 Skill 补齐专业规则 —— 导入本页 Skill 后，流程、口径、硬规则 Agent 自己知道。
• 用「增强提示词」补全遗漏 —— 输入框旁边有增强按钮，把随口说的话补成更完整的表述。

分工：自然语言负责「这是什么事」，Skill 负责「该怎么做」，增强提示词负责「别漏了什么」。

4. 预期输出

不方便现场跑的时候可以直接拿这份给客户看 · 与实跑结果同结构

📋正式交付物

带签批栏 / 冻结首行 / 开筛选 —— 判断标准是「能不能直接进企业的流程」

共 2 份

• GP-03_GPU利用率日报.xlsx 正式件 · 客户版与运营版 · 签批栏
• GP-03_异常任务清单.xlsx 可派发 · 每条带节点/客户/性能损失估算

Skill 里固化了什么：从历史里想起了公司踩过的坑该拦的地方拦住了排除性结论把技术动作翻译成钱

输入清单：DCGM 指标导出（GR_ENGINE_ACTIVE / SM Clock / clock throttle / 温度）利用率与降频的交叉口径调度平台任务级卡时消耗（当日）哪些任务在哪些节点上烧卡时客户反馈记录（群消息/工单）客户感知的「变慢」时间点历史正常基线（上月同期）判断异常的参照系

人工边界：不替客户调整任务、不做调度决策。日报只点名异常与证据，处置是集群工程师的判断。利用率口径（卡时/在册卡×自然小时）与调度平台口径的差异如实标注，不硬凑对齐。不承诺「利用率提升」。

升为客户真实案例还缺什么：客户当前真实输入文件（不要整理过的）岗位现行 SOP 与审批链（金额分档、谁签字）至少一次真实出过问题的案例客户当前正在用的正式输出模板客户确认的阈值口径（多少天算临期、多少金额算大额）

5. 同一角色下的其他场景

智算集群运维（GPU 与高速网络） · 产出即下一步输入

• GP-01 · GPU 故障换卡台账：换了 14 张卡，哪些真坏哪些误换，不该没有人说得清
• GP-02 · 故障 RCA 复盘报告初稿：合同给你的 24 小时，不该用来翻聊天记录

上下游串起来就是完整链路。每一步的产出都是下一步的输入，不用在不同工具之间来回复制粘贴。

场景内容基于 WorkBuddy 产品能力整理，演示中的企业、人物与数据均为虚构，不代表任何客户的实际成效；痛点引用的公开来源已做脱敏处理。网页版由原资料转换，部分演示表格以原文形式展示。