边缘 AI 板卡选型最容易犯的错误，是把营销页上的 TOPS 当成采购结论。算力指标当然重要，但在实际项目里，更常见的失败原因其实是显存不够、I/O 不匹配、热设计留白不足，或者软件栈在关键算子上不稳定。
Table of contents
Open Table of contents
先把需求拆成四层
在拿任何板卡做横向比较之前，先把需求拆成四层：
- 模型层：参数量、上下文长度、是否需要多模型并发。
- 数据层：相机、雷达、传感器、网络流的输入速率和预处理成本。
- 系统层：延迟预算、掉帧容忍度、断网时是否还能运行。
- 运维层：远程更新、日志、回滚、长期供货和备件策略。
只有把这四层写清楚，TOPS 才有解释空间。
内存比峰值算力更早撞墙
很多边缘项目卡住，不是因为 MAC 不够，而是因为模型权重、中间激活和输入缓存挤爆了内存层级。看板卡时至少要确认：
- 片上 SRAM 和外部内存各自负责什么。
- 内存带宽是否能覆盖峰值并发场景，而不是只覆盖单 batch 演示。
- 预处理和后处理是不是会抢同一块内存带宽。
如果这些问题答不清，所谓高 TOPS 通常只能停留在宣传场景里。
I/O 与热设计是隐性成本
项目从 demo 走向部署时，I/O 和热设计经常成为真正的门槛。常见的失配包括：
- 摄像头数量上来之后，接口数量和 DMA 路径不够用。
- 算法团队把 batch 拉高，结果整机功耗和噪声超出机箱边界。
- 实验室常温通过，到了封闭设备或夏季现场就开始降频。
所以板卡评估表里一定要有接口清单、热设计余量和持续功耗曲线，而不是只放一行 FP16 或 INT8 峰值。
软件栈稳定性决定交付风险
一个能跑通 demo 的 SDK，不等于能支撑半年后的维护。建议把下面几个问题前置：
- 关键算子是否需要大量自定义实现。
- 编译器和运行时版本升级会不会破坏已验证模型。
- 调试工具、profile 工具、日志机制是否完整。
在硬件 AI 项目里，软件栈的不确定性往往比芯片本身更贵。
一个实用的结论
选板卡时先做减法：先排除内存、I/O、热设计和软件栈不合格的方案，再比较算力。这样得到的结论通常比“谁的 TOPS 更大”更接近真实交付结果。