关键要点：
讨论已经从无限制的Token预算转向在工程层面限制Token数量或资金投入，而成本上升正在推动业界对开源模型的兴趣。
人类工程师需要具备工具素养和工作流程素养，才能有效地在基础模型层、工具与记忆层以及编排层实现智能体AI的应用。
强化学习、流程捕捉和模型路由都是确保智能体精确执行所需工作负载的必要手段，尤其是在混合专家系统中。
圆桌专家：Semiconductor Engineering近日邀请多位业内专家，就芯片设计中使用智能体AI的最新进展与挑战展开讨论。参与讨论的专家包括Cadence验证软件产品管理高级总监Matt Graham、ChipAgents业务发展与战略合作负责人Harrison Balistreri、是德科技EDA部门高级总监兼产品组合经理Alexander Petr、西门子EDA的EDA AI产品负责人Sathish Balasubramanian，以及新思科技AI产品管理执行总监兼负责人Anand Thiruvengadam。此次圆桌讨论在最近举行的设计自动化大会（DAC）期间闭门进行。以下是讨论内容节选，为三部分系列文章的第二部分，第一部分内容请参见此前报道。
图1：从左至右：新思科技的Thiruvengadam；是德科技的Petr；Cadence的Graham；ChipAgents的Balistreri；以及西门子的Balasubramanian。
SE：当设计团队考虑使用智能体AI工具的投资回报，或为客户估算设计成本时，现在必须把每个Token的成本纳入考量。你们观察到哪些情况？
Graham：在智能体AI的部署过程中，没有什么是免费的——无论从理论上、实际操作上还是具体层面来说都是如此。这也是为什么设计团队、验证团队和实现团队现在纷纷来找我们，询问关于Token效率、Token预算，以及如何为此做预算规划的问题。他们会问："我该如何为部署你们的工具做预算？部署那些和你们工具交互的工具，以及部署通用编码助手，又该如何预算？"就在过去三四周里，这类问题已经开始频繁出现在关于智能体AI的讨论中。整个行业普遍认同这里存在价值。在场的每一位都以某种方式证明了我们能在不同程度上提供投资回报。问题在于，我们该如何真正衡量这种投资回报？我们每个人在Token效率方面做得如何？我们能否证明自己能以合适的成本、高效地给出正确答案？
Petr：在讨论Token投资回报之前，我们需要先思考一下，做对一款芯片需要经过多少次迭代。这正是信任和验证发挥作用的地方。我们可以整天讨论设计师是否信任这个流程、是否愿意投片，但如果一套台积电的光罩要花费数百万甚至上亿美元，那就根本不存在"信任"这种东西，只有"信任并验证"，这正是问题的关键所在。别忘了，验证工作是通过物理仿真引擎完成的，这就涉及多物理场分析。不存在只添加一层本体论、让大语言模型进行推理和验证，同时让成千上万的智能体浪费Token去反复二次、三次、四次检查每个决策这种事情。你最终必须运行仿真引擎，如果热预算算错了，无论你的数字设计或模拟设计看起来多完美都无所谓，你的芯片会烧毁，那你就彻底完蛋了。如果功耗算错了，芯片同样会烧毁。所以你必须在整块电路板上，用真正具备验证能力的引擎，从上到下运行多物理场仿真。这不是靠人类看着代码说"哦，这里有两万行代码，我看不懂，让我的智能体来跑一遍，让智能体来判断好坏"就能解决的。这正是我们在软件工程领域看到的情况——亚马逊推送了一次更新，结果AWS服务器宕机了，因为已经没人真正理解代码是怎么写的了。这就是现实世界中新型的"AI垃圾"。我们在芯片领域也看到了同样的情况，现在我们让智能体去做人类根本不会那样设计的芯片，我们试图把寄生效应当作一种特性来推动芯片的产出。唱一下反调：我们可以用花哨的AI、超级智能体、智能体集群来简化所有这些流程，然后开始大量浪费Token。但如果芯片或光罩出了问题，无论在哪个环节出错，你都要重新跑一次迭代，这带来的成本会远超你节省的那些Token。这仍然是我们必须遵守的底线，尤其是在谈论新一代大型CPU、AI芯片的时候。这些芯片规模巨大，一旦第一次就出错，你就彻底完蛋了，公司很可能就此倒闭。
Graham：关键在于，我们已经知道如何把芯片推向市场。我们已经证明AI能在一定程度上加速这个过程，但它并不能消除原有的各项要求。下一步的问题是，无论浪费与否，Token预算正在占据光罩成本中越来越大的比例，这一点已经开始变得重要起来。去年，没人在意这个问题。
Petr：我们现在面临的真正问题是，如果你看看设计公司过去的运作方式——他们先提出一个项目方案，做好成本核算，然后说："我需要以X美元的价格卖出这款芯片，需要生产十亿或万亿片才能盈利。"然后再往下做成本分解，一直细化到工程成本和软件成本。EDA预算过去是固定的，现在不再固定了。这就带来一个问题：当底层预算不断膨胀、无法控制时，该如何估算芯片价格？过去，客户会跟我们所有人拼命压价谈判，最终确定一个成本。他们可以做出分解——每位工程师的成本、每颗芯片的成本——据此规划预算，决定是否值得去做这颗芯片。而现在，我们进来告诉他们效率可以大幅提升，价值主张就是"用同样的工程投入，产出十颗芯片而不是两颗"，这很好。但现在又冒出一个Token预算，这个预算正在失控膨胀。
Balasubramanian：整个经济账都开始失衡了。
Petr：结果就是每个CFO都只能被迫敞开钱包，因为他们不知道还能怎么办。目前根本谈不上控制。我预测明年这个讨论会完全不同，Token效率将成为主要议题。我们会看到客户尝试转向小语言模型（SLM），并想尽各种办法限制Token开支，因为他们需要成本是可预测的。
Thiruvengadam：这已经成为现实。在与许多客户的沟通中，讨论已经从"预算不设上限"转向"在工程层面限制一定数量的Token或资金"。这种情况正在发生，也正因如此，开源模型逐渐成为一种趋势。人们对"前沿"开源模型感到非常兴奋。
Petr：如果你想要可预测的资本支出，能够在若干年内进行折旧摊销，那就用前沿模型去搭建。这背后到底是怎么运作的，大家心里都清楚但不会公开摆到台面上讨论，但这确实正在发生。
SE：在芯片设计流程中使用智能体AI时，选择不同的AI模型或大语言模型，对每个Token的成本会产生怎样的差异？
Balasubramanian：回到工程师应该掌控什么的问题上，我们与英伟达在长时运行智能体方面展示的一件事就是大语言模型的路由。这属于工具提供商这一侧，或者说负责搭建流程的那一方需要考虑的事情。我们观察到，客户正在变得越来越聪明。对于设计初期阶段，或者那些并不真正需要顶尖模型的设计环节，他们不会调用最新最强的模型，也不会用任何前沿模型，而是使用开源模型，因为这些开源模型能完成任何人所能做到的98%的工作，只有那极端的2%（设计流程中的部分）才需要最强大的模型。六个月前，大家还都在用一辆法拉利去买菜，这完全没有道理。现在人们正在弄清楚该在哪里使用AI产品，以及该使用哪些具体的大语言模型。比如Switchboard（一个AI驱动的通信平台）和英伟达在大语言模型路由方面就做得很好。这需要在设计方、提供方以及软件方共同协作，找出哪种大语言模型最适合特定的工作流程。以前我们只考虑如何更快得到答案，现在成本也要纳入考量。如果是开源的，客户会非常喜欢，他们会说："好，我可以做气隙隔离，可以本地部署，可以加密，能做很多事情。"这就是目前的发展方向。
Petr：有个很有意思的现象是，一些公司算过账后发现，雇一名工程师做同样的工作，比让一个智能体持续运行还便宜。
Balistreri：这取决于你用的是什么智能体。根据我们产品的使用趋势，我们预计未来18个月内，每位工程师每年消耗的Token量将达到1000亿。我认为这不算是浪费或低效的支出。对我们的客户来说，这种预算和投资回报的讨论已经是当下的现实，不是明年才会发生的事，而是眼下正在发生，这已经是新的基准线了。如果你看看我们在自研循环流程中所做的工作，在相同基准下横向对比，同样的任务我们能便宜40%到50%。使用的是同样的底层Opus模型，情况是一样的。这也是为什么我认为开源在这场讨论中越来越受重视。但我们也做了大量的基准测试，这些模型如果没有经过大量的微调和后训练，在这些复杂、长周期的任务上表现并不好，而这正是我们在做的事情。我们发布了自己训练的开放权重模型，在芯片相关的特定任务上，即便面对长周期、高难度的SoC级任务，其表现也能媲美前沿模型，但成本却便宜5倍。客户之所以推动这一点，是因为这需要本地部署，需要安全部署——你的设计和你的工作流程都必须保密。
我再补充一层。大多数智能体在通用大语言模型方案中能用到的是局部上下文，但你真正需要的是全局上下文，也就是团队和个人之间那些未说出口、心照不宣的东西。我们投入了大量精力深入到各个组织内部，把这些内容映射到工作流程中，从而让他们通过效率提升获得投资回报。这既涉及智能体循环和框架层面，也涉及组织流程层面，还涉及模型本身。就在最近，Kimi模型（中国创业公司月之暗面开发的K3 AI）以48美元的成本交付了一款芯片。我听到有人说，这就像造出一辆每小时只能跑一英里的汽车。需要指出的是，一些引擎和工具本质上就是软件，它们会被逐渐吸收进模型本身，尤其是在我们与晶圆厂合作加速这一进程的情况下。但就目前而言，要实现真正具备投资回报的全流程自主成果，你还是需要本体论、工作流程、框架优化，以及那种客户能够本地部署、不必为前沿模型支付离谱Token费用的底层模型。
Petr：你说的这些其实都是"流程捕捉"——如何从一个组织中提取出其工作流程。你现在其实是在谈创建专属技能，这些技能理想情况下应该是确定性的，创建能够封装此前未自动化的工程知识的工具，而这些知识往往只存在于工程师的脑子里。要打通大任务之间的这些衔接环节，需要投入大量工作，而这与任何框架或大语言模型都没有关系。你可以用任何你想用的模型。你在打通这些环节上投入的时间越多，任何大语言模型的能力表现就会越强。所以，没错，你可以用Kimi，但你可能需要花更多时间去打通你的工作流程，确保捕捉到所有细枝末节的细节。如果用一辆大法拉利，它能平推过去，掩盖掉一些心照不宣的东西，但那样也是可以做到的，关键在于你把精力投在哪里。你完全可以选择用Opus，多花一点Token成本；也可以选择多投入时间去做打通和适配的工作。
Balistreri：我不认为这仅仅是打通适配的问题，这也涉及模型本身的微调，有些任务小模型根本处理不了。如果你在思考应该找谁作为合作伙伴来实施智能体AI，并借助全流程自主成果产生投资回报，你需要找的是那种既能深入企业内部梳理工作流程，又能——如果是开放权重模型的话——交付一个经过后训练的模型的伙伴，这个训练可能基于你的数据、你的芯片设计、你的库文件，或者是在基础模型性能之上进一步提升的模型。因为即便是较大的开源模型，其基础模型性能目前也还达不到要求。你要押注智能体AI，那就要想清楚：谁能帮你掌控自己的智能能力？谁能帮你不把组织的核心竞争优势拱手让人？又是谁能真正产生投资回报？现在，如果你想跟前沿模型做对比，直接拿一个现成的模型出来是不行的。
Graham：你所说的其实是强化微调，或者类似的东西。我认为这不是唯一的方式。前沿模型依然有其价值，如果你认为软件可以被吸收进模型中，那么微调很可能更容易被吸收进模型中。再过一年，看看到底哪种方式会胜出会很有意思——是微调模型？是简单问题和难题之间使用方式的分化？还是这三者的某种组合？需要多大程度的气隙隔离？这些问题目前都没有明确答案，最终可能是这些因素的某种组合。就部署模型之前的准备工作而言，如何去做这件事，对企业来说是当前真正的挑战，有些企业正在这几个方面全面下注，另一些则是选择性下注。所需的基础设施应该是什么样的？是找AI合作伙伴来构建定制模型？还是根据自身能力构建内部定制模型？是构建能够对接多种大语言模型的基础设施，无论是本地部署还是云端部署？这里有太多不同的选择。
Thiruvengadam：回到这次讨论最初的核心议题——Token效率，大家说的都有道理。上下文智能可以帮助缓解一部分Token效率低下的问题，或者说降低这类问题。工具素养和工作流程素养同样重要，这也是降低Token成本的另一种方式，而且这些是可以轻松做到的事情。工程师熟悉工具的使用，而这种素养需要传递给AI系统，让它们在调用大语言模型时变得更高效，这就决定了预算规模。所以，工具素养、工作流程素养，以及整体的上下文智能——这是一种途径。至于模型选择的讨论，重点并不在于"你可以用开源模型解决大多数复杂问题"，重点在于它打开了一种可能性。如果你有一个能力足够强的开源模型，那就为客户和供应商双方都提供了选择的余地。他们可以考虑采用一个能力较强的开源模型进行微调。然后，对于混合专家系统而言，剩下的就只是模型路由的问题。你可以部署一个模型路由器，我们已经在做这件事了。我们可以部署一个模型路由器，根据任务的性质和复杂程度来决定使用哪个模型。这些都是能进一步降低Token成本的方式。
Petr：或许我们可以用一句话来总结。有些公司把智能体框架和大语言模型混合在一起，导致很难区分哪部分是大语言模型，哪部分是推理逻辑。但事实上，大语言模型本身在整个技术栈中反而是最不重要的部分。真正的核心工作在于其他一切——包括打通适配工作，还有众多建立在其之上的技术，它们带来了Token效率、上下文处理、各种参考信息，以及可扩展的工具链。开源模型落后前沿模型大约六个月，而如今六个月几乎等同于无限的时间跨度。如果你今天问我，"你想要六个月后才会出现的那个开源模型吗？"我会说"当然想要"，因为我知道到那时它已经领先了整整一个时代。到某个阶段，这些东西会趋于饱和，一切最终都会归结到我们所做的适配和打通工作上。
阅读本系列讨论第一部分：
智能体AI的成功依赖于出色的人类协作框架
在将智能体AI部署到芯片设计中之前，工程师必须先定义领域本体论和智能体运行框架，基础引擎依然至关重要。
Q&A
Q1：Token成本上升对芯片设计行业有什么影响？
A：Token成本正在成为EDA预算中新的争夺焦点，设计团队现在必须把每个Token的成本纳入芯片投资回报的核算中，讨论已从无限制预算转向在工程层面严格限制Token数量或资金投入，这也推动了业界对开源模型的兴趣。
Q2：为什么越来越多客户开始转向开源大语言模型？
A：因为开源模型可以实现本地部署、气隙隔离和数据加密，成本也更可预测。有客户实测显示，经过微调的开源模型在芯片相关任务上能达到接近前沿模型的表现，但成本可以便宜5倍左右。
Q3：如何才能有效降低智能体AI在芯片设计中的Token消耗？
A：需要综合运用上下文智能、工具素养、工作流程素养、强化微调和模型路由等手段。通过模型路由器根据任务复杂度自动选择合适的模型，简单任务用开源模型，复杂任务才调用前沿模型，从而实现效率与成本的平衡。
