Token成本：EDA预算博弈的新战场

核心要点

• 行业讨论的重心已经从无限制 Token 预算，转向在工程层面限制 Token 调用量或者资金额度；不断走高的成本，也让业界对开源模型产生浓厚兴趣。

• 人类工程师需要具备工具理解能力与工作流理解能力，才能在基础大模型层、工具与内存层、编排调度层，有效落地智能体 AI。

• 想要确保智能体精准完成所需工作负载（尤其是混合专家系统），离不开强化学习、工作流捕获以及模型路由技术。

圆桌访谈嘉宾：《Semiconductor Engineering》在设计自动化大会（DAC）闭门会议上，围绕芯片设计中智能体 AI 的最新进展与现存挑战，邀请多位业内专家展开座谈。参会嘉宾包括：楷登电子（Cadence）验证软件产品管理高级总监 Matt Graham；ChipAgents 业务拓展与战略合作负责人 Harrison Balistreri；是德科技（Keysight EDA）高级总监、产品组合经理 Alexander Petr；西门子 EDA EDA‑AI 产品负责人 Sathish Balasubramanian；新思科技（Synopsys）AI 产品管理执行董事 Anand Thiruvengadam。

SE（本刊）： 当设计团队评估智能体 AI 工具的投资回报，或是向客户给出设计成本预估时，现在必须把单 Token 成本纳入考量。各位看到了哪些行业现状？

Graham： 在搭建智能体 AI 这套体系时，没有什么是免费的 —— 无论从理论层面还是实际落地层面都是如此。正因如此，现在设计团队、验证团队、实现团队都来找我们，咨询 Token 使用效率、Token 预算，以及该如何做相关预算规划。“部署你们的工具、部署需要联动的第三方工具、部署通用代码助手，这些我该怎么做预算？” 就在最近三四周，这类问题在智能体 AI 相关沟通里占比大幅提升。

整个行业普遍认可这项技术具备价值，在座各家企业也都用不同方式证明：在不同层级上，智能体 AI 可以带来一定投资回报。但真正的问题在于，我们该如何实实在在地衡量这份投资回报？各家在 Token 效率方面做得怎么样？能不能证明自己可以在明确成本、保证效率的前提下输出正确结果？

Petr： 在讨论 Token 的投资回报之前，我们得先把芯片要经过多少轮迭代才能成功流片这件事想明白，信任与验证的问题就在这里。我们可以一直聊设计师信任这套流程、直接流片，但台积电一套掩模就要耗资数百万、甚至上亿美元，这种场景下不存在无条件信任，只有 “信任且必须验证”，矛盾根源就在这里。

别忘了，验证必须依靠物理仿真引擎，也就是多物理场仿真。不能只搭建一套本体知识层，指望大模型靠推理完成验证，让成千上万个智能体消耗大量 Token 反复核对每一项决策。最后必须运行专业仿真引擎。一旦热预算估算出错，无论你的数字、模拟设计做得多漂亮，芯片都会烧毁，项目直接失败。功耗测算出错，同样会烧毁芯片。

因此必须依托具备真实验证能力的引擎，对全板卡做多物理场仿真校验。不能像软件行业那样：工程师看不懂两万行代码，就丢给 AI 智能体去判断好坏。软件行业已经出现过这种情况：亚马逊推送更新，AWS 服务器直接宕机，因为已经没人真正理解生成出来的代码。

芯片领域同样会遇到这类 “AI 劣质输出” 问题。现在我们让智能体去设计人类原本不会采用的芯片方案，甚至试图把寄生效应当作设计特性来实现芯片交付。唱个反调：我们完全可以靠酷炫 AI、超级智能体、智能体集群把流程做简化，肆意消耗大量 Token。可一旦芯片或者掩模出错，就要重新迭代，这笔开销会远远超过所有 Token 花费。这是我们必须恪守的底线，尤其是新一代大型 CPU、AI 芯片，规模巨大。如果第一次流片失败，项目基本宣告死亡，公司甚至可能就此倒闭。

