SD-01 · 客户 POC 测试报告

① 场景引入

一、这件事现在是什么样

售前方案与交付工程 · 真实业务触发

启明智驾想扩 40 个节点，先做 8 台的 POC：nccl-tests 总线带宽、IB 带宽、训练吞吐各跑一轮。测试当天跑完，客户的技术负责人当天就要看结论 —— 而往常这种报告要拖两周，商机窗口就是这么没的。

二、痛点 · 每条都有来源

1. POC 测试数据散落在客户侧产出 + 微信传回的截图与日志里 —— 「测试跑完报告拖两周」直接拖死商机
   依据：上架交付全流程：到货验收（SN 码/硬件配置/外观状态/配件清单、各方签字）、上架通电、压测烤机、出具机房测试报告
2. 验收级报告的栏位（测试环境/测试项/基准对比/瓶颈分析/结论）与 MLPerf 等公开基准的对照口径，每次都是现搭 —— 前一个 POC 的模板找不到了
   依据：智算中心验收方案目录：设备清单核对、到货检验、安装检查、系统联调、性能测试、稳定性验证、安全检查、网络连通性验证 —— 交付件的栏位清单
3. 隐性性能问题（NVLink 降速、PCIe带宽瓶颈）在 POC 阶段不查出来，就会在交付验收阶段变成扯皮 —— 「隐性降速不中断任务最难查」
   依据：大规模GPU 集群运维实践：Xid 79 掉卡（需换卡）、Xid 48/63/94 不可纠正 ECC、Xid 31 多为客户代码问题；隐性降速

（PCIe 降速、GPU 降频）不中断任务最难查 —— 实测 PSU 问题导致 SM Clock 从 2GHz 掉到 500MHz、性能降至 1/4而监控无感4中小企业售前与交付一两个人挑全流程，POC 支持挤在商机中间的缝隙里 —— 没有专职方案经理，报告质量全看加班依据 · 上架交付全流程：到货验收（SN 码/硬件配置/外观状态/配件清单、各方签字）、上架通电、压测烤机、出具机房测试报告

三、换个做法之后

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

✕ 现在的做法

• POC 测试数据散落在客户侧产出 + 微信传回的截图与日志里 —— 「测试跑完报告拖两周」直接拖死商机验收级报告的栏位（测试环境/测试项/基准对比/瓶颈分析/结论）与 MLPerf 等公开基准的对照口径，每次都是现搭—— 前一个 POC 的模板找不到了隐性性能问题（NVLink 降速、PCIe 带宽瓶颈）在 POC 阶段不查出来，就会在交付验收阶段变成扯皮 —— 「隐性降速不中断任务最难查」中小企业售前与交付一两个人挑全流程，POC 支持挤在商机中间的缝隙里 —— 没有专职方案经理，报告质量全看加班

✓ 交给 Agent 之后

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

四、场景闭环

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

1. 数据核验 · 测试输出是不是完整可信逐项检查测试输出：轮次是否齐全、结果是否离散度过大、环境信息是否记录完整 —— 不可信的数据不出报告
2. 基准对照 · 与自家历史与公开基准对标总线带宽/IB 带宽/训练吞吐逐项对照启明现有集群与公开基准 —— 差距逐项量化
3. 瓶颈定位 · 慢在哪、为什么逐节点下钻：发现某台机器

NVLink 降速 —— 定位到线缆与拓扑，给出复测建议第 4 步代表性声明 · 哪些数据不能外推8 台 POC 对 40 台规模的扩展性声明：哪些结论可外推、哪些要留到交付验收再验 —— 把丑话说在前面第 5 步成稿 · 验收级 POC 报告客户技术负责人直接可用：环境/数据/对照/瓶颈/结论与商务建议，签批栏齐备

要准备什么：nccl-tests / ib_write_bw 原始输出（终端日志/截图）POC 的原始证据POC 环境说明（8 台机器配置/拓扑/软件栈）数据代表什么的前提自家历史基准（启明现有 90 台集群的同期数据）增量对比的参照系客户提供的基线要求（启明智驾的性能预期）过不过线的判定标准

为什么这个场景值得做

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

最大差异点：与「性能测试工具」的区别：工具跑出数字，本场景把数字变成甲方技术负责人能直接用的验收级报告—— 含与历史基线（自家与公开基准）的对照、瓶颈定位、以及「哪些数据因环境限制不具代表性」的诚实声明。评分口径：痛感看「这事没做好谁会生气、生气到什么程度」；

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

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

