智能体AI落地芯片设计，Token成本成为新预算难题

近日多位专家围绕智能体AI在芯片设计领域的最新进展与挑战展开讨论，参与讨论的专家包括Cadence设计系统公司验证软件产品管理高级总监Matt Graham、Alpha Design AI Chipagents业务拓展与战略合作负责人Harrison Balistreri、是德科技高级总监兼投资组合经理Alexander Petr、西门子旗下Mentor EDA AI产品负责人Sathish Balasubramanian，以及新思科技AI产品管理执行董事Anand Thiruvengadam，围绕智能体AI在芯片设计领域的最新进展与挑战展开座谈。

从左至右：新思科技Thiruvengadam、是德科技Petr、Cadence Graham、ChipAgents Balistreri、西门子Balasubramanian

设计团队评估智能体AI工具投资回报，或是向客户估算设计成本时，现在必须把单Token成本纳入考量。各位看到了哪些现状？

Graham：搭建智能体AI体系，没有任何环节是免费的 —— 无论是理论层面还是实际落地层面都是如此。正因如此，设计、验证与实现团队都在向我们咨询Token效率、Token预算，以及如何做相关成本规划。“我该如何预算部署你们的工具、对接配套工具，还有通用代码助手的开销？” 就在过去三四周，这个问题已经成为智能体AI相关讨论里的高频话题。行业整体都认可这项技术具备价值。在座各位的团队都已经用不同方式证明，智能体AI可以在不同程度上带来投资回报。真正的问题在于，我们该如何精准衡量这份回报；各家在Token效率上做得怎么样，能不能证明以特定成本高效输出正确结果。

Petr：在讨论Token投资回报之前，我们先要考虑芯片一次成功需要多少次迭代。信任和验证正是关键。我们可以一直讨论设计师信任这套流程、流片。但台积电一套掩膜版成本动辄数百万甚至上亿美元，这种场景不存在单纯的信任，只有 “信任 + 验证”，矛盾也由此产生。别忘了，验证工作依赖物理仿真引擎，这里要做多物理场仿真。只靠增加本体知识库层，让大模型推理验证，成千上万个智能体消耗大量Token反复核对每一项决策，这条路走不通。最终必须运行仿真引擎。如果热预算出错，无论数字设计、模拟设计做得多漂亮，芯片都会烧毁，项目直接停滞。功耗参数出错，芯片同样会烧毁。因此必须借助具备真实验证能力的引擎，对整板做全维度多物理场仿真。这不是软件行业那种场景：工程师看着几万行代码，看不懂就调用智能体，由智能体判断代码好坏。软件领域就出现过这类问题：亚马逊推送一次更新，AWS服务器直接宕机，因为没人真正理解代码逻辑。这就是现实世界里的AI劣质输出问题。芯片领域也出现同类情况：我们让智能体完成人类原本不会采用的芯片设计方案，甚至尝试把寄生参数转化为设计特性来完成芯片交付。唱个反调：我们可以用炫酷AI、超级智能体、智能体集群简化全部流程，但无节制消耗Token。可一旦芯片或者掩膜版出错，到了这个层级发生问题，就要重新迭代，产生的成本远超所有Token开销。这是我们必须守住的底线，尤其针对新一代大型CPU、AI芯片。这类芯片体量巨大，首次流片失败，项目直接失败，企业甚至会破产。

Graham：核心在于，我们已经掌握芯片量产的方法，也证明AI可以在一定程度上加速流程，但AI并没有消除各类验证要求。下一步趋势是：无论Token是否被浪费，Token预算占掩膜成本的比重越来越高，开始成为不可忽视的支出。去年，行业还完全不在意这笔开销。

