AI-native芯片设计：需求工程、跨层优化与验证思维才是真正稀缺能力

最近某头部AI实验室放出的那份AI-native芯片设计研究报告业内讨论热度比我预期的要高得多。有意思的是我翻了一圈各路评论发现大家争论的焦点基本集中在模型参数、数据规模、自动化覆盖率这些技术指标上好像只要把这些数字做上去芯片设计就能顺理成章地进入“AI原生时代”。但以我在芯片后端和AI工程两个方向上都踩过坑的经验来看这个判断大概率是错的。那份报告真正的价值不在于展示一套多先进的工具链而在于逼着所有人重新回答一个问题当AI真的能参与甚至主导芯片设计时行业里最稀缺的到底是什么这篇文章不打算复述报告内容我只想结合自己在一线做AI辅助芯片设计的实际经历说说我的三点不同看法。1. AI-native芯片设计热潮背后的真实定义1.1 从“AI辅助”到“AI原生”两字之差天壤之别很多人一听到AI-native芯片设计第一反应是“用AI来设计芯片”觉得这不就是原来的电子设计自动化EDA流程里塞几个机器学习模型嘛。这么说其实把问题看小了。传统EDA流程的逻辑是人写好寄存器传输级RTL代码工具去做逻辑综合、布局布线人在关键节点上介入调约束、改脚本。AI辅助设计做的事情是在这条流水线的某个环节上用模型替代或加速人工操作比如用强化学习去摆放宏单元、用图神经网络预测时序拥塞。整体架构没变人依然是设计链条的主控者AI只是被局部调用的“小工具”。AI-native设计完全不同。它从问题定义那一刻起就不是按“人脑容易理解的方式”去组织设计流程的而是为了让AI能够全局搜索、全局优化而重新设计整个表示方法。比如说传统流程里架构师用文字和框图描述微架构这个描述天然带有人的思维习惯很多约束是隐含的、不精确的。AI-native流程里必须把“设计空间”本身显式地建出来什么样的微架构变体可选、哪些物理约束可以量化、PPA目标怎么表达成可优化的目标函数。AI在这个空间里自己探索、自己取舍而不是等人给出一版RTL再去优化。1.2 那份研究报告真正引起争议的地方某头部AI实验室这次放出的研究最让我在意的不是那些漂亮的指标数字而是他们展示了一条比我们现在常用的流程更完整的AI原生链路从高层次设计规格描述出发系统能够自动完成架构选择、RTL生成和物理实现的初步闭环。这立刻引发了一个争论芯片设计的核心创造工作到底是由人完成的还是由AI完成的有观点认为这是“设计民主化”以后人人都能设计芯片也有观点说这种自动生成的东西只能用在简单模块上复杂的高性能芯片想都别想。我的判断是两边都在讨论“AI能不能做到”却没讨论更关键的问题“如果AI真的能做到行业里需要什么样的人来驾驭它”。这就像当年编译器出现的时候大家争论的是“手写汇编会不会消失”而不是“会写编译器的人需要理解什么”。后来历史告诉我们手写汇编确实没消失但它变成了少数专家的事而真正稀缺的人是能够理解硬件、指令集和编译优化之间深层关系的系统级工程师。AI-native芯片设计面临的局面本质上是一样的。2. 主流看法里“最稀缺的三样东西”——我说它们都不是最关键的2.1 业内讨论最集中的三种观点最近各种文章和讨论里关于AI-native芯片设计“稀缺能力”的共识大概可以归纳成三句话第一缺算力——训练一个能生成合格布局或RTL的模型要消耗大量GPU资源第二缺数据——芯片设计数据分散在各家公司手里规模小、标注难、共享风险高第三缺算法——现在生成模型和强化学习算法还不够强生成的方案离工业可用还有很大距离。这三句话单独看都没错作为方向也都是真的瓶颈。但如果你真正在一个芯片设计团队里做过事就会明白它们只是表层原因。我做了个对比把“主流说法”和“我认为真正的问题”放在一起看差别会非常清楚。维度主流看法稀缺的是我的看法真正的问题算力训练大模型的硬件资源不够算力门坎是暂时的会随基础设施演化快速下降但“定义清楚问题”的能力不会自动提升数据带标注的芯片设计数据太少数据量不是核心核心是数据里有没有保留“设计意图”以及能否把分散的经验结构化算法生成模型和RL算法不够强模型能力已经超过大多数人的使用水平缺的是能把芯片约束翻译成模型可优化目标的中间人2.2 为什么说“算力论”站不住脚先说算力。在任何新技术的早期阶段算力都是稀缺的但这是“投入期”的稀缺不是“结构期”的稀缺。当年深度学习刚火的时候所有人都说GPU不够用后来超算中心和云算力把这个问题基本抹平了。AI-native芯片设计面临的情况也一样——随着专门为EDA工作流优化的硬件和调度系统出现算力门坎会逐步降低这只是一个时间问题。更关键的是算力再高也不会帮你回答“这个模块的功耗目标到底是该设成0.8毫瓦还是1.2毫瓦”这种问题。这种定目标的环节恰恰是现在整条流程里最消耗人力、最容易返工的地方。把更多的卡堆上去只会让一个错误的目标更快地被优化出来然后用更高的成本生产一个没人要的设计。2.3 数据和模型为什么也不是终局答案数据问题也一样。芯片设计数据确实少但这不是一个有解之前没法干活的问题。各家芯片公司过去几十年积累了大量带签核结果的真实设计数据问题在于这些数据散落在不同组织里格式不统一而且很少有人把“这个设计当初为什么这么做”记录下来。AI训练需要的是数据背后体现的决策逻辑而不是一堆孤立的网表和时序报告。至于算法我得说句可能不太讨喜的话当前生成式模型和强化学习算法的能力已经比绝大多数芯片工程师想象的要强了。做AI-native设计真正的挑战不是你训练不出一个会生成RTL的模型而是你根本不知道该怎么向这个模型描述“我要什么”。这个鸿沟算法本身解决不了。3. 第一点不同看法真正稀缺的是把模糊需求翻译成机器可优化目标的能力3.1 “需求工程”成了AI-native时代的隐性瓶颈我第一点不同看法是AI-native芯片设计真正稀缺的不是能写模型的人而是能把一个模糊的产品级需求翻译成机器可优化的形式化目标的人。这种能力在业界有个叫法叫“需求工程”但在传统芯片公司里这个工作一直没被当成核心能力来对待。传统流程里架构师拿到产品需求“性能要提升30%功耗尽量低”他用经验在大脑里拆解成微架构方案然后手工写成RTL。人的经验可以处理模糊性因为你在写代码的过程中会不断内省“这样应该能满足需求吧”。但在AI-native流程里机器不会像人一样内省它只会优化你给它的目标。如果你给的目标函数是“时序松弛度最大化”它就会老老实实地把所有能用的面积都拿去换性能哪怕功耗因此爆表。所以问题变成了不是AI不够聪明而是我们不知道自己该怎么把“性能提升30%、功耗尽量低”这种话翻译成一组合适的奖励函数、约束权重和优化边界。这个翻译过程需要深刻理解产品意图、架构取舍和物理实现任何一个环节掉链子结果都会跑偏。3.2 一个真实的翻车案例我自己在模拟项目X里就翻过一次车。当时我们想用强化学习给一个图像处理模块做宏单元布局团队里模型工程师把奖励函数设成了“在满足时序约束的前提下最小化面积”。听起来没问题对吧结果跑出来的布局时序确实过了、面积也小了但功耗翻了一倍。原因很简单我们把问题定义成“两点约束”但真实的物理设计是一个多目标权衡问题。那个模块在整颗SoC里本来就离电源网络很远如果面积过度缩小等效电阻变大供电网络IR drop急剧恶化前端为了补功耗不得不大幅提高工作电压。需求定义漏掉了一个维度的约束AI就把一个局部最优当成全局最优交了出来。这个教训让我印象特别深。AI-native流程不会替你定义问题它只是忠实地优化你定义出来的问题。你定义得好不好决定了结果的上限。现在行业里大家都忙着卷模型、卷算力但真正决定AI-native设计成败的是那些能把“更快、更省、更稳”这种模糊诉求转化成可计算、可验证、可回溯工程目标的人。这种能力需要长期浸泡在真实芯片项目里才能练出来不是读几篇论文就能补齐的。4. 第二点不同看法跨层联合优化的系统思维比AI专家更稀缺4.1 AI-native的真正红利在于打破层次壁垒我第二点不同看法也是我觉得最反直觉的一点AI-native芯片设计真正值钱的地方不是让AI把某一层的某个任务做得更好而是让整个芯片设计链条可以作为一个连续的整体来优化。这是对传统流程“分层抽象”模式的根本性冲击。传统芯片设计是一层一层往下做的架构层定微架构微架构层写RTL逻辑综合层做门级映射物理层做布局布线。每一层都把约束简化和编码之后传给下一层。架构层不会精确知道某条路径在物理层会走多远物理层也无法理解架构层为什么要做这样一个分支预测器。这种分层架构在过去几十年非常成功因为它让不同团队可以并行工作每个人只需要精通自己那一层。但AI-native设计的思路完全反过来。它把一个芯片的“架构选择”和“物理可实现性”放进同一个优化空间里搜索。比如一个模块用哪种微架构不再由架构师拍脑袋决定而是由AI综合评估它的时序、功耗、面积之后自动选择。这意味着过去靠分层壁垒保护的专业分工反而成了AI-native落地最大的障碍——如果你只懂架构不理解后端物理设计就无法给AI设计空间设置合理的边界如果你只懂物理设计不理解架构层的设计意图就无法判断AI搜索出来的方案是不是真的合理。4.2 “深井式分工”为什么会在AI-native时代失灵芯片行业现在的组织模式是典型的深井式分工架构组、前端组、后端组、签核组各管一段组和组之间通过文档和会议传递约束。这在传统流程里是跑得通的因为每一层都有明确交付物下一层拿到交付物用自己的工具链继续做就行。但在AI-native流程里你会发现这种分工模式到处是裂缝。AI模型做跨层优化的时候需要的是一个端到端的、数值化的反馈信号它要从物理层的拥塞情况直接反推架构层的决策是不是有问题。这个过程要求有一类人既能看懂架构描述又能理解物理设计的关键约束还能把这些同时塞进一个AI模型的训练框架里。我在模拟项目X里就碰到过这种“翻译者困境”。当时我们实验一个跨层优化方案算法团队的人不懂什么是pin density后端团队的人没接触过Transformer和强化学习。两边开会就是鸡同鸭讲算法的人说“你把这个约束量化一下我就能优化”后端的人说“这不是量化的问题这是你根本不懂这个约束背后的物理意义”。最后项目推进靠的不是算法最强的博士也不是后端经验最厚的专家而是一个愿意两边来回跑、把需求翻译成目标函数的资深工程师。所以我的第二点看法很明确AI-native时代真正稀缺的不是“AI专家”而是具备系统级思维、能在不同设计层次之间自由穿梭、能把跨层约束统一建模的人。这种人的培养周期比算法工程师和芯片工程师都要长因为他不只需要两边的知识还需要在真实项目中踩过足够多的坑才能在跨层冲突发生时知道该往哪个方向妥协。5. 第三点不同看法验证思维才是AI-native设计的隐形天花板5.1 “AI生成的东西凭什么相信它是对的”第三点不同看法可能是目前业内讨论最少、但我认为最要命的——验证思维。AI-native设计的一路上都在讨论怎么让AI生成更好的设计却很少有人问一个更基本的问题AI生成的设计我们凭什么相信它是对的传统芯片设计里验证工作的根基是“可控性”。工程师写出RTL之后验证团队通过约束随机激励和形式化验证来检查它是否满足规格。就算代码出错错误也是可以追溯的你打开某一行代码看到某个状态机漏了一个状态你就能解释为什么出错。因为人写的代码反映的是人的思维验证本质上是在检查人的思维和规格之间有没有偏差。但AI生成的RTL或布局完全不同。它不是一个“人的思维”的直接产物而是模型基于训练数据统计出来的结果。这意味着两个根本变化。第一模型的输出可能在语法上完全正确、甚至风格上非常专业但语义上错得离谱——因为它只是学会了“像这样的代码看起来是对的”并没有真正理解规格里的隐含需求。第二如果出错你无法通过打开某一行的方式来定位问题因为没有任何一行代码是“故意”写成这样的错误可能来自训练数据的偏见也可能来自搜索空间里恰好遗漏了一片区域。5.2 举证责任倒置验证方法论面临的重构这种变化带来的冲击我用一个类比来说明。以前的设计流程像是“作者对自己写的文章负责”出了问题找作者对质就能解决。AI-native流程里“作者”不是一个可以对话的人而是一个黑箱模型。于是举证责任发生了倒置以前是设计者证明自己设计是对的现在是使用者需要证明模型的输出在这个特定场景下是正确的。这个“证明”的难度远高于生成一个设计。我在模拟项目X里做过一个实验用经过微调的代码模型生成一段总线桥接逻辑单看每一行都很合理模块划分也干净利落但综合出来跑仿真的时候在边界条件下功能完全不对。后来排查发现模型在训练数据里见过太多类似的桥接逻辑但那些逻辑服务的总线协议版本略有不同于是模型把一个微妙的协议细节“统计”错了。这个问题如果你不做跨场景的形式化验证光靠代码评审一辈子也发现不了。这就是为什么我说验证思维是AI-native设计的隐形天花板。AI能生成的东西只会越来越多但如果我们依然沿用传统的验证思路假设“设计是人写的、错误来自人的疏忽”那AI生成出来的设计在工业级芯片里根本不敢用。真正的稀缺能力是能在模型生成的黑盒过程之外建立一套系统性的举证机制证明AI的输出在一个确定的设计空间内是可证正确的。这需要对形式化方法、约束求解和AI模型本身都有深刻理解比单纯会训练模型要稀缺得多。6. 关于“怎么练”的一点实在建议6.1 给算法方向的人去读一份PDK文档如果看到这篇文章的你是做算法或者模型出身、想切入AI-native芯片设计的方向我的第一个建议可能有点反直觉放下手头的模型去找一份工艺设计套件PDK文档从头到尾翻一遍。你不用记住每个参数但要理解什么是金属层、什么是通孔、什么是时序弧理解“布线的物理本质是给你画在纸上的逻辑连接找到真实世界的实现路径”。很多做AI芯片设计的算法工程师第一次接触这些概念时会发现自己之前在奖励函数里设置的很多参数在物理世界里根本没有对应物。你不理解物理约束就没办法设计一个有意义的优化空间模型跑得再快也是空转。6.2 给芯片方向的人亲手写一个端到端AI工作流反过来如果你是芯片设计工程师别觉得AI-native是算法团队的事。或者自己找一个只有几十万的模块亲手搭一个最小的端到端流程用模型生成RTL、自动做逻辑综合、跑一遍静态时序分析然后把结果反馈回模型里继续迭代。哪怕这个流程最初的产出比你的手工设计差一倍也要坚持跑通。只有把这个闭环亲手走一遍你才会真正理解AI-native的问题定义、跨层反馈和验证逻辑是怎么回事。光靠开会和读报告很难对这套流程产生直觉。6.3 给团队管理者把垂直分工改成“场景Owner制”最后说给带队做这件事的人。我见过太多团队指望“招几个AI专家进来再让他们跟芯片组配合一下”就把AI-native做起来结果就是两边互相觉得对方不懂行项目在沟通成本和权力争夺上消耗殆尽。我的实操体会是AI-native设计团队不该按“算法组”和“芯片组”划分而应该按“场景”来组织一个跨职能小组内部包含架构、前端、物理设计、算法和验证的人共同负责一个模块的端到端AI-native流程。小组负责人可以不一定是算法最强的但一定得是那个能够在所有层次之间来回翻译、并且对最终流片结果负责的人。这种转型很难迈出第一步因为传统组织里的晋升路径和职责边界都很清晰而场景Owner制会让很多人的工作界面变得模糊。但如果你问我在模拟项目X里踩过最深的一个坑是什么我的回答就是我们在团队结构和模块划分上纠结的时间远远超过了花在模型调优上的时间。AI-native设计能不能落地在很大程度上不是技术选择而是组织选择。最后再分享一个小体会。AI-native芯片设计这个方向现在看起来是被几家头部实验室的研究报告推到了聚光灯下但它真正能走多远不取决于实验室里跑出多少漂亮的测试用例而取决于行业里能不能长出一批同时理解芯片物理本质、架构取舍、AI建模逻辑和形式化验证的人。这类人的数量比显卡数量、比数据量、比模型参数量都难涨得多。如果你正好在这个交叉领域里别焦虑自己是不是还不够精通某一边——你愿意在两个世界之间来回跑本身就已经是稀缺能力了。