1. 先想清楚新造AI芯片到底要解决什么问题AI芯片这四个字这两年已经被聊到快起茧了。但真到“新造一颗”的层面大多数人第一反应是堆算力、追制程、对标某家头部产品这其实是最容易走偏的地方。我自己在这个圈子里摸爬滚打了十几年见过太多团队拿着好技术却死在了需求错位上——芯片做出来了客户用不上或者客户要的芯片做不到。所以聊新造AI芯片之前我特别想先把“问题定义”这个环节拎出来说透。1.1 需求驱动比技术驱动更重要场景决定架构芯片行业有一个很容易被忽视的规律一款芯片的成功技术只占三成剩下七成在于它能不能精准命中某个真实场景的痛点。新造一颗AI芯片第一件事不是研究该用7nm还是5nm也不是纠结算力要做到多少TOPS而是先回答三个问题这颗芯片给谁用跑什么模型在什么功耗和成本约束下工作举个例子同样是AI芯片云端训练芯片和边缘推理芯片的设计逻辑几乎是对着干的。云端训练要求极高的并行计算能力和超大存储带宽对功耗相对宽容边缘推理则恰恰相反功耗、面积和成本都是硬约束性能反而要往后靠。如果你把这两个场景混在一起设计最后大概率做出来一颗两头不讨好的芯片——跑训练算力不够跑推理功耗又压不住。这里我建议大家做一个非常务实的动作把目标场景的模型结构、数据流特征、算力需求、带宽需求全部量化成一个“需求清单”。比如做自动驾驶芯片就去采集实际跑过的感知模型记录每个卷积层、Transformer层的计算量和访存量做AIoT芯片就要明确跑的是哪种轻量化模型量化精度能接受多少损失。这张清单是所有架构决策的起点。1.2 从AI工作负载看芯片设计的三个核心约束把需求梳理清楚之后就进入了AI芯片设计的核心矛盾。我做了一张图在脑子里存了很多年——AI工作负载有三个核心约束相互拉扯算力、带宽、功耗。算力好理解就是MAC阵列乘累加单元阵列能跑多快的问题。但算力堆上去之后带宽跟不上计算单元就一直在“空转”等数据带宽解决了功耗又可能爆掉。这三者的关系就像木桶效应短板决定整体表现而且彼此之间还会互相制约。经典的做法是在架构层面解决这三者的矛盾。过去十年AI芯片架构演进有一条主线就是为了在算力和带宽之间找平衡从早期靠增大片上SRAM缓存来减少对外部存储的访问到后来发展出数据流Dataflow架构通过改变数据在计算阵列中的流动方式来复用数据尽可能减少搬运。我见过不少团队一上来就堆算力结果流片回来带宽墙死死卡住实际利用率只有30%——这个坑踩过的人应该都有共鸣。对于新造AI芯片我始终强调一个观点先有场景和约束后有架构和算力。芯片不是一个可以“先做出来再找市场”的产品它的研发周期动辄两三年等不起也改不起。2. 架构选型主流AI芯片路线的对比与决策2.1 从GPU到NPU再到ASIC三种主流路线各有各的算盘现在市面上能看到的AI芯片方案无外乎三大路线通用GPU路线、NPU神经网络处理器路线、以及ASIC专用定制路线。这三条路线没有绝对的好与坏只是在“通用性”和“专用性”的坐标轴上各居其位。GPU路线最典型的就是NVIDIA的A100、H100系列。它的底子是图形处理架构但通过引入Tensor Core等专用单元把矩阵乘法的效率做到了极致。GPU最大的优势在于生态成熟——CUDA平台积累了海量开发者任何新模型出来几乎当天就能在GPU上跑起来。自己造GPU这种路线难度在于必须同步搞定CUDA级别的软件生态这比芯片本身的难度更大。NPU路线是当前国产AI芯片最主流的选择也是我认为对新玩家最友好的切入点。NPU的本质是面向神经网络的计算流做架构优化比如高通、联发科手机SoC里的AI引擎以及各种云端推理芯片。NPU不需要兼容GPU那样几十年积累的图形生态只需要围绕AI算子优化。它的设计自由度更高可以从数据流、存储层次、计算精度等多个维度做定制做出差异化特征。ASIC路线则是把场景锁定到极致比如Google的TPU。TPU从第一代开始就明确“我只是为了跑推理/训练而生的”把一切与AI无关的功能全部砍掉换来极致的能效比。ASIC的局限也非常明显一旦算法范式变化硬件就面临淘汰风险。比如Transformer大模型兴起之后很多为CNN设计的ASIC直接失去了用武之地。2.2 对新造AI芯片创业者的现实建议综合来看如果今天有一个新团队找我问“应该选哪条路”我的建议非常明确除非你有极强的软件生态积累否则不要碰通用GPU除非你有非常确定的长期场景且算法演进慢否则不要一上来就做纯ASIC。最稳妥的切入点是NPU路线而且最好是“半定制”的思路——计算单元面向主流模型做优化同时保留一定程度的可编程能力方便适配新的算子。这个思路的核心在于“跟随主流但留有后手”。现在大模型是绝对的主角Transformer架构成为事实标准那么芯片架构就应该围绕Transformer的特征来设计支持大矩阵乘法、支持长序列的并行解码、针对注意力机制优化带宽调度。但同时CNN和传统NLP模型在存量市场仍然大量存在所以计算单元不能在架构上完全锁死。我经常给团队打一个比方做AI芯片架构有点像开餐厅。你可以开一家只做招牌菜的店纯ASIC效率极高但客人选择少也可以开一家大而全的饭店通用GPU什么菜都有但招牌菜未必突出最聪明的做法是开一家“招牌菜极强、但也能做家常菜”的餐厅——这就是NPU半定制路线的精髓。3. 硬件核心设计算力、带宽与存储的平衡术3.1 算力不只是TOPSMAC阵列和实际利用率才是关键很多芯片发布会喜欢标一个非常亮眼的TOPS数字但懂行的人都知道这个数字里面水分太大。TOPS是理论峰值算力而实际能达到的算力取决于一个关键指标MAC阵列利用率。以我见过的芯片为例标称算力100 TOPS实际跑ResNet可能只能达到60%-70%跑Transformer可能只有40%-50%遇到动态形状的输入甚至更低。MAC阵列利用率为什么这么难做上去核心原因还是数据喂不饱计算单元。一个典型的AI芯片内部计算单元是一块巨大的二维阵列每个周期要执行成千上万次乘累加。但计算单元所需要的数据如果不在最近的SRAM里就要从更远的内存层次去搬而搬数据的速度远低于计算速度于是计算单元大量时间都在“等待数据”。解决这个问题的核心思路叫“数据复用”。举个例子一个卷积核在一个特征图上滑动时中间的计算结果可以被多个输出位置复用。如果架构上设计好了数据流让数据在被计算完之后尽可能多地留在片上给后续计算用就能显著减少访存请求。具体实现方式包括权重固定Weight Stationary、输入固定Input Stationary、输出固定Output Stationary等数据流方案每种方案适合的场景不一样。我见过一些团队在这一层面的优化做得很好只用一半的MAC阵列就能打平对手满阵列的效果这就是架构设计的价值。3.2 存储墙问题为什么HBM和大缓存缺一不可存储墙是每一代AI芯片都绕不过去的坎。单颗HBM高带宽内存能提供几百GB/s到数TB/s的带宽但成本极其昂贵而且封装难度大。更现实的问题是外部存储带宽即使做得再高也远赶不上计算阵列的消耗速度。因此片上存储层次的设计往往决定了芯片最终性能的上限。我自己做架构设计时有一个经验值对Transformer类的推理负载片上SRAM至少需要把单个batch的中间激活值装下。假设一个7B模型的KV Cache在推理时占用几十MB那么片上缓存至少要做到几十MB量级否则每个Token生成都要回外部存储器拿数据性能会断崖式下降。这也是为什么新一代AI芯片都在拼命加大片上SRAM——某些高端芯片的片上存储已经做到几十MB甚至上百MB。另外一个重要技巧是减少“中间激活”的存储开销。Transformer的层数很深每一层都有巨大的中间结果需要暂存。业界目前的一个主流做法是“算子融合”把多个计算操作融合成一个kernel在计算过程中尽量保持数据在寄存器或L1 cache里避免把中间结果写回外部存储。这个技术看起来是软件层的优化实际上它倒逼了硬件的可编程性设计——芯片必须支持灵活的数据流调度才能实现有效的算子融合。3.3 互联设计与“解放算力”的最后一公里如果算力、存储都解决了还有一块硬骨头摆在面前芯片与芯片之间、片内计算核之间的互联。大模型训练和超大batch推理几乎必然是多卡协同互联带宽直接决定多卡效率。这里我想插一个实操经历有一次我们测一款自研芯片单卡跑ResNet-50性能完全达标但一上多卡数据并行训练效率直接掉到单卡时代的65%。排查了半天发现问题出在互联接口上的同步机制——核间通信在等待同步信号时浪费了大量时钟周期。后来我们在硬件里加了异步流水线机制多卡效率才拉回到接近线性加速的水平。这个问题的本质是算力再强如果数据搬来搬去的时间占比太高整体效率就上不去。对互联设计我的建议是优先关注两点一是高带宽低延迟的片间通信接口比如目前主流的类NVLink方案或CXL接口方案二是通信协议的硬件卸载能力尽量把数据搬运和同步逻辑下沉到硬件减少主控CPU的参与。4. 软硬协同AI芯片的隐藏战场4.1 没有编译器芯片只是一块昂贵的镇纸这是我最想强调的一个观点也是不少AI芯片团队栽过跟头的地方。很多团队花两年时间把芯片做出来了结果SDK和编译器一团糟模型根本跑不起来——芯片在实验室里可能表现优异但客户做不了任何实际工作。编译器的核心任务是把深度学习框架里的模型图Graph映射到底层硬件指令上。一个高效的编译器要做到三件事第一把算子拆分并映射到合适的计算单元上第二调度数据流让数据尽可能在片上复用第三自动做算子融合和内存分配优化。这三件事每一件都极其复杂。我见过一个实际案例同款芯片官方编译器生成的代码只能达到理论性能的45%而一个团队花了三个月手写kernel关键算子把性能拉到了85%。这中间的差距就是编译器的价值空间。对于新造AI芯片的团队我建议在硬件设计阶段就把编译器团队拉进来而不是等芯片快流片了才开始写编译器。编译器决定了芯片能否被客户真正用起来它的开发周期不比硬件短。芯片界有个老话叫“软硬协同”但在AI芯片时代这句话的分量比任何时候都重。4.2 算子库与基准测试空口无凭跑分见真章除编译器外算子库Kernel Library是另一块拦路虎。算子库是预先优化好的底层函数集合相当于给上层框架和开发者提供“积木”比如卷积函数、矩阵乘法、归一化、激活函数等。一个完整的算子库需要覆盖至少几十个常用算子而且每个算子都要针对不同shape、不同数据类型做极致优化。这里分享一个常见的“陷阱”想用benchmark数据对外宣传芯片性能但benchmark模型往往需要配套的优化算子才能发挥实力。如果算子库不全或者优化不到位跑出来的benchmark数据就会很惨。所以我的习惯是在项目立项时就把算子库的覆盖面列入验收标准至少覆盖PyTorch和ONNX Runtime中95%以上的常用算子并对头部模型全流程跑通做验收。另外千万不要忽略量化支持。目前主流推理芯片都支持INT8和FP16新造芯片至少要支持这两种精度的原生计算。现在大模型推理还流行FP8、INT4这类更激进的低比特量化这些都会影响硬件的指令集和数值格式设计必须在芯片定义阶段就想清楚而不是等流片后打补丁。4.3 生态兼容是走捷径还是自建平台“生态”这个词在AI芯片领域几乎等同于“未来”。一个新芯片要融入现有的AI软件生态最务实的路径是兼容主流框架。目前来看抽象层次有两个选择一是兼容到图编译器层面比如对接ONNX Runtime或TVM让模型可以无缝转换二是兼容到底层接口层面比如提供类PyTorch的算子接口。从我的实操经验来讲AI芯片团队最容易在产品早期犯的错误是“过度自建生态”。明明客户用PyTorch训练好的模型你要他为了你的芯片去学一套新框架这个学习成本大到足以劝退客户。正确的策略是“顺应为主差异为辅”核心对接PyTorch等主流框架保证客户模型可以“无感”迁入极少数的差异化能力比如特殊算子的硬件加速再作为可选项开放。5. 从流片到量产AI芯片落地的最后一步5.1 流片成本与风险控制的现实考量流片是整个芯片项目中最紧张、也最花钱的环节。先进工艺的一次MPW多项目晶圆流片费用动辄数百万美元Full Mask全掩模更是千万美元起步。对创业团队来说流片之前必须做足风险控制否则一次失败就可能拖垮整个公司。我见过多个团队总结下来降低流片风险有三大抓手第一尽可能在FGA现场可编程门阵列上做充分的验证先把数据通路、控制逻辑、软件栈全部在FPGA上跑通再开始物理实现第二重视仿真覆盖率和随机验证用例设计关键模块的功能覆盖要到95%以上第三预留DFT可测试性设计接口包括扫描链、BIST内建自测否则芯片一旦出问题连定位故障的手段都没有。还有一点是关于工艺选择。新造AI芯片不一定非要用最先进的制程。对于推理场景28nm到12nm的成熟工艺配合优秀的架构设计在很多情况下能做到和先进工艺相近的功耗表现。先进工艺的性能红利毋庸置疑但开发和流片成本也是指数级上升。我自己倾向于“性能目标反推工艺选择”设定好功耗和算力指标再评估哪个工艺节点可以达标且成本最低。5.2 客户验证阶段真实场景才是最好的试金石流片回来之后很多团队会松一口气但实际上最考验人的阶段才刚刚开始。芯片点亮、跑通测试程序这只是从0到1真正从1到N是让客户在自己的真实场景里跑起来。这一步我建议重点准备两样东西一个开箱即用的参考设计板卡一个带全套工具链的SDK交付包。客户拿到手后最好24小时内就能跑通一个示例模型。我踩过的一个坑是我们的芯片在自研开发板上性能很漂亮但客户在自己的硬件主板上怎么都跑不出同样效果。最后排查发现是供电设计问题——参考板用的电源模块品质较好客户的量产方案则选用了低成本电源模块在高负载时电压跌落导致频率自动降下来了。这就提醒我们芯片级验证时就要覆盖“客户可能出现的各种恶劣环境”最好在芯片内部加电源监控和时钟节流机制在性能下降时主动报警而不是默默降频。另外一个经验在客户验证阶段不要只展示跑分一定要跑对方真实场景的最小闭环用例。比如做AI摄像头芯片就带一个真实的端到端人脸识别演示做语音芯片就带完整的唤醒-识别-响应链路。客户看到真实场景的效果比看几百页PPT都管用。5.3 量产和新品迭代从追赶到建立护城河芯片一旦通过客户验证马上又要进入量产环节。量产没你想的那么简单——良率爬坡、封装测试、批次一致性、供应链管理每一个环节都可能导致交付延迟。这里我特别想说一下产能规划很多AI芯片创业公司在量产阶段才意识到代工厂的产能不是你想排就能排的尤其先进制程产能紧张时提前一年就要锁定产能。这不算技术问题但确实是很多技术团队容易忽略的经营问题。再说迭代第一款AI芯片从立项到量产往往需要两到三年而AI模型可能每半年就更新一次。所以芯片架构一定要有前瞻性。我建议在做第一颗芯片时就规划好第二代产品的方向在架构上预留扩展接口比如增加对稀疏计算的支持、增加对动态形状模型的处理能力。芯片不像软件可以随时发补丁它的灵活性体现在架构设计的“预先留白”上。6. 踩过的坑与经验复盘给新造AI芯片团队的几点忠告6.1 五个最容易被低估的问题我把自己和同行们经历过的各种教训梳理了一下选出五个最典型、也最具共性的问题写成了一份“避坑清单”大家可以对照着自查问题典型表现建议对策软件栈开发启动太晚硬件流片前编译器还没启动软硬件团队同步立项软件先行过信基准测试实验室跑分和客户实际体验差距大用客户真实模型做验收基准存储带宽评估不足实际运行中计算单元大量空转用Roofline模型前置测算瓶颈功耗预估偏低实测功耗超规格散热方案失效建立功耗BOM表流片前反复建模团队沟通壁杆架构、软件、应用各做各的建立跨职能例会统一目标语言这里特别想展开说一下Roofline模型。它是一个非常经典的分析工具用来直观地判断一个负载在给定硬件上是“计算受限”还是“带宽受限”。横轴是计算密度单位数据量的计算次数纵轴是可达性能。如果你的模型工作负载落在了带宽受限区那么就算再加MAC阵列也毫无意义应该优先解决带宽问题。这个工具在架构评估阶段简直到处都用得上强烈推荐团队里人人都能画一下。6.2 从第一颗芯片到持续成功的自然法则最后我想分享一个个人体会。做AI芯片本质上是在做一件“长跑”的事。第一颗芯片的成功只是一个起跑点真正拉开差距的是后续的系统能力有没有一套可持续演进的架构路线软件栈能不能跟上模型迭代速度供应链能不能稳定保障这些都不是一次流片能证明的而是需要团队持续投入、不断沉淀。在我参与过的项目里最让我惋惜的不是技术上的失败而是一些团队在拿到流片成功后陷入“虚假的安全感”以为芯片做出来就大功告成了结果产品和市场严重脱节最后被快速变化的模型生态和客户需求抛弃。新造AI芯片这件事门槛高、周期长、风险大但很值得做——因为算力在今天已经不只是技术问题而是实实在在制约AI落地的瓶颈。如果有人问我的建议我会说先想清楚场景和约束把编译器当成芯片的一部分来设计用真实客户模型来验收你的芯片。把这些基础打牢再谈架构创新和算力突破。这是我个人在实操中最深的体会也是我想重点分享给后来者的经验。