Petr：我们当下面临的真实问题是：回看芯片设计公司过去的工作模式，企业先撰写项目方案，测算后得出结论：这款芯片售价要达到X美元，需要生产十亿片或者万亿片才能盈利。之后拆分各项成本，细化到工程人力成本、软件成本。过去EDA预算是固定值，现在不再固定。这就带来难题：底层预算持续膨胀且不可控时，该如何估算芯片定价。过去客户会和我们激烈谈判敲定价格，拆分单工程师成本、单芯片成本，以此规划预算，判断芯片项目是否值得启动。现在我们告诉客户，效率可以大幅提升，价值主张是：同样的工程人力，原本只能做两款芯片，现在可以做十款。但新增了Token预算，这项开销会不受控地膨胀。

Balasubramanian：成本规模会彻底失控。

Petr：最终结果就是CFO只能不断追加预算，没有其他办法，现阶段完全无法管控。我的预判是，明年讨论方向会完全改变。Token效率会成为核心议题。客户会尝试采用小语言模型（SLM），想尽办法控制Token支出，他们需要可预测的成本。

Thiruvengadam：这个趋势已经落地。我们很多客户的讨论重点已经从无上限预算，转变为在工程层面限定Token总量或者Token费用。开源模型热度上升也源于此。前沿开源模型受到大量关注。

Petr：如果你想要可预测的资本开支，能够按多年周期做折旧，就会选用前沿大模型。模型来源问题大家心照不宣，但这件事已经在发生。

在芯片设计流程使用智能体AI时，选用不同AI模型、大模型，会对单Token成本带来哪些影响？

Balasubramanian：回到工程师管控要素这个话题。我们和英伟达合作，针对长时间运行的智能体，验证了大模型路由调度能力。这项能力属于工具供应商，或是流程搭建方。现在客户变得更加理性。初期设计阶段，或是不需要顶级能力的设计任务，他们不再调用最顶尖的前沿模型，而是选用开源模型。开源模型可以完成98% 的常规工作。只有剩下2% 极端复杂的设计环节，才需要最强的大模型。六个月前，所有人不管什么任务都直接调用顶级大模型，好比开跑车去买菜，完全不合理。现在大家开始思考AI的适用场景，挑选匹配工作流的大模型。例如Switchboard这款AI通信平台，和英伟达打造了一套成熟的大模型路由方案。设计师、供应商、软件侧都要判断，哪一类大模型最适配对应工作流。过去我们只关心快速拿到结果；现在成本成为考量因素。开源模型深受客户青睐：“我可以物理隔离系统、本地部署、数据加密，实现很多安全管控。” 行业正在朝这个方向发展。

Petr：一个有意思的事实：部分企业测算后发现，完成同一项工作，雇佣工程师的成本反而低于运行智能体。

Balistreri：取决于智能体本身。基于我们产品的使用趋势预测，未来18个月内，每位工程师每年对应的Token消耗量将达到1000亿。我认为这笔投入不是无效浪费。对我们客户来说，预算与投资回报的讨论已经是现实议题，不是明年才会出现，而是当下的新标准。对比基准方案，采用我们定制化智能体闭环方案，相同任务成本可以降低40%~50%，底层同样基于Opus模型。这也是开源模型热度提升的原因。我们做了大量基准测试：这类复杂任务下，模型必须经过深度微调与后训练才能达到理想性能，而这正是我们所做的工作。我们自研了经过主机端训练的开源权重模型，在长周期芯片任务、复杂SoC任务上性能对标前沿大模型，但成本仅为后者五分之一。客户有这方面诉求，因为模型需要本地部署，保障设计文件与流程的安全。

我再补充一点：通用大模型方案里，智能体只能读取局部上下文；而芯片设计需要全局上下文，需要掌握团队成员之间没有写在文档里的隐性信息。我们深入企业梳理这类隐性知识，嵌入设计流程，帮助客户通过效率提升实现投资回报。这件事同时涉及智能体闭环、调度框架、企业业务流程，以及模型本身。之前Kimi（月之暗面推出的K3 AI）曾传出消息，只用48美元成本完成芯片设计。有人评价，这就像造出一台时速仅1英里的汽车。要注意，很多仿真引擎和工具本质上是软件，未来会被集成进模型内部，我们也在和代工厂合作加速这个进程。但现阶段，想要全自动端到端流程并拿到真实投资回报，需要本体知识库、设计流程、调度框架优化，搭配可本地部署的底层模型，避免为前沿大模型支付高昂的Token费用。