五、会产出什么

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

• 正式件本体：POC测试报告_启明智驾.xlsx 正式件 · 验收级 · 签批栏
• 可派发清单：异常与复测清单.xlsx 可派发 · 逐项带定位与建议动作

这套东西不承诺什么：不替客户下「验收通过」的结论（验收是甲乙双方签字动作，报告只呈现数据与差距）。测试环境与生产环境的差异如实声明 —— POC 数据不冒充生产承诺。商务建议栏只列数据支撑的选项，报价与承诺是销售的事。

② Live Demo（演示逐步）

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

案例设定：云枢智算数据服务有限公司（虚构 · 河北张家口 · 186 人）8 月 27 日，启明智驾 8 台 POC 样机测试当天跑完。启明现用本中心 50 节点 H800 集群训练自动驾驶模型，计划再扩 40 节点，先以 8 台样机做 POC：nccl-tests 总线带宽、ib_write_bw、矩阵乘吞吐、Llama-7B 训练 MFU 各跑一轮。客户技术负责人当天就要看结论 —— 而去年 9 月另一家客户的 POC 里，一台 NVLink 降速的样机没查出来，交付验收扯皮 2 个月、保证金暂扣 60 万、尾款拖了一个季度。这次的报告必须当天成稿，且逐台查透。

输入素材5 份（环境说明 + 三类原始输出 + 基线与去年教训）逐机检查8 台 × 4 项，抓出 POC-03 NVLink 降速（x1 而非 x4）数据影响POC 数据整体低估约 6%（MFU 44.2% vs 剔除异常 46.9%）结论暂缓终版 · 换线缆复测后再出验收级报告

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

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

• 01_POC环境说明_8台样机.xlsx 8 台 POC 样机的配置与软件栈说明。启明现用本中心 50 节点训练自动驾驶模型，计划扩40 节点，先 8 台 POC；参考集群为启明在用 90 台（本中心 50 节点 + 客户自带 40 台）交付工程师李岩整理 · POC 专用
• 02_nccl-tests总线带宽_逐机原始输出.xlsx nccl-tests all_reduce 总线带宽（busbw）逐机三轮原始输出，参考值 415 GB/s取自启明在用 90 台集群同期测试均值客户侧测试工程师导出、微信传回，李岩汇总 · 以往没人逐台看这张表
• 03_IB带宽与单卡算力_逐机输出.xlsx ib_write_bw 逐机实测（参考值 49.0 GB/s，NDR 400G 线速）与单卡矩阵乘 FP16 吞吐（峰值 989 TFLOPS）—— 用于排除网络侧与计算侧客户侧测试工程师导出 · 微信传回
• 04_Llama7B训练MFU_逐机记录.xlsx Llama-7B 训练 POC 的逐机记录：并行配置 DP64（8 机×8 卡），基线要求 MFU ≥ 45.0%（启明技术负责人邮件口径，8 台整体）李岩按逐机口径记录 · 以往的 POC 只记一个总数
• 05_客户基线要求与去年POC教训.xlsx 启明智驾的四项基线要求 + 去年 9 月另一客户 POC 事件的复盘纪要（含 60 万保证金与 0.2 万线缆备件）售前共享盘 · 去年的复盘纪要压在文件夹最底层

注意标橙色那一份 —— 02_nccl-tests总线带宽_逐机原始输出.xlsx。它客户侧测试工程师导出、微信传回，李岩汇总 · 以往没人逐台看这张表，平时压根不在核对范围里。这个场景的价值，很大一部分就来自把它读进来。

提示词就说这么几句

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

启明的 POC 测试跑完了，nccl-tests、IB 带宽和训练吞吐的原始输出都在，8 台机器的配置说明也在这。 帮我出验收级报告，逐台机器都要查一遍——上次有一台 NVLink 降速的没查出来，别再犯。 哪些数据能代表 40 台规模、哪些不能，说清楚。结论建议栏留给我们自己写。

POC 报告的栏位标准与基准对照口径已内置，客户只需提供原始测试输出与环境说明。

触发事情是这么来的

商机窗口期里，报告拖两周等于把窗口让出去

启明智驾现用本中心 50 节点训练自动驾驶模型，计划再扩 40 节点，先以 8 台样机做 POC：nccl-tests 总线带宽、

