机器人边缘计算在处理器购物问题之前，是一个调度和数据流动的问题。摄像头、解码、感知、规划、通信和关节控制的运行速率和截止时间都不同。有用的平台是在机器人的有功功率和热条件下，完成整个数据时代的有界数据。
CPU适合不规则的控制流、操作系统服务、中间件、状态机及多种规划任务。 GPU对于大型并行工作负载和灵活神经模型非常高效。 NPU可以以吸引人的功耗效率执行支持的神经操作。当硬控制或保护性截止日期需要隔离时，没有任何处理器能替代专用MCU或实时控制器。
请结合 机器人推断延迟预算 和 ROS 2 实时控制指南阅读本书。测量可部署软件的图像和传感器配置；供应商峰值号或孤立模型基准无法确定机器人响应能力。
从物理系统的截止时间和更新频率开始
列出每个重复功能、触发器、标称速率、最差可接受完成时间和最大输入时间。 30 Hz摄像头可能输入15 Hz策略，而状态估计器运行200 Hz，电机控制器运行1 kHz。这些是独立的定时合同，而非单一平均帧率。
分配错过截止日期后必须发生的事情。感知可能会丢弃旧帧，规划可能会短暂保留最后有效轨迹，控制器可能会暂停或减速。备用需要独立边界，因此超载的加速器无法无声地重放陈旧指令。
将一个观察追踪到一个应用的命令
时间戳物理暴露、传感器传输、解码、预处理、推理队列和完成、后处理、规划、消息传递和命令应用。跨阶段携带同一个序列身份。主机时钟、设备时钟和传感器硬件时钟需要有文档的同步方法，才能比较时间戳。
报告中位数、 P95、 P99、最大观测延迟、采样计数和执行时输入年龄。吞吐量表示工作完成量；延迟表示单个项目等待的时间。高度流水线化的系统在机器人操作旧场景时可以报告高帧率。
| 阶段 | 典型的主人 | 主要测量 | 故障信号 |
|---|---|---|---|
| 俘获与转交 | 传感器与驱动器 | 暴露于宿主的时间 | 掉帧或后帧 |
| 预处理 | CPU还是GPU | 队列加执行 | 缓冲区的生长 |
| 推断 | GPU 或 NPU | 排队到输出时间 | 备用分区 |
| 规划 | CPU还是GPU | 状态到指令时间 | 错失视界 |
| 应用 | 控制器 | 指令使用年龄 | 陈旧的拒绝 |
使用CPU进行不规律工作和系统协调
CPU负责驱动程序、 ROS 2 执行器、状态机、通信、异常路径以及带有分支或小规模变化工作负载的算法。它们还负责启动加速器工作和管理内存。当一个繁忙的核心或锁决定截止日期时，低平均利用率并不代表剩余空间。
将硬循环或安全相关循环与页面错误、文件日志、动态分配和尽力而为服务区分开来。仅在追踪争用后应用亲和力和调度。钉顶线程仍可等待内存、驱动程序、中断或共享互斥。
用GPU处理广泛的并行工作负载
GPU在图像变换、特征提取、点处理和神经网络中表现有效，这些都暴露了大量并行工作。其成熟的库使其在快速模型迭代中非常有用。性能取决于张量形状、精度、核选择以及每次发布中分配的工作量。
小批量机器人通常更重视单次请求延迟而非最大吞吐量。在测量中包括主机队列、同步、输出副本和竞争内核。如果流水线等待格式转换或内存拥有时间更长，内核速度再快也无济于事。
只有在检查已编译的图后才使用 NPU
NPU可以以低功耗反复执行支持的操作符，但模型转换可能会改变精度、形状或图结构。不支持的操作符可能运行在CPU上，或将图分到不同设备。迁移和复制成本可能抹去预期的收益。
检查编译器报告，并与参考模型比较输出准确性。测试部署后的动态输入、预处理和后处理。当操作员覆盖率、内存或软件成熟度不同时，广告中更多TOPS的设备对特定型号可能较慢。
| 工作量 | 首选方案 | 为什么 | 需要核实的事项 |
|---|---|---|---|
| 驱动程序与状态机 | 中央处理器 | 不规则控制与输入输出 | 核心与锁的争夺 |
| 大视觉张量 | GPU | 并行灵活计算 | 复制品与发射台 |
| 固定支持网络 | 国家动力系统（NPU） | 功耗推断 | 操作员备份 |
| 硬实时关节控制环 | MCU或RT控制器 | 确定性时期 | 分离与安全反应 |
| 混合管道 | 异质性 | 并行优势 | 同步成本 |
内存带宽可以主导加速器的数学
多摄像机、深度图、点云、地图和大权重可能在算术单元繁忙前就使内存过饱和。共享内存硬件并不保证零复制：软件可以在每个边界分配新缓冲区、转换色彩格式或更改张量布局。
记录缓冲区所有权、分配、读写流量及队列深度。通过地址和追踪验证任何零副本声明。同时测试整个传感器组，因为同时突发和缓存压力能揭示单摄像头基准测试隐藏的问题。
电源模式和冷却是配置的一部分
电池机器人运行在电热预算的综合范围内。计算峰值可能与执行器峰值重叠，导致电压下降或功率限制。密封外壳、防尘过滤器、安静风扇策略或高温仓库可能会在短暂基准测试结束后长时间降低持续时钟。
每次比较时都要固定电源模式、时钟、风扇策略和环境条件。运行足够长以达到热平衡，并记录轨道功率、温度、频率和延迟。选择一个有余裕的持续工作点，而不是第一分钟的最大值。
比较具有可重复工作负载的板子
TOPS值可能采用不同的精度、稀疏度假设和操作定义。比较同一型号、输入、软件版本、精度目标、传感器负载和功率模式。测量端到端延迟、持续吞吐量、内存余量、任务能耗及超载恢复情况。
板材选择还包括摄像头和网络接口、存储、启动时间、安全性、长期供应、更新流程和诊断工具。稍慢的平台如果可重复且可在整个车队中维护，可以降低生命周期成本。
分析资源争用和故障，而不仅仅是名义上的操作
在感知和规划运行的同时，运行映射、日志、可视化、网络和更新检查。注入丢弃帧、突发流量、存储压力、热限速和挂机加速器作业。观察队列是否保持有界，以及是否拒绝过时输出。
将CPU调度、加速器时间线、内存流量、电源和机器人状态关联到一个时钟上。平均利用率可以隐藏短暂的阻塞事件。存储成功和失败运行的跟踪，以便性能回归与软件或固件更新关联。
一个SoC和分布式计算有不同的故障模式
单个SoC可以减少布线和串行化，但会集中热量、电力和软件故障。分布式控制器可以隔离快速环路并提供故障控制，同时增加网络延迟、时钟同步、协议和恢复状态。这两种拓扑都不会自动更具确定性。
将大量原始数据放置在传感器附近，并在保持任务证据的情况下发送紧凑结果。定义链路消失或某节点重启时的处理。接口必须包含时间戳、有效性、序列和健康状态，而不仅仅是有效载荷。
保持部署配置文件版本管理
归档板的版本、固件、内核、驱动程序、运行时、模型工件、编译器选项、电源配置和散热设置，涵盖每个基准测试。 NVIDIA Jetson当前的软件文档 暴露了多个版本分支，请引用测试的具体版本。平台文档描述的是能力，而非特定机器人工作负载的结果。
在模型、中间件、驱动或机箱变更后重复验收工作负载。如适用，使用 NVIDIA Nsight Systems文档，其他加速器使用等效厂商工具。只有当系统时序和任务性能同时提升时，才接受优化。
评估“机器人边缘计算：如何分配CPU、 GPU和NPU工作”时，还应保存模型版本、机器人配置、标定文件、测试日期和全部试验记录。把成功、失败、恢复与人工介入放在同一份数据中，才能区分模型能力、系统接口和现场流程造成的差异。
成本评估除了设备与算力，还要记录数据采集、工程调试、安全措施、维护、停机和人员培训。只有把这些持续投入与单位成功任务的价值比较，才能判断方案是否适合扩大。
- 定义速度、截止日期和指挥年龄限制。
- 通过命令应用追踪捕获。
- 检查已编译的图表和内存副本。
- 压力：电力、热量和同时工作量。
- 具体的硬件和软件配置文件。
常见问题
机器人能在没有CPU的情况下运行吗？
大多数实用机器人仍需CPU来驱动、通信、状态机和异常处理。 GPU和NPU设备加速选定工作负载。
更高的TOPS是否意味着机器人延迟更低？
不。精度、操作员支持、内存移动、批处理、电源模式、冷却和队列都会影响端到端的时序。
GPU和NPU应该同时运行吗？
它们可以，尤其是对于独立工作负载，但图拆分和缓冲区传输必须被测量，因为同步可能成本高于节省。
统一内存会自动变成零副本吗？
不。 API和所有权变更仍可分配或复制缓冲区。通过分析和地址级证据确认实际路径。
板块基准测试应该运行多久？
足够长的时间达到最糟糕的预期温度，暴露出限速、内存增长和队列不稳定，而所有生产传感器和服务都处于激活状态。
机载计算证据边界
计算性能取决于具体的电路板、软件版本、型号、传感器负载、电源模式和热环境。在提出部署声明前，请验证整个机器人流水线。