机器人算力PoC怎么做？测试任务、指标与验收清单
机器人算力PoC应使用可复现的代表任务，覆盖数据处理、仿真、训练和推理，并记录吞吐、时延、显存、I/O、多GPU扩展与稳定性。本文提供测试步骤、指标和验收清单。
- Slug
robot-compute-poc-checklist- 更新
- 2026-08-20
- 来源
- 4
- 关系
- 4
机器人算力PoC不是跑一次通用Benchmark，也不是证明硬件能够启动软件。有效PoC应使用项目真实版本和代表任务，覆盖单任务基线、容量扩展、多人并发、持续运行和故障恢复，并在测试前写清验收指标。最终结论应回答：当前任务能否按周期稳定完成、瓶颈在哪里、配置还有多少余量、下一阶段怎样扩展。
概述
同一台GPU服务器，在图像模型训练、机器人仿真、VLA微调和多路推理中的表现可能完全不同。通用Benchmark可以了解硬件基础状态，却不能替代项目脚本、场景、数据和软件栈。
机器人PoC的价值，是把“配置看起来够不够”转化为可复现的数据：任务完成时间、稳定吞吐、显存余量、数据读取、多GPU扩展、端到端时延和长时间运行结果。
一、PoC开始前先锁定范围
| 需要锁定 | 具体内容 | 原因 |
|---|---|---|
| 软件环境 | 操作系统、驱动、CUDA或相关运行时、框架、仿真软件和插件版本 | 版本变化可能影响兼容性和性能 |
| 任务输入 | 机器人模型、场景、传感器、训练数据、模型权重和配置文件 | 避免测试任务与实际项目脱节 |
| 任务规模 | 环境数、相机路数、分辨率、Batch、序列长度、数据量和并发数 | 保证各轮结果可比较 |
| 质量条件 | 物理步长、渲染质量、训练精度、量化方式和任务效果指标 | 性能提升不能来自降低必要质量 |
| 验收目标 | 完成周期、吞吐、时延、稳定性、容量余量和扩展目标 | 测试结束后能够形成明确结论 |
二、怎样选择代表性测试任务
测试任务不必覆盖项目中的每一种情况，但应覆盖最可能形成瓶颈的链路。建议至少包含一个常规任务和一个压力任务，压力任务应来自下一阶段真实规划，而不是脱离业务的极限负载。
| 链路 | 代表任务示例 | 主要指标 |
|---|---|---|
| 数据处理 | 多路视频解码、Episode读取、预处理和缓存生成 | 样本/秒、CPU、内存、NVMe与网络吞吐 |
| 机器人仿真 | 目标场景、计划使用的传感器和并行环境 | 实时因子、步数/秒、显存、有效样本/小时 |
| 模型训练 | 真实模型、数据、精度、Batch和优化器运行多个训练Step | 显存峰值、Step时间、样本/秒、数据等待 |
| 推理部署 | 计划使用的模型、并发、输入尺寸和端到端链路 | P50/P95/P99时延、吞吐、功耗和错误率 |
| 多人并发 | 同时提交仿真、训练、数据处理或评测任务 | 排队、资源争用、隔离效果和总体完成量 |
三、推荐的六步测试顺序
- 兼容性检查：确认设备识别、驱动、软件安装、容器、依赖、GPU功能和基础数据路径。
- 单任务基线：在单卡或单节点上运行代表任务，记录资源峰值、吞吐和完成时间。
- 容量测试：逐步增加环境数、Batch、传感器、数据量或并发任务，找到稳定平台期。
- 多GPU或多节点测试：比较1卡、2卡、4卡或不同节点规模下的总吞吐和通信时间。
- 持续运行测试：按项目运行时长执行，记录温度、错误、性能漂移、内存增长和存储空间。
- 恢复测试：验证任务中断、节点重启、检查点恢复、数据完整性和日志可追溯性。
每一步只改变少量变量。若同时更换驱动、Batch、数据路径和GPU数量，即使结果变快，也很难确定收益来自哪里。
四、PoC指标应该记录什么
| 指标类别 | 建议记录 | 判断目的 |
|---|---|---|
| 任务完成 | 总耗时、Step/Epoch时间、仿真任务完成量 | 是否满足项目周期 |
| 吞吐 | 样本/秒、环境步数/秒、Token或请求吞吐、有效数据/小时 | 单位时间产出 |
| 时延 | P50、P95、P99、抖动和超时 | 推理与交互稳定性 |
| GPU | 显存峰值、SM利用、功耗、温度、PCIe或NVLink流量 | GPU是否等待、容量和互联是否受限 |
| CPU与内存 | 核心利用、负载、内存峰值、交换和NUMA分布 | 数据准备、物理求解和进程调度 |
| 存储与网络 | 读写带宽、IOPS、时延、I/O等待、网络吞吐和重传 | 数据供给和共享访问 |
| 稳定性 | 错误、温度、性能漂移、ECC/Xid、任务恢复和数据校验 | 是否适合持续运行 |
| 任务质量 | 验证集指标、仿真精度、任务成功率或项目定义结果 | 防止用降低质量换取速度 |
nvidia-smi、DCGM、系统监控和框架Profiler可以提供资源和时间线数据，但工具本身不是结论。监控采样间隔要能够覆盖短时峰值，Profiler也可能带来额外开销，应结合任务日志解释。
五、验收标准怎么写
验收标准应来自项目目标，而不是由供应商临时给出。建议同时设置“必须达到”“目标值”和“观察项”，避免某一项利用率成为唯一判断。
| 验收项 | 填写方式 | 示例口径 |
|---|---|---|
| 兼容性 | 必须达到 | 指定版本可安装、任务可复现、关键功能无阻断错误 |
| 完成周期 | 目标值 | 代表任务在项目允许窗口内完成 |
| 吞吐与时延 | 目标值与波动范围 | 持续运行时达到目标吞吐，P95/P99不超过项目阈值 |
| 容量余量 | 必须达到或观察项 | 显存、内存和存储保留计划内扩展空间 |
| 扩展效率 | 目标值 | 增加GPU或节点后，总吞吐达到项目定义的增幅 |
| 稳定性 | 必须达到 | 持续测试无阻断错误，恢复和数据校验符合要求 |
六、PoC记录表建议字段
| 板块 | 建议字段 |
|---|---|
| 测试编号 | 日期、负责人、配置版本、任务版本、数据版本 |
| 硬件环境 | CPU、GPU、显存、内存、存储、网络、GPU拓扑 |
| 软件环境 | 操作系统、驱动、运行时、框架、容器与关键依赖 |
| 任务参数 | 场景、环境数、传感器、Batch、精度、序列和并发 |
| 测试结果 | 完成时间、吞吐、时延、资源峰值、错误与质量指标 |
| 判断 | 通过/有条件通过/不通过、瓶颈、余量与下一步动作 |
七、PoC常见误区
- 只跑通用Benchmark，不运行项目脚本和真实数据。
- 只记录平均值，忽略P95/P99、显存峰值和短时I/O阻塞。
- 测试时间过短，没有发现温度、内存增长、错误重试和性能漂移。
- 多GPU测试只看总吞吐，不计算单位GPU产出和通信开销。
- 为了提高速度改变分辨率、精度或物理步长，却没有同步验证任务效果。
- 没有保存配置、日志和脚本版本，导致结果无法复现。
八、赋创在机器人算力PoC中的工作边界
赋创可围绕客户提供的测试任务、软件版本、数据、验收指标和目标周期，协助准备计算平台、部署软硬件环境、采集资源指标并形成配置与扩展建议。测试结论以双方确认的脚本、场景和数据为基础。
机器人算法、场景模型、数据质量、控制效果和业务验收逻辑由项目团队或相应专业方定义。赋创重点验证底层算力和数据链路是否稳定承载这些任务。
FAQ：机器人算力PoC常见问题
1. PoC需要运行多长时间？
没有统一时长。功能和单任务基线可以较短，稳定性测试应覆盖项目典型连续运行窗口，并足以观察温度、资源增长和错误恢复。
2. 通用Benchmark能否替代项目PoC？
不能。通用Benchmark适合检查基础性能和硬件状态，但不能代表机器人场景、传感器、数据读取和训练脚本。
3. 没有完整数据集能否做PoC？
可以使用能代表编码、分辨率、结构和访问方式的样本子集，但需要说明样本与正式数据的差异，并对容量和吞吐结论保留边界。
4. 多GPU扩展达到多少才算通过？
由项目完成周期和成本目标决定，不存在统一比例。应比较总吞吐、单位GPU产出、通信时间和稳定性。
5. 什么是“有条件通过”？
核心任务可以运行，但存在需要优化或限制的条件，例如特定Batch、数据路径、并发上限或软件版本。条件必须写入最终报告和交付范围。
方案咨询
需要把方案落到实际配置？
联系赋创获取算力、软件栈和交付路径建议。