1. 为什么机器人项目不能按"几张GPU"直接选型
机器人研发通常同时运行数据处理、物理仿真、模型训练和推理验证。四类负载对硬件的依赖不同，单独提高GPU规格，只能解决其中一部分问题。
合理的分析单位应是可复现任务：固定软件版本、机器人模型、场景、传感器、数据和训练配置，再测资源峰值、吞吐、时延与稳定性。
2. 数据链路：训练前的CPU、内存和I/O压力
以遥操作示教为例，一条Episode可能包含多路视频、关节状态、末端位姿、力/力矩、动作序列和时间戳。数据写入后还要执行时间对齐、清洗、切分、索引和解码。
|--------------------------------------------------------------------------------------|
| 容量估算 视频主体可先按"单路平均码率 × 相机路数 × 每日有效采集时长"估算，再叠加点云、状态、标注、版本副本和训练缓存。最终容量应使用真实编码设置和样本数据校正。 |
- CPU：视频解码、数据预处理、压缩、索引和加载进程。
- 系统内存：缓存、预取、并发DataLoader和场景资产。
- NVMe：高频训练读取、临时样本和检查点。
- 共享存储与网络：多人访问、集中数据集和多节点训练。
3. 仿真链路：物理求解、渲染和并行环境
机器人数量、关节和刚体规模、碰撞体精度、接触点、物理步长、材质纹理、相机和激光雷达设置，会共同改变负载。纯物理环境与带多路视觉传感器的环境，资源分布可能完全不同。
|-------------|---------------|---------------------|
| 观察指标 | 反映的问题 | 主要关联资源 |
| 实时因子、物理步数/秒 | 物理求解能否达到目标速度 | CPU线程、GPU物理加速、场景复杂度 |
| 传感器帧率与输出吞吐 | 渲染和数据生成是否跟得上 | GPU、显存、内存、写盘 |
| 稳定并行环境数 | 环境增加后吞吐是否有效扩展 | GPU、CPU、显存、进程调度 |
| 有效轨迹或任务/小时 | 总体产出是否满足研发周期 | 完整软硬件链路 |
4. 训练链路：显存、吞吐与扩展效率
训练显存受模型参数、训练精度、优化器状态、激活值、视觉输入、历史帧、动作块、Batch和梯度策略共同影响。机器人模型还可能同时处理多相机画面、状态向量和语言指令。
建议先用目标训练脚本测单卡峰值，再记录样本吞吐、单轮时间和检查点写入。进入多GPU后，需要关注框架的并行方式、梯度同步、数据供给和GPU互联。多GPU的总体显存并不等于任意单个进程可用显存。
5. 推理链路：中心、边缘与本体分层
中心侧适合批量处理、训练和集中评测；边缘侧适合近端推理与多机器人协同；机器人本体更关注功耗、散热、接口和实时性。测试时应记录完整的传感器输入、预处理、模型推理、动作输出和异常恢复链路。
6. 常见瓶颈现象与排查方向
|--------------|----------------------|---------------------------|
| 现象 | 可能原因 | 优先检查 |
| GPU利用率低但训练慢 | 数据读取、解码、CPU预处理或同步等待 | DataLoader、CPU、内存、NVMe和网络 |
| 显存频繁溢出 | 视觉输入、序列、Batch或场景资产过大 | 单卡峰值、缓存、精度与模型配置 |
| 并行环境增加但吞吐不增长 | CPU、显存、传感器渲染或进程调度瓶颈 | 每阶段耗时和资源曲线 |
| 多GPU扩展效率低 | 通信、数据供给或框架并行方式不匹配 | 同步时间、GPU拓扑和存储吞吐 |
| 长时间运行后性能下降 | 温度、内存泄漏、缓存增长或写盘压力 | 温度、错误日志、内存与磁盘队列 |
7. 从工作站到服务器和集群的升级顺序
- 在工作站上建立代表任务基线。
- 确定瓶颈属于单卡容量、总体吞吐、数据链路还是多人协作。
- 用单节点服务器验证持续运行、资源隔离和多GPU扩展。
- 只有在单节点基线清楚、软件支持分布式并且共享存储与网络完成验证后，再扩展多节点。
8. 结语
机器人算力规划的核心不是把所有资源一次配满，而是让数据、仿真、训练和推理链路能够被测量。只要代表任务、目标周期和扩展条件明确，工作站、服务器和集群之间就不再是模糊的档位选择，而是可验证的工程决策。