Petr：你讲的本质就是流程提取，从企业内部梳理出完整工作流；打造确定性的专用能力模块，把过去只存在工程师脑海里、无法自动化的工程知识封装成工具。大量工作都用来搭建各个大任务之间的衔接组件，这部分和框架、大模型无关。你可以选用任意模型，在衔接组件上投入越多，大模型能力越强。所以，你确实可以选用Kimi，但要投入更多精力搭建工作流，梳理全部细节。如果选用顶级大模型，可以包容一部分隐性信息，省去部分梳理工作。但两种路线都可行，只是资源投入方向不同：选用Opus这类顶级模型，Token开销更高；选用小模型，则要投入更多精力做流程适配。

Balistreri：这不只是流程适配，还包括模型本身微调。有些任务，小模型根本无法胜任。如果要落地智能体AI，实现全流程自动化并拿到投资回报，合作方既要能深入企业梳理业务流程，还要提供模型。如果是开源权重模型，还可以基于客户自身数据、芯片设计、工艺库做后训练，在基础模型之上提升性能。即便是大型开源基础模型，原生能力也不足以对标前沿大模型。押注智能体AI方案，你需要合作方帮你掌握核心能力、守住企业独有技术优势，并且最终实现投资回报。现阶段，直接开箱即用的模型，很难达到前沿大模型的效果。

Graham：你说的是强化微调，或是类似方案。但我认为这不是唯一路径。前沿大模型依然有应用场景。如果软件工具未来会被集成进模型，微调能力或许更容易嵌入模型本身。一年之后我们再看结果会很有意思：胜出的会是微调模型吗？还是复杂任务、简单任务采用两套模型分流？或是多种方案结合？需要做到多强的物理隔离？目前这些问题都没有标准答案，最终大概率是多种方案组合。部署模型前的体系搭建，对企业来说是很大挑战。有些企业在所有方向都布局，也有企业选择性押注。配套基础设施该如何搭建？是由AI合作伙伴开发定制模型，还是企业自建内部模型，取决于自身实力？或是搭建一套可以同时调度本地、云端多类大模型的基础设施？可选方案非常多。

Thiruvengadam：回到本次讨论的核心 ——Token效率。大家的观点都很合理。上下文智能可以缓解Token低效问题，降低开销。工具理解能力、工作流理解能力同样重要，这也是降低Token成本的手段。工程师熟悉各类工具，要把这份能力迁移给AI系统，让AI更高效调用大模型，以此控制预算。工具理解、工作流理解、上下文智能，都是降本路径。关于模型选型，重点不是 “开源模型可以解决绝大多数复杂问题”，而是它带来更多选择。高性能开源模型，给客户和供应商提供备选方案：基于高性能开源模型做微调。混合专家模型本质就是模型路由。我们已经落地模型路由组件，根据任务类型、复杂度自动选择适配模型。以上都是进一步削减Token成本的办法。

Petr：简单总结一下。部分企业把智能体框架嵌入大模型，导致大模型和推理模块边界模糊。但在整套技术栈里，大模型本身已经不是最重要的一环。真正的难点在于配套能力，大量上层技术负责保障Token效率、上下文管理、资料引用、规模化工具链。开源模型比前沿模型落后大约六个月。放到当下节奏，六个月的差距非常巨大。如果问我想不想要六个月后的开源模型，我的答案是肯定的，因为那时的能力会远超现在。未来某个时间点，模型本身能力会进入瓶颈期，竞争焦点会转移到配套能力搭建上。