ib_write_bw、矩阵乘吞吐、Llama-7B 训练 MFU 各跑一轮。8 月 27 日测试当天跑完，客户技术负责人当天就要看结论—— 而往常这种报告要拖两周。更要紧的是：去年 9 月另一家客户的 POC 里有一台 NVLink 降速没查出来，交付验收扯了 2 个月皮、保证金暂扣 60 万、尾款拖了一个季度。这次 8 台每台都得查。

第 1 步 · 数据核验 · 测试输出完整可信才出报告

轮次、离散度、环境信息逐项过一遍

这一步的看点 · 排除性结论补测可以排除 —— nccl 三轮 × 8 台齐全，轮次间离散度最大 1.8%（POC-03 轮次间），其余 7 台均小于 0.5%，数据可信度足够出报告。不用等客户再跑一轮，当天成稿的前提在这一步就锁定了。

第 2 步 · 基准对照 · 8 台均值口径先过一遍

对照启明在用 90 台集群基线与客户要求

第 3 步 · 逐节点下钻 · 8 台 × 4 项一台台对

这是去年 POC 没做的一步

这一步的看点 · 从历史里想起了公司踩过的坑去年 9 月另一家客户的 POC：同样是一台 NVLink 跑在 x1 而不是 x4，当时没做逐台下钻、没查出来，客户把 POC数据当生产预期，交付验收时性能对不上 —— 扯皮 2 个月、性能保证金暂扣 60 万、尾款拖了一个季度。这次逐台下钻把同款问题当场抓出来：POC-03 的 busbw 只有参考值的 26.3%，与 x1/x4 的理论比例 25% 吻合（实测 26.3%，含链路层波动）。这个发现不靠碰运气 —— 8 台 × 4 项每个格子都过了一遍。

第 4 步 · 排除与定位 · 问题锁定在一根线缆

四个嫌疑方向排除三个，整改动作跟着定位走

这一步的看点 · 排除性结论「驱动与软件栈问题可以排除 —— 8 台机器同一镜像，仅 3号机异常；问题锁定在 3 号机的物理链路」。复测范围从「整机返厂排查」缩小到「换一根线缆重跑一轮」—— 客户侧配合项也只需保留 3 号机一个机位，报告里的整改建议精确到这一根线缆（备件 0.2 万，与去年整改同款）。

第 5 步 · 代表性声明 · 哪些数据不能外推到 40 台

8 台 POC 到 40 台规模的边界，把丑话说在前面

这一步的看点 · 把技术动作翻译成钱「POC 阶段换线缆复测的代价是 1 个工作日、备件 0.2 万；交付验收阶段才发现的代价是：40 台规模性能争议 + 保证金暂扣 60 万 +尾款延期一个季度 —— 去年那家客户的现金流占用就是 60 万」。报告里专门留一页给销售总监：复测 1 个工作日 vs60 万现金流占用，这笔账五分钟就能看完。

第 6 步 · 成稿 · 验收级 POC 报告

客户技术负责人直接可用，签批栏齐备

这一步的看点 · 该拦的地方拦住了报告结论：「本版数据不建议作为商务报价的性能依据 —— POC-03NVLink 异常已定位，建议更换线缆后复测；当前数据整体低估约 6%」。带着已知缺陷的数据去报价，就是把谈判筹码送给对方 —— 客户拿 44.2% 的 MFU 压价，而剔除异常机的真实水平是 46.9%。

这份报告现在还不能以终版出3： 号样机 NVLink 异常虽已定位到线缆，但换线复测未完成，当前数据整体低估约 6%—— MFU 整体口径 44.2% 会误判「不达标」，而剔除异常机后的真实水平 46.9% 是达标的。带着这个已知缺陷出终版，要么低估自己被压价，要么日后性能对不上扯皮 —— 去年那家客户 60 万保证金占用就是下场。方案一：先复测再出终版 —— 更换 POC-03 NVLink 线缆（备件 0.2 万）、复测窗口 1 个工作日，复测后四项全部以干净数据出验收级终版（预期 MFU 整体口径回到约 46.9%）—— 报价以复测版为性能依据，多花的代价是报告晚一个工作日。方案二：今天先出「异常声明版」—— 客户版如实标注 POC-03 异常、定位与整改时间表（展示的是检查能力，不藏着掖

着），MFU 以「剔除异常机 46.9% / 含异常机 44.2%」双口径并列；内部版给销售总监附一页账：复测 1 个工作日 vs交付后才发现的 60 万保证金占用 —— 报价口径等复测版再锁。

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

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

