每次听到有人说“新造一个AI芯片”我的第一反应不是兴奋而是先想追问一句你到底想解决什么问题这不是抬杠。AI芯片如今的局面并不是没得选而是选择多到泛滥在这种情况下还选择“新造”本质上是在做一个反共识的决定。反共识的决定如果只是赌大厂没看到机会那基本是误判真正值得折腾的是那些系统集成商、算法团队或垂直行业用户希望定制底层能力但市面产品又够不到的死角。这篇不聊PPT式的“国产替代”“算力翻倍”之类口号聊的是一个工程团队在决定“新造AI芯片”后真正要面对的东西场景怎么切、架构怎么取舍、软件栈怎么配套、验证和量产怎么过关。尤其是那些看似不起眼、却能让项目多烧一年时间和几千万流片费的问题。1. 新造之前先把三个“反共识问题”问明白1.1 场景边界没有边界就没有任何一条取舍的依据“新造”最大的风险是造出一颗“什么都能做但什么都做不深”的芯片。我在不少项目里见过一种没有边界的定义方式既要跑视觉模型又要跑语言模型还要兼容未来的多模态甚至希望训练和推理通吃。听起来覆盖面很大落到架构层面就是灾难——计算单元、存储层次、互联拓扑全都在互相打架。聪明的做法是先把场景写死写成一页纸的约束清单。比如只做端侧推理那么聚焦INT8量化、低功耗域、固定batch的吞吐优化很多昂贵机制直接砍掉如果是数据中心推理重点变成高带宽、高并发、动态shape处理如果是训练场景就要考虑梯度同步、多卡互联、BF32/TF32这类高精度计算路径。场景边界直接决定了一个最核心的参数MAC阵列的形态和精度组合。如果负载里95%是线性层和卷积部署一个大规模对称MAC阵列是合理的如果还有不少稀疏场景比如推荐系统、图神经网络就要加入结构化稀疏支持或者至少保证零值能跳过。没有边界后面每一条设计决策都会被反复争论。我在设计评审里见过最浪费时间的事就是两个小组对同一块片上存储区的分配争论一个月最后发现根源是产品定义时根本没有明确“主负载是A类还是B类”。所以新造芯片的第一个共识不是选什么制程而是先回答这芯片第一天上量时跑的是哪几个模型1.2 用“真实吞吐”估算规模而不是被峰值算力忽悠很多团队在立项时喜欢喊一个很响亮的峰值算力数字比如100Tops、200Tops。这个数字很容易算MAC数量乘以频率再乘以2就完事了。但峰值算力只是理想状态下的数学上限实际能跑出来的吞吐往往只有它的三分之一到十分之一。问题出在访存上。深度学习计算有一个很基础也很容易被忽略的指标叫算术密度arithmetic intensity单位是每字节访存对应多少算力操作。一个矩阵乘法如果权重和激活从片外读一次就用一次那性能瓶颈根本不在MAC阵列而在片外带宽。这也是为什么做AI芯片的人经常说真正的设计目标不是“算得快”而是“数据喂得饱”。估算真实吞吐有一个很实用的粗略办法先列出目标模型每层的计算量和访存量算出整图的带宽需求再对照你能提供的HBM或LPDDR带宽看瓶颈在哪一层。接着把存储复用、算子融合和片上调度考虑进去重新估算。这个过程在立项阶段就要做不能等RTL写完了再用仿真去发现。我用Roofline模型给过一个相对极端的案例一颗设计指标做到50Tops INT8的芯片完整跑一个推荐模型时由于嵌入表查表密集、权重复用率极低实际吞吐只有8Tops左右。问题不在MAC阵列不够而是带宽预算从第一天就不够。这类问题一旦在架构定义期没发现后面只能靠加大SRAM容量和做算子调度去硬补成本极其高昂。1.3 模型迭代节奏 vs 芯片研发周期的结构性错位芯片从定义到量产通常是18到30个月但模型结构的变化周期可能只有6到12个月。这类错位是所有“新造AI芯片”最难解决的时间账。你在2019年按CNN主导的负载定义架构到2021年模型市场可能已经被Transformer占领之前做的很多定点优化、数据流调度模式全部作废。应对这种错位不是追求“芯片能跑一切模型”而是在架构上保留一些软可扩展的接口。比如指令集层面预留可扩展的编码空间算子库层面做一层通用抽象片上调度器支持可配置的数据流模板。还有一个很实际的经验不要把一个加速器做成只能执行固定形状的卷积引擎要保证从外部能动态传入张量的形状、步长、内存布局。很多实际落地的加速器就是在“硬件固定但参数可配置”的中点上站稳的。如果这些约束在新造之前没有想透后面大概率出现一种尴尬局面芯片流片回来算法团队已经换了另一套模型结构加速器只能以极低利用率硬跑最后还是回到了CPU和GPU上。那个场面比流片失败还难受。2. 算力、带宽与存储的三角账架构层的第一道分水岭2.1 算力单元选型脉动阵列、通用PE还是近存计算AI芯片的算力单元并没有统一解常见选项是三类脉动阵列、通用处理单元PE和近存/存内计算。三者各有明显代价选择本质上是拿面积和灵活性做交易。脉动阵列Systolic Array是过去几年数据中心AI芯片最喜欢用的结构它的核心思路是让数据在PE间定向流动同一份数据可以被多个PE复用从而大幅降低寄存器搬运和访存压力。优势是规则、高效、面积利用率高短板是稀疏处理极差——如果矩阵里有一半是零脉动阵列仍然会傻算除非你额外设计跳过逻辑但跳过逻辑本身就增加了面积和功耗。通用PE阵列更容易支持复杂控制流和多样化算子但在高并发矩阵乘上效率明显不如脉动阵列因为每个PE都要独立取指令、管理数据。近存或存内计算把计算放到了存储单元里理论上能解决带宽瓶颈但工艺复杂度高、模拟电路占比大小团队没有足够的器件背景最好不要碰。从工程经验看绝大多数AI芯片项目的合理组合是“以脉动阵列或类脉动结构做矩阵引擎 少量通用向量核兜底”。这等于用一块高密度专用硬件覆盖80%的计算量再用通用核处理剩下的形状不规则、控制流复杂的算子。比例怎么定要拿你目标场景的算子profile统计绝对不能拍脑袋。2.2 片上存储SRAM永远不够用但问题不只容量AI芯片里SRAM的地位很微妙它比寄存器和缓存大又比HBM和LPDDR快是填补计算单元与外部存储器之间速度落差的关键。但几乎所有新团队都会在片上存储上栽跟头因为它面临的不只是容量问题还有分配问题。容量上一个比较实用的估算维度是“每Tops算力匹配多少MB片上存储”。低精度稠密推理可能需要每10Tops配4到8MB SRAM大型稀疏模型则可能需要更多用来缓存嵌入表和中间激活。这背后其实是一个复用率约束如果每份数据在片上只能被用一次SRAM再多也白搭因为瓶颈还是外访带宽如果一份数据能被反复用很多次较小容量的SRAM也能支撑很高吞吐。分配问题往往比容量问题更隐蔽。同一块SRAM到底给权重、给激活、给中间计算结果还是给指令/描述符怎么分bank不同bank之间会不会冲突这些设计直接决定调度器能不能在每拍打满数据带宽。很多团队在仿真里看到的利用率很高一到FPGA或流片回来就掉链子原因往往就是多bank访问冲突没仿真出来。一个建议是立项阶段就建一个非常细的存储带宽模型按SRAM bank数、端口数、读写冲突概率模拟目标算子在真实调度下的吞吐上限。别看这个模型粗糙它能在你写出第一行RTL之前就把“存储子系统”这条最容易翻车的路提前验证掉。2.3 片上互联与NoC机房Mesh不是万能药算力单元和存储之间需要一片网络把它们连起来。做小规模设计可能一组AXI互联总线就够了做到几十个PE的规模多层级总线或片上网络NoC就比较常见。很多新团队看到Mesh结构扩展性好就直接上网格形NoC但Mesh不是免费的。每个路由器节点都有面积和功耗开销而且随着跳数增加网络延迟也在上升。对AI加速器这种对延迟敏感、流量模式相对固定的场景有时候一个精心设计的环形或共享总线反而更稳定、更省资源。还有一个容易被忽略的问题是QoS和死锁。多个master同时访问共享存储时总线仲裁必须保证高优先级流量不被低优先级流量拖死跨多个路由器做事务排序时一旦出现环路依赖就可能死锁。这些在RTL仿真里偶尔能看到痕迹但业内尤其怕那种只在最坏case触发、把芯片挂在现场的状态。所以互联选型的原则是先用低风险方案跑通再根据后仿真的瓶颈决定要不要上更多路由节点永远不要为了架构上的炫技制造调试地狱。3. 软件栈不是等硬件出来再补的胶水而是架构的另一半3.1 编译器接口要提前到架构定义期一起定太多项目把软件栈当成“硬件流片后再找几个程序员写编译器”的后置任务。这是AI芯片项目里最致命的时间规划错误。芯片的可用性很大程度取决于编译器能否把模型高效地映射到硬件上如果硬件的抽象模型在架构阶段没有给编译器留好口子后期软件工程师只能在已冻结的RTL上打补丁效果可想而知。正确做法是把编译器的IR设计和硬件指令集一起定义甚至在寄存器传输级设计前先写出一个基于LLVM或MLIR的模拟编译器路径。这里的重点是定好指令集的抽象层级硬件对外暴露的是底层流水线操作还是高层张量指令以TPU这类架构为例对外往往给出的是一整层张量操作原语编译器要负责把上层模型拆成这些原语再做布局、切分和调度。MLIR让这类工作方便了很多它允许你自建一个针对目标硬件的Dialect在高层和低层IR之间做渐进式降级。但有利也有弊MLIR能让你快速拼出编译器原型却不能替你做所有硬件映射的决策比如内层循环的unroll因子、buffer拼接策略、memory layout转换这些还是要靠对硬件微架构的深入理解去逐个调。你在项目启动阶段要花多少时间在软件工具链上取决于团队是否已经搞过同类编译器。如果完全没有底子我建议把编译器工作量按硬件前端RTL工作量的0.8到1倍来预估绝不能当成零头。3.2 算子覆盖率的真相跑分漂亮不等于实际好用“能跑ResNet、能跑BERT”这种Demo话术在AI芯片行业里已经被证明是不太靠谱的验收标准。理由很简单公开模型的跑分只是一条特定路径真实工作负载里充满动态形状、控制流、嵌套分支和奇怪的内存布局任何一个细节没踩中硬件利用率就会剧降。算子覆盖率不该只看“支持多少个算子”而要看“目标模型里所有层在硬件上的映射效率”。比如只支持一种固定的NHWC排布那遇到某个算子输出格式是NCHW整个后续计算链就可能被迫插入大量重排操作白白浪费带宽和周期。我见过一个案例某加速器在官方benchmark上的算子覆盖率接近95%实际跑一个真实业务模型时因为几个不常出现的算子被编译器砍成了“最坏路径”整图性能只剩benchmark的40%。这种损失往往不是靠硬件加速能补回来的因为在定义算子接口时就没有把异常路径的效率考虑进去。所以算子覆盖率的正确评估方式是把目标负载中每一层都做一次“从图到硬件的完全映射”记录每层的利用率、访存和占用周期。任何利用率低于设定阈值的层要么优化编译器要么在架构上补充机制要么接受这个性能损失并明确告知产品方。这才是靠谱的验收方式。3.3 精度管理与量化软硬协同的真正试金石AI芯片多数走INT8、FP16或BF16路线精度管理从来不是纯硬件问题而是量化工具链、编译器、运行时和硬件单元四者之间的协同。新造芯片时最容易出现的误区是把INT8单元做出来了却没有人负责训练后的量化校准和精度回归。实际落地中有一整套细节权重量化是per-tensor还是per-channel激活量化是否要动态计算缩放因子量化感知训练QAT和训练后量化PTQ哪条路径更适合目标模型溢出和舍入模式怎么处理。这些事如果软件栈不管终端用户就要自己踩坑而多数用户对模型精度损失极其敏感一旦芯片被贴上“不靠谱”的标签就很难翻身。更现实的一点是硬件如果只支持对称量化许多模型在低比特下会掉点严重非对称量化需要硬件多一组偏置处理逻辑。如果你在架构阶段就把这块砍掉了后面算法团队大概率会要求补回来而补回来的代价是几层RTL重构加一遍重新验证。精度的另一个关键点是动态范围。很多新团队只做INT8但INT8的动态范围只有256档对激活值分布跨度大的模型必须依赖缩放因子而缩放因子在推理时是动态变化的。硬件能不能在运行时快速计算并应用缩放直接决定量化模型能否落到实际负载上。别把精度问题拖到流片后再救那时候能改的就是软件校准和运行时的各种workaround效果非常有限。4. 从流片到量产中间隔着的不是运气而是验证与供应链4.1 验证策略覆盖率数字再高也要回到场景驱动流片失败是成本最高的失败所以项目会把大量人力投入到验证上。但很多团队对验证的理解就是“跑UVM、拉高代码覆盖率、凑门控覆盖率”等覆盖率冲到99%就觉得万事大吉。实际踩过坑的人都知道覆盖率只是风险指标它只能说明硬件“被进过”不能说明硬件“行为正确”。正确做法是让验证工作围绕真实工作负载的场景列表展开。把目标模型分解成对应的运算序列、访存模式、异常场景和边界条件做成一张场景映射表确保每个场景都有对应的测试用例和断言。相比错误注入、随机约束测试这类“工作负载驱动验证”能更早暴露体系结构层的问题比如某些数据流模式的死锁、跨bank访问冲突、片上存储的写后读冒险。同时要把后仿真post-layout simulation做得足够充分尤其是时钟树、工艺角和功耗仿真的联合分析。很多功能验证通过的模块在时序闭合后出现建立时间违例因为布局布线的物理效应改变了一部分信号的相对延迟。新芯片项目在这块最容易低估工作量出现“验证报告很漂亮一跑物理版图就露馅”的局面。4.2 Bring-up阶段复位、时钟和调试口才是活下来的前提芯片从Foundry回片接上电源的那一刻你面前不是一块能运行模型的加速器而是一块需要“唤醒”的裸硅。Bring-up阶段最痛苦的往往不是算力跑不出来而是最基本的复位、时钟和调试机制还没搞顺。首先确定的是时钟系统锁相环能不能锁定有没有时钟相位问题片内产生的时钟在扫描模式下能不能被正常控制。其次是复位策略上电复位和各模块局部复位是否可靠复位的释放顺序会不会导致状态机进入未知态。这两个基础问题如果不稳后面所有测试都是在流沙上盖楼。调试接口的设计在RTL阶段看起来无关紧要但到了bring-up就是救命稻草。通常要预留可观测的片上log寄存器、JTAG调试口、内存读写backdoor以及足够覆盖主要子系统的计数器。有了这些你才能在没有波形仿真的真硬件上“看见”状态机停在哪儿、数据流堵在哪一拍。我在多个芯片项目里都验证过一句话每个可以快速Tracing片上状态的调试口在羞耻阶段都是救回一星期的神器。4.3 制程、封装与供应链小团队尤其别赌先进封装新造AI芯片有一道绕不开的选择题用先进制程还是成熟制程。先进制程带来的好处是频率和功耗优势但代价是流片成本、IP授权费用和良率风险都显著抬高。对多数小团队和垂直场景来说第一颗芯片选择成熟制程比如16nm、12nm甚至28nm是更务实的路径能大幅降低设计约束和一次性工程费用代价主要在能效比上看具体场景能不能承受。封装也是一样。HBM、CoWoS这类先进封装能带来惊人带宽但工程复杂度和供应链约束极高需要和封装厂提前几个月锁定产能一旦设计变更排期影响极其严重。对新造AI芯片的启动阶段我建议优先避开“必须上先进封装才能跑通”的架构方案先用传统封装完成功能验证和市场验证后续再做chiplet或HBM版本。供应链层面更现实备选工艺库、双源IP授权、晶圆产能锁定、封装测试厂合作这些在实际量产前就要签好协议。很多芯片设计团队觉得“流片完就赢了”结果死在量产阶段的小批量交付上。对“新造”这件事真正的终点从来不是流片而是能够让不知道你芯片好在哪里的客户稳定地用起来。5. 小团队的务实启动路径先做减法再谈造芯5.1 别一上来就写RTL先把建模环境搭好小团队最容易犯的错误是“满腔热情进入微架构细节”连芯片有几个MAC都没定就开始写Verilog。AA一定浪费。正确的启动顺序是先建立一个可执行的建模环境至少包含行为模型和Roofline分析模型把目标模型映射成架构方案估出性能、面积和功耗的QSD再决定要不要进入RTL。这个建模环境不必很高级Python脚本加一套简单的Cycle Estimator就够了。它的主要作用是让整个团队在同一个数字坐标系里说话这个方案理论峰值多少、实际可用带宽多少、片上SRAM够不够、外部访存会不会成为瓶颈。做AI芯片最贵的其实是做错误的架构决策建模阶段多花一个月的打磨后面能省下至少半年的迭代。5.2 最小团队配置和阶段交付压缩到极限新造AI芯片启动团队理想配置可以做得很小架构与体系结构设计12人前端RTL实现24人验证23人软件编译器与工具链12人后端与物理实现以及DFT可以根据IP和Foundry的成熟程度外包12人。小团队的底气不在于人多而在于决策链路短但这要求每个人都同时理解硬件和软件两层。阶段交付上我的经验是不要把“流片”当作第一个里程碑而是设置几个更容易检查的中继点第一架构规格书与建模报告第二编译器原型能在行为模型上跑通目标模型第三RTL前端完成并通过FPGA或仿真平台验证第四物理设计与后仿通过最后才是流片回片。这样每一阶段都有可衡量的产出不至于走到流片前才发现基础定义错误。对很多从没做过AI芯片的团队还有一个完全可行但容易被低估的起步路径先用FPGA原型平台或现成的可编程AI加速器软核验证负载效果把算法映射、量化策略和性能预期摸准再决定是否投入ASIC。那个阶段积累的经验在新造ASIC时会原封不动地变成你的判断力。5.3 自研可以但不要什么都自研新造AI芯片是一个系统工程并不意味着团队里每个环节都要从零起步。成熟的IP如DDRPHY、PCIe、SerDes、CPU总线接口等能让你把精力集中在真正的AI加速核心上编译器可以基于LLVM/MLIR做二次开发完全从零写一套编译框架通常没有必要验证环境可以复用主流方法学重点把场景库做厚。如果你把有限的工程时间平均撒在“自研所有IP”上结局往往是AI加速核心没做好周围配套链路却不成熟整个芯片无法形成竞争力。真正值得自研的是那些决定差异化性能的部分算力单元、数据流调度器、存储子系统、算子映射策略。周边常规能力一切能用成熟方案的直接用成熟方案这种克制比技术上的雄心更值钱。我在实际做AI芯片的这几年里最深的教训就是造一颗AI芯片的困难从来不是“想出一个很漂亮的架构”而是要在无数个“这里再强一点就好了”的诱惑里守住范围。每一次贪多都会把验证时间、软件栈复杂度和供应链风险一起放大。新造AI芯片这件事真正稀缺的不是聪明而是知道该对自己砍刀的决心。把面收得够窄才可能把尖磨得够利。
