最近朋友圈里被一份关于AI-native芯片设计的研究报告刷了屏标题很扎眼真正稀缺的能力是什么我读完第一遍觉得信息量很大第二遍却越看越不对劲。不是因为人家说得没道理而是我觉得这个话题的讨论起点被带偏了。太多人把AI-native芯片设计理解成多堆几个NPU核心用大模型跑跑EDA仿佛稀缺能力等同于算力、等同于人才数量、等同于先进工艺。我做了多年芯片相关的工作也深度参与过几个AI加速器项目今天想把我的三点不同看法掰开揉碎讲清楚。这篇文章不会有逐段翻译报告的冗长内容也不会复述那些正确但无用的废话。我只想从工程实战角度回答一个真问题如果明天你要带队做一颗AI-native芯片最值得拼命守住的能力到底在哪几个环节。1. 先厘清一个前提AI-native芯片设计到底在说哪一层1.1 三种AI芯片概念经常被混着用结论自然完全不同我观察到一个很有趣的现象技术讨论里只要同时出现AI和芯片两个词聊的往往不是一回事。第一种是用AI辅助芯片设计典型场景是拿机器学习模型做版图布局优化、DRC热点预测、逻辑综合里的时序预估这类工作发生在硅前设计流程内部本质是EDA工具的智能化。第二种是面向AI负载的芯片架构设计典型场景是设计一个对Transformer或卷积神经网络友好的数据流加速器重点是算子映射、片上存储层次和并行度设计这类工作发生在架构定义阶段。第三种是AI原生的芯片设计方法学指从需求规约到RTL再到验证整个流程由AI代理和自动化工具链驱动人的角色变成定义约束和检查结果。报告里讨论的AI-native最吸引人的解读其实是第三种但绝大多数人读出来的却是第二种。这不是读者的错而是概念本身确实横跨了三个完全不同的工程域。更麻烦的是不同的定义会直接推导出完全不同的稀缺能力结论如果你把AI-native理解成为AI设计专用芯片那稀缺的当然是高性能计算单元设计和能效比优化能力如果你把AI-native理解成用AI重构设计流程那稀缺的必然是高质量标注数据、自动化验证闭环和可复用的训练基础设施。搞不清这个前提后面所有讨论都是空中楼阁。我自己更倾向一个综合定义AI-native芯片设计指的是芯片的规格定义、架构探索、物理实现、验证调优、部署演进全链路都以AI负载的真实行为为第一约束并尽可能用AI方法反过来加速设计过程本身。换句话说它是双向的AI改变芯片的形态芯片也反过来为AI服务。这个定义意味着我不能用传统的先有CPU再找应用思路来评判它也不能用先有算法再把网络映射上去的线性流水线来理解它。这是一个螺旋上升的循环系统。1.2 定义的差异会实实在在改变你的资源投入方向一旦接受这个综合定义你就会发现不同的人读了同一份报告回去做的动作完全不同。有人回去购置更多GPU服务器做仿真有人回去扩建设计团队有人回去谈EDA授权。但我的判断是真正让团队拉开差距的根本不是这些常规动作。我见过一个很有代表性的案例某个做端侧AI推理芯片的团队花了大量精力去打磨一个号称业界最强的矩阵乘引擎峰值TOPS很漂亮PPT上吊打同行。结果产品提交给客户后对方拿真实业务模型一跑发现大量时间是耗在数据搬移和动态形状处理上矩阵乘引擎大部分时间在空转。团队被迫回炉重造重新设计数据通路和调度器。问题出在哪出在架构探索阶段用的是理想化的合成负载而不是真实的AI模型行为数据。这类事情在业内不是孤例几乎每颗AI芯片的迭代过程里都会重复出现。所以我要说的第一句话就是定义决定了稀缺能力的坐标系统。不在同一个坐标系统里讨论无论列出多少条关键能力最终都会被证明是闭环里的选择偏差。这也是我写这篇文章第一个想帮大家理清的事。2. 我的第一个不同意见算力堆砌之外数据资产才是AI-native设计真正的护城河2.1 模型的性能上限取决于训练数据的保真度讨论AI-native芯片设计时被提到最多的是算子库、编译器、互联带宽、能效比。为什么我从数据资产讲起因为我自己吃过大亏。很多年前我参与过一个AI加速器项目最初的架构评估报告里用了公开的、经过清洗的理想化算例规整的矩阵大小、固定的数据分布、稳定的分支行为。基于这份报告团队信心满满地决定了片上SRAM容量和NoC拓扑。等项目进入系统验证阶段我们把客户提供的真实模型部署上去发现情况完全不一样真实网络里有大量动态shape输入、不规则稀疏模式、长短不一的序列还有依赖输入数据的分支跳转。这些行为让原本精心设计的仲裁器和预取策略频繁失效片上网络拥塞率飙升最终利用率只有设计目标的四成多一点。这件事让我深刻意识到AI模型的精度提升可以依赖公开论文和开源代码但一个AI芯片设计团队最核心的数据资产是围绕真实负载行为建立的语料库和评测基线。这个资产包括几个层次部署端采集到的真实算子频率分布、模型结构演化趋势、量化误差的统计特征、内存访问模式、延迟敏感度曲线。这些数据在公开渠道根本找不到每一条都带有具体团队、具体产品、具体场景的痕迹。它们决定了架构探索阶段做的每一个取舍是否靠谱。2.2 为什么这些数据走不出实验室是行业性难题很多芯片公司并非意识不到真实负载数据的重要性而是被三座大山压住了。第一是隐私合规客户的模型和业务数据大部分不能离开对方环境法律风险极高。第二是二进制分析的困难很多商业推理引擎以闭源二进制形式分发你只能观测到外部行为拿不到内部的算子调度细节。第三是采集链路本身的建设成本要把部署日志匿名化、结构化并可靠地回流到设计团队需要一套完整的数据管道从设备端日志上报到云端清洗再到硅前仿真系统对接几十个人的团队也不一定搭得起来。行业里有一种常见的妥协方案用开源模型加上微小的变体来模拟真实负载。这个方案看起来很美实则会带来严重偏差。开源模型往往来自学术榜单结构相对干净、量化方案单一而真实生产环境里的模型往往经过蒸馏、剪枝、混合精度、动态batch等各类操作行为模式千差万别。用干净数据设计出来的加速器遇到脏现实的模型就露馅。这就是我强调数据资产更稀缺的原因模型是别人的成果工具是买来的商品数据管道才是你自己一砖一瓦修出来的基础设施而且它没有办法快速复制。2.3 从一次数据治理事故说起数据管道不是锦上添花我想分享一个具体项目里的教训这个项目后来我们戏称为数据治理事故专项复盘。事情的经过是这样的某边缘AI加速器Demo项目在规划阶段为了赶时间大家决定先用一个现成的、只包含标准ResNet风格网络的仿真benchmark集跑性能模型。当时负责架构的同学觉得问题不大因为目标场景是图像分类ResNet足够代表主流负载。结果项目进行到中段团队拿到一批真实业务数据之后发现目标场景里接近一半的算子集中在深度可分离卷积和动态形状的自定义算子还有相当多的不规则稀疏Pattern。架构被迫增加了一个专门处理稀疏数据的预处理模块改动直接涉及指令集扩展和存储层次调整代价是整体进度往后推了将近十周。如果一开始就搭一条哪怕很粗粒度但方向正确的数据回流管道这个改动完全可以在架构定型前完成。所谓数据回流管道听起来高大上落地其实也没有那么玄乎先用一个轻量级profiler在目标设备上跑一组代表性模型收集算子和内存访问特征再把采集结果转成统一格式的trace最后用聚类方法挑出十几种有代表性的负载模式用于硅前评估。三步走大约需要两到三周就能跑通第一版。相比几十周的返工这笔账非常划算。基于这次教训后来我参与的所有AI芯片项目都强制要求架构探索阶段的输入必须来自真实负载的行为摘要而不是人工拍脑袋合成的benchmark。3. 我的第二个不同意见架构再漂亮验证闭环断裂照样全军覆没3.1 设计-验证的剪刀差正在被AI-native推得更大被多数讨论忽略的维度是验证。大家看到的是AI芯片的架构创新空间大却看不到验证的复杂度也在指数级增长。传统SoC时代的验证思路是功能正确性优先验证计划围绕指令集架构合规性和总线协议一致性展开。AI-native芯片则完全不同它要验证大量非确定性行为——浮点累加顺序导致的数值误差、量化逻辑在不同中间表示下的精度损失、数据流调度器在动态负载下的性能退化。这些东西没有办法只用断言和覆盖率来保证正确的标准变得模糊。我把它叫做验证剪刀差左侧是RTL规模和状态空间的持续膨胀右侧是验证工程师的产出效率只能线性增长。任何一家公司在做AI芯片时都会感受到这个剪刀差的压迫感区别只是有人选择假装看不见有人选择在项目排期里把验证时间偷偷加长。老实说通过简单的多招验证工程师来弥合剪刀差已经被证明行不通因为AI芯片的验证瓶颈往往不是人头数而是跨团队沟通的断层——算法团队跟验证团队讲的精度掉了0.3个点到底意味着什么RTL团队跟验证团队争的这是feature不是bug要怎么判定这些事情堆在一起才是真正的黑洞。3.2 闭环不是工具链是一套贯穿四段流程的组织纪律一个完整的验证闭环在AI-native芯片项目里至少包括四个阶段硅前性能模型评估、RTL功能验证、硬件仿真加速或FPGA原型验证、硅后回归测试。这四个阶段如果分段看每段都有成熟工具性能模型有各类simulatorRTL验证有通用验证方法学FPGA原型有现成平台硅后调试有调试探针。问题从来不出在单点上而是出在连接的断裂性能模型里的激励格式到了RTL阶段要重写一遍RTL测试向量到了FPGA阶段由于跑不动而被迫裁剪硅后回归则经常忘了回到性能模型做比对。我自己最深刻的体会出现在一个量产项目里RTL验证阶段覆盖率已经做到97%以上功能点位全部收敛团队高高兴兴送交到硅后调试阶段。结果芯片回来后一个极其隐蔽的缓存一致性问题浮出水面——它只在真实运行某个动态shape网络时触发而RTL仿真环境里那个网络的激励版本因为耗时太长被裁剪成了静态版本。这个bug在实验室里反复定位了三周才最终复现而根因出在验证闭环的激励保真度上。如果当时有一套贯通四段流程的量化比对机制哪怕是很朴素的trace对比工具最初几天就能发现问题。这个事件让我坚定地认为验证闭环的真正缺失不是没有工具而是缺少一个对一致性负责的owner持续看守每一段流程之间的激励、数据格式和覆盖率指标是否对齐。3.3 可观测性预算从设计第一天就要划出来很多芯片团队做RTL设计时第一反应是功能先挂通调试以后再想。这个习惯在AI-native芯片领域尤其致命。异步流水线、分布式调度、片上网络状态这些模块一旦出问题外部表现非常迷惑——不是逻辑错误而是性能骤降、偶发卡死、精度漂移。没有内置观测点硅后排查只是大海捞针。我强烈建议在架构定义阶段就确定一项可观测性预算计划拿出芯片物理面积和功耗的百分之几来换取调试和性能监控能力。具体操作包括在关键队列和数据通路上预留计数器和追踪缓冲在仲裁器和缓存控制器上增加可编程事件采样点甚至预留一个低功耗的诊断子系统以便在运行时抓取现场。这么做的问题在于会增加设计复杂度让你在架构评审会上被质疑浪费了宝贵的面积。但如果把账算全面一次失败的硅后定位平均会消耗四到六周的全职工程师时间加上流片重启成本就已经远超那点可观测面积的开销了。提示每次架构评审和设计评审的时候尽量多问这样一句——这个问题在硅后出现时你有什么手段在三天内定位到根因任何空白区域都应该用调试像素和追踪逻辑去填平。与其把钱浪费在后期追查不如早期就把这个预算投出去。4. 我的第三个不同意见AI-native缺的不是AI人才数量而是算法-架构-物理三栖型判断力4.1 为什么单一背景的天才凑在一起仍然做不出好决策谈到稀缺能力绝大多数报告都会指向人才。这个答案正确得近乎废话。如果你问任何一家正在做AI芯片的公司你们缺人吗得到的回答一定都是缺。但我认为真正稀缺的人才类型和大家常说的AI科学家或架构师不是一回事。现实团队的配置通常是算法工程师理解模型但不懂时序收敛数字架构师擅长流水线设计但搞不清量化误差的统计学意义后端工程师对时钟树和物理实现门儿清却在架构评审时插不上嘴。这三个角色单看都是优秀人才放进同一间会议室讨论一个关键取舍时却经常演变成鸡同鸭讲的拉锯战。打个比方一个性能与精度的取舍决策算法团队提出把某个算子的中间累加精度从FP32降到FP16理由是模型对这个小损失不敏感架构团队认为这能省下一大块寄存器堆面积后端团队则指出降低精度会让该模块的电压裕量更好收敛。看起来三方都同意做这个取舍但谁也没有意识到真实负载里这个算子恰恰是长尾误差的敏感点统计上极端情况会直接导致偶发性精度崩溃。等到系统级验证时测试失败再回头推翻架构设计已经是三个月之后。这种事故的根因不是某一个人的专业能力有问题而是缺少一个能把算法、架构、物理约束放在同一个模型里权衡的人。4.2 三栖型判断力的四个具体组成我认真复盘过这类事故中真正起关键作用的三栖型决策者发现他们的能力可以拆解为四个可训练的部分。第一是对量化与数值误差的直觉看到一层神经网络的权重动态范围大致就能判断什么精度方案会造成风险、什么方案无伤大雅不需要跑完整仿真。第二是面积与功耗的估算能力看到一组算子设计心里就有个大概的硅面积和能效区间不需要后端详细实现就能排除一些离谱的架构方案。第三是对性能模型的怀疑能力拿到任何一个性能评估数据时第一反应是这个数据是拿什么负载跑出来的负载里有没有动态shape、同步开销、带宽竞争而不是照单全收。第四是把物理约束反馈到算法招式里的能力比如知道一个稀疏引擎的硬件开销后反过来指导算法团队设计对硬件友好的结构化稀疏方案而不是等算法跑出来再逼着硬件去适配。这套能力组合很传统芯片工程专家不具备纯AI研究专家也不具备。它是跨两个领域长期浸泡之后才能沉淀的判断力只能通过项目实践慢慢养出来课堂和论文都教不会。4.3 用最小可流片项目养人比空谈人才策略管用得多既然招不到现成的三栖人才那么问题就变成怎么培养。我的经验是与其大而全地启动一个旗舰芯片项目让新人瞎摸索不如有意识地设计和组织最小可流片项目。所谓最小可流片就是刻意把范围压缩到一个能跑通完整流程、能够流片并完成基础硅后回测的小芯片规模不会太大但一定完整覆盖模型探索、架构定稿、RTL编写、验证收敛、后端交付、流片到硅后调试的每一个环节。在这个项目里最好的培养方式不是给每个人划定严格的职责边界而是强制轮换和双角色头脑风暴。比如算法工程师必须参与至少一段时间的RTL测试与验证后端工程师需要负责一部分性能模型校准架构师则必须亲自去做一轮量化误差分析。这样做最大的价值是让每个人都知道隔壁环节的约束和痛苦。我在参与这类项目时注意到轮岗回来的工程师在原有岗位上的判断质量提升非常明显算法工程师写出来的部署方案开始自动考虑硬件的并行边界架构师设计流水线时也懂得为数值偏差预留裕量。这样的团队比那些堆了十几个顶级算法博士却各自为战的团队要能打得多。5. 如果让我带队做一个AI-native芯片项目资源配置会按这个序列来5.1 先明确排序数据、验证、人才、算力、论文看不到的东西最难管。为了把抽象能力落到资源分配上我一直建议团队把这些能力排序然后按照排序去分配预算和战略优先级。在AI-native芯片场景里我的排序是这样的按优先级从高到低优先级能力项为什么靠前/靠后1真实负载数据资产与评测基线所有架构与验证投入的前提错误输入导致一切白做2软硬件协同验证闭环决定芯片能不能快速收敛、硅后能不能活下来3算法-架构-物理三栖型人才决定关键取舍的正确率稀缺且培养周期长4AI赋能的EDA工具与自研平台重要但属于商业化较成熟的领域可以采购和定制5制程与算力资源花钱能解决的通常都不是最稀缺的能力这个排序可能跟不少人的直觉相反。特别是把算力和制程放到最后一位很多公司老板会觉得不可思议流片不才是芯片公司的生命线吗我的反驳是对于能认真讨论AI-native芯片设计的团队来说他们通常已经具备获得算力和制程资源的基本盘。真正让项目暴死的往往不是算力不足而是需求定义错了、数据喂错了、验证没过最后流片回来是一块跑不出真实性能的废硅。算力和制程是用钱和时间就能堆出来的数据管道和验证闭环却需要组织在正确的方法论上反复迭代很多轮才能跑顺这才是护城河。5.2 数据前置设计启动前先建设为期三个月的负载语料管道具体到实操我在新项目启动时都会强势要求一个数据先行阶段。团队在传统做法里习惯于先画架构图再找负载来验证我主张完全反过来启动后的前八到十二周不写RTL专门建负载语料管道。第一步是定义目标场景的画像从客户部署环境里采集模型列表、算子频率分布、内存访问trace、延迟敏感度约束。第二步是搭建自动化的负载处理脚本把不同来源的模型统一成标准算子图格式并生成量化变体和剪枝变体。第三步是从这些真实负载里聚类出十到二十个代表性基准点组成黄金评估集用来做后续所有架构探索的输入。这一步最大的阻力来自于团队的心理惯性——没有RTL、没有网表的项目让人心慌感觉在摸鱼。我的应对办法是让数据管道产出的第一份负载行为白皮书成为正式交付物它用图表和统计把目标负载的画像描述得清清楚楚。这份白皮书的价值在下一阶段架构评审时会立刻体现每一个架构决策都有了数据依据再也不用凭感觉打嘴仗。5.3 验证前置把软硬件协同仿真系统放在RTL交付之前另一个资源投入重点是验证前置。传统流程里验证跟着RTL走RTL快写完了验证才开始搭环境整个项目后半段都处于追赶状态。在AI-native项目里我强烈建议在RTL交付之前就完成验证环境的框架搭建——包括统一trace格式、激励生成器、覆盖率数据库和自动比对工具。这样当第一版RTL落地时验证团队不是从零开始而是直接把RTL接入一套已经跑通的测试环境。这么做的好处是RTL早期的不成熟形态可以提供给性能模型团队作为硅前探索与RTL行为一致性的初步校准样本。等到验证阶段性能模型、RTL仿真和FPGA原型之间每一个数据流动都自动留痕任何一层的偏差都可以快速定位。这个系统搭建成本不低大概需要两个资深验证工程师全职投入两到三个月但它几乎必然会把整个项目的验证周期缩短三成以上而且能显著降低硅后找到严重bug的概率。5.4 人才前置团队一组建就配一个架构翻译官在组建AI-native芯片团队时很多人喜欢凑阵容架构组几个人算法组几个人后端组几个人。我的习惯是即使暂时没有真正的三栖型大牛也要从一开始指定一个架构翻译官角色。这个角色的任务不是自己做决策而是在各个职能组之间负责把一句话翻译成各方都听得懂的语言。算法组说这个算子对量化敏感翻译官需要把它转译成架构组关心的这个模块需要保留FP32中间累加器或者至少做混合精度保护后端组说这条路径时序特别难收翻译官要把它转译成架构组关心的这里需要砍一级流水级或调整placement策略。长期来看架构翻译官会成长得无比迅速。因为他们每天的工作就是站在别人的代码和约束里想事情两三 个项目之后他们自然就变成了真正的三栖型人才。我给这个角色专门留出了一个不低的人力成本预算从项目第一天开始投入绝不把这种职能放在各组的业余时间里。事实证明这个岗位的投入产出比往往高于一个额外的高级架构师。6. 回到这份研究本身我认同的方向和我保留的担忧6.1 值得吸收的三项主张虽然整篇文章都在表达不同看法但我并不认为这份研究没有价值。相反它有三项主张我认为对整个行业的方向感塑造很有意义。第一它把AI-native这个概念从营销口号重新拉回到工程可拆解的维度至少给出了可以讨论的框架这比空谈下一代计算要有诚意得多。第二它明确指出了现有芯片度量体系的滞后传统的峰值TOPS和纸面能效比无法衡量真实AI负载下的综合表现这个判断和我多年实践中的感受完全一致。第三它强调了开放的软件工具链和标准化的评测基准的重要性这对全行业的数据透明化和协作效率是实打实的推动。作为一个研究者或者从业者我们不需要因为某些结论有分歧就全盘否定一份报告。更健康的做法是把它当作一个扎实的参考点从里面吸收自己认同的架构、重估自己忽略的维度、校正自己偏颇的方向。这些工作远比站在旁边评价对或错有价值。6.2 我保留的担忧度量体系的公信力和可复现性但我也必须把担忧说清楚。这份研究如果希望真正指导行业实践最需要回答的问题不是稀缺能力是什么而是我们凭什么相信你用来识别稀缺能力的度量体系是公允的。尤其当研究团队自身也拥有相关芯片产品线时评测基线的设计、基准模型的选择、负载分布的权重哪怕在一个细小参数上存在倾向结论都可能产生巨大漂移。这不是质疑研究者的诚信而是工程实践里非常现实的人性偏差。另一个担忧是可复现性。不同公司掌握的真实负载数据量差距悬殊小团队面对同样的方法论经常发现自己连跑通一个入门级数据管道的算力都不够。研究报告如果只给出能力清单而不给出一份最小可复现的操作手册很容易让行业头部的马太效应进一步加剧。说白了AI-native芯片设计这个方向需要的是越来越多可参与的玩家而不是被一份研究报告定义成只有少数巨头玩得起的游戏。6.3 个人体会所有稀缺能力最终都会沉淀为工程纪律我们总是在追逐稀缺这个词但实际上所谓稀缺能力放进项目中就是不可跳过的工程环节。没有数据管道想靠拍脑袋设计架构那叫赌。没有验证闭环想靠运气流片成功那叫赌。没有三栖判断力想靠会议投票解决关键取舍那还是赌。这些年我在AI芯片项目里踩过最大的坑往往不是技术难度本身而是觉得这步差不多就行了先往下走后面再补。遗憾的是芯片行业几乎没有后面再补的空间——越往后返工成本越是成倍增长。所以我看这份研究报告收获最大的不是稀缺能力清单而是一个提醒真正的高手不是在稀缺能力清单上打勾最多的人而是能识别出自己手里最薄弱的一环并且愿意把资源、时间和组织精力压到那一环上去的人。如果你现在正带一个AI芯片团队不妨问自己一个问题假如明天流片回来出了问题你的团队有没有可能在三天内定位到根因假如客户丢给你十个真实模型你的评测体系能不能立刻吐出一份可信的性能报告假如算法团队提出一个全新算子有没有一个人能当场判断它在硬件上的可行性这三个问题都答得上来稀缺能力对你来说已经不那么稀缺了。