• ✓ 验收级报告当天成稿 —— 商机窗口期内交付专业度，这本身就是竞争力
• ✓ 逐节点下钻的检查规则固化了 ——

NVLink 降速这类隐性缺陷在 POC 阶段就现形✓「哪些数据不可外推」的代表性声明成为报告标配 —— 交付验收的预期管理从 POC 就开始✓上一个客户的教训变成了本次的检查项 —— 每做一次 POC，检查规则就厚一层

追问现场可能被问到的

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

• 报告能不能写「性能承诺」？ 不能。报告写的是「本环境下实测 + 与基准的差距 + 扩展性声明」，承诺是合同条款的事 —— POC 数据当承诺用，上一个客户的扯皮就是下场。
• 复测要客户配合怎么办？ 异常清单里写明了定位与建议动作，客户侧配合项也列了 —— 这份清单本身就能直接发给客户技术负责人。
• 历史基准数据不全的机型呢？ 公开基准（如 MLPerf）作参照并标注来源；自家无基线的项目在报告里标「首次建立基线」—— 这也是资产。

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

1. Skill 能力包

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

客户 POC 测试报告 —— 测试跑完那天出报告，而不是跑完两周后 · Skill

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

版本 v1.0

poc-test-report.zip

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

包内结构

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

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

2. 原始素材

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

📁SD-01 · 演示素材

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

共 5 份

• 01_POC环境说明_8台样机.xlsx 8 台 POC 样机的配置与软件栈说明。启明现用本中心 50 节点训练自动驾驶模型，计划扩 40 节点，先 8 台 POC；参考集群为启明在用 90 台（本中心 50 节点 + 客户自带 40 台）
• 02_nccl-tests总线带宽_逐机原始输出.xlsx nccl-tests all_reduce 总线带宽（busbw）逐机三轮原始输出，参考值 415 GB/s 取自启明在用90 台集群同期测试均值
• 03_IB带宽与单卡算力_逐机输出.xlsx ib_write_bw 逐机实测（参考值 49.0 GB/s，NDR400G 线速）与单卡矩阵乘 FP16 吞吐（峰值 989 TFLOPS）—— 用于排除网络侧与计算侧
• 04_Llama7B训练MFU_逐机记录.xlsx Llama-7B 训练 POC 的逐机记录：并行配置 DP64（8 机×8 卡），基线要求 MFU ≥ 45.0%（启明技术负责人邮件口径，8 台整体）
• 05_客户基线要求与去年POC教训.xlsx 启明智驾的四项基线要求 + 去年 9 月另一客户 POC 事件的复盘纪要（含 60 万保证金与 0.2 万线缆备件）

怎么用

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

3. 提示词卡片

启明的 POC 测试跑完了，nccl-tests、IB 带宽和训练吞吐的原始输出都在，8 台机器的配置说明也在这。 帮我出验收级报告，逐台机器都要查一遍——上次有一台 NVLink 降速的没查出来，别再犯。 哪些数据能代表 40 台规模、哪些不能，说清楚。结论建议栏留给我们自己写。

为什么这么短就够了：POC 报告的栏位标准与基准对照口径已内置，客户只需提供原始测试输出与环境说明。

换成你自己的业务：把素材换成你手上的真实文件即可。导入 Skill 之后，

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

自己组织输入的三步法

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

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

4. 预期输出

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

📋正式交付物

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

共 2 份

• SD-01_POC测试报告_启明智驾.xlsx 正式件 · 验收级 · 签批栏
• SD-01_异常与复测清单.xlsx 可派发 · 逐项带定位与建议动作

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

输入清单：nccl-tests / ib_write_bw 原始输出（终端日志/截图）POC 的原始证据POC 环境说明（8 台机器配置/拓扑/软件栈）数据代表什么的前提自家历史基准（启明现有 90 台集群的同期数据）增量对比的参照系客户提供的基线要求（启明智驾的性能预期）过不过线的判定标准

人工边界：不替客户下「验收通过」的结论（验收是甲乙双方签字动作，报告只呈现数据与差距）。测试环境与生产环境的差异如实声明 —— POC 数据不冒充生产承诺。商务建议栏只列数据支撑的选项，报价与承诺是销售的事。

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

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

售前方案与交付工程 · 产出即下一步输入

• SD-02 · 机柜上架率报表与扩容测算：老板拍脑袋扩容的年代，该有个测算底稿了

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

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