Graham： 关键点在于，人类已经掌握成熟的芯片交付方法论。AI 确实可以在一定程度上加速流程，但不会消解原本的各项硬性要求。而现在，无论是否存在浪费，Token 预算占掩模总成本的比重已经高到不可忽视。去年大家还完全不在意这件事。

Petr： 现在设计公司的现实困境是：过去项目立项，团队完成测算，“这款芯片售价 X 美元，需要生产十亿或者万亿颗才能盈利”，再拆解成本，一直细化到工程人力成本、软件成本。过去 EDA 预算是固定的，而现在预算不再固定。当底层有一部分成本不受控制、持续膨胀，芯片定价估算就变得十分棘手。

过去客户会和各家厂商激烈谈判敲定价格，拆解单工程师成本、单颗芯片成本，以此做预算推演，判断这款芯片值不值得研发。现在我们告诉客户，AI 可以大幅提升效率，同样人力可以完成 10 款芯片而不是 2 款，听上去很美好，但随之而来的 Token 预算会不受控地暴涨。

Balasubramanian： 经济模型直接失衡。

Petr： 于是 CFO 只能被动掏钱，没有有效的管控手段。我的预判是，明年整个行业讨论风向会彻底改变。Token 使用效率会变成核心议题。客户会尝试采用小语言模型 SLM，想尽一切办法控制 Token 开支，他们需要成本具备可预测性。

Thiruvengadam： 这种转变已经发生。我们很多客户的讨论主题，已经从无限制预算，变成在工程层面限定 Token 数量或者资金上限。也正是这个原因，开源模型热度持续走高，业界对前沿开源模型抱有很高期待。

Petr： 如果你想要可预测、可以分多年折旧的资本开支，就可以选用前沿开源模型。模型的来源问题很多时候被摆在台面之下，但这类实践正在真实发生。

SE： 在芯片设计流程里使用智能体 AI，选用不同 AI 大模型，会对单 Token 成本带来多大差异？

Balasubramanian： 回到工程师管控的话题。我们和英伟达在长周期智能体项目中验证过模型路由机制，这是工具厂商或者流程搭建方要处理的工作。客户现在变得越来越理性：设计初期或者非关键环节，不再一味调用最强前沿大模型，改用开源模型。开源模型可以完成 98% 的工作；只有剩下 2% 极端复杂场景，才动用顶级大模型。

六个月前，大家干什么都调用最强大模型，好比开跑车出门买菜，完全不合理。现在企业开始思考不同任务适配哪一套 AI 产品、哪一款大模型。Switchboard 以及英伟达的模型路由方案就做得很好。设计者、工具厂商、软件侧需要共同判断，什么样的工作流适配哪一款大模型。过去我们只追求快速拿到结果，现在成本成为重要考量。开源模型很受客户欢迎：可以物理隔离网络、本地部署、加密数据，诸多特性都是行业发展方向。

Petr： 一个有意思的现象：有些企业测算之后发现，部分工作交给人力工程师完成，成本反而低于调用智能体。

Balistreri： 取决于你用的是什么智能体。按照客户使用趋势测算，未来 18 个月，每位工程师每年对应的 Token 消耗量将达到 1000 亿。但这不代表属于无效开销。对我们的客户来说，预算与投资回报的讨论不是未来话题，而是正在发生的现实，已经成为新行业基准。

在我们自研的定制智能体循环框架之下，完成同样任务，成本相比基准方案可以降低 40%‑50%，底层用的还是 Opus 大模型。这也是开源模型被频繁讨论的原因。但复杂任务下，模型必须经过大量微调与后训练才能发挥能力，这部分是我们要完成的工作。

我们发布过自研的权重开放模型，在长周期、高难度 SoC 芯片专属任务上，能力对标前沿闭源大模型，但成本仅为后者五分之一。客户对此需求强烈，因为模型需要本地部署，保障设计文档、工作流的安全。

再补充一点：通用大模型只能拿到局部上下文，而芯片设计更需要全局上下文，也就是团队、人与人之间那些没有写在文档里的隐性知识。我们深入企业内部，把这类隐性知识映射到工作流，帮助客户靠效率拿到投资回报。这件事同时涉及智能体循环框架、智能体调度基座、企业业务流程，以及模型本身。

