新造一颗AI芯片：从场景定义到软硬协同的完整思考

最近不少朋友在聊AI芯片有的是做算法的想往硬件摸一摸有的是创业团队想找新方向也有的是投资背景的人想搞清楚一颗AI芯片到底难在哪。我自己在芯片和AI交叉这块做过几年被问得最多的一个问题其实是如果今天让我重新新造一颗AI芯片我会从哪里开始想这个问题听起来像是要讲架构、讲算力、讲工艺但我真实的感受是——真正决定一颗AI芯片命运的往往不是那些听起来很酷的技术参数而是在动手之前你有没有把场景、边界、软件栈和测试策略想明白。这篇文章我就把自己对于新造一个AI芯片的完整思考过程摊开聊一聊不写教科书只聊实际决策时会撞到的那些问题、怎么拆解以及我踩过的坑和总结出的排查思路。如果你正打算入局AI芯片或者只是好奇这个行业到底在忙什么这篇笔记应该有你能拿走的东西。1. 先回答一个问题为什么偏偏要新造一颗AI芯片1.1 需求端到底发生了什么变化聊新造芯片之前必须先聊需求。最近一两年AI的应用形态变化太快了大模型从云端一路往端侧跑各种AI相机、AI眼镜、AI玩具、AI助手都在出现工业生产线上开始大量用视觉检测医疗影像、农业监测、机器人控制都在找专用的AI算力方案。与此同时通用GPU虽然算力强但功耗高、价格贵、供应还不稳定很多场景根本用不起也用不上那么大的算力。我见过不少项目的真实情况是这样的一个做边缘设备的团队用的方案是通用SoC加NPU结果发现NPU的算子支持不完全很多自定义算子跑不起来换到GPU方案功耗又压不住。最后他们不得不考虑一颗专用的AI加速芯片把特定的网络结构、特定的精度需求、特定的接口都固化进去——这就是新造AI芯片最典型的驱动力。所以第一个要想清楚的问题不是我要做什么样的芯片而是我要解决谁的问题、在什么场景下解决。AI芯片不是越强越好而是越匹配越好。很多新造芯片项目失败不是因为技术不行而是因为一开始就没想清楚服务的场景到底是什么最后做出来一颗什么都能干但什么都不好用的芯片。1.2 四个约束条件决定项目生死在我自己评估要不要启动一颗新AI芯片时我会先画四个约束条件任何一个不满足项目风险都会急剧上升。第一个是算力边界。你得知道目标场景里算法跑起来需要多少TOPS每秒万亿次操作这里的TOPS不是纸面算力而是实际能跑到多少。很多芯片标称算力很高但实际利用率只有三四成因为内存带宽不够、数据搬运太慢、算子调度效率低。所以我会先做一轮算法摸底把目标网络在真实数据上跑一遍量出真实算力需求。第二个是功耗边界。芯片的功耗决定了它能放进什么产品里。做手机、耳机的芯片功耗预算可能就是几百毫瓦做边缘盒子可能三五瓦做服务器加速卡可能到几百瓦。功耗和算力是强耦合的你不可能在几瓦功耗下做出几百TOPS的芯片——除非牺牲精度、压缩存储、做大量稀疏化。功耗边界必须在立项时就想好不然后面架构设计会来回推翻。第三个是成本边界。芯片的成本包含NRE费用一次性工程费用主要是流片、封装、测试、验证和单颗成本。28nm一次MPW多项目晶圆流片可能几十万到上百万人民币7nm的full mask流片则是千万级别。如果你的目标产品一年只卖几千片那成本分摊会非常高芯片可能比里面的AI算法还贵。所以成本边界决定了你只能用什么样的工艺、什么样的封装、什么样的芯片尺寸。第四个是生态边界。这颗芯片问世之后用户要拿什么工具链来开发是支持PyTorch框架还是只能用手写汇编大部分人低估了生态的重要性——芯片好不好用很大程度上不是硬件决定的而是软件工具链决定的。如果没有一套能用的编译器、算子库和运行时算力再强也没人愿意用。这四个约束条件像一个漏斗缺了任何一个后面都会出问题。我在评估项目的时候通常不会先看架构图纸而是先把这四个条件写在一张纸上然后逐个去验证。2. 从场景到架构AI芯片的核心决策流程2.1 看清楚算法演进的方向再定架构AI芯片最怕的事情是花了三年流片出来结果算法已经换了一代核心算子全变了。远的不说几年前很多芯片还是围绕CNN卷积神经网络来设计的MAC阵列、卷积加速器一大堆结果Transformer一来变成了矩阵乘法和Attention计算为核心旧架构的效率直接打折。所以新造AI芯片之前一定要认真做算法演进的趋势判断。这个判断不是看论文标题而是看你目标客户实际跑的模型到底长什么样。我的做法是收集目标场景里近两年的主流模型结构统计它们的算子分布、张量形状、精度需求、内存访问模式。比如以Transformer为主的场景会特别看重矩阵乘法单元的效率、头数并行度、KV Cache的存储带宽以CNN为主的场景则更看重卷积核的复用率、量化误差控制、多通道并行。这里有个生活化的类比芯片架构有点像装修房子你请工人来砌墙之前得先知道这房子是用来住人还是开店的。住宅和商铺的水电走位、隔断布局完全不同装完了再改就是噩梦。算法趋势分析就是这个确认房子用途的步骤。2.2 架构选型不只有NPU和GPU两条路很多人一聊AI芯片就想到做一个NPU觉得NPU就是AI芯片的代名词。其实架构选型的路子宽得多关键在于你的需求约束。如果你的目标场景特别固定比如只做某个特定的检测模型那可以考虑ASIC专用集成电路路线。ASIC把电路逻辑完全固化为特定计算模式面积小、功耗低、能效比极高但没有任何灵活性算法一变芯片就废了。这种路线适合产品形态非常稳定、算法三年不换的场景。如果你的场景比较多样今天跑这个网络、明天跑那个模型那就要考虑类NPU的可编程架构。NPU本质上是把计算阵列做成可配置的通过指令控制数据流和控制流灵活性比ASIC高不少。现在成熟的AI芯片公司大多走这条路线因为AI算法还在快速演进完全固化风险太大。还有一条路线是FPGA加自研IP适合小批量、算法不固定、需要快速迭代的场景。FPGA开发周期短、不用流片但单价高、峰值性能不如ASIC。有些团队会先用FPGA做原型验证跑通了再去流片这是很稳妥的路径。我在实际工作中见过的最常见误区是团队一上来就要自研NPU架构花了大量精力设计数据流调度和指令集结果后来发现自己的业务场景用现成的IP核就能覆盖七八成需求。新造芯片不一定要从零开始造轮子很多基础模块完全可以购买成熟IP或者授权把有限的研发精力集中在真正的差异化部分。2.3 算力、带宽、存储的三角平衡AI芯片设计绕不开一个不可能三角算力、带宽、存储。算力决定你每秒能算多少次带宽决定你每秒能搬多少数据存储决定你能放下多少参数和中间结果。这三者必须平衡任何一项成为瓶颈整体性能都会塌陷。举个例子你做一颗算力50TOPS的芯片但如果DDR带宽只有20GB/s那么很多模型跑起来计算单元大部分时间在空等数据实际吞吐率可能只有标称的三成。业内常说内存墙问题就是这个意思。解决思路有几个方向一是增加片上SRAM或者Cache把数据尽量放在离计算单元近的地方二是优化数据流调度让数据复用率提高三是用HBM这类高带宽存储但成本和封装复杂度会显著上升。我建议在架构设计阶段就做一次粗粒度的性能建模仿真把算力、带宽、存储三个参数放到同一个模型里跑一跑。别等技术细节都定完才发现带宽不够到时候改架构的成本就不是改个参数那么简单了。这里尤其要注意片上存储容量这个数字很多AI芯片标称算力很强但片上存储只有几MB跑大一点的模型时频繁从外部存储器取数性能断崖式下跌。3. 软硬协同经常被低估的另一半战场3.1 没有软件栈的AI芯片只是一块昂贵的石头我见过太多硬件很强但没人用的AI芯片了。它们算力不差功耗不高但开发者拿到手里发现SDK文档残缺、编译器不支持自定义算子、调试工具三天两头出bug最后只能放弃。硬件出货量上不去生态建设资金不足软件越做越差恶性循环。所以新造一颗AI芯片必须在第一天就把软件栈当成和硬件同等重要的部分来规划。软件栈通常包含这么几层编译器把PyTorch/TensorFlow的模型图转换成芯片指令、算子库高性能的卷积、矩阵乘、归一化等实现、运行时任务调度、内存管理、多核协同、上层SDK和调试工具。每一层都有大量工程细节。我的经验是软件工具链的研发量往往不亚于硬件设计甚至更耗人力。因为硬件设计有明确的标准流程而软件要适配的框架、算子、用户需求千变万化。很多团队早期对软件投入不足校准了硬件的每个细节却在软件层大面积欠债最后产品落不了地。3.2 编译器与算子库的实际矛盾编译器是AI芯片软件栈里最硬核的部分也是问题最多的地方。现在的AI模型大多是计算图形式编译器要做的事情是把图里的算子映射到芯片的计算单元上同时做算子融合、内存规划、循环变换等一系列优化。算子库则是手工优化的高性能实现。为什么要手工优化因为很多关键算子的最优实现编译器还做不到。比如一个7x7的卷积怎么拆分到多个计算核上、数据怎么排布、累加精度怎么处理这些东西编译器很难自动找到最优解需要人来写。所以业内通常的做法是编译器算子库混合常用算子用手工优化好的库自定义算子走编译器生成路径。这里最容易踩的坑是算子库覆盖不全。算法工程师在模型里用了某个不太常见的算子芯片的算子库不支持编译器生成的代码又很慢项目就得卡在那边。实务上我会提前准备一份算子覆盖矩阵把业界常用的几十个算子逐一列出来和目标算法比对缺什么尽早规划人工开发。别忘了把自定义算子的可扩展性写进架构需求里让开发者能自己接入新算子而不是等芯片公司发版。3.3 AI工具与辅助手段正在改变设计流程这几年我有一个很明显的感知芯片设计本身也在被AI改变。搜索到的热词里和AI辅助、专利辅助相关的讨论很密集这说明行业里已经有一批人在用AI工具辅助做芯片设计了。我自己试过的场景包括用AI模型辅助生成测试激励自动补全验证代码里的边界用例用AI辅助做静态时序分析的脚本优化从大量日志里快速定位时序违例路径还有用AI做版图热分析的初步筛查提前发现热点区域。这些工具目前还不能替代资深工程师的判断但在提升效率上是实打实的。在做专利相关的调研时AI辅助检索的价值也很明显。新造芯片涉及大量IP核和专利布局传统检索要翻海量文档用AI做语义检索和聚类分析能节省大量时间。不过要提醒的是AI检索结果一定要人工复核特别是涉及侵权风险评估的时候不能只依赖工具。4. 从设计到芯片落地后端流程与测试避坑实录4.1 后端设计不是画完版图就结束芯片的前端设计主要画逻辑后端设计则要把逻辑变成物理版图。很多新入行的朋友以为后端就是软件工具的自动流程跑完就完事实际远没那么轻松。综合、布局布线、时钟树综合、静态时序分析、物理验证、功耗分析、信号完整性分析每一关都可能让你回头改前端代码。这里分享一个我真实踩过的坑有一版设计前端仿真功能完全正确但到了布局布线阶段由于一条关键路径走线过长时序收敛不了只能降低芯片运行频率结果算力指标不达标。后来排查发现是前端设计时没有充分预估物理实现的难度把一个逻辑上很紧凑的设计排布到物理上却跨越了多个区块。从那以后我在前端设计评审时一定会拉上后端工程师一起看把物理可行性尽早纳入考量。工艺选择也是后端阶段必须做决策的先进工艺如7nm、5nm性能好、功耗低但流片费用极高设计规则复杂成熟工艺如28nm、40nm便宜、可靠、周期短但性能和功耗受限。AI芯片的工艺选择要看目标场景不是越先进越好。之前提到的成本约束在这里会发挥决定性作用——一颗在28nm上能跑的AI芯片没必要非去7nm凑热闹除非功耗和面积真的压不住。4.2 芯片测试的几个关键环节芯片流片回来之后测试是另一场硬仗。我先说一下测试的几个层次晶圆测试CPCircuit Probing是在晶圆上直接测每颗die的好坏封装测试FTFinal Test是封装后再测成品功能系统级测试SLT是把芯片装到实际板子上跑真实场景验证。AI芯片的测试难点在于算力验证和可靠性验证。算力验证需要构建大量的计算测试向量跑各种算子、各种精度的组合确认识别标称值是否一致。可靠性验证则要考察芯片在不同温度、不同电压下的表现。常见的测试项目包括看门狗功能、时钟稳定性、电源纹波、引脚连接完整性、存储器的读写稳定性、上下电时序等。我特别提醒一下芯片启动和引脚检查的细节。芯片到手后第一步往往是确认供电、时钟、复位、启动配置引脚都正常尤其是第一脚Pin 1的定位和连接问题——别笑我见过不少工程师因为引脚顺序看反了把芯片烧了或者压根点不亮。不同封装的第一脚位置标识方式不一样最好对着封装图纸核对三遍再上电。电源管理也是AI芯片测试的重灾区。很多AI芯片在跑大算力负载时电流变化剧烈如果电源设计没做好纹波会严重影响逻辑稳定性。我习惯在测试板上预留足够的电源测试点方便用示波器直接测量各路电压的纹波和瞬态响应。还有一个小提示看看门狗Watchdog电路时除了功能测试建议测一下看门狗超时后是否真的能复位整个系统这个场景很多芯片的看门狗实际效果和datasheet描述有差距。4.3 从SOC平台到周边芯片配合的完整视角新造一颗AI芯片从来不是孤零零造一颗裸核而是要放进一个完整的系统里。芯片要能和周边的存储芯片、电源管理芯片、接口芯片、传感器等协同工作。举个例子AI芯片通常需要高速接口去接摄像头或者连接主控这时要留意信号完整性和电平匹配。实际中常用的e-Marker芯片就是给USB线缆做身份识别的如果你设计的AI芯片要用在USB4或者雷电接口的系统中这个细节就得提前考虑。再比如板级电源芯片的选择很多工程师喜欢用常见的升压/降压芯片比如各种型号的Buck芯片、LDO芯片但要确认它们的纹波特性、 load transient 性能是否满足AI芯片的大电流需求不然摄像头取图、NPU算力全开时电压跌落会导致系统复位或者计算错误。还有看门狗芯片、复位管理芯片、RTC电池、启动配置电阻这些配角看起来不起眼实则在系统稳定性里承担着重要角色。我自己一次项目的惨痛经历是芯片功能完好但因为看门狗芯片的上拉电阻选错了阻值导致系统间歇性重启排查了整整两周。所以做系统设计时不要忽视这些小芯片的选型和测试。5. 常见问题排查与避坑技巧速查5.1 芯片点不亮、连不上、跑不对的排查清单我把AI芯片开发中问得最多的问题做一个速查清单都是实践中高频出现的问题表现可能原因建议排查方法芯片完全没反应供电没起来 / 复位引脚被拉死先测各路电源电压是否正常、复位信号时序是否正确仿真器连不上时钟没起来 / 引脚定义不对用示波器看时钟引脚是否有波形检查 Pin 1 及 JTAG/SWD 引脚接线程序跑飞或异常复位看门狗超时 / 电源纹波大检查看门狗配置测各路电源纹波必要时调整去耦电容算力跑不满存储带宽瓶颈 / 调度策略差用性能剖析工具查看计算单元利用率优化数据在存储层次的分布模型推理结果不对算子映射错误 / 精度丢失逐步对比中间张量定位第一个异常算子是关键这套清单是我做芯片调试时的主路线大多数问题都能从这张表里找到起点。遇到问题时别慌先缩小范围——是供电问题、时钟问题、还是逻辑问题再对症下药。5.2 软件栈和模型迁移的典型卡点新造AI芯片出来之后用户做的第一件事往往是把我的模型跑起来。这时候最容易卡住的几个点提前知道能省大量时间第一个是框架版本兼容性。用户可能用PyTorch 2.0甚至更新的版本训练模型如果芯片的编译器只支持旧版本转换工具链就会报错。解决方案是尽量兼容主流框架的稳定版本并且持续跟进更新。第二个是量化精度问题。AI芯片为了提升效率通常会做INT8甚至更低精度的量化但量化之后模型精度可能会下降。常见的处理办法是先做敏感层分析对敏感层保持FP16或INT16计算再对不敏感层用INT8。这个校准过程需要经验和耐心。第三个是自定义操作符的支持。用户模型里只要有一个原生算子库不支持的算子整个模型就可能跑不起来。所以我建议新造芯片时算子库要尽可能覆盖Transformer全家桶、卷积全家桶、各种归一化和激活函数同时预留自定义算子接入的API。5.3 测试环节的三条独家建议最后说几条从实践里沉淀下来的测试建议这些建议不太会写在官方文档里但很能救命第一条一定要做边界电压和边界温度的测试。很多时候芯片在常温常压下一切正常但到了高温、低电压边界就跑不动了。AI芯片的功耗大、发热快如果散热设计不足芯片温度上去之后性能会明显下降甚至触发降频保护。我习惯在测试阶段专门做一轮极限烤机测试把芯片放到高温环境下同时以最大算力长时间运行验证热管理方案是否靠谱。第二条留足测试接口和调试探针。设计测试板时别省这些引出点。JTAG/SWD接口、串口日志、各路电源测试点、关键信号测试点能引出来就尽量引出来。芯片出问题的时候每一个测试点都可能帮你在黑暗中找到方向。第三条采购和物料管理要有冗余。芯片项目周期长中间可能反复流片、反复焊接。同一颗料在不同批次可能存在微小差异我都建议把每个批次的芯片保留几颗存档方便日后比对。另外对于静电敏感的芯片焊接和工作时一定注意防静电措施我见过太多芯片不是用坏的而是静电打坏的。我的个人经验体会如果真的让我重新开始一个新造AI芯片的项目我的优先级排序会是这样第一步花最多时间定义场景、理解算法演进趋势、量化真实算力需求第二步决定架构方向和工艺选型把带宽、存储、功耗的平衡表做透第三步成立软件团队让工具链开发和硬件设计同步跑起来第四步才进入真正的前端RTL设计。一步走扎实了再走下一步比上来就画框图要靠谱得多。另外我想特别强调一点AI芯片虽然听起来是芯片但它本质上是为AI服务的系统。一个优秀的AI芯片团队既要有懂硬件的人也要有懂算法的人还要有懂系统软件的人三者缺一不可。如果你现在正在组队或者正考虑加入AI芯片相关的项目记住技术参数只是入场券真正的分水岭在软硬协同能力上。最后分享一个小技巧在做芯片规格定义时建议把未来一两年的算法变化纳入考虑比如把冗余算力留出20%到30%的余量、支持动态精度切换、预留扩展接口。这些余量会在产品生命周期里给你带来巨大的容错空间。新造AI芯片是一条长路学会给未来留余地才能走得更远。