一颗AI芯片的成败，往往不取决于峰值算力有多漂亮，而取决于真实模型能否持续把数据送进计算单元，并在功耗、延迟、成本和精度之间保持平衡。芯片开发也不是从画电路开始，而是从“这颗芯片究竟要完成什么工作”开始。
下面用一个假想的边缘视觉加X器 作为案例。它部署在生产线上，需要同时处理两路相机画面，识别表面缺陷，并在几十毫秒内把结果交给控制系统。这个案例不是某家公司的真实产品复盘，而是一条可验证的工程路径。
## 第一步是测量工作负载
团队先固定三个代表性模型：轻量分类、目标检测和小型分割网络。对每个模型记录算子比例、张量形状、权重大小、激活峰值、访存量和可接受的数值精度。只看每秒多少万亿次运算，会忽略很多实际瓶颈。
例如，卷积可能计算密集，后处理却含有分支和不规则访存；分割模型的中间激活很大，容易把片上存储挤满；小批量实时推理又无法像数据中心那样靠大批次摊薄调度成本。需求因此要写成一组场景指标，而不是一个孤立峰值。
接着建立软件基线。在通用CPU、GPU或现有边缘模块上运行同样的模型，测出端到端延迟、能耗、内存带宽和精度。基线既告诉团队哪里值得做专用电路，也防止新芯片只在精心挑选的算子上获胜。
## 架构设计围绕数据移动展开
神经网络加X器 通常包含乘加阵列、片上缓存、直接存储访问单元、片外内存接口和控制核心。计算阵列决定理论吞吐，存储与互连决定这些计算单元能否被喂饱。
案例团队把常用权重按块搬入片上存储，让输入特征在多个计算阶段之间复用；对体积较大的激活采用分块处理，避免频繁回写片外内存。量化到较低精度可以减少存储和能耗，但必须用真实数据复测缺陷召回率，不能只看通用数据集上的平均精度。
这时需要编译器参与。模型图要经过算子融合、布局变换、分块、调度和指令生成，才能映射到硬件。MLIR一类多层中间表示的价值，在于把模型级算子逐步降低为目标硬件可执行的循环、内存访问和指令，同时保留优化空间。
如果某个算子无法有效映射，团队有三种选择：修改硬件、改编译器，或调整模型结构。真正的软硬件协同不是硬件完成后再补驱动，而是在架构冻结前不断往返。
## 从RTL到版图不是一次直线前进
架构确定后，设计被写成可综合的硬件描述，并接受功能仿真、形式验证、覆盖率检查和随机测试。验证需要覆盖正常输入、边界尺寸、缓存冲突、异常中断以及长时间运行中的状态组合。
随后进入逻辑综合、布局规划、单元放置、时钟树、布线、时序收敛和功耗分析。OpenROAD展示了一条开放的RTL到GDSII流程，但“自动完成”不意味着结果天然适合量产；工艺库、时序角、供电网络、可测试性和制造规则仍需要专业审查。
版图阶段常会反过来改变架构。更大的缓存可能减少外存访问，却拉长连线并降低频率；更宽的互连提升带宽，也增加面积和动态功耗。团队需要同时观察性能、功耗和面积，也就是常说的PPA，而不是单独追求某一项最好。
## 首片回来后才进入真正的系统验证
流片前可以用FPGA或仿真器提前跑软件栈。首批样片回来后，要从上电、时钟、内存训练、指令执行逐层验证，再运行模型和长时间压力测试。开发板上的平均速度不够，还要观察尾延迟、温度升高后的降频、不同模型切换以及错误恢复。
MLPerf Inference把系统分为服务器、离线、单流、多流等场景，并把性能与准确率校验放在一起。这提醒开发者：AI芯片的指标必须绑定负载、场景、软件版本和精度约束，否则不同结果没有可比性。
案例最终的验收条件可以是：两路相机同时工作时，端到端延迟仍低于目标；缺陷召回率不低于软件基线；在规定散热条件下连续运行不降频；编译器能覆盖计划内模型的大部分算子；遇到不支持的算子时可以可靠回退。
## 实战中最容易低估的三件事
第一是数据移动。一次片外访存的代价可能远高于一次乘加，峰值算力利用率低往往不是阵列太小，而是数据没有按时到达。
第二是软件寿命。模型结构持续变化，过度绑定某一代网络的专用电路可能很快失去价值。稳定的中间表示、可扩展指令和可观测的性能工具，决定芯片能否跟上模型演进。
第三是验证范围。芯片逻辑正确不等于系统可用。驱动、编译器、内存、散热和应用代码共同决定真实表现。所谓AI芯片开发实战，本质是一场跨层迭代：每一层都用可复现证据约束下一层，而不是让一张规格表代替整个系统。
## 参考资料