网上看到 Kimi 模型宣称 48 美元完成芯片设计，打个比方，这就像造出来一台只能每小时跑一英里的汽车。要注意，部分引擎与工具未来会被整合进模型，我们也正在和晶圆厂合作加速这件事。但就当下而言，想要实现全流程自主交付并且拿到真实投资回报，本体知识体系、业务流程、智能体基座优化，再加上可以本地部署、不用承担前沿模型高昂 Token 费用的底层模型，缺一不可。

Petr： 你讲的本质就是工作流捕获：如何从企业中提取沉淀业务流程，构建具备确定性的专属能力模块，把只存在工程师脑子里、过去没有自动化的工程知识封装成工具。大量工作量花在各个大任务之间的衔接环节，这部分和框架、大模型本身无关，随便什么模型都可以接入。你在衔接环节投入越多，大模型发挥的能力就越强。

所以，你可以用 Kimi，但你就要投入更多精力做流程适配，梳理全部细枝末节。如果用能力更强的前沿大模型，它可以消化很多隐性信息，适配工作会简单不少，但 Token 开销更高。两种路线都可行，只是资源投入的侧重点不一样：要么多花 Token，要么多投入人力做流程适配。

Balistreri： 这不只是流程适配的问题，模型本身的微调同样关键。有一部分任务，小模型天生就处理不了。想要落地智能体 AI、拿到全流程自主运行的投资回报，合作方既要能深入企业梳理业务流程，又要能交付适配的模型。如果选用开放权重模型，最好还可以基于企业自身数据、芯片设计文件、IP 库做后训练优化，补齐基础模型的短板。即便是开源大模型，原生基础版本性能也达不到要求。

押注智能体 AI，你需要合作伙伴帮你掌握属于自己的智能能力，不把企业独有的技术优势拱手交出，同时真正实现投资回报。现在直接开箱即用的模型，很难对标前沿闭源模型的效果。

Graham： 你说的就是强化微调这类技术。但这不代表只有这一条路。前沿大模型依然有它的应用场景。如果软件可以被融入模型，那微调工作也更容易被模型本身承接。再过一年我们就能看到结果：胜出的会是微调模型？还是简单任务、复杂任务采用两套不同模型的分化模式？又或是多种方案的混合？物理隔离部署的要求要做到什么程度？这些问题目前都没有标准答案，大概率会是多种路线并存。

企业部署模型前，选型搭建基础设施就是实实在在的难题。有些企业多条路线同时押注，有些企业选择性布局。基础设施要怎么搭建？是找 AI 合作伙伴定制模型，还是依靠自身力量搭建内部定制模型？还是一套基础设施同时兼容本地部署与云端调用的多款大模型？可选路线非常多。

Thiruvengadam： 回到本次讨论的原点 ——Token 效率。各家的方向都是正确的。上下文智能可以缓解 Token 低效问题；工具理解能力、工作流理解能力同样重要，这是另一条降低 Token 成本的路径。工程师要吃透工具，并且把这种理解赋予 AI 系统，让大模型调用更加高效，直接决定预算高低。工具理解、工作流理解、上下文智能，都是降本手段。

谈及模型，开源模型不是说拿来就能解决绝大多数复杂问题，它提供的是一种可能性。高性能开源模型，给客户和厂商多了选择，可以拿来做微调。面对混合专家架构，就可以上模型路由器 —— 我们已经在落地。模型路由器分析任务本身和复杂度，自动挑选最合适的模型，进一步压低 Token 开销。

Petr： 可以做一个简单总结。部分厂商把智能体框架和大模型深度耦合，让人很难区分大模型本体和推理模块。但在整套技术栈中，大模型本身已经是最不重要的一环。真正的工作量，集中在上层各类配套技术：流程适配、上下文处理、引用管理、工具链调度，这些才是实现 Token 效率的核心。

开源模型整体比前沿闭源模型落后约六个月。放在当下的行业节奏，六个月已经是巨大差距。如果现在问我要不要拿到六个月之后的开源模型，我的答案毫无疑问是肯定的，那代表着巨大的技术进步。终有一天模型能力会趋于饱和，行业竞争的重心，会完全落到流程适配与工程实现层面。