1. 为什么会有人想新造一颗AI芯片
做AI芯片这件事，放在五年前是极少数人能聊的话题，而现在几乎每周都有朋友拿着各种PPT来跟我讨论“要不要自己搞一颗”。作为一个在芯片行业摸爬滚打多年的从业者，我想借这个机会把这些思考整理出来，给真正想动手做点事的人一份参考。
所谓AI芯片，简单说就是专门为人工智能计算任务设计的处理器。它跟CPU、GPU的本质区别在于：CPU是通用的，什么活都能干但什么活都不算快；GPU是为图形渲染优化的，后来被深度学习撞上了发现矩阵运算很强；而AI芯片则是彻底围绕神经网络的计算模式来设计的，把卷积、矩阵乘法、激活函数这些高频操作全部做成硬件指令，效率自然高出一截。
我见过太多人一上来就说“我要造一颗比英伟达更强的芯片”，这种想法没问题，但需要先搞清楚一个根本问题：你到底在给谁造芯片？如果是给数据中心的大客户，面对的是H100、B200这些庞然大物，你的资金、团队、软件生态没有任何优势；如果你是瞄准某个垂直场景，比如端侧推理、工业质检、智能座舱，那反而有得打。
新造AI芯片，本质上是在做一个系统工程决策。你不仅要设计一颗能跑神经网络的处理器，还要配套编译器、算子库、运行时框架、板卡方案，甚至要帮客户解决散热和功耗问题。芯片本身只是冰山一角，水面下的工程量会远超你的想象。
2. 造AI芯片之前必须想清楚的三件事
2.1 目标场景决定芯片的命
在开始写RTL代码之前，一定要把一句话写清楚：这颗芯片将跑在什么设备里，处理什么类型的神经网络，运行环境的功耗约束是多少。
我举个实际例子。同样是做AI芯片，自动驾驶芯片和TWS耳机芯片的差异大到离谱。自动驾驶场景下，你要处理8路摄像头输入、激光雷达点云，还要求整个感知链路延迟低于30毫秒，芯片功耗可以放到几十瓦；耳机里的唤醒芯片呢，你只有几毫瓦的功耗预算，但只需要处理一个关键词识别模型，精度要求也没那么苛刻。这两类芯片的架构设计、内存规划、NPU核心数量、制程选择完全是两套思路。
基于常见实践经验，我个人建议你把目标场景细化为三层：
- 网络模型层面：确定必须支持的骨干网络类型（CNN还是Transformer为主）、最大模型参数量、输入分辨率范围
- 部署环境层面：工作温度范围、可用功耗上限、外部内存还是片上存储为主、PCIe还是SoC总线接入
- 商业层面：单芯片目标成本、预期出货量级、竞争对手的部署方案是什么
这三层决策直接决定你的PPA（功耗Power、性能Performance、面积Area）目标。没有明确场景就动工，后面的坑只会越踩越多。
2.2 算力幻觉：8TOPS和800TOPS到底差了多远
很多团队把“算力”作为立项的第一指标，张口就是几百TOPS，但这恰恰是最容易产生幻觉的地方。TOPS只代表理论峰值算力，也就是在一个时钟周期内理论上能做多少次乘加运算，它跟实际跑模型时能发挥出来的有效算力完全是两码事。
一个残酷的现实是：绝大多数AI芯片，实际跑主流模型时只能发挥峰值算力的20%到40%。算力利用率上不去的核心原因是“内存墙”——数据从存储搬运到计算单元的速度跟不上计算单元消费数据的速度。你设计了每秒50TOPS的MAC阵列，但片上SRAM吞吐不够、数据复用策略差，实际跑ResNet的时候一大半时间都在等数据，算力自然就浪费了。
所以在新造芯片的思考框架里，不能只看TOPS，至少要看三个数字：
- 峰值算力：芯片规格书上的理论值，用来做市场宣传
- 持续算力：在给定模型和batch下实际能跑出的吞吐量
- 算力利用率：持续算力除以峰值算力
我见过不少创业公司用夸张的TOPS拿融资，但做芯片不是做PPT，真正拿给客户测试时，跑一个YOLOv8s，帧率还不如别人上一代产品，原因就是有效算力远低于标称值。造AI芯片一定要先接受一个理念：把数据供得上，比把计算堆得高更重要。
2.3 制程工艺选12nm还是7nm
制程选择是决定成本和周期的关键一步，也是个典型的工程权衡问题。以当前的流片成本来看，28nm的一次MPW费用大约在几十万元人民币量级，12nm就得几百万，7nm更是上千万，而且这些数字只是流片本身，不包含封装、测试和验证的人力成本。
对于一个新团队，我的建议是除非做数据中心级的训练芯片，否则尽量控制在12nm及以上成熟工艺。原因很简单：先进工艺的IP授权费用高、设计规则复杂、Signoff难度大，任何一个环节出错就会增加一轮几百万的流片成本。而多数边缘推理场景，12nm配合好的架构设计，已经能做出有竞争力的产品了。
做AI芯片本质上是在计算性能和成本的最优解，不是做最先进的芯片，而是做最适合场景的那一颗。
3. 新造AI芯片的架构设计核心细节
3.1 计算单元：脉动阵列还是SIMD
确定了场景和工艺之后，最核心的问题就是计算单元的选择。目前主流AI芯片的NPU计算阵列大致分两类：脉动阵列（Systolic Array）和SIMD向量单元。
脉动阵列是Google TPU带火的。它的核心思想是让数据像心跳一样在计算单元之间“涌动”——权重静止在阵列里，输入数据逐周期从一个PE流向另一个PE，每个PE同时做乘累加。由于数据复用率高、每次读取SRAM都能被多个PE使用，功耗效率很好。缺点是编译器必须把模型映射成脉动阵列能接受的数据流形态，对算法灵活性有约束。
SIMD向量单元更像CPU的向量扩展，每个周期可以同时处理多组数据，编程灵活，但数据搬运次数多，功耗效率略低。英伟达GPU的Tensor Core就带有脉动阵列的思想，而很多边缘芯片选择SIMD是因为配套软件更容易做。
给个参考数据：脉动阵列在数据复用充分时，算力利用率能到70%以上，而SIMD向量核通常只能到50%。但脉动阵列遇到不规则的模型结构比如稀疏注意力时，利用率会大幅下降。选哪种，取决于你的目标模型分布。
3.2 存储层次：片上SRAM就是你的命根子
系统架构设计界有一句老话：对于AI芯片，存储即架构。DRAM的带宽和延迟是固定的物理约束，唯一能优化的是把数据尽量留在片上SRAM里反复使用。
在做具体设计时，这片SRAM怎么分是门学问。按照业界比较通用的做法，我会把片上存储划成三块：
- 主Buffer：存放输入特征图和中间激活值，容量占比约50%
- 权重Buffer：存放当前层的权重参数，配合预取机制，容量占比约30%
- 辅Buffer：用于算子拼接、存储转换、输出暂存，容量占比约20%
这里有一个非常关键的设计参数。举个例子，假设芯片主频1GHz，目标跑YOLOv8s模型（约1120万参数，FP16约22MB权重）。如果你设计256KB的权重Buffer，一次只能缓存约1.2%的权重，意味着每做一次卷积都要频繁搬运权重；如果设计2MB，就能一次装下大部分权重，访存效率截然不同。当然SRAM面积很大，2MB在12nm下约占十几平方毫米，成本压力要权衡。
一个原则可以记住：宁可降低一点峰值算力，也要多留片上存储。大多数时候“片上有粮，心里不慌”。
3.3 互联总线：AXI还是NoC
AI芯片内部需要连接NPU核心、CPU子系统、编解码器、DMA控制器、外设接口。互联方案的选择直接影响带宽和可扩展性。
简单场景下，一个SoC级别的总线如AXI总线就够了，多个主设备通过仲裁共享总线。但如果你要做8个NPU核心、每个核心多路读取DRAM，单一总线会成为瓶颈，这时候需要上NoC（片上网络）。NoC把通信建模成网络路由——数据包从源节点出发，经过中间路由器转发到目的节点。
从实操角度看，第一代芯片建议用AXI做全局互联，集中精力把NPU和编译器做好；等到第二代芯片、核心数超过4个、有明确的多核并行需求时再上NoC。一上来就搞复杂互联拓扑，验证工程量会增加30%以上。
3.4 精度方案：FP16、BF16还是混合精度
精度设计决定的是计算单元的数量和存储带宽的需求。FP16（16位半精度）动态范围和精度都够用，是目前边缘推理的主流；BF16（Brain Floating 16）用一个符号位、8位指数、7位尾数，在训练场景有优势，动态范围和FP32一样，但尾数精度更低；而当前很多数据中心芯片引入FP8和INT8做推理，相应存储减半、吞吐翻倍。
按照现在主流实践，我建议新造AI芯片采用混合精度方案：默认FP16计算，同时支持INT8/INT16量化推理。这样既能保证模型性能，又能在部署阶段通过量化换取性能提升。对于有训练需求的场景，额外加BF16支持，代价是计算单元切换开销和验证复杂度增加。
还值得提醒的是，如果你要支持Transformer类模型，最好在硬件上加入针对Softmax、LayerNorm这类归一化算子的加速单元。软件跑Softmax也完全可以，但在低功耗场景下优化过的硬件实现能明显降低延迟，这一块在大多数“从TPU抄作业”的芯片里经常被遗漏。
4. 工具链与软件生态：决定生死的另一半
4.1 编译器才是真正的护城河
所有做过AI芯片的人都认同一个观点：造芯片只算完成了一半，另一半是工具链。你设计了一颗计算能力很强的NPU，但客户把Pytorch模型导进来发现算子不支持，编译器崩溃，或者性能远低于预期，这芯片就废了。
AI芯片的软件栈分层大概是这样：
- 前端：对接Pytorch、TensorFlow、ONNX模型，负责计算图解析
- 中间IR：图优化、算子融合、内存规划、并行调度
- 后端：指令生成、寄存器分配、Microcode编码
这里面最烦的是算子边界不清晰。比如Fused Conv-BN-ReLU，好的编译器会把它融合成一个算子，一次读数据、一次写回；差的编译器把它拆成三个核心算子，数据来回搬运三次，性能差出三倍。在项目规划时，一定要把编译器团队当成一等公民，而不是硬件的附属品。
4.2 算子库开发的“二八法则”
每个AI芯片公司都会遇到一个问题：到底要支持多少算子？答案是，真正主力的算子不超过20个，但它们覆盖了95%以上的主流模型计算量。Conv、GEMM、MatMul、Add、Relu、Softmax、LayerNorm、Pooling、Concat、Resize、Sigmoid、Permute、Transpose、Gelu、ArgMax、Slice/StridedSlice。先把这些算子在NPU上手工调优到极致，再用编译器覆盖剩余的长尾算子。
对于长尾算子，千万不要为了100%覆盖而死磕，投入产出比极低。常见实践是兼容一层轻量级的算子解释执行机制兜底，性能差一点但保证能跑通模型，等客户反馈某类模型经常用到时再专项优化。
4.3 驱动与开发板的坑
芯片回来后，你需要在FPGA验证平台和开发板上跑通第一版SDK。这个时候最容易遇到的坑包括：DMA描述符不工作、中断响应延迟过高、NPU的寄存器配置序列有误。
我个人总结的一点经验是：首次bring-up建议准备一个“最小可运行镜像”——不要跑任何神经网络，先把NPU寄存器读写、DMA拷贝、片上SRAM写入读回这三件事跑通。这三个动作验证了，再逐步加入具体算子。很多团队喜欢一上来就跑ResNet50，结果一旦跑不通，根本分不清是硬件问题、编译器问题还是环境问题，debug效率极低。
5. 实操过程：从立项到芯片回来的完整路线
5.1 28个月的时间线怎么排
基于行业普遍经验，一颗边缘推理AI芯片从立项到量产，一般需要24到36个月。这里给一个偏实际的排期参考：
| 阶段 | 周期 | 关键交付物 |
|---|---|---|
| 架构定义 | 3个月 | 架构文档、PPA目标、指令集草案 |
| RTL设计与集成 | 6个月 | 核心模块RTL冻结、IP集成完成 |
| 验证 | 5个月 | 功能仿真收敛、覆盖率达标 |
| 后端实现 | 3个月 | 综合、布局布线、时序收敛 |
| 流片前审查 | 1个月 | DFT测试方案、封装方案冻结 |
| 流片+封装 | 3个月 | 晶圆回片、封装完成 |
| Bring-Up与量产准备 | 7个月 | SDK稳定、测试报告、量产改制 |
Note：这个排期是大并联小串联，软件不能等硬件回来再开发。第一个月启动时，软件团队就要在模拟器上同步开发工具链。否则芯片回来等软件，一等就是半年。
5.2 验证策略：仿真图和FPGA验证怎么配合
验证工作往往占据整个项目一半以上的人力。功能仿真是验证准确性的保障，但AI芯片的NPU阵列动辄几十上百个PE，跑一个周期级仿真只能覆盖比较小的激励，速度感人。FPGA原型验证则是加速验证的关键：把RTL综合到FPGA上跑真实模型，速度能到几十MHz。
实操中我的建议是分段分工：
- 单元级验证：仿真器为主，重点验证单个PE、DMA等模块的边界条件和时序冲突
- 子系统验证：仿真器+FPGA结合，验证NPU与DMA的数据通路、中断流程
- 芯片级验证：FPGA为主，跑完整的模型部署流程，重点看软件栈成熟度
常见验证遗留的问题中，最容易踩的坑是死锁。两个主设备互相竞争总线资源，谁都在等对方释放，系统陷入停滞。这种问题仿真很难完全覆盖，因为涉及的激励条件组合空间极大。我的经验是，写个随机压力脚本，让DMA、NPU、CPU同时发起大量访问，跑够48小时，死锁问题大概率能暴露出来。
5.3 流片回来的Bring-Up流程
芯片从晶圆厂回来，封装好，上电。这一刻的心情既兴奋又紧张。Bring-Up的流程大致如下：
- 电源检查：核心电压、IO电压逐项测量，确认没有短路和异常漏电
- 时钟检查：确认PLL锁定、各模块时钟输出正常
- 复位释放：确认各子系统能正常复位
- 寄存器读写：通过JTAG或者调试端口读写寄存器
- 测试程序：跑芯片自带的BIST测试、Pattern测试
- 最小模型：跑通一个简单模型如LeNet/MobileNet
这里特别想说一下，上电之前一定要做电源上电时序检查。AI芯片电压域多，核心域、逻辑域、IO域的上电顺序如果不对，很可能会损害芯片。基于常见的负责任做法，需要对照设计规格书逐项核实上电顺序，并配备过压保护和限流措施。
6. 常见问题与排查技巧实录
6.1 芯片发热严重但算力上不去
这种情况很典型，很多人第一反应是散热不够，但实测下来，大概率是芯片在“空转”——计算单元在等数据，而时钟和供电一直在消耗。排查思路：
- 跑一个纯计算密集的程序，比如总在计算而不读内存的测试用例，看功耗是否上升
- 再跑一个访存密集的程序，对比两者的功耗差
- 如果纯计算功耗偏低、访存功耗偏高，基本可以确认数据供给跟不上，通常落脚在DMA带宽不足或片上缓冲太小
这类问题很难通过硬件改动解决，更靠编译器优化：比如算子融合、数据复用调整、DMA预取增加。也是我一直强调的，硬件条件的约束要靠软件策略来弥补，两者不能脱节。
6.2 模型实测精度与仿真差距大
芯片回来后，同样一个模型，在电脑上仿真精度98%，上芯片只有85%，这种落差常让人头疼。可能的原因按概率排序：
- 量化参数换算有误：比如用INT8权重时，scale因子算错一位，整个模型就废了
- DMA搬运数据时字节对齐问题：很多NPU要求数据按32字节对齐，没对齐的数据会被错误解析
- 片上存储中的位翻转：低电压下SRAM可能不稳定，导致权重被改
排查顺序建议是：第一步在芯片上用固定的随机数据做计算比对，确认算子本身正确；第二步再跑小模型逐层检查数值，通过切片定位问题在哪个层；最后再检查量化配置。不要一上来就怀疑硬件本身，更多时候是软件参数配置的问题。
6.3 工具链编译时间长到无法忍受
客户第一次拿到编译器，往往会遇到一个问题：编译一个大模型花40分钟，而英伟达几秒就完事了。这个现象背后是图优化能力不足——你的编译器用穷举法搜索最优排布方式，搜索空间太大，耗时自然惊人。
常见优化的思路是分层缓存：把算子的最优映射方案做成查找表，模型编译时直接套用；复杂融合策略只用在小范围子图上，不做全局搜索。经过优化后，编译时间应该能压到分钟级以内，这是客户愿意使用你芯片的底线之一。
7. 一些重要的补充思考
7.1 开源的ROI怎么算
新造AI芯片要不要用开源IP？很多团队在这个问题上摇摆。我对开源RISC-V核的态度是正面的，但不建议无脑用。RISC-V生态确实能省CPU子系统的授权费，但AI芯片的核心竞争点在NPU和工具链，CPU核的授权费用相比整体研发投入其实占比很小，更重要的是稳定性和技术支持的响应速度。
如果你用的是处理器只是做控制用（跑Linux、管理中断、调度DMA），用成熟商业IP风险更低。开源IP适合的场景是：团队有大量CPU架构经验，并且希望深度定制指令集来配合NPU调度。
7.2 人员和团队怎么配比
一个完整的AI芯片团队，大致需要这些角色：
- 架构师：1人，定方案、拆需求
- RTL设计：4至6人，前端设计和集成
- 验证：6至10人，验证往往比设计人多
- 后端：3至4人，综合和物理实现
- 软件：8至12人，编译器、驱动、算子库
- 板级与量产：2至3人
可以看到，软件团队通常比硬件人多一倍。如果按这个比例组队，你的项目才是健康状态。很多新团队把90%的人放在硬件设计上，软件只有一两个人，这是极度危险的信号。
7.3 造芯片是一次马拉松
无论在哪个细分领域，新造一颗AI芯片都像是跑一场马拉松。前期架构定义、中期验证、后期软件打磨，每一个阶段都有决定生死的问题。钱和时间都需要按“18个月没有芯片回来”来规划，心理预期也要按“流片一次可能不工作”来建设。
从我多年的体会来看，真正能把芯片做成的人，靠的往往是咬住最初定义的那个场景不放手的韧性。今天看到一个机会就改需求，明天看到热点就换场景，是AI芯片项目的头号死因。坚持住，先把一颗芯片做完整、做稳定，比什么都重要。
