03.5 端侧具身智能芯片深度调研 (Edge Chips)
端侧芯片决定了具身系统的三条硬约束：实时性、功耗/热设计、软件可维护性。本章不做营销参数堆砌，而是给出部署可用的选型框架与风险清单。
⏰ 最后更新时间: 2026-02-26 | 本页内容将每日更新「端侧芯片路线、软件生态与部署选型实践」。
1) 为什么“芯片环节”需要独立看
- 控制闭环：推理时延直接影响控制稳定性与恢复能力。
- 系统功耗：移动平台/人形平台受电池与散热约束，算力不能脱离功耗谈。
- 软件生态：同样是算力，工具链、驱动与部署框架成熟度差异巨大。
2) 主流端侧芯片参数对比（公开口径）
| 平台 | 代表产品/芯片 | 官方算力口径 | 功耗/能效口径 | 典型软件生态 |
|---|---|---|---|---|
| NVIDIA Jetson | Jetson AGX Orin | 最高 275 TOPS | 官方给出可配置 15W-60W | Isaac ROS |
| Qualcomm Robotics | RB5 Dev Kit (QRB5165) | 页面披露约 15 TOPS | 强调边缘端高能效 AI（页面未给同口径整机 TDP） | Qualcomm IoT |
| Hailo | Hailo-8 | 官方页面披露 26 TOPS | 强调边缘端高能效（具体功耗取决于模型与板级实现） | Hailo Model Zoo |
| Google Coral | Coral Edge TPU | 单 Edge TPU 约 4 TOPS | 官方文档披露约 2 TOPS/W | Edge TPU GitHub |
| MCU + AI 协同 | STM32N6 | 官方页面披露 NPU 最高 600 GOPS @ 1GHz | 面向低功耗边缘场景（功耗随频率与工作负载变化） | TFLite Micro |
参数来源：NVIDIA Jetson Orin、 Thundercomm RB5、 Hailo-8、 Coral Edge TPU Benchmarks、 STM32N6。
3) 运行模型 Benchmark（公开可核对）
| 平台 | Benchmark / 模型 | 场景与指标 | 公开结果 | 来源 |
|---|---|---|---|---|
| Jetson Orin (Orin_TRT) | MLPerf Inference v4.1 Closed / GPT-J-99 | Offline（Samples/s） | 0.934398 samples/s | mlperf_log_summary.txt |
| Jetson Orin (Orin_TRT) | MLPerf Inference v4.1 Closed / Stable Diffusion XL | Offline（Samples/s） | 0.101697 samples/s | mlperf_log_summary.txt |
| Hailo-8 | Hailo Model Zoo / resnet_v1_50 HEF | FPS / Latency / Power（示例输出） | FPS 1328.83；2.93646 ms；3.19395 W(avg) | Hailo BENCHMARKS.rst |
| Coral Edge TPU | Coral 官方表 / MobileNet v2 (224x224) | Dev Board with Edge TPU（ms/inf） | 2.6 ms（同表中 Embedded CPU 为 122 ms） | Edge TPU benchmarks |
| Coral Edge TPU | Coral 官方表 / MobileNet v2 SSD (224x224) | Dev Board with Edge TPU（ms/inf） | 14 ms（同表中 Embedded CPU 为 282 ms） | Edge TPU benchmarks |
| RB5 / STM32N6 | 公开产品页 | 统一模型 benchmark | 公开页面以规格参数为主，未给出与上表同口径的统一模型分数 | RB5 / STM32N6 |
说明：跨平台 benchmark 不能只看单一数字；至少要同时对齐模型版本、精度（INT8/FP16）、输入分辨率、batch、场景（Offline/SingleStream）后再横向比较。
4) 选型中的“六维约束”
| 维度 | 要问的关键问题 | 常见踩坑 |
|---|---|---|
| 实时性 | 端到端推理延迟是否满足控制周期？ | 只看离线吞吐，不看闭环抖动 |
| 功耗与散热 | 持续运行时是否会降频？热设计是否可落地？ | 实验室能跑，现场高温降频导致性能崩塌 |
| 内存与带宽 | 多模态输入与多模型并发是否会抢内存？ | 推理稳定但传感器数据堆积造成延迟尖峰 |
| I/O 与总线 | 相机/LiDAR/编码器接入能力是否足够？ | 算力足够但 I/O 不足，系统吞吐被总线卡死 |
| 软件栈 | 驱动、编译链、模型部署工具是否成熟？ | 模型可跑但升级困难，维护成本不可控 |
| 供应链 | 生命周期、供货节奏、BOM 风险可控吗？ | 试点成功但量产阶段缺货或成本失控 |
5) 推荐系统形态：主控 + 协处理 + 安全控制
flowchart LR
A[传感器输入 RGBD/LiDAR/IMU] --> B[主控 SoC: VLA/规划]
B --> C[协处理 NPU/加速卡: 视觉推理]
B --> D[实时控制 MCU: 电机与安全约束]
C --> B
D --> E[执行器与安全联锁]
B --> F[日志/回放/回归系统]
工程实践上，端侧平台通常不是“单芯片全包”，而是分层协同：高层决策、推理加速与安全控制各司其职。
6) 采购与部署观察（落地版）
- 基于目标任务定义控制周期与延迟预算，再反推芯片算力与功耗区间。
- 先做 72 小时稳定性压测（热、功耗、频率抖动、I/O 峰值）。
- 验证软件栈升级路径（驱动、推理框架、模型转换工具链）。
- 将供应链风险纳入评估：生命周期、备选方案、可替代BOM。
- 部署前通常会跑“旧任务回归 + 新任务扩展 + 安全指标”三套测试。
端侧芯片选型不是“谁 TOPS 高选谁”，而是“谁在你的任务约束下可持续稳定交付”。具身系统真正的门槛是长期运行稳定性与维护效率，而非单次峰值性能。